The Transformed Role Defined: Mandate, Accountabilities and Decision Rights

Every later chapter of this book asks the security architect to design a boundary, write a control, govern an agent team, verify what AI proposes or brief a management body. None of that works for a role whose authority exists only in a job description and in the goodwill of colleagues. This chapter defines the transformed role in the form the rest of the book relies on: a role charter, kept as code in roles/security-architect.yaml, that states the mandate, the accountabilities, the decision rights with their time limits, the escalation paths, the artefacts the role owns and, just as carefully, what the role does not do. As the reference for the whole book, the charter concerns all four shifts: it is an instance of Shift 1, from documents to code; the written instrument of Shift 2, from gatekeeper to boundary designer, replacing the right to say yes or no at a gate with rights over boundaries and their delegation; the source of the decision time limits that Shift 3, from periodic to continuous, at machine speed demands; and the fixed point of accountability when, under Shift 4, from sole author to conductor of an AI team, the architect verifies work that agents draft.

The chapter also connects the role to the duties that NIS 2, DORA and the AI Act place on management bodies and deployers, and shows how a charter is tested and changed like any other control. The examples are Nordvik Region's charter for its single security architect, ROLE-NR-SA-01, and Hansa Mutual's charters ROLE-HM-* for its group security architecture team of six.

The role charter as a decision-rights map: what the security architect decides, recommends, vetoes and escalates, placed against the four decision tiers and their time limits

Figure 4.1: The role charter as a decision-rights map, showing what the security architect decides, recommends, vetoes and escalates by decision tier and time limit.

Why a charter, and why as code

A job description describes a person; a charter describes decision rights that pipelines and forums can read. A job description tells a recruiter whom to look for and is rarely read again. A charter tells everyone else what the role may decide, what it must be asked, what it may stop and to whom it answers. It is read whenever a decision is contested, so it must be precise enough to settle the contest.

The European frameworks for cybersecurity roles describe the person rather than the rights. ENISA's European Cybersecurity Skills Framework includes a Cybersecurity Architect profile with a summary, a mission, deliverables, main tasks, key skills and knowledge (41, ENISA, 2022). SFIA 9 describes skills and generic levels of responsibility, with autonomy, influence and complexity rising from level to level (43, SFIA Foundation, 2024). Both serve competence and hiring (Chapters 21 and 22), but neither says who may block a tender annex that lacks a stop path, or who decides when two agents propose conflicting egress changes. Those are local decisions about authority, and a charter records them.

Governance research has framed the same point for IT in general. Weill and Ross defined IT governance as specifying the decision rights and accountability framework that encourages desirable behaviour in the use of IT (173, Weill & Ross, 2004). ISO/IEC 27001 asks top management to ensure that responsibilities and authorities for roles relevant to information security are assigned and communicated (clause 5.3), and ISO/IEC 27002 adds controls for information security roles and responsibilities and for segregation of duties (controls 5.2 and 5.3) (23, ISO/IEC, 2022) (24, ISO/IEC, 2022).

Keeping the charter as code adds three properties. Pipelines can read it, so a gate can check that a change to an egress policy carries the approval of a holder of the relevant right. Version control gives it a history, showing when a right was granted, by whom and in which pull request, which matters when a supervisor or a court asks who was entitled to decide. And the role can be changed the way the book recommends changing everything else: by a proposed change, a review, an approval and a record. Like the Architecture Decision Record of Architecture as Code (Chapter 4), which follows Nygard's form of context, decision, status and consequences, the charter is architectural memory: the record of the decisions that define the role itself (167, Nordqvist, 2025) (63, Nygard, 2011).

The charter also gives this book's first answer to an open question: what remains of the role when boundaries are code, routine decisions sit in pipelines and AI drafts most of the artefacts. The answer is not a list of tasks, because tasks move to pipelines and agents, but a set of rights and accountabilities that cannot move, because they need a person who can answer for them.

Mandate

The mandate states what the role designs and owns. For the transformed security architect it is a short list of products, not activities: the boundaries that hold whatever an actor attempts, the policy decision points that enforce them, the identity model for people, workloads and agents, the control catalogue and the evidence chain that shows each control working, and the stop paths that halt a system from outside it. Chapters 7 to 10 treat each in turn.

Writing the mandate as products means the architect owns the design of a boundary but not the system it surrounds. Fowler argued that one of an architect's most important tasks is to remove architecture by finding ways to eliminate irreversibility in designs (73, Fowler, 2003). A boundary is the security architect's version of that idea: it keeps the consequences of a mistake reversible and contained, whoever made the mistake. The mandate reaches into systems that others, including suppliers, build and operate, but only through the boundary, the requirement and the evidence, never through the delivery team's backlog or the operator's console.

The mandate also names the artefacts the role owns, in the literal sense of code ownership: the architect is a required reviewer for changes to the control catalogue, containment profiles, permission manifests, tender-annex templates and threat models in scope. Code-hosting platforms implement this with a code-owners file that requests review from named owners when a pull request touches their paths, which branch protection can make mandatory (174, GitHub, n.d.). The charter names the paths; the code-owners file enforces them; a test checks that the two agree.

Finally, the mandate must say where the role stops at the seams with its neighbours. AI Governance, Chapter 14, concluded that the AI architect owns the seams between the architecture roles: the security architect keeps the threat model, identity, secrets and zero trust, and relies on the AI architect for AI-specific threats, guardrail policy, agent permissions and the model supply chain (168, Nordqvist, 2026). This book builds on that division and sharpens it for agents. The security architect owns the containment that holds an agent regardless of its guardrails: its identity, its egress and its stop path. The AI architect owns the guardrail policy and the evaluation. The charter records that seam once; Chapter 16 maps the neighbouring roles in full.

Accountabilities

An accountability says what the role answers for, and to whom. The central distinction of this chapter is between accountability for a boundary and authorship of every artefact that makes it up. In the inherited role the two coincided: the architect wrote the reference architecture and signed the approval. Under Shift 1 most artefacts are code written by platform engineers, product teams and suppliers, and under Shift 4 a growing share is drafted by AI. If accountability still followed authorship, it would dissolve among dozens of authors and several agents, and nobody would answer for whether the boundary held.

The charter therefore attaches accountability to the property, not to the keystrokes. The security architect is accountable for the boundary holding: that the default-deny egress of the claims-triage agent actually denies, that the stop path for the benefits-triage system actually stops it within the agreed time, that the evidence for a catalogue control is current and genuine. The architect answers for that property whoever wrote the policy, because the architect approved its design, specified the test that shows it holding and must notice when it does not.

That accountability has three parts that the charter should state separately. The architect is accountable for the design: that the boundary, as specified, is adequate for the risk the system owner has accepted. The architect is accountable for the verification: that a test or evidence stream shows the boundary holding, and that the architect has reviewed it at a depth matched to the risk, which Chapter 14 turns into a protocol. And the architect is accountable for advice: that the people who own the risk, the system owner, the CISO and ultimately the management body, have been told in time and in plain language when a boundary cannot be held within their appetite. The third is most often missing from job descriptions and matters most when something goes wrong.

Each accountability names its recipient: normally the CISO for design and verification, and through the CISO the management body for advice on risk beyond appetite. Accountability without a named recipient is a statement of virtue, not a control.

Decision rights

A decision right states what the role may do with a decision of a given class, and four verbs suffice. The architect decides alone and records the decision; recommends where another holder decides, with the recommendation on record first; may veto a change, subject to a recorded override by a named higher authority; and must escalate what exceeds the role's rights, within a stated time to a stated holder.

The rights sit on the tiers of AI Governance, Chapter 13: tier 1 at pipeline gates for routine decisions, tier 2 at a design authority for exceptions and contested items, tier 3 at the AI governance board for high-risk go-live and residual-risk acceptance, and tier 4 at the management body for risk beyond appetite (168, Nordqvist, 2026). That volume concluded that governance as code changes what forums are for rather than removing them: pipelines enforce, observe and remember, while forums decide what pipelines cannot. The architect's characteristic contribution is at tier 1: writing the gate policies that decide routine changes, so that only exceptions reach a person.

Time limits make the rights work at machine speed. A right to review without a time limit is a right to delay; under Shift 3 the limit is part of the right. AI Threat, Chapter 30, concluded that decision rights to stop, pause, deny or reverse must be assigned before the crisis, to holders who can act within the time the threat allows, which for an agent on a production estate is minutes, and that the right to stop must be cheaper to exercise than the right to continue (171, Nordqvist, 2026). Applied to the architect's own rights, a veto not exercised within its window lapses to the escalation path rather than blocking the change indefinitely.

The table shows typical rights in an organisation with an AI estate; the defaults are a starting point to adapt to the risk appetite.

Decision class Architect's right Tier Time limit
Gate policy for a boundary in the catalogue Decide 1, applied by the gate Policy change reviewed within 2 working days
Security requirements in a tender annex Decide within catalogue; veto omission of stop path or egress limits 1 to 2 Annex reviewed within 5 working days
Exception to a catalogue control, up to 90 days Decide the compensating design; system owner accepts the risk 2 5 working days
Exception beyond 90 days or beyond appetite Recommend 3 or 4 Escalate within 2 working days of finding
Containment profile of a Mode 5 agent Decide the design; veto go-live without a tested stop path 2 Before go-live; review within 5 working days
Conflicting agent proposals on a boundary Decide 1 to 2 2 working days, else design authority
Stop an agent or system in production Recommend to the stop holder Incident authority Immediately; never a precondition for a stop
Stop or lower the level of the architect's own agents Decide, unilaterally None needed Minutes
Residual risk acceptance None; advise the risk owner 3 or 4 Advice on record before the decision

Two rows deserve comment. The architect does not hold the right to stop a production agent. The stop holder is the person on the incident rota who can act at three in the morning, and making the architect a precondition would make stopping more expensive than continuing. The architect recommends and designs the path. Conversely, the architect holds an unconditional right to stop the agents that work under the architect's own mandate.

The vetoes are deliberately narrow. A veto over every change is the gatekeeper's right in another form. A veto over a missing stop path or egress limit protects a property that is expensive to restore once a contract is signed or a system is live, and it is exercised against a short, testable criterion.

Practical guide: Writing a security architect role charter in five steps

Purpose. Produce a first, machine-readable charter that settles the decisions most often contested.

Roles involved. The security architect drafts; the CISO approves; HR reviews against grading and employment terms; the enterprise and AI architects review the seams; employee representatives are consulted where records about people change.

  1. Collect the decisions. List thirty to fifty decisions the role took, influenced or was blamed for over the last twelve months: tender annexes, go-live reviews, exceptions, incidents, agent proposals, disputes with neighbours.
  2. Classify each decision. Record the class, the tier at which it belongs, who decided in fact, how long it took and whether it was contested. Group them into ten to fifteen classes.
  3. Assign a verb and a time limit. Choose decide, recommend, veto or escalate for each class, name the holder where it is not the architect, and set a limit. Default to recommend; grant decide where the catalogue already sets the standard; grant veto only for properties expensive to restore. Use working days for design decisions and minutes for anything touching a running agent.
  4. Write the exclusions and the seams. State what the role does not do, using the next section as a template, and record each seam by naming both sides.
  5. Encode, test and adopt. Write the YAML, generate the code-owners entries from it, test it against ten past decisions with the second practical guide, and merge it with the CISO's approval and HR's review recorded.

Definition of done. Every right has a holder, a tier and a time limit; every mandate path has a code-owners entry; at least eight of ten past decisions resolve to one holder; the charter states its review date and triggers.

Worked example: roles/security-architect.yaml for Nordvik Region

The following charter is illustrative. It is the Region's answer to the regional director's commission AIDR-0500, written by the security architect, approved by the CISO and endorsed by the regional director before the 2027 budget is set. It gives the single post-holder written decision rights for the first time.

# roles/security-architect.yaml  (Nordvik Region, illustrative)
id: ROLE-NR-SA-01
title: Security architect
organisation: Nordvik Region
version: 1.0.0
effective: 2027-01-01
commissioned_by: AIDR-0500
reports_to: chief-information-security-officer
approved_by: chief-information-security-officer
endorsed_by: regional-director
reviewed_by: [hr-lead, enterprise-architect, ai-architect]
competence_record: CMP-NR-01
mandate:
  designs_and_owns:
    - security reference architecture and control catalogue CTRL-NR-*
    - identity model for staff, supplier and service identities
    - stop-path and egress requirements in tender annexes
    - pre-production security checklist for AI systems
    - threat models held as code
  code_owner_paths: [security/catalogue/, procurement/annexes/security/, threat-models/]
accountabilities:
  - for: boundaries in the catalogue hold, shown by test or supplier evidence
    answerable_to: chief-information-security-officer
  - for: advice in writing when a boundary cannot be held within appetite
    answerable_to: chief-information-security-officer
decision_rights:
  decide:
    - {class: stop-path-and-egress-requirements-in-tender-annex, limit_working_days: 5}
    - {class: gate-policy-for-catalogue-boundary, limit_working_days: 2}
    - {class: compensating-design-for-exception-up-to-90-days, limit_working_days: 5}
    - {class: stop-or-restrict-own-ai-tools, limit_minutes: 15}
  veto:
    - {class: tender-annex-without-stop-path, override_by: chief-information-security-officer}
    - {class: ai-go-live-without-tested-stop-path, override_by: chief-information-security-officer}
  recommend:
    - {class: residual-risk-acceptance, decided_by: system-owner}
    - {class: changes-to-MND-NR-01, decided_by: chief-information-security-officer}
    - {class: stop-of-supplier-system, decided_by: incident-authority}
  escalate:
    - {to: chief-information-security-officer, within_working_days: 2}
    - {to: regional-director, when: beyond CISO appetite}
    - {to: regional-executive-committee, when: political tier of escalation matrix}
does_not:
  - accept residual risk on behalf of a system owner
  - operate the SIEM or supplier systems
  - approve every change; routine changes are decided by gates
  - sign for the regional executive committee or the regional director
modes_and_levels:
  own_ai: {modes: [1, 3], mandate: MND-NR-01, max_level: Level 1 Assisted}
  mode_5_in_estate: design authority over containment in tender requirements
review: {cadence_months: 12, triggers: [new-mode-5-system, reorganisation, incident]}

Three features are specific to a single post in a public authority. The veto rights can be overridden only by the CISO, and only on the record, so the architect cannot become the single point of failure in a procurement. Changes to the architect's own mandate manifest, MND-NR-01, are recommended by the architect but decided by the CISO, because nobody else in the Region could review a change the architect approved alone. The charter caps the architect's own AI at Level 1 Assisted, below the Level 2 Supervised for edits that version 1.0.0 of the manifest allowed (Chapter 12); from the charter's effective date the stricter ceiling governs, and the manifest was aligned as version 3.0.0 at its May 2027 review (Chapter 25). And the escalation path ends in the regional executive committee for the political tier of the escalation matrix, because some boundaries, such as whether a supplier may process security information outside the EU, are political choices in a public authority, not technical ones.

What the role does not do

The list of what the role does not do matters as much as the mandate. The inherited role grew by accretion: whatever concerned security and had no other owner landed on the architect, and a role defined by accretion cannot be held to account for anything in particular. Unwritten exclusions surface during incidents, when each party assumes the other accepted the risk.

Four exclusions belong in almost every charter. The architect is not the risk owner. The system owner and, above them, the CISO and the management body accept residual risk; the architect advises, and the advice is on record. DORA Article 6(4) makes the separation explicit for financial entities, asking them to assign responsibility for managing and overseeing ICT risk to a control function with appropriate independence, and to keep risk management, control and internal-audit functions segregated (9, European Union, 2022). An architect who designs a boundary and accepts the risk of its failure is marking their own work.

The architect is not the operator. The SOC, the platform team and the agent operators run the systems and hold the stop path in operation; the architect designs and tests. Where a small organisation has no alternative, the charter says so and states the compensating review, because segregation of duties under ISO/IEC 27002 control 5.3 still applies (24, ISO/IEC, 2022).

The architect is not the approver of every change. Under Shift 2, routine changes are decided at gates by policies the architect designed; the architect reviews the policy, not each instance.

The architect is not the signatory for the management body. The architect prepares, advises and equips; the management body approves the measures and answers for them.

The charter and the management body

Three European instruments place duties on management bodies and deployers, not on architects; the charter connects the role to those duties without pretending to share them. What follows describes architectural implications, not legal advice.

The NIS 2 Directive, Directive (EU) 2022/2555, requires Member States to ensure that the management bodies of essential and important entities approve the cybersecurity risk-management measures taken under Article 21, oversee their implementation and can be held liable for infringements (Article 20(1)), and that members of those bodies follow training (Article 20(2)) (6, European Union, 2022). Article 21(2)(i) includes human-resources security and access-control policies among the measures. For the digital-infrastructure and ICT-service entities it covers, Implementing Regulation (EU) 2024/2690 asks for roles, responsibilities and authorities for network and information security to be laid down, and for at least one person to report directly to the management bodies on such matters (7, European Commission, 2024).

DORA, Regulation (EU) 2022/2554, goes further for financial entities. Article 5(2) requires the management body to define, approve, oversee and be responsible for the ICT risk-management framework, to bear the ultimate responsibility for managing ICT risk, and to set clear roles and responsibilities for all ICT-related functions; Article 5(4) requires its members to keep their knowledge and skills up to date, including through regular training (9, European Union, 2022). A role charter is one way of discharging the duty to set clear roles, and its approval record should say so.

In the AI Act, Regulation (EU) 2024/1689, Article 4 on AI literacy, as amended by the Digital Omnibus on AI, asks providers and deployers to take measures that support AI literacy among staff dealing with AI systems on their behalf (1, European Union, 2024) (2, European Union, 2026), and the Commission's guidance leaves the form of those measures to the organisation (4, European Commission, 2026). For high-risk AI systems, Article 26(2) still requires deployers to assign human oversight to natural persons who have the necessary competence, training and authority, and Article 14(4) describes what those persons must be able to do, including interrupting the system (1, European Union, 2024). This book builds on the conclusion of AI Governance, Chapter 14, that literacy is role-specific and must be evidenced in a competence framework and individual records (168, Nordqvist, 2026): the charter links the role to its competence record, CMP-* (Chapter 21).

The management body holds the accountability the law names; the architect equips it. The charter gives the role a duty to advise: to tell the management body, through the CISO, when a boundary cannot be held within its appetite, with the options and their costs. It gives the role a part in the training that NIS 2 Article 20(2) and DORA Article 5(4) require, because the architect can explain what the approved measures actually do. And it records that the architect turns articles into controls, which Chapter 18 develops, without signing for the result.

AI Governance, Chapter 13, concluded that NIS 2 Article 20 and DORA Article 5 anchor oversight in a trained management body (168, Nordqvist, 2026); that anchoring is observable law. No instrument places a comparable personal duty on architects. Named owners for controls in catalogues and evidence manifests are observable practice in the two organisations of this book, and are not a legal duty of the architect; the charter should not describe them as one. Whether the practice will extend to a named architect for each boundary is not established by any instrument or study this book has found, and Chapter 23 treats it as an outlook.

Accountability for what agents propose

Architecture as Code (Chapter 27) left open who holds responsibility for machine-authored artefacts, given that version control captures what changed but not whether the reasoning was sound (167, Nordqvist, 2025). The charter must settle the practical form of that question: who answers to a board, a supervisor or a court when an agent drafted a change, a pipeline merged it and an architect approved it.

This book builds on three earlier conclusions. Architecture as Code (Chapter 20) concluded that some decisions stay with people whatever the agents propose: architectural commitments with long-term consequences are escalated by the agent rather than resolved by it, conflicting agent recommendations are decided by the human owner, and every decision is linked to a commit, a pull request and an accountable individual (167, Nordqvist, 2025). AI Red Team, Chapter 6, concluded that every machine identity has an owner, operators and an authority who are named people, and that at Level 3 Bounded human approval moves from the individual action to the playbook and the decision record, which concentrates accountability rather than diluting it (170, Nordqvist, 2026). And NIS 2 Article 20 and DORA Article 5 do not let responsibility pass to a tool.

Applied to the architect's work, they give a rule the charter writes down: the person who approved is accountable for the approval, and the person who designed the gate is accountable for what the gate lets through. An agent that drafts a change proposed it and is accountable for nothing. The architect who approved the pull request is accountable for merging it after review at the depth the risk required. Where a gate merged a delegated change class without a human approval, the author of the gate policy answers for its adequacy and the forum that delegated the class answers for the delegation. The chain never ends in an agent or a pipeline.

The rule needs evidence: for each approval, the record shows who approved, what they saw, which tests and second opinions were attached and how long the review took. Chapter 14 turns this into a review protocol and treats approval time and rejection rate as signals of rubber-stamping. If an approval rested on evidence someone else falsified, or a gate passed a change because an upstream control failed silently, the record shows that too, and accountability follows the failure.

Some decisions the charter reserves to people at every autonomy level: agent-proposed changes that alter lock-in, data residency or an operational dependency go to a named architect however routine they look; conflicts between agents' proposals on a boundary are decided by the boundary's owner; and no agent approves its own or another agent's output, as Chapter 13 develops.

Worked example: Hansa Mutual's charters ROLE-HM-*

The following excerpt is illustrative. Hansa keeps one file, roles/security-architect.yaml, in the group architecture repository, with a shared section that every charter inherits and one entry per role. The excerpt shows the shared section, the head of security architecture and the AI domain security architect; the identity and platform domain architects and the two embedded architects follow the same pattern. It answers the executive board's request AIDR-0550.

# roles/security-architect.yaml  (Hansa Mutual, illustrative excerpt)
version: 2.0.0
commissioned_by: AIDR-0550
owner: group-chief-information-security-officer
shared:
  reports_to: head-of-security-architecture
  tiers: {1: pipeline-gate, 2: design-authority, 3: group-ai-governance-board, 4: executive-board}
  approval_rule: approver accountable for approval; gate author for gate policy
  never_delegated: [lock-in, data-residency, operational-dependency, agent-conflict]
  agents_never_approve: true
  does_not: [accept-residual-risk, operate-soc-or-platform, approve-every-change, sign-for-executive-board]
roles:
  - id: ROLE-HM-SA-HEAD
    title: Head of security architecture
    reports_to: group-chief-information-security-officer
    accountable_for: [consistency of decisions across seven regimes, advice to executive board via CISO]
    decide:
      - {class: mode-3-tools-for-architecture-work, limit_working_days: 5}
      - {class: autonomy-level-of-architecture-agents, max: Level 2 Supervised}
      - {class: stop-architecture-agents, limit_minutes: 15}
    recommend:
      - {class: level-3-for-architecture-agents, decided_by: design-authority}
      - {class: changes-to-MND-HM-01-recording-people, decided_by: design-authority, consult: employee-representatives}
    escalate:
      - {to: design-authority, within_working_days: 2}
      - {to: group-ai-governance-board, when: beyond design-authority mandate}
  - id: ROLE-HM-SA-AI
    title: Domain security architect, AI
    code_owner_paths: [platform/containment/, platform/egress/, controls/catalogue/CTRL-AGT-*]
    decide:
      - {class: containment-profile-of-mode-5-agent, limit_working_days: 5}
      - {class: conflicting-agent-proposals-on-ai-boundary, limit_working_days: 2}
      - {class: agent-permission-ceiling, limit_working_days: 5}
    veto:
      - {class: mode-5-go-live-without-tested-stop-path, override_by: group-ai-governance-board}
      - {class: agent-autonomy-level, override_by: group-ai-governance-board}
      - {class: model-admission-failing-provenance-or-inventory, override_by: group-ai-governance-board}
    recommend:
      - {class: guardrail-policy, decided_by: ai-architect}
      - {class: agent-permission-scope-within-ceiling, decided_by: ai-architect}
    seam: containment and identity here; guardrails and evaluation with the AI architects
delegated_to_gates:
  - catalogue-conformant egress change with passing tests
  - evidence-link refresh by evidence-collection agent at Level 3 Bounded
  - permission-manifest change that narrows scope
consultation:
  required_before_effect: [works-council-DE, works-council-NL, union-SE]
  reason: charters change what review agents may record about architects

The AI domain architect decides the containment profile of a Mode 5 agent such as the claims-triage agent and may veto its go-live without a tested stop path, but recommends on guardrail policy and on permission scope within the ceiling it sets, which the AI architects decide; the RACI of Chapter 16 records the same split, with the vetoes in a field of their own. Only the group AI governance board, chaired by the chief risk officer, can override the veto, so a disagreement between the two roles does not stall between colleagues. The delegated_to_gates block lists the change classes the fortnightly review board no longer sees, the first step of the redesign Chapter 17 completes.

Across the usage modes and autonomy levels

The charter's rights differ by usage mode, because the mode determines whose identity the AI uses and therefore who can be accountable for its actions, and by autonomy level, because the level determines where human approval sits.

Mode or level What the charter grants the security architect Where accountability rests
Mode 0 Ambient AI Recommend controls on vendor features in security products; no design authority Contract owner and CISO
Mode 1 Conversational assistants Use within the enterprise rules; no special rights The architect, for what they adopt from the output
Mode 2 Embedded workplace assistants Recommend data-access boundaries for assistants that read architecture information System owner
Mode 3 Agentic work tools Approval of tools for architecture work, under a mandate manifest Approver of the tool and the architect who uses it
Mode 4 Built AI applications Decide security requirements and the pre-production checklist System owner, on the architect's advice
Mode 5 Autonomous production agents Design authority over containment; veto go-live without a tested stop path Agent owner, operators and authority, named
Level 0 Advisory and Level 1 Assisted Architect authors or adopts each decision The architect
Level 2 Supervised Architect approves each agent action The approving architect
Level 3 Bounded Approval moves to the playbook and the record; decided at tier 2 The authority who approved the playbook
Level 4 Autonomous Never granted for architecture changes or irreversible actions Not applicable

The architect may set the level of the architect's own agents up to Level 2 Supervised; Level 3 Bounded needs a tier 2 decision for a narrow class of reversible actions, such as Hansa's evidence-collection agent refreshing evidence links. The charter never delegates accountability to a Level 3 or Level 4 action; it moves human approval from the action to the playbook and the record. Level 4 Autonomous is never used for irreversible actions, which in architecture work covers almost every change to a boundary.

Maintaining the charter

A charter written once and filed has become a job description again. Maintaining it as code means four things.

Ownership. The CISO owns the charter; the architect is its principal author; HR is a required reviewer, because decision rights affect grading, assessment and sometimes the employment contract. The code-owners entry for roles/ names the CISO and HR (174, GitHub, n.d.), and the architect never approves a change to their own charter.

Review cadence and triggers. Review the charter at least annually, alongside the ISO/IEC 27001 management review, and on trigger: a new Mode 5 agent, a reorganisation, a new regulatory duty, an incident in which a right was unclear or too slow, or a change to the architect's own mandate manifest. Each review runs the test in the practical guide below.

Consultation. Where a change alters what is recorded about people or how their work is assessed, employee representatives are involved before it takes effect, by routes that differ by country. In Germany, the works council has a right of co-determination over the introduction and use of technical facilities designed to monitor the behaviour or performance of employees (BetrVG section 87(1) no. 6) (22, Germany, 2001). In the Netherlands, the works council's consent is required for a decision on a system for observing or checking the presence, behaviour or performance of personnel (WOR Article 27(1)(l)) (175, Kingdom of the Netherlands, 1971). In Sweden, an employer bound by a collective agreement must negotiate with the union before deciding on important changes to work or working conditions (MBL section 11) (176, Sweden, 1976). A charter that ties rights to the approval-quality metrics of an agent team engages these rules, because the agents record who approved what and how quickly.

Change by pull request. Every change carries a reason, the review of the CISO and HR, a link to the decision record that prompted it and a passing charter test, so every right can be traced, years later, to the decision that granted it.

Organisational design shapes how a charter ages. Systems tend to mirror the communication structures of the organisations that design them (77, Conway, 1968), and team types, interaction modes and cognitive load set what a team can carry (83, Skelton & Pais, 2019). A charter that loads a single post with every decision class will produce boundaries shaped by that overload. Hohpe's architect who rides the elevator between the boardroom and the engine room is a useful check: a charter whose rights all sit at the gate, or all at the board, has lost one end of the ride (74, Hohpe, 2020).

Practical guide: Testing a charter against ten decisions from the last year

Purpose. Show, before adoption and at each review, that the charter resolves real decisions to one holder within the time those decisions allowed.

Roles involved. The security architect selects and encodes the cases; the CISO and one neighbouring role, normally the enterprise architect or the AI architect, review the results; the decision records come from the repository.

  1. Select ten decisions from the last twelve months, including two contested, two slow, one agent proposal and one supplier decision.
  2. Encode each as a test case with the decision class, the facts as they were known at the time, the holder who decided in fact and the elapsed time.
  3. Resolve each case against the charter, by hand or with a small script that reads the YAML, and record the holder and time limit the charter would have given.
  4. Classify the result as resolved (one holder, within time), ambiguous (two holders or none), or too slow (the charter's limit exceeds what the situation allowed).
  5. Change the charter for every ambiguous or too-slow case, by pull request, and re-run the test.

Definition of done. At least eight of ten cases resolve; no case involving a running agent or a stop decision is ambiguous or too slow; every change is merged with the test result attached.

The cases are kept beside the charter, so that the next review re-runs them with new ones added:

# roles/tests/charter-cases-2026.yaml  (Hansa Mutual, illustrative excerpt)
charter_version: 2.0.0
cases:
  - id: CASE-03
    facts: policy-author agent and threat-modeller agent proposed conflicting egress rules for the claims-triage agent
    class: conflicting-agent-proposals-on-ai-boundary
    decided_in_fact: {by: fortnightly review board, elapsed_working_days: 9}
    expected: {holder: ROLE-HM-SA-AI, limit_working_days: 2}
    result: resolved
  - id: CASE-06
    facts: change to MND-HM-01 adding approval timestamps per architect to the review log
    class: changes-to-MND-HM-01-recording-people
    decided_in_fact: {by: head-of-security-architecture, elapsed_working_days: 1}
    expected: {holder: design-authority, consult: employee-representatives}
    result: ambiguous   # charter 1.x let the head decide alone; fixed in 2.0.0
  - id: CASE-09
    facts: SOC shift lead asked the architect to confirm a stop of the IT-operations agent
    class: stop-of-production-agent
    decided_in_fact: {by: soc-shift-lead, elapsed_minutes: 22}
    expected: {holder: incident-authority, architect_right: recommend, precondition: none}
    result: too-slow   # confirmation was treated as required; runbook corrected

In the third case the charter was right, but the SOC runbook treated the architect's confirmation as a precondition for a stop, making stopping more expensive than continuing. The fix belongs in the runbook, but only the test made the gap visible.

Nordvik Region and Hansa Mutual

Nordvik Region's charter ROLE-NR-SA-01 answers AIDR-0500 and gives the single post-holder, for the first time, written decision rights: to decide the stop-path and egress requirements in tender annexes, to veto an annex or an AI go-live without a stop path, subject to the CISO's recorded override, and to escalate to the CISO within two working days and, through the regional director, to the regional executive committee for the political tier. Because the post is a single point of failure, every right that would let one person approve their own work, including changes to MND-NR-01, is a recommendation to the CISO instead. Approved by the CISO and endorsed by the regional director, it takes effect on 1 January 2027 and is written to survive public-access requests: it states rights and limits, not the weaknesses they address.

Hansa Mutual's charters ROLE-HM-* cover the head of security architecture, the three domain architects and the two embedded architects. They separate the AI domain architect's rights over containment and identity from the AI architects' rights over guardrails and evaluation, and they list the change classes the fortnightly review board delegates to pipeline gates. Because the charters change what the review agents under MND-HM-01 may record about architects, the change goes to the works councils in Germany and the Netherlands and to union consultation in Sweden before it takes effect in each entity; the charter test for version 2.0.0 is where the group found that the head's right to change what the agents record needed that consultation.

Nordvik's charter gives one person enough authority to hold boundaries through contracts without becoming a bottleneck or a sole approver. Hansa's charters distribute authority among six people so that decisions keep pace with agents in production without accountability dissolving between architects, AI architects and gates.

Summary

The transformed security architect is defined by a role charter kept as code. It states the mandate as products the role designs and owns (boundaries, policy decision points, the identity model, the control catalogue with its evidence chain, and stop paths) and the repository paths the architect reviews. It states accountabilities for design, verification and advice, each with a named recipient, and separates accountability for a boundary holding from authorship of its artefacts.

Decision rights take four forms, decide, recommend, veto and escalate, placed on the decision tiers of AI Governance and bounded by time limits that work at machine speed. Vetoes are narrow. The right to stop a production agent stays with the stop holder, while the architect may always stop the architect's own agents. What the role does not do, accept residual risk, operate, approve every change or sign for the management body, is written down as carefully as what it does.

NIS 2 Article 20, DORA Article 5 and the AI Act's literacy and oversight provisions are observable law placing accountability on management bodies and deployers; the architect's part is a duty to advise, to equip and to turn articles into controls. Naming an accountable architect per boundary is not a legal duty, and whether it will become usual is an outlook for Chapter 23. For what agents propose, the approver answers for the approval and the gate author for the gate; the chain never ends in an agent.

The chapter concerns all four shifts. The charter is an instance of Shift 1, from documents to code; the written instrument of Shift 2, from gatekeeper to boundary designer; the source of the time limits that Shift 3, from periodic to continuous, at machine speed, demands; and the fixed point of accountability for Shift 4, from sole author to conductor of an AI team. It is owned by the CISO, changed by pull request and tested against real decisions. Part II begins with the craft that the charter makes the architect accountable for: Chapter 5 shows how security architecture itself moves from documents to executable design.

Sources

  1. European Union (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (1, European Union, 2024)
  2. European Union (2026). Regulation (EU) 2026/1744 amending Regulation (EU) 2024/1689 (Digital Omnibus on AI). (2, European Union, 2026)
  3. European Commission (2026). AI literacy: questions and answers. (4, European Commission, 2026)
  4. European Union (2022). Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). (6, European Union, 2022)
  5. European Commission (2024). Commission Implementing Regulation (EU) 2024/2690 on technical and methodological requirements of cybersecurity risk-management measures. (7, European Commission, 2024)
  6. European Union (2022). Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (9, European Union, 2022)
  7. Federal Republic of Germany (2001). Betriebsverfassungsgesetz (BetrVG). (22, Germany, 2001)
  8. ISO/IEC (2022). ISO/IEC 27001:2022 Information security management systems: Requirements. (23, ISO/IEC, 2022)
  9. ISO/IEC (2022). ISO/IEC 27002:2022 Information security controls. (24, ISO/IEC, 2022)
  10. European Union Agency for Cybersecurity (2022). European Cybersecurity Skills Framework (ECSF): Role profiles. (41, ENISA, 2022)
  11. SFIA Foundation (2024). SFIA 9: The global skills and competency framework for a digital world. (43, SFIA Foundation, 2024)
  12. Nygard, M. (2011). Documenting Architecture Decisions. (63, Nygard, 2011)
  13. Fowler, M. (2003). Who Needs an Architect? (73, Fowler, 2003)
  14. Hohpe, G. (2020). The Software Architect Elevator: Redefining the Architect's Role in the Digital Enterprise. O'Reilly Media. (74, Hohpe, 2020)
  15. Conway, M. E. (1968). How Do Committees Invent? (77, Conway, 1968)
  16. Skelton, M. & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press. (83, Skelton & Pais, 2019)
  17. Nordqvist, G. (2025). Architecture as Code. (167, Nordqvist, 2025)
  18. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (168, Nordqvist, 2026)
  19. Nordqvist, G. (2026). AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. (170, Nordqvist, 2026)
  20. Nordqvist, G. (2026). AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. (171, Nordqvist, 2026)
  21. Weill, P. & Ross, J. W. (2004). IT Governance: How Top Performers Manage IT Decision Rights for Superior Results. Harvard Business School Press. (173, Weill & Ross, 2004)
  22. GitHub (n.d.). About code owners. (174, GitHub, n.d.)
  23. Kingdom of the Netherlands (1971). Wet op de ondernemingsraden (WOR). (175, Kingdom of the Netherlands, 1971)
  24. Sweden (1976). Lag (1976:580) om medbestämmande i arbetslivet (MBL). (176, Sweden, 1976)