1. Purpose
The Incident Register is the central record of information security incidents and significant security events.
It provides a consistent way to track incidents from initial reporting through:
Detection → Validation → Classification → Escalation → Investigation → Containment → Recovery → Corrective Action → Closure
The register provides management with visibility into:
- Number and type of incidents
- Incident severity
- Affected systems and information
- Response status
- Business and customer impact
- Root causes
- Corrective actions
- Recurring incidents
- Residual risks
- Incident trends
The Incident Register should be maintained as a controlled ISMS record.
2. Scope
The register may include:
- Confirmed information security incidents
- Significant security events
- Account compromises
- Phishing incidents
- Malware and ransomware
- Data breaches
- Cloud compromises
- Unauthorized access
- Vulnerability exploitation
- Availability incidents
- Supplier incidents
- Privacy-related incidents
- Lost or stolen information assets
- Source-code or CI/CD security incidents
- Physical security incidents affecting information
- Other events requiring formal investigation or escalation
Routine events that do not meet the organization’s incident criteria may be recorded in security monitoring systems instead.
3. Incident Register Master Table
| Field | Description |
|---|---|
| Incident ID | Unique incident reference |
| Date Reported | Date incident was reported |
| Time Reported | Time incident was reported |
| Date Detected | Date first detected |
| Incident Title | Short description |
| Incident Type | Phishing, breach, malware, etc. |
| Source | Employee, monitoring, supplier, customer, etc. |
| Severity | SEV-1 / SEV-2 / SEV-3 / SEV-4 |
| Status | Open / Investigating / Contained / Recovering / Closed |
| Incident Commander | Assigned incident owner |
| Security Lead | Security response owner |
| Business Owner | Affected business owner |
| Affected Asset | System, application, cloud account, etc. |
| Affected Information | Type of information involved |
| Customer Impact | Yes / No / Unknown |
| Personal Data Impact | Yes / No / Unknown |
| Supplier Involved | Yes / No |
| Business Impact | Low / Medium / High / Critical |
| Initial Impact | Short description |
| Root Cause | Confirmed root cause |
| Containment Date | Date containment completed |
| Recovery Date | Date recovery completed |
| Closure Date | Date incident closed |
| Corrective Action | Required remediation |
| Action Owner | Person responsible |
| Target Date | Corrective action deadline |
| Residual Risk | Remaining risk |
| Evidence Reference | Investigation/evidence records |
| Management Review | Yes / No / N/A |
4. Incident Status
Use controlled status values:
Open
Incident has been reported and accepted for investigation.
Validating
The response team is determining whether the event is a security incident.
Investigating
The incident has been confirmed and investigation is underway.
Contained
Immediate threat or unauthorized activity has been contained.
Recovering
Systems or services are being restored.
Monitoring
Recovery has occurred and additional monitoring is being performed.
Awaiting Corrective Action
Technical incident response is complete, but corrective actions remain open.
Closed
Investigation, recovery, impact assessment, and required actions have been completed or formally accepted.
5. Incident Classification
Classify each incident using standardized categories.
| Category | Examples |
|---|---|
| Account Compromise | Employee, administrator, cloud identity |
| Phishing | Credential phishing, malicious link, attachment |
| Malware | Trojan, spyware, malicious software |
| Ransomware | Encryption/extortion attack |
| Data Breach | Unauthorized access/disclosure |
| Cloud Compromise | AWS account, IAM, workload or storage compromise |
| Unauthorized Access | Access outside approved authorization |
| Vulnerability Exploitation | Exploited software or infrastructure vulnerability |
| Availability | Security-related outage or disruption |
| Supplier Incident | Third-party security incident |
| Privacy Incident | Personal-data security incident |
| Insider Incident | Suspected misuse or unauthorized activity |
| Physical Incident | Lost/stolen device or information |
| Application Security | Application compromise or attack |
| CI/CD Security | Pipeline, repository or deployment compromise |
| Other | Other security incident |
6. Severity
The Incident Register should use the organization’s approved Incident Severity Matrix.
| Severity | General Description |
|---|---|
| SEV-1 Critical | Major security, customer, business, regulatory, or operational impact |
| SEV-2 High | Significant security or business impact requiring prompt escalation |
| SEV-3 Medium | Limited and generally contained impact |
| SEV-4 Low | Minor impact or unsuccessful/blocked security event |
Severity should be reassessed when new evidence changes the understanding of impact.
7. Incident Source
Record how the incident was identified.
- Employee report
- Security monitoring
- SIEM
- EDR
- Cloud security alert
- Vulnerability scanner
- Application monitoring
- Customer report
- Supplier notification
- Internal audit
- External audit
- Threat intelligence
- Security testing
- Management report
- Law enforcement
- Other
This information helps identify weaknesses in detection capabilities.
8. Affected Assets
Record all affected or potentially affected assets.
Examples:
- AWS account
- IAM identity
- S3 bucket
- RDS database
- ECS workload
- Server
- Laptop
- Mobile device
- SaaS application
- Email account
- Git repository
- CI/CD pipeline
- API
- Network infrastructure
- Database
- Physical records
Where practical, link the incident to the organization’s Asset Register.
9. Information Involved
Record the type and classification of information involved.
- Public
- Internal
- Confidential
- Customer information
- Personal data
- Financial information
- Authentication information
- Credentials/secrets
- Source code
- Intellectual property
- Regulated information
Do not place unnecessary sensitive information directly into the register. Use a secure evidence or investigation reference where detailed information is required.
10. Impact Assessment
Each incident should assess:
Confidentiality
Was information accessed or disclosed without authorization?
Integrity
Was information, configuration, code, or system state changed without authorization?
Availability
Was a system or service unavailable or degraded?
Customer Impact
Were customers affected?
Personal Data Impact
Was personal data involved?
Business Impact
Did the incident affect:
- Revenue
- Operations
- Service delivery
- Reputation
- Contractual obligations
- Regulatory obligations
- Critical business processes?
11. Incident Timeline
Maintain key dates in the register.
| Milestone | Date/Time |
|---|---|
| First Activity | |
| Detection | |
| Reported | |
| Validated | |
| Incident Declared | |
| Severity Assigned | |
| Escalated | |
| Containment Started | |
| Containment Completed | |
| Investigation Completed | |
| Recovery Started | |
| Recovery Completed | |
| Corrective Actions Assigned | |
| Closure Approved | |
| Incident Closed |
Detailed events should be maintained in the Incident Timeline Template rather than overloading the register.
12. Escalation Tracking
| Field | Information |
|---|---|
| Escalation Required? | Yes / No |
| Escalation Level | |
| Incident Commander | |
| Security Lead | |
| Executive Management Involved? | |
| Legal/Privacy Involved? | |
| Business Owner Involved? | |
| Supplier Involved? | |
| External Support Required? | |
| Customer Communication Required? | |
| Regulatory Assessment Required? |
The register should reference the detailed escalation record where applicable.
13. Containment Tracking
Record the main containment actions.
Examples:
- Account disabled
- Session revoked
- Credentials rotated
- Device isolated
- Network access restricted
- Cloud resource isolated
- Malicious process terminated
- Compromised workload removed
- Vulnerability mitigated
- Supplier access suspended
| Action | Owner | Date | Status |
|---|---|---|---|
14. Investigation Summary
Record a concise summary of the investigation.
What Happened?
How Did It Happen?
What Was Affected?
What Information Was Accessed?
Was Data Exfiltration Confirmed?
Yes / No / Unknown
Was Lateral Movement Identified?
Yes / No / Unknown
Was Persistence Identified?
Yes / No / Unknown
Root Cause
Detailed investigation information should be maintained in the Incident Investigation Template.
15. Data Breach Assessment
For incidents involving potential information exposure:
| Question | Result |
|---|---|
| Personal data involved? | Yes / No / Unknown |
| Customer data involved? | Yes / No / Unknown |
| Sensitive information involved? | Yes / No / Unknown |
| Unauthorized access confirmed? | Yes / No / Unknown |
| Data exfiltration confirmed? | Yes / No / Unknown |
| Affected individuals identified? | Yes / No / Unknown |
| Legal assessment required? | Yes / No |
| Regulatory assessment required? | Yes / No |
| Customer notification assessment required? | Yes / No |
| Notification decision | |
| Decision Owner | |
| Evidence Reference |
The register should record the decision and reference detailed legal/privacy records where appropriate.
16. Supplier Incident Tracking
If a supplier is involved:
| Field | Information |
|---|---|
| Supplier | |
| Supplier Service | |
| Critical Supplier? | Yes / No |
| Supplier Notification Date | |
| Supplier Incident Reference | |
| Information Affected | |
| Customer Impact | |
| Supplier Investigation Status | |
| Corrective Action Required | |
| Supplier Action Owner | |
| Supplier Closure Date |
Link the incident to the organization’s Supplier Register and supplier risk records where applicable.
17. AWS SaaS Startup Example
Incident
A security monitoring system detects suspicious activity in an AWS production account.
Register Entry
| Field | Example |
|---|---|
| Incident ID | INC-2026-014 |
| Title | Suspicious AWS Administrator Activity |
| Type | Cloud Compromise |
| Source | Cloud Security Alert |
| Severity | SEV-1 / SEV-2 Pending Investigation |
| Status | Investigating |
| Asset | AWS Production Account |
| Identity | Privileged IAM Identity |
| Information | Customer/Application Data – Impact Unknown |
| Customer Impact | Unknown |
| Personal Data | Unknown |
| Incident Commander | Security Lead |
| Business Owner | CTO |
| Containment | IAM identity restricted |
| Evidence | CloudTrail / Security Logs |
| Root Cause | Under Investigation |
| Corrective Action | Pending Investigation |
The detailed investigation would then reference:
- CloudTrail
- IAM activity
- S3 access
- RDS activity
- ECS activity
- Secrets Manager
- Network activity
- Application logs
- Security alerts
The register remains the management-level record, while detailed technical evidence stays in the investigation record.
18. Corrective Action Tracking
Every significant incident should be reviewed to determine whether corrective action is required.
| Incident ID | Finding | Root Cause | Corrective Action | Owner | Due Date | Status |
|---|---|---|---|---|---|---|
Examples:
- Enable MFA
- Reduce privileged access
- Patch vulnerable application
- Improve logging
- Improve monitoring
- Update firewall rules
- Improve backup protection
- Modify supplier requirements
- Improve phishing awareness
- Improve incident detection
- Update procedure
- Conduct additional security testing
Corrective actions should be transferred to the organization’s Corrective Action Tracker where required.
19. Residual Risk
After response and corrective action, determine whether risk remains.
| Field | Information |
|---|---|
| Residual Risk | Low / Medium / High / Critical |
| Risk Description | |
| Existing Controls | |
| Additional Treatment Required? | Yes / No |
| Risk Owner | |
| Risk Acceptance Required? | Yes / No |
| Acceptance Authority | |
| Review Date |
An incident should not automatically be considered fully resolved simply because the technical threat has been removed.
The organization should also determine whether the underlying risk has been adequately addressed.
20. Incident Closure Criteria
Before closing an incident, verify:
- Incident scope established
- Severity confirmed
- Evidence preserved
- Containment completed
- Threat removed or controlled
- Root cause identified or documented as unknown
- Affected systems recovered
- Recovery verified
- Data impact assessed
- Customer impact assessed
- Privacy/legal assessment completed where required
- Regulatory obligations assessed
- Supplier actions completed where applicable
- Corrective actions assigned
- Residual risk assessed
- Lessons learned completed where appropriate
- Management review completed where required
- Incident Closure Report completed
21. Incident Metrics
The register can be used to calculate:
Volume
- Total incidents
- Incidents by month
- Incidents by severity
- Incidents by type
Response
- Mean Time to Detect (MTTD)
- Mean Time to Report
- Mean Time to Respond (MTTR)
- Mean Time to Contain
- Mean Time to Recover
Impact
- Customer-impacting incidents
- Data incidents
- Privacy incidents
- Production incidents
- Supplier incidents
- Critical incidents
Corrective Action
- Open corrective actions
- Overdue actions
- Recurring findings
- Average action closure time
22. Management Dashboard View
A management dashboard can summarize:
| Metric | Current Period | Previous Period | Trend |
|---|---|---|---|
| Total Incidents | |||
| SEV-1 | |||
| SEV-2 | |||
| SEV-3 | |||
| SEV-4 | |||
| Data Incidents | |||
| Customer-Impacting Incidents | |||
| Supplier Incidents | |||
| Open Incidents | |||
| Overdue Corrective Actions | |||
| Average Time to Contain | |||
| Recurring Incidents |
The dashboard should be used to identify trends and systemic weaknesses, not merely to count incidents.
23. Recurring Incident Analysis
Where similar incidents occur repeatedly, assess whether there is a systemic problem.
Example:
Five phishing incidents
→ Same type of email attack
→ Multiple employees clicking links
→ Similar credential exposure
→ Root cause analysis
→ Improve email controls + MFA + awareness + monitoring
→ Track effectiveness
Recurring incidents should feed into:
- Risk assessment
- Corrective actions
- Security awareness
- Control improvement
- Management review
- Continual improvement
24. Incident Register Review
The register should be reviewed periodically by the designated security or ISMS owner.
Review:
- Open incidents
- Overdue incidents
- High-severity incidents
- Recurring incidents
- Customer-impacting incidents
- Data/privacy incidents
- Supplier incidents
- Corrective actions
- Residual risks
- Response performance
- Trends
Significant incidents should be escalated to management according to the organization’s governance requirements.
25. Record Retention
The organization should define retention requirements based on:
- Legal requirements
- Regulatory requirements
- Contractual requirements
- Privacy requirements
- Business requirements
- ISMS record-retention rules
- Insurance requirements
- Investigation requirements
Incident records should be protected against unauthorized modification or deletion.
26. Access Control
The Incident Register may contain sensitive information and should therefore have controlled access.
Access should generally be limited to authorized personnel such as:
- Security team
- Incident response team
- IT/Engineering
- Privacy/Legal
- Compliance
- Relevant management
Detailed sensitive evidence should be stored separately where appropriate.
27. ISO 27001 Connection
The Incident Register supports the organization’s information security incident management process by providing evidence that incidents are:
- Reported
- Recorded
- Assessed
- Classified
- Escalated
- Investigated
- Responded to
- Reviewed
- Corrected
- Closed
The exact register structure should be determined by the organization’s risks, incident types, business requirements, contractual commitments, and applicable legal or regulatory obligations.
The register is an organizational implementation record, not a requirement to use a particular spreadsheet or software tool.
28. Recommended Incident Register Columns
For a practical startup implementation, the minimum spreadsheet/database columns can be:
Incident ID | Date Reported | Date Detected | Incident Title | Type | Source | Severity | Status | Incident Commander | Business Owner | Affected Asset | Information Involved | Customer Impact | Privacy Impact | Business Impact | Containment | Root Cause | Corrective Action | Action Owner | Due Date | Residual Risk | Closure Date | Evidence Reference
This provides a lightweight register without turning incident management into unnecessary administration.
29. Audit Trail
A complete incident record should demonstrate:
Event Detected
→ Incident Reported
→ Incident ID Assigned
→ Incident Validated
→ Severity Determined
→ Incident Owner Assigned
→ Escalation Performed
→ Evidence Preserved
→ Containment Performed
→ Investigation Completed
→ Impact Assessed
→ Root Cause Identified
→ Recovery Completed
→ Corrective Actions Assigned
→ Residual Risk Assessed
→ Lessons Learned
→ Management Review
→ Incident Closed
30. Final Principle
One Central Record + One Clear Incident ID + Complete Timeline + Evidence-Based Assessment + Defined Ownership + Corrective Action + Documented Closure = Effective Incident Management.
The Incident Register should remain the single management-level view of the organization’s security incidents, while detailed investigation, evidence, communications, and corrective-action records can remain in their respective controlled records.