Competences of the Transformed Security Architect: A Framework
Chapter 21 opens Part V: Competence and Career. The earlier parts described what the transformed security architect does; this chapter asks what a person must be able to do to hold the role, and how anyone, the person included, can tell. It gives a competence framework kept as code, with six domains (design, code, AI, adversary, law and people), four levels from Foundation to Expert, and for each competence the evidence that demonstrates it in practice rather than the certificate that claims it. It maps the framework to ENISA's European Cybersecurity Skills Framework, SFIA 9 and the NIST NICE Framework, so that HR, procurement and recruitment can use their existing vocabularies, and shows what a competence record may contain, who may see it, and how it connects to the role charter of Chapter 4.
The chapter concerns all four shifts, because each changes what competence means. Shift 1, from documents to code makes the framework and the records versioned artefacts and code a domain of its own. Shift 2, from gatekeeper to boundary designer moves the centre of the design domain from reviewing proposals to designing boundaries. Shift 3, from periodic to continuous, at machine speed puts machine-speed defence into the adversary domain. Shift 4, from sole author to conductor of an AI team creates the AI domain and changes how every domain is evidenced, because when AI drafts much of the visible work, the visible work no longer shows who could have done it.
Figure 21.1: The framework as code: six domains assessed at four levels, each level demonstrated unaided and with AI, evidenced by practice rather than certificates, mapped to three common vocabularies and recorded in a competence record that conditions the role charter's decision rights and the autonomy ceiling of the architect's agents.
Why a framework, and why as code
Most organisations already describe the security architect in a job description, a grading decision, a list of preferred certifications and the informal judgement of colleagues. None of these answers the question this book takes up from AI Governance, Chapter 14: how competence is evidenced when AI does much of the visible work and certificates measure knowledge rather than judgement (168, Nordqvist, 2026). A job description lists tasks without levels, a grading decision values the post rather than the holder, a certificate records what a person knew on the day of an examination, and informal judgement cannot be reviewed or shown to a supervisor.
This book builds on two earlier conclusions. Architecture as Code (Chapter 18) managed competence as a skills matrix by level, Foundation, Practitioner, Advanced and Expert, with interpersonal domains beside the technical ones, and concluded that certifications validate knowledge while practical demonstration on real delivery shows capability (167, Nordqvist, 2025). AI Governance, Chapter 14, kept such a framework in YAML with individual records checked at the readiness gate, and concluded that competence is assessed by practical demonstration and that assessment results are personal data whose use is agreed with employee representatives (168, Nordqvist, 2026).
The workforce evidence explains the urgency. The ISC2 study for 2024 again reported persistent shortages of cybersecurity staff and skills (89, ISC2, 2024), and ISACA's survey of the same year reported that hiring managers value hands-on experience highly (90, ISACA, 2024). Both findings are observable. Organisations that cannot hire their way out must grow and judge their own architects, and need a better instrument than the certificate.
Competence is also a regulatory question. Article 4 of the AI Act, as amended by the Digital Omnibus on AI, asks providers and deployers to take measures to support AI literacy among their staff (1, European Union, 2024) (2, European Union, 2026), and the Commission confirms that no particular certificate is required (4, European Commission, 2026). Article 26(2) still requires deployers to assign human oversight of high-risk systems to persons with the necessary competence, training and authority (1, European Union, 2024); Article 20(2) of NIS 2 requires management-body training (6, European Union, 2022), and Article 5(4) of DORA requires the management body to keep sufficient knowledge to assess ICT risk (9, European Union, 2022). None names the security architect, but the architect designs the oversight interfaces, stop paths and board reporting through which those duties are met, and an organisation that must evidence its overseers' competence will be asked about the designer's.
A framework kept as code can be assessed against, because every competence names its evidence at each level; compared, because the same file maps to ECSF, SFIA and NICE; linked, because the role charter and the mandate manifests refer to its identifiers; and changed by pull request, reviewed by the head of security architecture, HR and, where they have rights, employee representatives. That is Shift 1 applied to the role itself.
Six domains
The grouping of competences into six domains is the book's proposal. It follows the structure of the role in Parts II to IV rather than that of any external framework; the mappings translate it.
Design is the core: boundary and containment design (Chapter 7), threat modelling kept in code (Chapter 6), the identity model for people, workloads and agents (Chapter 8), and stop paths and recoverability (Chapters 10 and 11). The principles are old, from Saltzer and Schroeder's principles of protection (64, Saltzer & Schroeder, 1975) to Shostack's four questions of threat modelling (71, Shostack, 2014). What Shift 2 changes is the object: the architect designs the boundary within which any proposal, human or agent, is acceptable, rather than judging each proposal.
Code covers policy as code and its tests (Chapter 5), the control catalogue and its evidence manifests (Chapter 9), and architecture models and pipelines. The architect must read, write and test the rules that carry the architecture, for example policies for Open Policy Agent (62, Open Policy Agent, n.d.), and tell whether a test exercises the property it claims to.
AI covers the architect's own use of AI in Modes 1 to 3 with verification (Chapters 12 and 14), containment and identity for Mode 5 agents, the threats named in the OWASP lists for language-model and agentic applications (44, OWASP, 2025) (45, OWASP, 2025), autonomy levels per action, and the conduct of an agent team under a mandate manifest (Chapter 13). External frameworks say least about it.
Adversary covers technique-level knowledge in the vocabularies of MITRE ATT&CK and ATLAS (46, MITRE, n.d.) (47, MITRE, n.d.), at the depth needed to design controls, detections and tests and never deeper, and, under Shift 3, from periodic to continuous, at machine speed, machine-speed defence as a design property: patch velocity, detection with the authority to act, and containment measured in minutes (Chapter 10).
Law covers the translation of the AI Act, NIS 2, DORA, the Cyber Resilience Act and the GDPR into controls and evidence (Chapter 18), requirements and contracts in procurement (Chapter 20), and the answers supervisors expect. It is not legal advice: it is the ability to read an article, decide which boundary or record it implies, and know when to ask a lawyer.
People covers decision rights and forums (Chapter 17), communication with boards, supervisors and engineers (Chapter 19), mentoring and keeping the craft (Chapter 15), and work with employee representatives. Architecture as Code (Chapter 17) described security partners who influence without direct authority (167, Nordqvist, 2025); the transformed role has written decision rights, and needs this domain to use them well.
| Domain | Competences | Shift most concerned | Less central than before |
|---|---|---|---|
| Design | DES-01 Boundary and containment design; DES-02 Threat modelling as code; DES-03 Identity model for people, workloads and agents; DES-04 Stop paths and recoverability | Shift 2 | Reviewing each proposal at a gate |
| Code | COD-01 Policy as code and its tests; COD-02 Control catalogue and evidence by operation; COD-03 Architecture models and pipelines | Shift 1 | Writing and maintaining long reference documents |
| AI | AI-01 Own use of AI with verification; AI-02 Containment and identity for Mode 5 agents; AI-03 Autonomy levels and Level 3 playbooks; AI-04 Conducting an agent team | Shift 4 | Producing every first draft personally |
| Adversary | ADV-01 Technique literacy for control design; ADV-02 Machine-speed defence as measured properties; ADV-03 Exercises and findings into boundaries | Shift 3 | Annual review cycles and periodic test reports |
| Law | LAW-01 Articles into controls; LAW-02 Requirements and contracts as controls; LAW-03 Evidence for supervisors and auditors | Shifts 1 and 2 | Recalling clause numbers and answering questionnaires by hand |
| People | PPL-01 Decision rights and forums; PPL-02 Communicating architecture; PPL-03 Mentoring and keeping the craft; PPL-04 Working with employee representatives | Shifts 2 and 4 | Persuasion as the only source of authority |
The last column answers which competences have become less central. None has disappeared, but pipelines, retrieval and drafting assistants now do much of them. What distinguishes the competent architect is the ability to decide what the boundary should be, to verify that code and AI output are sound, and to answer for the decision. Recall has become a tool that must be checked; judgement has not moved.
Levels
The four levels keep the names of Architecture as Code (Chapter 18) (167, Nordqvist, 2025), but each is defined twice: unaided, and with AI that the person verifies. Without the second definition the framework ignores how the work is done; without the first, an assisted architect appears Advanced on artefacts the assistant largely produced.
| Level | Unaided | With AI | Scope of decisions |
|---|---|---|---|
| Foundation | Explains the controls and boundaries of one system and applies patterns with guidance | Uses approved Mode 1 tools under a checklist and declares their use | None alone; proposes to a named architect |
| Practitioner | Designs the boundary, threat model and controls for a system of moderate risk and writes the policy and tests for it | Uses Modes 1 to 3 at up to Level 2 Supervised and catches seeded errors in AI drafts of the same work | Routine decisions within the catalogue and pattern library |
| Advanced | Designs boundaries across domains and suppliers, writes a Level 3 playbook and its tests, and defends the design to a forum | Conducts agents under a mandate manifest, sets autonomy levels per action and reviews AI proposals with measured quality | Exceptions, containment of Mode 5 agents, tender requirements |
| Expert | Sets the estate's reference boundaries and patterns, and decides when the catalogue or the framework itself is wrong | Designs the review and verification regime for the organisation's AI-assisted architecture work | Reference architecture, framework changes, escalation to the management body |
A person's level in a competence is the lower of the two demonstrated levels. An architect whose AI-assisted output is excellent but who cannot produce a sound threat model unaided is Practitioner in DES-02, however good the repository looks. The rule rests first on the automation literature: operators who rarely do a task manually lose the skill to take over when automation fails (106, Bainbridge, 1983), and complacency grows with the automation's reliability (107, Parasuraman & Manzey, 2010). Supervision and the degraded mode after a stop still need the skill that erodes. The rule also builds on the conclusion of AI Red Team, Chapters 6 and 15, that autonomy is paced to the skills available to supervise it (170, Nordqvist, 2026).
Kahneman and Klein concluded that intuitive expertise is trustworthy only where the environment is regular and gives adequate feedback (109, Kahneman & Klein, 2009). Security architecture gives slow, sparse feedback, so the framework asks for evidence that brings feedback forward, such as a chaos experiment that tested a boundary, and treats Expert as earned on designs that held under test, not on years in post. Deliberate practice with feedback (108, Ericsson et al., 1993) is the route between levels; Chapter 15 describes how a team arranges it.
Evidence of competence
The framework's central decision is that every competence names the evidence that demonstrates it at each level, drawn from practice. Five kinds qualify.
Unassisted demonstration is work done without AI under observation or in a time-boxed exercise: a threat model, a containment profile, a testable tender requirement. It shows what the person can do when the assistant is wrong or stopped, and it is the only evidence that answers the question of judgement directly.
Review records (Chapter 14) show what the person caught in the work of others, human or AI. A rejected plausible but unsound proposal, or a seeded error found in a drill, is stronger evidence of judgement than any artefact authored with help.
Artefacts that held under test are designs later verified: a boundary a red-team exercise failed to cross, a stop path that worked in a drill, a tender requirement a supplier met and the organisation verified. This book builds on the conclusion of AI Threat, Chapter 30, that a control is a defence only when a test that re-runs its scenario has passed recently (171, Nordqvist, 2026); the same standard makes a design count as evidence.
Peer and forum evidence comes from the forums of Chapter 17, such as a design defended at the design authority, and evidences the people domain.
Certificates and courses evidence knowledge. ISC2's CISSP-ISSAP concentration, for example, examines a body of security architecture knowledge and requires professional experience (91, ISC2, n.d.). The framework records certificates as supporting evidence at Foundation and Practitioner and never as sufficient for Advanced or Expert, not because they are weak but because they measure a different thing.
Three rules govern evidence. AI-assisted work counts but is declared, starting with the architect's own log of which drafts came from a tool (Chapter 12). Evidence ages, normally after two years, earlier when a trigger such as a new agent platform or instrument expires it. And evidence is referenced, not copied, so the record stays small and the evidence stays where it was produced. The answer to the open question is therefore a combination: what the person can do without AI, what the person caught in AI output, and designs that held when tested.
Practical guide: Assessing an architect against the framework by practical demonstration
Purpose. Assess an architect once a year, or when a decision right or autonomy ceiling depends on an unevidenced level, in a way that tests judgement and produces a record the person accepts as fair.
Roles. The person assessed; a lead assessor at least one level above, not the line manager where the organisation is large enough; a second assessor from a neighbouring function or, for a single post, a peer organisation; and the HR competence lead, who owns the process but not the judgement.
Steps.
- Agree the scope. Select at most six competences: those due, those on which a decision right or autonomy ceiling depends, and those the person wants to raise.
- Collect the record. The person lists evidence references since the last assessment; the assessors read them beforehand.
- Run an unassisted scenario. Draw it from the organisation's own estate, sanitised to the session's classification, or use a synthetic system when an external peer assesses, and give three hours without AI for a threat model, containment profile or requirement annex; never less than two.
- Run an AI-assisted review with seeded errors. Give an AI-drafted artefact with three to five seeded errors, at least one a fluent omission, and allow the approved tools. Record what was found and missed.
- Hold the rationale interview. For forty-five minutes, ask the person to explain two decisions: the alternatives, what would make each wrong, and what evidence would show it.
- Decide levels. Each assessor proposes levels independently, applying the rule of the lower level; unresolved disagreements go to the head of security architecture.
- Write the record and plan. Update the record with levels and evidence references, agree at most three development items, and delete the session's working notes once the record is accepted.
- Calibrate. Once a year, compare a sample of anonymised decisions across assessors, or with the peer organisation for a single post.
Definition of done. Every competence in scope has a level supported by an unassisted demonstration or review record; the person has read and could comment on the record; it is committed; and no decision right or autonomy ceiling depends on a level the record does not show.
Mapping to ECSF
ENISA's European Cybersecurity Skills Framework describes twelve role profiles, each with a summary, mission, deliverables, main tasks, key skills and knowledge, linked to competences of the European e-Competence Framework (41, ENISA, 2022). Its user manual presents them as a common language for workforce planning, education and recruitment rather than job descriptions to adopt unchanged (42, ENISA, 2022), and the Commission's Cybersecurity Skills Academy communication refers to it as a European reference (219, European Commission, 2023). For a public authority writing tenders and job advertisements, it is the vocabulary suppliers and other authorities are most likely to share.
The corresponding profile is the Cybersecurity Architect, who plans and designs security-by-design and privacy-by-design solutions and controls, delivers architecture diagrams and requirements, and draws on e-Competence Framework competences in architecture and application design (41, ENISA, 2022). It covers design and the knowledge side of law well, code only as specification, and people mainly as coordination. Published in 2022, it does not address the architect's own use of AI, the containment of agents with identities of their own or the setting of autonomy levels, nor machine-speed defence as a measured property.
The mapping therefore marks each competence as direct (DES-01 and DES-02 to the profile's design and threat-analysis tasks), partial (COD-01 implements as code what the profile treats as specification) or none (AI-02, AI-03 and ADV-02, recorded as local extensions). Recording the extensions lets an organisation use the European vocabulary without pretending it covers the transformed role. That ECSF is maintained and promoted is observable; that later editions will add AI content is expected; whether they will cover agent supervision is speculation.
Mapping to SFIA and NICE
SFIA 9 describes skills at up to seven levels of responsibility, defined through generic attributes such as autonomy, influence, complexity and knowledge (43, SFIA Foundation, 2024). HR functions often grade technical roles with it, which makes it the bridge to grading and career ladders. No single SFIA skill equals security architecture; the role is a combination with solution architecture and information security at its heart and threat intelligence, information assurance, risk management and stakeholder relationship management around them. The four levels map approximately to SFIA levels 3 to 6. SFIA's attribute called autonomy describes a person's independence of supervision, not an agent's autonomy level, and the framework file names it explicitly to keep the two apart.
The NICE Framework, NIST Special Publication 800-181 Revision 1, describes cybersecurity work through Task, Knowledge and Skill statements grouped into work roles and competency areas (33, Petersen et al., 2020); its work roles include cybersecurity architecture and enterprise architecture. It is a United States framework widely used by multinationals and training providers, and its statement-level granularity helps to show that a learning path covers specific knowledge. Map to it where a multinational or supplier needs it, not for its own sake.
Neither addresses agent supervision directly. Setting an agent's autonomy per action and writing the playbook that bounds it remain local extensions in all three mappings, which is observable today and is the main reason the framework is the organisation's own file, mapped outward.
Practical guide: Mapping a local framework to ECSF, SFIA and NICE
Purpose. Give each competence a recorded mapping to ECSF, SFIA and NICE for grading, advertisements, tenders and training catalogues, without letting any external framework redefine the role.
Roles. The head of security architecture or, for a single post, the post-holder with the enterprise architect; the HR competence lead, who owns SFIA grading; and the procurement lead where training or consultancy is bought.
Steps.
- Fix the local framework first. Map only a merged version; mapping from the external framework imports its structure.
- Map to ECSF. Record the Cybersecurity Architect tasks, skills or knowledge each competence corresponds to, marked direct, partial or none.
- Map to SFIA. Record one to three skills per competence, and agree the level correspondence with HR once for the whole framework.
- Map to NICE where needed. Record work roles, and statement-level mappings only where a multinational, supplier or catalogue needs them.
- Record the extensions. List competences with no counterpart, with a reason, and review the list at each new external edition.
- Use the mapping. Generate advertisement and tender text from ECSF, grading evidence from SFIA and catalogue queries from NICE.
Definition of done. Every competence has an ECSF marking and at least one SFIA skill, the level correspondence is agreed with HR, extensions are listed, and the mapping sits in the framework file, reviewed in the same pull request.
Worked example: competence/security-architect-framework.yaml
Illustrative example. One competence per domain from the framework both organisations start from; the full framework belongs in Appendix A. SFIA codes and ECSF and NICE names must be checked against the current edition of each framework before use.
# competence/security-architect-framework.yaml (illustrative excerpt)
framework:
id: SA-CF
version: "2027.1"
owner: head_of_security_architecture
levels: [foundation, practitioner, advanced, expert]
level_rule: lower of unassisted and ai_assisted demonstrated level
evidence_validity_months: 24
external_levels:
sfia_level_of_responsibility: {foundation: 3, practitioner: 4, advanced: 5, expert: 6}
role_profiles:
ecsf: Cybersecurity Architect
nice: [Cybersecurity Architecture, Enterprise Architecture]
competences:
- id: DES-01
name: Boundary and containment design
evidence:
practitioner: containment profile for one system accepted at review
advanced: unassisted boundary design across suppliers, held in an exercise
expert: reference boundary pattern adopted across the estate
maps: {ecsf: direct, sfia: [ARCH, SCTY]}
- id: COD-01
name: Policy as code and its tests
evidence:
practitioner: policy and failing test written unassisted for a new control
advanced: policy test suite that caught a regression in production change
maps: {ecsf: partial, sfia: [SCTY, TEST]}
- id: AI-03
name: Autonomy levels and Level 3 playbooks
evidence:
advanced: Level 3 playbook and its tests written unassisted and passed review
expert: autonomy policy for the estate approved by the decision forum
maps: {ecsf: none, sfia: [SCTY], extension_reason: agent supervision not covered}
- id: ADV-02
name: Machine-speed defence as measured properties
evidence:
advanced: patch velocity and containment time designed as service levels and met
maps: {ecsf: partial, sfia: [THIN, SCTY]}
- id: LAW-02
name: Requirements and contracts as controls
evidence:
practitioner: testable tender requirement that a supplier met and was verified
maps: {ecsf: direct, sfia: [INAS, BURM]}
- id: PPL-04
name: Working with employee representatives
evidence:
advanced: agreement on review metrics reached and recorded
maps: {ecsf: none, sfia: [RLMT], extension_reason: co-determination not in profile}
The level_rule makes the rule of the lower level executable, evidence is defined per level so that assessors know beforehand what a demonstration looks like, and the none entries with an extension_reason keep the external frameworks' gaps visible.
Competence records as personal data
A competence record is personal data, and an assessment of judgement is among its more sensitive kinds. Under the GDPR it needs a lawful basis and must respect purpose limitation, data minimisation and storage limitation under Article 5(1)(b), (c) and (e), and the person has the right of access under Article 15; Article 88 lets Member States set more specific rules for employment, so one schema may need a different access policy in each country (5, European Union, 2016). The architectural implication is that purposes, readers and retention belong in the record schema, versioned and reviewed.
In Germany, the Works Constitution Act gives the works council a right of consent over general assessment principles under section 94 and co-determination over technical devices designed to monitor behaviour or performance under section 87(1), number 6 (22, Germany, 2001). Assessment criteria are likely to fall under the first and review agents that show who wrote what under the second. These are implications for the design of records and tools, not legal advice.
The framework separates the competence record (levels, evidence references, validity, development plan), the evidence it refers to, which stays under its own systems' access rules, and the working notes of an assessment, deleted once the record is accepted. The record holds no prompt logs, time data or individual approval metrics; Chapter 14 reports approval quality at team level for the same reason. Its purposes are closed: checking decision rights and autonomy ceilings, planning development and grading the post. Individual performance ranking is excluded in the schema.
The person can read the whole record and attach a comment, because a record the person does not accept will not be used honestly. And a reference to classified evidence, such as a red-team exercise, reveals that the exercise took place, so the access policy must allow for it.
Worked example: Competence records CMP-NR-01 and CMP-HM-04
Illustrative example. The first record belongs to Nordvik Region's security architect after the first assessment in December 2026, by the enterprise architect and a peer from a neighbouring region under the exchange arrangement of Chapter 15; the peer assessed only a synthetic case, because architecture information describes the Region's defences. The record shows a post-holder who came from the security coordinator's work: strong in law, still building design and code.
# competence/records/CMP-NR-01.yaml (illustrative)
competence_record:
id: CMP-NR-01
person_ref: NR-EMP-31108
role_charter: ROLE-NR-SA-01
framework: {id: SA-CF, version: "2027.1"}
assessed_on: 2026-12-10
assessors: [enterprise_architect, peer_security_architect_neighbouring_region]
purposes: [decision_rights_check, development_plan, post_grading]
not_used_for: [individual_performance_ranking]
readers: [record_subject, ciso, hr_competence_lead]
retention: current and previous record; working notes deleted on acceptance
competences:
- id: DES-02
level: practitioner
unassisted: EVD-NR-2026-031 # citizen-service assistant threat model redrafted without the tool
review: EVD-NR-2026-034 # three of four seeded errors found in an AI draft
peer: EVD-NR-2026-038 # synthetic case, assessed by the neighbouring region
- id: LAW-02
level: advanced
unassisted: EVD-NR-2026-022 # stop-path requirement written into NR-2026-117 and accepted by TriageSoft; first drill due 2027
- id: COD-01
level: foundation
unassisted: EVD-NR-2026-036 # reads and amends a checklist policy; tests not yet written
- id: AI-03
level: foundation
note: no Level 3 playbooks in the Region; not required by ROLE-NR-SA-01
certificates: [CISSP]
subject_comment: agrees; asks for COD-01 to be reassessed after the catalogue pilot
post_requires: {design: advanced, law: advanced}
development_plan:
learning_path: LP-NR-2027-01 # Chapter 22, decided as AIDR-0532
items:
- {competence: COD-01, target: practitioner, by: 2027-09-30}
- {competence: DES-01, target: practitioner, by: 2027-12-31}
- {competence: PPL-03, target: practitioner, evidence: deputy from platform team assessed, by: 2027-12-31}
valid_until: 2028-12-10
The second belongs to Hansa Mutual's AI domain security architect and refers to the group's works-council agreement instead of repeating purposes, readers and retention.
# competence/records/CMP-HM-04.yaml (illustrative)
competence_record:
id: CMP-HM-04
person_ref: HM-EMP-50421
role_charter: ROLE-HM-SA-AI
framework: {id: SA-CF, version: "2027.1", group_map: competence/ai-competence-framework.yaml}
assessed_on: 2027-02-18
terms: AIDR-0566 # purposes, readers and retention agreed with the works council
competences:
- id: AI-02
level: advanced
unassisted: EVD-HM-2027-011 # containment profile for a described Mode 5 agent
- id: AI-03
level: advanced
unassisted: EVD-HM-2027-012 # link-refresh playbook of the evidence collector rewritten and tested
review: EVD-HM-2027-015 # second-agent critique overruled with recorded rationale
- id: PPL-04
level: practitioner
forum: AIDR-0556 # team-level approval-quality metric agreed
valid_until: 2029-02-18
CMP-HM-02, the identity domain architect's record, has the same form, with DES-03 at Expert on the workload-identity pattern of the claims-triage agent. At its first assessment in February 2027 it showed AI-03 at Practitioner, because the unassisted playbook demonstration was still to come; the reassessment in September 2027 raised it to Advanced and made the identity architect the second holder that the Level 3 condition below requires. Until then the evidence collector's Level 3 rested on a recorded, time-limited exception approved by the design authority, expiring on 30 September 2027, with internal audit sampling the link refreshes weekly (Chapter 25).
Linking competence to the charter and to autonomy
A framework that only describes people remains an HR artefact. It becomes an architecture artefact when decisions depend on it, through two links.
The first runs to the role charter of Chapter 4. Each consequential decision right names the competences and levels it requires and what happens when the holder's record does not show them: the decision escalates, or the forum decides, until the gap is closed. The aim is an honest charter, not the removal of rights.
The second runs to the mandate manifests of Chapter 13. This book builds on the conclusion of AI Red Team, Chapter 6, that at Level 3 Bounded human approval moves from the action to the playbook and the decision record, which concentrates accountability rather than diluting it (170, Nordqvist, 2026). If approval moves to the playbook, the competence that matters is writing and testing it, so the autonomy ceiling in a manifest depends on the supervising architect's evidenced level in AI-03, including an unassisted demonstration.
# competence/conditions.yaml (illustrative excerpt, Hansa Mutual)
conditions:
- applies_to: {artefact: ROLE-HM-SA-AI, decision_class: containment-profile-of-mode-5-agent}
requires: {DES-01: advanced, AI-02: advanced}
if_unmet: decision escalates to head_of_security_architecture
- applies_to: {artefact: MND-HM-01, setting: autonomy ceiling for evidence-link refresh}
requires: {AI-03: advanced}
evidence_required: unassisted
min_holders: 2
if_unmet: ceiling falls to level_2_supervised until the record shows it
- applies_to: {artefact: MND-HM-01, setting: approver of review-agent pull requests}
requires: {AI-01: practitioner, COD-01: practitioner}
if_unmet: approval by a second named architect
check:
runs_on: [pull request to roles/, pull request to mandates/, nightly]
reads: competence/records/
output: pass or a finding to head_of_security_architecture; no record content is exposed
The check reads levels, not evidence, and reports a pass or a finding, never record content, which keeps it within the agreed purposes. When a record expires, the finding goes to the head of security architecture and the affected action reverts to Level 2 Supervised until the evidence is renewed. A lapse is managed like an expired certificate on a service, not as a disciplinary event.
Across the autonomy levels
The competence the architect needs, and the evidence that shows it, change with the mode in which AI is used and the level at which it acts.
| Mode or level | What the architect must be able to do | Evidence that shows it |
|---|---|---|
| Mode 0 Ambient AI | Find vendor AI in the architect's own tools and in procured products, and establish its effective autonomy | Inventory entry and contract requirement verified with the supplier |
| Modes 1 to 3 | Use AI with the architect's identity, route by classification and verify output | Declared-use log, seeded-error review results, AI-01 at Practitioner |
| Mode 3 at Level 2 Supervised | Read each proposed change or command before approval and recognise instructions that came from content | Review records with rejections and rationale |
| Mode 5 Autonomous production agents | Design identity, containment and stop paths for agents with identities of their own | Unassisted containment profile, AI-02 at Advanced, a stop-path drill |
| Level 3 Bounded | Write and test the playbook that bounds the action, unaided | AI-03 at Advanced with an unassisted demonstration |
| Level 4 Autonomous | Decide that an action is reversible enough, and design its monitoring and reversal | Expert decision recorded in an AIDR; never for irreversible actions |
Each step up in mode or level moves the architect's essential competence further from authoring and closer to designing the boundary and verifying its tests.
What the frameworks do not yet cover
ECSF, SFIA and NICE are observable, maintained frameworks; their coverage of AI is partial and of agent supervision thin. The AI domain is the book's proposal, expected to be revised as the external frameworks publish new editions, which is why the mapping lists extensions for review. Whether the frameworks converge on something like it is speculation; the need is not, because the agents already act.
The framework does not settle pay. It gives a grading function evidence of what the post requires and what the holder can show; the weighing against pay scales or market rates remains the organisation's decision, with employee representatives where they have rights.
Nordvik Region and Hansa Mutual
Nordvik Region uses the framework to answer the second half of the regional director's commission, AIDR-0500: the competence plan that accompanies ROLE-NR-SA-01. The plan argues the post's grading within fixed pay scales from what the post requires, Advanced in design and law, which the security coordinator post it replaced did not, and separates that from what the holder shows today. CMP-NR-01 records the evidence: Advanced in LAW-02 on the stop-path requirement the architect wrote unaided into tender NR-2026-117 and TriageSoft accepted, to be held under test at the first drill, Practitioner in threat modelling on a threat model redrafted without the tool, and code still at Foundation, which the learning path of Chapter 22 addresses. Because the post is a single point of failure with no colleague at its level, a peer from a neighbouring region assesses with the enterprise architect, and the plan includes a deputy from the platform team. The Region uses the ECSF Cybersecurity Architect profile in consultancy requirements under its framework agreements, so that a supplier's architect is asked for the same evidence as its own.
Hansa Mutual adopts the framework for its team of six and maps it to the group competence framework of AI Governance, Chapter 14, so that both use one level scale (168, Nordqvist, 2026). It agrees purposes, readers and retention with the works councils in Germany and the Netherlands and in union consultation in Sweden, including that results are not used for performance ranking, recorded as AIDR-0566. The conditions file ties the evidence collector's Level 3 ceiling to two architects whose records show AI-03 at Advanced, consistent with the craft-keeping rule of Chapter 15. Hansa maps to ECSF for EU job advertisements, to SFIA for grading and to NICE where the UK entity and training suppliers use it.
For Nordvik the framework is the argument for a post and a plan for one person who must not remain the only one; for Hansa it keeps decision rights and agent autonomy in step with a team's evidenced judgement across seven jurisdictions.
Summary
The transformed security architect is defined by six domains of competence: design, code, AI, adversary, law and people. Recall, authorship of every draft and review at every gate have become less central because tools now do much of them; the judgement to decide a boundary, verify code and AI output, and answer for the decision has not.
Each competence is assessed at four levels, Foundation to Expert, demonstrated unaided and with AI, with the lower of the two counting. Evidence comes from unassisted demonstrations, review records, artefacts that held under test and forum decisions; certificates support the lower levels but do not show judgement. That is the chapter's answer to how competence is evidenced when AI does much of the visible work.
The framework maps to ECSF, SFIA 9 and NICE and records where they have no counterpart, above all for agent supervision. Competence records are personal data with closed purposes, agreed with employee representatives where they have rights, and connected to the role charter and the mandate manifests, so that decision rights and the autonomy ceiling of the architect's agents depend on evidenced competence and fall back safely when it lapses.
The chapter concerns all four shifts: Shift 1, from documents to code in the framework, records and conditions as versioned artefacts; Shift 2, from gatekeeper to boundary designer at the centre of the design domain; Shift 3, from periodic to continuous, at machine speed in the adversary domain; and Shift 4, from sole author to conductor of an AI team in the AI domain and in the demand that every domain be shown without the assistant. Chapter 22 turns the framework into practice: learning paths, certifications and their limits, hiring profiles, interview exercises that test judgement, and the choice between upskilling and hiring.
Sources
- Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Architecture as Code Series, Book 2. (168, Nordqvist, 2026)
- Nordqvist, G. (2025). Architecture as Code. The Architecture as Code Series, Book 1. (167, Nordqvist, 2025)
- ISC2 (2024). 2024 ISC2 Cybersecurity Workforce Study. ISC2. (89, ISC2, 2024)
- ISACA (2024). State of Cybersecurity 2024: Survey results. ISACA. (90, ISACA, 2024)
- Saltzer, J. H. & Schroeder, M. D. (1975). The Protection of Information in Computer Systems. (64, Saltzer & Schroeder, 1975)
- Shostack, A. (2014). Threat Modeling: Designing for Security. Wiley. (71, Shostack, 2014)
- Open Policy Agent Contributors. Open Policy Agent Documentation. (62, Open Policy Agent, n.d.)
- OWASP Foundation. OWASP Top 10 for Large Language Model Applications, 2025 edition. (44, OWASP, 2025)
- OWASP Foundation (2025). OWASP Top 10 for Agentic Applications for 2026. (45, OWASP, 2025)
- MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (46, MITRE, n.d.)
- MITRE Corporation. MITRE ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems. (47, MITRE, n.d.)
- Nordqvist, G. (2026). AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. The Architecture as Code Series, Book 4. (170, Nordqvist, 2026)
- Bainbridge, L. (1983). Ironies of automation. Automatica. (106, Bainbridge, 1983)
- Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. Human Factors. (107, Parasuraman & Manzey, 2010)
- Kahneman, D. & Klein, G. (2009). Conditions for Intuitive Expertise: A Failure to Disagree. American Psychologist. (109, Kahneman & Klein, 2009)
- Ericsson, K. A., Krampe, R. T. & Tesch-Römer, C. (1993). The Role of Deliberate Practice in the Acquisition of Expert Performance. Psychological Review. (108, Ericsson et al., 1993)
- Nordqvist, G. (2026). AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. The Architecture as Code Series, Book 5. (171, Nordqvist, 2026)
- European Parliament and Council of the European Union (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union. (1, European Union, 2024)
- European Parliament and Council of the European Union (2026). Regulation (EU) 2026/1744 (Digital Omnibus on AI). Official Journal of the European Union. (2, European Union, 2026)
- European Commission (2026). AI literacy: questions and answers. Shaping Europe's digital future. (4, European Commission, 2026)
- European Parliament and Council of the European Union (2022). Directive (EU) 2022/2555 (NIS 2 Directive). Official Journal of the European Union. (6, European Union, 2022)
- European Parliament and Council of the European Union (2022). Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union. (9, European Union, 2022)
- ISC2. CISSP-ISSAP: Information Systems Security Architecture Professional. ISC2 certification page. (91, ISC2, n.d.)
- European Union Agency for Cybersecurity (2022). European Cybersecurity Skills Framework (ECSF): Role profiles. ENISA. (41, ENISA, 2022)
- European Union Agency for Cybersecurity (2022). European Cybersecurity Skills Framework (ECSF): User manual. ENISA. (42, ENISA, 2022)
- European Commission (2023). Closing the cybersecurity talent gap to boost the EU's competitiveness, growth and resilience ('The Cybersecurity Skills Academy'). COM(2023) 207 final. (219, European Commission, 2023)
- SFIA Foundation (2024). SFIA 9: The global skills and competency framework for a digital world. SFIA Foundation. (43, SFIA Foundation, 2024)
- Petersen, R., Santos, D., Wetzel, K. A., Smith, M. C. & Witte, G. (2020). Workforce Framework for Cybersecurity (NICE Framework). NIST Special Publication 800-181 Revision 1. (33, Petersen et al., 2020)
- European Parliament and Council of the European Union (2016). Regulation (EU) 2016/679 (General Data Protection Regulation). Official Journal of the European Union. (5, European Union, 2016)
- Federal Republic of Germany (2001). Betriebsverfassungsgesetz (BetrVG). (22, Germany, 2001)