Target: Threat-Informed Scenarios, Risk and Priority Techniques

Every loop starts with a choice of what to test. This chapter describes how an organisation makes that choice well: how intelligence, the threat register, risk assessment and incidents become a short list of priority techniques and a versioned library of scenarios, who decides what enters the library, and what must be kept out of it. It concerns P1 Target above all. It reaches forward to P2 Emulate, because a scenario is the unit that emulation executes under a signed rules-of-engagement manifest (Chapter 6), and back from P5 Verify, because every re-test result and every coverage gap returns to the list and changes its order.

The choice matters more when AI is in the loop. Emulation that costs little can run every scenario in the library every month, and an agent can draft new scenarios faster than a person can read them. The scarce resource moves from the hours of the red team to the judgement that decides which scenarios are worth running at all. A library chosen for convenience produces a loop that is busy and green and says little about the risks the organisation carries. The chapter argues that targeting is a risk decision with an owner, a record and a review date, and that the commonest failure of P1 Target is a quiet one: testing what is easy to emulate and calling the result coverage.

Figure 5.1: From sources through risk ranking and a named reviewer to a versioned scenario library.

The chapter builds on four conclusions of the earlier volumes. Architecture as Code (Chapter 9C) established that threat handling belongs in the codebase: intelligence is ingested through pipelines, risk is a versioned record with likelihood, impact, owner and expiring exceptions, and findings return as pull requests (87, Nordqvist, 2025). AI Red Team, Chapter 10, established that threat models live beside the architecture, that AI proposes candidate threats at Level 1 Assisted, that soundness is defined in advance and that a named reviewer decides each candidate; no AI accepts a threat, a risk or an exception (90, Nordqvist, 2026). AI Threat, Chapter 32, established the threat register as code: scenarios with a path to harm, an owner, a decision tier and triggers, with probability omitted on purpose (91, Nordqvist, 2026). AI Blue, Chapter 5, established intelligence as code, the path from a report to a hypothesis, a hunt and a detection requirement, and the verification of what an AI extracts from a report (94, Nordqvist, 2026). This chapter does not repeat them. It takes the next step: from a risk-ranked view of threats to the scenarios that test whether the defence answers them.

From intelligence to scenario

A scenario is a statement that the organisation wants to know the answer to a specific question: if an adversary did this, in this part of the estate, would the defence prevent it, see it, raise it and act on it? Four kinds of input supply the questions.

Intelligence supplies the adversary's behaviour. A report on a campaign against the sector, a sector information-sharing note or a vendor advisory describes what adversaries did elsewhere. AI Blue, Chapter 5, treats such reports as records with provenance and turns them into hunts and detection requirements. P1 Target takes the same record in a different direction and asks which behaviours in it should become tests. The two uses are complementary: the hunt looks for the behaviour in the estate, the scenario tests whether the defence would notice it. Structured exchange formats such as STIX and TAXII carry the technique references that make the step mechanical (27, OASIS Cyber Threat Intelligence (CTI) TC, 2021).

The threat register supplies the consequences. An entry such as THR-HM-02, AI-enabled intrusion into the group estate, says what the organisation fears and who owns the fear; it does not say which behaviours would realise it. The scenario supplies the path: the techniques an adversary would chain to reach the harm the entry describes. Because the register omits probability on purpose, the entry cannot rank techniques by likelihood. It does supply the impact side of the ranking and the owner who must accept the risk.

Risk assessment supplies exposure. A threat model of a service says which assets, trust boundaries and identities an adversary would meet, and a vulnerability and exposure view says which of them are reachable today. The scenario library should follow the architecture: a technique that cannot reach any asset of consequence does not earn a place, and a technique that reaches the most important service earns a scenario for each layer of the defence that is supposed to stop it.

Incidents and findings supply the organisation's own history. An incident shows a technique that did happen here, and a finding from an earlier exercise shows a technique the defence did not handle. Both go to the front of the queue, because each is evidence about this estate and not about estates in general. An incident also tells the loop something the other inputs cannot: which scenarios would have caught it. Every closed incident review should ask whether a scenario existed for the technique that mattered, and if not, add one. That connects P1 Target to the learning loop of AI Blue, Chapter 11.

The four inputs are not equal in kind. Intelligence and prevalence data are reports about other organisations, the register and the risk assessment are the organisation's own judgements, and incidents and findings are the organisation's own observations. A defensible target list uses all three kinds and records which one supports each entry.

The European supervisory frameworks describe the same separation of roles. TIBER-EU, the European Central Bank's framework for threat intelligence-based red teaming, begins an exercise with a threat intelligence phase that precedes and informs the red-team test (20, ECB, 2025). For financial entities within DORA's threat-led penetration testing, the delegated regulation on testing methodology provides that the threat intelligence provider proposes scenarios that differ by threat actor and by tactics, techniques and procedures, and that the control team lead selects at least three of them, with no more than one that is not threat-led (Delegated Regulation (EU) 2025/1190, Article 10) (8, European Commission, 2025). The architectural point is general: the party that proposes scenarios is not the party that selects them, and the selection is recorded. The sections below apply the same principle to an internal library.

ATT&CK and ATLAS as vocabulary

A scenario needs a vocabulary that the red team, the detection engineers, the intelligence analysts and the auditors share. MITRE ATT&CK provides it for conventional intrusions (17, MITRE, n.d.), and MITRE ATLAS provides it for attacks on AI-enabled systems (18, MITRE, n.d.). MITRE D3FEND offers a matching vocabulary of countermeasures, which lets a scenario state which defensive technique is expected to answer it (19, MITRE, n.d.). Detections written in the Sigma format can carry the same technique tags, so that a scenario and the detection expected to see it refer to one identifier (30, SigmaHQ, n.d.).

Four rules keep the vocabulary honest.

1. Use the identifier, not the procedure. A scenario records T1110.003, not a description of how to carry out a password spray. The execution detail belongs in the emulation plan and in the tool configuration under the controls of Chapters 6 and 7, and the library that holds scenarios is itself a sensitive asset. The library is written so that a reader with repository access learns what the organisation tests and why, and learns nothing about how to defeat it.
2. Record the knowledge-base version. ATT&CK and ATLAS are revised; techniques are added, merged and deprecated. A scenario written against one release should say which, and the library should be reviewed when the release changes. The identifiers themselves move: ATT&CK v19 (April 2026) revoked technique T1562, Impair Defenses, and introduced T1685, Disable or Modify Tools, so a list written against v18 or earlier and a list written against v19 or later name that behaviour differently (17, MITRE, n.d.). The example lists in this book are written against v19 for that reason. This is a rule of the book, not a requirement of the frameworks.
3. Use sub-techniques where the detection differs. Password spraying (T1110.003) and password guessing (T1110.001) call for different detections. A scenario at the parent level cannot say which detection it expects.
4. Say what the identifier cannot say. An ATT&CK identifier names a behaviour. It does not say how well the adversary is resourced, how fast the adversary moves or what the adversary does next. The scenario adds those as parameters: the entry point, the identity used, the target asset and the expected sequence.

For AI systems, the scenario draws on ATLAS and on the OWASP lists for language-model applications and agentic applications (21, OWASP, 2025) (22, OWASP, 2025), and the loop applied to such systems is the subject of Chapter 12. The same rule applies there: an identifier and an expected outcome, never a prompt string.

Priority techniques

ATT&CK lists hundreds of techniques and sub-techniques, and no organisation can test them all at the cadence its evidence requires. The question is how to choose. The wrong answer is novelty. A technique reported last week in a conference talk is interesting, and a technique used in most intrusions is important; the two lists overlap less than the programme of a security conference suggests. The Center for Threat-Informed Defense publishes a ranked list of ATT&CK techniques built to help defenders decide where to start, with prevalence, common choke points and actionability as its criteria (31, Center for Threat-Informed Defense, 2024). Reports from incident-response engagements, such as Mandiant's annual M-Trends, and the ENISA Threat Landscape give the global and the European view of what adversaries do in practice (62, Mandiant, 2026) (51, ENISA, 2025). That prevalence is observable. What it cannot tell the organisation is which of the common techniques would do the most damage here, and that needs the local factors.

A workable ranking combines three factors, each on a coarse ordinal scale.

• Impact. What the technique would allow against the assets that the threat register and the business impact analysis name as critical. A technique that leads to the loss of the claims platform or to the exposure of the benefits register scores high. Take the value from the register's harm paths, not from an estimate made for the ranking.
• Relevance. How strongly the evidence points to this technique against this organisation or sector: prevalence in public reporting, appearance in sector intelligence, appearance in the organisation's own incidents and findings, and the exposure of the relevant assets. Relevance is not a probability. The register omits probability on purpose because the evidence does not support a number, and the ranking follows it: three tiers, with the reasons written down.
• Uncertainty about the defence. How little the organisation knows about whether it would stop the technique. A technique with a recent passing test needs less attention than one that has never been tested or whose evidence has expired. This factor ties the ranking to P5 Verify, and it is the one that keeps the list moving.

The sum of the three gives the order and a priority tier, not a score to the second decimal. Tier 1 techniques are exercised continuously or at least every 90 days, tier 2 every 180 days, and tier 3 on trigger. The cadence defaults match the evidence-expiry rule used by the organisations in this book; each organisation should adapt them to its risk appetite and its capacity to test.

Practical guide: Building a first priority list of 20 to 40 techniques

Purpose. Produce a priority list that a risk owner has accepted, that every entry in the scenario library can be traced to, and that can be re-ranked in a day when the evidence changes.

Roles. The red-team lead or contracted tester (chair), the intelligence analyst, the detection owner, the owner of the service in scope, the CISO or delegate as the accepting owner, and for organisations with one, the white-team lead. The detection owner may nominate techniques and may comment on the ranking; the detection owner does not remove a technique from the list, because the party being tested must not be able to veto the test.

Steps.

1. List the services in scope and take the harm paths of the threat-register entries that touch them. For a first list, choose one or two services; breadth comes later.
2. Collect candidate techniques from four places: the technique tags of the last four quarters of intelligence records, the techniques in the organisation's own incidents and findings, the techniques in the public prevalence sources named above, and the techniques the threat model of each service in scope lists. Remove duplicates and keep the source of each.
3. Give each candidate an impact tier (1 to 3) from the register's harm paths, a relevance tier (1 to 3) from the sources and the exposure, and an uncertainty tier (1 to 3) from the last test result and its age, with the reason in one sentence. Where the technique has never been tested, uncertainty is 3.
4. Sort by the sum, break ties by uncertainty, and cut the list at 20 to 40 entries. Fewer than 20 usually means a service has been missed. More than 40 means the organisation cannot keep the evidence fresh.
5. Check the list for selection bias. For each of the first twenty entries, record how the technique can be emulated safely (benign, reversible and tagged; in a mirror; by a person only). If every high-ranked entry is of the first kind, ask what was left out because it was hard to emulate, and put at least a quarter of the list in the categories that need the red team or a mirror.
6. Write the list as code, assign an owner to each entry, and have the accepting owner sign the pull request. Record the decision as an AI Decision Record if AI took part in producing the candidates.
7. Set the review date: every six months, on a trigger (a new threat-register entry, a major incident, a change in the estate) and after any finding that was not on the list.

Definition of done. Every entry has a tier with reasons, an owner, a safety class and an emulation route; at least one scenario exists or is planned for every tier 1 and tier 2 entry; the accepting owner has signed; and the list contains at least one entry that is hard to emulate and is marked as such.

The list is an artefact in the repository:

# priority/benefits-triage.yaml  (illustrative excerpt)
list: PRI-NR-2028-01
service: benefits-triage
attack_version: "v19"            # record the release the list was written against
review: { cadence_months: 6, next: 2028-07-31, triggers: [new-register-entry, major-incident, estate-change] }
accepted_by: ciso-nordvik
techniques:
  - id: T1110.003
    name: Password Spraying
    tiers: { impact: 3, relevance: 3, uncertainty: 1 }
    why: "Exposed staff portal; DET-NR-0001 passed last test"
    emulation_route: mirror
    scenarios: [SCN-NR-0001]
  - id: T1486
    name: Data Encrypted for Impact
    tiers: { impact: 3, relevance: 2, uncertainty: 3 }
    why: "Mirror only, irreversible if real; last run 2027-03-30, evidence expired"
    emulation_route: mirror
    hard_to_emulate: true
    scenarios: [SCN-NR-0009]     # expired evidence is shown as untested

The scenario record

A technique is a vocabulary item. A scenario is the testable statement built from one or more techniques, and the scenario record is the unit that the rest of the loop references. P2 Emulate executes it, P3 Observe compares the result with its expectations, P4 Improve changes the defence if the expectations fail, and P5 Verify re-runs it as a regression case (Chapter 11). A record that is missing any of the following fields makes one of those stages guess.

• Identity and owner. A stable identifier (SCN-NR-* or SCN-HM-*), a version, a named owner who is a role, and the date the owner accepted it.
• Source. The intelligence record, register entry, incident or finding that justified it. A scenario without a source has no reason to be tested rather than another.
• Technique set and parameters. Identifiers, the entry point, the identity class used, the target asset, and the sequence, at the level of design and no further.
• Expected outcome per layer. What the defence is expected to do at each layer: prevention, telemetry, detection, alert and triage, and response. Chapter 9 compares the observed outcome with this expectation, so the expectation must be written before the run and by someone other than the person who will be measured against it.
• Safety class and environment. Whether the scenario is benign and reversible enough to run in production, needs the red team in the loop, or runs only in a mirror or range. Chapter 6 defines the classes and the rules-of-engagement manifest that enforces them.
• Evidence rule. How long a passing result stays valid, and the result of the last run once there is one.
• Exclusions. What the scenario must not touch, which feeds the scope of the rules of engagement.
• Sensitivity. The classification of the record itself. A library of scenarios, with the weaknesses they reveal, is a map of the organisation that an adversary would value, so both organisations hold it with restricted access.

Worked example: Scenario records SCN-NR-0001 and SCN-HM-0007

The first record is Nordvik Region's password-spray scenario for the benefits-triage staff portal. Elin Berglund, the contracted tester, wrote it; Karin Lund owns the library and reviewed the expectations. It runs against the staff identity provider's test tenant, with synthetic accounts and a per-run white-team approval, because a spray against real staff accounts risks locking them out. The second is Hansa Mutual's service-account scenario, written by the group red team after the incident INC-HM-2027-0455 and the intelligence record INTEL-HM-0142 of AI Blue. It runs in production under HM-SEC-004 because it is benign, reversible and tagged.

# scenarios/SCN-NR-0001.yaml  (illustrative)
id: SCN-NR-0001
version: 3
title: Password spray followed by a successful sign-in, staff portal
status: active
owner: karin-lund                # ROLE-NR-SEC-DET from 2027-07-01
author: contracted-tester         # Elin Berglund, call-off NR-2026-071
accepted_on: 2027-02-22
source: { type: assessment, refs: [ATA-NR-2026-01, THR-NR-02], note: "sector information-sharing group" }
techniques: [T1110.003, T1078]
attack_version: "v19"
parameters: { entry: staff-portal, identity_class: test-accounts, target: staff-identity-provider-test-tenant }
safety_class: S2                  # red team in the loop; classes defined in Chapter 6
environment: production           # test tenant, synthetic accounts, per-run white-team approval (S2)
expected:
  prevention: "lockout policy limits attempts per account"
  telemetry: "all sign-in events reach the SIEM within 60 s"
  detection: { rule: DET-NR-0001, within_minutes: 15 }
  alert_triage: "alert reaches the MSSP queue; triage under annex MS-1"
  response: "analyst disables the account and opens a case"
evidence: { expires_days: 180, last_run: 2028-02-09, last_result: detected-alert-triaged }
exclusions: [production-accounts, named-individuals, resident-data]
classification: security-sensitive

# scenarios/SCN-HM-0007.yaml  (illustrative)
id: SCN-HM-0007
version: 5
title: Service account used from a new host, claims export
status: active
tier: 1
owner: group-red-team-lead        # Mareike Hartmann
accepted_on: 2027-04-20
source: { type: incident, refs: [INC-HM-2027-0455, INTEL-HM-0142, HNT-HM-0031] }
techniques: [T1078]
attack_version: "v19"
parameters: { identity_class: tagged-test-service-account, target: claims-export-range-node }
safety_class: S1                  # benign, reversible, tagged
runner: { agent: emulation-runner, mandate: MND-HM-EMU-01, level: "Level 3 Bounded" }
expected:
  prevention: "none required; detection is the control under test"
  telemetry: "identity and host events present in SIEM"
  detection: { rule: DET-HM-0455, within_minutes: 10 }
  alert_triage: "case opened by the SOC without red-team contact"
  response: "no containment of production assets; tag recognised"
cadence: { every_days: 30, also_after: [detection-change, connector-change, mandate-change] }
evidence: { expires_days: 90, last_run: 2028-01-23, last_result: detected-alert-triaged }
stop_path: "white-team lead; kill switch outside the runner"
classification: security-sensitive

Both records say what was tested, when and with what result, and both carry an expiry. Neither says how to carry out the behaviour. A reader who finds last_result: detected-alert-triaged with a date older than expires_days knows the claim has lapsed, which is the use of the field.

AI-proposed scenarios and who decides

AI is useful at the front of the funnel. A scenario curator, an agent or a drafting assistant, reads intelligence records, register entries, incident reviews and the technique tags of new detections, and proposes drafts: a new technique chain, a variant of an existing scenario for a different identity class, or a scenario for a technique with no coverage. It does this faster than a person, and it can compare the library with the sources to list the gaps. The same pattern appears in AI Red Team, Chapter 10, for threat models: AI proposes at Level 1 Assisted, the proposals carry provenance, and a named reviewer decides each one (90, Nordqvist, 2026).

Four rules apply to the curator.

1. It proposes; a named person accepts. The curator holds a Level 1 Assisted mandate. A draft enters the library only when the owner accepts it, and the record carries the name of the person who accepted it, the date and the version of the curator that proposed it. The decision to accept belongs to a person; the curator does not decide. For Hansa Mutual, the curator's mandate is MND-HM-EMU-02, which also covers the planner (Chapter 14); the curator proposes and a person accepts, so the planner never plans from an unreviewed proposal.
2. It reads sources and does not follow instructions in them. An intelligence report is untrusted input. A document that tells an agent to add or drop a scenario is a hostile source, and the curator is built and tested as such, using the same controls as the SOC agents of AI Blue, Chapter 15 (94, Nordqvist, 2026).
3. Each draft passes soundness checks defined in advance. The checks are the ones carried over from threat modelling: every technique identifier exists in the cited release; the source is real and reachable; the expected outcome names a layer and a detection that exists; the safety class is stated; the draft is not a duplicate of an existing scenario. A draft that fails a check is rejected before a person reads it.
4. The reviewer's work is measured. Reviewers who see mostly good drafts begin to accept them without reading. Automation bias, the tendency to follow an automated suggestion and to miss errors that the automation does not flag, is well documented in human-automation research (101, Parasuraman & Manzey, 2010). The loop measures acceptance rate, the share of accepted drafts edited by the reviewer, and the outcome of a sample of rejected drafts re-read by a second person. A reviewer who has accepted forty drafts in a row without an edit is a signal about the process, not a compliment.

Independence also constrains the curator. A system that helps choose a scenario should not also write the detection that is expected to catch it, and an agent that drafts a detection should not choose the scenario that tests it. The principle is developed in Chapter 15; at the level of P1 Target it means that the curator and the detection-drafting assistant are separate mandates, ideally on different model families (the model kind of Chapter 15), and that Nordvik's detection-drafting assistant is not used for a scenario it helped to choose.

Selection bias and the risk of testing what is easy

A scenario library tends to fill with the scenarios that are cheap to run. That is understandable: benign, reversible and tagged scenarios can run every week, and they generate fast evidence. A technique such as encryption for impact (T1486) cannot be run in production in any form that is both realistic and reversible, so it is emulated in a range with a benign marker or tested by a human-led exercise, or it is not tested at all. The library then shows green for the easy techniques and silence for the hard ones, and a dashboard that counts scenarios passed rewards the first kind. The pattern is the streetlight effect applied to testing. It is the book's own conclusion from the structure of the loop, not a finding of a study, and the safeguards are structural.

• Report gaps as gaps. A priority technique with no scenario, or with a scenario that cannot run in the environment that matters or whose evidence has expired, appears on the list as scenarios: [] or with hard_to_emulate: true and is reported as untested. It is never removed.
• Reserve a share for the hard. At least a quarter of the tier 1 and tier 2 list is in techniques that need the red team or a mirror, and that share is reviewed by someone outside the team that runs the easy scenarios.
• Watch the curator's mix. AI drafts tend to favour techniques that are well documented in public sources, because that is what the sources describe. This is an inference, and the check is cheap: compare the technique distribution of proposals with the distribution of the priority list. Where the curator proposes a dozen variants of one well-documented technique and none for a hard one, the proposals are not representative.
• Keep human-authored novelty. Scenarios written by a person who has thought about this estate, such as the contracted tester's or the red-team lead's, are a distinct class and are tagged as such. They supply the independent element that Chapter 15 requires of the loop.

What not to test

A library records what the organisation tests and also what it deliberately does not. Four categories stay out.

Out of scope. Systems, networks and data that the rules of engagement do not name. A technique on the priority list may still be out of scope for a given service, and the scenario then names the environment where it can run. Third-party systems need the consent of the provider; a cloud provider, a managed-service provider such as Nordvik's MSSP, or a software-as-a-service vendor is not tested without it (Chapter 6).

Unsafe. Scenarios that are irreversible in production, that could damage availability or integrity beyond what a stop path can restore, or that cannot be stopped by someone outside the emulating system. The usual response is not to drop the technique but to move it to a range, a mirror or a human-led exercise, and to record the move.

Unauthorised. Scenarios that require an authority nobody has given: a test that touches personal data beyond the exercise's authorisation, one that targets a named person, or one that involves staff without the notice that the local agreement requires. Personal data in exercise telemetry still falls under the General Data Protection Regulation, and the data minimisation principle of Article 5(1)(c) applies to the exercise as to any processing (7, European Union, 2016). At Nordvik Region the staff representatives' joint committee needs written notice ten working days before a window that involves staff; at Hansa Mutual the clause KBV-IT-2024-SOC-05 requires advance information to the Konzernbetriebsrat and the Polish and Swedish representatives, and no exercise result enters an appraisal. A scenario that cannot satisfy these conditions stays in draft.

Not worth testing. A technique that cannot reach any asset of consequence in the estate has low impact by the ranking and no place on the list. The decision is recorded with its reason, so that it can be reversed when the estate changes.

All four categories end in a record, not in silence. The exclusion register lists each excluded technique or environment, the reason, the person who decided and the review date. This keeps the coverage statement honest: a technique that is excluded is untested, and untested is not covered.

Obligations that shape the choice

Three European instruments set the frame for what a target list has to show, each to be read as an architectural implication and not as legal advice. NIS 2, Article 21(2), point (f), requires essential and important entities to include policies and procedures to assess the effectiveness of cybersecurity risk-management measures among their measures, which is the question a scenario library answers (3, European Union, 2022). DORA requires financial entities to test their digital operational resilience and, for those identified by their competent authority, to carry out advanced testing by threat-led penetration testing at least every three years, which the authority may lengthen or shorten (DORA, Chapter IV, including Articles 24 and 26) (2, European Union, 2022). The delegated regulation on the methodology gives the roles and the selection rule of the threat-led test, and an internal library that follows the same separation of proposer and selector will be easier to reconcile with a supervisor's expectations (8, European Commission, 2025). None of these instruments asks for a particular list of techniques. They ask for a defensible, evidenced choice, and the priority list with its tiers and reasons is the artefact that shows one.

Across the usage modes

The usage modes describe how the AI is deployed and whose identity it uses; the level says who decides each action. For P1 Target, no mode selects without a person.

Usage mode	What it does at P1 Target	Level	Who decides
Mode 1 Conversational assistants	Help a tester or analyst draft a scenario description or map a report to technique identifiers, under the person's identity	Level 0 Advisory	The person, who owns the output
Mode 2 Embedded workplace assistants	Summarise reports and suggest technique tags in the intelligence tool	Level 0 Advisory to Level 1 Assisted	The intelligence analyst
Mode 3 Agentic work tools	Assemble a candidate list from sources the person names, with provenance	Level 1 Assisted	The red-team lead or tester
Mode 4 Built AI applications	A scenario curator reads feeds, register and incident reviews and proposes drafts	Level 1 Assisted	The library owner, who accepts or rejects each draft
Mode 5 Autonomous production agents	None at P1 Target; scenario selection is not delegated	None	A named owner

The ceiling at P1 Target is Level 1 Assisted. A proposal made by a system is not a decision, and nothing in the stage requires a higher level. The levels that matter arise at P2 Emulate, where the Level 3 Bounded ceiling applies to catalogued scenarios of the safe class and Level 4 Autonomous is never used for an irreversible or out-of-scope action, for personal data beyond the authorisation, or for an action that targets a named person.

Observable, expected, speculation

Two statements about the future of targeting carry labels. The prevalence of a small set of techniques in reported intrusions, and the use of ATT&CK identifiers as the working vocabulary of exercises and of threat-led testing, are observable. The use of AI-curated scenario libraries, in which an agent proposes and a person accepts, is expected, supported by the spread of agentic tools in security operations and by the decided instruments that already require documented, reviewed test selection. Autonomous scenario selection, in which a system chooses what to test, runs it and judges the result without a person reading the choice, is speculation. This chapter's rules do not depend on it and do not permit it.

Nordvik Region and Hansa Mutual

Nordvik Region buys the loop, and its leverage at P1 Target is the contract. After RoE-NR-2027-001 the Region keeps a library of 12 scenarios, SCN-NR-0001 to SCN-NR-0012, covering a first priority list of nine ATT&CK techniques for the benefits-triage service: among them T1078 valid accounts, T1110.003 password spraying, T1566.002 spearphishing link (the technique of CASE-NR-0231), T1190 exploitation of a public-facing application, T1098 account manipulation, T1486 data encrypted for impact and T1685 disabling or modifying tools (17, MITRE, n.d.). The sources are the threat-register entries THR-NR-*, the assessment ATA-NR-2026-01, the sector information-sharing group and the tester's own findings. Karin Lund owns the library; Elin Berglund, who wrote its human-authored core, proposes and the Region's CISO accepts the list. The list governance is recorded in AIDR-0801 (2028-01-25): a review every six months and on trigger, an evidence expiry of 180 days for every technique on the list, and a rule that a technique may be moved to a mirror but never dropped without a recorded reason. When the audit committee put its question in January 2028 (AIDR-0800), the list answered part of it. Seven of the nine had something behind them: a result inside the 180-day expiry for five and the provider's runbook statement under MS-1 for two. The other two, T1190 and T1486, had last been exercised in a mirror during the spring 2027 fieldwork, which ended on 2 April 2027, so their evidence had expired. Those two were reported as untested, which is the honest statement, and put at the head of the next run. The Region has no curator agent. Its drafting assistant is used for descriptions, not choices, and the independence rule keeps it away from any scenario it helped to choose.

Hansa Mutual runs the loop, and its leverage is the pipeline. At the start of 2028 the group had 86 scenarios, SCN-HM-0001 to SCN-HM-0086, with at least one for each of the 34 priority techniques, held in a repository that the red team owns and detection engineering reads. At BTP-HM-2027-Q3 25 of the 34 were verified; of the nine that were not, four had evidence past its expiry, three had failed a re-test and two had never been tested. In February 2028, as part of the work recorded in AIDR-0850, the 34 techniques were re-ranked from the threat register, with THR-HM-02 (AI-enabled intrusion into the group estate) as the main new input and the red team's incident-derived scenarios as the second. The number stayed at 34; five techniques changed tier, and the two never-tested techniques, T1486 and T1490 (inhibit system recovery), moved to tier 1 and were put in the plan for the red-team range, because neither can be run in production in a reversible form. The re-ranking was accepted by the group CISO on the proposal of the red-team lead, Mareike Hartmann, with the white-team lead reviewing and Lena Vogel's detection-engineering team nominating techniques without the power to remove one; the decision is AIDR-0851 (2028-02-08). The scenario curator under MND-HM-EMU-02 proposed 17 drafts in its first month. Mareike Hartmann's review accepted six, five of them variants of existing scenarios, and rejected eleven, seven as duplicates. The accepted draft that addressed a new technique chain became SCN-HM-0087. The curator's proposals were also compared with the priority list: none concerned T1486 or T1490, which confirmed the expectation that an agent drawing on public reporting would not propose the hard techniques unprompted. The threat-led test for the German entity (RoE-HM-2027-TLPT) follows the supervisor's selection process, and the library feeds it without deciding it.

The difference is of kind. Nordvik's risk at P1 Target is a list that is built once and then ages because nobody has the hours to review it; the contract term and the six-monthly review in AIDR-0801 are its answer. Hansa's risk is a large library that grows because scenarios are cheap, and a list that the tested side quietly shapes; the separation of nomination from removal and the reserved share of hard techniques are its answer.

Summary

This chapter described P1 Target, the stage in which the loop decides what to test. Intelligence, the threat register, risk assessment and incidents supply the questions, and the party that proposes scenarios is not the party that selects them. ATT&CK and ATLAS supply a shared vocabulary that is used at the level of identifier and parameter, never of procedure, and the release of the knowledge base is recorded. Priority techniques are chosen by impact, relevance and uncertainty about the defence, in coarse tiers, with reasons, and not by novelty. The scenario record, held as code, carries source, techniques, expected outcome per layer, safety class, evidence rule, owner and classification. It is the unit that P2 Emulate executes, that P3 Observe compares with its expectation, that P4 Improve corrects and that P5 Verify re-runs.

AI proposes scenarios at Level 1 Assisted, and a named person accepts each one, with the reviewer's work measured. The main hazard of the stage is the library that grows toward what is easy to emulate. The structural answers are gaps reported as gaps, a reserved share of hard techniques, a check of the curator's mix and a protected class of human-authored scenarios. Out-of-scope, unsafe, unauthorised and not-worth-testing scenarios go to an exclusion register. A technique that is excluded is untested, and untested is not covered.

These conclusions are the book's own. What a reader can do on Monday is to write the list: take one service, build the first priority list of 20 to 40 techniques by the practical guide, mark which entries are hard to emulate, and put a review date on it. Chapter 6 sets the rules of engagement under which the scenarios on that list may run, and Chapter 7 describes how a plan is built from them.

Sources

1. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (2, European Union, 2022)
2. 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). (3, European Union, 2022)
3. European Parliament and Council of the European Union. Regulation (EU) 2016/679 (General Data Protection Regulation). (7, European Union, 2016)
4. MITRE Corporation. MITRE ATT&CK. (17, MITRE, n.d.)
5. MITRE Corporation. MITRE ATLAS. (18, MITRE, n.d.)
6. MITRE Corporation. MITRE D3FEND. (19, MITRE, n.d.)
7. European Central Bank. TIBER-EU: Threat Intelligence-Based Ethical Red Teaming framework. (20, ECB, 2025)
8. OWASP Foundation. OWASP Top 10 for Large Language Model Applications, 2025 edition. (21, OWASP, 2025)
9. OWASP Foundation (2025). OWASP Top 10 for Agentic Applications for 2026. (22, OWASP, 2025)
10. OASIS Cyber Threat Intelligence (CTI) TC. STIX Version 2.1 and TAXII Version 2.1. (27, OASIS Cyber Threat Intelligence (CTI) TC, 2021)
11. SigmaHQ. Sigma: Generic Signature Format for SIEM Systems. (30, SigmaHQ, n.d.)
12. European Union Agency for Cybersecurity (2025). ENISA Threat Landscape 2025. (51, ENISA, 2025)
13. Mandiant (2026). M-Trends 2026. (62, Mandiant, 2026)
14. Nordqvist, G. (2025). Architecture as Code. (87, Nordqvist, 2025)
15. Nordqvist, G. (2026). AI Red Team. (90, Nordqvist, 2026)
16. Nordqvist, G. (2026). AI Threat. (91, Nordqvist, 2026)
17. Parasuraman, R. & Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation: An Attentional Integration. (101, Parasuraman & Manzey, 2010)
18. Nordqvist, G. (2026). AI Blue. (94, Nordqvist, 2026)
19. Center for Threat-Informed Defense (2024). Top ATT&CK Techniques. (31, Center for Threat-Informed Defense, 2024)
20. European Commission (2025). Commission Delegated Regulation (EU) 2025/1190 on threat-led penetration testing. (8, European Commission, 2025)