What the Security Architect Did: The Role Before the Transformation

The security architect existed, and was valued, before any of the shifts this book describes. The role grew out of information-security management and network design, took its frame from ISO/IEC 27001, SABSA and TOGAF, and did its work through risk registers, layered design documents, reference architectures, review boards and signatures. Those methods were not mistakes. They answered the conditions of their time: a few hundred systems, quarterly releases, a defined network perimeter, suppliers who delivered products rather than services, and adversaries who worked at human speed. This chapter describes the practice fairly, says why it was valuable, and shows where it stopped scaling, so that the chapters that follow can keep what was right and replace only what no longer works.

The chapter concerns all four shifts, because it describes the starting point from which each departs: documents where Shift 1, from documents to code, puts versioned artefacts; the gate where Shift 2, from gatekeeper to boundary designer, puts boundaries that hold whatever anyone intends; the annual and quarterly rhythm that Shift 3, from periodic to continuous, at machine speed, replaces with verified properties; and the architect as sole author, the starting point of Shift 4, from sole author to conductor of an AI team. Chapter 3 defines the shifts. This chapter supplies the baseline against which they are measured.

Figure 2.1: Each inherited method assumed conditions that held in its time, each stopped scaling where those conditions changed, and four things survive into the transformed role.

Where the role came from

Security architecture became a distinct role in the large European organisation along two routes. The first ran through the information-security officer. Policies, awareness and audit answers were the officer's work, and as systems multiplied, someone had to translate the policy into a design that engineers could build. The second ran through network and infrastructure design. Firewalls, zones and remote access were designed by people who understood the network, and security was one of their concerns before it became their title. The security architect sat where the two routes met: close enough to policy to know what the organisation had promised, and close enough to engineering to know what could be built.

The profession formalised the role during the 2000s and 2010s. Sherwood, Clark and Lynas published SABSA in 2005 as a method for enterprise security architecture driven by business requirements (38, Sherwood et al., 2005). The Open Group published guidance on integrating risk and security into a TOGAF enterprise architecture (40, The Open Group, 2016). Certification followed: ISC2 offers the CISSP-ISSAP concentration for the architecture role (91, ISC2, n.d.). The standards gave the role a vocabulary, and the vocabulary gave organisations something to put in a job description.

What the role did day to day was consistent across organisations, whatever the title. The architect maintained the security policy and standards or advised the people who did. The architect produced a security reference architecture and kept it current in as far as time allowed. The architect reviewed new systems against it, wrote security requirements for tenders and projects, sat on or reported to a review board, and signed or recommended the signature of a risk acceptance when a system could not meet a requirement. Between those tasks the architect answered questions, from project managers who needed to know what was allowed, from auditors who needed to see how it was decided, and from the chief information security officer who needed to know where the exposure lay. The architect was also, in nearly every task, the sole author: one person wrote the standard, the reference architecture, the requirements and the risk-acceptance recommendation, and the quality and currency of all of them depended on that person's hours. This is the starting point of Shift 4, from sole author to conductor of an AI team, and it is why a single post, as in Nordvik, is a single point of failure. Chapters 12 to 15 take up what changes when the architect is no longer the only author.

The two example organisations reached this practice from different directions. Nordvik Region created its post in 2025 by converting a security coordinator post, whose work was keeping the information-security policy documents, coordinating the annual procured penetration test and answering supplier security questionnaires. Hansa Mutual's group security architecture team of six grew around a fortnightly architecture review board and a control catalogue of about 180 controls. Both are recognisable descendants of the practice described here, and Chapter 1 introduced both organisations.

Risk-based security management

The frame inside which the security architect worked was, in most European enterprises and public authorities, an information security management system under ISO/IEC 27001. The standard asks the organisation to define a risk assessment process, to assess risks against criteria it has set, to choose treatments, and to record in a statement of applicability which controls it has selected, which it has excluded and why; it also asks top management to review the system at planned intervals (23, ISO/IEC, 2022). The 2022 edition lists 93 controls in four themes, organisational, people, physical and technological, in the companion standard ISO/IEC 27002 (24, ISO/IEC, 2022), and ISO/IEC 27005 gives guidance on the risk process itself (25, ISO/IEC, 2022).

The architect's contribution to this frame was threefold. The architect translated an abstract risk into a design: a risk that a supplier's administrators could read citizen records became a requirement for customer-held keys and a logging requirement. The architect kept the statement of applicability honest, by checking that a control marked as implemented was implemented in the systems that mattered. And the architect prepared the evidence for the management review, so that the people accountable for the risk saw the exposure in terms they could act on.

The method had real strengths. It forced the organisation to say what it was protecting and why, in a form an auditor could test. It gave risk acceptance an owner. It produced the continuity that makes audits tractable: the same structure year after year, so that change was visible. European regulation has since built on the same pattern. NIS 2 requires entities in scope to take appropriate and proportionate risk-management measures, among them policies on risk analysis and information system security and measures for supply chain security, and makes the management body approve and oversee them (Articles 20 and 21 of Directive (EU) 2022/2555) (6, European Union, 2022). DORA places responsibility for ICT risk management on the management body of the financial entity (Article 5 of Regulation (EU) 2022/2554) (9, European Union, 2022). The architectural implication is that the risk-based frame is law's own frame as well as the profession's, and the transformed role keeps it.

The conditions under which the method worked were equally clear. The cycle was annual: the risk assessment, the statement of applicability and the management review turned once a year, with surveillance audits in between. The scope was a defined estate, in which an asset register was a tolerable approximation of reality. And the evidence was attested: someone with knowledge of a system stated, in a spreadsheet or a document, that a control operated. Attestation is cheap to collect and expensive to trust, and it ages from the day it is signed. That is the point at which the practice begins to strain, and Chapter 9 returns to it when the control catalogue becomes code.

Layered, business-driven design

SABSA contributed what risk management alone does not: a way to get from a business requirement to a component, and back. Its matrix crosses six layers, contextual, conceptual, logical, physical, component and operational, with six questions, what, why, how, who, where and when. Its distinctive device is the business attribute profile, in which the organisation's goals are expressed as attributes such as available, accurate or private, and each attribute is traced through the layers to the controls that deliver it (38, Sherwood et al., 2005). The traceability runs both ways. A control that traces to no business attribute is a candidate for removal, and a business attribute that traces to no control is a gap.

TOGAF supplied the other half: a place for security in the way an enterprise plans change. Its Architecture Development Method iterates from vision through business, information systems and technology architectures to opportunities and governance (39, The Open Group, 2022), and the Open Group's guide shows where risk and security considerations enter each phase (40, The Open Group, 2016). For the security architect, the method meant that a security concern raised in the architecture vision could shape the target architecture, and need not wait to be bolted on at release.

Beneath both sat the principles that outlasted every method. Saltzer and Schroeder set out eight design principles in 1975, among them economy of mechanism, fail-safe defaults, complete mediation, separation of privilege and least privilege (64, Saltzer & Schroeder, 1975). The NCSC's secure design principles restate the practice for current systems, from establishing the context before designing a system to making compromise difficult, making disruption difficult, making compromise detection easier and reducing the impact of compromise (70, NCSC, 2019). Anderson's treatment of security engineering shows how often failures follow from the economics: the party who decides is not the party who bears the loss (65, Anderson, 2020). Schneier's remark that security is a process, not a product, captures the stance of the whole tradition (66, Schneier, 2000).

The strengths were traceability and a shared vocabulary. A layered design let a business owner, an engineer and an auditor each find their own view of the same system, and Rozanski and Woods make the same argument for viewpoints in software architecture generally (75, Rozanski & Woods, 2011). The limit was the unit of work. The matrix and the architecture development method presume that architecture is planned in cycles and recorded in documents that humans curate. When the estate is described by thousands of changes a week, the matrix cannot be kept current by hand, and a layer that is stale is worse than a layer that is absent, because readers trust it. Architecture as Code (Chapter 9) took the first step away from this limit by making the four dimensions of security architecture, threat modelling, zero trust, Policy as Code and risk assessment, properties of the codebase rather than of a document set (167, Nordqvist, 2025).

Review boards and sign-off

The review board is the institution most associated with the security architect, and it is the most misunderstood. Its legitimate purposes were three, and each remains a purpose after the transformation.

The first was scarce expertise. A large organisation had a handful of people who could tell whether a design for remote access, key management or tenant separation would hold. A board concentrated their attention on the decisions where it mattered, and it spread their knowledge by making projects present to them. Fowler's argument that an architect's value lies in spreading a shared understanding of the important decisions, and not in imposing them, describes what a good board did on its best days (73, Fowler, 2003).

The second was irreversibility. When a system was deployed once a quarter into a data centre, a mistake in the design stayed in production for months, and the cost of reversing it was high. A gate before deployment was a rational response to a deployment that could not be undone cheaply. The reasoning is worth keeping: the inherited gate was proportionate to the cost of reversal, and where reversal is cheap, the gate can be lighter.

The third was accountability. Someone had to be able to say that the design was reviewed, by whom, against what, and that a named person accepted any residual risk. A signature is a crude instrument for this, but it served the purpose that regulators and auditors still ask of it. NIS 2 and DORA place accountability on the management body (Article 20 and Article 5 respectively) (6, European Union, 2022) (9, European Union, 2022), and a review record is how the management body shows that it knew what it accepted. The control function's independence mattered as well: the person who challenges a design must not be the person who delivers it. AI Governance (Chapter 12) concluded that control functions keep this independence through gates and records rather than meetings, with exceptions routed as expiring records (168, Nordqvist, 2026), and the conclusion is a refinement of the inherited purpose, not a rejection of it.

Hansa Mutual shows the board at its most developed. The fortnightly architecture review board hears contested items, a design authority runs inside it as a forum of the second tier, and decisions beyond its mandate go to the group AI governance board and then to the executive board, which is the management body for DORA purposes. Nordvik Region has no standing board. Its security architect brings decisions to the few existing forums and to the chief information security officer, and records them in documents that must survive public-access requests and archiving. The two arrangements carry the same three purposes at different scales.

Reference architectures as documents

The reference architecture was the board's counterpart: the standing answer to the questions that did not need to come to the board. A security reference architecture set out the approved zones, the identity model, the data classification and the logging requirements, and a project that followed it was spared a detailed review. In principle this was delegation, because the architect decided once and the project applied the decision many times.

The weakness lay in the medium. A reference architecture published as a document has no mechanism that connects it to the estate it describes. Nobody runs the estate against the document, so the two diverge at the rate the estate changes, and the document keeps its authority long after it stops being accurate. Its readers also differ from its authors. Engineers consult it when they are blocked, find that it does not cover their case and decide for themselves. Auditors read it as a statement of what the organisation does, and the gap between the statement and the practice becomes an audit finding.

Two further weaknesses compound this. Documents cannot be tested, so the architect learns of an error only when a reader reports it or an incident exposes it. And a document cannot refuse. A system that violates its reference architecture is discovered at a review, if it comes to one, and not at the moment of violation. Kindervag's critique of the perimeter model, written in 2010, made a related point about networks: a model that treats the inside as trusted offers a hard shell and a soft centre (67, Kindervag, 2010). A reference document that depends on every project to read and apply it has the same shape. It protects the projects that come to it and says nothing about those that do not.

The documents were still valuable. Their principles were sound, their decisions had been argued, and their structure was a record of what the organisation had learned. Architecture as Code (Chapter 4) kept the argument and changed the medium by recording each significant decision as an immutable Architecture Decision Record beside the code, so that the rationale survives the people who made it (167, Nordqvist, 2025). The transformed role keeps the reasoning in the reference architecture and moves it into artefacts that the estate can be tested against.

The department of no

Security architecture carries a reputation that the profession has earned in part and in part been given. The reputation says that the security architect says no, says it late, and gives reasons in the vocabulary of policy rather than in the vocabulary of the project. Three mechanisms produced it, and separating them shows which are worth keeping.

The first mechanism is timing. A review that happens at the end of a project is a veto in all but name, because by then the cost of change is the cost of the project. Architects who were consulted only at the gate saw projects that had already committed to a supplier, a hosting model and a date. Their only available answer was yes or no, and an architect who has only that answer will be remembered for the no.

The second is asymmetry. The architect who approves a design that is later breached is blamed, and the architect who blocks a project that would have been fine is not, because nobody sees the counterfactual. Anderson's analysis of security failures as failures of incentive, in which the party who decides is not the party who bears the loss, points the same way: under an asymmetric payoff caution is the rational individual response, and caution at a gate looks like obstruction (65, Anderson, 2020). The architects were not unusually timid. They were responding to the incentives their organisations had given them.

The third is culture. Westrum distinguishes pathological, bureaucratic and generative organisational cultures by how they handle information, and shows that the bureaucratic orientation, which follows rules and compartmentalises responsibility, handles novelty poorly (78, Westrum, 2004). A gate that exists to apply a rule to every request belongs to this orientation, and it works well while requests are few and the rules are stable.

The evidence on what the gate costs is specific. Forsgren, Humble and Kim found that external approval of changes, by a change advisory board or a similar body, was associated with slower delivery and no better stability than lightweight peer review and automated checks (81, Forsgren et al., 2018). Kim and colleagues describe the practice that follows from this: security that is part of daily work, with automated checks in the pipeline, and not a stage at the end (82, Kim et al., 2016). The finding concerns a particular form of review, external and periodic, and it does not show that review is unnecessary. The inherited gate was usually the heavy form.

The reputation also hides what was right. The gates caught real defects: a flat network behind a new application, an administrative interface exposed to the internet, a supplier whose contract gave it unrestricted access to data. Where teams bypassed the gate, those defects reached production unchallenged. A fair account therefore separates the function of the gate, independent challenge before an irreversible commitment, from its implementation, a meeting that a project must pass. The transformed role keeps the function. AI Governance (Chapter 24) and AI Platform and Security (Chapter 17) already show the implementation changing: patch decisions are delegated in advance so that a weekly board does not sit in the path of known-exploited vulnerabilities, and the threat model lives in the repository, where it fails the pipeline when a threat has no control (168, Nordqvist, 2026) (169, Nordqvist, 2026).

What did not scale

Four developments strained the inherited practice, and a fifth breaks one of its assumptions.

Release frequency. The conditions of the inherited practice included quarterly or slower releases. Forsgren, Humble and Kim found that low-performing organisations deployed between once a month and once every six months, while the best performers deployed on demand, several times a day (81, Forsgren et al., 2018). A board that meets fortnightly can review a quarterly release programme. It cannot review changes that arrive daily from dozens of teams, and the queue in front of it grows in proportion to the release rate. This is observable in organisations that have moved to continuous delivery: the review either becomes a formality or becomes the bottleneck.

Cloud and platform estates. The perimeter model assumed that the architect could draw the boundary. In a cloud estate the boundary is a set of configurations that any team with the right permission can change, and the estate described by a reference document is not the estate that exists an hour later. Kindervag's argument for zero trust was an early response (67, Kindervag, 2010); the CISA Zero Trust Maturity Model is a current one (37, CISA, 2023). The architectural implication is that the architect must own the mechanisms that hold the boundary (policy points, identity, egress), not only the diagram that describes them. AI Platform and Security (Chapter 4) designed the platform on that principle, and the conclusion that the security architect is already a named owner of boundaries in the platform's code, not a reviewer of documents, comes from its Chapter 8 (169, Nordqvist, 2026).

Supplier ecosystems. The inherited practice reviewed products. Today's estate consumes services whose behaviour the supplier controls and changes, and the architect's levers are contracts and evidence rather than configuration. NIS 2 names supply chain security among the required measures (Article 21(2)(d)) (6, European Union, 2022), and DORA sets principles for the management of ICT third-party risk (Article 28) (9, European Union, 2022). A supplier questionnaire answered once a year is an attestation in the sense used above, and it ages from the day it is returned.

Adversaries at machine speed. A periodic cycle assumes that the interval between cycles is safe. Mandiant's analysis found that the average time between disclosure of a vulnerability and its exploitation fell to five days in 2023 (143, Charrier & Weiner, 2024), and AI Platform and Security (Chapter 18) and AI Red Team (Chapter 11) treat the collapsing exploitation window and exposure management at that speed (169, Nordqvist, 2026) (170, Nordqvist, 2026). Against that window, a monthly patch board and an annual penetration test measure the estate at intervals longer than the adversary needs. This is observable. The further claim, that AI will shorten the interval again, is expected: AI Threat (Chapter 18) weighs the evidence on cyber offence at machine speed (171, Nordqvist, 2026).

Agents with identities of their own. The inherited methods assumed, without stating it, that every action in the estate traced to a person's identity or to a service account that a person owned. Review, logging, segregation of duties and sign-off all depend on that assumption. A Mode 5 autonomous production agent acts with an identity and permissions of its own, at a pace and volume that no person's account matches, and the assumption fails. The claim that gate-based review cannot keep pace with such agents is expected, not yet demonstrated at scale. Chapters 10 and 17 test it.

Across the usage modes

The security architect met AI before the transformation mostly as Mode 0 features inside procured products and occasionally as Mode 4 applications under review. The table shows what the inherited methods assumed about each mode and where the assumption strains. The modes are those of AI Governance and AI Platform and Security (Chapter 2 in each) (168, Nordqvist, 2026) (169, Nordqvist, 2026).

Usage mode	How the inherited practice met it	What the practice assumed	Where it strains
Mode 0 Ambient AI	A supplier questionnaire line and a product property	The product's behaviour is stable between reviews	The supplier changes the feature without notice, and the questionnaire ages
Mode 1 Conversational assistants	An acceptable-use policy and a data classification rule	People follow the policy	The policy cannot see what is pasted, so only a platform boundary can enforce it
Mode 2 Embedded workplace assistants	A procurement review	The assistant reads only what the user is entitled to read	Existing permission sprawl becomes visible and exploitable through the assistant
Mode 3 Agentic work tools	Treated as developer tooling, outside the board's scope	A tool acts only when a person clicks	The tool chains actions under the person's identity and needs a mandate
Mode 4 Built AI applications	A system review at the board, as an application with a model inside	The application behaves as designed, release to release	Model and prompt changes ship without a release, so the review is stale
Mode 5 Autonomous production agents	Not anticipated	Every action traces to a person's identity	The agent has an identity of its own and acts at machine speed

The pattern is that the inherited methods fit the modes in which a person remains the actor and strain as the actor changes. That is the architectural reason why Shift 2 and Shift 3 are driven above all by Mode 5.

What the transformed role inherits

The transformed role replaces the form of the inherited practice and keeps its content. Four things carry over, and each is an inheritance with an owner, not a courtesy.

Traceability to business risk. SABSA's discipline that every control traces to a business attribute, and every attribute to a control, is the model for the control catalogue of Chapter 9 and the threat model of AI Platform and Security (Chapter 17), in which every threat names a control, every control a configuration and every configuration produces evidence (38, Sherwood et al., 2005) (169, Nordqvist, 2026). Shift 1 turns this discipline from a matrix that someone maintains into a check that the pipeline runs.

Principles of secure design. Saltzer and Schroeder's principles and the NCSC's secure design principles are the criteria by which a boundary is judged, and they do not depend on the technology. Complete mediation is a description of a policy point that every model call and tool call passes. Least privilege is a description of a mandate manifest (64, Saltzer & Schroeder, 1975) (70, NCSC, 2019).

Independent challenge. The control function's independence survives, as a property of the design: the challenge is built into the pipeline and the record, and the person who challenges does not author what is challenged. AI Platform and Security (Chapter 17) records the mechanism, a code-ownership rule that routes changes to its review triggers to the security architect (169, Nordqvist, 2026).

Accountable sign-off. Someone with a name and a decision right must be able to accept a risk. The signature moves from the document to the record: a decision written down, with its context, options and consequences, and an expiry for any exception. Chapter 4 gives the role a charter that states which decisions the architect owns. The sign-off stays human. What changes is how many routine decisions need one.

Practical guide: Auditing an inherited security architecture practice

Purpose. Decide, for each practice the organisation has inherited, whether to keep it, codify it, delegate it or retire it, and record the reasons, so that the transformation preserves the function of each practice and replaces only its form.

Roles. The security architect leads. The chief information security officer owns the outcome. The enterprise architect and the platform lead contribute their knowledge of the estate. Internal audit observes, so that the record satisfies the people who will later test it.

Steps.

1. Inventory the practices. List every recurring activity the architect or the architecture function performs: documents maintained, forums attended, reviews run, sign-offs given, questionnaires answered. Allow five working days. Include activities nobody remembers deciding to do.
2. State the purpose of each practice in one sentence, using the three purposes of the gate (expertise, irreversibility, accountability) and the purposes of the risk frame (traceability, ownership, evidence). A practice with no stated purpose is a candidate for retirement.
3. State the conditions the practice assumed: release frequency, the number of systems, the kind of identity that acts, the speed of the adversary. Mark each condition as still holding, partly holding or no longer holding.
4. Classify each practice. Keep it when the purpose and conditions both hold. Codify it when the purpose holds and the form is a document or a meeting that a check could carry. Delegate it when the decision is routine and a named forum, pipeline or supplier can own it with written decision rights. Retire it when the purpose is covered elsewhere or the practice has none.
5. Check every proposed retirement against the purpose. Name the control, record or forum that now covers the purpose, in a field of the record, and do not retire a practice until that field is filled.
6. Set a review date. Re-audit at least every 12 months, and after a trigger such as a new usage mode, a regulatory change or an incident. Adapt the default to the organisation's risk appetite; a regulated financial entity may shorten the interval.
7. Record the decision as an Architecture Decision Record, and take delegations to the forum that grants decision rights.

# architecture/practice-audit.yaml (illustrative)
audit: PA-2026-01
scope: security architecture practice
review_by: 2027-11-06
practices:
  - id: P-REVIEW-BOARD
    form: fortnightly review meeting for all new systems
    purpose: [expertise, irreversibility, accountability]
    conditions:
      release_frequency: no_longer_holds
      acting_identity: no_longer_holds
    disposition: delegate
    covered_by: pipeline checks and expiring exception records
    keeps_in_meeting: contested items only
  - id: P-REF-ARCH
    form: reference architecture document
    purpose: [traceability, delegation]
    conditions:
      release_frequency: partly_holds
    disposition: codify
    covered_by: containment profiles and policy as code
  - id: P-SUPPLIER-QUESTIONNAIRE
    form: annual supplier questionnaire
    purpose: [evidence]
    conditions:
      supplier_behaviour: no_longer_holds
    disposition: codify
    covered_by: supplier evidence request with expiry

Definition of done. Every practice has a stated purpose, a classification, a reviewer and a review date; every retirement names what covers its purpose; and the delegations have been approved by the forum that holds the decision right.

Worked example: Nordvik's 2024 security reference architecture assessed against the AI estate

This example is illustrative. Nordvik Region's security reference architecture, version 2024-1, was approved by the chief information security officer in 2024 and predates most of the AI estate. It lives beside, and not inside, the AI platform repository that holds the AI reference-architecture overlay (AIDR-0002). The security architect applied the audit above to it section by section and recorded the result.

Section	What it says	Why it was rational in 2024	Gap against the AI estate	Disposition
1 Principles	Least privilege, defence in depth, fail-safe defaults	Sound and technology-neutral	None	Keep
2 Network zones	Internal, DMZ and partner zones	Matched a perimeter estate with few suppliers	Reserved accelerator capacity and the AI gateway sit outside the zone model	Codify as containment profile
3 Identity and access	Staff identities and owned service accounts	Every action traced to a person	Mode 3 tools act under staff identities with no mandate; no class for agent identities	Codify, then extend
4 Data classification	Four classes with handling rules	Matched documents and databases	No routing of classes to model hosting	Codify as routing rule
5 Supplier requirements	Tender annex and questionnaire	Matched product purchases	No stop path outside the supplier's system in the annex	Keep, extend the annex
6 Logging and monitoring	Supplier-default SIEM rules	Matched a stable estate	No detections for AI gateway events	Delegate to the managed security service provider under NR-2025-044
7 Approval and exceptions	Exceptions granted by the CISO by letter	Matched few exceptions	Letters carry no expiry	Codify as expiring records
8 Hardening appendices	Product-by-product baselines	Matched a fixed product list	Out of date for most products	Retire in favour of supplier baselines referenced by version

# records/ref-arch-2024-assessment.yaml (illustrative)
assessment: RAA-NR-2026-01
document: security-reference-architecture-2024-1
decision_record: AIDR-0500
sections_assessed: 8
dispositions:
  keep: [principles, supplier_requirements]
  codify: [network_zones, identity_access, data_classification, exceptions]
  delegate: [logging_monitoring]
  retire: [hardening_appendices]
retire_requires:
  hardening_appendices: supplier baselines referenced by version
review_by: 2027-11-06

The assessment shows the practice was rational for its conditions, and that most of it is kept in some form. Two of eight sections are kept as they stand, four change medium, one changes owner and one is retired. The security architect did not discard the document. The principles in section 1 became the preamble of the role charter in Chapter 4, and the other sections became requirements on artefacts that Chapters 5 and 7 build. The record also carries a public-access consideration: because the Region's documents must survive public-access requests and archiving, the assessment states what is retained and why, and keeps information about defences out of the released version.

Nordvik Region and Hansa Mutual

Nordvik's practice was mostly documents and contracts. The post was created in 2025 from a security coordinator post, its 2024 reference architecture lives beside the AI platform repository, its controls are mapped to ISO/IEC 27001 Annex A in a spreadsheet kept for the annual management review, and its supplier requirements reach the market through tender annexes. The inherited practice was rational: a single legal regime, long procurement cycles and a small estate of suppliers made an annual cycle and a document set workable. What did not scale was a single point of failure, a reference document that nobody ran the estate against, and supplier questionnaires that aged. Nordvik keeps the principles, the tender-annex route and the statement of applicability, and codifies the rest in the order Chapters 5 to 7 set out.

Hansa's practice was mostly code with attestation around it. A Structurizr workspace models the group estate, policy as code runs on the shared platform, and the control catalogue of about 180 controls maps each control to ISO/IEC 27001, DORA and the AI Act. Evidence for many controls is still attested, and the UK and Swiss mappings are kept by local security officers outside the catalogue. The fortnightly review board was rational for seven legal regimes and for works councils and unions that expect to see how decisions are made. It is also becoming the bottleneck that the group's agents expose, because changes that agents propose daily cannot wait for a fortnightly session. Hansa keeps the board's function for contested items and delegates the routine to gates, which Chapter 17 designs.

The difference is instructive. Nordvik has to build what Hansa already has, and Hansa has to remove what Nordvik never built. Both keep traceability, the principles, independent challenge and accountable sign-off, and each keeps different parts of the practice because each started from a different one.

Summary

The security architect before the transformation worked within a coherent practice. ISO/IEC 27001 gave the risk frame and the statement of applicability, SABSA gave traceability from business attribute to component, TOGAF gave a place in the planning of change, and review boards, reference architectures and signatures gave scarce expertise, an answer to irreversibility and an accountable record. The practice was valuable and rational for its conditions: annual or quarterly cycles, a perimeter, a few hundred systems, and adversaries and insiders who worked at human speed through human identities.

It stopped scaling where those conditions changed. Release frequency outran a fortnightly board. Cloud and platform estates made the boundary a set of configurations that reference documents could not hold. Supplier ecosystems turned products into services whose questionnaires aged on return. The exploitation window fell to days, and agents with identities of their own broke the assumption that every action traces to a person. The department of no was the visible consequence of a gate used for every decision, and its reputation hides that the function of the gate, independent challenge before an irreversible commitment, remains needed.

This chapter concerned all four shifts as the baseline they depart from: the document that Shift 1, from documents to code, replaces with versioned artefacts; the gate that Shift 2, from gatekeeper to boundary designer, replaces with boundaries and delegated decision rights; the periodic cycle that Shift 3, from periodic to continuous, at machine speed, replaces with verified properties; and the sole author that Shift 4, from sole author to conductor of an AI team, replaces with an accountable conductor. The history and limits of the inherited methods are observable. The claim that gate-based review cannot keep pace with agents is expected, and Chapters 10 and 17 test it.

The transformed role inherits traceability to business risk, principles of secure design, independent challenge and accountable sign-off. The practical guide in this chapter gives a way to decide, practice by practice, what to keep, codify, delegate or retire, and the worked example shows Nordvik doing so for its reference architecture. Chapter 3 now defines the four shifts precisely, with the evidence that each is happening, what each changes in daily work, and the failure mode when each is taken too far.

Sources

1. International Organization for Standardization and International Electrotechnical Commission (2022). ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection, Information security management systems, Requirements. (23, ISO/IEC, 2022)
2. International Organization for Standardization and International Electrotechnical Commission (2022). ISO/IEC 27002:2022 Information security, cybersecurity and privacy protection, Information security controls. (24, ISO/IEC, 2022)
3. International Organization for Standardization and International Electrotechnical Commission (2022). ISO/IEC 27005:2022 Information security, cybersecurity and privacy protection, Guidance on managing information security risks. (25, ISO/IEC, 2022)
4. Sherwood, J., Clark, A. & Lynas, D. (2005). Enterprise Security Architecture: A Business-Driven Approach. (38, Sherwood et al., 2005)
5. The Open Group (2022). The TOGAF Standard, 10th Edition. (39, The Open Group, 2022)
6. The Open Group (2016). Integrating Risk and Security within a TOGAF Enterprise Architecture. (40, The Open Group, 2016)
7. Saltzer, J. H. & Schroeder, M. D. (1975). The Protection of Information in Computer Systems. (64, Saltzer & Schroeder, 1975)
8. Anderson, R. (2020). Security Engineering: A Guide to Building Dependable Distributed Systems. (65, Anderson, 2020)
9. Schneier, B. (2000). Secrets and Lies: Digital Security in a Networked World. (66, Schneier, 2000)
10. Kindervag, J. (2010). No More Chewy Centers: Introducing the Zero Trust Model of Information Security. (67, Kindervag, 2010)
11. National Cyber Security Centre (2019). Secure design principles: Guides for the design of cyber secure systems. (70, NCSC, 2019)
12. Fowler, M. (2003). Who Needs an Architect? (73, Fowler, 2003)
13. Rozanski, N. & Woods, E. (2011). Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives. (75, Rozanski & Woods, 2011)
14. Westrum, R. (2004). A typology of organisational cultures. (78, Westrum, 2004)
15. Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. (81, Forsgren et al., 2018)
16. Kim, G., Humble, J., Debois, P. & Willis, J. (2016). The DevOps Handbook. (82, Kim et al., 2016)
17. ISC2. CISSP-ISSAP: Information Systems Security Architecture Professional. (91, ISC2, n.d.)
18. European Parliament and Council of the European Union (2022). Directive (EU) 2022/2555 (NIS 2 Directive). (6, European Union, 2022)
19. European Parliament and Council of the European Union (2022). Regulation (EU) 2022/2554 (DORA). (9, European Union, 2022)
20. Charrier, C. & Weiner, R. (2024). How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends. (143, Charrier & Weiner, 2024)
21. Nordqvist, G. (2025). Architecture as Code. (167, Nordqvist, 2025)
22. Nordqvist, G. (2026). AI Governance. (168, Nordqvist, 2026)
23. Nordqvist, G. (2026). AI Platform and Security. (169, Nordqvist, 2026)
24. Nordqvist, G. (2026). AI Red Team. (170, Nordqvist, 2026)
25. Nordqvist, G. (2026). AI Threat. (171, Nordqvist, 2026)
26. Cybersecurity and Infrastructure Security Agency (2023). Zero Trust Maturity Model, Version 2.0. (37, CISA, 2023)