A useful board discussion about digital sovereignty starts with one service the organisation must be able to control. Choose payroll, customer orders, a clinical scheduling system or another process whose interruption has a clear consequence. Ask what the organisation could still decide and execute if a critical supplier became unavailable.
The answer needs evidence: an exercised recovery path, a usable export, an authorised deputy, a contract someone has checked. A supplier list alone cannot show how these parts work together.
Swiss federal cybersecurity guidance for businesses and public authorities places risk and continuity decisions with senior management and emphasises explicit responsibilities when IT is outsourced. The checklist below is an operational companion for that discussion. It does not certify legal or regulatory compliance.
Start with one bounded service
Write down the service, the people affected, the interruption the organisation can tolerate and the business result that must be preserved. Management should state the tolerance and its reasoning before the exercise begins. The board can then challenge whether the resources, authority and evidence support it.
Use the six layers of the Observatory to examine the same service from different directions. Record each answer as demonstrated, documented but untested, or unknown. Those descriptions are working notes; they do not replace the Observatory's assessment scale.
1. Infrastructure sovereignty
Ask the operator to show the path from normal operation to a tested fallback. Include power, network, storage, identity and access to recovery instructions. A second environment that depends on the same unavailable login or network may fail at the same moment.
Request the last recovery record: what was restored, how long it took, which data was unavailable and how the business result was checked. Keep the failed steps in the record. They identify where investment or a changed expectation is needed.
Evidence to request: a dated recovery exercise with its scope, observed result and unresolved defects.
2. Cloud and platform sovereignty
Choose one important SaaS or cloud dependency and inspect its exit path. Ask for a small, representative export and show that another environment can read it. Include identifiers, relationships, attachments, permissions and the history the business needs to retain.
Then examine the practical constraints: contractual notice, extraction cost, implementation effort, support access and the internal people needed to move. A negotiated right to leave becomes useful when someone can explain and demonstrate the route.
Evidence to request: a tested export and import, together with the remaining commercial and operational constraints.
3. Data sovereignty
Trace one sensitive dataset through collection, processing, backups, support access and deletion. Record the locations and organisations involved, the identities that can access it and the contractual basis for each handoff. Include logs and copied data used for testing.
Have the responsible data and legal specialists assess the applicable obligations for the actual service. A location label cannot describe every access path or processing arrangement. The board should be able to see what has been assessed and what remains unresolved.
Evidence to request: a current data-flow map linked to access reviews, processor terms and retention decisions.
4. AI sovereignty
Choose one AI-assisted workflow and trace its inputs, model dependency and possible actions. Identify which data may be sent outside the organisation, which outputs require review and who can stop the workflow. Include the route for handling an output that has already reached a customer or downstream system.
Ask the team to demonstrate a bounded fallback: human review, a reduced service or a previously tested alternative. A substitute model may behave differently; switching requires checks against the same business task.
Evidence to request: an owner, action limits, monitoring criteria and a tested pause or fallback procedure.
5. Application and software sovereignty
Ask someone other than the original developer to build, deploy and operate a representative part of the service from the maintained instructions. Check access to source, dependencies, licences, release artefacts, credentials and operational knowledge through the approved processes.
This exercise makes maintainability visible. It can reveal that a build depends on an undocumented account, or that a recovery step exists only in one person's memory. Record the dependency without blaming the person who has been carrying it.
Evidence to request: a repeatable build and recovery record completed by a second operator.
6. Governance and procurement
Name the person who can accept the interruption, the person who can authorise a fallback and the person who can execute it. Identify deputies and the limits of delegated authority. Check how these responsibilities survive leave, staff turnover and contract renewal.
For the next procurement decision, include the cost of exit and ongoing operation alongside the purchase price. Record any accepted dependency, who accepted it, why it was proportionate and what would trigger a new review.
Evidence to request: a decision record with an owner, budget, limits and review triggers.
Turn the review into one working record
Copy this structure for each critical service:
- Service and business result to preserve.
- Interruption tolerance and the person authorised to accept it.
- Evidence for each of the six layers, with the date and scope of the last test.
- Known limits, shared dependencies and unanswered questions.
- Next correction, its owner and a review date agreed with that owner.
Avoid averaging a missing recovery path into a reassuring overall result. A single untested dependency may dominate the service's ability to continue. Repeat the bounded exercise after a material change to the supplier, architecture, data flow or responsible team.
This extends Digital sovereignty is not nationalism, Sovereignty is measured in response time and Preparedness is the highest form of sovereignty. The practical question running through them is how much room the organisation retains to act.
Start with the Observatory to locate the least understood layer. Bring one service and its evidence into a Conversation when the next decision needs closer examination.