The Pressure on the Loop: Machine-Speed Adversaries, Detection Decay and the Annual Test

Chapter 2 described the loop as it ran before AI joined it: a penetration test, a red team engagement, a tabletop, a purple session, each an event with a start and an end. This chapter explains why that rhythm no longer fits. Four things move faster than a yearly or quarterly event can follow: the window between disclosure and exploitation, the estate that is being defended, the detections that defend it and the list of findings that are meant to improve it. Two more things stay scarce: the hours of people who can emulate an adversary or write a detection, and the patience of a compliance regime that is satisfied by an annual report. The chapter then separates what open tooling already made cheap, repetition, from what AI is expected to make cheaper, variation and drafting, and it keeps apart what AI does not make cheaper.

The chapter concerns every stage of the loop, because the pressure falls on all five. P1 Target is pressed because the list of priority techniques ages faster than its review. P2 Emulate is pressed because an annual campaign samples a moving estate once. P3 Observe is pressed because a detection that fired in March may not fire in September. P4 Improve is pressed because findings wait for a control. P5 Verify is pressed hardest, because a finding is closed only when a re-test passes and the evidence is attached (Chapter 4), and the traditional rhythm has no re-test in it.

Figure 3.1: Four pressures between tests, and how an annual rhythm and a pipeline rhythm each meet them.

The chapter builds on conclusions of the earlier volumes and does not repeat them. AI Platform and Security, Chapter 18, concluded that AI-enabled adversaries collapse the exploitation window and set four commitments against them: patch velocity as a measured service level, detection at machine speed with the authority to act, identity and approvals that resist synthetic media, and AI for defence under oversight, in which human verification is the bottleneck (89, Nordqvist, 2026). AI Threat, Chapter 18, treated cyber offence at machine speed from the standpoint of evidence (91, Nordqvist, 2026). AI Governance, Chapter 24, concluded that patch decisions must be delegated in advance, because a weekly change advisory board cannot sit in the path of a known-exploited vulnerability (88, Nordqvist, 2026). AI Blue, Chapter 3, described the same pressure from the blue team's side: machine-speed adversaries, alert volume and scarce talent (94, Nordqvist, 2026). This chapter takes those conclusions as given and asks what they mean for the loop between the teams, which tests, repairs and re-tests the defence.

The shrinking window

The traditional rhythm rests on an assumption that the interval between a weakness becoming known and its use against a target is longer than the interval between tests, or at least that a test can find what matters before it is used. The evidence that the assumption is weakening is documented, and it comes from several independent sources.

Mandiant's analysis of time-to-exploit reports an average of 63 days for vulnerabilities exploited in 2018 and 2019, 32 days for 2021 and 2022, and 5 days for 2023, with 70 per cent of the 138 exploited vulnerabilities of 2023 exploited as zero-days, before a patch was available (61, Charrier & Weiner, 2024). The analysts excluded 15 outliers from the five-day figure and report 47 days without the exclusion, so the figure is best read as a direction and a method, not as a constant. Its successor in M-Trends 2026 reports an estimated mean time to exploit of minus seven days for the 2025 data, meaning that exploitation on average began before a patch existed, and it records exploits as the most common initial infection vector for the sixth year running, at 32 per cent of intrusions (62, Mandiant, 2026). The Verizon Data Breach Investigations Report of 2025 found that exploitation of vulnerabilities was the entry point in 20 per cent of breaches, a 34 per cent rise on the year before, and that of the edge-device and VPN vulnerabilities it followed only 54 per cent were fully remediated, with a median of 32 days to fix (57, Verizon Business, 2025).

The Google Threat Intelligence Group adds the volume. Its 2026 analysis counts disclosed vulnerabilities rising from 5,045 in January 2026 to 10,740 in August 2026, an average of 10.5 exploited vulnerabilities a month in 2025 against 18 a month from January to August 2026, and 141 vulnerabilities both disclosed and exploited in those eight months against 127 in the whole of 2025 (65, Grunewald et al., 2026). Two cautions belong beside the counts. The same report says that only 0.23 per cent of disclosed vulnerabilities in 2026 were exploited, and that some 5,000 of the disclosures were Linux kernel entries with no observed exploited zero-days, so the headline growth overstates the exposure of any single estate. And the report is guarded about the mechanism by which AI acts: it says that AI is measurably changing the pace and kind of vulnerability discovery and exploitation, suggests that growth in exploitation is concentrated in the rapid weaponisation of already-patched vulnerabilities, and says it is possible that adversaries use language models to analyse patches and proof-of-concept code, without establishing that they do. It calls the link between AI-discovered flaws and exploitation an early indicator, not an established trend. In its own example, a threat cluster was observed exploiting a disclosed BeyondTrust vulnerability within four days of disclosure, and five more within seven days. The UK National Cyber Security Centre expects the pressure to arrive on the defender's side as a "patch wave", a rush of software updates and a forced correction of technical debt across all types of software, and advises organisations to plan to apply updates quickly, more frequently and at scale (53, NCSC, 2026).

What this means for the loop is the book's own conclusion, drawn from those figures and not stated by them. A control that depends on a patch being applied, or a detection written for a technique as it was known last quarter, has a shorter useful life than the interval between two annual tests. The test is still necessary, but it describes the estate on the days it ran. The three questions the loop must be able to answer are what was tested, when, and with what result (Chapter 4); an annual test answers the first correctly and the second with a date that is already old when the report is read.

Adversaries that vary and repeat

The window is one half of the pressure. The other half is that an adversary can chain known techniques faster. The Google Threat Intelligence Group and Mandiant describe agentic offensive frameworks used in incidents from late August 2026: in one campaign attributed to a single threat cluster the time from the first compromised account to deep system access was typically about four hours and in one case as little as 15 minutes, with execution sequences running in bursts of roughly two to 25 seconds (66, Blum et al., 2026). The same report is careful in a way a defender should copy. The tools are noisy, one web-server exploitation produced 240 log events, they rely on trial and error, and they "trade stealth for velocity". The techniques are not new, much of the activity may use valid credentials and supported functionality, and the report's guidance is to detect behavioural and volumetric change and to correlate sequences across telemetry. Mandiant's incident data show the same compression in hand-off: the median time from initial access to hand-off to a second group fell from more than eight hours in 2022 to 22 seconds in 2025 (62, Mandiant, 2026).

For a loop that emulates adversary behaviour, the point is practical. A scenario library written for a human operator's pace tests a sequence at a pace the adversary no longer needs to keep. A detection that triggers on the third step of a chain after an hour has not been tested against a chain that completes in minutes. Chapter 8 returns to this when it designs continuous emulation, and Chapter 9 when it measures how long each layer took.

An estate that changes faster than the test

The second pressure is on the defender's side of the table. A test describes the estate it ran against. The estate then changes: a release, a configuration change, a new log connector, a retired identity provider tier, a model update. The standard measure of how often a software organisation changes production is deployment frequency, defined as the number of deployments over a period or the time between deployments (43, DORA (DevOps Research and Assessment) & Google Cloud, n.d.). The loop's concern is narrower and can be measured by the loop itself: how many changes touched the path of a priority technique between two verifications of that technique.

The book calls this the test-to-change ratio. For a given technique, it is the number of production changes that touch what the technique depends on (the service it targets, the identity path it uses, the log source and the detection that should fire) between two passing tests. A ratio of one means that every change was followed by a verification. A ratio of twenty means that twenty changes accumulated before anyone looked, and that if the twentieth broke something, the test cannot say which of the twenty did.

The two organisations illustrate the range. Nordvik Region's annual penetration test covers a benefits-triage service that the Region releases every two weeks, so 26 releases fall between two annual tests of the same service, before counting the quarterly retraining of the provider's ranking model that the Region's own profile records. Hansa Mutual's quarterly purple sessions cover 34 priority techniques while the estate changes daily; with about 60 working days between sessions, the ratio for a technique on a path that changes every working day is of the order of 60 (the book's arithmetic from the profile, not a measurement). Hansa's rule that evidence for a priority technique expires after 90 days sits at the same interval as its quarterly session, which means that evidence is on the point of expiring on the day each session ends and every claim of coverage is stale before the next session begins. That is a design finding about the cadence, not about the people.

Practical guide: Estimating a team's test-to-change ratio

Purpose. To find out, from records the team already holds, how many production changes occur between two verifications of a priority technique, and to decide where the cadence must change.

Roles. The purple team coordinator (a role, not a team; Chapter 4) leads. The detection owner supplies the detection and log-source dependencies. The platform or release owner supplies the change log. The white-team lead reviews the result.

1. Choose the priority techniques (Chapter 5). Start with the ten that matter most if the list is long.
2. For each technique, write down its dependency path: the service or identity it targets, the log source, the detection record DET-* and the playbook PBK-* that follow.
3. From the change log, count changes that touched anything on that path in the last 12 months. Count a release of the targeted service, a connector or schema change, a rule-engine upgrade, a change of identity provider configuration and a model or mandate update. Do not count changes elsewhere.
4. From the coverage and evidence records, list the dates of passing tests of the technique in the same 12 months, and divide: changes per passing test.
5. Mark any technique whose ratio exceeds 10, or whose last passing test is older than its evidence expiry (90 days for a priority technique at Hansa Mutual; 180 days at Nordvik Region), as unverified in the coverage record.
6. Choose the remedy per technique: a trigger (re-run the scenario after a change on the path, which brings the ratio towards one), a schedule (every 30 days for a priority technique where triggers are not available), or an accepted gap with a named authority and an expiry (Chapter 20).

The defaults are the ones this book uses in Chapter 8: every 30 days for a priority technique and after any change to a detection, a connector or a mandate. Adapt them to the contract, to what a re-run costs and to the safety class of the scenario (Chapter 6); a scenario above S1 cannot run on a trigger in production.

Definition of done. A table with one row per technique showing changes, passing tests, ratio, last passing test and the chosen remedy, reviewed by the white-team lead and dated.

Detection decay

A detection is a record with logic, data sources, mapping, tests, owner and review date (AI Blue, Chapter 6), and it counts only when a recent test shows that it fires. It decays for reasons that are mundane: the log source changes its schema, a field is renamed, a collector is upgraded, an identity provider tier stops emitting an event, an exclusion added to quieten one noisy rule hides the case that mattered, an owner leaves. The detection logic is unchanged, and the world it reads is different.

One external observation and the book's own illustrations bear on the claim that this is common. A vendor-published summary of breach-and-attack simulations (the Picus Blue Report 2025, over 160 million simulated attacks in the first half of 2025, not peer reviewed) reports that about 54 per cent of the simulated activity was reflected in the logs, that 14 per cent of simulated attacks generated an alert, that prevention effectiveness fell from 69 to 62 per cent in a year, and that half of the detection-rule failures were caused by log-collection problems (108, Zorz, 2025). The population is the vendor's customers and the simulations are the vendor's, so the figures describe those environments, not all organisations. The book's own illustrations, which are constructed and are not evidence, show the same mechanism: the Swiss audit log not forwarded pending a transfer decision, the document-store log kept for seven days at source and the identity provider tier that emits no token-use events are all decay in the telemetry layer, and none of them is a defect in a rule (Chapter 9). At Nordvik Region, DET-NR-0001 passed its regression case on 2027-11-17 and failed a night-hours variant on 2028-01-19, 63 days later, with detection taking 41 minutes; the finding was reopened as FND-NR-2028-002 (Chapter 11). The detection had not changed in the interval. The conditions it was tested under had.

The measure that follows is age: days since the last passing test, set against the evidence expiry, together with the count of changes to the detection's dependencies since that test. Age alone misleads in both directions, since a detection tested yesterday on a connector replaced this morning is stale, and a detection untested for 80 days on a source that has not changed is probably sound. The two together separate three states, and the book's rule is to report them as three and never as one.

Worked example: A decay estimate for three detections at Hansa Mutual

The record below is illustrative. It is dated 2028-02-05, before the finding of Chapter 10 led to the retirement of DET-HM-0201, and it uses no figure that is not derived from its own dates. A detection is current if it passed a test within its evidence expiry and no dependency has changed since; at-risk if it is within expiry but a dependency has changed; expired if the last passing test is older than the expiry.

# Illustrative: Hansa Mutual, decay estimate for three detections
record: DCY-HM-2028-01
estimated_on: 2028-02-05
estimated_by: detection-engineering        # lead Lena Vogel
reviewed_by: white-team-lead
expiry_days: { priority: 90, other: 180 }
detections:
  - id: DET-HM-0455            # service account used from a new host
    technique: T1078
    priority: true
    last_passing_test: 2027-12-14
    age_days: 53
    dependency_changes_since_test:
      - identity-provider log connector upgraded 2028-01-11
    state: at-risk
    action: re-run scenario on the connector change, due 2028-02-12
  - id: DET-HM-0388            # mailbox forwarding rule created
    technique: T1114.003
    priority: false
    last_passing_test: 2027-09-06
    age_days: 152
    dependency_changes_since_test:
      - mail-gateway field renamed 2027-12-02
      - rule-engine upgrade 2028-01-08
    state: at-risk
    action: re-run before expiry on 2028-03-04, trigger on next schema change
  - id: DET-HM-0201            # cloud identity credential added
    technique: T1098.001
    priority: true
    last_passing_test: 2027-07-19
    age_days: 201
    dependency_changes_since_test:
      - audit-log source reassigned, owner not updated
    state: expired
    action: re-test now or retire; coverage record shows technique unverified
summary: { current: 0, at-risk: 2, expired: 1 }

Three points follow from the record. First, no detection is current: each has a dependency that changed after its last test, which is what a daily-changing estate produces. Second, the oldest detection is the cheapest to deal with, because an expired state makes the coverage claim for its technique visibly false and demands a decision. Third, the two at-risk detections would have passed a dashboard that shows only whether a rule exists and is enabled. A coverage statement that cannot show age (Chapter 17) hides exactly this.

The finding half-life

A finding enters the loop at P3 Observe and leaves it at P5 Verify. The time it spends in between has two parts: the wait for a change (P4 Improve) and the wait for a re-test. The first is observable in public data. Verizon's figures for edge-device vulnerabilities, 54 per cent remediated, median 32 days, show that even where the change is a patch and the vendor has done the work, a large share of the population was still not fully remediated at the end of the observation period (57, Verizon Business, 2025). The Hansa Mutual figure carried over from AI Blue is a finding-to-control median of 19 days at BTP-HM-2027-Q3 (AIDR-0778), which is a fast median by those standards and still means half of the findings wait longer.

The second part is the loop's own. In the traditional rhythm a finding from an annual test has no re-test until the next annual test, unless one was bought separately, so a finding that was fixed in week three is verified, if at all, eleven months later; a finding that was not fixed is rediscovered. The book's conclusion, which the sources do not establish for any specific organisation, is that many findings stalled for want of a re-test and not for want of a fix: the change was made, nobody was assigned to prove it, and the register showed the finding as open or, worse, closed at merge. The white-team sample of Chapter 4 illustrates the conclusion, as a constructed case and not as evidence: of 20 findings closed in the third quarter of 2027 at Hansa Mutual, 14 had a re-test log and an evidence manifest and six had been closed when the change merged.

The regulatory text points the same way. DORA requires financial entities, other than microenterprises, to establish procedures to prioritise, classify and remedy all issues revealed during testing, and internal validation methods to ascertain that identified weaknesses, deficiencies or gaps are fully addressed (Article 24(5)) (2, European Union, 2022). Validation that weaknesses are fully addressed is a re-test by another name. The architectural implication is that the register needs a state for "implemented, unverified" and a clock on it (Chapters 4 and 10), because a finding can be fixed in the change system and open in the risk sense simultaneously.

Scarce talent on both sides

The last pressure is on people. The loop needs red-team operators who can write a convincing scenario, detection engineers who can turn an observation into a tested rule, and analysts who can tell a real signal from a seeded one. The ISC2 2025 Cybersecurity Workforce Study, an online survey of 16,029 practitioners in May and June 2025, found that 88 per cent had experienced at least one significant consequence of a skills shortage, that 33 per cent said their organisations lack the resources to staff their teams adequately, and that AI was the most cited skill need, at 41 per cent (99, ISC2, 2025). The survey does not isolate red-team or detection-engineering roles, so it describes the field and not the loop.

The two organisations show the shape of the constraint. Nordvik Region has no in-house red team, six analysts in office hours and a contracted tester, so each purple session is a draw on a fraction of one person's time (Karin Lund, detection owner and purple team coordinator). Hansa Mutual has a group red team of five, a detection-engineering team of four and a SOC of about 38, and 86 scenarios to keep alive against 34 priority techniques. Both are short of the same thing: hours of judgement. An annual test spends those hours in one block and leaves the rest of the year without them; a pipeline spends them on novelty and on reviewing machine output, which is a different load, discussed in Chapter 23, and not a smaller one. AI Threat, Chapter 6, found that reliance on AI reduces effort and, among those who trust the tool, checking, and identified the risk that automating junior work removes the route by which experts are made, a risk it took up again in Chapter 14 (91, Nordqvist, 2026). A loop that saves red-team hours by automating the junior tasks may leave the loop short of experts later (expected; Chapter 24 sets out the response).

The calendar that rewards a report

A last pressure comes from the rules that shape the calendar. DORA requires financial entities, other than microenterprises, to ensure at least yearly that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions (Article 24(6)), and to carry out advanced testing by means of threat-led penetration testing at least every three years for the entities in scope (Article 26(1)) (2, European Union, 2022). Both are minimum frequencies, and both are sensible. The risk is a management habit that treats the minimum as the design: a yearly test satisfies the clause, produces a report, and is entered as compliance. The Commission's Delegated Regulation on threat-led testing sets the scope, methodology and approach of the phases of such a test (8, European Commission, 2025), and the ECB's TIBER-EU framework prescribes the roles and the control group (the white team of this book, the control team in the ECB's current text) that Chapter 4 uses (20, ECB, 2025). Neither instrument says that a yearly test is the whole of verification, and the minimum for a threat-led test does not limit the frequency at which a catalogued scenario may be re-run. Chapter 21 treats the regulation as a constraint on the design of the loop. For the present chapter the point is that a calendar set by the clause is an annual calendar, and an annual calendar is the rhythm the other pressures defeat.

For a public authority such as Nordvik Region, the pressure takes another form: procurement. A test is bought per system, a scope is written, a report is delivered and the contract ends. A re-test is a second purchase that nobody has budgeted, unless the call-off agreement made it part of the first. That is one reason the Region's NR-2026-071 includes test rights and a rules-of-engagement template and the managed-detection annex MS-2 carries its own injected tests: they turn a purchase into a rhythm.

What AI makes cheaper and what it does not

The pressures above are not new in kind. Open tooling already makes repetition cheap (Chapters 1 and 2); AI is expected to make variation and drafting cheaper, which is not yet measured in any cited source, and the loop should be redesigned around that without assuming that AI changes a third cost.

Variation is expected to become cheaper. A catalogued scenario has parameters: the account, the host, the hour, the rate, the tool that performs the technique. A tester varying them by hand tests a few combinations. An agent that varies them inside written bounds can test dozens, and the variants that evade a detection are the useful output, since they show whether the detection recognises the technique or only the instance. The constructed case of Hansa Mutual's first quarter of 2028 in Chapter 8 illustrates the effect, and is not evidence for it: detections fired on 90 per cent of known-form scenarios and on 71 per cent of held-out variants. That gap of 19 points is invisible to an annual test that runs only the known form.

Repetition is already cheaper. A catalogued, reversible scenario that can run on a schedule and after a change costs compute and review time, not a week of a tester's time. That is what turns a yearly event into a pipeline, with or without a model, and it is the reason the loop's rhythm can follow the estate. It is also why Chapter 8 can promise a ratio near one for the paths that change, and Chapter 11 can promise that a regression case runs after every fix.

What does not become cheaper. Four things stay costly, and each has a chapter. Novelty still comes from people: the technique chain no one catalogued is found by an operator with an adversary's habits of mind, which is why the human-led exercise remains in the design (Chapters 7 and 24). Judgement of what a result means is still slow: AI Platform and Security, Chapter 18, put it as human verification being the bottleneck, and every machine-drafted change adds to the queue that reviewers must clear (Chapter 10). Independence is not free: a loop in which one model family plans the scenario, drafts the detection and judges the result has correlated failures that raise confidence without raising assurance, and Chapter 15 sets out the principle that keeps the two sides of a check from sharing a failure. And safety is not free: an emulation agent holds offensive capability and privileged access, and the controls that stop it must sit outside it (Chapter 6; AI Threat, Chapter 25, on agents that acted beyond their mandate) (91, Nordqvist, 2026).

A further conclusion of the earlier volumes applies here. A control is a defence only when a test that re-runs its scenario has passed recently and produced evidence by operation (AI Threat, Chapter 30). That is the sentence the pressure puts under strain: "recently" has a shorter meaning than it had, and the loop must be able to say how recent.

Observable, expected, speculation

That AI-assisted adversaries operate and that exploitation windows have shortened is observable, on the evidence of the sources cited above: time-to-exploit measured at 5 days for 2023 and estimated as negative for 2025, agentic offensive frameworks seen in incidents, hand-off between intruder groups measured in seconds. That the link between AI and the growth in exploitation is established is not observable: the Google Threat Intelligence Group calls the link an early indicator and the specific mechanism a possibility, and this chapter keeps that label. That continuous verification, with scheduled and change-triggered re-tests, becomes the normal way of keeping a high-risk estate's defence current is expected, as a consequence of the cost of repetition and of the age requirement that supervisors already place on tests (DORA Article 24); the evidence is the trend and the instruments, and not yet a body of measured outcomes. That a defence could improve itself continuously with no human-authored novelty, no independent verification and no review is speculation, and Chapters 15 and 25 give the reasons for treating it so.

Across the usage modes

The pressure falls differently according to how AI is deployed, because the mode sets whose identity the AI uses and therefore what it changes about the rhythm.

Usage mode	Where it already sits in testing and detection	Effect on the pressure
Pre-AI baseline	Annual penetration test, red team engagement, quarterly session	The rhythm this chapter describes
Mode 0 Ambient AI	Features inside simulation and detection products, and the provider's own alert closure	Changes the detection layer between tests without a record of the change; a decay source
Mode 1 Conversational assistants	A tester drafts a scenario variant or summarises a result	Speeds one person; the cadence of the loop is unchanged
Mode 2 Embedded workplace assistants	Drafting in the ticketing or document tools	Speeds record keeping; a draft is not a record
Mode 3 Agentic work tools	A practitioner's agent assembles a plan or a timeline with the practitioner's credentials	Speeds one person further; the reach of the credentials becomes the risk
Mode 4 Built AI applications	A scenario curator, an observation correlator or a critic with read-only access	Changes the cost of variation and of observation; the cadence can follow the estate
Mode 5 Autonomous production agents	An emulation runner or re-test runner with an identity of its own	Changes the cadence: scheduled and change-triggered runs; adds an offensive capability to be contained

Modes 1 to 3 make each tester faster and leave the rhythm as it was. Modes 4 and 5 change the rhythm, and so they change what the loop has to protect and verify; the later chapters, from Chapter 12, treat what follows from that.

Nordvik Region and Hansa Mutual

Nordvik Region procures an annual penetration test per system and has never run a threat-led exercise before the programme of RoE-NR-2027-001. Its annual test covers a benefits-triage service that is released every two weeks, which gives a test-to-change ratio of about 26 for the service as a whole, and its two catalogue runs a year by the testing firm, with the managed provider's quarterly injected tests, lower the figure for the techniques in the catalogue and not for the rest. Its pressure is the contract: a re-test that was not bought does not happen, and its small team cannot absorb extra sessions. DET-NR-0001 shows the decay in miniature. Its remedy is to tie triggers to the change notices it already receives and to write the re-test into the agreements (Chapter 19).

Hansa Mutual runs the loop and carries the opposite pressure: many sources of findings, daily change and a quarterly session that cannot keep pace. Its findings wait a median of 19 days for a control, 25 of its 34 priority techniques were verified at BTP-HM-2027-Q3, and the decay estimate DCY-HM-2028-01 above shows no detection in the sample as current. Its remedy is the pipeline of Chapter 8, HM-SEC-004, with a rule that each priority technique is exercised every 30 days and after a change; the board's question whether that makes the quarterly session redundant is the subject of Chapters 8 and 15 and of the report due on 2028-04-30. The two organisations are under the same pressure and meet it through different levers: Nordvik through terms, Hansa through a platform.

Summary

The rhythm of the traditional loop assumed that the window between disclosure and exploitation was longer than the interval between tests, that the estate held still between them, that a detection that worked in March would work in September, that findings were fixed and proved in due course, and that the people to run all this were available. The sources cited in this chapter show each assumption weakening: time-to-exploit measured at 63 days, then 32, then 5, and estimated as negative for 2025; initial access handed on in seconds; vulnerability disclosures roughly doubling in eight months; detections failing for want of log collection; edge-device fixes taking a median of 32 days with only 54 per cent complete. The link between AI and the growth in exploitation is an early indicator, and its mechanism a possibility, in the source that reports it, and the chapter states it the same way.

The pressure falls on every stage of the loop. P1 Target needs a priority list that is reviewed when the threat changes. P2 Emulate has to follow the estate and not the calendar. P3 Observe has to measure the age of every result and the decay of every detection, in three states and not one. P4 Improve has to count the wait for a change. P5 Verify is the stage the annual rhythm lacks, and the one the rest of the book builds up: a re-test after each fix, a regression case in the library, and evidence with a date. The test-to-change ratio is a measure any team can calculate from its own records, and the decay estimate is the way to make a coverage claim show its age.

Open tooling already makes repetition cheap; AI is expected to make variation and drafting cheaper, and so to widen what continuous verification can cover. It does not make novelty, judgement, independence or safety cheaper, and a design that assumes it does will move the bottleneck without removing it. Chapter 4 defines the loop that meets the pressure: five stages, the records they produce, the closure rule, the degrees of delegation and the independence principle.

Sources

1. 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)
2. European Central Bank. TIBER-EU: Threat Intelligence-Based Ethical Red Teaming framework. ECB, framework updated January 2025. (20, ECB, 2025)
3. National Cyber Security Centre (2026). Preparing for a 'vulnerability patch wave'. NCSC blog, 1 May 2026. (53, NCSC, 2026)
4. Charrier, C. and Weiner, R. (2024). How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends. Mandiant, Google Cloud Blog, 15 October 2024. (61, Charrier & Weiner, 2024)
5. Mandiant (2026). M-Trends 2026: Data, Insights, and Strategies From the Frontlines. Google Cloud Blog, 23 March 2026. (62, Mandiant, 2026)
6. Grunewald, R., Mazumdar, S. and Vanderlee, K. (2026). Vulnerability Discovery and Exploitation Trends in the AI Era. Google Threat Intelligence Group, 30 September 2026. (65, Grunewald et al., 2026)
7. Blum, Mainor, Nambiar et al. (2026). ARTEX and Friends: Enter Agentic Offensive Frameworks. Google Threat Intelligence Group and Mandiant, 30 October 2026. (66, Blum et al., 2026)
8. European Commission (2025). Commission Delegated Regulation (EU) 2025/1190 supplementing Regulation (EU) 2022/2554 as regards regulatory technical standards specifying the criteria used for identifying financial entities required to perform threat-led penetration testing. (8, European Commission, 2025)
9. Nordqvist, G. (2026). AI Governance. The Transformed Architecture, Book 2. (88, Nordqvist, 2026)
10. Nordqvist, G. (2026). AI Platform and Security. The Transformed Architecture, Book 3. (89, Nordqvist, 2026)
11. Nordqvist, G. (2026). AI Threat. The Transformed Architecture, Book 5. (91, Nordqvist, 2026)
12. ISC2 (2025). 2025 Cybersecurity Workforce Study. (99, ISC2, 2025)
13. Nordqvist, G. (2026). AI Blue. The Transformed Architecture, Book 8. (94, Nordqvist, 2026)
14. Verizon Business (2025). 2025 Data Breach Investigations Report. (57, Verizon Business, 2025)
15. Zorz, M. (2025). Weak alerting and slipping prevention raise risk levels for CISOs. Help Net Security, reporting the Picus Security Blue Report 2025. (108, Zorz, 2025)
16. DORA (DevOps Research and Assessment). DORA's software delivery performance metrics. (43, DORA (DevOps Research and Assessment) & Google Cloud, n.d.)