\cleardoublepage \part{The Role in the Organisation} \setbookpart{The Role in the Organisation}

Part IV: The Role in the Organisation

A role is defined as much by its relations as by its craft. This part places the transformed security architect in the organisation: beside the CISO, the enterprise and AI architects and the platform and product teams; in the forums and pipeline gates through which decisions are made; under the European instruments that constrain architecture and name accountable people; in front of the audiences who must understand the architecture; and in organisations that procure rather than build or that operate under many legal regimes.

The chapters apply Shift 2, from gatekeeper to boundary designer, to the organisation itself: routine decisions are delegated to pipelines and forums with written decision rights, and the architect keeps accountability for the boundaries within which they are taken. They also carry the other shifts into the organisation. Regulatory mappings, supplier requirements, overlays and generated views are versioned artefacts (Shift 1, from documents to code); decisions, reporting clocks and board indicators run continuously (Shift 3, from periodic to continuous, at machine speed); and the architect's own agents appear on the role map as tools without decision rights (Shift 4, from sole author to conductor of an AI team). The part answers the open questions of where the role ends (Q9), when an AI may change the architecture without per-action approval (Q2), what management-body accountability means for the architect (Q11) and how a single architect who procures holds boundaries in suppliers' systems (Q10).

Chapters in this part:

  • Chapter 16, The Role Map, places the security architect among the other roles and team types.
  • Chapter 17, Design Authority, Decision Forums and Gates Instead of Meetings, sets out tiered decisions, pipeline gates and expiring exceptions.
  • Chapter 18, Regulation as the Architect's Constraint, turns the AI Act, NIS 2, DORA and the CRA into engineering constraints and controls.
  • Chapter 19, Communicating Security Architecture, generates views for boards, supervisors, auditors, engineers and suppliers from the same model, catalogue and evidence.
  • Chapter 20, Public Authorities and Multinationals, covers procurement, digital sovereignty and one architecture across several jurisdictions.

What you will learn in this part:

  • How to divide work and accountability between the security architect and neighbouring roles
  • How to delegate decisions to forums and pipelines without losing accountability
  • What each European instrument expects of architecture and of named people, framed as architectural implications rather than legal advice
  • How to report architecture to different audiences from one model, and how to disclose what AI contributed

Each chapter ends with how its subject plays out at Nordvik Region and Hansa Mutual.