ISO 27001 Security Incident Management Procedure
1. Purpose
This procedure defines how the organization identifies, reports, records, assesses, responds to, escalates, resolves, and learns from information security incidents.
The objective is to ensure that security incidents are handled consistently and that appropriate actions are taken to:
- Minimize business impact
- Protect information and systems
- Preserve evidence
- Restore normal operations
- Meet legal, regulatory, and contractual obligations
- Prevent recurrence
- Support continual improvement of the ISMS
2. Scope
This procedure applies to:
- Employees
- Contractors
- Consultants
- Temporary personnel
- IT and security teams
- Engineering teams
- Third-party service providers where applicable
- Information systems and applications within the ISMS scope
- Cloud environments
- Corporate endpoints
- Customer-facing systems
- Information processed by the organization
The procedure applies to both internally detected incidents and incidents reported by customers, suppliers, security researchers, or external parties.
3. Security Event vs Security Incident
A security event is an observable occurrence that may be relevant to information security.
Examples:
- Multiple failed login attempts
- Suspicious email
- Malware alert
- Unusual network activity
- Unexpected configuration change
A security incident is an event or series of events that requires investigation or response because it has, or may have, an adverse impact on information security.
Examples:
- Confirmed unauthorized access
- Customer data exposure
- Compromised privileged account
- Malware infection
- Successful phishing attack
- Unauthorized production change
- Data loss
- Security breach involving a supplier
Not every security event becomes a security incident.
4. Incident Management Principles
The organization should manage incidents using the following principles:
4.1 Report Early
Employees should report suspected incidents immediately rather than waiting to confirm whether an incident has occurred.
4.2 Contain First Where Necessary
Where an active threat exists, reasonable containment actions should be taken quickly to limit further damage.
4.3 Preserve Evidence
Relevant logs, records, communications, and other evidence should be preserved appropriately.
4.4 Use Need-to-Know Access
Incident information should be shared only with individuals who need it for investigation, response, management, legal, regulatory, or business purposes.
4.5 Document Decisions
Important response decisions, actions, approvals, and communications should be recorded.
4.6 Learn From Incidents
Significant incidents should be reviewed to identify control weaknesses and improvement opportunities.
5. Incident Management Lifecycle
The organization should follow this process:
Report
↓
Record
↓
Triage
↓
Classify
↓
Contain
↓
Investigate
↓
Resolve / Recover
↓
Communicate
↓
Close
↓
Lessons Learned
↓
Corrective Action & Improvement
6. Step 1 – Incident Reporting
Anyone who becomes aware of a suspected security incident should report it through the organization’s approved reporting channel.
Possible reporting channels include:
- Security email address
- Service desk
- Security ticketing system
- Incident hotline
- Direct escalation to Security Lead
- Automated security alert
- Customer support channel
Example
An employee receives a suspicious email requesting their corporate password.
The employee should report the email to the security team rather than attempting to investigate it independently.
7. Step 2 – Create an Incident Record
The incident owner or designated responder should create an incident record.
Minimum information should include:
| Field | Example |
|---|---|
| Incident ID | INC-2026-001 |
| Date/Time Reported | 30-Sep-2026 10:15 |
| Reported By | Employee |
| Detection Source | Employee |
| Incident Type | Phishing |
| Affected Asset | Corporate Email |
| Initial Severity | Medium |
| Assigned Owner | Security Lead |
| Status | Open |
| Initial Description | Suspicious credential phishing email |
The record should be updated throughout the incident lifecycle.
8. Step 3 – Initial Triage
The assigned responder should perform an initial assessment.
Determine:
- What happened?
- When did it happen?
- How was it detected?
- Which systems are affected?
- Which information may be affected?
- Is the incident still active?
- Is unauthorized access suspected?
- Is personal data involved?
- Are customers affected?
- Is a supplier involved?
- Is there potential legal or regulatory impact?
The initial assessment should be based on available evidence and updated as more information becomes available.
9. Step 4 – Incident Classification
Incidents should be categorized to support consistent handling.
Example Categories
| Category | Examples |
|---|---|
| Account Compromise | Stolen credentials, unauthorized login |
| Malware | Virus, ransomware, trojan |
| Phishing | Credential theft, malicious attachment |
| Data Exposure | Accidental disclosure, unauthorized access |
| Application Security | Exploitation, insecure configuration |
| Cloud Security | Unauthorized AWS/Azure/GCP activity |
| Network Security | Intrusion, suspicious traffic |
| Physical Security | Lost device, unauthorized physical access |
| Insider Activity | Unauthorized employee activity |
| Supplier Incident | Third-party security compromise |
| Availability | Security-related service disruption |
10. Step 5 – Determine Severity
The organization should assign a severity based on factors such as:
- Confidentiality impact
- Integrity impact
- Availability impact
- Number of affected systems
- Number of affected customers/users
- Sensitivity of information
- Privileged access involved
- Business impact
- Legal/regulatory impact
- Duration
- Potential for further compromise
Example Classification
| Severity | Description | Example |
|---|---|---|
| Critical | Significant or potentially widespread impact | Confirmed compromise of critical production environment |
| High | Significant security or business impact | Compromised privileged account |
| Medium | Limited but material impact | Malware on one endpoint |
| Low | Minor impact requiring limited response | Suspicious email blocked before interaction |
Severity may be increased or decreased as investigation findings develop.
11. Step 6 – Escalation
The incident should be escalated according to its severity and impact.
Example
| Situation | Escalation |
|---|---|
| Low-risk event | Security/IT |
| Medium incident | Security Lead + System Owner |
| High incident | Security Lead + CTO/Management |
| Critical incident | Incident Manager + Top Management + Legal/Privacy as applicable |
| Potential personal-data breach | Security + Privacy/Legal |
| Potential regulatory violation | Compliance/Legal |
| Suspected criminal activity | Legal / appropriate authority where required |
The organization should maintain an up-to-date escalation and contact list.
12. Step 7 – Containment
Where an incident is active, the response team should take reasonable measures to prevent additional damage.
Possible actions include:
- Disable compromised accounts
- Revoke sessions
- Reset credentials
- Rotate API keys
- Isolate affected endpoints
- Block malicious traffic
- Restrict network access
- Disable compromised integrations
- Restrict cloud permissions
- Remove unauthorized access
- Temporarily disable affected functionality
Containment decisions should consider business continuity and the potential impact of taking systems offline.
13. Step 8 – Investigation
The investigation should determine the scope and cause of the incident.
The responder should attempt to establish:
- Initial attack vector
- Affected accounts
- Affected systems
- Timeline
- Unauthorized actions
- Information accessed
- Information modified or deleted
- Potential data exfiltration
- Vulnerabilities exploited
- Controls that operated or failed
- Whether other systems are affected
Investigation findings should be documented in the incident record.
14. Evidence Collection
Relevant evidence should be collected and protected.
Possible evidence includes:
- Authentication logs
- AWS CloudTrail
- CloudWatch logs
- Application logs
- Endpoint security alerts
- Email headers
- Firewall logs
- Network logs
- Database logs
- Access records
- Screenshots
- System configuration
- Ticket history
- Relevant communications
Evidence should be protected against unauthorized modification or deletion.
Where legal proceedings or forensic investigation are possible, Legal or an appropriate specialist should be consulted regarding evidence preservation.
15. Step 9 – Eradication
After investigation, the organization should remove the cause or mechanism of the incident where reasonably possible.
Examples:
- Remove malware
- Patch exploited vulnerabilities
- Disable compromised accounts
- Remove unauthorized software
- Correct insecure configurations
- Rotate compromised credentials
- Remove malicious code
- Correct excessive privileges
- Rebuild compromised systems where necessary
16. Step 10 – Recovery
Affected systems should be restored in a controlled manner.
Before restoring normal operations, verify:
- The immediate threat has been addressed.
- Unauthorized access has been removed.
- Required credentials have been rotated.
- Security configurations are correct.
- Relevant vulnerabilities have been addressed.
- Monitoring is active.
- Backups are available where required.
- The system is functioning correctly.
Enhanced monitoring may be used following a significant incident.
17. Step 11 – Legal, Regulatory & Contractual Assessment
The organization should determine whether the incident creates any:
- Legal notification requirement
- Regulatory notification requirement
- Data-protection notification requirement
- Customer notification requirement
- Contractual reporting obligation
- Insurance notification requirement
- Law-enforcement requirement
Legal/Compliance should be involved where appropriate.
The organization should use its Authority & Regulatory Contact Register to identify relevant external contacts.
Notification decisions and communications should be recorded.
18. Step 12 – Communication
Incident communication should be coordinated and controlled.
Potential stakeholders include:
- Top Management
- Security Team
- IT/Engineering
- Legal
- Privacy/Compliance
- HR
- Customers
- Suppliers
- Regulators
- Law enforcement
- Insurance provider
Only authorized personnel should communicate externally regarding significant incidents.
Communications should be based on verified information and should clearly distinguish confirmed facts from information still under investigation.
19. Step 13 – Incident Resolution
An incident may be considered resolved when:
- The immediate threat has been contained.
- Necessary investigation has been completed.
- Affected systems have been recovered.
- Required notifications have been addressed.
- Required corrective actions have been identified.
- Business owners have confirmed restoration where appropriate.
- No further immediate response is required.
The incident record should then be prepared for formal closure.
20. Incident Closure Criteria
Before closing an incident, confirm:
- Root cause or probable cause documented
- Impact assessed
- Affected assets identified
- Containment completed
- Recovery completed
- Evidence preserved
- Required notifications assessed
- Customer impact assessed
- Corrective actions identified
- Risk Register reviewed where necessary
- Incident owner confirms closure
- Management notified where required
21. Post-Incident Review
Significant incidents should undergo a post-incident review.
The review should consider:
Detection
- How was the incident detected?
- Could it have been detected earlier?
Response
- Was escalation timely?
- Were responsibilities clear?
- Were containment actions effective?
Controls
- Which controls worked?
- Which controls were ineffective or missing?
Process
- Were procedures followed?
- Were communication channels effective?
Risk
- Does the incident indicate a change in information security risk?
Improvement
- What should be changed?
22. Corrective Actions
Corrective actions should be recorded and tracked.
| Action ID | Finding | Corrective Action | Owner | Due Date | Status |
|---|---|---|---|---|---|
| CA-001 | Excessive AWS privileges | Review and reduce privileged access | CTO | [Date] | Open |
| CA-002 | Phishing weakness | Conduct targeted awareness training | HR/Security | [Date] | Open |
| CA-003 | Missing alert | Improve cloud monitoring | IT | [Date] | Open |
Actions should remain open until the responsible owner provides appropriate evidence of completion.
Where appropriate, effectiveness should also be verified.
23. Link to Risk Management
Security incidents should feed back into the organization’s risk management process.
Example
Incident
Compromised AWS administrator account
↓
Investigation
Excessive privileges identified
↓
Risk Register
Unauthorized production access risk reviewed
↓
Risk Treatment
Improve privileged access controls
↓
Control
MFA + least privilege + access review
↓
Evidence
IAM configuration + review records + logs
↓
Verification
Internal audit / control review
This ensures that incident management contributes to continual improvement rather than ending when the immediate incident is resolved.
24. Third-Party Security Incidents
When a supplier reports or causes a security incident:
- Record the incident.
- Identify affected services/information.
- Assess customer and business impact.
- Request relevant incident information from the supplier.
- Assess contractual notification requirements.
- Determine whether regulatory requirements apply.
- Coordinate containment.
- Monitor supplier remediation.
- Update the risk assessment if necessary.
- Record lessons learned.
Supplier incidents should be tracked through the organization’s supplier risk management process where appropriate.
25. Security Incident Register
The organization should maintain a central incident register.
| Incident ID | Date | Type | Severity | Affected Asset | Owner | Status | Root Cause | Corrective Action | Closure Date |
|---|---|---|---|---|---|---|---|---|---|
| INC-001 | [Date] | Phishing | Medium | Security | Closed | User interaction | Training | [Date] | |
| INC-002 | [Date] | Account Compromise | High | AWS | CTO | Open | Credential compromise | MFA/access review | — |
Access to the incident register should be restricted based on the sensitivity of incident information.
26. Incident Management Metrics
Management may monitor metrics such as:
| Metric | Example |
|---|---|
| Number of incidents | 8 |
| Critical incidents | 0 |
| High incidents | 1 |
| Average response time | 25 minutes |
| Average resolution time | 6 hours |
| Repeat incidents | 1 |
| Incidents caused by phishing | 3 |
| Incidents with customer impact | 0 |
| Corrective actions overdue | 1 |
| Security incidents by category | Monthly trend |
Metrics should be used to identify trends and improvement opportunities rather than simply to demonstrate that the process exists.
27. Incident Management Testing
The organization should periodically test the incident management process.
Possible tests include:
- Phishing tabletop exercise
- AWS account compromise scenario
- Ransomware scenario
- Customer data exposure scenario
- Lost laptop scenario
- Supplier breach scenario
- Cloud outage/security incident scenario
The organization should document:
- Scenario
- Participants
- Expected response
- Actual response
- Gaps
- Corrective actions
- Responsible owners
- Completion status
28. Roles & Responsibilities
| Role | Responsibility |
|---|---|
| Top Management | Strategic decisions and major escalation |
| Incident Manager | Coordinates incident response |
| Security Lead/CISO | Security assessment and technical coordination |
| IT/Engineering | Investigation, containment and recovery |
| Legal | Legal and external communication requirements |
| Privacy/Compliance | Privacy and regulatory assessment |
| HR | Employee-related incidents |
| System Owner | Business impact and recovery decisions |
| Employees | Prompt reporting of suspected incidents |
| Internal Auditor | Independent review of the process where appropriate |
For a small organization, one person may perform several roles. However, independence should be maintained for assurance activities.
29. Required Records
The following records should be retained according to the organization’s documented information and retention requirements:
- Incident reports
- Incident register
- Investigation records
- Evidence
- Communication records
- Regulatory notifications
- Customer notifications
- Corrective actions
- Lessons-learned reports
- Incident exercise records
- Management reporting
- Risk assessment updates
Sensitive incident information should be protected according to its classification.
30. Startup Implementation Model
A small SaaS startup can implement this procedure using existing tools.
Example Tool Chain
Employee
→ Security email / ticket
Monitoring
→ Cloud/endpoint alert
Ticketing
→ Incident record
Security Lead
→ Triage and severity
AWS / M365 / GitHub
→ Investigation evidence
Legal / Compliance
→ Regulatory assessment
Management
→ Major incident decisions
Corrective Action Tracker
→ Follow-up
Risk Register
→ Risk update
Management Review
→ Continual improvement
The objective is to create a controlled process without introducing unnecessary software or documentation.
31. Quick Audit Checklist
An auditor should be able to verify:
- Security incidents can be reported.
- Incidents are recorded.
- Incident ownership is assigned.
- Incidents are classified.
- Severity criteria are defined.
- Escalation requirements are defined.
- Investigation procedures exist.
- Evidence is preserved.
- Containment actions are documented.
- Recovery is documented.
- Regulatory requirements are assessed.
- Customer notification requirements are assessed.
- Incidents are formally closed.
- Significant incidents undergo review.
- Corrective actions are tracked.
- Risk assessments are updated where necessary.
- Incident metrics are monitored.
- Incident response is periodically tested.
32. Relationship With Other ISMS Documents
The Security Incident Management Procedure should connect with:
Information Security Policy
↓
Defines overall security direction
Incident Management Policy
↓
Defines management requirements and principles
Security Incident Management Procedure
↓
Defines how incidents are operationally handled
Incident Response Plan
↓
Defines detailed response actions for significant incidents
Authority & Regulatory Contact Register
↓
Identifies relevant external authorities
Risk Register
↓
Captures risks identified or changed through incidents
Corrective Action Register
↓
Tracks improvements
Management Review
↓
Reviews trends, significant incidents and improvement actions
33. Final Principle
Security incident management should not end when the immediate problem is fixed.
The complete cycle is:
Report → Record → Assess → Contain → Investigate → Recover → Communicate → Close → Learn → Improve
A mature ISMS uses every significant incident as an opportunity to determine whether the organization’s risks, controls, procedures, and security practices need to change.