Incident Response Procedure

1. Purpose

The Incident Response Procedure defines the operational process for identifying, reporting, assessing, containing, investigating, resolving, and closing information-security incidents.

The procedure ensures that incidents are handled consistently and that the organization can demonstrate:

What happened
When it happened
What was affected
How the incident was contained
What evidence was collected
How recovery was performed
What risks remain
What corrective actions were taken
What was learned

This procedure supports the organization’s Information Security Incident Management Policy and should be applied proportionately to the nature, severity, and business impact of each incident.

2. Scope

This procedure applies to security incidents involving:

Information systems
Applications
Servers
Endpoints
Networks
Cloud services
Databases
SaaS applications
User accounts
Privileged accounts
Mobile devices
Customer information
Personal information
Confidential information
Source code
Credentials and secrets
Physical information assets
Suppliers and third parties
Software and technology dependencies

It applies to employees, contractors, temporary personnel, suppliers, and other authorized parties.

3. Incident Response Lifecycle

The organization shall manage incidents through the following lifecycle:

Prepare → Detect → Report → Validate → Classify → Assign → Contain → Investigate → Eradicate → Recover → Verify → Communicate → Close → Learn → Improve

Not every incident will require identical actions. The response should be proportionate to the incident.

4. Incident Types

Incidents may include:

Unauthorized access
Account compromise
Credential theft
Malware
Ransomware
Phishing
Data leakage
Data breach
Unauthorized disclosure
Vulnerability exploitation
Cloud misconfiguration
Unauthorized configuration change
Denial-of-service attack
Insider incident
Lost or stolen device
Physical security incident
Supplier incident
Software supply-chain incident
API compromise
Website/application compromise
Security-policy violation

5. Roles and Responsibilities

Role	Responsibility
Incident Reporter	Reports suspected incident
Incident Manager	Coordinates overall response
Security Lead	Directs security investigation and response
IT/Infrastructure Team	Performs technical containment and recovery
Application Owner	Assesses application impact
Cloud Team	Handles cloud-specific technical response
Data/Privacy Owner	Assesses personal/customer data impact
Legal/Compliance	Reviews legal, regulatory, and contractual obligations
Business Owner	Assesses business impact
Supplier Owner	Coordinates third-party incidents
Management	Makes significant business/risk decisions

For smaller organizations, one individual may perform multiple roles.

6. Preparation

Before an incident occurs, the organization should maintain appropriate response capability.

Preparation should include:

Approved incident-management policy
Incident-response procedure
Incident reporting channel
Incident severity criteria
Incident contacts
Escalation contacts
Asset inventory
System/application owners
Cloud service information
Relevant security logs
Backup and recovery capability
Security monitoring
Vulnerability management
Contact information for key suppliers
Legal/privacy escalation contacts

The organization should periodically verify that important contacts and response procedures remain current.

7. Incident Detection

An incident may be detected through:

Employee reports
Customer reports
Security monitoring
SIEM
EDR
Antivirus
Firewall
WAF
Cloud security tools
Authentication alerts
Audit logs
Vulnerability scanners
Penetration testing
Supplier notifications
Cloud provider notifications
Threat intelligence
Security researchers
Internal audits

The person or system identifying a potential incident should initiate the reporting process.

8. Incident Reporting

The reporter should provide as much information as reasonably available.

The initial report should include:

Date and time
Reporter
Description of event
Affected system
Affected user/account
Possible information involved
How the event was detected
Initial business impact
Screenshots/logs/evidence where available
Actions already taken

Employees should not intentionally delay reporting while attempting to determine whether an event is a genuine incident.

9. Initial Triage

The incident owner should perform an initial assessment to determine:

Is this a genuine security event?
What system is affected?
Is the system operational?
Is unauthorized access suspected?
Is sensitive information involved?
Is the incident ongoing?
Is immediate containment required?
Does management need to be notified?
Are legal, privacy, customer, or regulatory requirements potentially involved?

The objective is to establish the initial scope quickly without prematurely assuming the final cause or impact.

10. Event Validation

The response team should validate the event using available evidence.

Validation may include:

Reviewing logs
Checking authentication activity
Reviewing recent changes
Confirming authorized activity
Checking system configuration
Reviewing endpoint alerts
Checking application activity
Contacting system owners
Reviewing supplier information

The event may be categorized as:

False positive
Normal/authorized activity
Security event
Suspected incident
Confirmed incident

11. Incident Classification

Confirmed incidents should be classified according to the organization’s approved severity methodology.

An illustrative model is:

Severity	Description
Low	Limited impact with no significant business disruption
Medium	Meaningful security impact requiring coordinated response
High	Significant impact to information, systems, customers, or operations
Critical	Major compromise, widespread impact, critical service disruption, or significant data exposure

Classification should consider:

Confidentiality
Integrity
Availability
Information sensitivity
Customer impact
Personal-data impact
Production impact
Privileged access
Number of affected systems
Duration
Business impact
Regulatory requirements
Contractual obligations

12. Incident Assignment and Escalation

Each confirmed incident should have an identified owner.

The Incident Manager should determine whether additional personnel are required.

Escalation may include:

Security leadership
IT
Cloud/DevOps
Application owners
Business owners
Privacy
Legal
Compliance
Management
Suppliers
Cloud providers
External incident-response specialists

Critical incidents should receive appropriate management attention.

13. Immediate Containment

The response team should take appropriate action to prevent further damage.

Possible actions include:

Account compromise

Disable account
Revoke sessions
Reset credentials
Revoke tokens
Rotate access keys
Enforce MFA
Remove unauthorized privileges

Compromised endpoint

Isolate device
Disable network access where appropriate
Preserve evidence
Remove malicious software

Compromised application

Restrict affected functionality
Block malicious traffic
Disable compromised credentials
Deploy emergency security controls

Data exposure

Remove unintended access
Restrict affected resources
Preserve relevant evidence
Assess whether information was accessed

Containment should consider both security and business impact.

14. Evidence Preservation

The response team should preserve relevant evidence where required.

Evidence may include:

Authentication logs
Application logs
Cloud logs
Network logs
Endpoint information
Security alerts
Firewall/WAF logs
Database logs
Configuration history
Emails
Screenshots
System images
Vulnerability reports
Supplier communications
Incident tickets

Evidence should be:

Protected from unauthorized modification
Accessible only to authorized personnel
Traceable to the incident
Retained according to applicable requirements

Actual passwords, API keys, private keys, or other secrets must not be stored in incident records.

15. Investigation

The investigation should establish, as far as reasonably possible:

Timeline

When did the activity begin?
When was it detected?
How long did it continue?
When was it contained?

Attack or failure mechanism

Examples:

Stolen credentials
Phishing
Vulnerability exploitation
Misconfiguration
Malware
Unauthorized access
Supplier compromise
Software vulnerability

Affected assets

Identify:

Systems
Applications
Accounts
Devices
Databases
Networks
Cloud resources
Information

Impact

Determine whether there was:

Unauthorized access
Unauthorized disclosure
Unauthorized modification
Data destruction
Service disruption

16. Scope Assessment

The investigation should determine whether the incident is isolated or broader than initially reported.

Consider:

Related accounts
Related systems
Similar vulnerabilities
Other environments
Other users
Other customers
Other suppliers
Related cloud resources
Related applications
Related credentials

Where appropriate, threat-hunting activities may be performed to identify additional compromise.

17. Information and Data Impact Assessment

Where information is involved, determine:

Information type
Classification
Information owner
Location
Approximate volume
Customer involvement
Personal-data involvement
Confidentiality impact
Integrity impact
Availability impact
Evidence of access
Evidence of disclosure or exfiltration

The organization should distinguish between:

Potential exposure → Suspected access → Confirmed access → Confirmed disclosure

This distinction should be supported by available evidence.

18. Supplier and Third-Party Incidents

If an incident involves a supplier:

Identify the supplier.
Identify the affected service.
Determine affected information/systems.
Review contractual obligations.
Notify or engage the supplier.
Obtain available incident information.
Assess organizational impact.
Track supplier corrective actions.
Reassess supplier risk where appropriate.
Update supplier records.

Supplier notifications should be validated against the organization’s own information where practical.

19. Cloud Incidents

Cloud-specific incidents should be handled using the Cloud Incident Response Procedure.

Examples include:

Compromised cloud account
Unauthorized IAM activity
Public storage exposure
Compromised cloud workload
Unauthorized security-group changes
Cloud database exposure
Compromised API credentials
Cloud cryptomining

Relevant cloud audit logs and provider information should be preserved.

20. Eradication

After sufficient investigation and containment, the response team should remove the cause of compromise.

Actions may include:

Remove malware
Patch vulnerabilities
Correct configuration weaknesses
Remove unauthorized accounts
Remove malicious code
Rotate credentials
Rebuild systems
Replace compromised components
Remove malicious persistence
Disable compromised integrations

Where appropriate, affected systems should be rebuilt from trusted configurations.

21. Recovery

Recovery should restore systems to a secure and operational condition.

Activities may include:

Restore from trusted backups
Rebuild systems
Deploy patched applications
Restore databases
Restore configuration
Reconfigure security controls
Validate access
Validate monitoring
Test application functionality
Verify data integrity

Recovery should be coordinated with the relevant business and system owners.

22. Recovery Verification

Before the incident is considered operationally recovered, verify:

Unauthorized access has been removed.
Compromised credentials have been addressed.
Vulnerabilities have been remediated or risk-treated.
Security controls are functioning.
Logging is operational.
Monitoring is operational.
Data integrity is acceptable.
Applications are functioning.
Business services are available.
No continuing indicators of compromise are present.

23. Communication

Incident information should be communicated according to severity and need-to-know.

Internal stakeholders may include:

Management
Security
IT
Application owners
Business owners
Privacy
Legal
Compliance

External stakeholders may include:

Customers
Suppliers
Cloud providers
Regulators
Law enforcement
Insurance providers

Only authorized personnel should issue external communications.

Communications should be factual and should avoid unsupported conclusions.

24. Legal, Regulatory and Contractual Assessment

The organization should determine whether the incident creates notification or reporting obligations under:

Applicable laws
Data-protection requirements
Regulatory requirements
Customer contracts
Supplier agreements
Data Processing Agreements
Insurance requirements

Legal, privacy, compliance, and management personnel should be involved where appropriate.

25. Root Cause Analysis

Significant incidents should undergo root-cause analysis.

The analysis should distinguish:

Immediate Cause

What directly caused the incident?

Contributing Factors

What increased the likelihood or impact?

Root Cause

What underlying control or process weakness allowed the incident?

Example:

Incident: Unauthorized production access

Immediate cause: Compromised user credentials.

Contributing factors:

Excessive privileges
Weak authentication controls
Inadequate monitoring

Underlying weakness:

Insufficient privileged-access management.

Corrective actions:

Enforce MFA
Implement least privilege
Remove unnecessary privileged access
Perform periodic access reviews
Improve monitoring

26. Corrective Actions

Incident findings should be recorded in the organization’s corrective-action process.

Each action should identify:

Finding
Risk
Root cause
Corrective action
Owner
Priority
Due date
Status
Evidence
Verification
Closure

Corrective actions should address underlying control weaknesses rather than only the immediate incident symptom.

27. Lessons Learned

For significant incidents, conduct a post-incident review.

Consider:

How was the incident detected?
Was detection timely?
Was reporting effective?
Was escalation appropriate?
Were roles clear?
Was evidence sufficient?
Was containment effective?
Was recovery effective?
Were communications appropriate?
Were contractual/regulatory requirements met?
What controls failed?
What controls were missing?
What should be changed?

Lessons learned should feed into the ISMS continual-improvement process.

28. Incident Closure

An incident should be formally closed when:

Investigation is sufficiently complete.
Containment is confirmed.
Eradication is complete or appropriately tracked.
Recovery is verified.
Required notifications are completed.
Evidence has been retained.
Corrective actions have been assigned.
Residual risk has been assessed.
Required approvals have been obtained.

Open corrective actions do not necessarily prevent incident closure, provided they remain formally tracked.

29. Incident Record

Each confirmed incident should have an incident record containing, as applicable:

Field	Description
Incident ID	Unique identifier
Date/Time	Detection and reporting time
Reporter	Person/source reporting
Category	Type of incident
Severity	Incident classification
Incident Owner	Responsible person
Affected Assets	Systems/services involved
Information	Information involved
Description	What happened
Evidence	Supporting evidence
Timeline	Key events
Containment	Actions taken
Investigation	Findings
Impact	Business/security impact
Root Cause	Underlying cause
Recovery	Recovery actions
Notifications	Stakeholders notified
Corrective Actions	Remediation
Residual Risk	Remaining risk
Closure	Closure date/approval

30. Incident Response Evidence

Typical evidence includes:

Incident reports
Incident register
Security alerts
Audit logs
Authentication logs
Investigation notes
Screenshots
System/configuration evidence
Containment records
Credential-rotation evidence
Recovery records
Customer/regulatory communications
Root-cause analysis
Corrective-action records
Lessons-learned records
Management approvals
Incident exercise results

31. Incident Response Testing

The organization should periodically test its response capability where appropriate.

Examples:

Tabletop exercise
Phishing simulation
Compromised account exercise
Ransomware scenario
Cloud compromise scenario
Data-breach scenario
Supplier incident scenario
Lost-device scenario

Testing should assess:

Detection → Reporting → Escalation → Containment → Investigation → Communication → Recovery → Closure

Findings should be documented and tracked.

32. Startup-Friendly Incident Response

A startup can begin with a simple but controlled model.

People

Incident Manager
Security/technical responder
Business/management escalation
Privacy/legal contact

Technology

Centralized logging
Endpoint protection
Cloud monitoring
MFA
Vulnerability management
Backup and recovery

Process

One incident-reporting channel
Severity matrix
Escalation contacts
Incident register
Response procedure
Corrective-action tracker

Evidence

Maintain a traceable record:

Detection → Response → Recovery → Closure → Improvement

As the organization grows, it can introduce SIEM, 24×7 monitoring, forensic capabilities, external incident-response retainers, and automated response.

33. Relationship With Other ISMS Documents

Document	Relationship
Information Security Incident Management Policy	Establishes overall governance
Incident Register	Records incidents
Cloud Incident Response Procedure	Handles cloud-specific incidents
Data Breach Procedure	Handles privacy/data-breach requirements
Vulnerability Management Procedure	Handles vulnerability-related findings
Supplier Incident Response Procedure	Handles supplier incidents
Cloud Backup and Recovery Procedure	Supports recovery
Business Continuity Plan	Supports business continuity
Disaster Recovery Plan	Supports technical recovery
Risk Management Procedure	Supports risk assessment
Corrective Action Register	Tracks remediation
Risk Register	Tracks significant residual risks
Lessons Learned Register	Tracks improvement opportunities

34. Internal Audit Checklist

An auditor can verify:

Incident response procedure is approved.
Roles and responsibilities are defined.
Reporting mechanisms exist.
Incident validation is performed.
Severity criteria are defined.
Escalation requirements are documented.
Containment procedures exist.
Evidence preservation is addressed.
Investigation procedures exist.
Data impact assessment is performed where applicable.
Supplier incidents are addressed.
Cloud incidents are addressed.
Recovery procedures are defined.
Recovery is verified.
Legal/regulatory requirements are assessed.
Incident records are maintained.
Significant incidents receive root-cause analysis.
Corrective actions are tracked.
Lessons learned are documented.
Incident-response testing is performed where appropriate.
Incident trends are reviewed.
Improvements are incorporated into the ISMS.

35. ISO 27001 Connection

This procedure operationalizes the organization’s information-security incident-management requirements.

The applicable controls should be determined through:

Context → Risk Assessment → Risk Treatment → Applicable Controls → Statement of Applicability → Implementation → Evidence → Continual Improvement

The procedure itself is not proof that incident management is effective.

An auditor should be able to trace an actual incident through:

Alert/Report → Incident Record → Classification → Investigation → Containment → Recovery → Evidence → Corrective Action → Closure

The organization should also demonstrate that lessons from incidents are considered in its risk assessment and continual improvement activities.

36. Final Incident Response Audit Trail

A complete incident should produce a traceable chain:

Event Detected
→ Reported
→ Validated
→ Classified
→ Assigned
→ Escalated
→ Contained
→ Evidence Preserved
→ Investigated
→ Scope Determined
→ Impact Assessed
→ Eradicated
→ Recovered
→ Recovery Verified
→ Communications Completed
→ Root Cause Identified
→ Corrective Actions Assigned
→ Residual Risk Assessed
→ Lessons Learned
→ Management Review
→ Incident Closed
→ ISMS/Risks/Controls Improved

37. Final Principle

Effective Incident Response = Detect Quickly + Contain Safely + Investigate Properly + Recover Securely + Verify + Learn

The goal is not simply to close an incident ticket.

The organization should be able to demonstrate:

What happened, how it was detected, what was affected, how the organization responded, what evidence supports the investigation, how recovery was verified, what risk remains, and what changed as a result of the incident.

ISO/IEC 27001