Every conclusion in the earlier volumes ends in a control, built in four different books and living in four different places, and someone has to say which threat each answers, which obligation each helps to meet and whether it works today. This chapter argues that this someone is the security architect, working through three artefacts: the control catalogue, the evidence manifest and the assurance relationship with the people who test the architect's work. It concerns Shift 1, from documents to code, because the catalogue, the mappings and the evidence are versioned and testable instead of living in a spreadsheet and a folder of screenshots, and Shift 3, from periodic to continuous, at machine speed, because a control verified once a year is declared for the other 364 days, while agents now change the estate daily.
In many organisations nobody does: controls are described in policies, implemented by platform teams, listed in a spreadsheet and evidenced by screenshots collected when an audit is announced. Three connections need an owner: from threat to control, through the threat models of Chapter 6; from control to boundary, through the containment profiles and permission manifests of Chapters 7 and 8; and from control to obligation, because ISO/IEC 27001 Annex A, NIS 2, DORA, the AI Act and national schemes each ask for measures the catalogue must show to be in place (23, ISO/IEC, 2022). The architect does not operate the controls; platform and operations teams do, and named system owners answer for each system. What the architect owns is the catalogue's structure, the quality of each entry and the correctness of each mapping. That ownership has a limit, however: an architect who designs a control and also declares that it works marks their own work, so the judgement that a control is effective is left to a test and, above that, to people independent of the architect.
A control entry is complete when a stranger can tell from it alone what the control does, who is accountable, where it is implemented, how it is tested and where the proof is. The fields are these.
Primary topics explored
- Why the catalogue is the architect's artefact
- Anatomy of a control entry
- Mapping once to many obligations
- Evidence as a by-product
- Verified, declared and failed
- Coverage against threats
About The Transformed Security Architect
The Transformed Security Architect is Book 6 of The Transformed Architecture. It describes how the security architect role is transformed when architecture is code, when AI drafts and acts, and when adversaries move at machine speed: the craft, the architect's own AI team, the role in the organisation, the competences and the career, for European enterprises and public authorities.
It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team and AI Threat.
Security architects, CISOs and heads of security architecture, enterprise, solution and AI architects, engineering leads, competence and hiring leads, procurement and programme leaders, and risk, compliance and audit.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 9: The Control Catalogue, Evidence and Assurance as the Architect's Artefacts in The Transformed Security Architect gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Craft” and is one of 31 drawn from the manuscript.