Detect: Detection Engineering as Code

This chapter describes how the blue team's work of engineering, running and tuning detections changes when each detection becomes a versioned record and AI drafts candidates for review. It concerns B2 Detect, and it hands its output to B3 Investigate, because every alert a detection raises is the first claim that Chapter 7 will test. The chapter covers the detection record, the pipeline that carries it into production, AI as drafter, the testing that decides whether a detection counts, the measurement of coverage and cost, the detections that suppliers hold, and detection debt. Its central discipline is short: a detection is not accepted until a test shows that it fires and a measure shows what it costs in false positives.

A detection record's path from requirement to draft, test, review, rollout and review date, with the test gate marked

Figure 6.1: A detection record's path from requirement to draft, test, review, rollout and review date, with the test gate marked.

From rules to records

A rule that lives only inside a security information and event management (SIEM) console is a configuration without a history. Nobody can say who wrote it, which threat it was meant to catch, which log source it depends on, when it last fired for a real reason or whether the log source is still arriving. Most security operations centres (SOCs) start there, and so does Nordvik Region: AI Red Team, Chapter 19, treated detections, intelligence and deception as code for a large estate, and this chapter takes the next step for a team, which is to decide what a detection is.

A detection record (DET-NR-NNNN, DET-HM-NNNN) is the versioned definition of one detection. It holds six things that a rule alone does not:

  1. Logic, referenced rather than pasted, in a portable format where one exists. Sigma is an open signature format for describing log events, with rules kept as YAML files and converters such as the Sigma command-line tool that translate them into the query language of a particular SIEM (27, SigmaHQ, n.d.). A portable format keeps the team's intent separate from the supplier's query dialect, so a change of SIEM does not discard the knowledge in the rules.
  2. Data sources, with the fields the logic needs and a health check that fires when the source goes silent. A detection that depends on a log source that stopped arriving three weeks ago is not covering anything, and nothing in the rule says so.
  3. Mapping, to the MITRE ATT&CK techniques the detection addresses (9, MITRE, n.d.), and where useful to a countermeasure in MITRE D3FEND (11, MITRE, n.d.). The mapping states which behaviour is meant to be seen, which is what makes coverage discussable.
  4. Tests, the cases that show the detection fires on the behaviour and stays quiet on the benign look-alikes, with the date of the last run.
  5. Ownership and cost, a named owner, a severity, an alert budget and a review date.
  6. Origin, which requirement, intelligence record, hunt or incident asked for it, and whether a person or an AI system drafted it.

The record builds on a conclusion the series has reached several times. Architecture as Code (Chapter 9C) put threat handling in the codebase, with findings returning as pull requests, and Architecture as Code (Chapter 13) ran security tests in the pipeline against ephemeral environments (61, Nordqvist, 2025). AI Platform and Security, Chapter 17, made every threat name a control and every control a configuration that produces evidence (63, Nordqvist, 2026). A detection is a control of the kind that chapter catalogues, and the record is the configuration and the evidence at once.

The record also answers a regulatory question in an organisational form. NIS 2 Article 21(2)(b) names incident handling among the risk-management measures that essential and important entities must take (3, European Union, 2022), and DORA Articles 17 to 19 set requirements for the management, classification and reporting of ICT-related incidents for financial entities (2, European Union, 2022). Neither prescribes a detection format. What a supervisor can ask for, and what a record can answer, is evidence that the organisation knows which behaviours it is able to see and has tested that it can. That is an architectural implication, not legal advice.

Worked example: Detection record DET-HM-0455

The following record is illustrative, shown as it stood in March 2027. It follows the intelligence record INTEL-HM-0142, which the threat-intelligence cell converted into the hunt HNT-HM-0031 and a detection requirement (Chapter 5). The source report described credential theft against service accounts. Service accounts never answer multi-factor prompts, so the detection watches the host from which an account signs in and leaves MFA signals out. The drafting assistant HM-SEC-002 (AIDR-0312), a Mode 5 identity held at Level 1 Assisted, produced the first logic on a branch, a detection engineer rewrote part of it, and a second engineer approved the merge.

id: DET-HM-0455
title: Service account used from a host not seen before
version: 1.2.0
status: production
owner: team-detection-engineering        # accountable: detection engineering lead
origin:
  intelligence: INTEL-HM-0142
  hunt: HNT-HM-0031
  drafted_by: HM-SEC-002                # Level 1 Assisted, AIDR-0312
  reviewed_by: detection-engineer-2
attack:
  tactic: defence-evasion
  techniques: [T1078]                   # Valid Accounts
logic:
  format: sigma
  ref: detections/sigma/identity/service_account_new_host.yml@v1.2.0
data_sources:
  - name: idp-signin-log
    required_fields: [account, account_type, result, source_host, source_market]
    max_silence_minutes: 30
  - name: service-account-baseline        # source hosts seen in the last 30 days
    max_silence_minutes: 1440
severity: medium
applies_in: [PL, DE, NL, SE, NO, UK, CH]
tests:
  unit:
    positive: tests/DET-HM-0455/service_account_from_new_host.json
    negative: tests/DET-HM-0455/service_account_from_baseline_host.json
  replay:
    window_days: 30
    expected_alerts_per_week: {max: 6}
  simulation:
    scenario: BAS-IDP-021
    last_run: 2027-03-02
    result: pass
cost:
  alert_budget_per_week: 6
  observed_alerts_per_week: 4
  precision_30d: 0.75
rollout:
  stages: [shadow-14d, pilot-shift, all-shifts]
  tune_or_retire_review_if: alerts_per_week > alert_budget_per_week for 2 consecutive weeks
  rollback_if: alerts_per_week > 2 x alert_budget_per_week for 2 consecutive weeks
review_date: 2027-09-02                  # about six months after the last simulation

Four fields carry the discipline. max_silence_minutes makes the dependency on the log source testable. The two rollout criteria state in advance what happens to a noisy rule: a review that tunes, narrows or retires it when it exceeds its budget for two weeks, and an automatic revert when it exceeds twice the budget. review_date forces a decision to keep, change or retire the detection, instead of letting it persist because nobody looked.

On 2027-04-12 this version fired on what turned out to be a rollout step of a scheduler migration that used the service accounts from new hosts. The post-incident review (Chapter 11) added the change calendar as a suppression and corroboration input, which is why version 1.5.0 exists; the detection needed the context that an incident, and not a replay, supplied.

Detection pipelines

Treating detections as code means treating them as changes. A change to a detection is a pull request, reviewed by a second person, tested by the pipeline, rolled out in stages and reversible by reverting a commit. The pipeline has seven stations: requirement, draft, test, review, rollout, operation and review date, as Figure 6.1 shows, with the test gate placed before any person spends review time.

The requirement comes from somewhere identifiable: an intelligence record (B1 Anticipate), a hunt that found something (Chapter 9), a post-incident review (Chapter 11), a red-team or purple-team finding, or a gap in the coverage map. The pull request names it. A detection with no requirement is a candidate for the debt register.

The test gate is a set of automated checks on the pull request. The schema check confirms that the record is complete. The logic check confirms that every field the rule uses exists in the data source's schema. The unit tests confirm the positive and negative cases. The replay test runs the logic over a window of stored telemetry and compares the number of alerts with the budget. A change that fails any of these cannot be merged, whoever or whatever wrote it. This is the point of the gate: the review that follows is spent on judgement, such as whether the logic fits the technique and whether the alert will be useful, and not on finding typing errors.

Rollout is staged. A detection first runs in shadow, writing alerts to a log that no analyst reads, so that its volume and precision can be measured against real traffic. It then goes to a pilot shift or a pilot segment, and then to everyone. The shadow period is the cheapest way to learn that a rule matches every administrative script in the estate.

Rollback is a property of the pipeline, not a decision taken in the heat of a bad night. Because the previous version is in the repository, withdrawing a noisy detection is a revert that the on-call analyst may execute under the record's rollback criterion, with the detection engineer informed afterwards.

The pipeline also produces evidence. Each merge, test run and rollout is a dated, signed event, which makes the proof that a detection existed and was tested on a given day a by-product of operation and not a document assembled for an audit. That is the Evidence as Code conclusion of Architecture as Code (Chapter 15A) applied to B2 (61, Nordqvist, 2025).

One consequence concerns people. A repository history shows who wrote and approved each change. At the group level, Hansa Mutual's Konzernbetriebsrat co-determines under BetrVG §87(1) no. 6 on tools that can monitor employees' behaviour or performance, and the repository and its review tool are likely to be regarded as such tools under the Federal Labour Court's broad reading, which the legal function confirms. The SOC annex to the group works agreement therefore states that commit history serves the quality of detections and is not used to rank detection engineers. Where a representative body has agreed a purpose, the pipeline keeps to it.

AI as drafter

AI helps B2 most where a detection begins as prose. Threat reports, advisories and incident write-ups describe behaviour in sentences, and turning a sentence into logic over a particular schema is slow, careful work. A large language model (LLM) can propose the logic, the field mapping and the test cases for a reviewer to correct. Hansa Mutual's HM-SEC-002 is the book's illustration: it holds a Mode 5 identity but a permission set that allows a branch and nothing else, and it works at Level 1 Assisted, which in AI Red Team, Chapter 6, means that a person decides every action while the system prepares it (64, Nordqvist, 2026).

A draft is a claim about behaviour, and four faults recur. Ungrounded fields: the logic uses a field that does not exist in the data source, so the detection compiles and never fires. Overfitting to indicators: the draft matches the file name or string in the report, which the adversary changes next time, and misses the technique. Cost blindness: the logic is right and matches ten thousand benign events an hour. Borrowed tests: the assistant writes both logic and tests, so both share the same misunderstanding.

The source report is untrusted input, as Chapter 8 explains for evidence. The drafting pipeline passes it as data, gives the assistant no tools beyond reading the schema catalogue and writing a branch, and keeps its identity unable to merge, following the permission-manifest approach of AI Red Team, Chapter 18 (64, Nordqvist, 2026).

Practical guide: Reviewing an AI-drafted detection

Purpose. Accept a drafted detection only on evidence, at a review cost that stays below the cost of writing it unaided.

Roles. A detection engineer reviews; a second detection engineer or the detection engineering lead approves the merge; the SOC lead receives the monthly measures.

Steps.

  1. Check grounding. Confirm that every field and value in the logic exists in the schema of the named data source. The pipeline performs this check; the reviewer reads its result.
  2. Check technique fit. State in one sentence which ATT&CK technique the logic detects and which variations of the behaviour it would still catch if the indicators in the report changed. Reject a draft that cannot be explained without the report's strings.
  3. Check the tests are independent. Require at least one positive and one negative case that a person wrote or reviewed, and one replay over at least 30 days of real telemetry. Tests produced by the same run as the logic do not count alone.
  4. Check the cost. Read the replay result against the alert budget. Default budget for a new medium-severity detection: no more than six alerts a week for the whole SOC; adapt to the size of the team and the severity.
  5. Name the owner and set the review date. Default: about six months, and three months for a high-severity detection.
  6. Record the origin. Record the drafting system, its level and the reviewer in the record.

Definition of done. The pull request is merged by someone other than the drafter, the gate has passed, the shadow period is scheduled and the record holds the origin.

Measuring the drafter

The question for Hansa's four detection engineers is whether HM-SEC-002 raises quality or only volume, and whether the volume drowns the team. Output counted in drafts answers the wrong question, since drafts are cheap. Five measures answer the right one:

  • Acceptance rate: the share of drafts merged after review.
  • Rework: the share of merged logic that a person rewrote.
  • Review time per accepted detection, set against the time to write one unaided.
  • True-positive yield in the first 90 days: the share of alerts that became cases.
  • Early retirement: the share of drafted detections retired within a quarter.

Two risks need an answer in the design. The first is that review quality degrades as drafts become fluent, the automation bias that Chapter 7 cites and Chapter 14 designs against. The countermeasure is to seed known faults and measure whether review catches them (66, Nordqvist, 2026): the detection engineering lead has the pipeline inject a drafted detection with a planted grounding fault or an unreasonably broad match in about one draft in ten and measures the catch rate.

The second risk is volume, and Hansa's first quarter gives a real figure for it. HM-SEC-002 produced 48 drafts in the first quarter of 2027 and 15 were merged after review, an acceptance rate of 0.31. That is 16 drafts a month, or four per engineer, which a team of four can review without ceasing to engineer. Volume is not yet the problem. It becomes one when the review queue grows faster than it is cleared, and the trigger is a cap on open drafts per reviewer (a default of six, set by the team and not by the assistant's throughput). Review time, rework and early retirement need more than one quarter to be stable and are reported monthly.

Testing

A detection counts only when its test has run recently. This applies to detections the conclusion that AI Threat, Chapter 30, applied to controls: a control is a defence when a test that re-runs its scenario has passed recently and produced evidence by operation, and controls are classified as verified, declared or failed (65, Nordqvist, 2026). A detection with a passing test less than 90 days old is verified. A detection with a record and no recent test is declared. A detection whose test fails, or whose log source is silent, is failed.

Four layers of test serve different purposes.

Layer What it shows Typical cadence
Unit The logic fires on a minimal positive event and stays quiet on a minimal negative one Every pull request
Replay Behaviour over stored real telemetry: volume, precision and the known past incident, if there is one Every pull request; weekly on the production set
Simulation The detection fires when an authorised emulation of the technique runs in the estate, end to end through collection, parsing and alerting Monthly or quarterly per technique
Purple loop A finding from an exercise ends as a changed detection that passes its re-test Each exercise

Unit tests are fast and narrow. Replay is the layer most teams lack, and it is the one that exposes cost: stored telemetry shows how many alerts a rule would have produced last month. Simulation tests the whole chain, including the collector and the parser that unit tests assume. Hansa's breach-and-attack simulation tool provides authorised emulation of defined techniques, such as scenario BAS-IDP-021 in the record above; Nordvik runs a smaller set through the annual penetration test and, from 2027, a short list of agreed simulations by the unit's own analysts. All emulation is authorised, scoped and ends in a defensive improvement, and none of it is described here beyond the technique and the expected alert.

The purple loop is the one the series has consistently argued for. AI Red Team, Chapter 26, makes every finding from an exercise end as a verified control, closed only when the re-test passes (64, Nordqvist, 2026). For B2, the closed loop is a merged detection whose simulation test passes after the red team has repeated the technique. A finding closed by a ticket, with no changed detection, remains open in the register.

AI can help with tests as well as logic. It can propose test events, generate benign variations from the schema and summarise replay results. The rule of independence stays: a test suite written entirely by the system that drafted the logic proves little, and a replay over real telemetry cannot be replaced by synthetic events.

Coverage and cost

Counting rules does not measure coverage. A SIEM with 4,000 rules may see one technique repeatedly and another not at all, and the number says nothing about whether the rules run. Coverage is better stated as a map with three axes: the ATT&CK technique, the data source that would show it and the asset class in which it matters. Each cell has a state, the same three as above: verified, declared or failed. A cell with no detection is a gap. The map is generated from the detection records, so that it cannot drift from them.

A local map is more useful than the full matrix. The matrix lists every technique, while the team needs the techniques that matter for its assets and its adversaries, which is the output of B1 Anticipate. The tension between the two is deliberate: intelligence selects the techniques, the map shows which are covered, and the difference is the work for the quarter. ATT&CK is a knowledge base of adversary tactics and techniques (9, MITRE, n.d.), and the map uses its identifiers as labels, not as a score to be maximised.

The cost side is as important as the coverage side. Every alert asks an analyst for attention. A qualitative study of analysts' perspectives on security alarms reports their views of false positives in practice (69, Alahmadi et al., 2022), and a survey of the literature maps research challenges around alert fatigue in security operations centres (72, Tariq et al., 2025). The studies describe an association between alert burden and fatigue as analysts report it. They do not establish a particular number of alerts at which detection quality collapses, and the design should not assume one.

What the design can do is make cost visible and bounded. Each detection has an alert budget, the number of alerts per week the SOC agrees to take from it. The budget is an engineering constraint: a detection that exceeds it for two consecutive weeks goes to a review that tunes, narrows or retires it, and one that exceeds twice the budget for two weeks is reverted automatically, as the record states. Precision is measured from the case outcomes of Chapter 7, not from opinion: the share of the detection's alerts that became cases of any severity. The sum of the budgets is the SOC's alert capacity, and a new detection that does not fit within it displaces another or waits. This ties B2 to the measurement question of this book: time to respond can be improved by closing alerts faster, so the cost of a detection is measured in verified cases per hour of team time, never per analyst and never in closure speed.

Vendor-supplied detections

Not every detection is written by the team. Endpoint detection, email gateways and managed detection and response (MDR) services ship detections that they update continuously, and a managed security service provider (MSSP) runs its own content in its own platform. From the customer's perspective this content is Mode 0 Ambient AI or ambient rules: it acts without a decision by the customer and changes without the customer's pull request. The team cannot test what it cannot see, and a detection that changes underneath the SOC cannot be verified.

The architecture answers this with four rights that a contract or a platform setting must grant: provenance (which detections are active, with identifiers, versions and techniques, and notice of change), access to the logic or a machine-readable description of it, rights to tune locally under version control, and rights to run authorised simulations against the supplier's detections. Chapter 16 sets them in the contract annex, with the other terms for managed AI. Where the contract grants none of these, the vendor detection is declared, not verified, in the coverage map, however good the supplier's marketing. This is the finding of The Transformed Security Architect, Chapter 9, for Nordvik Region: the control catalogue recorded the MSSP's detections as failed (CTRL-LOG-001) because the Region could not show that they ran (66, Nordqvist, 2026). Annex MS-1 already records that the Region owns detection content. The practical result for B2 is that a supplier default can be adopted into the repository, as the next guide describes, and thereafter the Region's version is the one that counts.

Practical guide: Taking a supplier-default rule into the repository

Purpose. Convert one rule that exists only as a supplier default into a detection record that is tested, owned and budgeted.

Roles. The senior security analyst or detection owner leads; a second analyst reviews; the CISO signs off the owner and the budget; the provider's service manager is informed where the rule runs on the provider's platform.

Steps.

  1. Choose the rule. Rank the active default rules by alert volume over the last 90 days and by relevance to the assets and techniques from B1. Take the one that produces the most alerts for the least value, or the one that covers a technique the unit cares most about. Start with one rule, not twenty.
  2. Export the logic. Extract the rule's logic as it stands, and write it in a portable format or reference it in place. Record the supplier's rule identifier and version.
  3. Write the record. Fill in the fields of the detection record: technique mapping, data sources and their health checks, severity, origin (supplier default, adopted on a date).
  4. Write the tests. Provide at least one positive case, one negative case and a replay over 30 days of the unit's own logs. If no positive event is available, use an authorised simulation, scoped and logged, and record it.
  5. Set the alert budget. Read the replay and the last 90 days of alerts. Default: set the budget at about the median weekly volume if the rule was useful, and at half the median if analysts routinely closed it without action. Adapt to the team's size.
  6. Assign the owner and the review date. One named person owns the record; default review date about six months ahead, three months for a high-severity detection.
  7. Roll out in stages. Run the repository version in shadow for 14 days beside the supplier version, compare alerts, then switch. Keep the supplier version disabled but documented for one cycle.
  8. Review and merge. A second analyst approves the pull request. The CISO's office records the decision (for Nordvik Region, AIDR-0701).

Definition of done. The detection runs from the repository version, its test has passed within the last 30 days, the owner and the review date are recorded, and the alert budget is in force.

Worked example: The first detection record at Nordvik Region

This illustrative record is the first one the Region writes. The supplier default flagged repeated failed sign-ins followed by a success and produced alerts that analysts mostly closed. Karin Lund, the senior security analyst, took it over, tightened the logic to a spray pattern across many accounts from one source and recorded the result.

id: DET-NR-0001
title: Many accounts failing sign-in from one source, then a success
version: 1.0.0
status: production
owner: senior-security-analyst          # K. Lund, first detection owner
origin:
  kind: supplier-default
  supplier_rule: SIEM-DEFAULT-AUTH-007
  adopted: 2027-02-08
  decision: AIDR-0701
attack:
  tactic: credential-access
  techniques: [T1110.003]
logic:
  format: sigma
  ref: detections/sigma/identity/spray_then_success.yml@v1.0.0
data_sources:
  - name: idp-signin-log
    max_silence_minutes: 60
severity: medium
tests:
  unit:
    positive: tests/DET-NR-0001/spray_then_success.json
    negative: tests/DET-NR-0001/one_user_forgot_password.json
  replay: {window_days: 30, expected_alerts_per_week: {max: 8}}
cost:
  alert_budget_per_week: 8
review_date: 2027-08-08

The Region's choice of fields is modest on purpose: one technique, one data source, two unit tests and a replay over its own logs. It is enough to move the rule from a supplier's configuration to a record that a second analyst can read and the CISO can name an owner for.

Detection debt

Detection debt is the accumulated cost of detections that no longer do what they claim. It accrues as quietly as technical debt, and for the same reason: each rule seemed sensible when it was added. Five kinds recur.

  • Stale: the review date has passed with no decision.
  • Untested: no test has run in the period the team has set, 90 days by default.
  • Noisy: alerts exceed the budget for two or more consecutive weeks.
  • Blind: the data source is silent or lacks a required field, so the detection cannot fire.
  • Orphaned: the owner has left or changed role.

The register that lists them is generated from the records, not kept by hand. A hand-kept register is itself a document that goes stale. The generated register is a short YAML or table with the detection identifier, the kind of debt and the age, grouped by detection and by team; the owner appears in the record and not in the weekly view, and the weekly SOC meeting reads the top of it. The decision for each item is one of four: fix, retire, accept with a dated reason, or escalate.

Paying down debt needs capacity that is protected from the incident queue. A default that works for a small team is to reserve about a fifth of detection engineering time for debt, and to let the budget fall when the register is short. For a team that has no dedicated detection engineers, which describes Nordvik Region, the reservation is one half-day a week of the detection owner's time, and the first target is zero blind detections, since those give false assurance.

The register also gives the board a figure that does not reward speed of closure. The number of verified detections against techniques that the local map marks as important, and the age of the oldest unreviewed one, report on the health of B2 without setting analysts against each other. Figures are reported by detection and by team, never by name: the union at Nordvik has negotiated that closure rates and similar measures are never reported by name, and the same discipline applies to detection ownership.

Across the degrees of delegation

The table sets the degree of delegation for each action class in B2. The mode describes how the AI is deployed and whose identity it uses; the level describes who decides each action. The levels are those of AI Red Team, Chapter 6 (64, Nordqvist, 2026).

Action class Mode Level in this book Condition
Draft logic and test events from a report or incident Mode 5 identity (HM-SEC-002), branch-only permissions Level 1 Assisted A person decides what enters the repository
Run replay, summarise results, propose tuning Mode 4 built AI application Level 1 Assisted Replay on stored data only; no production writes
Open a pull request with a drafted change Mode 3 agentic work tool Level 2 Supervised Branch only; the agent cannot merge or approve
Merge a change to staging or shadow Pipeline Level 2 Supervised Gate passed and a named approver
Deploy to production for a narrow, pre-approved class (for example, adding a known benign source to an exclusion list) Mode 5 within a codified playbook Level 3 Bounded, not recommended by this book until the conditions below hold Passing test, named approver, policy decision point outside the model, rollback criterion
Retire a detection Pipeline Level 2 Supervised Owner approves; retirement is reversible by revert
Vendor-supplied content Mode 0 Ambient AI Not delegated by the team Declared until the contract grants logic and test rights

This book does not use Level 4 Autonomous for changes to detection content. Rollback is cheap, so the rule does not rest on irreversibility. It rests on the cost of a silent miss: a detection quietly withdrawn or loosened by a system that nobody reviews produces no alert to show that it has gone wrong. No agent merges a detection into production without a passing test and a named approver.

Observable, expected, speculation

The following labels apply to the statements about the future in this chapter.

  • Observable. Sigma rules and the converters that translate them to SIEM query languages are published as open source (27, SigmaHQ, n.d.). Hansa's drafting assistant is the book's illustration, not evidence about the field.
  • Expected. No decided instrument or cited source makes automatic deployment of drafted detections expected, so the book gives a design position instead: Level 3 Bounded deployment for a narrow class is defensible only where three conditions hold, a codified playbook, a policy decision point outside the model and a measured catch rate for seeded faults.
  • Speculation. Detection estates that tune and rewrite themselves without human review are speculation. No present evidence shows that such a system keeps coverage of the techniques that matter or reports its own silent failures.

Nordvik Region and Hansa Mutual

For Nordvik Region the step is to create a detection-engineering practice where none exists. The unit of 14 has six analysts working office hours, and Karin Lund in practice owns the SIEM and its few local rules. The unit has no detection engineers. The first move is DET-NR-0001, decided under AIDR-0701 (2027-01-18): the Region takes ownership of the rules that matter, one at a time, using the guide above and its own reserved capacity for any drafting. The detection-drafting assistant at Level 1 Assisted is first used on these adopted rules, never on the provider's platform. The second move is contractual: the Region owns detection content under annex MS-1, and the provider's service must also give it provenance, logic access, tuning rights and test rights, which the annex of Chapter 16 sets out. Alert data contains personal and health data, which keeps drafting and replay on the Region's self-hosted capacity. Where the provider's AI closes low-severity alerts out of hours, the lack of notice and sampling rights described in Chapter 7 means that coverage claims for those classes remain declared.

For Hansa Mutual the step is the opposite. Its four detection engineers already manage detections as code, with a group SIEM, a SOAR layer and the breach-and-attack simulation tool, and the pipeline of this chapter is largely their daily practice. The question is quality against volume. In the first quarter of 2027 HM-SEC-002 produced 48 drafts, of which 15 were merged after review, and the detection engineering lead reports the five measures above to the SOC lead monthly, together with the catch rate for seeded faults, under AIDR-0751. Because the pipeline records authorship, the SOC annex to KBV-IT-2024 fixes its purpose, and the Polish service centre's employee representatives and the Swedish unions are informed of the same purpose. UK and Swiss telemetry stays in the markets' replay sets where transfer rules require it, and applies_in on each record says where a detection runs.

The two differ in what limits them. Nordvik is limited by capacity and by the contract, and a single owner is a single point of failure for its detections. Hansa is limited by review attention. At 16 drafts a month the load is manageable; the risk to watch is that fluent drafts come to consume the engineers' time without raising coverage.

Summary

This chapter treated B2 Detect as engineering. A detection is a record with logic, data sources, an ATT&CK mapping, tests, an owner, an alert budget and a review date, carried through a pipeline whose test gate sits before human review. The central discipline is that a detection counts only when a recent test shows that it fires and a measure shows what it costs. The classification that AI Threat, Chapter 30, gave to controls, verified, declared or failed, applies unchanged to detections, and the coverage map is built from it.

AI drafts well where a detection begins as prose, and the drafts carry predictable faults: ungrounded fields, overfitting to indicators, blindness to cost and tests that share the drafter's mistake. The answer is the review protocol, independent tests, replay over real telemetry, seeded faults to check that review is real and a cap on open drafts. Drafting sits at Level 1 Assisted; branch-only agents at Level 2 Supervised; Level 3 Bounded deployment is defensible only for narrow classes with a passing test and a named approver, and the book does not yet recommend it; Level 4 Autonomous is not used for detection content. Supplier detections are Mode 0 Ambient AI until the contract grants provenance, logic, tuning and test rights, and until then they stay declared. Detection debt, in its five kinds, is a generated register with an owner, paid down from protected time.

The chapter also touches B1 Anticipate, which supplies the requirements that start the pipeline, and B3 Investigate, which receives the alerts and measures their precision. For Nordvik Region the work is to create the practice, one adopted rule at a time and with contractual rights; for Hansa Mutual, where 16 drafts a month are not yet a burden, it is to keep review real as volume grows. Chapter 7 turns to what happens to the alert next: triage, the closure policy by class and the verified case.

Sources

  1. SigmaHQ. Sigma: Generic Signature Format for SIEM Systems. Open-source detection rule specification and rule repository. (27, SigmaHQ, n.d.)
  2. MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (9, MITRE, n.d.)
  3. MITRE Corporation. MITRE D3FEND: A knowledge graph of cybersecurity countermeasures. (11, MITRE, n.d.)
  4. 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)
  5. 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)
  6. Alahmadi, B. A., Axon, L. & Martinovic, I. (2022). 99% False Positives: A Qualitative Study of SOC Analysts' Perspectives on Security Alarms. 31st USENIX Security Symposium. (69, Alahmadi et al., 2022)
  7. Tariq, S., Baruwal Chhetri, M., Nepal, S. & Paris, C. (2025). Alert Fatigue in Security Operations Centres: Research Challenges and Opportunities. ACM Computing Surveys 57(9). (72, Tariq et al., 2025)
  8. Nordqvist, G. (2025). Architecture as Code. The Architecture as Code Series, Book 1. (61, Nordqvist, 2025)
  9. 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)
  10. Nordqvist, G. (2026). AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. The Architecture as Code Series, Book 4. (64, Nordqvist, 2026)
  11. Nordqvist, G. (2026). AI Threat: Are the Dystopias Coming True? Evidence, Risk and Response for European Enterprises and Public Authorities. The Architecture as Code Series, Book 5. (65, Nordqvist, 2026)
  12. 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)