Digital sovereignty starts in your management system

It is easy to read the news about the EU plan to reduce dependence on US tech giants as geopolitics. Data centres. Cloud. AI. Chips. Open source.

For companies, the question starts in daily work. Which systems do you depend on? Which data passes through them? Who owns the risk? Can you show why you accept a dependency, or what you are doing to reduce it?

Sovereignty means the ability to decide for yourself. For a state, it is about political independence. For a company, the meaning is more practical: being able to understand, govern, and reassess the dependencies the business relies on.

Digital sovereignty is therefore control over data, systems, suppliers, and AI decisions. Enough control to know what you accept, what you can change, and what you will do when conditions move.

What does digital sovereignty mean for a company?

SVT describes the European Commission package as a way to reduce Europe’s dependence on US tech giants. The package includes data centre capacity, cloud and AI, open source, and Chips Act 2.0.¹

The Commission’s own definition is useful here. Tech sovereignty is described as Europe’s ability to act independently in the digital world by developing and controlling key technologies, data, and infrastructure, while reducing dependence on non-EU providers.²

At company level, this becomes a question of control level. A payroll system, an identity platform, an operations partner, and an AI tool do not need the same answer. They need a conscious assessment of how critical the dependency is, who is responsible for it, and which alternatives exist.

The Cloud and AI Development Act describes sovereignty in levels: where data is processed, independence from third countries, transparency in the software supply chain, ownership and control over the provider, and at the highest level full transparency and control over the software supply chain without third-country influence.³

The EU Open Source Strategy points in the same direction: more control, less lock-in, stronger security, and reusable building blocks.⁴

The management question becomes simple: what control do we need for this dependency?

The problem is invisible dependencies

When dependencies hurt, it is often because no one can describe them before they have to be defended.

Which systems are critical? Which data is there? Who can change the terms? How quickly can you switch? What happens if the service is down? Which customers, processes, or legal requirements are affected? Who in management has accepted the risk?

In cloud and SaaS dependencies, the same practical questions keep returning:

• where data is stored and moved,
• what requirements and responsibilities the contract sets,
• how the supplier is monitored,
• what exit from the service requires,
• what happens during disruption or outage.

AI dependencies add more questions. What may the tool be used for? Which data is used? Which logs exist if something goes wrong? How is responsibility divided between you, the supplier, and other third parties? How do you assess the impact on people and the business when use changes?

This is management’s control over the business, with technology as one of several dependency surfaces.

ISO 27001 makes the dependency visible

ISO/IEC 27001:2022 starts in the organization’s context.

Clause 4 requires the organization to determine external and internal issues, relevant interested parties, and their requirements. The standard also requires you to consider interfaces and dependencies between activities performed by the organization and those performed by other organizations.⁵

This is where digital sovereignty becomes practical. Cloud, identity, operations partners, and critical suppliers need to be visible in the management system if you want to govern them.

Clause 6.1.2 requires an information security risk assessment process that identifies risks to confidentiality, integrity, and availability, identifies risk owners, assesses consequence and likelihood, and prioritizes what needs treatment.⁵

Clause 6.1.3 requires you to select necessary controls, compare them with Annex A, and produce a Statement of Applicability. It must show which controls are needed, why they are included, whether they are implemented, and why any Annex A controls have been excluded.⁵

That makes the SoA more than an audit list. It becomes your decision record for dependencies.

Several Annex A controls sit close to the sovereignty question: supplier relationships, information security requirements in supplier agreements, the ICT supply chain, monitoring of supplier services, acquisition and exit for cloud services, information security during disruption, and ICT readiness for business continuity.⁶

ISO 27001 does not choose suppliers for you and does not automatically make you digitally sovereign. It does give you a clear way of working: make the dependency visible, choose controls, and document why you accept or reduce the risk.

ISO 42001 makes AI dependency governable

ISO/IEC 42001:2023 takes the same management logic to AI systems and AI use.

The standard requires risks and opportunities to be determined based on domain, context of use, intended use, and the organization’s external and internal context. It also requires AI risk assessment, AI risk treatment, and an AI system impact assessment that considers deployment, intended use, and reasonably foreseeable misuse.⁷

Clause 8 makes this ongoing. Risk assessments, risk treatments, and impact assessments must be performed at planned intervals or when significant changes are proposed or occur.⁷

That matters for companies that “only use” AI. ISO 42001 is not reserved for organizations that train their own models. The standard also says externally provided processes, products, or services relevant to the AI management system must be controlled.⁷

Annex A makes the AI dependency concrete. It covers AI policy, roles and responsibilities, impact assessment, operations, monitoring, logs, data acquisition, data quality, data provenance, intended use, and division of responsibility with suppliers and customers.⁸

That is why ISO 42001 fits questions about Copilot, ChatGPT, specialized AI tools, and AI features built into other platforms. Even when you do not build the model yourself, you need to govern the use, data, roles, logs, and supplier relationship.

ISO 42001 does not solve the AI Act, geopolitics, or supplier risk automatically. It does make AI easier to treat as part of the management system, not as a side track.

A simple sovereignty check for management

Start with your own dependencies.

List the systems and AI tools that are critical to the business. Do not only include the big platforms. Add identity, integrations, support paths, databases, decision support, and AI tools used in daily work.

Set an owner for each dependency. Someone must be able to answer for use, risk level, supplier relationship, and next steps if conditions change.

Write down what you accept and why. For information security, that belongs in risk treatment and the SoA. For AI, it belongs in AI policy, risk treatment, and impact assessment.⁵⁷

Check that you have an exit path or a disruption plan. Exit, alternative operations, fallback routines, and follow-up are not details when the dependency is critical.⁶

Repeat the assessment when the supplier, model, data, use, or external environment changes. Both ISO 27001 and ISO 42001 rely on risks and treatments being followed up when conditions move.⁵⁷

Digital sovereignty is ongoing follow-up. The decision needs to hold when the supplier, technology, or external environment changes.

Where AmpliFlow fits

This is hard when decisions live in scattered documents, spreadsheets, and email threads.

In AmpliFlow for ISO 27001, risks, SoA, control status, actions, and audit evidence can stay connected in the same platform. The ISO 42001 support builds on the same idea for AI: approved tools, risks, impact assessments, actions, and documentation are kept together in one AI management system.

A system does not make you sovereign by itself. The value is that risks, suppliers, controls, responsibilities, and follow-up are connected.

For most companies, digital sovereignty starts there: in the management system.

Footnotes

1. SVT Nyheter, “EU:s plan: Frigöra sig från USA:s techdominans”, published 2026-06-03 and updated 2026-06-04. The article describes the European Commission package as a response to dependence on US tech giants and mentions data centre capacity, cloud and AI, open source, and Chips Act 2.0. Original URL. ↩

2. European Commission, “Strengthening Europe’s Tech Sovereignty”. The page defines tech sovereignty as Europe’s ability to act independently in the digital world by developing and controlling key technologies, data, and infrastructure, while reducing dependence on non-EU providers. It also lists the main parts of the package. Original URL. ↩

3. European Commission, “Cloud and AI Development Act”. The page describes CADA as part of the AI Continent Action Plan, with focus on capacity, autonomy, an EU-wide sovereignty framework, and four levels of cloud and AI sovereignty. Original URL. ↩

4. European Commission, “EU Open Source Strategy”. The page describes open source as a tool for tech sovereignty through more control, less lock-in, stronger security, reusable building blocks, and European alternatives. Original URL. ↩

5. ISO/IEC 27001:2022, clauses 4.1, 4.2, 4.3 c), 6.1.2, and 6.1.3. These parts cover context, interested parties, dependencies on other organizations, risk assessment, risk treatment, and Statement of Applicability. ↩ ↩² ↩³ ↩⁴ ↩⁵

6. ISO/IEC 27001:2022, Annex A controls 5.19, 5.20, 5.21, 5.22, 5.23, 5.29, 5.30, and 5.31. These controls cover supplier relationships, supplier agreements, ICT supply chain, monitoring of supplier services, cloud services, disruptions, continuity, and relevant requirements. ↩ ↩²

7. ISO/IEC 42001:2023, clauses 6.1.1, 6.1.2, 6.1.3, 6.1.4, 8.1, 8.2, 8.3, and 8.4. These parts cover AI risk, AI risk treatment, impact assessment, control of external services, and repeated follow-up when conditions change. ↩ ↩² ↩³ ↩⁴ ↩⁵

8. ISO/IEC 42001:2023, Annex A controls A.2.2, A.3.2, A.5.2-A.5.5, A.6.2.6, A.6.2.8, A.7.3-A.7.5, A.8.5, A.9.2, A.9.4, A.10.2, and A.10.3. These controls cover AI policy, roles, impact assessment, operations, logs, data, information to interested parties, intended use, and supplier responsibilities. ↩