Near-miss log template for cyber security
A near-miss log records events that could have harmed you but didn't, with your reasoning. The Cyber Security and Resilience Bill (CSRB) does not expressly require one, but it helps you justify reporting decisions and find weak controls. Copy the unofficial template below and adapt it.
The Bill is not yet law. Regulation and section references come from the Bill as brought from the Commons (HL Bill 32). The Lords has since amended the Bill, so numbering and detail may change in the final Act. This guide is general information, not legal advice.
Report Stage update: VinciWorks reports that Government amendments on 26 October 2026 narrowed the incident definition to incidents that have actually adversely affected systems, and removed mandatory near-miss reporting for data centre operators. We could not check this against the amended Bill, so the wording below reflects HL Bill 32 and may be out of date. See what Parliament changed.
The short version
A near-miss log is a simple record of events that could have harmed your organisation but didn't. The Cyber Security and Resilience Bill (CSRB) does not expressly require one, and "near miss" isn't a defined term in the text. Keeping one still helps you defend your reporting decisions and spot weak controls.
The template below is unofficial. Adapt it to your organisation and replace it if your regulator publishes requirements.
Why keep one if it isn't required?
It records your reasoning. Near misses can be the hardest reporting calls. A dated note showing what you knew and why you decided not to report is far better than reconstructing it later.
Regulators can ask. The Bill lets regulators issue information notices about whether an incident occurred that they believe "could have had" an adverse effect on systems, and about its nature and impact. Your log would be a natural place to start.
It supports your security duty. Regulated organisations must take appropriate measures to manage risk. Patterns of near misses show where those measures depend on luck.
It helps with UK GDPR. Personal data breaches must be recorded even if they aren't reported. A near-miss entry can record why something wasn't a breach.
Data centres face a wider test. Their reporting test covers incidents that "could have had" a significant impact, so a clear process matters even more. See breach vs incident vs near miss.
What to log
Keep the bar low. Log any event that met these conditions:
- A control failed, or only just worked.
- Someone or something outside the normal process stopped it.
- It would have had a real effect if it had gone further.
- A staff member was worried enough to raise it.
Examples include:
- a phishing email clicked, with credentials entered, where a second factor stopped the login
- an administrator account exposed online, found before use
- a suspicious change caught in review just before release
- a supplier reporting a compromise that didn't reach you
- a backup failure found during a test
- sensitive data almost sent to the wrong recipient
Don't log routine blocked traffic such as automated scans. Those belong in your monitoring tools. Otherwise the log turns into noise and people stop reading it.
The template
Copy these fields into a spreadsheet or ticketing system.
| Field | What to enter | Example |
|---|---|---|
| Reference | Unique ID | NM-2026-014 |
| Date and time found | When someone first noticed, with time zone | 3 Nov 2026, 09:42 GMT |
| Reported by | Name or team | Service desk |
| Summary | What happened, in plain English | Admin credentials found in a public code repository |
| Systems or services | What was exposed or at risk | Customer remote management platform |
| How it was found | Control, person, supplier or luck | Staff member noticed by chance |
| What stopped it | Which control worked, if any | Not exploited; access logs reviewed |
| What could have happened | Realistic worst case | Access to customer environments |
| Evidence checked | Logs and tools, with coverage | Access logs for 90 days, no use found |
| Bill assessment | Test applied, outcome and reasons | Security not affected on current evidence; not reportable |
| UK GDPR assessment | Was personal data affected? | No personal data accessed on current evidence |
| Other duties | Contracts, other regulators | Contract: customer notice not triggered |
| Decision maker | Name, role and time | Head of Security, 3 Nov, 11:15 |
| Root cause | Why it was possible | No secret scanning in pipeline |
| Actions | Fixes, owners and dates | Add secret scanning, Dev lead, 14 Nov |
| Status | Open or closed, with date | Open |
| Reviewed again? | Whether new facts changed the assessment | Reassess if logs show access |
How to run it
Assign ownership
Give the log to one role, such as the head of security or the incident manager. Others can add entries, but one person should check they're complete.
Make it easy to report
Use whatever staff already have, such as a form, a chat channel or a service desk category. Make clear that nobody will be penalised for raising a concern, including about their own mistake. If people fear blame, the log only captures what they can't hide.
Reassess when facts change
A near miss can turn out to be an incident. If new evidence shows the attacker did get in, reassess straight away. Under the Bill, the reporting clock depends on when you first became aware of a reportable incident, so record the time the assessment changed.
Protect the log
The log can reveal weaknesses in your defences and personal details about staff. Limit access, set a retention period and avoid putting credentials or unnecessary personal data in it. Talk to your legal team about how to handle entries linked to legal advice.
Review it regularly
Once a month, or quarterly for smaller organisations, look for:
- repeat causes
- controls that often fail or are often the last line of defence
- suppliers that keep appearing
- how many events were found by luck
- overdue actions
Share a short summary with senior leadership. Numbers alone can mislead. A rising count may mean people trust the process, not that security got worse.
What the log doesn't replace
- Incident notifications. If an event meets a reporting test, use your 24-hour notification template.
- Your UK GDPR breach record. Keep the two linked, but make sure breaches are clearly recorded.
- Your risk register. Move lasting weaknesses there.
Sources
Frequently asked questions
Not expressly in the text we reviewed. Regulators can still ask about incidents that could have had an adverse effect, so a log is useful evidence of your reasoning. Reports say the Lords may have narrowed this at Report Stage, so check the final text.
At minimum: the date and time, what happened, what stopped it, the realistic worst case, your reporting assessments, who decided, the root cause and any actions.
No. Routine blocked traffic belongs in monitoring tools. Log events where a control failed or only just worked, or that had real potential to cause harm.
Reassess straight away and record when your assessment changed. If it now meets a reporting test, start your notification process.