Product
Framework alignment
Which NEMUQU case records relate to which incident response references in NIST SP 800-61 Rev. 3, CIS Controls v8 Control 17, ISO/IEC 27001:2022 Annex A 5.24 to 5.28 and NIS2 Article 23. Each case can export this as an appendix showing which of those records it holds.
On this page
Alignment reference prepared by the team using NEMUQU. It is not an assessment, certification or legal advice, and it does not show that any framework's requirements are met.
What the appendix is
From a case, you can download a framework alignment appendix in Markdown or HTML. For each reference below it lists the records in that case that relate to it, with their refs, times and who recorded them, or says they are not recorded. For example: "Incident declared: recorded 2026-10-12 14:02 UTC by" the person who recorded it, or "Incident declared: not recorded".
- A recorded item is something your team or the analysis wrote down. It does not show that a reference is satisfied, and a missing one does not show that it is not.
- The reference descriptions are our own short paraphrase. Read the source documents for their text.
- Client contacts appear only as a count. The custody record's length is shown only to owners and members with edit access to the client.
- A member with read access to the case can download it, as with the report. Each download is recorded in the audit log.
- No language model is involved, and generating the appendix changes nothing in the case.
Records the mapping uses
| Record | What it is |
|---|---|
| Evidence received and hashed | Each uploaded file is stored as an artifact with its SHA-256 digest, size and the time it was received. |
| Evidence records | Immutable pointers into the parsed evidence that findings cite, each with a content hash. |
| Findings with cited evidence | Conclusions from the analysis of the supplied evidence. A finding cannot be written without evidence references. |
| Unknowns | What the evidence cannot establish, recorded on findings and on the case overview. |
| Case owner | The member running the investigation, as assigned on the case. |
| Incident priority | P1, P2 or P3, set by a person. Separate from finding severity. |
| Incident declared | When the team recorded declaring an incident, and who recorded it. |
| Became-aware time | When the team asserts it became aware of the incident. |
| Notification clocks | Deadlines the team chose to track, counted in elapsed hours from the declared or became-aware time. |
| Response actions taken | An append-only log of containment, eradication and recovery steps people recorded taking outside NEMUQU. |
| Tasks | Work items on the case with an assignee, a due date and a status. |
| Client contact tree | The client's incident contacts in escalation order. Kept in the product; never included in an export. |
| Post-incident review draft | A draft built from the case record for the team to edit, with placeholders where a person must write. |
| Custody record | The case's hash-chained audit entries, exportable with a verification result. |
| Legal hold | An owner's hold that stops NEMUQU deleting the case, with an append-only history of placements and releases. |
| Case closure | An immutable snapshot recorded when a person closes the case, with the package digest. |
NIST SP 800-61 Rev. 3
Revision 3, published 2025-04. References are NIST Cybersecurity Framework 2.0 subcategory identifiers, as used by the SP 800-61 Rev. 3 community profile. Source: https://csrc.nist.gov/pubs/sp/800/61/r3/final
| Reference | What it covers (paraphrased) | Related NEMUQU records |
|---|---|---|
| DE.AE-08 | Declaring an incident when analyzed activity meets the organization's incident criteria. | Incident declared |
| RS.MA-02 | Triaging and validating incident reports. | Evidence received and hashed, Findings with cited evidence |
| RS.MA-03 | Categorizing and prioritizing incidents. | Incident priority |
| RS.MA-04 | Escalating or elevating incidents when needed. | Case owner, Tasks, Client contact tree |
| RS.AN-03 | Analysis to establish what happened during the incident and its root cause. | Findings with cited evidence, Unknowns |
| RS.AN-06 | Recording the actions performed during an investigation and preserving the integrity and provenance of those records. | Response actions taken, Custody record |
| RS.AN-07 | Collecting incident data and metadata and preserving their integrity and provenance. | Evidence received and hashed, Evidence records, Legal hold |
| RS.AN-08 | Estimating and validating the magnitude of an incident. | Findings with cited evidence, Unknowns |
| RS.CO-02 | Notifying internal and external stakeholders of incidents. | Notification clocks, Client contact tree |
| RS.MI-01 | Containing incidents. | Response actions taken |
| RS.MI-02 | Eradicating incidents. | Response actions taken |
| RC.RP-01 | Carrying out the recovery part of the incident response plan. | Response actions taken |
| RC.RP-06 | Declaring the end of recovery against criteria and completing the incident documentation. | Case closure, Post-incident review draft |
| ID.IM-03 | Identifying improvements from carrying out operational processes, including incident response. | Post-incident review draft |
CIS Critical Security Controls v8, Control 17 (Incident Response Management)
Version 8, published 2021-05-18. References are CIS Safeguard numbers within Control 17. Source: https://www.cisecurity.org/controls/v8
| Reference | What it covers (paraphrased) | Related NEMUQU records |
|---|---|---|
| 17.1 | A named person, with a backup, manages incident handling. | Case owner, Tasks |
| 17.2 | Contact information for reporting security incidents is kept current. | Client contact tree |
| 17.3 | An enterprise process for the workforce to report incidents. | An organizational process outside NEMUQU. No case record corresponds to it. |
| 17.4 | An incident response process is established and maintained. | Incident declared, Response actions taken, Tasks |
| 17.5 | Key incident response roles and responsibilities are assigned. | Case owner, Tasks |
| 17.6 | Primary and secondary ways to communicate during incident response are defined. | Client contact tree |
| 17.7 | Incident response exercises are run on a routine basis. | Exercises happen outside a real case. No case record corresponds to them. |
| 17.8 | Post-incident reviews are held to capture lessons learned and follow-up. | Post-incident review draft, Tasks |
| 17.9 | Thresholds that separate a security incident from an event are set and maintained. | Incident priority, Incident declared |
ISO/IEC 27001:2022, Annex A controls 5.24 to 5.28
ISO/IEC 27001:2022, published 2022-10-25. References are Annex A control numbers. Source: https://webstore.iec.ch/publication/79694
| Reference | What it covers (paraphrased) | Related NEMUQU records |
|---|---|---|
| A.5.24 | Planning and preparing for information security incident management, including roles and contacts. | Case owner, Client contact tree |
| A.5.25 | Assessing information security events and deciding whether they are incidents. | Incident declared, Incident priority, Findings with cited evidence |
| A.5.26 | Responding to information security incidents according to documented procedures. | Response actions taken, Tasks, Notification clocks, Case closure |
| A.5.27 | Using knowledge gained from incidents to strengthen controls. | Post-incident review draft |
| A.5.28 | Identifying, collecting, acquiring and preserving evidence related to information security events. | Evidence received and hashed, Evidence records, Custody record, Legal hold |
NIS2 Directive (EU) 2022/2555, Article 23 (reporting obligations)
Directive (EU) 2022/2555, published 2022-12-14. References are Article 23 paragraph and point. Source: https://eur-lex.europa.eu/eli/dir/2022/2555/oj
NEMUQU does not determine whether NIS2 applies to an entity, whether an incident is significant, or which deadline applies. Each entity in scope reports for itself. The times and clocks below are your team's own records.
| Reference | What it covers (paraphrased) | Related NEMUQU records |
|---|---|---|
| Art. 23(1) | Entities in scope notify their CSIRT or competent authority of significant incidents without undue delay. | Incident declared, Notification clocks. Times and clocks are your team's own records. |
| Art. 23(4)(a) | An early warning within 24 hours of becoming aware of a significant incident. | Became-aware time, Notification clocks. Times and clocks are your team's own records. |
| Art. 23(4)(b) | An incident notification within 72 hours of becoming aware, with an initial assessment and indicators of compromise where available. | Became-aware time, Notification clocks, Findings with cited evidence. Times and clocks are your team's own records. |
| Art. 23(4)(c) | An intermediate report with status updates when the CSIRT or competent authority asks for one. | Made on request. No case record corresponds to the request. |
| Art. 23(4)(d) | A final report no later than one month after the incident notification, describing the incident, its likely cause, the mitigation applied and any cross-border impact. | Findings with cited evidence, Response actions taken, Post-incident review draft. Times and clocks are your team's own records. |
| Art. 23(4)(e) | A progress report when the incident is still ongoing at the time the final report is due. | Tasks, Response actions taken. Times and clocks are your team's own records. |
NIS2 timing
NEMUQU does not determine whether NIS2 applies to an entity, whether an incident is significant, or which deadline applies. Each entity in scope reports for itself. The times and clocks below are your team's own records.
The 24-hour and 72-hour clocks on a case are presets your team chooses to add. They count elapsed hours from the became-aware or declared time your team records, and NEMUQU sends no notifications. See How it works for the rest of the case record.
Versions
Mapping version 2026-10-16. References were checked against public sources on 16 October 2026. A framework revision changes this mapping only when we update it here and in the export together.
Alignment reference prepared by the team using NEMUQU. It is not an assessment, certification or legal advice, and it does not show that any framework's requirements are met.