Regulation as Constraint: NIS 2, DORA, CRA, GDPR, the AI Act and the Reporting Clock

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.

One incident, four reporting clocks: the timeline from awareness to final report with the owners marked

Figure 19.1: One incident, four reporting clocks: the timeline from awareness to final report with the owners marked.

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.

A map of obligations

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.

Instrument and article Who is addressed What the blue team must be able to show
NIS 2, Article 20 (3, European Union, 2022) The management bodies of essential and important entities That the body approved the cybersecurity risk-management measures, oversaw them and was trained
NIS 2, Article 21 The entity Incident handling among the risk-management measures, including supply chain security, in proportion to risk
NIS 2, Article 23 The entity An early warning, an incident notification and a final report for each significant incident, each with its facts and its sender
Implementing Regulation (EU) 2024/2690 (4, European Commission, 2024) Defined digital infrastructure and ICT service management providers, among them managed security service providers Documented incident response procedures, logging of response activities, communication plans with the CSIRT and post-incident reviews
DORA, Article 5 (2, European Union, 2022) The management body of a financial entity Approval, oversight and accountability for the ICT risk management framework
DORA, Articles 17 to 19 The financial entity Incident management, classification and reporting of major ICT-related incidents; third-party providers recorded in the register of information
Regulation (EU) 2024/2847, Article 14 (5, European Union, 2024) Manufacturers of products with digital elements Reports of actively exploited vulnerabilities and severe incidents to the designated bodies
GDPR, Articles 33 and 34 (8, European Union, 2016) The controller Notification of the supervisory authority and, where the risk is high, of the people affected
GDPR, Articles 32 and 88 The controller Security of processing, the principles of purpose limitation and minimisation in monitoring, and the national rules on employee data
AI Act, Articles 4, 14, 26 and 73 (1, European Union, 2024) Providers and deployers of AI systems AI literacy, competent human oversight, deployer duties and serious incident reporting for high-risk systems
Cyber Solidarity Act (80, European Union, 2025) Member states and Union bodies A Union framework for detection and response, which the team meets as a channel for information and, in some cases, support

Three points about the map shape what follows. First, an entity can sit under several rows at once. A financial entity is under DORA for its ICT incidents and under the GDPR for the personal data in them, and DORA is the primary regime for a financial entity where NIS 2 might otherwise also apply; which instrument governs which duty for a given entity is for its legal function. Second, the rows differ in what starts the clock. A significant incident, a major ICT-related incident, a personal data breach, an actively exploited vulnerability and a serious incident involving a high-risk AI system are five different tests applied to the same facts. Third, the rows are not equally settled. NIS 2, DORA and the GDPR are in force and applied, and amendments to the timetable and reporting channels of several instruments are under discussion at Union level. The register therefore records, for each limit, the version of the instrument and technical standard in force, and the overlay that holds it is a reviewed file.

The team does not need to master the law. It needs a register that says, for each legal entity and each system, which tests apply, who owns each, and what the case record must contain for each test to be applied quickly. In the SOC the owner of that translation is the person with reporting authority, and the rest of this chapter describes what that person needs from the team.

The reporting clock

The reporting clock is the interval between the moment an organisation is regarded as aware of an incident and the moment each notification is due. The principle of this chapter is that a clock is a requirement on the case record and the decision rights, not a paragraph in a policy. A design makes the time visible to the people who can act on it, at the moment it starts.

Four clocks, one incident

An incident that touches personal data in a financial entity's systems and runs through a vendor's product can open four clocks at once.

  • NIS 2, Article 23. An entity within scope sends an early warning of a significant incident within 24 hours of becoming aware of it, an incident notification within 72 hours and a final report within one month (3, European Union, 2022). The early warning says whether an unlawful or malicious act is suspected and whether the incident could have cross-border impact; the later reports add assessment and root cause.
  • DORA, Articles 17 to 19. A financial entity classifies incidents and reports the major ones to its competent authority in an initial notification, an intermediate report and a final report (2, European Union, 2022). The time limits and classification criteria sit in technical standards adopted under the Regulation and are set from the moment of awareness and from the classification as major, so the profile holds two timers for the clock and takes the earlier. The numbers belong in the market overlay, taken from the standards in force, and not in this book.
  • GDPR, Article 33. A controller notifies the supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it (8, European Union, 2016). Article 34 adds communication to the people affected, without undue delay, where the breach is likely to result in a high risk to them.
  • Regulation (EU) 2024/2847, Article 14. A manufacturer of a product with digital elements reports an actively exploited vulnerability, or a severe incident that affects the security of the product, in an early warning, a notification and a final report on timings set by the Regulation (5, European Union, 2024). Neither Nordvik Region nor Hansa Mutual is a manufacturer of what it runs. The duty matters to the SOC as a source: suppliers' reports feed the exposure work of B1 Anticipate.

A fifth test belongs to incidents involving a high-risk AI system. The provider reports a serious incident to the market surveillance authority under Article 73 of the AI Act, within the time the Article sets, and a deployer informs the provider and, in the cases the Act names, the authorities under Article 26 (1, European Union, 2024). The architectural point is the one AI Platform and Security drew: the SOC needs an AI classification step in its triage, so that an event touching a high-risk system is recognised as such in the first hour and not on the third day.

The clocks start at different moments and are owned by different people. The NIS 2 and DORA clocks run on the entity's awareness and classification of a significant or major incident, the GDPR clock from the controller's awareness that personal data has been compromised, and the vendor's duty from the manufacturer's awareness. A single incident ticket with a single "reported" flag cannot carry this. The case record needs one clock per regime, each with its own start, limit, owner and state.

What awareness is

Every clock starts at awareness, and awareness is a fact the case record must be able to show. The European Data Protection Board's guidelines are the most careful treatment of it. They regard a controller as aware when it has a reasonable degree of certainty that a security incident has occurred that led to personal data being compromised, and they accept that a short period of initial investigation to establish whether a breach has occurred does not by itself make the controller aware, provided the investigation begins as soon as possible (79, EDPB, 2023). Two consequences follow for a SOC whose triage is partly done by AI.

The first is that the architecture should not try to settle whether an AI system's flag counts as awareness; that is for counsel and the supervisor, and the answer may differ between regimes. The second is that the architecture can make the question answerable. The case record keeps both moments, the time a system first flagged the event and the time a person confirmed it, as Chapters 8 and 10 set out. A team with both timestamps can answer however the question is decided. A team with one cannot. A conservative default follows from the cost of error: open every clock that could apply at the earlier of the two moments, and close the ones that do not apply, with a reason, once the classification is made. A clock opened and closed costs a few minutes of the reporting authority's attention; a clock opened late can mean a breached duty.

Classification is the hard part

The clock does not start at "an incident" but at a significant, major or notifiable one, and deciding which is a judgement. The implementing regulation under NIS 2 lists criteria that a classification procedure should weigh, and ENISA's guidance on it adds examples such as the impact on business operations, the sensitivity of the data, the scope and scale, the criticality of the systems affected, the potential for data exfiltration and the legal and regulatory impact, including the reporting timelines of the GDPR and national rules (7, ENISA, 2025). Classification is therefore an AC-4-adjacent act in the language of Chapter 10: it commits the organisation to an external statement. The team should treat it that way. An AI system may assemble the criteria and the evidence for each, and may draft the reasoning, at Level 1 Assisted. A named person with reporting authority classifies, and the case record states who.

Practical guide: Building the incident clock

Purpose. Give every incident a set of clocks that starts at the right moment, has an owner who can be reached and can be shown to a regulator afterwards. Roles. The reporting authority (the person who may classify and sign a notification), the incident commander, the data protection officer, the SOC lead, the detection engineer who maintains the clock rules, and, where staff are affected, the employee representative who agreed the logging.

  1. List the regimes per legal entity. For each entity and each system, record which of the tests in the map apply, and which authority or CSIRT receives the report. Hansa Mutual keeps this per market overlay; Nordvik keeps one national list.
  2. Fix the awareness moments. Define which events write first_flag_at (a detection fired, a provider's page received) and which write human_confirmed_at (a named analyst confirmed). Both are written by the case system, not typed.
  3. Open the clocks at the earlier moment. On the first flag of an incident-class event, the case system opens every clock that could apply and computes its due time from the start rule. Opening is a deterministic rule of the case system and not an action of an AI agent.
  4. Name an owner and a deputy for each clock, and check they can be reached. Out of hours, the owner is a person on a roster, not a role in a diagram. The default is a classification checkpoint two hours after confirmation. Adapt it to the shortest clock in the entity's register.
  5. Prepare the drafts. Keep a template for each notification with fields filled from the case record. The AI drafts at Level 1 Assisted, cites the record entries it relies on, and a person checks each statement of fact before a person sends.
  6. Close with reasons. A clock that does not apply is closed with the classification, the time and the name. The closed clocks are part of the evidence.
  7. Rehearse. Run a tabletop each quarter that uses the real timestamps of a closed case, and measure the time from confirmation to a checked draft.

Definition of done. For any incident-class case the record shows, within minutes of confirmation, which clocks are open, who owns each, when each is due, and the two awareness timestamps. A rehearsal has produced a checked draft inside the shortest limit with the roster as it stands on a Saturday night.

The following table is the skeleton the guide produces. The figures for NIS 2 and the GDPR are those given above; the other limits are set by the instrument or its technical standard and are configured in the overlay.

Clock Starts at First limit Later steps Addressee Owner
NIS 2 Article 23 Awareness of a significant incident 24 hours Notification at 72 hours, final report within one month National CSIRT or competent authority Reporting authority
DORA Articles 17 to 19 Classification as major, and awareness Set by the technical standards; the earlier of two timers Intermediate and final reports Financial supervisor Reporting authority
GDPR Article 33 Awareness that personal data was compromised 72 hours Staged information; Article 34 to people at high risk Supervisory authority and affected people Data protection officer
Regulation (EU) 2024/2847, Article 14 Manufacturer's awareness Set by the Regulation Notification and final report Designated bodies Product security lead
AI Act Article 73 Provider's awareness of a serious incident Set by the Article Follow-up report Market surveillance authority AI system provider; deployer informs

Worked example: A reporting-clock profile

The following profile is illustrative. It is the configuration CLK-HM-01, which the group SOC of Hansa Mutual adopted under AIDR-0777 on 2027-06-24, applied afterwards to the case record of incident INC-HM-2027-0455 (Chapters 10 and 11): the April clocks are reconstructed from that record, not generated on the night. The times are in Central European Summer Time. The profile opened the clocks at the first flag and closed them after classification, because the activity was assessed as a legitimate rollout step of the scheduler migration CHG-PL-2291 and no compromise of personal data was established. The limit of the DORA clock is per_instrument: the overlay supplies it from the technical standards.

clock_profile: CLK-HM-01
decision_record: AIDR-0777
incident: INC-HM-2027-0455
case_record: CASE-HM-0455
timestamps:
  first_flag_at: "2027-04-12T02:14:05+02:00"
  human_confirmed_at: "2027-04-12T02:16:40+02:00"
  start_rule: earlier_of_the_two
  opened_at: "2027-04-12T02:14:05+02:00"
clocks:
  - id: dora-initial
    basis: "DORA Articles 17 to 19"
    applies_if: classified_major
    timers:
      - {from: awareness, limit: per_instrument}
      - {from: classification, limit: per_instrument}
    due: earlier_of_timers
    owner: reporting-authority
    draft: ai_level_1
    send: human
  - id: nis2-early-warning
    basis: "NIS 2 Article 23"
    applies_if: entity_in_nis2_scope   # decided per entity by the group's legal function
    limit_hours: 24
    due: "2027-04-13T02:14:05+02:00"
    owner: reporting-authority
    draft: ai_level_1
    send: human
  - id: gdpr-authority
    basis: "GDPR Article 33"
    applies_if: personal_data_compromise_established
    start_rule: when_compromise_established
    limit_hours: 72
    due: null
    owner: data-protection-officer
    draft: ai_level_1
    send: human
checkpoint:
  classify_by: "2027-04-12T04:16:40+02:00"
outcome:
  classified_by: reporting-authority
  classified_at: "2027-04-12T03:40:00+02:00"
  classification: not_major
  personal_data_compromise_established: false
  impact_noted: "the second isolation interrupted a settlement run for a Norwegian claims batch; released at 02:22:15"
  clocks_closed: [dora-initial, nis2-early-warning, gdpr-authority]
  reviewed_in: PIR-HM-0455

Three design choices are visible. The clocks open and the due times are counted from the first flag, so that the record never claims more time than the conservative reading allows. The GDPR clock has its own start rule, because its test is the establishment of a compromise of personal data and not the first alert. And the outcome records the side effect of the containment itself, the interrupted settlement run, because the operational impact of a response action is part of what classification weighs.

Evidence by design

A regulator, a supervisor or an auditor will ask the same questions after an incident: when did you become aware, who decided it was significant, what did you know at each report, what did you do and who authorised it, and what changed afterwards. A team whose records were written for those questions answers in an afternoon. The implementing regulation under NIS 2 asks for much of this directly. Its annex requires documented incident response procedures, communication plans, logging of incident response activities with the evidence recorded, and post-incident reviews that identify root cause and produce lessons learned with owners (4, European Commission, 2024), and ENISA's guidance gives the log a content: times of detection, containment and eradication, recovery, indicators, root cause, actions in each phase, scope and impact, and communications (7, ENISA, 2025). The implementing regulation binds the providers it names, which include managed security service providers; a public authority or insurer is bound by its national rules or by DORA instead. The book's conclusion is that a customer can reasonably expect such a provider's records to take this shape, and that an in-house SOC which adopts it is unlikely to be asked for less.

Four records carry the evidence. The case record (Chapter 8) holds the two awareness timestamps, the established, assessed and unknown layers of the narrative, and a source reference for every statement an AI drafted. The containment ledger (Chapter 10) holds every action, its actor, its level, its playbook and its rollback state. The clock profile above holds the open, closed and owned clocks. The post-incident review (Chapter 11) holds the findings, owners and re-tests that answer "what changed afterwards". The records link by identifier, so that "everything about this incident" is a query.

Evidence also has a cost, and the design has to keep it in proportion. The GDPR's principles of data minimisation and storage limitation apply to the evidence itself, and the case record often holds personal data about staff and customers. The conclusion for the design is a split. The case system keeps what the regulatory duties need for the periods they imply, with access limited to the incident roles, and the shared and published versions strip names and customer data. For Nordvik Region there is a further constraint: case records are subject to public-access and archive rules, so a record should be written on the assumption that an outsider may one day read the unclassified parts of it.

The management body

NIS 2 Article 20 places the approval and oversight of the cybersecurity risk-management measures on the management bodies of essential and important entities, makes them answerable for infringements and requires them to follow training (3, European Union, 2022). DORA Article 5 places the definition, approval, oversight and accountability for the ICT risk management framework on the management body of a financial entity, with a training duty of its own (2, European Union, 2022). AI Governance, Chapter 14, drew the consequence for competence: these are duties of a trained body, not of a specialist function (62, Nordqvist, 2026).

The duties constrain delegation in a particular way. A management body may delegate the work of detection, investigation and response. It cannot delegate its own accountability, and it cannot be accountable for what it cannot see. The architectural implication has three parts.

  • The body approves the delegation, not the alerts. The levels at which AI systems act in the SOC are a measure the body should approve in outline and see in report. In Hansa Mutual the group AI governance board grants every level above Level 2 and the executive board in Hamburg is the management body for DORA purposes; the board does not read alerts, and it does read the delegation profile DLG-HM-SOC-01 and the exceptions to it.
  • The body receives a report with the right content. A quarterly report that lists significant incidents, the clocks and whether each was met, the time from confirmation to a checked draft, the state of the stop path from Chapter 10 and the oversight-quality measures of Chapter 14 gives the body the means to oversee. A report of closed tickets does not.
  • Disclosure stays with a person. Any step that commits the organisation to a statement to a regulator, to people affected or to the public is an AC-4 action. The ceiling is Level 1 Assisted for the AI and the sender is a named human who can answer for it. Level 4 Autonomous is never used for these actions, and not only because the series forbids it for irreversible actions: the duty falls on the body and its officers, and a system cannot hold it.

Chapter 18 treats the decision rights in full. The regulatory constraint on it is short: the person with reporting authority must be reachable within the shortest clock the entity faces, with a deputy, at any hour.

Employee data in monitoring

Security monitoring processes data about people, and the people are mostly the organisation's own staff. Every endpoint detection, identity log and mailbox rule inspection records what employees do. The GDPR does not forbid this, and Article 32 positively requires measures for the security of processing. It does set limits: data are to be processed for specified purposes, be adequate and limited to what is necessary, and not be kept longer than needed (8, European Union, 2016). Article 88 lets member states and collective agreements set more specific rules for the employment context, including monitoring systems at the workplace, and member states have used the room differently.

Two kinds of monitoring should be kept apart, because the law and the representatives treat them differently. The first is security monitoring of the estate and its users: the detections, the behavioural analytics, the case records. Its purpose is the security of systems and data, and it is justified by that purpose and limited by it. The second is the recording of the blue team's own work: every query, ticket, action and prompt of an analyst, which SOC tooling captures as a by-product and which an AI-assisted case tool captures in more detail. Its legitimate purposes are accountability for actions, evidence for the regulators and the reproduction of cases. Its tempting purpose is the assessment of analysts, and AI Boss, Chapters 13 and 23, set out why that purpose brings in co-determination and the proportionality tests of data-protection law (67, Nordqvist, 2026). The answer is a design.

The same log serves two masters. The regulation asks that incident response activities be logged, and the log that satisfies it records who did what. The works agreement asks that the same data never become a score. The two can be reconciled by purpose and by access, and the book's conclusion is:

  1. Write the purpose into the agreement and the tool. The log of analysts' actions exists for accountability, evidence and reproduction, and the agreement says so in terms the tool enforces.
  2. Separate the evidence view from the management view. The incident roles and the auditors see the action-level record. The management reports show aggregates only, by team and period, with no figure by name.
  3. Fix retention. The retention of action-level records follows the regulatory period for the case, and personal identifiers in them are removed or reduced when the period ends.
  4. Record the agreement. The works agreement, the date and the representatives' name are part of the control's evidence, because a monitoring control that lacks a lawful basis is a finding, not a control.

The AI Act adds a further point. Under Article 26, a deployer that is an employer must inform the workers' representatives and the affected workers before a high-risk AI system is put into use at the workplace (1, European Union, 2024). The Act's high-risk list in Annex III, point 4, covers systems used in employment to monitor and evaluate the performance and behaviour of workers. If a SOC tool were ever used to evaluate analysts, it would move from a security tool to a system of that kind. A SOC that keeps its tools to the purposes above stays on the other side of the line.

The AI Act and the SOC's AI

The AI in the SOC is an AI system under the Act's definition. The organisation is its provider if it builds it or puts it into service under its own name, and its deployer for the systems it has procured (1, European Union, 2024). Four questions follow.

Is it high-risk? As the book reads the Act's Annex III, no listed use describes security operations. The category for critical infrastructure concerns safety components in the management and operation of critical digital infrastructure, which does not describe a triage, investigation, hunting or detection-drafting agent that enriches, correlates and recommends. The employment category (point 4) would apply only if a tool were used to evaluate workers, which the previous section keeps out of the design. This is the book's reading and not legal advice. If it holds, the organisation's own rules (mandate manifests, containment profiles, oversight protocols) do the work the high-risk regime would otherwise do.

What does the Act demand of oversight and competence? Article 14 requires that high-risk systems be designed so that people can oversee them effectively, and Article 26 requires deployers to assign oversight to people with the necessary competence, training and authority. Article 4 asks for measures that support the AI literacy of staff. The SOC meets the substance of these without being forced to by the regime. AI Governance, Chapter 14, concluded that literacy is role-specific and evidenced in individual records, and the review protocols of Chapter 14 of this book are the operational form of effective oversight. A supervisor who asks how the SOC's AI is overseen is best answered with the oversight-quality measures and the seeded-error results, which show that the oversight works as well as that it exists.

What if the SOC's AI is itself in an incident? The classification step applies to it. An event in which the investigation agent is manipulated, or in which a provider's model changes behaviour in a way that affects a decision, is an incident in an AI system. Whether it is a serious incident in the sense of Article 73 depends on whether the system is high-risk, and in any case the NIS 2, DORA and GDPR tests apply to its consequences. Chapter 15 set out the containment and detection for such events. The regulatory addition is that the case record for them follows the same clock profile, and that the register of information under DORA covers the model hosting and the managed detection services the SOC depends on, as Chapter 15 noted for Hansa Mutual. The supply chain duty in NIS 2 Article 21 points the same way for Nordvik.

What does the provider of the SOC's AI owe? Providers of general-purpose AI models with systemic risk have duties of their own, including to report serious incidents, and the Commission's code of practice is a document through which they can show compliance (6, European Commission, 2025). The SOC's concern is the customer side: a contract that obliges a managed provider to tell its customers promptly of its own incident or of a material model change, so that their clocks can start. For Nordvik that is the incident-notification condition of annex MS-2 (Chapter 16), and for Hansa an entry in the register of information.

National differences

The Directive and the Regulations set a floor and a shape, and national law sets much of the rest. Chapter 18 tabulates the supervisor and the filer for each Hansa entity. Three national points matter to the design. In Germany, the Betriebsverfassungsgesetz, Section 87(1) no. 6, gives the works council co-determination over technical devices suited to monitoring behaviour or performance, which covers almost all SOC tooling (67, Nordqvist, 2026); Hansa also consults works councils in the Netherlands and the unions in Sweden before a security tool that can monitor employees goes live. In Norway, EU instruments apply through the EEA Agreement once they are incorporated, so the date from which a duty binds the Norwegian entity can differ from the date for the EU entities. And in Poland the service centre processes claims for several markets, so an incident there can touch several entities' clocks at once; the profile records the affected entities. Which national statute transposes NIS 2 and what it requires are matters for each entity's legal function.

The practical rule is to keep national differences in data, not in code, on the pattern of the market overlays of Chapter 12. A change in a national limit then becomes a reviewed change to a file, with a test that the due times it produces are right.

Where the rules are heading

The labels of AI Governance, Chapter 22, apply (62, Nordqvist, 2026). It is observable that the reporting duties of NIS 2, DORA and the GDPR are in force, that supervisors ask for the records described in this chapter, and that the reporting duty of Regulation (EU) 2024/2847 is part of the Union's decided law (5, European Union, 2024). It is observable that the Cyber Solidarity Act has established a framework for Union-level detection and response (80, European Union, 2025). Amendments to the timetables and reporting channels of several instruments are under discussion; the design response, not a forecast, is to keep limits in market and regime overlays, which absorb a change at the cost of a reviewed file. The author's own projections on the blue team are confined to Chapters 24 and 28.

Across the degrees of delegation

The table sets the ceiling for each regulatory activity by the series' levels. It shows that regulation does not forbid AI in the SOC's reporting work. It fixes where a person must hold the pen.

Activity AI ceiling Who acts Why
Write the two awareness timestamps Not an AI action: a deterministic rule The case system A fact recorded at the moment, not a judgement
Open the clocks that could apply Not an AI action: a deterministic rule The case system Conservative and reversible; closing needs a reason
Assemble classification criteria and evidence Level 1 Assisted AI prepares; reporting authority reads The criteria are checkable against the record
Classify an incident as significant, major or notifiable Level 0 Advisory to Level 1 Assisted The reporting authority Commits the organisation externally; duty of the body
Draft a notification or a message to people affected Level 1 Assisted AI drafts, citing the record; a person checks Fluent drafts can carry unsupported facts
Send a notification Not delegated A named person AC-4; the duty cannot be held by a system
Close a clock that does not apply Level 1 Assisted The reporting authority The reason is evidence
Write the quarterly report to the management body Level 1 Assisted AI drafts from the register; the CISO signs The body relies on it for oversight

Nordvik Region and Hansa Mutual

Nordvik Region reports to the national CSIRT and competent authority under the national transposition of NIS 2, to the extent regional government entities fall within its scope, and to the data protection authority where personal data is involved. Its six analysts work office hours and the provider monitors at night under framework agreement NR-2025-044, so its clocks are shorter than its staffing assumes. A 24-hour early warning that starts at 17:30 on a Friday is due before the unit reopens. CASE-NR-0231 shows the shape of the risk without being a reportable incident: the provider's AI closed it on Saturday 2027-03-06, and the Region's weekly sampling reopened it on Monday 2027-03-08. Had it been a significant incident, the question of when the Region became aware, at the provider's first flag or at the reopening, would have mattered, and the Region had no record of the first moment. AIDR-0721, dated 2027-03-29, records the response. A reporting roster of two reachable people, the CISO and a deputy from the security unit's non-analyst posts, covers nights and weekends; the provider's page under annex MS-1 also reaches the roster when the provider confirms a candidate incident; and the Region's position for the MS-2 negotiation (AIDR-0722) is that the provider's handover note carries its own first-flag and confirmation timestamps and that the provider tells the Region of its own incidents promptly. The provider may itself be within the scope of the implementing regulation under NIS 2, and its own duties do not discharge the Region's. The union's agreement that closure rates are never reported by name covers the action log, and case records are written on the assumption that an outsider may request their unclassified parts.

Hansa Mutual has parallel clocks. It is an insurance group, so DORA applies directly to its EU financial entities for ICT incidents, alongside the GDPR for personal data. Whether NIS 2 also reaches non-financial parts of the group depends on national transposition and is for the group's legal function; DORA is the primary regime, and the profile carries the NIS 2 clock as a rule with a scope condition and not as a default. The supervisors differ by market, and the Norwegian entity follows the EU instruments through the EEA Agreement with a lag. The UK and Swiss entities sit outside DORA and the AI Act and report under their own regimes (the UK GDPR and the PRA and FCA for the UK, the revised Swiss data protection act and FINMA for Switzerland). AIDR-0777, dated 2027-06-24, adopts clock profile CLK-HM-01 as code in the SOC repository, owned by the SOC lead, with a market overlay for each entity that the data protection officer and legal counsel sign. It adds the profile's closed-clock record to the quarterly report to the executive board. The Konzernbetriebsrat, chaired by Thomas Brandt, agreed in the SOC annex to KBV-IT-2024 that the action-level log is evidence for accountability and incident reporting and that management reports are aggregate.

Summary

Regulation reaches the blue team as clocks, records and named people. This chapter mapped the instruments that bear on B3 Investigate, B4 Respond and B5 Learn: NIS 2 Articles 20, 21 and 23, the implementing regulation for the providers it names, DORA Articles 5 and 17 to 19, Regulation (EU) 2024/2847 Article 14, the GDPR Articles 32 to 34 and 88, the AI Act Articles 4, 14, 26 and 73, and the Cyber Solidarity Act. One incident can open several clocks that start at different moments and are owned by different people, so the case record needs one clock per regime with its own start, limit, owner and state.

The design conclusions are these. Record two awareness timestamps and open every clock that could apply at the earlier one, then close those that do not with a reason. Treat classification as the act of a named person with reporting authority, prepared by AI at Level 1 Assisted. Let the AI draft notifications from the case record and let a person send them, because a system cannot hold the duty. Write the records for the regulator's questions.

Two limits matter as much. The management body may delegate the work and never its accountability, so it approves the delegation and receives a report that lets it oversee. And the log that satisfies the regulations also records analysts' actions, which data-protection law and the works agreements treat with care: its purpose, access and retention are written into the agreement and enforced by the tool, and the management view is aggregate.

For Nordvik Region the chapter means a roster that covers the weekend and a handover note from the provider that carries its own timestamps (AIDR-0721). For Hansa Mutual it means a clock profile in code with an overlay for each market (AIDR-0777). Chapter 20 turns to how the transformed blue team is measured, including the measures that these clocks and records make possible, and the measures that must never be made about people.

Sources

  1. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 12 July 2024. (1, European Union, 2024)
  2. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (2, European Union, 2022)
  3. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union, 27 December 2022. (3, European Union, 2022)
  4. European Commission. Commission Implementing Regulation (EU) 2024/2690 laying down rules for the application of Directive (EU) 2022/2555 as regards technical and methodological requirements of cybersecurity risk-management measures. (4, European Commission, 2024)
  5. European Parliament and Council of the European Union. Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). Official Journal of the European Union, 20 November 2024. (5, European Union, 2024)
  6. European Commission. The General-Purpose AI Code of Practice. European AI Office, 10 July 2025. (6, European Commission, 2025)
  7. European Union Agency for Cybersecurity (2025). Technical implementation guidance on Commission Implementing Regulation (EU) 2024/2690 (version 1.0). ENISA, June 2025. (7, ENISA, 2025)
  8. European Parliament and Council of the European Union. Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). (8, European Union, 2016)
  9. European Data Protection Board (2023). Guidelines 9/2022 on personal data breach notification under GDPR, version 2.0. EDPB, 4 April 2023. (79, EDPB, 2023)
  10. European Parliament and Council of the European Union. Regulation (EU) 2025/38 laying down measures to strengthen solidarity and capacities in the Union to detect, prepare for and respond to cyber threats and incidents (Cyber Solidarity Act). (80, European Union, 2025)
  11. Nordqvist, G. (2026). AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. The Architecture as Code Series, Book 2. (62, Nordqvist, 2026)
  12. Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. The Architecture as Code Series, Book 3. (63, Nordqvist, 2026)
  13. Nordqvist, G. (2026). The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities. The Architecture as Code Series, Book 6. (66, Nordqvist, 2026)
  14. Nordqvist, G. (2026). AI Boss: When Artificial Intelligence Manages People in European Enterprises and Public Authorities. The Architecture as Code Series, Book 7. (67, Nordqvist, 2026)