A regulation reaches the blue team in two ways. It sets a duty on the organisation, and it sets a clock, a record and a named person that the team's design must supply. This chapter treats regulation as a constraint on that design. It maps the instruments that bear on detection, investigation and response, lays the reporting clocks of one incident side by side, shows what the logs, case records and decision records must hold so that a regulator can be answered without reconstruction, and explains what the duties of the management body leave a SOC lead free to delegate. It then turns to the rules on employee data in security monitoring and to the position under the AI Act of the AI in the SOC. It concerns B3 Investigate, because the clocks start from what the investigation establishes, B4 Respond, because communication and reporting are part of response, and B5 Learn, because the implementing regulation under NIS 2 asks the providers it names for post-incident reviews that identify root cause and produce lessons with owners. Every statement of law is attributed to its instrument and article and framed as an organisational and architectural implication. None of it is legal advice.
The chapter builds on three earlier conclusions. AI Platform and Security, Chapters 17 and 21, concluded that the reporting deadlines of NIS 2, the AI Act, DORA and the Cyber Resilience Act are design constraints on the logs, and that AI incident management needs an extra classification step and an impact query against the event log (63, Nordqvist, 2026). The Transformed Security Architect, Chapter 18, concluded that European regulation places duties on named people and management bodies, that someone must turn each article into a control, and that accountability cannot be delegated to a system (66, Nordqvist, 2026). AI Governance, Chapter 13, concluded that governance as code leaves the forums with what pipelines cannot decide: appetite, policy, exceptions and residual risk (62, Nordqvist, 2026). This chapter carries them into the SOC.
The instruments differ in who they address, which incidents they cover and how they count time, and a team that treats them as one "compliance" duty will build one clock where it needs several. The right-hand column of the table is the design requirement; the left-hand column is where it comes from.
Primary topics explored
- A map of obligations
- The reporting clock
- Evidence by design
- The management body
- Employee data in monitoring
- The AI Act and the SOC's AI
About AI Blue
AI Blue is Book 8 of The Transformed Architecture. It examines how the blue team, the people and functions that defend an organisation, is transformed when artificial intelligence takes part in their work: anticipating, detecting, investigating, responding and learning, the team's own AI and how to verify and protect it, operating models, roles, decision rights, regulation and measurement, and the careers and wellbeing of the people involved, for European enterprises and public authorities.
It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect and AI Boss.
Chief information security officers, heads of security operations, SOC managers, analysts, detection engineers and incident commanders, security and AI architects, boards and management bodies, procurement leads, works councils and unions, data protection and audit functions, and public-sector leaders.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 19: Regulation as Constraint: NIS 2, DORA, CRA, GDPR, the AI Act and the Reporting Clock in AI Blue gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Team in the Organisation” and is one of 32 drawn from the manuscript.