What this is
What is a cyber incident record?
What is a cyber incident record?
A record of a cyber event affecting systems, data or plant operation, covering detection, containment, impact, recovery and notification. It is the evidence that the organisation responded to a security incident in a controlled way rather than reconstructing events afterwards from memory and system logs.
Who owns the record while the incident is live?
IT owns containment and recovery; the site lead owns production and safety decisions. Neither completes the record alone, because it asks about both the technical state of the systems and whether product on the line is safe, questions that sit with different people.
Does a phishing email that was reported and deleted count as an incident?
If it was clicked, or credentials entered, yes; work through containment and impact rather than closing it as a non-event. If reported and deleted without interaction, most organisations log it below the incident threshold, but the decision should be recorded, not assumed.
Scope
When is a cyber incident record required?
This record is one step in a larger programme. Using it for work that belongs to a neighbouring template produces records that are hard to report on later.
Use this template when
- A cyber event is detected: ransomware, phishing, unauthorised access, denial of service, malware or data loss
- Systems, data or plant operation are affected, or credibly suspected to be
- You are running the Data Protection and Information Security programme and this is one of its steps
- A linked record needs this one to exist: business continuity, breach record
- A supplier, customer or regulator raises a report that points back at your systems
Do not use it for
- Information Security Risk Assessment, which assesses threats to systems, data and operational technology, including plant control systems.
- System Access Review, which reviews who has access to which systems and at what privilege level.
- Backup and Recovery Test Record, which records a test that backups can actually be restored, not merely that they ran.
- A near miss with no interaction (an email reported and deleted unopened), which most organisations log separately below the incident threshold
- Anything outside KnowComply, which belongs in the workspace that owns that process
Compliance mapping
Which ISO 27001 cl.16 requirements does this satisfy?
Incident management is a named Annex A domain, and where the event touches personal data or plant safety, three other regimes attach specific deadlines the record has to be able to demonstrate were met.
| Clause | Requirement | Where it lands |
|---|---|---|
| ISO 27001:2013 Annex A.16.1.1 | Defined responsibilities and procedures for a swift, effective and orderly response | Header |
| ISO 27001:2013 Annex A.16.1.5 | Response to information security incidents follows the documented procedure | Containment |
| ISO 27001:2013 Annex A.16.1.7 | Collection of evidence, identification, collection and preservation for potential use | Containment |
| ISO 27001:2022 Annex A.5.25 / A.5.26 | Assessment and decision on security events, and response to confirmed incidents | Impact |
| GDPR Article 33 | Notification of a personal data breach to the supervisory authority within 72 hours where required | Recovery and reporting |
| GDPR Article 34 | Communication of a personal data breach to affected individuals where high risk to rights and freedoms | Recovery and reporting |
| ISO 27001:2013 Annex A.16.1.6 | Learning from information security incidents to reduce likelihood or impact of future ones | Outcome |
What it does not cover
- Information Security Risk Assessment, which assesses threats to systems, data and operational technology before an event happens.
- System Access Review, which reviews who has access to which systems and at what privilege level, independent of any incident.
- Backup and Recovery Test Record, which proves backups restore in advance, rather than recording their use during a live incident.
- The business continuity plan, which sets out how production keeps running or resumes; this record triggers it and reports back into it.
- Data Breach Record, which is the dedicated personal-data-breach record this incident may need to link to when confidentiality is affected.
Global
Cyber Incident Record requirements by country
ISO 27001 sets the incident management process. Two obligations attach a clock to it: US breach notification statutes with short, state-specific windows, and the UK's 72-hour reporting duty for personal data.
ISO/IEC 27001 Annex A.16 (2013) / A.5.24–A.5.28 (2022)
The certifiable process for incident management, evidence collection and post-incident learning
Certification bodies and customer audits expect to see the full cycle: detection, response, evidence preservation and a documented lesson, not just that the incident was eventually closed.
State breach notification statutes (all 50 states) and, for regulated sectors, HIPAA or GLBA-specific timelines
Notification duties triggered by the state of residence of affected individuals, not the company's own location
A single incident touching customers across several states can trigger several notification clocks at once, each with its own deadline and its own definition of personal information.
UK GDPR Article 33 (72-hour regulator notification) and Article 34 (notification to individuals at high risk)
A hard 72-hour clock that starts at awareness, not at confirmation
The clock starts when the organisation becomes aware a breach has probably occurred, not once the investigation confirms scope, which means the notification decision has to be made on incomplete information.
How to complete it
How to complete a cyber incident record, step by step
The form records what happened. Whether it holds up afterwards turns on four judgement calls the fields alone don't settle.
"Production Affected" and "Product At Risk" sit next to the data fields for a reason. On an operational site, deciding whether product made during the incident window is safe to release is frequently the harder and more consequential call, and it needs its own sign-off, not a note buried under the containment fields.
"Personal Data Breach Assessed" has to be answered deliberately. A cyber incident with no personal data exposure is common, but the record needs to show that someone actually checked, because the 72-hour notification clock runs from awareness, not from a completed assessment.
The pressure to restore operations works directly against "Evidence Preserved." Imaging an affected system before wiping and restoring it takes time an operational site under pressure to resume production doesn't want to give, and that trade-off needs to be a deliberate decision, not a default.
"Continuity Plan Updated" is where the record either changes something or doesn't. If manual operation fallback was used and it worked, or didn't, that's the input the continuity plan needs; recording the fact without feeding it back produces the same gap next time.
What auditors find
Most common cyber incident record findings
The findings below are what a review of incident records of this kind actually turns up.
| Finding | Clause | What fixes it |
|---|---|---|
| The personal data breach question was left blank because confidentiality wasn't obviously affected. | GDPR Article 33 | Record a deliberate assessment either way; the 72-hour clock runs from awareness, not from a completed answer. |
| Evidence was not preserved before the affected system was wiped and restored. | ISO 27001:2013 Annex A.16.1.7 | Image or isolate before restoring wherever the timeline allows; note the trade-off when it genuinely can't. |
| Production and safety impact recorded as an afterthought under a general containment note. | ISO 27001:2022 Annex A.5.26 | Give product-at-risk its own sign-off from the site lead, separate from the IT containment narrative. |
| Regulator notification decided without reference to the 72-hour window. | GDPR Article 33 | Log the awareness timestamp explicitly and measure the notification decision against it. |
| The continuity plan was not updated after manual operation fallback was used. | ISO 27001:2013 Annex A.16.1.6 | Feed what worked, and what didn't, back into the continuity plan as part of closing the record. |
| Root cause analysis was never linked, so the same phishing pattern recurred within the year. | ISO 27001:2013 Annex A.16.1.6 | Link the RCA ID and track its actions to closure, not just the incident's own status field. |
Case in point
Case in point: the plan that only covered data
A manufacturer's incident response plan, tested annually, walked through a ransomware scenario ending in a data confidentiality assessment and a customer notification decision. When an actual attack hit, it encrypted the engineering historian and, through a shared network segment nobody had mapped, the HMI terminals on two production lines. IT followed the plan well: systems isolated, credentials reset, external support engaged within the hour.
Nobody could answer the site lead's first question, though: was the half-built batch on the stopped line safe to release once systems came back. The plan had never addressed product risk. The batch sat in limbo for two days while quality worked it out from scratch, isolated from the incident record entirely. The record that closed showed a clean containment story and a correct no-exposure data assessment, and said nothing about the two days a production decision took because nobody had planned for it.
The template
The template, field by field
The form exactly as it installs. Every field, option, score and conditional rule is editable, and the links to other templates come with it.
5 sections
- Reference
- CMP-037
- Archetype
- Record
- Record ID
- CYB-2026-000
- Scoring
- Incidents contained
- Direction
- High is good
- Singleton
- Yes
- Basis
- ISO 27001 cl.16
- Links
- Links Business continuity, Breach record
- Tags
- Security, Cyber
- Sections
- 5
- Fields
- 45
- Follow up fields
- 3
- Repeating sections
- 0
- Links out
- 4
Header
13 fieldsRecord ID*
Auto sequence. Format CYB-2026-000.
The record's own ID. Other templates point at this value.
Status*
Drives who this goes to next.
- Planned2 pts
- In progress2 pts
- Complete3 pts
- Deferred0 pts
- Open0 pts
- Closed3 pts
- Overdue0 pts
Date and Time*
Completed By*
Site*
Site ID*
Format SITE-000.
Links to FDN-001 Site ID
Detected*
Incident Type*
Detected By*
- Monitoring4 pts
- User report2 pts
- Third party1 pt
- Customer0 pts
Systems Affected*
Production Affected*
- No3 pts
- Partly1 pt
- Stopped0 pts
Product At Risk*
- No3 pts
- Possibly1 pt
- Yes0 pts
An Attack That Stops The Control System Stops The Site
Most cyber response plans assume data loss. On a manufacturing site the more likely outcome is that nothing runs and the product on the line is at risk.
Containment
6 fieldsAffected Systems Isolated*
- Yes2 pts
- No0 pts
- N/Aexcluded from denominator
Spread Prevented*
- Yes3 pts
- Partly1 pt
- No0 pts
Credentials Reset Where Needed*
- Yes3 pts
- Partly1 pt
- No0 pts
External Support Engaged*
- Yes3 pts
- Partly1 pt
- No0 pts
Evidence Preserved*
- Yes2 pts
- Partly1 pt
- No0 pts
Manual Operation Fallback Used*
- Yes3 pts
- Partly1 pt
- No0 pts
Impact
6 fieldsData Confidentiality Affected*
- Yes3 pts
- Partly1 pt
- No0 pts
Data Integrity Affected*
- Yes3 pts
- Partly1 pt
- No0 pts
System Availability Affected*
- Yes3 pts
- Partly1 pt
- No0 pts
Control Systems Affected*
- Yes3 pts
- Partly1 pt
- No0 pts
Product Safety Records Affected*
- Yes3 pts
- Partly1 pt
- No0 pts
Traceability Affected*
- Yes3 pts
- Partly1 pt
- No0 pts
Recovery and reporting
6 fieldsBackups Used Successfully*
- Yes3 pts
- Partly1 pt
- No0 pts
Systems Restored And Verified*
- Yes2 pts
- No0 pts
- N/Aexcluded from denominator
Regulator Or Authority Notified Where Required*
- Yes2 pts
- No0 pts
- N/Aexcluded from denominator
Personal Data Breach Assessed*
- Yes3 pts
- Partly1 pt
- No0 pts
Customers Informed Where Needed*
- Yes3 pts
- Partly1 pt
- No0 pts
Insurer Notified*
Outcome
14 fieldsHours Of Disruption*
Recovery Objective Met*
- Yes3 pts
- Marginal1 pt
- No0 pts
Product Released Safely*
- Yes3 pts
- Held1 pt
- No0 pts
Breach Record ID
Links to CMP-033 Record ID
RCA ID
Links to FDN-013 RCA ID
Continuity Plan Updated*
- Yes3 pts
- Not needed3 pts
- No0 pts
Action Required*
Raise the action record, then enter its reference here.
- No2 pts
- Yes0 pts
Priority
- High0 pts
- Medium1 pt
- Low3 pts
CAPA ID
Format CAPA-2026-00000.
Links to FDN-014 CAPA ID
Action Owner
IT*
Signature*
Site Manager*
Second Signature*
CMP-037 · record IDs look like CYB-2026-000 · Links Business continuity, Breach record
Open in KnowellaRun it with agents
From a document you fill in to a programme that runs itself
The form is the easy part. Deciding the personal data question under time pressure, weighing evidence preservation against getting the line running, and feeding the lesson back into continuity is the work that actually slips.
Holds the incident record against the register, tracks the notification clock from the awareness timestamp, and keeps evidence and RCA links together.
Brings the control system and connected machinery context IT-drawn plans usually omit, so production impact is assessed alongside data impact from the start.
Carries the manual operation fallback decision and product-at-risk call through to the site lead, so it doesn't sit buried under a containment note.
Flags the personal data breach question when left blank, tracks the 72-hour window against the awareness timestamp, and holds every write for your approval.
This template lives in KnowComply — audit and governance. Audit programmes, legal register, management review, risk and certification.
Meet KnowComply→Glossary
Cyber Incident Record definitions and key terms
- Containment
- The stage of incident response that stops an attack spreading further, distinct from recovery, which restores normal operation afterwards.
- Operational technology (OT)
- Control systems, HMIs and connected machinery, as distinct from business IT; an incident can affect one, the other, or both.
- Evidence preservation
- Imaging or isolating an affected system before remediation, so a forensic or legal review remains possible afterwards.
- Awareness (breach notification)
- The point the 72-hour GDPR notification clock starts: when a breach is probably known to have occurred, not once fully investigated.
- Manual operation fallback
- Running a process by hand when the control system it normally depends on is unavailable, used as a stopgap during containment.
FAQ
Frequently asked questions about cyber incident record
What is the cyber incident record template based on?+
It is built against ISO 27001 Annex A.16, information security incident management, covering responsibilities, response, evidence collection and learning from incidents. The 2022 revision moved the same requirements into A.5.24 through A.5.28.
What sections does the cyber incident record contain?+
Five: header, containment, impact, recovery and reporting, outcome. Together they hold 45 fields, 39 required, spanning detection through to continuity plan updates.
How many cyber incident records should we have?+
This is a singleton register: one live record maintained per event as it unfolds, from detection through recovery and reporting, rather than a separate document built up after the fact.
Which programme does the cyber incident record belong to?+
It is part of Data Protection and Information Security, alongside the processing register, impact assessments, breach response, access review and backup testing.
How is a cyber incident record scored?+
Scoring is incidents contained, where high is good; production and product-at-risk fields correctly score No as the best answer, since containment is the point of the record.
Can the cyber incident record template be changed?+
Yes. Every field, option, score and conditional rule is editable, and links to other templates come with it. Most teams install it as it is, run it through one real incident, then adjust.
Keep going
Related templates and programmes
Industries this is written for
Programmes this belongs to
Used together in Data Protection and Information Security
Personal Data Processing Record
Records what personal data the organisation holds, why, on what basis and for how long
Data Protection Impact Assessment
Assesses the privacy impact of a new system or monitoring activity before it is introduced
Data Breach Record
Records loss, exposure or unauthorised access to personal data, with the assessment of harm and notification decision
Subject Access Request Record
Records a request from an individual for the data held about them, and how it was answered within the deadline
Information Security Risk Assessment
Assesses threats to systems, data and operational technology, including plant control systems
System Access Review
Reviews who has access to which systems and at what privilege level
More in Information Security
Information Security Risk Assessment
Assesses threats to systems, data and operational technology, including plant control systems
System Access Review
Reviews who has access to which systems and at what privilege level
Backup and Recovery Test Record
Records a test that backups can actually be restored, not merely that they ran
Written and reviewed by
Siddarth Singh
Founder & Chief Executive Officer, Knowella
Certified Safety Professional and industrial and systems engineer with more than a decade inside food supply chain, freight and manufacturing operations. This page was written against the current text of the standards it cites, not against secondary summaries of them.
- Certified Safety Professional (CSP), Board of Certified Safety Professionals
- MBA, University of Chicago Booth School of Business
- MS and BS, The Ohio State University, Industrial and Systems Engineering
- Six Sigma Black Belt
Sources and last review. Reviewed 16 August 2026 against:
- ISO/IEC 27001:2013 Annex A.16 — Information security incident management
- ISO/IEC 27001:2022 Annex A.5.24–A.5.28 — Incident management, planning and response
- UK GDPR Articles 33 and 34 — Notification of a personal data breach
- US state breach notification statutes (all 50 states)
This page is general guidance, not legal advice. Confirm requirements with your jurisdiction’s regulator.