Public Authorities and Multinationals: Sovereignty, Procurement and Many Legal Regimes

Two settings change the security architect's role more than any others. In a public authority the architect procures far more than builds, so the boundaries that matter run through tender annexes and contracts, and the architect holds them by what suppliers are required to do and by the evidence that arrives to show they have done it. In a multinational the architect does build, but across several legal regimes, so the task is to keep one architecture and let each jurisdiction tighten it without ever loosening it. This chapter concerns Shift 1, from documents to code, because requirements, contract clauses, market overlays and regime mappings become versioned, testable artefacts, and Shift 2, from gatekeeper to boundary designer, because neither architect can approve every system that a supplier or a national entity runs. Each designs the boundary and the evidence that it holds, and delegates the routine cases.

The chapter builds on conclusions of the earlier volumes. Model origin is a risk question separate from hosting, and the position it produces is reviewed rather than set once; in public authorities legality comes before capability (AI Governance, Chapters 6 and 17) (168, Nordqvist, 2026). Adaptations of a reference architecture are overlays on a pinned baseline that may only tighten it, and digital sovereignty is a set of verifiable properties rather than a location (AI Platform and Security, Chapters 4 and 13) (169, Nordqvist, 2026). Vendor AI in products and managed services may already act at an autonomy nobody decided, so its use is established and contracted before it is relied on (AI Red Team, Chapters 8 and 28) (170, Nordqvist, 2026). The chapter answers an open question those volumes left: how a single security architect in an authority that mostly procures can hold boundaries in systems that suppliers build and operate.

Two settings side by side: a procuring authority that holds boundaries through requirements, contracts and evidence, and a multinational that keeps a pinned baseline with market overlays, both under verifiable sovereignty properties

Figure 20.1: The procuring authority holds its boundaries through requirements, contracts, evidence and a rehearsed exit; the multinational keeps one baseline whose overlays can only tighten it.

The architect who procures

Most systems in a public authority are built and operated by someone else. The architect cannot change a line of the code inside a supplier's product, cannot read its internal logs and, in a single-post team, cannot review every contract that touches it. The accountability of the role (Chapter 4) is unchanged, so the boundary has to be placed where the architect can reach it: at the interface between the authority and the supplier.

Three moves follow. The first is to decide what the authority holds on its own side of the interface whatever the supplier does: the identity provider against which the supplier's service authenticates, the keys, a copy of the logs, the egress rules, the evaluation gate before a new model version reaches production, and the stop path. Nordvik's benefits-triage system already shows the pattern. The ranking model is retrained quarterly by the supplier inside Nordvik's own platform, so the registry, the evaluation gates and the evidence stay with the Region. The second move is to turn everything that must come from the supplier into requirements that can be verified. The third is to make the evidence arrive on a schedule without anyone asking, so that the architect's attention goes to exceptions. AI Red Team, Chapter 8, observed that the procurement document is the moment of greatest leverage: requirements absent from a tender are hard to add to a framework agreement afterwards (170, Nordqvist, 2026).

European law supports this way of working. Directive 2014/24/EU requires technical specifications to be expressed, where possible, as performance or functional requirements and not as named products (Article 42), lets the authority set conditions for the performance of the contract (Article 70) and limits modification of a contract once awarded (Article 72) (18, European Union, 2014). The architectural reading is that a requirement written as a verifiable result is both lawful in a tender and enforceable afterwards. NIS 2 makes supply chain security part of the minimum risk-management measures and asks entities to take account of the vulnerabilities specific to each direct supplier and the quality of its secure development practices (Article 21(2)(d) and (3)) (6, European Union, 2022). ISO/IEC 27036-1 describes the supplier relationship as a lifecycle that ends in termination (26, ISO/IEC, 2021), and ISO/IEC 27002:2022 gives controls for supplier agreements, the ICT supply chain and cloud services (24, ISO/IEC, 2022). National guidance for public administration is developing alongside, for example the Swedish guidance on introducing an AI policy, which sets the internal rules that a tender must then reflect (156, Digg & IMY, 2025).

A single post is a single point of failure, so the architect writes the requirements once and lets others use them. The standard annex lives in the catalogue of Chapter 9. A procurement officer attaches it to every relevant tender without the architect in the room, and only a deviation or a new class of system comes back, through the forums of Chapter 17. That is Shift 2, from gatekeeper to boundary designer, in a small organisation: judgement goes into the annex and the exceptions, not into every purchase.

Requirements as code

A testable security requirement has six parts: an identifier, a statement of the result required, a level (mandatory or weighted), a verification, a consequence if the verification fails, and a link to the control in the catalogue that it serves. The verification names the method (a demonstration, a test, an artefact or an audit), the moment, the evidence and the frequency. Three moments matter. At evaluation, the tenderer shows that it can meet the requirement. At acceptance, the delivered system is shown to meet it before go-live. In operation, the requirement is checked continuously or on a schedule. A requirement tested once at tender and never again protects the authority only on the day of signature.

A requirement that only an attestation can verify is, in the vocabulary of AI Threat, Chapter 30, a declared control rather than a verified one (171, Nordqvist, 2026). Declared is acceptable for a low-risk component. For anything that supports a high-risk system, the tender states when the declaration must become verified, and by which evidence. The same discipline applies to model updates: the annex specifies model changes as a contracted process with notice, an evaluation window and a rollback right, which Article 70 of the Directive permits as a condition for the performance of the contract (18, European Union, 2014).

Practical guide: Writing testable security requirements for a tender

Purpose. Produce a requirements annex that evaluators can score, that holds after award and that the authority can verify without the supplier's goodwill.

Roles. The security architect writes and owns the annex; the procurement officer attaches it; legal counsel confirms that each mandatory requirement is proportionate; the system owner confirms that the acceptance tests are practical; the evaluators score the responses.

Steps.

  1. Start from the control in the catalogue, not from the supplier's product. Name the obligation or threat that the requirement serves, for example AI Act Article 14(4)(e) for a stop path or Article 12 for logging (1, European Union, 2024).
  2. State the result in functional terms and with a number where one exists: "within 15 minutes", "for at least 12 months", "without staff of the supplier taking part". Never name a product or a method that only one supplier offers (Directive 2014/24/EU, Article 42).
  3. Name the verification: method, moment (evaluation, acceptance, operation), evidence and frequency. Default: every mandatory requirement is verified at acceptance and again in operation, at least annually.
  4. Check that someone other than the supplier can produce or confirm the evidence. If only the supplier holds it, require the evidence as a delivery obligation with an audit right.
  5. Set the level. Keep mandatory requirements to what law or risk appetite makes non-negotiable; default: no more than twelve per tender, with the rest weighted under the award criteria of Article 67.
  6. State the consequence of failure: release blocked at acceptance, a remedy in operation, termination for repeated failure.
  7. Test the test. Run the verification against the current supplier's current system before publication. A requirement that the incumbent cannot be tested against is not yet testable.
  8. Publish the annex with a version number. Mark any part that would reveal the authority's defences as confidential under Article 21 of the Directive and release it only to tenderers who have accepted the confidentiality terms.

Definition of done. Every requirement has an identifier, a verification with a named owner, a consequence and a catalogue link; the annex is versioned in the repository; and the dry run in step 7 has passed.

Worked example: Nordvik Region's security requirements annex as code

Illustrative example. The contract for the benefits-triage system, awarded under tender NR-2026-117 to TriageSoft, comes up for renewal. Nordvik's security architect rewrites the security annex as code, so that the renewal carries requirements that are tested in operation and not only read at signature. The excerpt shows four of the requirements. Identifiers of the form CTRL-SUP-nnn are control catalogue entries for supplier controls, and AIDR-0504 records the decision to hold the boundary through these requirements.

# procurement/annexes/SECREQ-NR-2026-117.yaml (Nordvik Region, illustrative)
annex: SECREQ-NR-2026-117
version: 3.1.0
procurement: NR-2026-117 renewal, benefits-triage system (supplier TriageSoft)
owner: security-architect
decision_record: AIDR-0504
review_when: [supplier change of control, new model release, change in AI Act guidance]
requirements:
  - id: SR-01
    level: mandatory
    ctrl: CTRL-SUP-011
    statement: >-
      Stop holders named by the Region can suspend the ranking function without
      staff or software of the supplier taking part.
    verify: {method: drill, at: [acceptance, operation], evidence: signed drill record, every_months: 12}
    on_failure: release blocked; remedy under clause 14.2
  - id: SR-02
    level: mandatory
    ctrl: CTRL-SUP-012
    statement: >-
      Every ranking, with its inputs and model version, is written to the Region's
      log store within 15 minutes and kept for at least 12 months.
    verify: {method: automated completeness check, at: [operation], evidence: daily report, every_hours: 24}
    on_failure: service credit; escalation to the system owner after 2 failed days
  - id: SR-03
    level: mandatory
    ctrl: CTRL-SUP-013
    statement: >-
      A new model version reaches production only after 20 working days notice and
      a pass in the evaluation gate that runs in the Region's platform.
    verify: {method: gate result, at: [operation], evidence: gate record per release}
    on_failure: version rolled back within 2 working days
  - id: SR-04
    level: weighted
    weight: 10
    ctrl: CTRL-SUP-014
    statement: >-
      Every AI component, with model version and the actions it takes without a
      person approving, is declared in a machine-readable bill of materials.
    verify: {method: artefact, at: [evaluation, operation], evidence: ML-BOM diff per release}
    on_failure: undeclared feature treated as a finding; disabled until declared

SR-01 and SR-03 follow from the design of the system: the stop path must sit outside the supplier, and the evaluation gate is the Region's own. SR-02 sets a retention of twelve months, which is longer than the six-month floor in Article 26(6) of the AI Act for deployers' logs (1, European Union, 2024), because appeals can arrive later than that. SR-04 is weighted and not mandatory, because declaring components is cheaper for a supplier that already produces a bill of materials, and CycloneDX, standardised as ECMA-424, has a profile for machine-learning components (54, Ecma, 2025).

Contracts as controls

A contract clause is a control only when it has an owner, produces evidence and is tested. Otherwise it is a hope that the authority holds against the supplier's goodwill. The practical consequence is that each clause family corresponds to an entry in the control catalogue with the evidence source marked as the supplier, and the catalogue records whether the clause is declared or verified. The table shows the families that matter most for AI in procured products and the instruments they serve.

Clause family What it makes true Evidence that arrives Anchor
Declaration of AI and effective autonomy The authority knows where AI acts and what it does unaided Component declaration, release-note diff AI Act Articles 13 and 25(4)
Stop path Named people can halt the function without the supplier Drill record AI Act Article 14(4)(e)
Logs and access The authority holds the record it needs to oversee and to answer for Completeness report AI Act Articles 12 and 26(6)
Change notice and evaluation Model changes happen under the contract Gate record Directive 2014/24/EU Article 70
Audit and testing rights The authority may test and red-team the system within rules of engagement Audit and test reports NIS 2 Article 21(2)(d); DORA Article 30
Incident notification The supplier reports faster than the authority's own deadlines Notification log AI Act Articles 26(5) and 73; NIS 2 Article 23
Subcontracting The authority knows who else touches its data Sub-processor list GDPR Article 28(2); Directive Article 71
Exit and switching The authority can leave and keep running Exit test record Data Act Chapter VI; DORA Article 28(8)

The Commission's model contractual AI clauses offer a vocabulary for part of this table. They were published for pilot use in procurements of AI, in a version for high-risk systems and a lighter version for systems that are not high-risk (155, European Commission, 2023). They are a schedule of AI-specific terms and not a complete contract, and their value to the architect is that the clause names the obligation and the annex names the test. Two details deserve the architect's attention. The first is Article 25(4) of the AI Act, under which a provider of a high-risk system and the third parties that supply it with components must specify by written agreement the information and assistance the provider needs (1, European Union, 2024). The architect should ask to see the supplier's side of that chain, because the authority's assurance is only as good as the agreements beneath the supplier. The second is timing. Under NIS 2 Article 23(4) an entity gives an early warning of a significant incident within 24 hours and an incident notification within 72 hours (6, European Union, 2022). A contract that gives the supplier 72 hours to tell the authority leaves the authority unable to meet its own deadline, so the supplier's notification period is set from the authority's.

For a managed security service provider the instruments differ. Managed security service providers fall within the scope of NIS 2 and are subject to detailed risk-management requirements in Commission Implementing Regulation (EU) 2024/2690 (7, European Commission, 2024), so a deployer can ask such a provider to show how it manages the AI tooling it uses on the deployer's telemetry. Nordvik's framework agreement NR-2025-044 with its provider of out-of-hours monitoring requires processing and log storage inside the EU and the EEA. Additions that concern AI tooling wait for the next amendment of that agreement; the architect records them as declared in the catalogue until then, so that the gap is visible and not forgotten. For financial entities such as Hansa Mutual, DORA fixes much of this in law: a register of information on all arrangements for ICT services (Article 28(3)), an exit strategy for services that support critical or important functions (Article 28(8)) and a list of key contractual provisions (Article 30) (9, European Union, 2022). The ESAs designated critical ICT third-party providers in November 2025, which adds oversight of those providers but, under Article 28(1), does not relieve the financial entity of its own responsibility (11, ESAs, 2025).

Exit plans and reversibility

Reversibility is the criterion that runs through the series: dependence is acceptable when it can be undone. For the procuring architect that means an exit plan that is a rehearsed capability and not a clause. Public procurement law supports it. Article 73 of Directive 2014/24/EU obliges Member States to ensure that contracting authorities can terminate a contract in defined circumstances, among them a substantial modification that should have required a new procedure (18, European Union, 2014). For cloud and other data processing services, Chapter VI of the Data Act gives customers a right to switch provider, requires contract terms on the switching process (Article 25) and withdraws switching charges in stages, to nothing from 12 January 2027 (Article 29) (16, European Union, 2023). The Interoperable Europe Act points public bodies the same way, towards shared and reusable interoperability solutions (17, European Union, 2024). None of this moves a workload; the architect still decides what must leave and how quickly, and proves it.

The exit plan answers four questions: what leaves with the authority (data, configuration, evaluation sets, decision history and, where the licence allows, model weights), in what open formats and how fast, what keeps the function running meanwhile, and who has tried. The dependency map of AI Threat, Chapter 15, supplies defaults that fit a regional authority: a maximum switch time of ten working days for a standard service and two for a critical one, and a second source in another jurisdiction or under the authority's own control for every reducible dependency of a critical service (171, Nordqvist, 2026). For a procured system the realistic exit is often not another supplier's product but the process without the AI, as AI Red Team, Chapter 8, concluded for security AI (170, Nordqvist, 2026). For the benefits-triage system, exit plan EXIT-NR-01 therefore includes a controlled test in which the ranking is switched off for a day, caseworkers work the queue in order of arrival and the extra handling time is measured.

AIDR-0504 records these decisions for Nordvik's four supplier relationships together, so that the contract, the annex, the exit plan and the evidence schedule for each can be traced to one decision.

Vendor AI and Mode 0

The procuring architect meets AI first as Mode 0 Ambient AI: features inside licensed software, security products and managed services that the authority did not choose and may not know about. AI Red Team, Chapter 8, named the level at which a supplier's feature actually acts its effective autonomy, and treated an undeclared effective autonomy as a supply-chain finding in its own right (170, Nordqvist, 2026). Nordvik's email-security gateway is the standing example. Its classifier for reported phishing messages acts on mailboxes automatically, which is at least Level 3 Bounded in effect, although the Region never decided that level.

Three facts must be established before such a feature is relied on: where AI is used in the product or service, which actions it takes without a person approving, and whether those actions can be reversed. The contract then requires four things: a declaration, repeated at every material change; AI features that act automatically to be off until the authority enables them, and configurable to propose rather than act; notice of changes in advance; and every automatic action logged in a form the authority can ingest. The Cyber Resilience Act helps from the product side. Manufacturers of products with digital elements must identify and document components, including through a software bill of materials, and handle vulnerabilities, with the main obligations applying from December 2027 (12, European Union, 2024). Until then the contract carries the requirement. Detection does not depend on the supplier's honesty: the authority compares release notes with the component declaration, watches its own logs for automatic actions it did not enable and reassesses when either changes. The declaration records what the supplier says; the logs record what the product does.

Where a supplier operates an agent that acts in the authority's environment, the position is stricter. AI Threat, Chapter 24, concluded that the stop path must sit outside the system it stops, and Nordvik's supplier contracts apply that conclusion: any agentic feature must have a stop path that the Region's named holders can trigger without the supplier's agent or staff and without prior approval, demonstrated in a drill with the Region present before go-live and annually afterwards (171, Nordqvist, 2026). SR-01 in the worked example above is the form this takes in the TriageSoft annex.

Across the usage modes

The mode decides what procurement has to establish and what the architect holds on the authority's side.

Mode What the contract must establish What the architect holds on the authority's side
Mode 0 Ambient AI Declaration of AI and effective autonomy; off by default; change notice Release-note diff; logs of automatic actions; reassessment on change
Mode 1 Conversational assistants Hosting, model origin, no training on inputs, retention The approved enterprise tool; data-loss controls at the gateway
Mode 2 Embedded workplace assistants Data boundary, inherited permissions, model changes The permission model of the suite; the pilot's data boundary settings
Mode 3 Agentic work tools Provenance of skills, connectors and packages Containment profile and credentials issued by the platform team
Mode 4 Built AI applications AI Act roles, logs, instructions for use, evaluation access The evaluation gate, the log store and the registry
Mode 5 Autonomous production agents Stop path outside the supplier; an identity issued by the authority Named stop holders; drills; the right to revoke credentials

In Mode 0 the risk is that someone else decided the autonomy, and the remedy is to find it and either contract it or switch it off. In Mode 5 the autonomy is intended, the risk is that the authority cannot stop it, and the remedy is that the authority owns the identity and the stop path and has exercised both.

Digital sovereignty as verifiable properties

AI Platform and Security, Chapter 13, defined digital sovereignty as a set of verifiable properties: knowing where workloads run, which law governs them, being able to move them and being able to continue if a provider fails (169, Nordqvist, 2026). Each property becomes a check, and each check belongs in the requirements annex or the overlay.

Property Check Evidence
Where workloads run Region pinning enforced by policy; no support access from outside the stated area Policy export; access log sample
Which law governs Ownership and control of the provider; reach of third-country law; who holds the keys Ownership declaration; counsel's analysis; key custody demonstration
Ability to move Exit test; open formats; switching terms Exit test record
Ability to continue Second source or fallback; failover drill Drill record

The second row needs care. The US CLOUD Act requires providers subject to United States jurisdiction to preserve and disclose data in their possession, custody or control regardless of whether it is located inside or outside the United States (166, US Congress, 2018). Whether that reaches a given arrangement is a question for counsel. The architect's contribution is to make the facts visible: who owns the provider, who operates the environment, where the keys are held and what the provider can read. Sovereignty-branded offerings by non-European hyperscalers illustrate the distinction. Amazon describes its European Sovereign Cloud, generally available since January 2026, as operated by EU residents with no operational control outside the Union (165, Amazon, 2026). That addresses operational access. AI Governance, Chapter 6, recorded that such offerings reduce operational and continuity risk without by themselves removing legal access risk, and the record in the architecture repository should say the same (168, Nordqvist, 2026).

Schemes give the properties shared names. Gaia-X defines labels and machine-readable self-descriptions through which a consumer can check a provider's claims about jurisdiction and data handling (157, Gaia-X, n.d.). ENISA's candidate scheme EUCS was drafted under the European cybersecurity certification framework of Regulation (EU) 2019/881, which provides for assurance levels of basic, substantial and high (Article 52) (159, ENISA, 2020) (14, European Union, 2019). A candidate scheme is not a certificate, so the architect checks its status when writing the requirement and does not assume that a supplier can show it. ANSSI's SecNumCloud requirements (version 3.2, March 2022) and BSI's C5:2020 are national criteria catalogues against which cloud providers are assessed (160, ANSSI, 2022) (161, BSI, 2020). A tender can name a scheme as one way of providing evidence, with equivalent proof accepted, so that the specification does not close the market (Article 42). Governments are moving in the same direction: the Dutch central government announced stricter rules for its use of cloud services in July 2026, and the Swedish government presented a cloud policy in May 2026 intended to strengthen digital sovereignty in public administration (163, Rijksoverheid, 2026) (164, Regeringskansliet, 2026).

Observable, expected, speculation

The sovereignty schemes, the national cloud policies of 2026, the model contractual AI clauses and the Data Act's switching rules are observable: the architect can write requirements against them. The Cloud and AI Development Act is a proposal, COM(2026) 502 of 3 June 2026, which would introduce Union assurance levels for cloud services and bears on public procurement (158, European Commission, 2026). It is expected that, if adopted, those levels become the common vocabulary of sovereignty requirements in public tenders; its final shape is not settled, so the architect treats it as a planning assumption and does not cite it as law. That a single European label displaces the national schemes is speculation: no instrument decided so provides for it.

One architecture, many regimes

A multinational has the opposite problem. It builds, but its entities sit under different laws. Hansa Mutual's German, Dutch, Swedish and Polish entities apply EU instruments directly, with national supervision and national derogations. Its Norwegian entity follows EU law through the EEA only once an act is incorporated. Its UK and Swiss entities sit outside the AI Act and DORA altogether, under their own regimes. One architecture per jurisdiction would give seven architectures to maintain and seven places for a control to drift. The answer in AI Platform and Security, Chapter 4, is a pinned baseline with market overlays, and the rule that keeps it sound is that an overlay may add controls or tighten them but never relax the baseline (169, Nordqvist, 2026).

The security architect applies the rule to the control catalogue and not only to the platform. The catalogue holds each control once, mapped to the instruments it helps meet, which is the "assure once, comply many" principle of Architecture as Code (Chapter 10) (167, Nordqvist, 2025). An overlay records the three kinds of difference that a jurisdiction introduces. The regime states which instruments apply to the entity and whether the AI Act is law or group policy. Placement states where its logs and evidence are kept and where its data may be processed. Timing states when an obligation starts. A mapping states how each local requirement is met by an existing control. A pipeline check compares each overlay with the baseline and fails when any value is weaker: a shorter retention, a smaller set of notification recipients, a later deadline, a control removed.

Hansa's difficulty is the mappings. The UK and Swiss local security officers keep theirs outside the catalogue, and evidence for many controls is still attested. The group architects bring them in as files that the officers own and the group reviews, so that every local requirement is traceable to a control and to evidence and cannot silently diverge from the baseline.

Practical guide: Adding a market overlay without weakening the baseline

Purpose. Bring a jurisdiction's requirements into the group architecture so that the entity can evidence them and the baseline stays intact.

Roles. The local security officer owns the overlay and its mapping; a group security architect reviews; the entity's market liaison confirms the legal position with local counsel; employee representatives are consulted where a tool in scope can monitor staff.

Steps.

  1. Pin the baseline version the overlay is written against, for example catalogue@4.2.0.
  2. Create overlays/markets/<country>.yaml with the entity, the owner and the decision record.
  3. Declare the regime: which instruments apply, which supervisor is responsible, and whether the AI Act is law or group policy in this entity.
  4. Declare placement: where the entity's logs and evidence are kept, where processing is allowed, and which law governs transfers out of the entity.
  5. Import the local mappings. Each local requirement must point to an existing control. If none fits, propose a new control to the baseline and treat the requirement as an exception with an expiry date until the baseline is changed. Do not keep it only in the overlay.
  6. List the changes as tightenings only, and list the controls that no overlay may remove. The relaxes list must stay empty.
  7. Run the check. It fails the pipeline if any overlay value is weaker than the baseline or if a protected control is missing.
  8. Resolve conflicts at the proper tier. When a local rule appears to require less than the baseline, for instance a shorter retention, do not relax silently. Raise it as an expiring exception for the design authority of Chapter 17, or place the data differently.
  9. Set the review triggers: a change in local law, a change of supervisory expectation, a change to the transfer mechanism, or a new baseline version.

Definition of done. The overlay validates against the schema, passes the tightening check, maps every local requirement to a control with evidence, and has an owner, a decision record and review triggers.

Worked example: Hansa Mutual's overlays for the UK and Swiss entities

Illustrative example. Hansa adds the overlays for its UK and Swiss entities at the level of the control catalogue, beside the platform overlays of AI Platform and Security, Chapter 4. The local mappings that the security officers kept in their own documents are brought in as mappings. AIDR-0569 records the decision to treat the mappings as catalogue content.

# overlays/markets/uk-ch.yaml (Hansa Mutual, illustrative)
baseline: catalogue@4.2.0
decision_record: AIDR-0569
overlays:
  - id: OVL-UK
    entity: hansa-mutual-uk
    owner: uk-local-security-officer
    reviewer: domain-architect-platform
    regime: {ai_act: group-policy, dora: not-applicable, data_protection: [uk-gdpr, dpa-2018], supervisors: [PRA, FCA]}
    placement: {evidence: UK, processing_allowed_in: [UK, DE], transfers_out_governed_by: uk-law}
    mappings:
      - {ctrl: CTRL-SUP-003, satisfies: PRA-SS2/21, evidence: catalogue-generated}
      - {ctrl: CTRL-AGT-002, satisfies: UK-op-resilience, evidence: attested, expires: 2027-03-31}
    tightens:
      - {ctrl: CTRL-IR-007, add_recipients: [uk-entity-board]}
    relaxes: []
  - id: OVL-CH
    entity: hansa-mutual-ch
    owner: ch-local-security-officer
    reviewer: domain-architect-platform
    regime: {ai_act: group-policy, dora: not-applicable, data_protection: [fadp], supervisors: [FINMA]}
    placement: {evidence: CH, processing_allowed_in: [CH, DE], transfers_out_governed_by: ch-law}
    mappings:
      - {ctrl: CTRL-SUP-003, satisfies: FINMA-GUIDANCE-08/2024, evidence: catalogue-generated}
      - {ctrl: CTRL-DAT-004, satisfies: FADP-Art-16, evidence: catalogue-generated}
    tightens:
      - {ctrl: CTRL-IR-007, add_recipients: [ch-entity-board]}
    relaxes: []
protected_controls: [CTRL-AGT-002, CTRL-SUP-003, CTRL-IR-007, CTRL-DAT-004]
review_when: [uk-law-change, ch-law-change, adequacy-change, new-baseline-version]

The UK mapping of CTRL-AGT-002 is attested and carries an expiry date, which shows the architects what still depends on a person's statement. The references name the Prudential Regulation Authority's supervisory statement on outsourcing and third party risk management (215, Prudential Regulation Authority, 2021), the UK Data Protection Act 2018 (217, UK Parliament, 2018), FINMA's guidance on governance and risk management when using artificial intelligence (218, FINMA, 2024) and the revised Swiss Federal Act on Data Protection (216, Swiss Confederation, 2020). The mapping does not interpret those instruments; local officers and counsel do. The overlay makes their interpretation reviewable and keeps it from relaxing a group control.

Architecture information across borders

Architecture information is itself an asset with a border problem. Threat models, trust-boundary diagrams, the Structurizr workspace, control evidence, exception records and penetration test reports describe how the organisation is defended. They are valuable to an attacker, they often contain personal data such as names and roles, and they travel to a group function in another country, to a supplier during a tender and to a supervisor.

Three questions classify a piece of architecture information: whether it contains personal data, whether it is security-sensitive because it would help an adversary, and whether law or contract restricts it, for example as a supplier's trade secret or as national classified information. The answers decide how it may move.

Where it contains personal data, Chapter V of the GDPR governs transfers to third countries (Articles 44 to 49) (5, European Union, 2016). The judgment in Schrems II held that an organisation relying on standard contractual clauses must assess whether the law of the destination undermines the protection they promise (214, CJEU, 2020). For Hansa, transfers from the EU entities to the UK and Switzerland rely on adequacy decisions under Article 45, which the Commission can review, amend or withdraw, so the architects treat each decision as a dependency with an owner and a review date. Transfers from the UK and Swiss entities are governed by their own law. In practice the group workspace stays the single model, and the views sent to an entity are generated from it with fields that the entity may not see removed. Evidence is kept in the entity's region, as the overlay states. The generated views of Chapter 19 are the mechanism, and the classification of each element is an attribute of the model.

For the public authority the border runs through the tender. Directive 2014/24/EU allows the authority to require tenderers to protect the confidentiality of information made available during the procedure (Article 21) (18, European Union, 2014). Nordvik's public-access rules make some security documentation requestable unless it is classified, so the detailed architecture annex is classified and released only to tenderers who have accepted the confidentiality terms, while the requirements themselves, written as results, can be public. The same care applies to the architect's own tools. Architecture information describes the Region's defences, so the Mode 3 agentic work tool of the architect's team runs only on open-weight models on the Region's reserved capacity, as the profile of the post requires.

Nordvik Region and Hansa Mutual

Nordvik's single architect holds boundaries mostly through procurement. The relationships that matter are the benefits-triage system under tender NR-2026-117, the staff assistant under contract NR-2026-031 with a European cloud provider, the hosting provider that reserves accelerators in a Nordic data centre and the managed security service provider under framework agreement NR-2025-044. Each carries testable requirements, evidence obligations and an exit plan, recorded as AIDR-0504. The renewal annex for the benefits-triage system is the first to be written fully as code; the other three follow as their terms come up, and the MSSP agreement waits for its next amendment. The architect cannot attend every purchase, so the standard annex is the instrument of delegation. The weakness is the single post: the annex, the catalogue and the exit tests depend on one person, a question of competence and succession that Chapters 21 and 22 take up.

Hansa's architects keep one baseline and overlays for seven jurisdictions. Their work is to bring the UK and Swiss mappings, until now held by local officers, into the group catalogue, to make the tightening check part of the pipeline, and to generate the views of architecture information that reach those entities. Hansa has the engineering capacity to build the checks, and DORA makes the supplier register and exit strategies mandatory for its EU entities. Nordvik's leverage lies in the contract and in what it holds on its side of the interface; Hansa's lies in the platform and in the catalogue that every entity reads.

Summary

The public authority that procures and the multinational that spans regimes both rest on the same move: the architect expresses the boundary as an artefact that can be tested, and then arranges for the evidence to arrive. For the authority this means requirements written as verifiable results, contract clauses entered in the catalogue as controls with evidence and tests, and exit plans that have been rehearsed. For the multinational it means one baseline, market overlays that can only tighten it and local mappings that live in the catalogue. This is Shift 1, from documents to code, applied to tender annexes, contracts and regime mappings.

It is also Shift 2, from gatekeeper to boundary designer. A single architect in an authority cannot approve what suppliers build and run, and a team of six cannot approve what seven jurisdictions change. Each designs what the organisation holds on its side of the interface, writes the standard annex or overlay once, and routes only the exceptions to a forum. Vendor AI in Mode 0 is found and contracted before it is relied on, and for supplier-operated agents in Mode 5 the organisation owns the identity and the stop path and has exercised both. Digital sovereignty is checked as four properties (where workloads run, which law governs them, whether they can move and whether they can continue) and not asserted as a location.

The legal setting is observable: the Directive's rules, the model contractual AI clauses, the Data Act's switching rules, the national cloud policies and the sovereignty schemes exist and can be written into requirements. The Cloud and AI Development Act is a proposal, which the architect treats as expected and does not rely on. Statements about legal instruments in this chapter are architectural implications and not legal advice.

The role has to be carried by people who can write such artefacts and judge such evidence. Chapter 21 turns to that question and sets out a competence framework for the transformed security architect, kept as code and evidenced by practice.

Sources

  1. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 (Artificial Intelligence Act). (1, European Union, 2024)
  2. European Parliament and Council of the European Union. Regulation (EU) 2016/679 (General Data Protection Regulation). (5, European Union, 2016)
  3. European Parliament and Council of the European Union. Directive (EU) 2022/2555 (NIS 2 Directive). (6, European Union, 2022)
  4. European Commission. Commission Implementing Regulation (EU) 2024/2690. (7, European Commission, 2024)
  5. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 (DORA). (9, European Union, 2022)
  6. European Supervisory Authorities: EBA, EIOPA and ESMA. European Supervisory Authorities designate critical ICT third-party providers. (11, ESAs, 2025)
  7. European Parliament and Council of the European Union. Regulation (EU) 2024/2847 (Cyber Resilience Act). (12, European Union, 2024)
  8. European Parliament and Council of the European Union. Regulation (EU) 2019/881 (Cybersecurity Act). (14, European Union, 2019)
  9. European Parliament and Council of the European Union. Regulation (EU) 2023/2854 (Data Act). (16, European Union, 2023)
  10. European Parliament and Council of the European Union. Regulation (EU) 2024/903 (Interoperable Europe Act). (17, European Union, 2024)
  11. European Parliament and Council of the European Union. Directive 2014/24/EU on public procurement. (18, European Union, 2014)
  12. International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 27002:2022 Information security controls. (24, ISO/IEC, 2022)
  13. International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 27036-1:2021 Supplier relationships, Part 1. (26, ISO/IEC, 2021)
  14. Ecma International. ECMA-424: CycloneDX Bill of Materials Specification, 2nd edition. (54, Ecma, 2025)
  15. European Commission. EU model contractual AI clauses to pilot in procurements of AI. (155, European Commission, 2023)
  16. Agency for Digital Government and Swedish Authority for Privacy Protection. Inför en AI-policy. (156, Digg & IMY, 2025)
  17. Gaia-X European Association for Data and Cloud AISBL. Gaia-X: A Federated Secure Data Infrastructure. (157, Gaia-X, n.d.)
  18. European Commission. Proposal for a Cloud and AI Development Act (CADA). (158, European Commission, 2026)
  19. European Union Agency for Cybersecurity. EUCS: Cloud Services Scheme. (159, ENISA, 2020)
  20. ANSSI. Prestataires de services d'informatique en nuage (SecNumCloud): référentiel d'exigences. (160, ANSSI, 2022)
  21. BSI. Cloud Computing Compliance Criteria Catalogue: C5:2020. (161, BSI, 2020)
  22. Rijksoverheid. Strengere regels voor het gebruik van clouddiensten door de Rijksoverheid. (163, Rijksoverheid, 2026)
  23. Regeringskansliet. Ny molnpolicy ska bidra till ökad digital suveränitet i offentlig förvaltning. (164, Regeringskansliet, 2026)
  24. Amazon. AWS Launches AWS European Sovereign Cloud and Announces Expansion Across Europe. (165, Amazon, 2026)
  25. United States Congress. 18 U.S.C. § 2713 (CLOUD Act). (166, US Congress, 2018)
  26. Nordqvist, G. Architecture as Code. (167, Nordqvist, 2025)
  27. Nordqvist, G. AI Governance. (168, Nordqvist, 2026)
  28. Nordqvist, G. AI Platform and Security. (169, Nordqvist, 2026)
  29. Nordqvist, G. AI Red Team. (170, Nordqvist, 2026)
  30. Nordqvist, G. AI Threat. (171, Nordqvist, 2026)
  31. Court of Justice of the European Union. Judgment of 16 July 2020, Schrems II, Case C-311/18. (214, CJEU, 2020)
  32. Prudential Regulation Authority. Supervisory Statement SS2/21: Outsourcing and third party risk management. (215, Prudential Regulation Authority, 2021)
  33. Swiss Confederation. Federal Act on Data Protection (FADP). (216, Swiss Confederation, 2020)
  34. UK Parliament. Data Protection Act 2018. (217, UK Parliament, 2018)
  35. FINMA. FINMA Guidance 08/2024 on artificial intelligence. (218, FINMA, 2024)