Setting up an incident log that auditors trust

An empty incident log is a red flag for auditors. It doesn't mean nothing went wrong — it means you're not recording it. Here's how to set up a log that actually works.

"We haven't had any incidents in the past year" is a sentence that makes auditors raise an eyebrow. Almost every organisation has incidents — ranging from a spotted phishing email to a shared password accidentally pasted into Slack. Logging them shows you're on top of it.

What counts as an incident?

Any event that (potentially) affects the confidentiality, integrity, or availability of business information. Incidents are not the same as data breaches — many incidents stay small and are resolved quickly, but they still deserve to be recorded.

What do you capture per incident?

• Date + time of detection
• Brief description (e.g. "phishing email appearing to come from the CEO")
• Category (phishing, lost device, malware, unintended disclosure, data breach, other)
• Severity (low / medium / high)
• Who reported it
• Who picked it up
• Status (open, in progress, closed)
• Actions taken
• Root cause + lesson learned (on closure)
• GDPR data breach notification required? Yes / No + rationale

Where do you log it?

An Airtable, Notion database, or a dedicated spreadsheet works fine — as long as it's structured. For 50+ incidents per year, a dedicated tool starts to pay for itself.

Linking to the risk register

Every high-impact incident should feed back into the risk register: raise the likelihood score, update the control, and lower the residual risk once action has been taken.

Data breach notification (GDPR)

A data breach must be reported to the supervisory authority within 72 hours of discovery. See GDPR data breach notification. Your incident log is the primary evidence that you did so on time.