> ## Content Index > Fetch the complete content index at: https://www.rumblingmind.com/llms.txt > Use this file to discover other available public pages before exploring further. # When Privacy Risk Becomes Physical Risk - URL: https://www.rumblingmind.com/when-privacy-risk-becomes-physical-risk/ - Published: 2026-10-10T19:26:40.000Z - Updated: 2026-10-10T19:26:40.000Z - Author: Saad Bin Hamid ### What happens when the data stays the same, but the world around it doesn’t? Most enterprise data is spectacularly boring. Names. Employee IDs. Phone records. Travel history. Building-access logs. Authentication timestamps. Backups. Cloud regions. Nobody collecting any of this is usually thinking about geopolitics. HR needs to manage employees. IT needs to authenticate users. Finance needs records. Security needs logs. Telecom operators need metadata to keep networks running. Architects need backups because, apparently, “we’ll restore it from production” still doesn’t qualify as a resilience strategy. Most days, this is all completely normal. - Then the environment changes. - The database is still the same. - The employee is still the same person. - The application may still be running the same version. But the consequences of someone accessing that information may no longer be the same at all. That led me to a question I found increasingly difficult to ignore: > **Can data that creates perfectly legitimate business value in one environment create disproportionate risk in another?** --- ## The data did not change The humanitarian context gives us one of the clearest examples of what this really means. The [UN Office for the Coordination of Humanitarian](https://centre.humdata.org/ufaqs/how-can-i-assess-and-manage-the-sensitivity-of-data-before-sharing-on-hdx?ref=rumblingmind.com) Affairs points out that the sensitivity of information depends heavily on context. The location of a medical facility may be valuable information during a natural disaster. In a conflict environment, the very same coordinates could put patients and staff at greater risk. - Same information. - Different environment. - Very different consequence. Privacy practitioners will quite reasonably say: this is not a new idea. And they are right. [NIST’s Privacy Framework](https://www.nist.gov/privacy-framework/getting-started-0?ref=rumblingmind.com) already treats privacy risk as contextual and recognises that data processing can create consequences ranging from embarrassment and discrimination to economic loss and physical harm. So this is not an argument that privacy professionals somehow missed context. The more interesting question is what happens when that change in context starts rippling through the rest of the enterprise. > **Because geopolitics has an irritating habit of eventually becoming an IT problem.** --- ## Enterprise architecture has a few invisible assumptions Look at a normal architecture diagram. Applications. Networks. Identity. Databases. Cloud regions. Integrations. Possibly seventeen arrows nobody remembers approving. What you probably will not find is a box labelled: ***POLITICAL REALITY*** Yet plenty of assumptions about the outside world are embedded in the design. - That a jurisdiction remains acceptable. - That the authority overseeing a market tomorrow will behave broadly as it does today. - That a cloud region will remain reachable. - That administrators can continue operating from their current locations. - That a supplier will still be permitted to serve the customer. - That the network path between two systems remains viable. - That keeping another copy of data improves resilience rather than exposure. - That historical data which is useful today remains harmless tomorrow. None of these are unreasonable assumptions. Technology architecture has to assume something about the environment in which it operates. The problem appears when the environment changes but the architecture — and the data inside it — does not. Most enterprise architecture is designed for most days. The interesting cases begin when several assumptions stop being true at once. ![](https://storage.ghost.io/c/87/2a/872aa023-c87f-4280-82c7-4458d05d5c54/content/images/2026/10/The-Data-Didnt-Change.-The-Environment-around-it-did.png) > ***The data can stay exactly where it is while the assumptions around it move.*** --- ## When billing metadata stops looking like billing metadata Telenor’s experience in Myanmar is an unusually revealing enterprise case. Call data records are not exotic datasets. They are part of running a telecommunications network. Telenor itself explained that such records can contain information including the parties to a communication, its timing and duration, and the tower or base station through which it passed. The company used them for routine purposes including service provision, billing, quality monitoring and customer care. Perfectly ordinary telecom operations. Then Myanmar’s operating environment changed dramatically following the military takeover in February 2021. Telenor received numerous authority directives. It faced network restrictions, changing transparency constraints, employee-safety considerations and, eventually, a requirement that operators activate interception equipment. The company said activation would conflict with Norwegian and international sanctions and became a key reason for its decision to leave the market. But leaving did not magically remove the data problem. Telenor said local law required operators to retain traffic data and that instructing employees to delete it could expose them to danger for violating local law or military orders. This is where an apparently technical question becomes uncomfortable. The data had not suddenly become different data. Its relationship with the world around it had changed. - Who might obtain it. - What legal authority applied. - What options the company had. - What consequences different actions might create for customers and employees. And whether deleting, retaining, transferring or restricting access could itself create another category of risk. The Norwegian OECD National Contact Point later examined Telenor’s exit and [raised questions around the adequacy of aspects of its human-rights due diligence and preparedness](https://responsiblebusiness.no/en/2026/01/12/ncp-norway-concludes-examination-of-specific-instance-with-final-statement?ref=rumblingmind.com). Telenor disputed several conclusions while agreeing on the importance of earlier planning for responsible exits from unstable markets. That disagreement matters. There was no neat button marked “responsible outcome”. Sometimes preparedness does not guarantee a clean decision. It creates more options before the options disappear. --- ## Sometimes the safest answer is the opposite answer If the Telenor case points towards reducing exposure and controlling access, Ukraine provides an apparently contradictory lesson. Following Russia’s 2022 invasion, Ukraine moved critical government information away from vulnerable physical infrastructure. A World Bank review describes regulatory changes that allowed state information resources and public electronic registries to be placed in cloud environments, including outside Ukraine. More than 100 state and critical information registries were migrated. Here, resilience meant increasing geographic distribution. PrivatBank provides an enterprise example from the same environment. According to an AWS case study, the bank moved 4 petabytes of client data, 270 applications and workloads across 3,500 servers in roughly two months. The objective was not to make the data less reachable. It was to preserve the bank’s ability to operate despite threats to physical infrastructure. The figures are vendor-reported, so they should be treated accordingly. - But the architectural point is still useful. - Sometimes safety means reducing access. - Sometimes resilience means creating new paths to the data. - And occasionally sovereignty and survivability point in different directions. [SAP faced](https://www.datacenterdynamics.com/en/news/sap-plans-orderly-exit-from-russia-over-ukraine-invasion-shutdown-of-cloud-services/?ref=rumblingmind.com) another variation when winding down its cloud operations in Russia in 2022\. Non-sanctioned customers were given options to have their cloud data deleted, returned to them, or migrated to a data centre outside Russia. - Delete. - Transfer. - Move. - Preserve. Four verbs that could produce very different outcomes from the same basic technology estate. That is why “protect the data” is not quite enough as a decision rule. The appropriate action depends on what has changed around it. ![](https://storage.ghost.io/c/87/2a/872aa023-c87f-4280-82c7-4458d05d5c54/content/images/2026/10/3_3.png) > ***Same underlying challenge. Very different responses. The operating environment determines which data decision becomes safer.*** --- ## Protecting data can create another problem The International Committee of the Red Cross offers an even sharper illustration of the tension. In 2022, the [ICRC disclosed that](https://www.icrc.org/en/document/cyber-attack-icrc-what-we-know?ref=rumblingmind.com) attackers had gained access to servers containing personal information concerning more than 515,000 people, including missing people and their families, detainees and others receiving humanitarian services. Taking compromised systems offline was clearly necessary. But those systems also supported the Restoring Family Links programme. The [ICRC said the Red Cross and Red Crescent Movemen](https://www.icrc.org/en/document/sophisticated-cyber-attack-targets-red-cross-red-crescent-data-500000-people?ref=rumblingmind.com)t normally helped reunite around 12 missing people with their families each day, and that disruption to the affected systems impeded that work. That tension is worth sitting with. Keeping information accessible created one kind of risk. Making it inaccessible created another kind of harm. Cybersecurity people will recognise this immediately. Confidentiality and availability have been arguing with one another since long before anyone invented a catchy acronym for Zero Trust. The interesting part is not that the trade-off exists. It is that a change in the external environment can alter the weighting between those objectives very quickly. The right answer may be less accessibility. - Or more redundancy. - Or tighter key custody. - Or geographic relocation. - Or shorter retention. - Or keeping critical systems available despite increased exposure. What changes is the appropriate balance. ![](https://storage.ghost.io/c/87/2a/872aa023-c87f-4280-82c7-4458d05d5c54/content/images/2026/10/2.png) *Four cases. Four different ways a changed operating environment altered the data decision.* --- ## The most consequential dataset may not be a dataset There is another complication. Enterprises tend to classify information in neat containers. - HR data. - Travel data. - IAM logs. - Building access. - Customer records. - Location data. - Cloud telemetry. Each dataset may have a sensible owner, classification and retention rule. But real-world consequences do not necessarily respect database boundaries. - An employee directory tells me who you are. - An access-control system tells me where you entered. - Authentication logs tell me which systems you use. - Travel data may tell me where you are going. - Organisational records tell me what you do. Individually, each dataset may be unremarkable. Joined together, they can reveal something none of the systems was designed to reveal on its own. This is sometimes discussed as a mosaic effect: information that appears relatively benign in isolation acquires sensitivity through combination. Which raises an awkward possibility: > **The most consequential dataset in an enterprise may not be a dataset at all. It may be a join.** That is a slightly different problem from traditional classification. The question is no longer only: “How sensitive is this system?” It becomes: “What could someone infer if this system were combined with everything else we already know?” And once again, the answer depends on context. --- ## This probably does not require another framework Enterprise technology is not suffering from a shortage of frameworks. NIST. ISO. COBIT. ITIL. Privacy frameworks. Cyber frameworks. Risk frameworks. Continuity frameworks. We are, frankly, quite well supplied. Nor is the underlying idea absent from them. - Privacy frameworks recognise contextual harm. - Cybersecurity frameworks recognise changing threats. - Risk management expects organisations to reassess conditions. - Zero Trust and risk-adaptive access models already make access decisions using contextual signals. - Business continuity exists precisely because circumstances change. So I do not think the answer is another six-box diagram with an acronym ambitious enough to deserve its own conference booth. The issue is more mundane. And perhaps more difficult. **Can the organisation connect a change outside the technology estate to the assumptions inside it?** - When country risk changes, which data decisions change? - When legal authority changes, which access decisions change? - When infrastructure becomes vulnerable, does resilience require fewer copies or more? - When a supplier can no longer operate in a geography, where does custody move? - When retaining a record creates one risk but deleting it creates another, who is actually empowered to make that decision? Those questions cross privacy, cybersecurity, architecture, legal, risk, cloud, business continuity and executive management. - Which usually means they belong completely to everyone. - And therefore, if we are not careful, operationally to no one. --- ## The assumption worth testing None of this means enterprises should start designing every system around coups, wars or sanctions. That would be absurd. Nor does every organisation carry the same exposure. A domestic retailer, a multinational telecom operator, a critical-infrastructure provider and a global SaaS company live with very different dependencies. The point is simpler. Enterprise technology architectures quietly embed assumptions about the environment in which data will exist and be used. Most of the time, those assumptions remain invisible because they remain true. Geopolitical disruption can make them visible very quickly. The enterprise challenge is therefore not predicting every geopolitical crisis. It is understanding which business and technology decisions depend on assumptions that could change — and which options we would want available if they did. That feels less like a privacy question. And more like an enterprise resilience question with privacy, architecture, cloud, identity, legal risk and human consequences tangled together inside it. Which brings me back to the question that started this research: > **If the world around our data changed tomorrow, which of today’s technology decisions would we suddenly wish we could change?** - Data has a habit of outliving the reason we collected it. - Risk, inconveniently, can have an even longer memory. --- ## Research note The cases in this article explore different ways in which a changing external environment can alter technology and data decisions. They are not intended to suggest that the circumstances, severity or human consequences of these cases are equivalent. Humanitarian examples are used cautiously to understand mechanisms of contextual data risk. The broader enterprise interpretations — particularly the connection between geopolitical change, enterprise architecture and the options available to technology leaders — are my own. An earlier version of this essay was published on LinkedIn. --- ## Source and Notes 1. [**OCHA Centre for Humanitarian Data — “How can I assess and manage the sensitivity of data before sharing on HDX?”**](https://centre.humdata.org/ufaqs/how-can-i-assess-and-manage-the-sensitivity-of-data-before-sharing-on-hdx/?ref=rumblingmind.com) Used for the example showing that the same information can have very different sensitivity depending on context, including medical-facility locations in conflict settings 2. [**NIST — “Privacy Framework: A Tool for Improving Privacy Through Enterprise Risk Management, Version 1.0” (2020).**](https://csrc.nist.gov/pubs/cswp/10/nist-privacy-framework-version-10/final?ref=rumblingmind.com) Used for the discussion of contextual privacy risk and enterprise risk management 3. [**Telenor Group — “Directives from authorities in Myanmar – February 2021–February 2022.”**](https://www.telenor.com/esg/social/human-rights-in-myanmar/directives-from-authorities-in-myanmar-february-2021-new/?ref=rumblingmind.com) Used for call-data-record definitions, authority directives, interception requirements and the changing operating environment in Myanmar. 4. [**Telenor Group — “We cannot make our employees in Myanmar delete data and break the law” (18 February 2022).**](https://www.telenor.com/media/newsroom/announcement/we-cannot-make-our-employees-in-myanmar-delete-data-and-break-the-law-update-by-jorgen-c-arentz-rostrup-evp-and-head-of-telenor-asia/?ref=rumblingmind.com) Used for Telenor’s explanation of traffic-data retention obligations, employee-safety considerations and the constraints surrounding its exit. 5. [**Norwegian OECD National Contact Point — “SOMO on behalf of 474 CSOs in Myanmar vs Telenor ASA.” Final Statement, 11 December 2025.**](https://responsiblebusiness.no/en/unique-grievance-mechanism/specific-instances-handled-in-norway/somo-on-behalf-of-474-csos-in-myanmar-vs-telenor-asa/?ref=rumblingmind.com) Used for the discussion of due diligence, preparedness and responsible-exit planning. The NCP is a non-judicial mechanism. 6. [**Telenor Group — “Telenor’s forced exit from Myanmar – in response to the NCP’s final statement” (11 December 2025).**](https://www.telenor.com/media/newsroom/press-releases/telenors-forced-exit-from-myanmar-in-response-to-the-ncps-final-statement/?ref=rumblingmind.com) Included to reflect Telenor’s disagreement with several NCP conclusions while acknowledging the importance of earlier responsible-exit planning. 7. [**Telenor Group — Q1 2021 Interim Report.**](https://www.telenor.com/binaries/investors/reports-and-information/quarterly/2021/Telenor-Group-Q1-2021-Report-0fe827900a389764548e3e7664530a14.pdf?ref=rumblingmind.com) Source for the 18.2 million Myanmar subscriber figure used in the visual. 8. [**World Bank — “Advancing Cloud and Data Infrastructure Markets.”**](https://documents1.worldbank.org/curated/en/099052824071033398/pdf/P1730321d6e1a30f71ae7717923561a28a4.pdf?ref=rumblingmind.com) Used for the Ukraine case, including the migration of more than 100 state and critical-information registries to cloud environments. 9. [**Amazon Web Services — “PrivatBank Protects Business, Safeguards Customer Access to Banking Services at Time of Unrest by Migrating to AWS.”**](https://aws.amazon.com/solutions/case-studies/privatbank-case-study?ref=rumblingmind.com) Source for the vendor-reported migration of 4 PB of client data, 270 applications and 3,500 servers in roughly two months. 10. [**Data Center Dynamics — “SAP plans ‘orderly exit’ from Russia over Ukraine invasion, shutdown of cloud services” (20 April 2022).**](https://www.datacenterdynamics.com/en/news/sap-plans-orderly-exit-from-russia-over-ukraine-invasion-shutdown-of-cloud-services?ref=rumblingmind.com) Used for SAP’s statement that non-sanctioned customers could have cloud data deleted, returned to them or migrated outside Russia. 11. [**International Committee of the Red Cross — “Cyber-attack targets Red Cross Red Crescent data” (2022).**](https://www.icrc.org/en/document/sophisticated-cyber-attack-targets-red-cross-red-crescent-data-500000-people?ref=rumblingmind.com) Source for the compromise affecting data relating to more than 515,000 people, the shutdown of affected systems and the estimate that the Red Cross/Red Crescent Movement normally helped reunite around 12 missing people with their families each day.