Beyond legal #16: GRC leaders - your chance to shine

In this post #16 of my Beyond Legal series, I want to cover a couple of areas, one is timely as companies try to make sense of current global events and the second is a common frustration I hear from GRC leaders: they have a leader title, but they struggle to get buy-in from their peers.

In some companies, governance is still framed as review, approval, and constraint. It's something that happens after strategy, after architecture, and after procurement.

These days, geopolitical events are forcing many European organisations to explore reducing dependencies on US vendors. It's a feasibility question and a business issue (not just a tech issue) that cuts through operating models, product delivery, security dependencies, and the end-to-end processing and movement of data, and is no longer just a legal discussion about transfer mechanisms (SCCs or frameworks).

And this is why I keep coming back to a line that I think matters a lot these days: GRC should be a design requirement for a company's business model and if you are a GRC leader, you have an opportunity now be part of the important conversations that are could be taking place in your company.

Convergence is the new operating reality
In an earlier post on The convergence of AI Governance, Data Protection, and ESG, I stated that these disciplines can no longer be managed in silos, or as separate pieces of work. I repeat here a few phrases from the post

• AI governance - “compliance is in code”

• Trust - evidence and certification rather than marketing promises.

• The environmental footprint of digital is becoming measurable - “digital is physical”.

• Data sovereignty and fragmented digital markets are now shaping IT architecture and business strategy.

If you are struggling with getting buy-in for your work, this convergence could be your way in. It's going to allow you to stop talking about data protection, privacy or GRC as siloed specialist concerns and start talking about governed digital transformation as a foundation for growth, resilience, and market access.

Sovereignty is also about dependency

Years ago I shared a post on LinkedIn that was perhaps relevant back then in relation to GDPR, but I think things have certainly moved on in relation to mapping data flows across the data lifecycle and the kinds of questions to ask as part of your risk assessment. Fit for purpose back then perhaps but not for the challenges we face today.

I'm currently seeing many articles in the tech media and on LinkedIn where tech leaders say "we need to reduce our dependency on US vendors,” or words to that effect but I sense some may underestimate what dependency actually means.

It's not just about where data is stored (residency). Dependency shows up in control planes and less obvious flows such as identity providers, key management, device management, monitoring and telemetry, vendor support access, backup flows, and embedded AI services where prompts and context flow in ways few people have mapped. And don't forget the often invisible supply chain of your vendors, in other words, your vendors' vendors, and so on.

I'm currently looking for a similar mapping approach that can be used to capture the hidden sovereignty risks inherent in modern, integrated architectures. The diagram above is a simple Excalidraw mock-up based a few diagrams I've seen shared online. It hopefully moves beyond the simpler data lifecycle diagrams I made back around 10 years ago - this is work in progress, and any input you may have will be welcomed.

The answers to the questions many tech leaders are asking right now should not involve a knee-jerk vendor purge. For example, anything US is no-go, cut it immediately. The right response is to conduct a methodical, business-facing assessment that answers: What would it take? What would it break? What is the impact on our business objectives? And critically: what type of risk are we actually talking about?

I also think there are quite a few companies claiming they know their data flows, or at least that's what they say on the stage when presenting at conferences. In practice, they may know fragments of the reality and that is not enough for sovereignty decisions because sovereignty risk often lives in the secondary flows as I illustrate in my mock-up above: diagnostic logs, analytics tags, customer support tooling, cross-region failover, developer environments, and shadow AI usage.

"Sovereignty Feasibility Assessment"
As I've written many times over the years, my business analysis education through BCS in London around 20+ years ago gave me some very useful tools and techniques including the concept of conducting a feasibility study or feasibility analysis, rather than jumping right in making brash decisions here and there, and I therefore think it can be applied to help figure out how to address today's sovereignty challenges

So if you lack business support or buy-in, don’t start by proposing a sweeping “sovereign cloud programme.” Instead, propose to conduct a time-boxed (and what I call) a Sovereignty Feasibility Assessment with a clear output: a set of scenarios and their business impacts. This requires getting the right people in the room - Enterprise Architecture, Security, Data/AI leadership, Procurement, Product, Operations, and ESG/Sustainability to name a few examples.

The deliverable is a small number of realistic scenarios or options, for example:

• Harden and Segment: Reduce exposure via encryption and keys without replacing the vendor.

• Multi-Sovereign: Regional routing and localised control planes.

• Dual-Stack: Replace specific domains while retaining incumbents for others.

• Full Decouple: (Not fast, not cheap, but sometimes necessary).
  

The value is the explicit trade-offs that must be described in business language.

Below is a mock-up of a simplified scenarios matrix which in reality would eventually require actual quantification in terms of cost, time impacts, etc. Obviously different scenarios exist dependent upon your business context.

We also really need to be clear about the type of risk we are referring to here - it's sovereignty risk and how this is assessed and eventually articulated to senior leadership is important. Since the goal is risk reduction via, say, "Decoupling," the risks being treated are likely to be around:

• Extraterritorial access, i.e., the risk of foreign governments (e.g., US Cloud Act) accessing data regardless of where it is legally "resident."

• Vendor lock-in / sanctions, i.e., the risk of being cut off from critical infrastructure due to trade wars or policy changes.

• Operational resilience, i.e., the ability to operate autonomously without reliance on a global control plane.

Once you understand these risks you can then link them to other organisational risks that you may have previously identified and mapped in a causal loop diagram showing the potential ripple effects (see this post that covers this concept) of these sovereignty risks.

What happens to your business if you jerk your knee?
This is the part many governance narratives avoid. Reducing dependencies can strengthen resilience, but your company can quickly be in free-fall as a result if you don't do things in a methodical manner with a calm head. You need to understand the impacts, such as:

• The impact on innovation
  Hyperscalers often provide best-in-class managed services and AI acceleration. Replacing them can reduce velocity and create talent challenges. Your teams may interpret or experience this as a step back, unless the migration is paired with architectural simplification.

• The impact on resilience
  Putting all your eggs in one basket (over-dependence) creates systemic risk i.e., single provider, single jurisdiction. Reducing concentration improves continuity and your ability to negotiate.

• The market impact
  Sovereignty can be a commercial and positive differentiator, especially when talking about "trust" but it can also result in plenty of negative impacts.

• Impact on the operating model
  Orchestrating the right people to conduct this "sovereignty work" forces a company to ask some very fundamental questions that they wished they had the easy answers to: Who owns this data product? What is the authoritative source? Where is deletion actually enforceable? This is very much about “compliance is in code” that I referenced earlier in this post. Also as I mentioned earlier, this is a business issue especially these days when tech is integrated tightly in business processes and ownership is in the business.

Where does ESG and CDR fit in?
Corporate Digital Responsibility (CDR) is getting attention globally, but to be fair, it does have deeper roots in Europe. The European Commission’s approach to data and AI is increasingly framed around societal outcomes, not just economic growth.

For GRC leaders, CDR can be the bridge that binds sovereignty to ESG. It extends the Social and Governance pillars into the digital domain, for example, digital inclusion, fairness, transparency, bias prevention. It also touches Environmental concerns through sustainable ICT.

My point certainly isn’t to transform every vendor decision into an ESG initiative, rather to show that digital transformation is now part of how the company delivers on its broader obligations and long-term license to operate in the markets it's present in or wishes to enter.

To conclude, if you take one idea from this Beyond Legal post: stop trying to get buy-in through policy. Instead, achieve it through relevant dialogue and methodical practices.

You change the conversation and hold attention when you can present a lineage-based diagram of how the company’s data actually flows and all the vendor dependencies that go with it.

We are living in times that demands method, not knee-jerk reactions. Get the right competences around the table, map the lineage, and turn sovereignty into a set of feasible scenarios.

Purpose and Means is a niche data protection and GRC consultancy based in Copenhagen but operating globally. We work with global corporations providing services with flexibility and a slightly different approach to the larger consultancies. We have the agility to adjust and change as your plans change. Take a look at some of our client cases to get sense of what we do.

We are experienced in working with data protection leaders and their teams in addressing troubled projects, programmes and functions. Feel free to book a call if you wish to hear more about how we can help you improve your work.