Published

Incident Response

vr.wm-act-042 · wm-act-042-incident-response

Provide the format-neutral context an agent needs to open, operate, inspect and close an incident response engagement from detection through containment, recovery coordination and lessons learned.

World Models Activities and processes ACT.INC

Bundle → Layer → Finding → Questions Classifiers What it is Why it exists Distinguishing features What robots and AI may and may not do Moral aspects Owners Links to other meta-models Identity and identifiers Direct properties Recognition Capabilities and actions Hazards and failure modes Standards and interfaces Context of use Sources

Bundle → Layer → Finding → Questions Filled

7 bundles · 15 layers · 26 findings · 108 questions

Mandate, Authority and Readiness Who is empowered to respond, with what authority and decision rights, and what preparedness the capability relies on when a case opens.

Response Mandate and Authority

The declared charter, constituency, service scope and the decision rights exercised during a case.

Response capability charter and constituency

The published mandate of the responding capability: mission, constituency, sponsorship, authority level over constituent systems, supported incident types and level of support.

What authority does the responding capability hold over constituent systems, and is it advisory, shared or full? authority
Which constituency, sites and organisational units does this capability serve? ownership
Which incident types are supported and at what declared level of support? definition
Which published version of the service description governs this case, and when was it last updated? provenance

Case roles and decision rights

Named roles engaged on the case, their delegated decision rights, handover points and the escalation trigger to crisis management.

Who holds the decision right for containment actions that disrupt production services? authority
How is case ownership handed over between shifts or teams without losing accountability? process
Which condition escalates the case from response coordination into crisis management support? exception
How are conflicts between response, legal and business owners recorded and resolved? decision

Preparedness Baseline

Which governing procedure version and which readiness preconditions the case relies on.

Governing playbook and procedure binding

The identity, version and validity window of the playbook, procedure or plan invoked to govern the case, plus whether the case runs ad hoc.

Which playbook or procedure version governs this case, and is it still within its validity window? identity
What playbook type applies, such as detection, investigation, mitigation or remediation? classification
If no playbook exists for this situation, what is recorded in its place? exception
How is the bound playbook version verified as unaltered at the moment of binding? validation

Readiness preconditions relied upon

The readiness state the case depends on: reachable contacts, available tooling access, current training and exercise evidence, referenced rather than re-assessed.

Which readiness preconditions must hold before this response tier can be operated? requirement
What external assessment or exercise evidence is relied upon, and when was it produced? evidence
Which readiness gaps were known and accepted at the time the case opened? quality
Are out-of-band contact and authentication means available if primary channels are compromised? security

Case Identity, Scope and Triage How the response case is identified, bounded and prioritised, and how it binds to external classification vocabularies.

Case Identification and Scope

The identifiers, cross-references and perimeter that define which response engagement this is.

Response case identity, cross-references and perimeter

The authoritative case identifier, identifiers held by cooperating parties, the reference to the incident record handled, and the declared perimeter of the engagement.

What is the authoritative identifier of this response case and which system issued it? identity
Which tracking numbers do cooperating teams, vendors or authorities use for the same engagement? relationship
Which incident record does this case handle, and is the link one-to-one? composition
What is inside the response perimeter and what was explicitly excluded from it? spatial
How are duplicate or related cases merged, split or superseded without losing identifiers? lifecycle

Triage and Classification Binding

The response-side prioritisation decision and the bindings to external classification vocabularies.

Triage decision and response tier

The recorded decision assigning a response tier, target response clocks and resourcing, together with the criteria version applied.

What response tier was assigned, by whom, and against which criteria version? decision
Which response clocks start on triage and what are their targets? temporal
Under what conditions is the response tier re-evaluated during the case? state
How does the assigned response tier relate to the severity held on the incident record? relationship

External classification and technique bindings

Bindings from the case to external vocabularies for incident class, adversary technique and exchange-format attributes, always with catalogue version.

Which external classification class and type were assigned, from which taxonomy version? classification
Which adversary techniques are referenced and against which catalogue version? interoperability
What is the declared purpose of documenting this case for exchange, such as mitigation, reporting or traceback? interoperability
How are bindings revalidated when an external catalogue publishes a new version? validation

Detection Intake and Analysis How the engagement was triggered, how an event became a declared incident, and what the analysis concluded for response purposes.

Detection and Report Intake

Receipt of the trigger and the decision that promotes it to a handled incident.

Detection and report intake

How the engagement was triggered: discovery source, reporting party, channel, submitted content and receipt acknowledgement.

By which discovery source was the situation first noticed, such as monitoring, audit, external notification or law enforcement? provenance
Who reported the situation and how was the reporting party authenticated? identity
What acknowledgement was returned to the reporter and within what interval? process
How complete and reliable was the initial report, and what was missing? quality

Event to incident declaration

The decision that promotes one or more events to a declared incident under response, including the declaring authority and the basis.

Who declared the incident and under which delegated authority? authority
On what basis was the event judged to be an incident rather than a near miss or false positive? definition
How is a declaration reversed if analysis later shows no incident occurred? exception
Is a near miss recorded even when no incident is declared, and where? event

Investigation and Analysis

Analytical conclusions and the response-side impact assessment that drive containment and notification decisions.

Analysis findings, hypotheses and confidence

Working hypotheses, supporting and contradicting observations, confidence, and the root cause status as understood during response.

What hypotheses about the attack path are open, and what would falsify each one? quality
What confidence is attached to each conclusion and on what scale? measurement
Has a root cause been established, and is it provisional or confirmed? state
Which observations underpin a finding and where are the underlying data held? provenance

Response-side impact assessment

The assessed impact used to drive response decisions and notification thresholds, distinguished from the incident model's authoritative impact facts.

Which impact categories are assessed for response purposes and on what scale? measurement
What is the current estimate of affected parties or records, and how uncertain is it? measurement
Does the assessed impact cross a reporting or escalation threshold, and which one? constraint
Is cross-border or multi-jurisdiction impact likely, and on what basis? spatial

Response Actions and Recovery Coordination Authorisation and tracking of response actions, deviations from the governing playbook, and the coordination interface to continuity and recovery plans.

Action Authorisation and Tracking

What was authorised, by whom, with what intended effect and what recorded outcome reference.

Response action authorisation and outcome reference

Each authorised containment, eradication or mitigation action with its target reference, approver, requested and completed times and a reference to execution evidence held by the executing system.

Which action was authorised, against which target, and who approved it? authority
What effect was the action intended to achieve and how would success be recognised? requirement
Where is the evidence that the action was carried out, and who holds it? evidence
Is the action reversible, and what is the rollback path if it causes harm? constraint

Containment decisions, trade-offs and playbook deviations

Recorded decision points where containment competed with evidence preservation or service availability, and any departure from the bound playbook.

Which trade-off between containment speed, service availability and evidence preservation was chosen and why? decision
Where did the response depart from the bound playbook, and who approved the departure? exception
What conditions would abort or reverse the containment strategy? constraint
Which dependencies or third parties had to consent before containment could proceed? relationship

Recovery Coordination

The interface between the response case and externally governed continuity and recovery plans, and the response-side verification of restoration.

Continuity and recovery plan invocation binding

The reference, trigger, parameters and acknowledgement recorded when the response requests invocation of a continuity or recovery plan governed by another model.

Which continuity or recovery plan version was requested, and by which reference? identity
What condition triggered the invocation request and who was authorised to make it? authority
Which case-specific parameters were passed with the invocation request? composition
What acknowledgement or activation reference was returned by the plan owner? interoperability

Restoration verification and residual risk hand-off

The response-side verification that response objectives were met, the heightened monitoring period, and the residual risk handed to risk owners.

How was it verified that affected services and systems returned to an acceptable state? validation
When was recovery reached, as distinct from when containment was achieved? temporal
What heightened monitoring period follows restoration and what would reopen the case? state
Which residual risks remain accepted after restoration, and who accepted them? ownership

Evidence, Chronology and Record Integrity How case-related evidence is registered and held, and how the case chronology and change history are kept trustworthy.

Evidence Register and Holds

Registration, integrity and custody of evidence at the case boundary, and preservation obligations.

Evidence register entries and custody handoffs

Register of evidence items relied upon by the case with integrity values, acquiring party and custody transfers into and out of the response capability.

Which evidence items does this case rely on and where is each physically or logically held? identity
What integrity value was recorded at acquisition and when was it last reverified? validation
Which custody transfers occurred, between whom, and under what authorisation? provenance
Which handling constraints were imposed for possible legal use, and who set them? constraint

Preservation hold and retention classification

Holds that suspend routine disposal of case records and evidence, the retention class assigned, and the party that must execute disposal when the hold lifts.

Which records and evidence are under preservation hold and who imposed the hold? retention
What retention class and minimum period apply to the case record itself? retention
Which case content contains personal data requiring minimisation before long-term retention? privacy
Who authorises release of the hold and who executes the resulting disposition? ownership

Chronology and Record Provenance

Time semantics of the case and the history of who changed the record and on what basis.

Case chronology, time semantics and change history

The reconstructed sequence of the engagement with explicitly typed times, together with the log of record changes, their authors and the systems they came from.

Which distinct time types are recorded, such as event start, detection, report, containment, recovery and record generation? temporal
Which timestamp constitutes awareness for the purpose of starting regulatory clocks? constraint
How are uncertain or estimated times distinguished from observed ones? quality
Who changed the case record, when, and what was the stated reason? provenance
From which source system did each imported element arrive, and at what ingestion time? provenance

Communication, Notification and Sharing Internal escalation and situation reporting, external and regulatory notification, affected-party communication, and control of onward disclosure.

Internal Escalation and Situation Reporting

Who inside the organisation was informed, when, through which channel, and at what reporting cadence.

Internal escalation and situation reporting

The record of internal notifications, escalation steps and periodic situation reports issued during the engagement.

At what cadence are situation reports issued for this response tier, and to which audiences? process
Which internal escalation steps were taken and what triggered each one? event
Which communication channel was used, and was it out-of-band because primary systems were suspect? security
Which internal audiences were deliberately not informed, and on what basis? access

External and Regulatory Notification

Binding of determined reporting obligations to the case, and communication to affected parties and the public.

Regulatory notification binding and submission record

For each applicable regime, the bound deadline structure, the clock start, and the record of each submission and its acknowledgement, without owning the legal determination itself.

Which reporting regimes were determined applicable, by whom, and against which case facts? authority
Which submission stages does the bound regime require and what is each deadline relative to the clock start? constraint
What was submitted, to which recipient authority, and what reference was returned? evidence
If a deadline was missed, what reasoned justification for the delay was recorded? exception
Which mandated content elements were included, and which were still unknown at submission? requirement

Affected-party and public communication

Communication to affected individuals, customers or service recipients and any public statement, including approval and the content required for recipients to protect themselves.

What determination triggered direct communication to affected individuals rather than authority notification alone? decision
Which protective recommendations and contact points were given to recipients? requirement
How were recipients reached when direct contact was disproportionate or impossible? exception
Who approved the wording before release and which parties reviewed it? ownership

Information Sharing Controls

Handling markings and disclosure control applied to case-derived information.

Handling markings and onward disclosure control

The handling label applied to case content, its mapping to exchange-format markings, and the record of onward disclosure packages and redactions.

Which handling label applies to this case content and how is it displayed on issued material? security
How does the handling label map to markings in the exchange formats used, and where does the mapping break down? interoperability
Who may share this content onward, to whom, and under what condition? access
What was redacted or aggregated before onward sharing and who authorised it? privacy

Closure, Learning and Assurance How a case reaches a defensible end state, what is learned from it, and how response performance and record quality are evidenced.

Closure and Post-Incident Review

The end state of the case and the structured learning drawn from it.

Case status model and closure

The workflow status vocabulary of the case, closure preconditions, the final closure statement and the conditions permitting reopening.

Which workflow statuses can the case hold and which transitions are permitted? state
Which preconditions must be satisfied before the case may be closed? validation
What closure outcome is recorded, such as resolved, unresolved, transferred or withdrawn? lifecycle
Under what conditions is a closed case reopened rather than a new case being opened? exception

Post-incident review and improvement actions

The structured review of the engagement and the improvement actions it generates, each with an owner, target and verification of implementation.

Which review was held, who participated, and what scope was agreed? process
Which findings concern the response process rather than the underlying technical cause? quality
Who owns each improvement action and by when must it be completed? ownership
How is it verified that an improvement action was actually implemented and effective? validation
Which artefacts, such as playbooks, detection rules or the charter, must be updated as a result? relationship

Assurance and Measurement

How response performance is measured and how the case record itself is validated.

Response performance measurement

Defined measures of response performance derived from typed case timestamps, with explicit definitions, windows and known data-quality limits.

How is each response measure defined, including which timestamps bound it? measurement
Which population of cases does a reported figure cover and over which window? temporal
Which known data-quality limits would make a measure misleading? quality
Which decisions may and may not be based on these measures? constraint

Case record validation and conformance claims

Completeness and consistency rules the case record must satisfy at each state gate, and how alignment to external standards is claimed with evidence rather than asserted.

Which fields must be present before the case may move to a given status? validation
Which cross-field consistency rules apply, such as recovery time not preceding detection time? constraint
What evidence supports any claim of conformance to an external standard or profile? evidence
Which validation applies when the case is exported to an exchange format, and what is lost? interoperability

Classifiers Filled

Family: World Models
Category: Activities and processes
Entry kind: aggregate
Navigation path: NAV.ACT.INC
Domain: ACT.INC
Industry: Cross-industry
Tags: incidentresponseact.inc

What it is Filled

This model is the response-process record: a case aggregate binding a declared incident to a mandated response capability, its triage and containment decisions, authorised actions, evidence and communication records, closure and learning outcomes. It owns the response case, not the incident entity, not the continuity or recovery plan, and not the runtime systems that execute or enforce actions. Evidence is drawn primarily from cybersecurity incident management sources; an adopting Dimension may bind a non-cyber incident model to the same case structure.

In scope

Response capability mandate, constituency, authority level and decision rights as applied to a case
Binding of a governing playbook, plan or procedure version to a case, and recorded deviations from it
Case identity, alternative identifiers held by cooperating teams, and the case scope perimeter
Triage decision record, assigned response tier and response-side clocks
Detection and report intake, discovery source, and the event-to-incident declaration decision
Analysis findings, hypotheses, confidence and response-side impact assessment
Authorisation, tracking and outcome references for containment, eradication and mitigation actions
Invocation reference and parameters for continuity or recovery plans governed by WM-ACT-043
Evidence register entries, custody handoffs at the case boundary and preservation holds
Case chronology distinguishing event, detection, report, containment, recovery and closure times
Internal escalation, situation reporting, regulatory notification submissions and affected-party communication
Handling markings and disclosure control for case-derived information
Case closure, post-incident review, improvement actions and response performance measurement

Out of scope

Definition, categorisation, severity taxonomy and affected-asset inventory of the incident itself (WM-ACT-020)
Authoring, approval, testing, exercising and lifecycle of continuity or recovery plans, and RTO/RPO targets (WM-ACT-043)
Execution, orchestration or enforcement of response actions by security tooling, and the tooling's own audit-trail semantics
Forensic acquisition, imaging and examination methodology and expert reporting
Statutory interpretation determining which reporting regime applies, and the regulator's own case handling
Threat intelligence production, actor attribution and indicator curation
Vulnerability discovery, disclosure coordination and patch management
Risk register, risk acceptance authority and enterprise control framework ownership
Identity, access and asset master data
Crisis communications strategy, litigation, insurance claims and ransom payment or sanctions decisions
Physical execution of records disposal and platform-level retention enforcement

Why it exists Filled

Provide the format-neutral context an agent needs to open, operate, inspect and close an incident response engagement from detection through containment, recovery coordination and lessons learned.

Distinguishing features Filled

Covers the response case from detection to lessons learned, not the incident as an event, which a sibling model owns.
Records authorised response actions and their evidence but never executes them on security or IT systems.
Differs from a continuity plan: it invokes and references plans rather than authoring them.
Computes notification deadlines from the recorded awareness time, distinguishing it from a generic ticket.

What robots and AI may and may not do Filled

Must not

Record a containment, notification or disclosure entry without a recorded authorisation.
Run containment or eradication actions directly on production systems through this model.
Share case content beyond its handling label.
Present hypotheses or attribution estimates as established facts.
Alter awareness or detection times after the fact.

Only with a human decision

Declaring an incident and setting its severity tier.
Approving notification to regulators, affected persons or the public.
Authorising disruptive containment such as isolating critical systems.

May

Open a response case and record detection and report intake with timestamps.
Propose a response tier and the governing playbook for approval.
Attach execution evidence references and record custody handoffs.
Compute and remind about regulatory notification deadlines from the recorded awareness time.
Draft a lessons-learned record after closure.

Moral aspects Filled

Delayed or incomplete notification can leave affected people unable to protect themselves.
Case records often contain personal data of victims and staff and must follow need-to-know handling.
Premature attribution can harm reputations of people or organisations wrongly named.

Who is affected

People whose data or services were affected
Responders and staff named in the case
Regulators and partners receiving notifications

Owners Filled

Steward

The adopting Dimension must designate a single accountable owner for this model and a named response case owner role for each open case, with documented delegation when unavailable.

Roles

Model steward: Maintain the model, its bindings and its alignment mappings, and record divergences from external standards; Approve compatible and breaking changes and publish the migration guidance
Response case owner: Own an individual case end to end, including triage, decisions, escalation and closure; Ensure every decision carries an acting role and an authority basis; Request continuity or recovery plan invocation without assuming ownership of plan execution
Records and disclosure controller: Assign retention classes, impose and release preservation holds and approve dispositions; Approve handling labels, recipients and redactions for onward disclosure
Notification coordinator: Bind determined reporting obligations to the case and monitor stage deadlines; Retain submissions, acknowledgements and any reasoned justification for delay
Interoperability maintainer: Maintain mappings to exchange formats and external vocabularies with their catalogue versions; Report information loss and unmapped values on export rather than silently coercing them
Post-incident reviewer: Convene reviews, record findings about the response process and open owned improvement actions; Verify that improvement actions were implemented and assess whether they were effective

Links to other meta-models Filled

child

WM-ACT-019 - This model is registered as a child of WM-ACT-019 and specialises it for incident response only; generic activity, case and work-record scaffolding defined by the parent is inherited rather than restated here.

composes

WM-ACT-020 - Incoming composition: a cyber incident is handled by a response case. WM-ACT-020 owns incident identity, category, severity, affected assets and impact facts; this model carries only references to them plus response-side decisions such as declaration, tier and clocks.
FIRST Traffic Light Protocol version 2.0 - Handling and disclosure labels are applied as a cross-cutting marking vocabulary to case content and issued artifacts, with placement rules taken from the source specification.

references

WM-ACT-043 - Outgoing reference: the response may request invocation of a continuity or recovery plan. This model carries the plan reference, trigger, invocation parameters and acknowledgement reference only; plan authoring, approval, testing, activation state and execution remain with WM-ACT-043.
Candidate sibling model: digital forensics and evidence examination (not yet registered) - Acquisition, examination, analysis methodology and expert reporting are referenced from the case rather than modelled here; this model retains only register entries, integrity values and custody handoffs at the case boundary.
Candidate sibling model: regulatory obligation and jurisdiction register (not yet registered) - Determination of which reporting regime and threshold applies is a legal determination owned elsewhere; this model binds the determined obligation to the case and records submissions and acknowledgements.
MITRE ATT&CK technique catalogue - Technique references are carried with an explicit catalogue version so that assertions remain resolvable across catalogue releases; technique definitions are not reproduced.

aligned

IETF RFC 7970 IODEF version 2 - Alignment for case exchange: identifiers, typed times, discovery source, assessment, contact, expectation and history structures. Alignment is asserted at element level with recorded divergences and is not a conformance claim.
OASIS CACAO Security Playbooks version 2.0 - Alignment for playbook identity, versioning and validity when binding a governing procedure to a case; workflow execution, agents and targets remain outside this model.
OASIS STIX version 2.1 - Alignment for object identity, creation and modification markers, confidence, external references, notes and data markings when case content is exchanged as threat intelligence.
ENISA Reference Security Incident Taxonomy - External classification vocabulary bound by coded value and taxonomy version for interoperability with CSIRT and law-enforcement reporting; the vocabulary is not forked or maintained locally.
NIST SP 800-61r3 CSF 2.0 Community Profile - Alignment of case outcomes to cybersecurity risk-management outcomes so that response records can evidence detection, response, recovery and improvement expectations; conformance is claimed only with evidence.

neighbor

WM-ACT-020 Cyber incident (incoming COMPOSE) - The incident model owns what happened: incident identity, classification, severity, affected assets and impact facts. This model owns how it was handled and carries only references plus response-side decisions such as priority tier and declaration.
WM-ACT-043 Continuity and recovery plans (outgoing REFERENCE) - Plan content, approval, testing and activation lifecycle stay in the target model. This model carries only the plan reference, invocation trigger, invocation parameters and the returned acknowledgement reference.
WM-ACT-019 registered parent activity model (CHILD) - Generic activity, case and work-record scaffolding defined by the parent is inherited, not restated; only incident-response specialisation is modelled here.
Security orchestration and enforcement platforms - Playbook execution engines, agents, targets and command execution semantics are external. This model records the authorisation, the intended effect and a reference to execution evidence, never the execution or enforcement semantics themselves.
Digital forensics and evidence examination (candidate sibling) - Collection, examination, analysis and expert reporting methodology are external. This model holds register entries, integrity digests and custody handoffs at the case boundary only.
Regulatory obligation register and legal counsel - Determining which regime and threshold applies is a legal determination held elsewhere. This model binds the determined obligation to the case and records submission facts and acknowledgements.
Threat intelligence and technique catalogues - Technique, actor and indicator definitions are external catalogue content referenced by identifier and version; this model does not curate or version them.
Capability maturity assessment programmes - Maturity scoring and assessment methodology are external; this model records readiness preconditions and references to assessment outcomes relied upon at case time.

parent

WM-ACT-019

What else AI and robots need to interact with it Filled

Sources Filled

Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile (NIST SP 800-61r3) - National Institute of Standards and Technology
RFC 7970: The Incident Object Description Exchange Format Version 2 (IODEF) - Internet Engineering Task Force
RFC 2350: Expectations for Computer Security Incident Response (BCP 21) - Internet Engineering Task Force
Traffic Light Protocol (TLP) Version 2.0 - Forum of Incident Response and Security Teams (FIRST)
FIRST CSIRT Services Framework Version 2.1 - Forum of Incident Response and Security Teams (FIRST)
CACAO Security Playbooks Version 2.0 - OASIS Open
STIX Version 2.1 (OASIS Standard) - OASIS Open
Directive (EU) 2022/2555 (NIS 2 Directive), Articles 6 and 23 - European Parliament and Council of the European Union
Regulation (EU) 2016/679 (GDPR), Articles 33 and 34 - European Parliament and Council of the European Union
Reference Incident Classification Taxonomy: Task Force Status and Way Forward - European Union Agency for Cybersecurity (ENISA)
Reference Security Incident Taxonomy (RSIT), human-readable working copy - TF-CSIRT Reference Security Incident Taxonomy Working Group / ENISA
NIST SP 800-184: Guide for Cybersecurity Event Recovery - National Institute of Standards and Technology
NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response - National Institute of Standards and Technology
ISO/IEC 27035-1:2023 Information technology - Information security incident management - Part 1: Principles and process - ISO/IEC JTC 1/SC 27
MITRE ATT&CK Versions of ATT&CK - The MITRE Corporation
SIM3: Security Incident Management Maturity Model - Open CSIRT Foundation
CIRCIA, other big cyber rules expected to get finalized this fall - Federal News Network

Open questions

Independent second-provider or substitute-reviewer pass over WM-ACT-042 once a second provider is restored, to replace the owner-waived cross-provider comparison that this audit cannot supply.
Reconcile the WM-ACT-020 to WM-ACT-042 edge typing: decide whether it is containment (COMPOSE) or handling reference, then settle case-to-incident cardinality and the merge, split and supersession identity rules that depend on it.
Register the CHILD edge to WM-ACT-019 in the relationship contract, and decide whether the risk-acceptance, records-disposition and forensic-examination hand-offs named in out_of_scope require registered REFERENCE targets or remain non-model externalities.
Add producing functions for a-analysis-note, a-deviation-record, a-restoration-verification, a-case-chronology, a-situation-report and a-affected-party-notice, which are declared artifacts with no operation that emits them.
Enumerate sector and national reporting regimes beyond NIS2 and GDPR from primary text, including national NIS2 transpositions with their own thresholds and portals, and verify the CIRCIA implementing rule once finalised so it can move from pending binding to operative obligation.
Obtain the ISO/IEC 27035-1:2023 normative text and extract the NIST SP 800-61r3 body so the declaration, closure and post-incident-review findings can rest on verified clauses instead of catalogue-level scope.
Ground non-cyber, operational-technology and safety-of-life incident command structures in primary sources before the scope statement's claim that an adopting Dimension may bind a non-cyber incident model to this case structure is treated as supported.
Define the artifact serial predicate for the Vercy artifact schema and normalise register-versus-entry naming, then re-evaluate all 18 artifacts against the stated definition.
Model the access-control and disposition-tombstone rules that the coverage checklist currently asserts, or remove the assertion, including the five named exception paths and the deny-by-default grant model.
The normative text of ISO/IEC 27035-1:2023 is paywalled and was not machine-verified in this session; only its catalogue-level scope and the existence of a phased process were relied upon.
The body of NIST SP 800-61r3 could not be extracted from the published PDF in this session. Title, authors, publication date, DOI, supersession of Revision 2 and its character as a CSF 2.0 Community Profile were verified from NIST pages; internal category-level mappings were not, so no subcategory identifiers are asserted.
Sector-specific and national reporting regimes beyond NIS2 and GDPR are not enumerated and must be bound by the adopting Dimension.
Ransom payment decision-making, sanctions screening, cyber insurance claims and litigation hold strategy are deliberately excluded and not modelled anywhere here.
Insider and HR-linked investigations, with their separate confidentiality and employment-law constraints, are not modelled.
Operational technology, industrial control and safety-of-life response constraints are not covered by the cited sources.
The full SIM3 parameter set and the ENISA taxonomy governance process were only partially verified.
Cross-organisation coordination protocols beyond identifier exchange, such as joint command arrangements between constituencies, are not modelled.

Machine files

Card as JSON Specification AGENTS.md Source Card backlog vercy.card/1

Provenance

world-models research · reviewable-draft

Built from: models/wm-act-042-incident-response/spec.yaml, ver-cy/world-models/card-supplements/wm-act-042-incident-response.json