The Transformed Security Architect · Whitepaper

Chapter 20 · The Role in the Organisation

Public Authorities and Multinationals

Sovereignty, Procurement and Many Legal Regimes

Author Conceived and directed by Gunnar Nordqvist; text written by AI agents under his direction.
Published 6 November 2026
Build number 2026.11
security-architecture security-architect-role architecture-as-code ai-agents competence
Figure 20.1: A procuring authority and a multinational, both under verifiable sovereignty properties.
Figure 20.1: A procuring authority and a multinational, both under verifiable sovereignty properties.

Two settings change the security architect's role more than any others. In a public authority the architect procures far more than builds, so boundaries run through tender annexes, contracts and the evidence suppliers return. In a multinational the architect builds across several legal regimes, so the task is to keep one architecture that each jurisdiction may tighten but never loosen. 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 a supplier or national entity runs.

The chapter builds on earlier conclusions: in public authorities legality comes before capability (AI Governance, Chapter 17) (162, Nordqvist, 2026); adaptations are overlays on a pinned baseline that may only tighten it, and digital sovereignty is a set of verifiable properties (AI Platform and Security, Chapters 4 and 13) (163, Nordqvist, 2026); and vendor AI may already act at an autonomy nobody decided, so it is established and contracted before it is relied on (AI Red Team, Chapters 8 and 28) (164, Nordqvist, 2026). It answers how a single architect in an authority that mostly procures can hold boundaries in systems suppliers build and run.

Most systems in a public authority are built and operated by someone else, whose code and internal logs the architect cannot touch. Because the accountability of the role (Chapter 4) is unchanged, the boundary must sit where the architect can reach it: at the interface between authority and supplier.

Primary topics explored

  1. The architect who procures
  2. Requirements as code
  3. Contracts as controls
  4. Exit plans and reversibility
  5. Vendor AI and Mode 0
  6. Digital sovereignty as verifiable properties

About The Transformed Security Architect

The Transformed Security Architect is Book 6 of The Transformed Architecture. It describes how the security architect role is transformed when architecture is code, when AI drafts and acts, and when adversaries move at machine speed: the craft, the architect's own AI team, the role in the organisation, the competences and the career, for European enterprises and public authorities.

It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team and AI Threat.

Who should read this

Security architects, CISOs and heads of security architecture, enterprise, solution and AI architects, engineering leads, competence and hiring leads, procurement and programme leaders, and risk, compliance and audit.

Portrait of Gunnar Nordqvist

Gunnar Nordqvist

Conceived, directed and published the books of The Transformed Architecture.

Continue with the full chapter

Read the full chapter online

Chapter 20: Public Authorities and Multinationals: Sovereignty, Procurement and Many Legal Regimes in The Transformed Security Architect gives the detailed explanations, practical examples and implementation patterns behind this summary.

This whitepaper belongs to “The Role in the Organisation” and is one of 31 drawn from the manuscript.