What To Do Next

Most large organizations have a sovereignty budget and a governance program. Most are not yet ready to keep critical services running if a supplier, cloud service, software component, or support path becomes unavailable. The recommendations below close that readiness gap by turning intent into tested operational capability.

• - Test the exit from an environment, against a clock. Choose one critical production workload, move it or a full copy of it to a second environment, and time the move, at least once a year and after any major change. A plan that has never been run describes what you hope will happen: 41.4% of organizations hold a formal, tested contingency plan, and only 24% could move a critical workload within 30 days.
• - Write exit plans into the contract at renewal. At the next infrastructure renewal, add a documented migration path with timelines and data-export commitments, and identify in advance where support would come from if the primary vendor could no longer provide it, which can mean a third party, or your own staff certified to support the components you depend on. Sovereignty is already decisive at renewal for 43.7% of buyers, and few have either term in writing.
• - Prefer open, commercially supported software where being trapped is the risk. Choose software you can inspect, patch, and move, backed by a commercial support contract with service-level guarantees, patching, and legal indemnification, and run it the same way across a public cloud, a sovereign region, a private cloud, and on-premises. Unsupported open source is the wrong choice for anything critical.
• - Build an inventory you can act on. List every cloud, vendor, and hosted service the business depends on, and for each record where the data sits, who holds the encryption keys, which open-source components run underneath, and what would replace it. Most inventories stop at the application layer, where exits actually fail.
• - Assess every supplier, and make the assessment include a way out. Extend your sovereignty framework beyond critical vendors to every supplier: every one should answer whose law reaches the data held for you, who staffs your support and where, and how you leave. Disruptions practitioners described came from acquired vendors and small suppliers as often as from the largest.
• - Settle who owns sovereignty, and report it to the board as a risk. Give one owner, whether the CIO, the CTO, the CISO, or the chief risk officer, authority to accept or reject a dependency on the organization's behalf, and report accepted dependencies to the board like any other operating risk, with the exit tested and the second source named. 21% of organizations report active internal disagreement about direction or ownership.
• - Revisit the decision to consolidate every year. If the plan is to place most workloads with a single provider, write down the assumptions behind it and review them on a fixed schedule, keeping the exit tested and the second source live. A data center's location does not grant legal immunity, and encryption does not settle the question while the provider holds the keys.
• - If you run a large enterprise, go first. Size, legacy systems, and a footprint across several jurisdictions make the largest organizations the most exposed and the slowest to move, so start with one workload and the exit test this year. What that test shows decides the rest of the list.

If we cannot administer their cases or make their payments, it disrupts their ability to put food on the table. In the worst case, it could lead to civil unrest. — CDIO, large public agency in EMEA