The Role Map: CISO, Enterprise Architect, AI Architect, Platform and Product Teams

The security architect never works alone, even in an organisation that employs only one. Every boundary the architect designs is built by one team, run by another, funded by a third and answered for by a fourth, and it holds only to the extent that those neighbours know what it is, accept it and can act on it. This chapter places the role among its neighbours: the CISO, the enterprise architect, the AI architect, the platform team, the product teams, the risk function, internal audit and the roles that the usage modes have created. It uses Team Topologies and Conway's law to explain where the role can sit, settles the seams that AI systems have opened, above all the one between the security architect and the AI architect, and ends with a responsibility assignment for the decisions that cross roles. The chapter concerns Shift 2, from gatekeeper to boundary designer, because a boundary designer needs decision rights that are written down and shared with the people who build and run the boundary, and Shift 4, from sole author to conductor of an AI team, because the architect's own agents join the map as tools without decision rights, and the architect remains the accountable verifier of what they propose. The mechanics of forums and gates belong to Chapter 17.

The role map: the security architect among the CISO, the enterprise architect, the AI architect, the platform team, product teams, risk, audit and agent operators, with four seams marked

Figure 16.1: The role map. The security architect sits between direction and challenge above, design beside and build and run below. Four seams, marked in the figure, are where decisions fall between roles unless one role owns them in writing.

A role among roles

A security architect is defined as much by the neighbours as by the mandate. Chapter 4 wrote the mandate as a role charter; a charter alone cannot say what happens at the edge of the role, because the edge is shared with someone else. The profiles that professional frameworks publish show the same limit. The European Cybersecurity Skills Framework, whose Cybersecurity Architect profile Chapter 21 treats in full, keeps that profile separate from the chief information security officer's (41, ENISA, 2022), and the NICE Framework describes security architecture as a work role with its own tasks, knowledge and skills (33, Petersen et al., 2020). Both describe what a role knows and does. Neither says who decides when two roles disagree, which is the question this chapter answers.

The literature on the architect's role points the same way. Fowler (2003) argues that the architect's value lies in identifying the important decisions and making sure they are right (73, Fowler, 2003), and Hohpe (2020) describes the architect as the person who rides the elevator between the penthouse, where strategy is set, and the engine room, where systems are built (74, Hohpe, 2020).

AI Governance, Chapter 14, drew the conclusion on which this chapter builds: the established roles keep their domains, and the AI architect owns the seams between them (168, Nordqvist, 2026). Its table of roles records what the security architect keeps, which is the threat model, identity, secrets and zero trust, and what the security architect relies on the AI architect for: AI-specific threats, guardrail policy, agent permissions and the model supply chain. That book left open where the security architect's role ends and the AI architect's, the platform engineer's and the CISO's begin once AI systems cross every architectural domain. This book answers with a rule rather than a line. A seam is a point where the work of two roles meets and a decision can fall between them. For each seam, one role proposes, one role holds the ceiling and one role operates, and a file in version control says which. This is the book's own conclusion: where two roles collide, the cause usually sits at the seam, not in either role.

The CISO and the security architect

The CISO owns the security risk strategy and answers upward for it. Under Article 20(1) of NIS 2, the management bodies of essential and important entities approve the cybersecurity risk-management measures and oversee their implementation, and can be held liable for infringements; Article 20(2) requires them to follow training that lets them assess those measures (6, European Union, 2022). DORA places the same responsibility on the management body of a financial entity in Article 5, and Article 6 requires the ICT risk-management framework to be documented and reviewed (9, European Union, 2022). ISO/IEC 27001 expects top management to assign and communicate the responsibilities and authorities of information-security roles (clause 5.3) (23, ISO/IEC, 2022). The architectural implication is that someone must be able to show how the management body's duties are discharged in design, and the CISO and the architect do that together (Chapters 18 and 19).

The division of labour between the two roles follows the difference between appetite and design. The CISO decides how much security risk the organisation carries, funds the programme and accepts residual risk at the tier the decision rules give the CISO. The architect decides where boundaries run and what holds them, within that appetite. A working test separates the two. A decision that changes a boundary without changing the risk the organisation carries belongs to the architect. A decision that changes the residual risk belongs to the CISO or to whoever the tier policy names. The architect therefore recommends an exception to a boundary but does not grant one, and the CISO does not redesign a boundary by accepting its risk without comment. Chapter 17 sets the tiers and records exceptions as expiring entries.

In both of the book's organisations the architect or the architecture team reports to the CISO. That protects independence from delivery, but the architect is easily read as the CISO's inspector, and architecture drifts from the enterprise landscape. Hansa Mutual offsets the cost with a dotted line from its group security architecture team to the group enterprise architecture function.

The risk function and internal audit

The risk function and internal audit appear on the map because the architect's output is their input. The Three Lines Model of the Institute of Internal Auditors keeps management's ownership and management of risk distinct from independent assurance, and gives internal audit independence from management so that its assurance is objective (191, Institute of Internal Auditors, 2020). Financial-sector law builds the same separation into governance. DORA Article 6(4) requires financial entities to assign responsibility for managing and overseeing ICT risk to a control function with an appropriate level of independence (9, European Union, 2022). Solvency II requires a risk-management function (Article 44) and an internal audit function that is objective and independent of the operational functions (Article 47) (19, European Union, 2009).

The consequence for the architect is a rule of conduct. The architect designs and holds boundaries and therefore cannot also assure them. The architect gives the risk function the control catalogue and its coverage, and gives internal audit read access to the evidence the pipelines produce, but never writes the audit conclusion or edits the evidence. Both functions may be consulted on design; independence requires only that they carry no responsible role in building what they later assess.

The enterprise architect and the AI architect

The enterprise architect owns the capability map, the target landscape and the standards of the estate. The enterprise-architecture literature treats this as the foundation for executing the business strategy: Ross, Weill and Robertson (2006) describe an operating model and an architecture that together give the organisation a stable base for change (72, Ross et al., 2006), and the TOGAF Standard organises the work as a method of governed iterations (39, The Open Group, 2022). The Open Group's guide on risk and security in TOGAF shows how the security viewpoint enters that method (40, The Open Group, 2016), and SABSA describes a business-driven layering of security architecture (38, Sherwood et al., 2005). The security architect's contribution to the enterprise architect's work is a set of boundary constraints stated as principles with owners, for example that no non-human identity exists without a named owner and an expiry. The seam with the enterprise architect appears when a standard and a boundary collide, such as a standardisation decision that would merge two isolation zones. The rule is that the enterprise architect owns what the standard says, and the security architect holds a veto where the standard would breach an invariant of the control catalogue. Both record the disagreement in an Architecture Decision Record, so that the rationale outlives the people who held it.

The seam with the AI architect is harder, because AI systems use every domain at once. The AI architect owns the AI Decision Records of a portfolio of use cases, applies the AI reference architecture, defines evaluation strategy and designs human oversight (AI Governance, Chapter 14) (168, Nordqvist, 2026). The security architect owns the threat model, identity, secrets and zero trust. Four seams follow from the overlap. Table 16.1 states, for each, who proposes, who holds the ceiling and who operates.

Seam Proposes Holds the ceiling Operates
1. Identity and agent permissions AI architect, in the permission manifest for each agent Security architect: the identity model, task-scoped and expiring credentials, no permission above the ceiling Platform team
2. Guardrail content and boundaries AI architect: what the guardrails check and how they are evaluated Security architect: egress, workspace isolation, and the rule that no guardrail is the only control Platform team
3. Model and skills supply chain AI architect: model choice, origin and hosting, recorded in the decision record Security architect: provenance, signing and inventory requirements Platform team, with procurement
4. Stop path AI architect: the oversight path for people Security architect: a stop path outside the system, tested, with revocation by an operator Agent operator and platform team

Table 16.1: The four seams between the security architect and the AI architect.

The columns follow one principle. Whoever knows the AI system best proposes, because the proposal depends on how models behave. Whoever knows the attacker's reach best holds the ceiling, because the ceiling must not depend on the model behaving. The platform team operates, because a boundary that is a platform property holds for every team at once. The principle rests on the conclusion of AI Platform and Security, Chapter 19, that containment must not depend on intent: instructions and guardrails lower the rate of unwanted behaviour, while task-scoped credentials, default-deny egress, protected control artefacts and an independent stop path set a ceiling on the consequences (169, Nordqvist, 2026). The security architect's rights at the seams are therefore rights over ceilings, not over content. The AI architect keeps the guardrail policy and the evaluation thresholds; the security architect keeps the requirement that those guardrails are never the only barrier, and that identity, egress and the stop path hold whatever the guardrails miss.

For the supply chain, the AI architect chooses which model and skills the platform admits, and the decision record states origin and hosting; the security architect states how admission is verified, drawing on build-provenance and inventory practice such as SLSA (51, OpenSSF, n.d.) and software bills of materials (53, NTIA, 2021). For the stop path, Article 14 of the AI Act requires high-risk systems to be designed so that natural persons can oversee them, including by deciding not to use the output and by interrupting the system (1, European Union, 2024). The AI architect designs that path for the people who oversee. The security architect requires a second path that does not depend on the system's cooperation.

Disagreements will occur. The default is that the more restrictive position stands until the tier named in the decision rules decides, and the default lapses after 30 days, so that restriction does not become a veto by delay. This is the book's own conclusion; an organisation with a different risk appetite records a different default.

Platform and product teams

Skelton and Pais (2019) distinguish four team types, stream-aligned, platform, enabling and complicated-subsystem, and three interaction modes, collaboration, X-as-a-service and facilitating, and AI Governance, Chapter 12, applied them to the AI operating model (83, Skelton & Pais, 2019) (168, Nordqvist, 2026). A stream-aligned team owns a use case from intake to production. A platform team provides the gateway, registry, evaluation service and guardrail library as a service. An enabling team helps stream-aligned teams adopt the golden path and then leaves. Control functions stand outside these types and keep their independence through gates and records.

For the security architect the useful consequence concerns where boundaries are held. A boundary that exists only because the architect reviews every design holds only where the architect looks. A boundary that is a property of the platform holds for every team on the golden path, and a team that wants to leave the path has to ask. AI Platform and Security, Chapter 8, made the same point for the delivery pipeline: the platform team owns the templates, system teams consume them and may add gates but not remove them, and the security architect owns the thresholds and the bypass list (169, Nordqvist, 2026). That is Shift 2 in organisational form. The architect moves from approving each system to owning the requirement that the platform turns into a default.

The architect's interaction modes follow the work. With the platform team the architect collaborates while a new boundary is designed, for a limited period, and then moves to X-as-a-service, in which the platform delivers the boundary and the architect checks it by test rather than by meeting. With a stream-aligned team the architect works in facilitating mode, helping it use the boundary and understand the threat model, and withdraws when the team can do so unaided. Skelton and Pais treat cognitive load as the quantity team design must protect: a review step on every release adds load, and a safe default removes a decision from the team (83, Skelton & Pais, 2019).

Two cautions apply. A platform team that also designs the controls on itself reviews its own work, so the architect keeps the requirement and the platform keeps the implementation. And the stream-aligned team keeps the accountability for its use case; the architect is accountable only for boundaries.

Enabling, embedded or platform

A security architect can be placed in three ways: as an enabling team in facilitating mode, embedded in a stream-aligned team, or as a member of the platform team. Each placement makes some boundaries easy to hold and others hard, as Table 16.2 shows.

Placement Interaction mode Makes easy Makes hard
Enabling team (a hub) Facilitating, time-boxed Consistent judgement across teams, independence from delivery, rotation and mentoring Distance from context; becoming a gate if engagements never end
Embedded in a stream-aligned team Collaboration Early involvement, deep context, fast feedback Loss of independence over time, inconsistent boundaries between streams, one architect per team does not scale
Member of the platform team X-as-a-service Boundaries become defaults for every team Conflict between delivering features and constraining them, self-review, constraints invisible to product teams

Table 16.2: Three placements for the security architect.

The enabling placement is the default this book recommends, with a named hub that reports to the CISO. Its weakness is distance, and the remedy is to embed an architect only where the risk justifies the cost: a product line whose systems are high-risk or whose agents hold write access to core systems. An embedded architect keeps the reporting line to the hub, works under the same charter and rotates after a fixed term, so that context is gained without independence being lost. The platform placement is attractive because it gives the strongest enforcement, but it merges the roles that must stay separate, designer of the requirement and builder of the implementation. The better arrangement is a standing seat for the architect in the platform team's design reviews and a written interface, rather than membership. These are the book's own conclusions from the analysis of interaction modes, not findings from a source.

Westrum (2004) described the generative culture as one in which messengers are trained, responsibilities are shared and failure leads to inquiry (78, Westrum, 2004). Placement is partly a decision about information flow: an embedded architect sees problems early but may stop passing them on, and a hub passes them on but sees them late. The test is whether the architect hears of a boundary problem from the team that has it before an incident reveals it.

Practical guide: drawing the role map for an organisation in one workshop

Purpose. Produce, in one session, a role map that shows the seams where decisions fall between roles, with one owner per seam, and commit it as a file. Roles. The security architect (facilitator), the CISO or a delegate, the enterprise architect, the AI architect where one exists, the head of the platform team, a product-team lead from a high-risk system, and a representative of the risk function as observer. Internal audit may observe but does not assign.

  1. Before the workshop, collect 15 to 20 decisions from the last twelve months that changed a boundary: decision records, exceptions, incident reviews and tender annexes. Prefer decisions that were slow or contested.
  2. At the start, list the roles in the room and write the name of the actual holder of each, including roles staffed by suppliers. A role nobody holds is itself a finding.
  3. For each decision, record who proposed it, who decided it, who did the work and who was surprised. The surprised column marks the seams.
  4. Cluster the decisions by seam. Keep every seam where two roles each believed the other owned the decision, or both believed they owned it.
  5. For each kept seam, name the role that proposes, the role that holds the ceiling and the role that operates, and name exactly one accountable role.
  6. For each stream-aligned team that the architect serves, choose the placement of Table 16.2, the interaction mode and a time limit for the engagement.
  7. Write the result as a YAML file in the architecture repository, as in the worked examples below. Open a pull request, and have the CISO and the AI architect approve it.
  8. Test the file against five further decisions that the workshop did not discuss. A decision that the file cannot route is a gap, and the file is amended before it is merged.

Defaults. Allow two hours; use the last twelve months as the window; review the file every six months, when a new usage mode is adopted and when the organisation restructures. Adapt these to the pace of change and the risk appetite of the organisation.

Definition of done. Every seam has one accountable role and a named proposer, ceiling-holder and operator; every decision in the test set routes to a role; the file is merged by pull request; the next review date is recorded.

Conway's law and boundaries

Conway (1968) observed that organisations that design systems produce designs that copy their own communication structures (77, Conway, 1968). Architecture as Code (Chapter 18) applied the observation to team structure, and AI Governance, Chapter 12, to AI (167, Nordqvist, 2025) (168, Nordqvist, 2026). The security reading is direct. A trust boundary in a system will follow the organisation chart unless someone designs otherwise, and it fails where the chart has a seam. Brooks (1995) showed that the number of communication paths among n people grows as n(n−1)/2 (76, Brooks, 1995). A team of six architects has fifteen pairs, and every additional role with a vote on a boundary adds paths along which a decision can be lost.

Four organisational seams recur as security seams in the book's two organisations. The first lies between the platform team and the product teams: when each product team configures its own guardrails, boundaries differ team by team. The second lies between the organisation and a supplier. Where a supplier builds and runs a system, the contract is the boundary, and what the contract does not say is not held. The third lies between legal entities and countries, where the same control must satisfy several regimes and an architect in one country cannot see the decisions of another. The fourth lies between the people who design a stop path and the people who must use it at three in the morning, which is where the stop path tends to have no owner.

Skelton and Pais call the remedy the inverse Conway manoeuvre: shape the teams so that the architecture the organisation wants is the one its communication structure naturally produces (83, Skelton & Pais, 2019). The architect has four practical ways to apply it.

  • Give every boundary one owner team. The boundary inventory of Chapter 7 and the role map must agree, and a validation job fails when a boundary has no owner in the map or a seam has no accountable role. An orphan boundary is an incident waiting for a reorganisation.
  • Publish the interface at each seam. The platform team publishes the guardrail interface and its tests, so that product teams depend on a contract and not on a conversation.
  • Test at the seams. Exercises and security chaos experiments that cross an organisational seam find the failures that tests inside one team cannot (AI Red Team, Chapters 25 and 26) (170, Nordqvist, 2026).
  • Keep the number of voting roles small. A boundary decision with three consulted roles is cheaper than one with seven, and the RACI below limits consultation to roles whose input changes the outcome.

For Shift 2 this means designing the organisation's seams as deliberately as the system's boundaries.

New neighbours from the usage modes

The usage modes created work that no existing role owned, and AI Governance, Chapter 14, named four roles that follow from them (168, Nordqvist, 2026). Each becomes a neighbour of the security architect.

The AI system owner is the accountable person for one system in use. Article 26 of the AI Act gives the deployer of a high-risk system duties that someone must be able to show were met, among them assigning human oversight to persons with the necessary competence, training and authority (Article 26(2)) (1, European Union, 2024). The architect gives the owner a boundary profile in plain terms, what the system may reach and what stops it, and the owner accepts the residual risk at the tier the decision rules give the owner.

The agent operator runs Mode 5 agents in production, watches the agent's delegated actions, works the approval queue and may revoke the agent's credentials. The architect designs for this neighbour in three ways. Revocation of an agent's identity is one action and takes effect within minutes, which the operator tests at least quarterly, as AI Threat, Chapter 30, recommends for agents with write access (171, Nordqvist, 2026). The operator's tools do not depend on the agent's cooperation or on the agent's own logs alone. And the right to stop is cheaper to exercise than the right to continue: the operator need not ask permission to halt an agent, and an unnecessary halt is reviewed without blame.

The skills curator owns the governed catalogue of skills, the packaged instructions and resources that agents and agentic work tools load on demand (118, Anthropic, 2025) (168, Nordqvist, 2026). The architect depends on this neighbour more than most, because the architect's own Mode 3 tools load skills from the same catalogue (Chapter 12). The seam is a split of ceilings: the curator owns the quality, ownership and retirement of skills, and the architect owns the permission ceiling that no skill may exceed, whatever it requests.

The evaluation engineer maintains the evaluation sets and thresholds that gate each release. The architect relies on these results as evidence that guardrails and containment behave as designed, and does not set the thresholds, which belong to model risk. The separation matters because the person who tuned a control to pass a test is the wrong person to declare that it passed.

Existing roles change as well: procurement officers write security annexes (Chapter 20), internal auditors sample pipeline evidence, and the data protection officer acts independently under Article 38(3) of the GDPR and must not be placed where a conflict of interest arises (Article 38(6)) (5, European Union, 2016). The architect consults the data protection officer on logging and retention but never instructs the officer on the outcome.

The architect's own agents on the map

The architect's own agents belong on the map as tools, not as roles. Chapter 13 describes an agent team of reviewer, threat modeller, policy author, evidence collector and researcher, each under a mandate manifest. In the role map those agents hold no decision rights. A RACI cell never names an agent as accountable; an agent may be responsible for drafting, and a named architect is accountable for what is approved. A boundary change that an agent proposes follows the same route as one that a person proposes, and the map names the person who verifies it (Chapter 14). This is Shift 4 in the role map: the conductor of an AI team is a person with a seat in the map, and the team is invisible to every seam except through that person.

Across the usage modes

The mode determines which neighbours appear and which seam moves. Table 16.3 gives the pattern.

Usage mode Neighbour added or changed What the architect designs for or with them
Mode 0 Ambient AI Procurement, owners of affected applications A register of supplier-enabled features and security annexes that require notice of change
Mode 1 Conversational assistants Data protection officer, data classification owner Acceptable-use boundaries and tenant configuration
Mode 2 Embedded workplace assistants Digital workplace team Permission hygiene and sensitivity labelling in the office estate
Mode 3 Agentic work tools Platform team, skills curator Sandbox, permission ceiling and skills admission (seams 1 and 3), including for the architect's own tools
Mode 4 Built AI applications AI system owner, AI architect, evaluation engineer, product team Seams 1 to 3 in the design of each system
Mode 5 Autonomous production agents Agent operator, platform team, SOC Seam 4: independent stop path, revocation, quarterly drills

Table 16.3: Neighbours by usage mode.

In Modes 1 to 3 a person's identity acts and a person reviews, so the neighbours are mostly literacy and tooling owners. In Modes 4 and 5, and in the automatic features of Mode 0, an identity that is not a person's acts, and the neighbours must include someone who can stop it. The architect's design work moves from guidance for people to ceilings for identities.

Observable, expected, speculation

Observable: the AI Act already requires providers to design high-risk systems for interruption (Article 14) and deployers to assign oversight to persons with the competence, training and authority it needs (Article 26(2)) (1, European Union, 2024), which is the work the new roles above take up; the roles themselves are the conclusion of AI Governance, Chapter 14, on which this section builds (168, Nordqvist, 2026). Expected: supervisors will ask who may stop a system, and role descriptions that name the stop right will follow. Speculation: that the roles of security architect and AI architect converge in organisations that run many agents is a scenario that Chapter 23 examines; this chapter treats the roles as separate, with a documented seam between them.

A RACI for cross-role decisions

A responsibility assignment gives each decision one accountable role and names who does the work, who is consulted and who is informed. AI Governance, Chapter 12, used one for the lifecycle of an AI system (168, Nordqvist, 2026). The matrix here covers the decisions that cross roles in security architecture: changing a boundary, granting an exception, setting an agent's permission ceiling and autonomy level, changing guardrail policy, admitting a model, setting supplier security requirements, and stopping and restarting a system. Four rules govern it.

  1. One accountable role per decision. A decision with two accountable roles has none. The file's validation fails when it finds two.
  2. A veto is not an accountability. The security architect may hold a veto over a ceiling without being accountable for the whole decision. The file records vetoes separately, so that the veto is visible and its scope is bounded.
  3. Independent functions are never responsible for building. Internal audit and model risk appear as consulted or informed, or as accountable for their own judgements, never as responsible for the work they later assess.
  4. Agents are never accountable. An agent may be responsible for drafting a change; a named role is accountable for approving it.

The stop decision breaks the symmetry on purpose. Anyone on the operator rota, the platform on-call and the security operations centre may stop a system and need not ask; restarting needs the system owner, with the architect consulted. The asymmetry makes the safe action cheap and the unsafe one deliberate.

Worked example: a RACI as code for cross-role decisions at Hansa Mutual

Illustrative example. Hansa Mutual's group security architecture team keeps the file below in the group architecture repository. The tier at which each decision is taken is set in the tier policy of Chapter 17; this file says who holds each role once a decision has a tier.

# roles/decision-rights.yaml (Hansa Mutual, illustrative)
version: "2026.4"
roles: [ai_domain_architect, claims_architect, psc_architect, ai_architect,
        platform_team, agent_operator, evaluation_engineer, system_owner,
        group_ciso, model_risk, procurement, internal_audit]
decisions:
  boundary_change:
    A: ai_domain_architect
    R: platform_team
    C: [ai_architect, system_owner]
    I: [model_risk]
  boundary_exception:
    A: group_ciso
    R: system_owner
    C: [ai_domain_architect, model_risk]
    I: [internal_audit]
    expires_days: 90
  agent_permission_ceiling:
    A: ai_domain_architect
    R: ai_architect
    C: [platform_team, agent_operator]
    veto: [ai_domain_architect]
  agent_autonomy_level:
    A: system_owner
    R: ai_architect
    C: [ai_domain_architect, agent_operator, model_risk]
    veto: [ai_domain_architect]
    escalate_above_level_2: group_ai_governance_board
    level_4_irreversible: forbidden
  guardrail_policy_content:
    A: ai_architect
    R: evaluation_engineer
    C: [ai_domain_architect, platform_team]
  guardrail_implementation:
    A: platform_team
    decision_record: AIDR-0557
    C: [ai_architect, ai_domain_architect]
  model_admission:
    A: ai_architect
    R: platform_team
    C: [ai_domain_architect, procurement]
    veto: [ai_domain_architect]
    veto_scope: provenance_and_inventory_only
  supplier_security_requirements:
    A: ai_domain_architect
    R: procurement
    C: [model_risk]
  stop_activation:
    who_may_act: [agent_operator, platform_oncall, group_soc]
    approval_required: false
  stop_release:
    A: system_owner
    C: [ai_domain_architect, agent_operator]
validation:
  one_accountable_per_decision: true
  never_responsible_for_build: [internal_audit, model_risk]
  agents_accountable: false

Three features of the file settle the seam between the AI domain architect and the AI architects. The AI domain architect is accountable for the permission ceiling and holds a veto over autonomy levels and over model admission when provenance or inventory fails, and holds no right over guardrail content or evaluation thresholds. The AI architects are accountable for guardrail content and model choice and hold no right over identity or egress. The platform team is accountable for guardrail implementation, recorded as AIDR-0557, which is the answer to the question of who owns the guardrails that the architects design. Because the file names roles, not persons, a change of staff does not change it, and a change to it goes through a pull request. The review agents of Chapter 13 read it to route proposals to the accountable role.

Worked example: Nordvik Region's role map for a single security architect

Illustrative example. Nordvik Region has one security architect, one enterprise architect in the digitalisation unit, one AI architect and a platform team of a handful of engineers, with the CISO above them. The security architect keeps the map in roles/role-map.yaml in the architecture repository, written so that it survives public-access requests and archiving.

# roles/role-map.yaml (Nordvik Region, illustrative)
placement:
  role: security_architect
  unit: security unit
  reports_to: ciso
  mode: enabling
  backup_for_review: enterprise_architect
neighbours:
  enterprise_architect: {interaction: collaboration, role: peer review of tender annexes}
  ai_architect: {interaction: collaboration, owns: [ai_decision_records, guardrail_policy]}
  platform_team: {interaction: x-as-a-service, owns: [reserved_capacity, ai_gateway, mode_3_tools]}
  head_of_benefits_unit: {role: system owner, system: benefits-triage}
  managed_security_provider: {contract: NR-2025-044}
seams:
  - {id: identity_and_agent_permissions, proposes: ai_architect, holds: security_architect, operates: platform_team}
  - {id: guardrail_and_boundary, proposes: ai_architect, holds: security_architect, operates: platform_team}
  - {id: supply_chain, proposes: ai_architect, holds: security_architect, operates: platform_team}
  - {id: stop_path, proposes: ai_architect, holds: security_architect, operates: platform_oncall}
no_agent_operators: true
stop_cover: platform_oncall

The security architect keeps the identity, egress and stop-path requirements and writes them into tender annexes for suppliers such as TriageSoft, so that a stop path outside the supplier's system is a contractual requirement (AI Threat, Chapter 24) (171, Nordqvist, 2026). The AI architect owns the AI Decision Records of the AI estate and the guardrail policy. The Region has no agent operators and no Mode 5 agents, and the platform team runs its Mode 3 tools, including the security architect's own under MND-NR-01 (Chapter 12), so the platform on-call covers the stop right and the file records that choice. The map also records that the single architect is a single point of failure: the enterprise architect covers review when the architect is absent, and the CISO holds the accountability for any boundary exception.

Nordvik Region and Hansa Mutual

At Nordvik the role map is small and personal. Writing it clarified that the AI architect owns guardrail policy and the security architect owns identity, egress and stop-path requirements, a division that existed in practice but not on paper. The seams are held mostly through procurement, because suppliers build and run most systems, and the map shows where the architect has no neighbour to consult: the same person proposes, holds and checks unless the enterprise architect or the CISO steps in.

At Hansa the map settles the seam between the AI domain security architect and the AI architects, and records the platform team as owner of the guardrails the architects design (AIDR-0557). It also shows the limit of the fortnightly review board: a seam that needs a decision daily cannot wait for a fortnightly meeting, which Chapter 17 takes up. The difference follows from what each does: Nordvik buys and holds boundaries through contracts, Hansa builds and holds them through the platform.

Summary

The security architect is defined as much by neighbours as by mandate. The CISO owns risk appetite and its acceptance, the architect owns where boundaries run and what holds them, and the risk function and internal audit challenge and assure without sharing in the design. The enterprise architect owns the standard and the AI architect owns the AI system's decisions, and the security architect holds the ceilings on identity, egress and the stop path. This is the book's answer to the open question of where the roles end: they meet at four seams, and each seam has one role that proposes, one that holds the ceiling and one that operates.

Team Topologies and Conway's law explain why placement matters. A boundary held by the platform holds for every team, a boundary held by review holds where the architect looks, and the organisational seams between platform and product, organisation and supplier, entity and country, and designer and stop-path user become the security seams of the system. The recommended placement is an enabling hub reporting to the CISO, with embedded architects only where the risk justifies them.

The chapter concerns Shift 2, from gatekeeper to boundary designer, because the architect moves from deciding at gates to owning ceilings, seams and written decision rights that the platform turns into defaults. It also concerns Shift 4, from sole author to conductor of an AI team, because the architect's own agents appear on the map only as tools, with no accountable cell, and the usage modes add the AI system owner, the agent operator, the skills curator and the evaluation engineer as neighbours the architect designs for. The RACI as code makes both visible and testable.

Chapter 17 takes the next step. A role map says who holds each decision; the design authority, the tier policy and the pipeline gates determine how quickly decisions are taken and when they need a meeting.

Sources

  1. European Parliament and Council of the European Union (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (1, European Union, 2024)
  2. European Parliament and Council of the European Union (2016). Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). (5, European Union, 2016)
  3. European Parliament and Council of the 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)
  4. European Parliament and Council of the European Union (2022). Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (9, European Union, 2022)
  5. European Parliament and Council of the European Union (2009). Directive 2009/138/EC on the taking-up and pursuit of the business of Insurance and Reinsurance (Solvency II). (19, European Union, 2009)
  6. 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)
  7. Petersen, R., Santos, D., Wetzel, K. A., Smith, M. C. & Witte, G. (2020). Workforce Framework for Cybersecurity (NICE Framework). (33, Petersen et al., 2020)
  8. Sherwood, J., Clark, A. & Lynas, D. (2005). Enterprise Security Architecture: A Business-Driven Approach. (38, Sherwood et al., 2005)
  9. The Open Group (2022). The TOGAF Standard, 10th Edition. (39, The Open Group, 2022)
  10. The Open Group (2016). Integrating Risk and Security within a TOGAF Enterprise Architecture. (40, The Open Group, 2016)
  11. European Union Agency for Cybersecurity (2022). European Cybersecurity Skills Framework (ECSF): Role profiles. (41, ENISA, 2022)
  12. Open Source Security Foundation. Supply-chain Levels for Software Artifacts (SLSA). (51, OpenSSF, n.d.)
  13. NTIA (2021). The Minimum Elements For a Software Bill of Materials (SBOM). (53, NTIA, 2021)
  14. Ross, J. W., Weill, P. & Robertson, D. C. (2006). Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. (72, Ross et al., 2006)
  15. Fowler, M. (2003). Who Needs an Architect? (73, Fowler, 2003)
  16. Hohpe, G. (2020). The Software Architect Elevator: Redefining the Architect's Role in the Digital Enterprise. (74, Hohpe, 2020)
  17. Brooks, F. P. (1995). The Mythical Man-Month: Essays on Software Engineering. (76, Brooks, 1995)
  18. Conway, M. E. (1968). How Do Committees Invent? (77, Conway, 1968)
  19. Westrum, R. (2004). A typology of organisational cultures. (78, Westrum, 2004)
  20. Skelton, M. & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. (83, Skelton & Pais, 2019)
  21. Anthropic (2025). Introducing Agent Skills. (118, Anthropic, 2025)
  22. Nordqvist, G. (2025). Architecture as Code. (167, Nordqvist, 2025)
  23. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (168, Nordqvist, 2026)
  24. Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (169, Nordqvist, 2026)
  25. Nordqvist, G. (2026). AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. (170, Nordqvist, 2026)
  26. Nordqvist, G. (2026). AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. (171, Nordqvist, 2026)
  27. Institute of Internal Auditors (2020). The IIA's Three Lines Model: An update of the Three Lines of Defense. (191, Institute of Internal Auditors, 2020)