# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "published", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-29T17:11:10Z", "synthesisSha256": "61e02f148dffe154673021bfc028ffeec8ecb2beb2aff0ebb312795bcfb83bf2", "providerMode": "single-provider-waiver", "providers": [ "Claude" ], "waivedProviders": [ "Grok" ] }, "metaModel": { "id": "WM-ACT-042", "registryId": "vr.wm-act-042", "name": "Incident Response", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "aggregate", "family": "World Models", "category": "Activities and processes", "industry": [ "Cross-industry" ], "domain": [ "ACT.INC" ], "tags": [ "incident", "response", "act.inc" ], "status": "published" }, "canonicalUrl": "https://ver.cy/models/wm-act-042-incident-response/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-act-042", "model": { "registry_id": "vr.wm-act-042", "model_id": "WM-ACT-042", "name": "Incident Response", "entry_kind": "aggregate", "purpose": "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.", "scope_statement": "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" ], "boundary_notes": [ { "neighbor": "WM-ACT-020 Cyber incident (incoming COMPOSE)", "distinction": "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.", "source_refs": [ "SRC-002", "SRC-010", "SRC-011" ] }, { "neighbor": "WM-ACT-043 Continuity and recovery plans (outgoing REFERENCE)", "distinction": "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.", "source_refs": [ "SRC-012" ] }, { "neighbor": "WM-ACT-019 registered parent activity model (CHILD)", "distinction": "Generic activity, case and work-record scaffolding defined by the parent is inherited, not restated; only incident-response specialisation is modelled here.", "source_refs": [ "SRC-001", "SRC-005" ] }, { "neighbor": "Security orchestration and enforcement platforms", "distinction": "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.", "source_refs": [ "SRC-006" ] }, { "neighbor": "Digital forensics and evidence examination (candidate sibling)", "distinction": "Collection, examination, analysis and expert reporting methodology are external. This model holds register entries, integrity digests and custody handoffs at the case boundary only.", "source_refs": [ "SRC-013" ] }, { "neighbor": "Regulatory obligation register and legal counsel", "distinction": "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.", "source_refs": [ "SRC-008", "SRC-009" ] }, { "neighbor": "Threat intelligence and technique catalogues", "distinction": "Technique, actor and indicator definitions are external catalogue content referenced by identifier and version; this model does not curate or version them.", "source_refs": [ "SRC-007", "SRC-015" ] }, { "neighbor": "Capability maturity assessment programmes", "distinction": "Maturity scoring and assessment methodology are external; this model records readiness preconditions and references to assessment outcomes relied upon at case time.", "source_refs": [ "SRC-016" ] } ] }, "sources": [ { "id": "SRC-001", "title": "Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile (NIST SP 800-61r3)", "organization": "National Institute of Standards and Technology", "url": "https://csrc.nist.gov/pubs/sp/800/61/r3/final", "version_or_date": "Revision 3, published 2025-04-03, DOI 10.6028/NIST.SP.800-61r3; supersedes Rev. 2 (2012)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:05:00Z", "relevance": "Current NIST position that incident response is expressed as a CSF 2.0 Community Profile across all six Functions rather than a standalone phase lifecycle; anchors preparation, detection, response, recovery and improvement outcomes." }, { "id": "SRC-002", "title": "RFC 7970: The Incident Object Description Exchange Format Version 2 (IODEF)", "organization": "Internet Engineering Task Force", "url": "https://www.rfc-editor.org/rfc/rfc7970.html", "version_or_date": "Version 2, November 2016", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:07:00Z", "relevance": "Normative data model for incident case exchange: IncidentID and AlternativeID, DetectTime/StartTime/EndTime/RecoveryTime/ReportTime/GenerationTime, Discovery source enumeration, Assessment, Contact, Expectation, History, and the purpose/status/restriction attribute vocabularies." }, { "id": "SRC-003", "title": "RFC 2350: Expectations for Computer Security Incident Response (BCP 21)", "organization": "Internet Engineering Task Force", "url": "https://www.rfc-editor.org/rfc/rfc2350.html", "version_or_date": "BCP 21, June 1998", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:09:00Z", "relevance": "Normative disclosure template for a response capability: contact information, charter, mission, constituency, sponsorship, authority, policies on incident types and level of support, disclosure and communication, services and reporting forms." }, { "id": "SRC-004", "title": "Traffic Light Protocol (TLP) Version 2.0", "organization": "Forum of Incident Response and Security Teams (FIRST)", "url": "https://www.first.org/tlp/", "version_or_date": "TLP 2.0, in force from August 2022", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:11:00Z", "relevance": "Handling labels TLP:RED, TLP:AMBER, TLP:AMBER+STRICT, TLP:GREEN, TLP:CLEAR with normative rules on label form, placement and source responsibility for recipient understanding." }, { "id": "SRC-005", "title": "FIRST CSIRT Services Framework Version 2.1", "organization": "Forum of Incident Response and Security Teams (FIRST)", "url": "https://www.first.org/education/csirt_services_framework_v2.1", "version_or_date": "Version 2.1", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:12:00Z", "relevance": "Service-area, service, function and sub-function decomposition; Information Security Incident Management comprises report acceptance, incident analysis, artifact and forensic evidence analysis, mitigation and recovery, incident coordination and crisis management support." }, { "id": "SRC-006", "title": "CACAO Security Playbooks Version 2.0", "organization": "OASIS Open", "url": "https://docs.oasis-open.org/cacao/security-playbooks/v2.0/security-playbooks-v2.0.html", "version_or_date": "Committee Specification 01, 27 November 2023", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:14:00Z", "relevance": "Machine-readable playbook identity and versioning (id, created, modified, valid_from, valid_until, revoked, derived_from), playbook_types vocabulary, agent/target/authentication definitions, data marking definitions, signatures and workflow step types; locates execution semantics outside this model." }, { "id": "SRC-007", "title": "STIX Version 2.1 (OASIS Standard)", "organization": "OASIS Open", "url": "https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.html", "version_or_date": "OASIS Standard, 10 June 2021", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:16:00Z", "relevance": "Common object properties (id, spec_version, created, modified, created_by_ref, revoked, confidence, external_references, object_marking_refs, granular_markings), Note SDO for analyst commentary, Sighting SRO, TLP marking definitions, and a deliberately minimal Incident SDO." }, { "id": "SRC-008", "title": "Directive (EU) 2022/2555 (NIS 2 Directive), Articles 6 and 23", "organization": "European Parliament and Council of the European Union", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022L2555", "version_or_date": "Adopted 14 December 2022, OJ L 333", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:18:00Z", "relevance": "Definitions of incident, incident handling, near miss and significant incident; multi-stage reporting duty of 24-hour early warning, 72-hour incident notification, intermediate report on request, one-month final report or progress report, plus service-recipient notification." }, { "id": "SRC-009", "title": "Regulation (EU) 2016/679 (GDPR), Articles 33 and 34", "organization": "European Parliament and Council of the European Union", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679", "version_or_date": "Adopted 27 April 2016, OJ L 119", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:20:00Z", "relevance": "72-hour personal data breach notification with required content, reasoned justification for delay, processor duty to notify the controller, Article 33(5) internal breach documentation duty, and Article 34 communication to data subjects on high risk." }, { "id": "SRC-010", "title": "Reference Incident Classification Taxonomy: Task Force Status and Way Forward", "organization": "European Union Agency for Cybersecurity (ENISA)", "url": "https://www.enisa.europa.eu/publications/reference-incident-classification-taxonomy", "version_or_date": "Published 26 January 2018", "source_type": "classifier", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:22:00Z", "relevance": "Establishes a harmonised reference incident classification for CSIRTs and law enforcement, derived from the eCSIRT.net taxonomy, and the governance of its continued maintenance." }, { "id": "SRC-011", "title": "Reference Security Incident Taxonomy (RSIT), human-readable working copy", "organization": "TF-CSIRT Reference Security Incident Taxonomy Working Group / ENISA", "url": "https://raw.githubusercontent.com/enisaeu/Reference-Security-Incident-Taxonomy-Task-Force/master/working_copy/humanv1.md", "version_or_date": "Working copy, taxonomy version 1003", "source_type": "classifier", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-29T09:24:00Z", "relevance": "Concrete classification classes and incident types (abusive content, malicious code, information gathering, intrusion attempts, intrusions, availability, information content security, fraud, vulnerable, other, test) used as an external classification vocabulary." }, { "id": "SRC-012", "title": "NIST SP 800-184: Guide for Cybersecurity Event Recovery", "organization": "National Institute of Standards and Technology", "url": "https://csrc.nist.gov/pubs/sp/800/184/final", "version_or_date": "December 2016, DOI 10.6028/NIST.SP.800-184", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:26:00Z", "relevance": "Separates recovery planning, playbook development, testing and improvement from response execution, and supplies recovery metrics; supports placing plan ownership in WM-ACT-043 while this model records invocation and verification." }, { "id": "SRC-013", "title": "NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response", "organization": "National Institute of Standards and Technology", "url": "https://csrc.nist.gov/pubs/sp/800/86/final", "version_or_date": "August 2006, DOI 10.6028/NIST.SP.800-86", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:28:00Z", "relevance": "Establishes forensic practice as a discipline integrated with but distinct from incident response, including data integrity and the need to involve management and legal counsel; grounds the evidence boundary note." }, { "id": "SRC-014", "title": "ISO/IEC 27035-1:2023 Information technology - Information security incident management - Part 1: Principles and process", "organization": "ISO/IEC JTC 1/SC 27", "url": "https://www.iso.org/standard/78973.html", "version_or_date": "Edition 2, 2023", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-29T09:30:00Z", "relevance": "International phase-based incident management process (plan and prepare, detect and report, assess and decide, respond, learn lessons) and the event/incident distinction; cited at catalogue level because the normative text is paywalled and was not machine-verified in this session." }, { "id": "SRC-015", "title": "MITRE ATT&CK Versions of ATT&CK", "organization": "The MITRE Corporation", "url": "https://attack.mitre.org/resources/versions/", "version_or_date": "ATT&CK v19.2, current from 28 April 2026", "source_type": "registry", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-29T09:32:00Z", "relevance": "Versioned technique catalogue with major.minor release semantics and archived versions; requires that technique references carry a catalogue version to remain resolvable." }, { "id": "SRC-016", "title": "SIM3: Security Incident Management Maturity Model", "organization": "Open CSIRT Foundation", "url": "https://opencsirt.org/csirt-maturity/sim3-and-references/", "version_or_date": "SIM3 v2 interim, released 1 January 2023", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-29T09:34:00Z", "relevance": "Maturity parameters covering organisational, human, tools and process aspects of a response capability; supports readiness preconditions being referenced rather than re-derived at case time." }, { "id": "SRC-017", "title": "CIRCIA, other big cyber rules expected to get finalized this fall", "organization": "Federal News Network", "url": "https://federalnewsnetwork.com/cybersecurity/2026/07/circia-other-big-cyber-rules-expected-to-get-finalized-this-fall/", "version_or_date": "July 2026", "source_type": "secondary", "primary_source": false, "authority_tier": 3, "accessed_at": "2026-08-29T09:36:00Z", "relevance": "Used only to record that the US CIRCIA implementing rule was still not final as of mid-2026, so its 72-hour incident and 24-hour ransom-payment reporting duties must be modelled as a pending, jurisdiction-specific binding rather than an active obligation." } ], "structure": { "bundles": [ { "id": "mandate-and-readiness", "name": "Mandate, Authority and Readiness", "description": "Who is empowered to respond, with what authority and decision rights, and what preparedness the capability relies on when a case opens.", "rationale": "Response acts are only defensible if the responding capability's constituency, authority level and governing procedures are declared in advance; RFC 2350 makes this a publication duty and the CSIRT Services Framework decomposes the services offered.", "source_refs": [ "SRC-003", "SRC-005", "SRC-001" ], "layers": [ { "id": "response-mandate-and-authority", "name": "Response Mandate and Authority", "description": "The declared charter, constituency, service scope and the decision rights exercised during a case.", "source_refs": [ "SRC-003", "SRC-005" ], "findings": [ { "id": "f-capability-charter", "name": "Response capability charter and constituency", "description": "The published mandate of the responding capability: mission, constituency, sponsorship, authority level over constituent systems, supported incident types and level of support.", "source_refs": [ "SRC-003", "SRC-005" ], "questions": [ { "id": "q-charter-authority", "text": "What authority does the responding capability hold over constituent systems, and is it advisory, shared or full?", "kind": "authority", "answer_data": [ "Authority level code", "Scope of authority statement", "Escalation path when authority is insufficient" ] }, { "id": "q-charter-constituency", "text": "Which constituency, sites and organisational units does this capability serve?", "kind": "ownership", "answer_data": [ "Constituency definition", "Constituent organisation references", "Coverage exclusions" ] }, { "id": "q-charter-support-level", "text": "Which incident types are supported and at what declared level of support?", "kind": "definition", "answer_data": [ "Supported incident type list", "Level of support per type", "Service hours and reachability" ] }, { "id": "q-charter-currency", "text": "Which published version of the service description governs this case, and when was it last updated?", "kind": "provenance", "answer_data": [ "Charter document identifier", "Version label", "Last update timestamp" ] } ], "data_elements": [ { "id": "de-capability-id", "name": "Responding capability identifier", "description": "Authoritative identifier of the team or capability accepting the case.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-003", "SRC-002" ] }, { "id": "de-authority-level", "name": "Authority level", "description": "Declared authority over constituent systems, from advisory through full.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-003" ] }, { "id": "de-constituency-scope", "name": "Constituency scope", "description": "Definition of the served constituency and its stated exclusions.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-003" ] }, { "id": "de-service-catalogue-ref", "name": "Service catalogue reference", "description": "Reference to the services and functions the capability offers for this incident type.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "a-service-description", "name": "Response capability service description", "description": "Published document following the RFC 2350 template covering contact information, charter, policies, services, reporting forms and disclaimers.", "media_or_form": [ "structured document", "published web resource", "signed text" ], "serial": false, "identity_strategy": "Stable resource identifier for the published description plus an explicit version label; never identified by publication date alone.", "source_refs": [ "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "f-role-and-decision-rights", "name": "Case roles and decision rights", "description": "Named roles engaged on the case, their delegated decision rights, handover points and the escalation trigger to crisis management.", "source_refs": [ "SRC-005", "SRC-003" ], "questions": [ { "id": "q-roles-who-decides", "text": "Who holds the decision right for containment actions that disrupt production services?", "kind": "authority", "answer_data": [ "Decision role", "Delegation reference", "Disruption approval threshold" ] }, { "id": "q-roles-handover", "text": "How is case ownership handed over between shifts or teams without losing accountability?", "kind": "process", "answer_data": [ "Handover record", "Outgoing and incoming role holders", "Handover timestamp" ] }, { "id": "q-roles-crisis-trigger", "text": "Which condition escalates the case from response coordination into crisis management support?", "kind": "exception", "answer_data": [ "Escalation trigger condition", "Receiving crisis role", "Escalation timestamp" ] }, { "id": "q-roles-conflict", "text": "How are conflicts between response, legal and business owners recorded and resolved?", "kind": "decision", "answer_data": [ "Conflict statement", "Deciding authority", "Resolution reference" ] } ], "data_elements": [ { "id": "de-case-role-assignment", "name": "Case role assignment", "description": "Binding of a role to an identity reference for a stated period of the case.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "de-decision-right", "name": "Decision right", "description": "The class of decision a role may take without further approval.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-handover-event", "name": "Ownership handover", "description": "Record of transfer of case ownership between role holders.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "Role engagement is reference data: it points to identity records and duty rosters mastered elsewhere and exists only as fields on the case record, so no separately transmissible artifact is produced or needed." } ] }, { "id": "preparedness-baseline", "name": "Preparedness Baseline", "description": "Which governing procedure version and which readiness preconditions the case relies on.", "source_refs": [ "SRC-006", "SRC-016", "SRC-001" ], "findings": [ { "id": "f-playbook-and-procedure-binding", "name": "Governing playbook and procedure binding", "description": "The identity, version and validity window of the playbook, procedure or plan invoked to govern the case, plus whether the case runs ad hoc.", "source_refs": [ "SRC-006", "SRC-001" ], "questions": [ { "id": "q-playbook-which", "text": "Which playbook or procedure version governs this case, and is it still within its validity window?", "kind": "identity", "answer_data": [ "Playbook identifier", "Version or modified marker", "valid_from and valid_until values" ] }, { "id": "q-playbook-type", "text": "What playbook type applies, such as detection, investigation, mitigation or remediation?", "kind": "classification", "answer_data": [ "Playbook type value", "Vocabulary reference", "Selection reason" ] }, { "id": "q-playbook-absent", "text": "If no playbook exists for this situation, what is recorded in its place?", "kind": "exception", "answer_data": [ "Ad hoc response flag", "Justification text", "Approver reference" ] }, { "id": "q-playbook-integrity", "text": "How is the bound playbook version verified as unaltered at the moment of binding?", "kind": "validation", "answer_data": [ "Content digest", "Signature reference", "Verification timestamp" ] } ], "data_elements": [ { "id": "de-playbook-ref", "name": "Playbook reference", "description": "Identifier of the externally governed playbook or procedure bound to the case.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-playbook-version", "name": "Playbook version marker", "description": "Version or modification marker of the bound playbook at binding time.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-playbook-validity", "name": "Playbook validity window", "description": "Earliest and latest time the bound playbook is declared valid for execution.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-ad-hoc-flag", "name": "Ad hoc response flag", "description": "Indicates the case proceeds without a pre-approved playbook.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] } ], "artifacts": [], "inline_only_rationale": "The playbook itself is an externally governed object with its own identity, versioning, signatures and execution engine; this finding carries only the binding tuple of reference, version, validity and digest, which is inline reference data on the case." }, { "id": "f-capability-readiness-evidence", "name": "Readiness preconditions relied upon", "description": "The readiness state the case depends on: reachable contacts, available tooling access, current training and exercise evidence, referenced rather than re-assessed.", "source_refs": [ "SRC-016", "SRC-003", "SRC-001" ], "questions": [ { "id": "q-readiness-precondition", "text": "Which readiness preconditions must hold before this response tier can be operated?", "kind": "requirement", "answer_data": [ "Precondition statement", "Verification method", "Responsible role" ] }, { "id": "q-readiness-evidence", "text": "What external assessment or exercise evidence is relied upon, and when was it produced?", "kind": "evidence", "answer_data": [ "Assessment reference", "Assessment date", "Assessing party" ] }, { "id": "q-readiness-gap", "text": "Which readiness gaps were known and accepted at the time the case opened?", "kind": "quality", "answer_data": [ "Gap statement", "Acceptance reference", "Compensating measure" ] }, { "id": "q-readiness-contact", "text": "Are out-of-band contact and authentication means available if primary channels are compromised?", "kind": "security", "answer_data": [ "Out-of-band channel reference", "Key or credential reference", "Last verification timestamp" ] } ], "data_elements": [ { "id": "de-readiness-precondition", "name": "Readiness precondition", "description": "A named condition required before the response tier is operable.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "de-readiness-assessment-ref", "name": "Readiness assessment reference", "description": "Pointer to an externally held maturity, training or exercise record.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016" ] }, { "id": "de-out-of-band-channel", "name": "Out-of-band channel reference", "description": "Reference to the secure alternate communication and authentication means.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [], "inline_only_rationale": "Maturity assessments, training records and exercise reports are produced and versioned by other programmes; this finding holds only pointers and the accepted-gap statement, so declaring a local artifact would duplicate externally mastered records." } ] } ] }, { "id": "case-identity-and-triage", "name": "Case Identity, Scope and Triage", "description": "How the response case is identified, bounded and prioritised, and how it binds to external classification vocabularies.", "rationale": "IODEF requires a tracking identifier assigned by the generating team plus alternative identifiers from cooperating teams, and separates classification vocabularies from the case record itself.", "source_refs": [ "SRC-002", "SRC-011", "SRC-005" ], "layers": [ { "id": "case-identification", "name": "Case Identification and Scope", "description": "The identifiers, cross-references and perimeter that define which response engagement this is.", "source_refs": [ "SRC-002", "SRC-007" ], "findings": [ { "id": "f-case-identity", "name": "Response case identity, cross-references and perimeter", "description": "The authoritative case identifier, identifiers held by cooperating parties, the reference to the incident record handled, and the declared perimeter of the engagement.", "source_refs": [ "SRC-002", "SRC-007", "SRC-005" ], "questions": [ { "id": "q-case-id", "text": "What is the authoritative identifier of this response case and which system issued it?", "kind": "identity", "answer_data": [ "Case identifier", "Issuing system or team namespace", "Assignment timestamp" ] }, { "id": "q-case-alt-id", "text": "Which tracking numbers do cooperating teams, vendors or authorities use for the same engagement?", "kind": "relationship", "answer_data": [ "Alternative identifier", "Holding party reference", "Correlation confidence" ] }, { "id": "q-case-incident-link", "text": "Which incident record does this case handle, and is the link one-to-one?", "kind": "composition", "answer_data": [ "Incident record reference", "Link cardinality", "Merge or split history" ] }, { "id": "q-case-perimeter", "text": "What is inside the response perimeter and what was explicitly excluded from it?", "kind": "spatial", "answer_data": [ "In-perimeter references", "Excluded references", "Perimeter change history" ] }, { "id": "q-case-merge", "text": "How are duplicate or related cases merged, split or superseded without losing identifiers?", "kind": "lifecycle", "answer_data": [ "Superseding case reference", "Related case references", "Merge decision record" ] } ], "data_elements": [ { "id": "de-case-id", "name": "Case identifier", "description": "Tracking identifier assigned by the responding capability within its own namespace.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "de-case-alt-id", "name": "Alternative case identifier", "description": "Identifier used by another team or authority for the same engagement.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-incident-ref", "name": "Handled incident reference", "description": "Reference to the incident record whose facts are mastered by the incident model.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "de-related-activity-ref", "name": "Related activity reference", "description": "Reference to related cases, campaigns or prior engagements.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-perimeter-scope", "name": "Response perimeter", "description": "Declared set of in-scope and out-of-scope entities, sites or tenants for the engagement.", "value_kind": "collection", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "a-response-case-record", "name": "Response case record", "description": "The aggregate root record of the engagement carrying identity, cross-references, perimeter, decisions and state.", "media_or_form": [ "structured record", "exchange document", "case-management entry" ], "serial": true, "identity_strategy": "Master case-management identifier where one exists, otherwise a governed identifier within the issuing team namespace; serial numbering is monotonic within that namespace and carries no date component.", "source_refs": [ "SRC-002", "SRC-007" ] } ], "inline_only_rationale": null } ] }, { "id": "triage-and-classification", "name": "Triage and Classification Binding", "description": "The response-side prioritisation decision and the bindings to external classification vocabularies.", "source_refs": [ "SRC-005", "SRC-011", "SRC-015" ], "findings": [ { "id": "f-triage-decision", "name": "Triage decision and response tier", "description": "The recorded decision assigning a response tier, target response clocks and resourcing, together with the criteria version applied.", "source_refs": [ "SRC-005", "SRC-002", "SRC-001" ], "questions": [ { "id": "q-triage-tier", "text": "What response tier was assigned, by whom, and against which criteria version?", "kind": "decision", "answer_data": [ "Response tier value", "Deciding role reference", "Criteria version identifier" ] }, { "id": "q-triage-clock", "text": "Which response clocks start on triage and what are their targets?", "kind": "temporal", "answer_data": [ "Clock name", "Clock start timestamp", "Target duration" ] }, { "id": "q-triage-rerank", "text": "Under what conditions is the response tier re-evaluated during the case?", "kind": "state", "answer_data": [ "Re-triage trigger", "New tier value", "Change timestamp" ] }, { "id": "q-triage-vs-severity", "text": "How does the assigned response tier relate to the severity held on the incident record?", "kind": "relationship", "answer_data": [ "Severity reference", "Mapping rule reference", "Divergence justification" ] } ], "data_elements": [ { "id": "de-response-tier", "name": "Response tier", "description": "Response-side priority class driving resourcing and clocks.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "de-triage-criteria-version", "name": "Triage criteria version", "description": "Version identifier of the prioritisation criteria applied.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "de-response-clock", "name": "Response clock", "description": "A named target interval with its start time and target duration.", "value_kind": "duration", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "de-triage-decider", "name": "Triage decider reference", "description": "Reference to the role or identity that assigned the tier.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "Triage output is a small decision tuple stored on the case record and consumed by workflow; severity and impact facts belong to the incident model, so a separate transmissible artifact would fragment the decision from the case state it governs." }, { "id": "f-classification-alignment-binding", "name": "External classification and technique bindings", "description": "Bindings from the case to external vocabularies for incident class, adversary technique and exchange-format attributes, always with catalogue version.", "source_refs": [ "SRC-011", "SRC-010", "SRC-015", "SRC-002" ], "questions": [ { "id": "q-class-vocab", "text": "Which external classification class and type were assigned, from which taxonomy version?", "kind": "classification", "answer_data": [ "Taxonomy class value", "Taxonomy type value", "Taxonomy version" ] }, { "id": "q-class-technique", "text": "Which adversary techniques are referenced and against which catalogue version?", "kind": "interoperability", "answer_data": [ "Technique identifier", "Catalogue version", "Assertion confidence" ] }, { "id": "q-class-purpose", "text": "What is the declared purpose of documenting this case for exchange, such as mitigation, reporting or traceback?", "kind": "interoperability", "answer_data": [ "Purpose value", "Intended recipient class", "Exchange format reference" ] }, { "id": "q-class-drift", "text": "How are bindings revalidated when an external catalogue publishes a new version?", "kind": "validation", "answer_data": [ "Revalidation rule", "Last revalidation timestamp", "Deprecated mapping list" ] } ], "data_elements": [ { "id": "de-taxonomy-binding", "name": "Taxonomy binding", "description": "Class and type value drawn from an external incident taxonomy with its version.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-010" ] }, { "id": "de-technique-ref", "name": "Technique reference", "description": "Versioned identifier of an adversary technique asserted for the case.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "de-exchange-purpose", "name": "Exchange purpose", "description": "Declared reason the case is documented for exchange.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "These are alignment bindings to catalogues owned by other organisations; the model stores only coded values, catalogue versions and confidence, and must not restate or fork the external vocabularies as local artifacts." } ] } ] }, { "id": "detection-and-analysis", "name": "Detection Intake and Analysis", "description": "How the engagement was triggered, how an event became a declared incident, and what the analysis concluded for response purposes.", "rationale": "IODEF enumerates discovery sources and separates detection from report and generation times; the CSIRT Services Framework separates report acceptance from incident analysis; ISO/IEC 27035-1 separates events from incidents.", "source_refs": [ "SRC-002", "SRC-005", "SRC-014" ], "layers": [ { "id": "detection-intake", "name": "Detection and Report Intake", "description": "Receipt of the trigger and the decision that promotes it to a handled incident.", "source_refs": [ "SRC-002", "SRC-005", "SRC-014" ], "findings": [ { "id": "f-detection-and-report-intake", "name": "Detection and report intake", "description": "How the engagement was triggered: discovery source, reporting party, channel, submitted content and receipt acknowledgement.", "source_refs": [ "SRC-002", "SRC-005", "SRC-003" ], "questions": [ { "id": "q-intake-source", "text": "By which discovery source was the situation first noticed, such as monitoring, audit, external notification or law enforcement?", "kind": "provenance", "answer_data": [ "Discovery source value", "Detecting system reference", "Detection timestamp" ] }, { "id": "q-intake-reporter", "text": "Who reported the situation and how was the reporting party authenticated?", "kind": "identity", "answer_data": [ "Reporter contact reference", "Authentication method", "Report channel" ] }, { "id": "q-intake-ack", "text": "What acknowledgement was returned to the reporter and within what interval?", "kind": "process", "answer_data": [ "Acknowledgement reference", "Acknowledgement timestamp", "Interval from receipt" ] }, { "id": "q-intake-quality", "text": "How complete and reliable was the initial report, and what was missing?", "kind": "quality", "answer_data": [ "Completeness assessment", "Missing element list", "Follow-up request reference" ] } ], "data_elements": [ { "id": "de-discovery-source", "name": "Discovery source", "description": "Coded means by which the situation was discovered.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-reporter-contact", "name": "Reporting party contact", "description": "Contact reference for the party that submitted the report.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-report-received-at", "name": "Report receipt time", "description": "Time the report was received by the responding capability.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-intake-completeness", "name": "Intake completeness assessment", "description": "Assessment of whether the submitted report met the minimum reporting form.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "a-inbound-report", "name": "Inbound incident report", "description": "The submitted report as received, whether a reporting form, structured exchange document or transcribed notification.", "media_or_form": [ "reporting form", "structured exchange document", "message transcript" ], "serial": false, "identity_strategy": "Submission identifier assigned on receipt, bound to the case identifier; the original sender reference is retained as provenance rather than as identity.", "source_refs": [ "SRC-002", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "f-incident-declaration", "name": "Event to incident declaration", "description": "The decision that promotes one or more events to a declared incident under response, including the declaring authority and the basis.", "source_refs": [ "SRC-014", "SRC-008", "SRC-005" ], "questions": [ { "id": "q-declare-who", "text": "Who declared the incident and under which delegated authority?", "kind": "authority", "answer_data": [ "Declaring role reference", "Authority basis", "Declaration timestamp" ] }, { "id": "q-declare-basis", "text": "On what basis was the event judged to be an incident rather than a near miss or false positive?", "kind": "definition", "answer_data": [ "Declaration basis statement", "Supporting evidence reference", "Rejected alternative" ] }, { "id": "q-declare-reverse", "text": "How is a declaration reversed if analysis later shows no incident occurred?", "kind": "exception", "answer_data": [ "Reversal decision record", "Reversal timestamp", "Notification correction reference" ] }, { "id": "q-declare-nearmiss", "text": "Is a near miss recorded even when no incident is declared, and where?", "kind": "event", "answer_data": [ "Near miss flag", "Target register reference", "Retention treatment" ] } ], "data_elements": [ { "id": "de-declaration-state", "name": "Declaration state", "description": "Whether the trigger stands as an event, near miss, declared incident or rejected report.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-014", "SRC-008" ] }, { "id": "de-declared-at", "name": "Declaration time", "description": "Time the incident was formally declared under response.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-declaration-basis", "name": "Declaration basis", "description": "Stated reasoning and evidence references supporting the declaration.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] } ], "artifacts": [], "inline_only_rationale": "Declaration is a state transition with an authority reference and a basis statement recorded on the case record; the incident entity it promotes is mastered by the composing incident model, so no independent document is created here." } ] }, { "id": "investigation-and-analysis", "name": "Investigation and Analysis", "description": "Analytical conclusions and the response-side impact assessment that drive containment and notification decisions.", "source_refs": [ "SRC-005", "SRC-007", "SRC-002" ], "findings": [ { "id": "f-analysis-findings", "name": "Analysis findings, hypotheses and confidence", "description": "Working hypotheses, supporting and contradicting observations, confidence, and the root cause status as understood during response.", "source_refs": [ "SRC-005", "SRC-007", "SRC-013" ], "questions": [ { "id": "q-analysis-hypothesis", "text": "What hypotheses about the attack path are open, and what would falsify each one?", "kind": "quality", "answer_data": [ "Hypothesis statement", "Falsifying observation", "Current status" ] }, { "id": "q-analysis-confidence", "text": "What confidence is attached to each conclusion and on what scale?", "kind": "measurement", "answer_data": [ "Confidence value", "Scale reference", "Assessing analyst reference" ] }, { "id": "q-analysis-rootcause", "text": "Has a root cause been established, and is it provisional or confirmed?", "kind": "state", "answer_data": [ "Root cause statement", "Confirmation status", "Supporting evidence reference" ] }, { "id": "q-analysis-source", "text": "Which observations underpin a finding and where are the underlying data held?", "kind": "provenance", "answer_data": [ "Observation reference", "Holding system reference", "Observation timestamp" ] } ], "data_elements": [ { "id": "de-analysis-hypothesis", "name": "Analysis hypothesis", "description": "A stated hypothesis with its current status.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-analysis-confidence", "name": "Analysis confidence", "description": "Confidence assigned to a stated conclusion on a declared scale.", "value_kind": "number", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "de-root-cause-status", "name": "Root cause status", "description": "Whether root cause is unknown, provisional or confirmed.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "a-analysis-note", "name": "Investigation analysis note", "description": "Dated analytical note attached to the case or to referenced objects, carrying assessment, confidence and author, without altering the referenced objects.", "media_or_form": [ "analyst note", "structured commentary object" ], "serial": false, "identity_strategy": "Governed object identifier assigned by the analysis platform, with author reference and creation and modification markers; sequence within a case is derived from those markers, not from the identifier.", "source_refs": [ "SRC-007" ] } ], "inline_only_rationale": null }, { "id": "f-response-impact-assessment", "name": "Response-side impact assessment", "description": "The assessed impact used to drive response decisions and notification thresholds, distinguished from the incident model's authoritative impact facts.", "source_refs": [ "SRC-002", "SRC-008", "SRC-009" ], "questions": [ { "id": "q-impact-categories", "text": "Which impact categories are assessed for response purposes and on what scale?", "kind": "measurement", "answer_data": [ "Impact category", "Assessed value", "Scale reference" ] }, { "id": "q-impact-affected-count", "text": "What is the current estimate of affected parties or records, and how uncertain is it?", "kind": "measurement", "answer_data": [ "Estimated count", "Estimation method", "Uncertainty statement" ] }, { "id": "q-impact-threshold", "text": "Does the assessed impact cross a reporting or escalation threshold, and which one?", "kind": "constraint", "answer_data": [ "Threshold reference", "Crossing determination", "Determination timestamp" ] }, { "id": "q-impact-crossborder", "text": "Is cross-border or multi-jurisdiction impact likely, and on what basis?", "kind": "spatial", "answer_data": [ "Affected jurisdiction reference", "Likelihood statement", "Supporting rationale" ] } ], "data_elements": [ { "id": "de-impact-assessment", "name": "Impact assessment entry", "description": "Assessed impact in a named category on a declared scale at a stated time.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-affected-count-estimate", "name": "Affected party estimate", "description": "Approximate number of affected data subjects, records or services.", "value_kind": "quantity", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-jurisdiction-ref", "name": "Affected jurisdiction reference", "description": "Jurisdictions in which impact is assessed as likely.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [], "inline_only_rationale": "This is a working assessment that changes repeatedly during a case and exists to drive response and notification decisions; the authoritative impact statement belongs to the incident model, so publishing a separate local artifact would create a competing record of fact." } ] } ] }, { "id": "response-actions-and-recovery", "name": "Response Actions and Recovery Coordination", "description": "Authorisation and tracking of response actions, deviations from the governing playbook, and the coordination interface to continuity and recovery plans.", "rationale": "CACAO locates command execution in agents and engines outside the case record, SP 800-184 separates recovery planning and execution from response, and the CSIRT Services Framework treats mitigation and recovery as coordinated services.", "source_refs": [ "SRC-006", "SRC-012", "SRC-005" ], "layers": [ { "id": "action-authorisation", "name": "Action Authorisation and Tracking", "description": "What was authorised, by whom, with what intended effect and what recorded outcome reference.", "source_refs": [ "SRC-006", "SRC-005", "SRC-013" ], "findings": [ { "id": "f-response-action-authorisation", "name": "Response action authorisation and outcome reference", "description": "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.", "source_refs": [ "SRC-006", "SRC-005" ], "questions": [ { "id": "q-action-authorised", "text": "Which action was authorised, against which target, and who approved it?", "kind": "authority", "answer_data": [ "Action description", "Target reference", "Approver reference" ] }, { "id": "q-action-intended-effect", "text": "What effect was the action intended to achieve and how would success be recognised?", "kind": "requirement", "answer_data": [ "Intended effect statement", "Success criterion", "Verification method" ] }, { "id": "q-action-outcome-ref", "text": "Where is the evidence that the action was carried out, and who holds it?", "kind": "evidence", "answer_data": [ "Execution evidence reference", "Executing system reference", "Completion timestamp" ] }, { "id": "q-action-reversibility", "text": "Is the action reversible, and what is the rollback path if it causes harm?", "kind": "constraint", "answer_data": [ "Reversibility flag", "Rollback procedure reference", "Rollback decision authority" ] } ], "data_elements": [ { "id": "de-action-id", "name": "Action record identifier", "description": "Identifier of the authorised action within the case.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-006" ] }, { "id": "de-action-target-ref", "name": "Action target reference", "description": "Reference to the asset, account or network object the action addresses.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-action-authorisation", "name": "Action authorisation", "description": "Approver reference, authorisation basis and authorisation time.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "de-action-outcome-ref", "name": "Execution evidence reference", "description": "Pointer to the executing system's record that the action was performed.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-action-requested-at", "name": "Action request time", "description": "Time the action was requested or authorised.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "a-action-task-record", "name": "Response action task record", "description": "Case-scoped record of one authorised action carrying target, authorisation, intended effect, timing and outcome references.", "media_or_form": [ "task record", "structured work item" ], "serial": true, "identity_strategy": "Master work-management identifier where the adopting Dimension operates one, otherwise a monotonic sequence within the case identifier namespace with no date component.", "source_refs": [ "SRC-006", "SRC-005" ] } ], "inline_only_rationale": null }, { "id": "f-containment-decision-and-deviation", "name": "Containment decisions, trade-offs and playbook deviations", "description": "Recorded decision points where containment competed with evidence preservation or service availability, and any departure from the bound playbook.", "source_refs": [ "SRC-013", "SRC-006", "SRC-005" ], "questions": [ { "id": "q-contain-tradeoff", "text": "Which trade-off between containment speed, service availability and evidence preservation was chosen and why?", "kind": "decision", "answer_data": [ "Options considered", "Chosen option", "Justification and deciding role" ] }, { "id": "q-contain-deviation", "text": "Where did the response depart from the bound playbook, and who approved the departure?", "kind": "exception", "answer_data": [ "Deviation description", "Approver reference", "Deviation timestamp" ] }, { "id": "q-contain-abort", "text": "What conditions would abort or reverse the containment strategy?", "kind": "constraint", "answer_data": [ "Abort condition", "Fallback strategy", "Monitoring signal reference" ] }, { "id": "q-contain-dependency", "text": "Which dependencies or third parties had to consent before containment could proceed?", "kind": "relationship", "answer_data": [ "Dependency reference", "Consent status", "Consent timestamp" ] } ], "data_elements": [ { "id": "de-decision-entry", "name": "Decision entry", "description": "A recorded decision with options, choice, rationale and deciding role.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-deviation-entry", "name": "Playbook deviation entry", "description": "Departure from the bound playbook with justification and approver.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-evidence-conflict-flag", "name": "Evidence preservation conflict flag", "description": "Marks that a containment action risked destroying evidence.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [ { "id": "a-deviation-record", "name": "Decision and deviation record", "description": "Reviewable record of material response decisions and departures from the governing playbook, suitable for post-incident review and external scrutiny.", "media_or_form": [ "decision log", "structured record" ], "serial": true, "identity_strategy": "Sequence within the case identifier namespace, bound to the deciding role reference and authorisation time; no date component in the identifier.", "source_refs": [ "SRC-006", "SRC-005" ] } ], "inline_only_rationale": null } ] }, { "id": "recovery-coordination", "name": "Recovery Coordination", "description": "The interface between the response case and externally governed continuity and recovery plans, and the response-side verification of restoration.", "source_refs": [ "SRC-012", "SRC-005" ], "findings": [ { "id": "f-continuity-plan-invocation-binding", "name": "Continuity and recovery plan invocation binding", "description": "The reference, trigger, parameters and acknowledgement recorded when the response requests invocation of a continuity or recovery plan governed by another model.", "source_refs": [ "SRC-012", "SRC-005" ], "questions": [ { "id": "q-invoke-which", "text": "Which continuity or recovery plan version was requested, and by which reference?", "kind": "identity", "answer_data": [ "Plan reference", "Plan version marker", "Request timestamp" ] }, { "id": "q-invoke-trigger", "text": "What condition triggered the invocation request and who was authorised to make it?", "kind": "authority", "answer_data": [ "Trigger condition", "Requesting role reference", "Authorisation basis" ] }, { "id": "q-invoke-parameters", "text": "Which case-specific parameters were passed with the invocation request?", "kind": "composition", "answer_data": [ "Parameter name and value", "Perimeter reference", "Constraint statement" ] }, { "id": "q-invoke-ack", "text": "What acknowledgement or activation reference was returned by the plan owner?", "kind": "interoperability", "answer_data": [ "Acknowledgement reference", "Acknowledging party", "Acknowledgement timestamp" ] } ], "data_elements": [ { "id": "de-plan-ref", "name": "Continuity or recovery plan reference", "description": "Reference to the externally governed plan requested for invocation.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-invocation-request", "name": "Invocation request", "description": "Trigger condition, requesting role, parameters and request time.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-invocation-ack-ref", "name": "Invocation acknowledgement reference", "description": "Reference returned by the plan owner confirming receipt or activation.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [], "inline_only_rationale": "This finding deliberately holds only a reference, a trigger, parameters and an acknowledgement pointer. Plan content, activation state, execution steps, testing and completion are owned by the referenced continuity and recovery model, so producing a local plan or activation artifact here would duplicate that model's lifecycle." }, { "id": "f-restoration-verification-and-residual-risk", "name": "Restoration verification and residual risk hand-off", "description": "The response-side verification that response objectives were met, the heightened monitoring period, and the residual risk handed to risk owners.", "source_refs": [ "SRC-012", "SRC-002", "SRC-005" ], "questions": [ { "id": "q-restore-verified", "text": "How was it verified that affected services and systems returned to an acceptable state?", "kind": "validation", "answer_data": [ "Verification method", "Verifying role reference", "Verification timestamp" ] }, { "id": "q-restore-recovery-time", "text": "When was recovery reached, as distinct from when containment was achieved?", "kind": "temporal", "answer_data": [ "Containment timestamp", "Recovery timestamp", "Definition applied" ] }, { "id": "q-restore-monitoring", "text": "What heightened monitoring period follows restoration and what would reopen the case?", "kind": "state", "answer_data": [ "Monitoring period duration", "Reopen trigger", "Monitoring owner reference" ] }, { "id": "q-restore-residual", "text": "Which residual risks remain accepted after restoration, and who accepted them?", "kind": "ownership", "answer_data": [ "Residual risk statement", "Accepting role reference", "Risk register reference" ] } ], "data_elements": [ { "id": "de-recovery-time", "name": "Recovery time", "description": "Time at which the affected environment was assessed as recovered.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-verification-result", "name": "Verification result", "description": "Outcome of the response-side restoration verification.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-monitoring-period", "name": "Heightened monitoring period", "description": "Duration of post-restoration watch before the case may close.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-residual-risk-ref", "name": "Residual risk reference", "description": "Pointer to the risk record accepting any remaining exposure.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "a-restoration-verification", "name": "Restoration verification record", "description": "Record of the checks, results and sign-off used by the response to conclude that response objectives were met.", "media_or_form": [ "verification record", "checklist result" ], "serial": false, "identity_strategy": "Bound to the case identifier with the verifying role reference and verification timestamp; identity derives from the case namespace, not from the verification date.", "source_refs": [ "SRC-012" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "evidence-timeline-and-record", "name": "Evidence, Chronology and Record Integrity", "description": "How case-related evidence is registered and held, and how the case chronology and change history are kept trustworthy.", "rationale": "Forensic practice requires integrity and custody discipline while keeping examination methodology separate; IODEF distinguishes detection, start, end, recovery, report and generation times and carries an explicit history log.", "source_refs": [ "SRC-013", "SRC-002", "SRC-009" ], "layers": [ { "id": "evidence-handling", "name": "Evidence Register and Holds", "description": "Registration, integrity and custody of evidence at the case boundary, and preservation obligations.", "source_refs": [ "SRC-013", "SRC-009" ], "findings": [ { "id": "f-evidence-register-and-custody", "name": "Evidence register entries and custody handoffs", "description": "Register of evidence items relied upon by the case with integrity values, acquiring party and custody transfers into and out of the response capability.", "source_refs": [ "SRC-013", "SRC-005" ], "questions": [ { "id": "q-evidence-what", "text": "Which evidence items does this case rely on and where is each physically or logically held?", "kind": "identity", "answer_data": [ "Evidence item identifier", "Storage location reference", "Custodian reference" ] }, { "id": "q-evidence-integrity", "text": "What integrity value was recorded at acquisition and when was it last reverified?", "kind": "validation", "answer_data": [ "Digest algorithm and value", "Acquisition timestamp", "Reverification timestamp" ] }, { "id": "q-evidence-custody", "text": "Which custody transfers occurred, between whom, and under what authorisation?", "kind": "provenance", "answer_data": [ "Transferring party", "Receiving party", "Transfer time and authorisation" ] }, { "id": "q-evidence-admissibility", "text": "Which handling constraints were imposed for possible legal use, and who set them?", "kind": "constraint", "answer_data": [ "Handling constraint statement", "Imposing authority", "Applicable jurisdiction reference" ] } ], "data_elements": [ { "id": "de-evidence-item-id", "name": "Evidence item identifier", "description": "Identifier of a registered evidence item relied upon by the case.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "de-evidence-digest", "name": "Evidence integrity value", "description": "Cryptographic digest with named algorithm recorded at acquisition.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "de-custody-transfer", "name": "Custody transfer entry", "description": "Transfer of custody with parties, authorisation and time.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [ { "id": "a-evidence-register-entry", "name": "Evidence register entry", "description": "Case-boundary register entry describing an evidence item, its integrity value, custodian and handling constraints.", "media_or_form": [ "register entry", "structured record" ], "serial": true, "identity_strategy": "Master evidence-management identifier where one exists, otherwise a monotonic sequence within the case namespace bound to the acquiring party; no date component.", "source_refs": [ "SRC-013" ] }, { "id": "a-custody-handoff-receipt", "name": "Custody handoff receipt", "description": "Signed or acknowledged receipt recording transfer of an evidence item between custodians.", "media_or_form": [ "receipt", "signed acknowledgement" ], "serial": true, "identity_strategy": "Sequence within the evidence register entry namespace, bound to both party references and the transfer timestamp.", "source_refs": [ "SRC-013" ] } ], "inline_only_rationale": null }, { "id": "f-preservation-hold-and-retention-class", "name": "Preservation hold and retention classification", "description": "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.", "source_refs": [ "SRC-009", "SRC-008", "SRC-013" ], "questions": [ { "id": "q-hold-scope", "text": "Which records and evidence are under preservation hold and who imposed the hold?", "kind": "retention", "answer_data": [ "Held record references", "Imposing authority", "Hold start timestamp" ] }, { "id": "q-hold-retention-class", "text": "What retention class and minimum period apply to the case record itself?", "kind": "retention", "answer_data": [ "Retention class code", "Minimum retention period", "Basis reference" ] }, { "id": "q-hold-personal-data", "text": "Which case content contains personal data requiring minimisation before long-term retention?", "kind": "privacy", "answer_data": [ "Personal data element references", "Minimisation measure", "Responsible role" ] }, { "id": "q-hold-release", "text": "Who authorises release of the hold and who executes the resulting disposition?", "kind": "ownership", "answer_data": [ "Releasing authority", "Executing party reference", "Disposition policy reference" ] } ], "data_elements": [ { "id": "de-hold-flag", "name": "Preservation hold flag", "description": "Indicates whether routine disposal is suspended for case records.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-009" ] }, { "id": "de-retention-class", "name": "Retention class", "description": "Retention class assigned to the case record and its attachments.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-disposition-owner-ref", "name": "Disposition owner reference", "description": "Party responsible for executing disposal when the hold is released.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [ { "id": "a-preservation-hold-notice", "name": "Preservation hold notice", "description": "Notice recording the scope, basis, imposing authority and release conditions of a hold over case records and evidence.", "media_or_form": [ "notice document", "structured record" ], "serial": true, "identity_strategy": "Sequence within the case namespace bound to the imposing authority reference; the effective period is carried as fields, never as part of the identifier.", "source_refs": [ "SRC-009", "SRC-013" ] } ], "inline_only_rationale": null } ] }, { "id": "chronology-and-provenance", "name": "Chronology and Record Provenance", "description": "Time semantics of the case and the history of who changed the record and on what basis.", "source_refs": [ "SRC-002", "SRC-007" ], "findings": [ { "id": "f-case-timeline-and-provenance", "name": "Case chronology, time semantics and change history", "description": "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.", "source_refs": [ "SRC-002", "SRC-007", "SRC-008" ], "questions": [ { "id": "q-time-types", "text": "Which distinct time types are recorded, such as event start, detection, report, containment, recovery and record generation?", "kind": "temporal", "answer_data": [ "Time type name", "Timestamp value with offset", "Precision and source system" ] }, { "id": "q-time-awareness", "text": "Which timestamp constitutes awareness for the purpose of starting regulatory clocks?", "kind": "constraint", "answer_data": [ "Awareness timestamp", "Determining role reference", "Justification statement" ] }, { "id": "q-time-uncertainty", "text": "How are uncertain or estimated times distinguished from observed ones?", "kind": "quality", "answer_data": [ "Estimation flag", "Uncertainty interval", "Basis of estimate" ] }, { "id": "q-history-changes", "text": "Who changed the case record, when, and what was the stated reason?", "kind": "provenance", "answer_data": [ "Change author reference", "Change timestamp", "Change description" ] }, { "id": "q-history-source-system", "text": "From which source system did each imported element arrive, and at what ingestion time?", "kind": "provenance", "answer_data": [ "Source system reference", "Ingestion timestamp", "Import batch reference" ] } ], "data_elements": [ { "id": "de-event-start-time", "name": "Event start time", "description": "Time the underlying activity is assessed to have started.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-detect-time", "name": "Detection time", "description": "Time the activity was first detected.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-generation-time", "name": "Record generation time", "description": "Time this case record or exchange document was generated.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "de-awareness-time", "name": "Awareness time", "description": "Determined moment of awareness used to start notification clocks.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008", "SRC-009" ] }, { "id": "de-history-entry", "name": "History entry", "description": "Change log entry with author, time, description and originating system.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-007" ] } ], "artifacts": [ { "id": "a-case-chronology", "name": "Case chronology", "description": "Ordered chronology of the engagement with typed timestamps, uncertainty markers and references to supporting entries.", "media_or_form": [ "chronology table", "structured timeline record" ], "serial": false, "identity_strategy": "Bound to the case identifier with a generation marker for each issued version; supersession is expressed by version, never by embedding a date in the identifier.", "source_refs": [ "SRC-002" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "communication-and-notification", "name": "Communication, Notification and Sharing", "description": "Internal escalation and situation reporting, external and regulatory notification, affected-party communication, and control of onward disclosure.", "rationale": "NIS2 imposes staged reporting duties, GDPR imposes separate supervisory-authority and data-subject duties, and TLP governs how case-derived information may be shared onward.", "source_refs": [ "SRC-008", "SRC-009", "SRC-004", "SRC-005" ], "layers": [ { "id": "stakeholder-communication", "name": "Internal Escalation and Situation Reporting", "description": "Who inside the organisation was informed, when, through which channel, and at what reporting cadence.", "source_refs": [ "SRC-005", "SRC-003" ], "findings": [ { "id": "f-internal-escalation-and-sitrep", "name": "Internal escalation and situation reporting", "description": "The record of internal notifications, escalation steps and periodic situation reports issued during the engagement.", "source_refs": [ "SRC-005", "SRC-003", "SRC-008" ], "questions": [ { "id": "q-sitrep-cadence", "text": "At what cadence are situation reports issued for this response tier, and to which audiences?", "kind": "process", "answer_data": [ "Reporting cadence", "Audience reference", "Next report due time" ] }, { "id": "q-sitrep-escalation", "text": "Which internal escalation steps were taken and what triggered each one?", "kind": "event", "answer_data": [ "Escalation step", "Trigger condition", "Escalation timestamp" ] }, { "id": "q-sitrep-channel", "text": "Which communication channel was used, and was it out-of-band because primary systems were suspect?", "kind": "security", "answer_data": [ "Channel reference", "Out-of-band flag", "Authentication method" ] }, { "id": "q-sitrep-audience-limit", "text": "Which internal audiences were deliberately not informed, and on what basis?", "kind": "access", "answer_data": [ "Excluded audience reference", "Exclusion basis", "Approving authority" ] } ], "data_elements": [ { "id": "de-notification-entry", "name": "Internal notification entry", "description": "Record of an internal party informed, with channel and time.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-sitrep-cadence", "name": "Situation report cadence", "description": "Interval at which situation reports are due for the assigned tier.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-channel-ref", "name": "Communication channel reference", "description": "Channel used, including any out-of-band alternative.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "a-situation-report", "name": "Situation report", "description": "Periodic report of current status, actions taken, next steps and outstanding decisions for a defined internal audience.", "media_or_form": [ "report document", "structured status record", "briefing message" ], "serial": true, "identity_strategy": "Monotonic sequence within the case identifier namespace with an audience marker; the reporting period is carried in fields, not in the identifier.", "source_refs": [ "SRC-005" ] } ], "inline_only_rationale": null } ] }, { "id": "external-regulatory-notification", "name": "External and Regulatory Notification", "description": "Binding of determined reporting obligations to the case, and communication to affected parties and the public.", "source_refs": [ "SRC-008", "SRC-009", "SRC-017" ], "findings": [ { "id": "f-regulatory-notification-binding", "name": "Regulatory notification binding and submission record", "description": "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.", "source_refs": [ "SRC-008", "SRC-009", "SRC-017" ], "questions": [ { "id": "q-notify-regime", "text": "Which reporting regimes were determined applicable, by whom, and against which case facts?", "kind": "authority", "answer_data": [ "Regime reference", "Determining party reference", "Determination basis" ] }, { "id": "q-notify-stages", "text": "Which submission stages does the bound regime require and what is each deadline relative to the clock start?", "kind": "constraint", "answer_data": [ "Stage name", "Deadline offset", "Clock start reference" ] }, { "id": "q-notify-submitted", "text": "What was submitted, to which recipient authority, and what reference was returned?", "kind": "evidence", "answer_data": [ "Submission content reference", "Recipient authority reference", "Acknowledgement reference and time" ] }, { "id": "q-notify-late", "text": "If a deadline was missed, what reasoned justification for the delay was recorded?", "kind": "exception", "answer_data": [ "Delay justification text", "Approving role reference", "Actual submission timestamp" ] }, { "id": "q-notify-content", "text": "Which mandated content elements were included, and which were still unknown at submission?", "kind": "requirement", "answer_data": [ "Content element name", "Provided value or omission marker", "Follow-up commitment" ] } ], "data_elements": [ { "id": "de-regime-binding", "name": "Reporting regime binding", "description": "Reference to a determined applicable regime with its determining party.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-009" ] }, { "id": "de-submission-stage", "name": "Submission stage", "description": "Named stage such as early warning, notification, intermediate or final report.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "de-submission-deadline", "name": "Submission deadline", "description": "Absolute deadline derived from the bound regime and the clock start.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-009" ] }, { "id": "de-authority-ack-ref", "name": "Authority acknowledgement reference", "description": "Reference returned by the receiving authority for a submission.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "de-delay-justification", "name": "Delay justification", "description": "Recorded reasons where a submission was later than the deadline.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [ { "id": "a-regulatory-submission", "name": "Regulatory notification submission", "description": "The dispatched notification for one stage of one regime, retained together with its transmission and acknowledgement references.", "media_or_form": [ "submission document", "portal form record", "structured message" ], "serial": true, "identity_strategy": "Sequence within the pairing of case identifier and regime binding, so that stages remain ordered; the authority's own reference is stored as an alternative identifier.", "source_refs": [ "SRC-008", "SRC-009" ] } ], "inline_only_rationale": null }, { "id": "f-affected-party-and-public-communication", "name": "Affected-party and public communication", "description": "Communication to affected individuals, customers or service recipients and any public statement, including approval and the content required for recipients to protect themselves.", "source_refs": [ "SRC-009", "SRC-008" ], "questions": [ { "id": "q-affected-trigger", "text": "What determination triggered direct communication to affected individuals rather than authority notification alone?", "kind": "decision", "answer_data": [ "Risk determination", "Deciding role reference", "Determination timestamp" ] }, { "id": "q-affected-content", "text": "Which protective recommendations and contact points were given to recipients?", "kind": "requirement", "answer_data": [ "Recommendation text", "Contact point reference", "Plain-language confirmation" ] }, { "id": "q-affected-reach", "text": "How were recipients reached when direct contact was disproportionate or impossible?", "kind": "exception", "answer_data": [ "Substitute communication method", "Justification", "Reach estimate" ] }, { "id": "q-affected-approval", "text": "Who approved the wording before release and which parties reviewed it?", "kind": "ownership", "answer_data": [ "Approving role reference", "Reviewer references", "Approval timestamp" ] } ], "data_elements": [ { "id": "de-affected-audience", "name": "Affected audience reference", "description": "Reference to the population addressed by a communication.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-protective-advice", "name": "Protective advice", "description": "Recommendations issued to recipients to mitigate adverse effects.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-communication-approval", "name": "Communication approval", "description": "Approver reference and approval time for released wording.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [ { "id": "a-affected-party-notice", "name": "Affected-party notice", "description": "Issued communication to affected individuals, customers or service recipients, retained in the released wording.", "media_or_form": [ "notice document", "published statement", "direct message template" ], "serial": true, "identity_strategy": "Sequence within the case namespace with an audience marker; superseding corrections reference the prior notice identifier.", "source_refs": [ "SRC-009", "SRC-008" ] } ], "inline_only_rationale": null } ] }, { "id": "information-sharing-controls", "name": "Information Sharing Controls", "description": "Handling markings and disclosure control applied to case-derived information.", "source_refs": [ "SRC-004", "SRC-007", "SRC-002" ], "findings": [ { "id": "f-handling-marking-and-disclosure", "name": "Handling markings and onward disclosure control", "description": "The handling label applied to case content, its mapping to exchange-format markings, and the record of onward disclosure packages and redactions.", "source_refs": [ "SRC-004", "SRC-007", "SRC-002" ], "questions": [ { "id": "q-marking-label", "text": "Which handling label applies to this case content and how is it displayed on issued material?", "kind": "security", "answer_data": [ "Handling label value", "Placement rule applied", "Labelling authority reference" ] }, { "id": "q-marking-map", "text": "How does the handling label map to markings in the exchange formats used, and where does the mapping break down?", "kind": "interoperability", "answer_data": [ "Source label", "Target marking value", "Unmapped case note" ] }, { "id": "q-marking-onward", "text": "Who may share this content onward, to whom, and under what condition?", "kind": "access", "answer_data": [ "Permitted recipient class", "Sharing condition", "Approving role reference" ] }, { "id": "q-marking-redaction", "text": "What was redacted or aggregated before onward sharing and who authorised it?", "kind": "privacy", "answer_data": [ "Redacted element reference", "Redaction method", "Authorising role reference" ] } ], "data_elements": [ { "id": "de-handling-label", "name": "Handling label", "description": "Sharing label applied to case content or to a specific element.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-marking-reference", "name": "Exchange marking reference", "description": "Reference to the marking object used in an exchange format.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-002" ] }, { "id": "de-disclosure-entry", "name": "Onward disclosure entry", "description": "Record of content disclosed to a named recipient with the condition applied.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "a-marked-disclosure-package", "name": "Marked disclosure package", "description": "Case-derived material prepared for a specific recipient, carrying the handling label on the material itself and a record of any redaction.", "media_or_form": [ "labelled document", "structured exchange bundle" ], "serial": true, "identity_strategy": "Sequence within the case namespace bound to the recipient reference and the applied handling label; identity never encodes the disclosure date.", "source_refs": [ "SRC-004", "SRC-007" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "closure-learning-and-assurance", "name": "Closure, Learning and Assurance", "description": "How a case reaches a defensible end state, what is learned from it, and how response performance and record quality are evidenced.", "rationale": "IODEF carries an explicit workflow status vocabulary, ISO/IEC 27035-1 makes lessons learned a named phase, and SP 800-61r3 places improvement inside cybersecurity risk management rather than treating it as an optional postscript.", "source_refs": [ "SRC-002", "SRC-014", "SRC-001", "SRC-012" ], "layers": [ { "id": "closure-and-review", "name": "Closure and Post-Incident Review", "description": "The end state of the case and the structured learning drawn from it.", "source_refs": [ "SRC-002", "SRC-014", "SRC-001" ], "findings": [ { "id": "f-case-status-and-closure", "name": "Case status model and closure", "description": "The workflow status vocabulary of the case, closure preconditions, the final closure statement and the conditions permitting reopening.", "source_refs": [ "SRC-002", "SRC-014" ], "questions": [ { "id": "q-status-vocab", "text": "Which workflow statuses can the case hold and which transitions are permitted?", "kind": "state", "answer_data": [ "Status value", "Permitted transitions", "Transition authority" ] }, { "id": "q-closure-precondition", "text": "Which preconditions must be satisfied before the case may be closed?", "kind": "validation", "answer_data": [ "Precondition list", "Satisfaction evidence reference", "Verifying role" ] }, { "id": "q-closure-outcome", "text": "What closure outcome is recorded, such as resolved, unresolved, transferred or withdrawn?", "kind": "lifecycle", "answer_data": [ "Closure outcome code", "Closure timestamp", "Closing role reference" ] }, { "id": "q-reopen", "text": "Under what conditions is a closed case reopened rather than a new case being opened?", "kind": "exception", "answer_data": [ "Reopen condition", "Reopen decision reference", "Successor case reference" ] } ], "data_elements": [ { "id": "de-case-status", "name": "Case status", "description": "Current workflow status of the response case.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "de-closure-outcome", "name": "Closure outcome", "description": "Recorded outcome at closure.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-closed-at", "name": "Closure time", "description": "Time the case was closed.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-reopen-ref", "name": "Reopen reference", "description": "Reference to the decision that reopened a previously closed case.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "a-closure-statement", "name": "Case closure statement", "description": "Final statement of what was handled, what was done, what remains open and on what basis the case was closed.", "media_or_form": [ "final report", "structured closure record" ], "serial": false, "identity_strategy": "Bound to the case identifier with a version marker so that corrections supersede rather than replace; no date component in the identifier.", "source_refs": [ "SRC-002", "SRC-014" ] } ], "inline_only_rationale": null }, { "id": "f-post-incident-review-and-improvement", "name": "Post-incident review and improvement actions", "description": "The structured review of the engagement and the improvement actions it generates, each with an owner, target and verification of implementation.", "source_refs": [ "SRC-014", "SRC-001", "SRC-012", "SRC-005" ], "questions": [ { "id": "q-review-scope", "text": "Which review was held, who participated, and what scope was agreed?", "kind": "process", "answer_data": [ "Review type", "Participant references", "Review scope statement" ] }, { "id": "q-review-finding", "text": "Which findings concern the response process rather than the underlying technical cause?", "kind": "quality", "answer_data": [ "Finding statement", "Category", "Supporting evidence reference" ] }, { "id": "q-review-action-owner", "text": "Who owns each improvement action and by when must it be completed?", "kind": "ownership", "answer_data": [ "Action statement", "Owner reference", "Target completion time" ] }, { "id": "q-review-verify", "text": "How is it verified that an improvement action was actually implemented and effective?", "kind": "validation", "answer_data": [ "Verification method", "Verification result", "Verifying role reference" ] }, { "id": "q-review-feedback", "text": "Which artefacts, such as playbooks, detection rules or the charter, must be updated as a result?", "kind": "relationship", "answer_data": [ "Target artefact reference", "Requested change", "Receiving owner reference" ] } ], "data_elements": [ { "id": "de-review-finding", "name": "Review finding", "description": "A stated finding about the response process with its category.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "de-improvement-action", "name": "Improvement action", "description": "Action with owner, target time and current status.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-improvement-verification", "name": "Improvement verification", "description": "Evidence that an improvement action was implemented and assessed.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "a-post-incident-review", "name": "Post-incident review report", "description": "Record of the review, its participants, findings and agreed decisions about the response process.", "media_or_form": [ "review report", "structured record" ], "serial": false, "identity_strategy": "Bound to the case identifier with a version marker; where several reviews occur, each is distinguished by review type and participant set rather than by date.", "source_refs": [ "SRC-014", "SRC-001" ] }, { "id": "a-improvement-action-register", "name": "Improvement action register", "description": "Register of actions arising from the review with owners, targets, status and verification references.", "media_or_form": [ "register", "structured backlog entries" ], "serial": true, "identity_strategy": "Master work-management identifier where one exists, otherwise a monotonic sequence in the improvement register namespace, cross-referenced to the originating case.", "source_refs": [ "SRC-001", "SRC-012" ] } ], "inline_only_rationale": null } ] }, { "id": "assurance-and-measurement", "name": "Assurance and Measurement", "description": "How response performance is measured and how the case record itself is validated.", "source_refs": [ "SRC-012", "SRC-001", "SRC-002" ], "findings": [ { "id": "f-response-performance-metrics", "name": "Response performance measurement", "description": "Defined measures of response performance derived from typed case timestamps, with explicit definitions, windows and known data-quality limits.", "source_refs": [ "SRC-012", "SRC-001", "SRC-002" ], "questions": [ { "id": "q-metric-definition", "text": "How is each response measure defined, including which timestamps bound it?", "kind": "measurement", "answer_data": [ "Measure name", "Start and end timestamp types", "Unit and precision" ] }, { "id": "q-metric-population", "text": "Which population of cases does a reported figure cover and over which window?", "kind": "temporal", "answer_data": [ "Case selection rule", "Window start and end", "Excluded case references" ] }, { "id": "q-metric-quality", "text": "Which known data-quality limits would make a measure misleading?", "kind": "quality", "answer_data": [ "Limitation statement", "Affected measure", "Mitigation or caveat" ] }, { "id": "q-metric-use", "text": "Which decisions may and may not be based on these measures?", "kind": "constraint", "answer_data": [ "Permitted use", "Prohibited use", "Approving authority" ] } ], "data_elements": [ { "id": "de-measure-definition", "name": "Measure definition", "description": "Named measure with its bounding timestamp types and unit.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-measure-value", "name": "Measure value", "description": "Computed value for a case or a case population.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-measure-caveat", "name": "Measure caveat", "description": "Known limitation affecting interpretation of a value.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [], "inline_only_rationale": "Measures are derived values computed from typed timestamps already held on the case record; materialising them as a separate artifact would create a second, drifting source of truth, so they are kept as inline definitions and computed values." }, { "id": "f-case-record-validation-and-conformance", "name": "Case record validation and conformance claims", "description": "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.", "source_refs": [ "SRC-002", "SRC-004", "SRC-001", "SRC-006" ], "questions": [ { "id": "q-validate-gate", "text": "Which fields must be present before the case may move to a given status?", "kind": "validation", "answer_data": [ "Status gate", "Mandatory field list", "Enforcing role or process" ] }, { "id": "q-validate-consistency", "text": "Which cross-field consistency rules apply, such as recovery time not preceding detection time?", "kind": "constraint", "answer_data": [ "Rule statement", "Violation severity", "Remediation action" ] }, { "id": "q-validate-conformance", "text": "What evidence supports any claim of conformance to an external standard or profile?", "kind": "evidence", "answer_data": [ "Claimed standard reference", "Evidence reference", "Scope and limits of the claim" ] }, { "id": "q-validate-export", "text": "Which validation applies when the case is exported to an exchange format, and what is lost?", "kind": "interoperability", "answer_data": [ "Target format reference", "Validation result", "Known loss statement" ] } ], "data_elements": [ { "id": "de-validation-rule", "name": "Validation rule", "description": "Rule that the case record must satisfy at a defined state gate.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-validation-result", "name": "Validation result", "description": "Outcome of applying validation rules to the case record.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-alignment-claim", "name": "Alignment claim", "description": "Declared alignment to an external standard with its supporting evidence and stated limits.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-004" ] } ], "artifacts": [], "inline_only_rationale": "Validation rules and alignment claims are metadata about the case record rather than deliverables of the engagement; they are evaluated by the adopting platform against the inline record, and no separate transmissible object is produced by this model." } ] } ] } ] }, "functions": [ { "id": "open-response-case", "name": "Open response case", "description": "Create a case aggregate for a declared or suspected incident, assign identity and bind the responding capability.", "inputs": [ "Incident record reference", "Responding capability identifier", "Intake record reference" ], "outputs": [ "Response case record with case identifier", "Initial case status" ], "preconditions": [ "Responding capability charter is published and current", "Incident record reference resolves in the composing incident model" ], "effects": [ "Case identifier reserved in the issuing namespace", "Case placed in an open status with a generation time recorded" ], "source_refs": [ "SRC-002", "SRC-003", "SRC-005" ] }, { "id": "record-detection-intake", "name": "Record detection and report intake", "description": "Register how the situation was discovered or reported, authenticate the reporter and acknowledge receipt.", "inputs": [ "Inbound report content", "Discovery source value", "Reporter contact reference" ], "outputs": [ "Inbound incident report artifact", "Report receipt time", "Acknowledgement reference" ], "preconditions": [ "An open case exists or is created by this call" ], "effects": [ "Intake provenance attached to the case", "Completeness assessment recorded for follow-up" ], "source_refs": [ "SRC-002", "SRC-003", "SRC-005" ] }, { "id": "declare-incident-and-assign-tier", "name": "Declare incident and assign response tier", "description": "Record the declaration decision and the triage outcome, including criteria version and started clocks.", "inputs": [ "Declaration basis", "Declaring role reference", "Triage criteria version" ], "outputs": [ "Declaration state", "Response tier", "Started response clocks" ], "preconditions": [ "Declaring role holds the delegated authority recorded in the charter" ], "effects": [ "Case status transitions to an active response state", "Response clocks begin from the recorded start times" ], "source_refs": [ "SRC-014", "SRC-005", "SRC-002" ] }, { "id": "bind-governing-playbook", "name": "Bind governing playbook or procedure", "description": "Attach the identity, version, validity window and integrity value of the externally governed playbook, or record ad hoc response.", "inputs": [ "Playbook reference", "Version marker", "Content digest" ], "outputs": [ "Playbook binding tuple", "Ad hoc response flag where applicable" ], "preconditions": [ "Playbook validity window covers the current time or a deviation is recorded" ], "effects": [ "Case records which procedure governs it without copying or executing that procedure" ], "source_refs": [ "SRC-006", "SRC-001" ] }, { "id": "authorise-response-action", "name": "Authorise response action", "description": "Record an authorised containment, eradication or mitigation action with target, approver, intended effect and reversibility.", "inputs": [ "Action description", "Target reference", "Approver reference" ], "outputs": [ "Response action task record", "Action request time" ], "preconditions": [ "Approver holds the decision right for the action class", "Evidence preservation conflict has been assessed" ], "effects": [ "Action is authorised and tracked in the case; execution remains with the external system that performs it" ], "source_refs": [ "SRC-006", "SRC-005", "SRC-013" ] }, { "id": "attach-execution-evidence-reference", "name": "Attach execution evidence reference", "description": "Link an authorised action to the executing system's record that it was performed, without importing execution or audit semantics.", "inputs": [ "Action record identifier", "Executing system reference", "Completion timestamp" ], "outputs": [ "Updated action record with outcome reference" ], "preconditions": [ "Action record exists and is in an authorised state" ], "effects": [ "Case can evidence that an action was carried out while the executing system remains the authority for how" ], "source_refs": [ "SRC-006" ] }, { "id": "request-continuity-plan-invocation", "name": "Request continuity or recovery plan invocation", "description": "Emit a referenced invocation request with case-specific parameters to the model that owns the plan, and record the acknowledgement.", "inputs": [ "Plan reference", "Trigger condition", "Invocation parameters" ], "outputs": [ "Invocation request record", "Acknowledgement reference" ], "preconditions": [ "Requesting role is authorised to invoke", "Plan reference resolves in the referenced continuity and recovery model" ], "effects": [ "Invocation request and acknowledgement recorded on the case; plan activation state and execution remain owned by the referenced model" ], "source_refs": [ "SRC-012", "SRC-005" ] }, { "id": "register-evidence-and-custody", "name": "Register evidence and record custody handoff", "description": "Add an evidence item to the case register with integrity value and custodian, and record transfers at the case boundary.", "inputs": [ "Evidence item description", "Digest algorithm and value", "Custodian reference" ], "outputs": [ "Evidence register entry", "Custody handoff receipt" ], "preconditions": [ "Acquisition was performed under the applicable handling constraints" ], "effects": [ "Case can demonstrate what it relied on and who held it; examination methodology stays with the forensic discipline" ], "source_refs": [ "SRC-013", "SRC-005" ] }, { "id": "apply-preservation-hold", "name": "Apply or release preservation hold", "description": "Set or lift a hold that suspends routine disposal of case records and registered evidence, naming the authority and the executing party.", "inputs": [ "Hold scope", "Imposing or releasing authority", "Basis reference" ], "outputs": [ "Preservation hold notice", "Updated retention state" ], "preconditions": [ "A retention class is assigned to the case record" ], "effects": [ "Disposal is suspended or resumed; physical disposal is executed by the party named in the adopting Dimension's records policy" ], "source_refs": [ "SRC-009", "SRC-013" ] }, { "id": "bind-reporting-obligation", "name": "Bind determined reporting obligation", "description": "Attach an externally determined reporting regime to the case, derive stage deadlines from the recorded awareness time and track submissions.", "inputs": [ "Regime reference", "Determining party reference", "Awareness timestamp" ], "outputs": [ "Regime binding with staged deadlines", "Deadline monitor state" ], "preconditions": [ "Awareness time is determined and recorded", "Applicability was determined by the competent party outside this model" ], "effects": [ "Case carries computable deadlines and stage state without asserting the legal determination itself" ], "source_refs": [ "SRC-008", "SRC-009", "SRC-017" ] }, { "id": "record-notification-submission", "name": "Record notification submission", "description": "Retain the dispatched notification for a stage, its recipient authority, transmission facts and returned reference or delay justification.", "inputs": [ "Submission content", "Recipient authority reference", "Submission timestamp" ], "outputs": [ "Regulatory notification submission artifact", "Acknowledgement reference" ], "preconditions": [ "A regime binding exists for the stage being submitted" ], "effects": [ "Stage marked as submitted; missed deadlines carry a recorded justification" ], "source_refs": [ "SRC-008", "SRC-009" ] }, { "id": "produce-marked-disclosure", "name": "Produce marked disclosure package", "description": "Assemble case-derived material for a named recipient, apply the handling label to the material and record redactions and conditions.", "inputs": [ "Content selection", "Handling label", "Recipient reference" ], "outputs": [ "Marked disclosure package", "Onward disclosure entry" ], "preconditions": [ "Handling label is set and the approving role has authorised the recipient class" ], "effects": [ "Onward sharing is traceable and conditions travel with the material" ], "source_refs": [ "SRC-004", "SRC-007" ] }, { "id": "validate-case-record", "name": "Validate case record against state gate", "description": "Evaluate completeness and cross-field consistency rules for a target status and report violations.", "inputs": [ "Case record", "Target status", "Rule set reference" ], "outputs": [ "Validation result", "Violation list" ], "preconditions": [ "Rule set for the target status is available" ], "effects": [ "Blocking violations prevent a status transition until remediated" ], "source_refs": [ "SRC-002", "SRC-006" ] }, { "id": "close-case", "name": "Close case and issue closure statement", "description": "Verify closure preconditions, record the closure outcome and issue the final statement of handling.", "inputs": [ "Closure outcome", "Closing role reference", "Verification results" ], "outputs": [ "Case closure statement", "Closure timestamp" ], "preconditions": [ "Restoration verification recorded or explicit exception approved", "All blocking validation violations cleared" ], "effects": [ "Case status becomes closed; reopening requires a recorded decision" ], "source_refs": [ "SRC-002", "SRC-014", "SRC-012" ] }, { "id": "record-post-incident-review", "name": "Record post-incident review and improvement actions", "description": "Capture review findings about the response process and open owned improvement actions with verification requirements.", "inputs": [ "Review participants", "Findings", "Proposed actions" ], "outputs": [ "Post-incident review report", "Improvement action register entries" ], "preconditions": [ "Case is closed or a review is scheduled for a long-running case" ], "effects": [ "Improvement actions are owned and tracked to verified implementation" ], "source_refs": [ "SRC-014", "SRC-001", "SRC-012" ] }, { "id": "compute-response-measures", "name": "Compute response performance measures", "description": "Derive defined measures from typed case timestamps for a stated case population and window, with caveats attached.", "inputs": [ "Measure definitions", "Case selection rule", "Window bounds" ], "outputs": [ "Measure values", "Applicable caveats" ], "preconditions": [ "Required timestamp types are present and typed" ], "effects": [ "Comparable measures produced without creating a second source of truth" ], "source_refs": [ "SRC-012", "SRC-001" ] }, { "id": "export-case-to-exchange-format", "name": "Export case to exchange format", "description": "Project the case record into an external exchange representation, applying marking mappings and reporting information loss.", "inputs": [ "Case record", "Target format reference", "Handling label" ], "outputs": [ "Exchange document", "Loss and mapping report" ], "preconditions": [ "Handling label maps to a supported marking in the target format or an unmapped-case note is produced" ], "effects": [ "Interchange is possible while divergences between vocabularies are recorded rather than hidden" ], "source_refs": [ "SRC-002", "SRC-007", "SRC-004" ] } ], "composition": [ { "target": "WM-ACT-019", "relation": "CHILD", "purpose": "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.", "required": true, "source_refs": [ "SRC-001", "SRC-005" ] }, { "target": "WM-ACT-020", "relation": "COMPOSE", "purpose": "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.", "required": true, "source_refs": [ "SRC-002", "SRC-010", "SRC-011" ] }, { "target": "WM-ACT-043", "relation": "REFERENCE", "purpose": "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.", "required": false, "source_refs": [ "SRC-012" ] }, { "target": "Candidate sibling model: digital forensics and evidence examination (not yet registered)", "relation": "REFERENCE", "purpose": "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.", "required": false, "source_refs": [ "SRC-013" ] }, { "target": "Candidate sibling model: regulatory obligation and jurisdiction register (not yet registered)", "relation": "REFERENCE", "purpose": "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.", "required": false, "source_refs": [ "SRC-008", "SRC-009", "SRC-017" ] }, { "target": "IETF RFC 7970 IODEF version 2", "relation": "ALIGN", "purpose": "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.", "required": false, "source_refs": [ "SRC-002" ] }, { "target": "OASIS CACAO Security Playbooks version 2.0", "relation": "ALIGN", "purpose": "Alignment for playbook identity, versioning and validity when binding a governing procedure to a case; workflow execution, agents and targets remain outside this model.", "required": false, "source_refs": [ "SRC-006" ] }, { "target": "OASIS STIX version 2.1", "relation": "ALIGN", "purpose": "Alignment for object identity, creation and modification markers, confidence, external references, notes and data markings when case content is exchanged as threat intelligence.", "required": false, "source_refs": [ "SRC-007" ] }, { "target": "FIRST Traffic Light Protocol version 2.0", "relation": "MIX-IN", "purpose": "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.", "required": false, "source_refs": [ "SRC-004" ] }, { "target": "ENISA Reference Security Incident Taxonomy", "relation": "ALIGN", "purpose": "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.", "required": false, "source_refs": [ "SRC-010", "SRC-011" ] }, { "target": "NIST SP 800-61r3 CSF 2.0 Community Profile", "relation": "ALIGN", "purpose": "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.", "required": false, "source_refs": [ "SRC-001" ] }, { "target": "MITRE ATT&CK technique catalogue", "relation": "REFERENCE", "purpose": "Technique references are carried with an explicit catalogue version so that assertions remain resolvable across catalogue releases; technique definitions are not reproduced.", "required": false, "source_refs": [ "SRC-015" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "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.", "The owner package must declare the bindings this model leaves open: the incident model instance, the continuity and recovery model instance, the applicable reporting-regime register, the evidence discipline and the records retention policy.", "The owner package must publish the responding capability's service description and keep the authority level, constituency and level of support current, since case decisions cite it.", "The owner package must state which platform executes response actions and holds their audit trail, confirming that this model records authorisations and references only." ], "namespace_guidance": "Use a stable dimension-scoped namespace of the form .act.inc for case identifiers, with sub-namespaces per responding capability so that identifiers issued by cooperating teams remain distinguishable and can be carried as alternative identifiers. Namespaces must not encode dates, org-chart names or tool names that change on reorganisation or migration.", "registry_links": [ "Vercy registry entry vr.wm-act-042 with nav path NAV.ACT.INC and domain tag ACT.INC", "Relation ledger entry composing WM-ACT-020 into this model and referencing WM-ACT-043", "Adopting-Dimension register of responding capabilities, reporting regimes and evidence custodians" ] }, "canon_and_patch": { "canonicalization_rules": [ "Timestamps are canonicalised to RFC 3339 with seconds and an explicit offset or Z; the original local representation is retained as provenance where it carries meaning.", "Identifiers are canonicalised as namespace plus local identifier; alternative identifiers held by other parties are kept as a separate typed collection and never overwrite the master identifier.", "Coded values from external vocabularies are stored as the pairing of value and catalogue version; unmapped values are retained verbatim with an explicit unmapped marker rather than being coerced.", "Free text is stored without presentational markup; handling labels are stored as structured values and rendered onto issued material at export." ], "patch_rules": [ "Patches are additive: superseded values are retained with the superseding change entry, its author and its stated reason, because response records are reviewed after the fact.", "Any change to a typed timestamp, declaration state, closure outcome or handling label requires a recorded reason and the acting role reference.", "Correcting an issued artifact creates a superseding version referencing the prior identifier; issued notifications and disclosures are never edited in place.", "Patches to a case under preservation hold are permitted only as additive corrections and must reference the hold notice." ], "compatibility_rules": [ "Adding an optional data element, coded value or artifact type is a compatible change; making an element required, narrowing cardinality or removing a status value is breaking.", "Changing the meaning of a typed timestamp, of the awareness time, or of a closure outcome is breaking even when the field name is unchanged.", "External vocabulary version upgrades are compatible only when accompanied by a mapping and a revalidation record; unmapped values must be reported, not silently dropped.", "Projections to exchange formats must declare known information loss; loss discovered later is treated as a defect against the projection, not against the model." ] }, "artifact_rules": { "identity_priority": [ "Identifier issued by the authoritative master system for the record, such as the case-management, work-management or evidence-management system of record in the adopting Dimension", "Governed global identifier or IRI where the record is published under a registry or exchange-format namespace, including identifiers assigned by a cooperating authority and carried as alternative identifiers", "UUID or ULID minted by the adopting Dimension when no master-system or governed identifier exists, recorded together with the minting namespace" ], "timestamp_rule": "All time values use RFC 3339 with seconds and an explicit numeric offset or Z; local wall-clock strings without an offset are rejected. Event time, detection time, report time, containment time, recovery time and closure time are stored as separate typed values and must never be collapsed into one field, and the record generation or ingestion time is stored separately from every event time so that late or corrected reporting is visible. Where the two differ, both the event time and the observation or ingestion time are retained, with estimated times explicitly flagged and carrying an uncertainty interval.", "serial_naming_rule": "Serial artifacts are numbered monotonically within an explicitly named parent namespace, normally the case identifier, starting at one and never reused, even after withdrawal. Serial numbers must not embed dates, years, periods or organisational codes; effective periods and audiences are carried as fields. Corrections take a new serial that references the superseded identifier.", "integrity_rule": "Every issued artifact records a content digest with its named algorithm, the issuing role reference and the issue time; evidence register entries additionally record the digest captured at acquisition and each reverification. Integrity values are recorded and compared by this model, while the storage platform and the evidence discipline remain responsible for enforcing immutability and for the platform audit trail." }, "policies": [ "Boundary policy: the case record cites incident facts, plan content, execution results and audit records by reference; it never copies or restates content that another model or system masters.", "Authority policy: no containment, notification or disclosure entry is valid without a recorded acting role and the authority basis under which the role acted.", "Handling policy: every case and every issued artifact carries a handling label, and onward disclosure is recorded with recipient, condition and any redaction.", "Deadline policy: notification deadlines are computed from the recorded awareness time and the bound regime; a missed deadline is recorded with a reasoned justification rather than being retro-adjusted.", "Falsifiability policy: hypotheses, estimates and confidence values are recorded as such and are distinguishable from observed facts at every point in the case record." ], "crud": { "read": [ "Reading a case record requires an assigned case role or an explicit grant; the handling label constrains what may be read and by whom.", "Aggregated and de-identified reads for measurement are permitted without case-level grants where the population is large enough to prevent re-identification.", "Every read of evidence register entries and of affected-party content is restricted to roles named in the case, with the reason for access recorded.", "Historic versions and superseded values are readable to roles with review authority so that decisions can be reconstructed." ], "create": [ "A case may be created only with a resolvable incident reference or an intake record, and always with an issued case identifier from the governed namespace.", "Artifacts are created only by roles holding the corresponding decision right; issued notifications additionally require the recorded approval.", "Every created record carries a generation time, a creating role reference and, where imported, a source system reference and ingestion time.", "Duplicate detection runs on creation against open cases and alternative identifiers to prevent parallel handling of the same engagement." ], "update": [ "Updates are additive and versioned; the superseded value, the acting role and the stated reason are retained.", "Status transitions are permitted only where the target state's validation gate passes or an approved exception is recorded.", "Handling labels may be relaxed only by the labelling authority or the original source, and the change is recorded with justification.", "Issued artifacts are never updated in place; a superseding version is issued that references the prior identifier." ], "delete": [ "Case records are not hard-deleted while a preservation hold is in force; the hold flag blocks all disposition until released by the recorded authority.", "On release of a hold and expiry of the assigned retention class, disposition is applied to the case record and its attachments, and a tombstone is retained carrying the case identifier, retention class, disposition authority, disposition time and a statement of what was disposed, so that references from other models continue to resolve.", "Erasure requests affecting personal data inside a case record are handled by minimising or redacting the affected elements while retaining the case skeleton and the breach documentation required of the controller; the request itself is adjudicated by the privacy or legal function, not by this model.", "Execution of physical deletion, media sanitisation and backup expiry is owned by the adopting Dimension's records and platform policy; evidence disposal is owned by the evidence custodian and, where an evidence item is under legal control, by the competent authority. This model records the disposition decision and the tombstone but does not perform or enforce deletion.", "Deletion of an artifact never deletes the references held by other models; broken references are reported as defects and resolved through the tombstone." ] }, "roles": [ { "name": "Model steward", "responsibilities": [ "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" ] }, { "name": "Response case owner", "responsibilities": [ "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" ] }, { "name": "Records and disclosure controller", "responsibilities": [ "Assign retention classes, impose and release preservation holds and approve dispositions", "Approve handling labels, recipients and redactions for onward disclosure" ] }, { "name": "Notification coordinator", "responsibilities": [ "Bind determined reporting obligations to the case and monitor stage deadlines", "Retain submissions, acknowledgements and any reasoned justification for delay" ] }, { "name": "Interoperability maintainer", "responsibilities": [ "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" ] }, { "name": "Post-incident reviewer", "responsibilities": [ "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" ] } ], "access": { "default_rule": "Deny by default. Access is granted to roles assigned on the specific case, bounded further by the handling label carried by the content, and every grant is time-bounded and recorded with its reason.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Break-glass access for a declared crisis, granted by a named authority, time-bounded and reviewed after closure", "Regulator, supervisory authority or law-enforcement access under a recorded legal basis, which may override the handling label but is recorded as a disclosure entry", "Legal counsel and privacy function access to affected-party content and evidence for obligation assessment", "Aggregated and de-identified access for measurement and improvement reporting", "Emergency read for a downstream continuity function limited to the invocation parameters it needs, not to the whole case" ], "audit_requirements": [ "The adopting Dimension's platform must log every read, grant, export and disposition of case content with actor, time, scope and reason, and must retain those logs at least as long as the case retention class.", "Break-glass and authority-override accesses must be reviewed after case closure by a role independent of the case owner.", "This model records references to such logs and the disclosure entries it creates; the semantics, integrity and retention of the platform audit trail are owned by the platform and the adopting Dimension's audit policy, not by this model." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Owner or maintainer", "Registry and model identifier" ], "read_order": [ "Read AGENTS.md first and resolve Name, Type and the four URLs before touching any record", "Read the specification to establish scope, boundaries and the out-of-scope list, especially incident facts, plan execution and action enforcement", "Read the storage type description to learn how bundles, layers, findings and artifacts are projected in this deployment", "Read the interface description for the read, create, update and delete operations available and their authorisation model", "Read the processes description for state gates, validation rules, deadline handling and disposition", "Resolve the bound sibling models and registers before opening or modifying a case" ] } }, "coverage": { "claim": "Single-provider (Claude) coverage of the incident-response case surface: mandate and readiness binding, case identity and triage, detection intake and analysis, action authorisation and recovery coordination, evidence and chronology, notification and disclosure control, and closure, learning and measurement — 7 bundles, 15 layers, 26 findings, 108 questions, 18 artifacts and 17 functions grounded in 16 primary and 1 tier-3 secondary source. Coverage is claimed only for the response process, not for incident facts (WM-ACT-020), continuity-plan lifecycle (WM-ACT-043), action execution or audit-trail semantics. It is not complete for sector or national reporting regimes beyond NIS2 and GDPR, for non-cyber, OT and safety-of-life incident command, or for access-control and disposition-tombstone rules asserted in the coverage checklist but not carried by any finding. No independent second-provider review exists, so this is a reviewable draft, not a validated model.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Case identifier plus alternative identifiers held by cooperating parties, with master-system identifier first in the identity priority and no date components permitted." }, { "dimension": "lifecycle", "status": "covered", "notes": "Declaration, triage, active response, restoration verification, closure and reopening are modelled as explicit states with gates; the incident's own lifecycle stays with WM-ACT-020." }, { "dimension": "relationships", "status": "covered", "notes": "Composition to the incident model, reference to continuity and recovery plans, related-activity links and alignments to external vocabularies are all typed and cited." }, { "dimension": "temporal", "status": "covered", "notes": "Event, detection, report, containment, recovery, closure and generation or ingestion times are separately typed in RFC 3339 with offsets; awareness time is singled out as the notification clock start." }, { "dimension": "provenance", "status": "covered", "notes": "Discovery source, reporting party, change history with author and reason, and source system plus ingestion time for imported elements." }, { "dimension": "ownership", "status": "covered", "notes": "Case owner, decision rights, handover records, residual risk acceptance and named disposition owner; plan and evidence ownership are explicitly external." }, { "dimension": "validation", "status": "covered", "notes": "State-gate completeness rules, cross-field consistency rules, export validation with declared loss, and evidence-backed alignment claims rather than conformance assertions." }, { "dimension": "access", "status": "covered", "notes": "Deny-by-default with case-role grants bounded by handling labels, five named exception paths, and platform audit requirements stated as obligations on the adopting Dimension." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Retention class, preservation hold, tombstone on disposition, personal-data minimisation, and explicit statement that execution of deletion is owned by the records policy, evidence custodian or competent authority." }, { "dimension": "interoperability", "status": "covered", "notes": "Alignments to IODEF, STIX, CACAO, TLP, RSIT and ATT&CK carry catalogue versions; unmapped values are retained with an explicit marker and loss is reported on export." }, { "dimension": "classification", "status": "covered", "notes": "External taxonomy and technique bindings are carried by value and version; the response tier is modelled as a response-side decision distinct from incident severity." }, { "dimension": "evidence and chain of custody", "status": "covered", "notes": "Register entries, integrity digests and custody handoffs at the case boundary only; acquisition and examination methodology are referenced to the forensic discipline." }, { "dimension": "measurement", "status": "covered", "notes": "Measures are defined from typed timestamps with population, window and caveats, and are inline derived values rather than a competing artifact." }, { "dimension": "jurisdiction and regulatory scope", "status": "gap", "notes": "Only NIS2 and GDPR are grounded in primary text. Sector regimes such as DORA, HIPAA, securities disclosure rules and national CSIRT rules are not enumerated, and CIRCIA is modelled only as a pending binding." }, { "dimension": "non-cyber incident applicability", "status": "gap", "notes": "The structure is drawn from cybersecurity incident management sources. Command-and-control structures for safety, physical or emergency incidents were not grounded in a primary source in this session and are marked as unverified extension surface." }, { "dimension": "security", "status": "covered", "notes": "Out-of-band communication, reporter authentication, handling labels, redaction and break-glass review are modelled; enforcement remains with the platform." } ], "known_omissions": [ "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." ], "conflicts": [ "IODEF version 2 restriction values include legacy colour terms white, green, amber and red that correspond to an earlier Traffic Light Protocol; TLP 2.0 uses CLEAR and adds AMBER+STRICT, which has no IODEF enumeration value. Any mapping is lossy and must be recorded, so no conformance is claimed in either direction.", "IODEF workflow status values such as new, in-progress, forwarded and resolved describe record workflow, not process phase. They must not be conflated with the phase model of ISO/IEC 27035-1 or with CSF Function coverage.", "NIST SP 800-61r3 is published as a CSF 2.0 Community Profile and supersedes the Revision 2 lifecycle presentation, while ISO/IEC 27035-1 retains a named phase process. The model therefore avoids hard-coding either phase enumeration and treats both as alignments.", "Notification clocks differ by regime: NIS2 uses awareness of a significant incident with a 24-hour early warning and 72-hour notification, GDPR uses awareness of a personal data breach with a 72-hour deadline, and the US CIRCIA statute contemplates 72 hours for covered incidents and 24 hours for ransom payments. Clock starts and scopes are not interchangeable, so a single global deadline field is rejected.", "STIX 2.1 defines Incident as a minimal domain object without the properties needed for case handling, so it can carry a reference but cannot serve as the case record schema.", "External taxonomy classes describe incident type, not response urgency; mapping a taxonomy class directly to a response tier would conflate classification with prioritisation." ], "regional_assumptions": [ "EU obligations are modelled from the NIS2 Directive and GDPR as adopted at Union level. National transposition varies in thresholds, reporting portals and additional sector duties, so the adopting Dimension must bind the applicable national instrument.", "As of the research date the US CIRCIA implementing rule had not been finalised, with finalisation reported as expected later in 2026. Its reporting duties are modelled as a pending, jurisdiction-specific binding rather than an operative obligation.", "US state breach notification laws and securities disclosure obligations are outside the modelled set and must be bound separately.", "Handling labels assume TLP 2.0 as published by FIRST; communities operating older TLP versions or national variants require an explicit mapping.", "The model assumes a single accountable responding capability per case. Jurisdictions or sectors mandating joint or governmental command may require an extension recorded through the parent model." ], "adversarial_checks": [ "Tested whether incident severity, category or affected-asset facts had leaked into this model. Triage was reduced to a response-side tier decision citing the incident record, and severity, classification and impact facts were pushed to WM-ACT-020 in line with the incident-process separation rationale.", "Tested whether continuity plan lifecycle had leaked in through recovery. Plan content, approval, testing, activation state and completion were removed to WM-ACT-043, leaving only an inline invocation binding of reference, trigger, parameters and acknowledgement, and that finding was deliberately given no artifact.", "Tested whether the model claims execution or enforcement of response actions. Action findings record authorisation, intended effect and a reference to the executing system's evidence; CACAO agents, targets and workflow execution were kept outside, and no function performs or enforces an action.", "Tested whether audit-trail semantics were claimed. Audit obligations are written as requirements placed on the adopting Dimension's platform, with an explicit statement that log semantics, integrity and retention are owned by the platform and audit policy rather than by this model.", "Tested whether a single notification deadline field could be modelled across regimes and rejected it after comparing NIS2, GDPR and the pending CIRCIA duties; deadlines are computed per regime binding from a separately determined awareness time.", "Tested the handling-label mapping against IODEF restriction values and found no equivalent for AMBER+STRICT, so the divergence is recorded as a conflict and export must report unmapped values instead of coercing them.", "Searched for counterexamples to the assumption that a response is always playbook-governed. Novel and ad hoc incidents exist, so playbook binding is optional and carries an explicit ad hoc flag and a deviation record.", "Checked every function against the relation rationales. No function creates, mutates or closes an incident record, a continuity plan, an evidence examination result or an audit log; each either writes case-local state or emits a referenced request." ] }, "researchAdjudication": { "providerMode": "single-provider-waiver", "activeProviders": [ "claude" ], "waivedProviders": [ "grok" ], "providerPolicy": { "contract_version": "1.0.0", "mode": "single-provider-waiver", "effective_at": "2026-08-29T09:06:27Z", "scope": "Queued subject-model research from WM-XCT-013 onward", "active_providers": [ "claude" ], "waived_providers": [ { "provider": "grok", "authorized_by": "repository owner", "authorized_at": "2026-08-29T09:06:27Z", "reason": "The repository owner explicitly instructed the research queue to continue without Grok after repeated structured-output failures." } ], "review_rule": "Claude-only results require a separate no-tools adversarial audit and remain reviewable drafts with a visible single-provider hold." }, "boundaryDecision": { "entry_kind": "aggregate", "status": "reclassified", "rationale": "The structural evidence supports an aggregate whose root is the response case, not the incident: the case carries its own issued identifier and cooperating-party cross-references (f-case-identity), its own state vocabulary with closure gates and reopen conditions (f-case-status-and-closure), its own owned artifacts, and 17 functions that only write case-local state or emit referenced requests. The frozen registry record carries entry_kind 'standalone-mm', which is a record-plane value and does not declare an aggregate root, so the research record is reclassified to 'aggregate' and the registry field must be reconciled before promotion beyond candidate. This reclassification is not clean: the frozen contract types WM-ACT-020 -> WM-ACT-042 as COMPOSE while its own instance_semantics reads 'is handled by' and the registry sets composition_role REFERENCE. A strict COMPOSE would make the case a part whose lifecycle is subordinate to the incident, which contradicts open-response-case operating on a merely 'suspected' incident, q-case-merge allowing independent merge/split/supersession, and the case holding its own retention class and preservation holds. The aggregate reading is therefore accepted on the evidence and the edge typing is routed to the boundary review the registry already requires (review_state boundary-review-required)." }, "decisions": [ { "concept": "Aggregate root is the response case, not the incident", "disposition": "accepted", "rationale": "Triage is reduced to a response-side tier decision citing the incident record; severity, classification, affected assets and authoritative impact are pushed to WM-ACT-020, and f-response-impact-assessment is deliberately artifact-free so it cannot become a competing record of fact. The root holds identity, state, gates and closure, which is what an aggregate root must own." }, { "concept": "Entry kind 'aggregate' versus frozen registry value 'standalone-mm'", "disposition": "reclassified for the research record; registry field flagged for reconciliation", "rationale": "The two values come from different vocabularies and are not directly contradictory, but the registry carries no aggregate-root declaration while the whole model depends on one. The synthesizer must publish 'aggregate' with a visible note that the registry entry_kind is unreconciled and review_state remains boundary-review-required." }, { "concept": "COMPOSE edge from WM-ACT-020 versus 'is handled by' semantics and registry composition_role REFERENCE", "disposition": "deferred to boundary review; no edge retyped in this pass", "rationale": "The frozen inputs disagree with each other: relation_type COMPOSE implies part-of containment and cascaded lifecycle, while the instance_semantics phrase and the registry composition_role both read as reference. Case-side retention, independent closure and pre-declaration case opening all hinge on which reading governs, and an auditor without tools must not silently retype a frozen contract edge." }, { "concept": "CHILD relation to WM-ACT-019 present in registry parent_ids and boundary_notes but absent from the frozen relationship contract", "disposition": "deferred — must be registered as an explicit contract row", "rationale": "The model relies on inherited activity, case and work-record scaffolding from WM-ACT-019 to justify not restating it, so the inheritance edge is load-bearing for the scope statement. It currently exists only as a registry field and a prose boundary note, which is weaker than the two relations that are contractually frozen." }, { "concept": "Artifact a-service-description declared as an owned artifact of f-capability-charter", "disposition": "rejected as owned artifact; reclassify to an inline binding tuple", "rationale": "A published capability service description is mastered by the responding capability and shared across every case, so declaring it as a case artifact asserts ownership the scope statement disclaims. The model already handles the identical situation correctly twice — f-playbook-and-procedure-binding and f-capability-readiness-evidence hold reference, version, validity and digest inline with no artifact — so this is an internal inconsistency, not a judgement call." }, { "concept": "Coverage checklist claims for access control and disposition tombstones", "disposition": "rejected as stated; claim must be narrowed to what the structure carries", "rationale": "The access row asserts deny-by-default with case-role grants, five named exception paths and platform audit obligations, and the retention row asserts a tombstone on disposition, but no finding, question or artifact in the 26 findings carries any of it — access appears only as two question kinds inside communication findings and the retention finding has no tombstone question. Marking these dimensions 'covered' overstates the evidence." }, { "concept": "Single awareness timestamp in bind-reporting-obligation and q-time-awareness", "disposition": "rejected; require a per-regime clock start on each obligation binding", "rationale": "The model's own conflicts list records that NIS2 awareness of a significant incident, GDPR awareness of a personal data breach and the pending CIRCIA triggers are not interchangeable, and explicitly rejects a single global deadline field. The function description derives stage deadlines from 'the recorded awareness time' and q-time-awareness asks which single timestamp constitutes awareness, reintroducing the exact conflation the model rejected." }, { "concept": "Artifact-to-function closure: six declared artifacts have no producing function", "disposition": "deferred — add_functions is barred under the single-provider waiver", "rationale": "a-analysis-note, a-deviation-record, a-restoration-verification, a-case-chronology, a-situation-report and a-affected-party-notice are declared as artifacts but no function emits them; record-notification-submission covers only submissions to a recipient authority, so affected-party communication has a finding and an artifact but no operation. This is a real completeness gap that must be closed in the next pass rather than papered over." }, { "concept": "SRC-011 RSIT cited via a mutable raw working-copy URL on a moving branch", "disposition": "accepted conditionally; a pinned commit or release reference is required before publication", "rationale": "The citation points at a master-branch working copy whose content can change without notice while the pack asserts taxonomy version 1003. Since q-class-vocab and q-class-drift depend on a stable catalogue version, an unpinned URL cannot support the version-binding discipline the model claims elsewhere." }, { "concept": "SRC-017 tier-3 news article cited alongside NIS2 and GDPR in f-regulatory-notification-binding and bind-reporting-obligation", "disposition": "accepted as a status and currency citation only; no obligation content may derive from it", "rationale": "It is correctly flagged primary_source false at authority tier 3 and the regional assumptions model CIRCIA as a pending binding rather than an operative duty, which is the right handling. The tier difference must remain visible at the finding level so no reader treats a trade-press piece as regulatory grounding." }, { "concept": "SRC-001 and SRC-014 cited while their normative bodies were not machine-verified", "disposition": "accepted at catalogue and scope level only; no clause, phase or subcategory assertion permitted", "rationale": "The known omissions state that the SP 800-61r3 body could not be extracted and that ISO/IEC 27035-1 is paywalled and unverified. The model mitigates this by refusing to hard-code either phase enumeration, but both sources still ground definitional findings, so the limitation must travel with every citation rather than sitting only in the omissions block." }, { "concept": "Grounding of the case status and closure state machine", "disposition": "deferred — support is thin and must be strengthened", "rationale": "f-case-status-and-closure rests on exactly two citations: IODEF, whose workflow values the model's own conflicts list says must not be conflated with process phases, and the unverified ISO standard. A state machine with closure preconditions and reopen rules deserves stronger grounding than one lossy exchange vocabulary plus one unread standard." }, { "concept": "Artifact serial-flag semantics and register-versus-entry naming", "disposition": "deferred normalization; the serial predicate must be defined before publication", "rationale": "The flag is applied inconsistently under any plain reading — a-response-case-record is serial true while a-inbound-report and a-analysis-note are serial false — and a-improvement-action-register names the container while a-evidence-register-entry names the entry, so the transmissible unit differs between two otherwise parallel registers. The function id apply-preservation-hold likewise omits the release operation its own name and description include." }, { "concept": "Case-to-incident cardinality and merge, split and supersession identity rules", "disposition": "deferred", "rationale": "q-case-incident-link leaves one-to-one open while q-case-merge contemplates merge, split and supersession without losing identifiers, and the contract's instance_semantics does not settle cardinality. Identity rules that permit a case to be split cannot be evaluated until the compose-versus-reference question above is decided." }, { "concept": "Model name 'Incident Response' against a scope that is strictly the response case", "disposition": "accepted; alternate name proposed rather than renaming the frozen registry entry", "rationale": "The name invites precisely the incident-versus-response conflation that eight boundary notes and four adversarial checks exist to prevent, and registry alternate_names is empty. Proposing 'Incident Response Case' as an alternate name preserves the frozen identifier while making the aggregate root legible at the top of the record." } ], "publicationHolds": [ "Live source verification hold: every one of the 17 sources must be re-resolved and version-pinned at publication time — specifically the SRC-011 RSIT raw working-copy URL on a moving branch (asserted taxonomy version 1003), the SRC-015 ATT&CK pin 'v19.2, current from 28 April 2026' on a versions index page, the SRC-004 TLP 2.0 living page, the SRC-016 SIM3 v2 interim release, and the SRC-014 ISO catalogue edition. No URL or version string in this pack was verified during the audit, which had no tools.", "Single-provider hold: Grok was waived by the repository owner at 2026-08-29T09:06:27Z after repeated structured-output failures, so no independent second-provider review of WM-ACT-042 exists. This audit is a same-provider adversarial pass, not independent corroboration. Every publication artifact must carry the waiver, its authorization, and the statement that the model remains a reviewable draft; provider counts show 0 cross-provider matches on sources, bundles, layers, findings and questions by construction, not by disagreement.", "Boundary hold: the entry_kind mismatch (registry 'standalone-mm' versus research 'aggregate') and the COMPOSE-versus-REFERENCE contradiction between the frozen contract, its own instance_semantics and registry composition_role must be resolved before the record moves past status 'candidate'. Publication as a draft is permitted; promotion is not.", "Coverage hold: the access-control and disposition-tombstone rows of the checklist must be downgraded from 'covered' or backed by an actual finding before the checklist is published, since neither is carried by any finding, question or artifact in the current structure.", "Source-strength hold: no clause-level, phase-level or CSF-subcategory assertion may be published from SRC-001 or SRC-014 while their normative bodies remain unextracted or paywalled, and SRC-017 must be visibly marked tier-3 non-primary wherever it appears beside NIS2 and GDPR.", "Independent second-provider review was explicitly waived by the repository owner; this Claude-only result remains a reviewable draft." ], "deferredResearch": [ "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." ] }, "statistics": { "sources": 17, "bundles": 7, "layers": 15, "findings": 26, "questions": 108, "artifacts": 18, "functions": 17 } }