What Is an Incident Register and How Do You Set One Up?

When something goes wrong, whether it is an outage, a data leak, a near-miss, or a customer complaint that turns into a regulatory question, the worst time to invent a process is in the middle of it. An incident register gives you a structured, consistent place to capture every incident from the moment it is reported through to its final lessons learned. Done well, it is the operational twin of your risk register. One tells you what could go wrong; the other tells you what actually did.

Watch: Set up an incident register (short tutorial)

What an Incident Register Is

An incident register (sometimes called an incident log) is a central record of all incidents that affect your organization, captured in a consistent structure so they can be tracked, analysed and reported. An incident is any unplanned event that causes, or could have caused, harm, loss, disruption, or a breach of policy or obligation. That definition is deliberately broad: it covers IT outages, security breaches, safety events, data-protection incidents, fraud, supplier failures, and plain operational errors.

The register is not the same thing as a single incident report. A report is the narrative document about one event; the register is the master list that holds a row for every incident and links out to the detail. If you have read what goes into an incident report, think of the register as the table of contents and the report as the chapter.

A good incident register does four things at once:

• Captures every incident in one place, so nothing falls through the cracks of email threads and chat channels.
• Classifies incidents by type and severity so you can prioritise and trend them.
• Tracks ownership, status and corrective actions through to closure.
• Connects incidents back to the risks and controls they relate to, feeding your wider risk picture.

Why an Incident Register Matters

Organizations without a register tend to manage incidents from memory and inbox. That creates a handful of predictable problems:

• The same root cause recurs because nobody noticed the pattern across three separate tickets.
• Corrective actions are agreed in a meeting and then quietly forgotten.
• Regulators or auditors ask "show me every privacy incident in the last 12 months" and the answer takes two weeks of archaeology.
• Leadership has no reliable view of how often things go wrong, how badly, or whether it is getting better.

A register fixes all of these. It also carries a strategic payoff: incident data is some of the most honest risk intelligence you will ever get. It tells you which of your controls are actually failing in the real world, not just on paper. That is why mature programs treat the register as a feedback loop into risk, a connection we explore in how incidents connect to your risk register.

The Core Fields Every Register Needs

The exact columns vary by organization, but the trade-off is constant: a register that is too thin cannot be analysed, and one that is too heavy never gets filled in. The following fields are the practical core. Make the first handful mandatory at intake and let the analytical fields fill in as the investigation matures.

Field	Purpose	Captured When
Incident ID	Unique identifier for tracking and cross-reference (e.g. INC-2026-0142)	At intake (auto-generated)
Date & time	When the incident occurred and when it was reported (track both)	At intake
Reported by	Who raised it, so you can follow up for detail	At intake
Type / category	Taxonomy bucket: IT, security, safety, privacy, fraud, operational, etc.	At intake (provisional)
Severity / priority	How bad it is and how urgently it needs attention	At intake, refined after investigation
Description	A clear, factual account of what happened	At intake, expanded over time
Impact	What was affected: systems, customers, data, money, people	During response
Root cause	The underlying reason, not just the symptom	After investigation
Owner	The single person accountable for resolving and closing it	At triage
Status	Open, in progress, contained, resolved, closed	Updated throughout
Linked risk	The risk-register entry this incident relates to	During or after investigation
Corrective actions	What you are doing to fix and prevent recurrence, with due dates	After investigation

Optional but valuable fields

As your program matures, consider adding a few more: detection method (how you found out), time to detect and time to resolve, affected business unit or location, a regulatory reportability flag, the linked controls that failed, and a free-text "lessons learned" field that feeds your post-incident review.

Setting Up Your Register Step by Step

Step 1: Define what counts as an incident

Before you build anything, agree on scope. Is a single failed login an incident, or only a confirmed breach? Does a near-miss get logged? Write a one-paragraph definition with a few clear examples and counter-examples. Without it, people either over-report trivia or under-report serious events, and both corrupt your data.

Step 2: Choose your taxonomy and severity scale

Decide on a short, mutually understood list of incident types and a severity scale (commonly four or five levels). Keep the type list under about a dozen top-level categories, with optional sub-types. The detail of how to classify is covered in how do you classify an incident; pin those definitions down now so every entry uses the same language.

Step 3: Build the structure

Create your register with the core fields above. A spreadsheet is a fine starting point for a small team. As volume grows you will want a tool that enforces required fields, generates IDs, timestamps changes, and links incidents to risks and actions, because the manual version quietly drifts out of date.

Step 4: Define the intake path

Decide how incidents get into the register: a form, an email alias, a chat command, or an integration from your ticketing tool. The easier you make reporting, the more complete your data. Make sure every channel funnels into the same register so you do not end up with three competing logs.

Step 5: Assign triage and ownership rules

Agree who reviews new entries, how fast, and how owners are assigned. This is also where you set escalation thresholds, so that when a severity crosses a line it triggers the path described in when and how do you escalate an incident.

Capturing Incidents Consistently

The single biggest threat to a register is inconsistency. If two people log the same kind of event in two different ways, your trends become noise. A few habits keep capture clean:

• Write descriptions factually. What happened, when, and what was affected, with no blame and no speculation. Save the analysis for the root-cause field.
• Classify at intake, then confirm later. Set a provisional type and severity immediately so the incident is actionable, and revisit both once you know more.
• Use controlled vocabularies. Drop-downs for type, severity and status beat free text every time, because free text cannot be counted.
• Timestamp everything. Status changes, ownership changes and key actions should each carry a time, building a timeline you can reconstruct later.

Maintaining the Register Over Time

A register is a living record, not a write-once archive. Maintenance has three rhythms.

Per incident

Keep each entry current as it moves through its lifecycle, and do not close it until corrective actions are genuinely complete and verified. A "resolved" incident with three overdue actions is not closed. It is a recurrence waiting to happen.

Periodic review

On a regular cadence (monthly is common), review open incidents, chase overdue actions, and check that classifications still make sense. Look for clusters too: several "minor" incidents with the same root cause may add up to a serious systemic issue.

Trend and feedback

Periodically aggregate the register by type, by severity, by root-cause theme, and by time-to-resolve. Feed those insights back into your risk register and into your wider incident-management practice. This is where the register stops being administrative overhead and starts driving real improvement.

Common Mistakes to Avoid

1. Too many fields, too few completed

A register with 30 columns where only 5 are reliably filled in is worse than a focused one with 12. Make the core mandatory and keep the rest optional.

2. No clear definition of "incident"

Without a shared definition you get inconsistent reporting: either trivia floods the log or serious events never reach it.

3. Closing incidents before actions are done

Marking something "resolved" because the immediate fire is out, while corrective actions remain open, defeats the purpose. Track actions to verified completion.

4. Free text everywhere

If type and severity are free text, you cannot trend or report. Use controlled vocabularies.

5. Treating it as separate from risk

An incident register that never links back to the risk register wastes its best data. Connect the two so real-world events refine your risk estimates.

Frequently Asked Questions