Information Security Incident Management Policy

1. Purpose

The Information Security Incident Management Policy establishes the organization’s approach for identifying, reporting, assessing, responding to, recovering from, and learning from information-security incidents.

The objective is to ensure that information-security events are:

Identified promptly
Reported through defined channels
Assessed consistently
Classified according to risk and impact
Contained appropriately
Investigated using reliable evidence
Communicated to relevant stakeholders
Recovered in a controlled manner
Recorded and tracked
Reviewed for lessons learned
Used to improve information-security controls

The policy supports the organization’s Information Security Management System (ISMS) and should be implemented proportionately to the organization’s size, risk profile, business requirements, contractual obligations, and applicable legal and regulatory requirements.

2. Scope

This policy applies to information-security incidents involving:

Information assets
Information systems
Cloud environments
Applications
Networks
Databases
Endpoints
Mobile devices
Identity and access systems
Physical information assets
Customer information
Personal information
Confidential information
Source code
Credentials and secrets
Suppliers and third parties
Cloud service providers
SaaS applications
Software and technology dependencies
Employees, contractors, and other authorized users

The policy applies to employees, contractors, temporary personnel, suppliers, and other parties whose activities may affect the organization’s information security.

3. Information Security Incident Management Principles

The organization shall manage information-security incidents according to the following principles:

Report early — suspected incidents should be reported promptly.
Assess before concluding — alerts and unusual activity should be validated.
Contain appropriately — actions should limit further impact.
Preserve evidence — relevant evidence should be protected from unnecessary alteration.
Protect confidentiality — incident information should be shared only with authorized parties.
Maintain business continuity — response actions should consider business impact.
Meet obligations — applicable legal, regulatory, contractual, and customer requirements should be considered.
Document decisions — significant actions and decisions should be traceable.
Learn from incidents — significant incidents should contribute to corrective action and continual improvement.

4. Definitions

Information Security Event

An observed occurrence that may indicate a security issue but has not yet been established as an incident.

Examples:

Multiple failed login attempts
Unusual network traffic
Malware alert
Unexpected configuration change

Information Security Incident

A single or series of unwanted or unexpected information-security events that has a significant probability of compromising information security or disrupting business operations.

Security Alert

A notification generated by a security tool, monitoring system, supplier, employee, or other source indicating potentially suspicious activity.

Data Breach

An incident involving unauthorized access to, disclosure, alteration, loss, or destruction of protected information, where applicable under relevant law or contractual requirements.

Major/Critical Incident

An incident whose impact or potential impact requires significant management involvement, coordinated response, or urgent escalation.

5. Incident Management Lifecycle

The organization shall manage incidents through an appropriate lifecycle:

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

Not every security event will require every stage. The response should be proportionate to the nature and severity of the event.

6. Incident Sources

Information-security events may be identified through:

Employees
Customers
Security monitoring
SIEM
EDR
Cloud security tools
Vulnerability scanners
Application monitoring
Network monitoring
IAM systems
Audit logs
Penetration testing
Internal audits
Supplier notifications
Cloud provider notifications
Threat intelligence
Security researchers
Automated alerts
Physical security systems

The organization should provide practical mechanisms for reporting suspected incidents.

7. Incident Reporting

All personnel should promptly report suspected information-security incidents through the organization’s approved reporting channel.

Reports should contain, where available:

Reporter
Date and time
Description of event
Affected system
Affected information
Location/environment
Source of detection
Users involved
Initial impact
Evidence available
Actions already taken

Employees should not conceal, intentionally delay, or independently suppress a suspected security incident.

Where immediate containment is required, personnel may take reasonable emergency action within their authority and should report the action as soon as practical.

8. Incident Validation

The designated security or incident-management team shall assess whether a reported event is:

False positive
Normal/authorized activity
Security event requiring monitoring
Suspected security incident
Confirmed security incident

Validation may include:

Reviewing logs
Checking authorized changes
Confirming affected identities
Reviewing system activity
Checking vulnerability information
Reviewing relevant evidence
Contacting system owners
Engaging suppliers

The organization should avoid declaring an incident solely on the basis of an automated alert without reasonable validation where practical.

9. Incident Classification

Incidents should be classified using an approved severity methodology.

An illustrative classification is:

Severity	Typical Characteristics
Low	Limited security impact and no significant business disruption
Medium	Meaningful security issue requiring coordinated response
High	Significant impact to systems, information, customers, or operations
Critical	Major compromise, widespread impact, significant customer/data exposure, or critical business disruption

Classification should consider:

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

The organization may define different thresholds appropriate to its environment.

10. Incident Escalation

Incidents shall be escalated according to severity and business impact.

Escalation may involve:

Security leadership
IT/Cloud team
Application owners
Business owners
Senior management
Privacy team
Legal counsel
Compliance
Communications team
Supplier management
Cloud provider
External incident-response specialists

Critical incidents should have a clearly identified incident manager responsible for coordinating response activities.

11. Roles and Responsibilities

Role	Responsibility
All Personnel	Report suspected incidents and cooperate with investigations
Incident Manager	Coordinate incident response
Security Lead/CISO	Direct security assessment and response
IT/Cloud Team	Containment, technical investigation, and recovery
Application Owner	Assess application impact and support recovery
Business Owner	Assess business impact and service priorities
Privacy/Data Protection Owner	Assess privacy and personal-data implications
Legal/Compliance	Assess legal, regulatory, and contractual requirements
Supplier Owner	Coordinate incidents involving suppliers
Communications Lead	Coordinate approved internal/external communications
Management	Provide decisions, resources, and risk acceptance where required

One person may perform multiple roles in a startup, but responsibilities should remain clear.

12. Incident Response Team

The organization should maintain an appropriate incident-response capability.

Depending on organizational size, this may include:

Incident Manager
Security Lead
Cloud/Infrastructure Engineer
Application Engineer
IT/IAM Administrator
Privacy/Compliance representative
Legal representative
Business representative
Communications representative

External specialists may be engaged when internal capability is insufficient.

13. Immediate Response and Containment

Response actions should seek to prevent further damage while preserving evidence where practical.

Potential containment actions include:

Disabling compromised accounts
Revoking sessions
Blocking malicious traffic
Isolating endpoints
Restricting network access
Removing unauthorized access
Disabling compromised API keys
Rotating credentials
Isolating cloud workloads
Blocking malicious domains/IPs
Restricting affected applications
Suspending compromised integrations

Containment actions should consider:

Business impact
Evidence preservation
Customer impact
Safety
Recovery requirements

14. Evidence Preservation

Relevant evidence should be preserved where necessary for:

Investigation
Root-cause analysis
Regulatory requirements
Contractual requirements
Legal proceedings
Insurance requirements
Corrective actions

Evidence may include:

Audit logs
Authentication logs
Network logs
Application logs
Cloud logs
Endpoint information
Security alerts
Emails
Screenshots
System configurations
Access records
Vulnerability reports
Incident tickets
Supplier communications

Evidence should be protected from unauthorized modification and access.

Actual credentials, 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:

What happened?

What event occurred?
When did it occur?
How long did it continue?

How did it happen?

Compromised credentials?
Vulnerability?
Misconfiguration?
Phishing?
Malware?
Supplier compromise?
Insider activity?
Software supply-chain issue?

What was affected?

Systems
Applications
Infrastructure
Accounts
Networks
Information
Customers

What information was involved?

Public
Internal
Confidential
Customer
Personal
Financial
Source code
Credentials

What was the actual impact?

The investigation should distinguish between:

Suspected exposure
Confirmed access
Confirmed modification
Confirmed disclosure
Confirmed destruction

16. Information and Data Impact Assessment

For incidents involving information, the organization should determine:

Type of information
Classification
Owner
Location
Number of records, where known
Customer involvement
Personal-data involvement
Confidentiality impact
Integrity impact
Availability impact
Evidence of unauthorized access
Evidence of exfiltration
Retention requirements

Where personal information may be involved, the appropriate privacy/legal process should be initiated.

17. Supplier and Third-Party Incidents

Where an incident involves a supplier, the organization should:

Identify the affected supplier.
Identify the affected service.
Determine what information or systems are involved.
Review contractual notification requirements.
Contact the supplier through the approved channel.
Obtain available incident information.
Assess organizational impact independently.
Track supplier containment and corrective actions.
Assess residual risk.
Update supplier records where necessary.

Examples include:

Cloud provider incident
SaaS compromise
Supplier credential compromise
Third-party data breach
Software supply-chain compromise
Managed-service-provider incident

18. Cloud Incidents

Cloud incidents should be handled using the organization’s Cloud Incident Response Procedure.

Examples include:

Compromised cloud administrator account
Unauthorized IAM role assumption
Publicly exposed storage
Compromised cloud workload
Unauthorized security-group modification
Cloud database exposure
Compromised API credentials
Cloud cryptomining
CI/CD compromise

Relevant cloud logs and provider evidence should be preserved.

19. Cybersecurity Incident and Business Continuity

Where an incident affects availability or critical business operations, incident management should coordinate with:

Business Continuity Plan
Disaster Recovery Plan
Cloud Backup and Recovery Procedure
Crisis Management Process

For example:

Cyber Incident → Containment → Determine Service Impact → Activate Recovery → Restore Service → Validate Security → Resume Operations

Security recovery should not introduce the original compromise again.

20. Communication

Incident information should be communicated on a need-to-know basis.

Internal communication may include:

Incident status
Affected systems
Required actions
Business impact
Recovery status
Management decisions

External communication may involve:

Customers
Suppliers
Cloud providers
Regulators
Law enforcement
Insurance providers
Other contractual stakeholders

Only authorized personnel should issue external communications.

The organization should avoid unverified conclusions or speculative statements.

21. Legal, Regulatory and Contractual Notifications

For relevant incidents, the organization shall determine whether notification obligations exist under:

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

The appropriate legal, privacy, compliance, and management personnel should participate in these decisions.

Notification timelines should be based on the applicable requirement rather than an arbitrary internal assumption.

22. Eradication

After containment and investigation, the organization should remove the cause of the incident where practical.

Actions may include:

Removing malware
Patching vulnerabilities
Correcting misconfigurations
Removing unauthorized accounts
Removing malicious code
Rotating compromised credentials
Rebuilding systems
Replacing compromised components
Removing unauthorized integrations
Strengthening security controls

For significant incidents, rebuilding affected systems from trusted configurations may be preferable to attempting to clean compromised systems in place.

23. Recovery

Recovery activities should include:

Restoring systems
Restoring information
Rebuilding infrastructure
Reconfiguring security controls
Validating authentication
Validating access controls
Validating monitoring
Testing application functionality
Validating data integrity
Monitoring for recurrence

Recovery should be coordinated with business owners and system owners.

24. Incident Closure

An incident may be closed when:

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

Closure does not necessarily mean every corrective action has already been completed. Outstanding actions should remain tracked until resolved or formally risk-accepted.

25. Root Cause Analysis

Significant incidents should undergo root-cause analysis.

The organization should distinguish:

Immediate cause

What directly caused the incident?

Contributing factors

What conditions made the incident possible or increased its impact?

Root cause

What underlying weakness allowed the incident to occur or persist?

Example:

Incident: Unauthorized access to production environment

Immediate cause: Compromised credentials

Contributing factors:

Excessive permissions
Weak credential controls
Limited monitoring

Underlying control weaknesses:

Inadequate privileged-access management
Insufficient access review
Incomplete MFA enforcement

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

26. Corrective Actions

Incident findings should be recorded and tracked through the organization’s corrective-action process.

Actions may include:

Control improvements
Policy updates
Access changes
Security configuration changes
Vulnerability remediation
Additional monitoring
Employee awareness
Supplier requirements
Architecture changes
Backup improvements
Incident-response improvements
Risk treatment

Each significant action should have:

Finding
Risk
Root cause
Action
Owner
Due date
Status
Evidence
Verification
Closure

27. Lessons Learned

For significant incidents, the organization should perform a post-incident review.

The review should consider:

How was the incident detected?
Was detection sufficiently timely?
Was escalation effective?
Were roles clear?
Were logs sufficient?
Was evidence available?
Was containment effective?
Was recovery effective?
Were communications appropriate?
Were customer obligations met?
What controls failed?
What controls were missing?
What should change?

Lessons learned should feed into the ISMS improvement process.

28. Incident Testing and Exercises

The organization should periodically test its incident-management capability where appropriate.

Testing may include:

Tabletop exercises
Simulated phishing
Cloud compromise scenarios
Ransomware scenarios
Data-breach exercises
Lost-device scenarios
Supplier incident scenarios
Credential compromise exercises
Business continuity exercises

Exercises should evaluate the organization’s ability to:

Detect
Report
Escalate
Contain
Communicate
Recover
Document
Learn

Test findings should be tracked as corrective actions.

29. Incident Records

The organization should maintain appropriate records of information-security incidents.

Typical records include:

Incident ID
Date/time detected
Date/time reported
Reporter
Incident category
Affected systems
Affected information
Classification
Severity
Incident owner
Investigation
Evidence
Containment
Root cause
Impact assessment
Communications
Recovery
Corrective actions
Residual risk
Closure date
Approval
Lessons learned

The level of documentation should be proportionate to incident severity.

30. Incident Categories

The organization may categorize incidents such as:

Unauthorized access
Account compromise
Malware
Phishing
Ransomware
Data exposure
Data breach
Information leakage
Denial of service
Vulnerability exploitation
Cloud misconfiguration
Insider incident
Lost or stolen device
Physical security incident
Supplier incident
Software supply-chain incident
Credential compromise
Policy violation
Availability incident

The organization may add categories relevant to its environment.

31. Metrics and Management Reporting

Management may monitor appropriate incident-management metrics, such as:

Number of incidents
Number by severity
Number by category
Mean time to detect
Mean time to respond
Mean time to contain
Mean time to recover
Repeated incidents
Incidents involving suppliers
Incidents involving customer information
Open corrective actions
Overdue corrective actions
Incident exercise findings

Metrics should be used to identify trends and improvement opportunities rather than merely to count incidents.

32. Startup-Friendly Implementation

A startup can establish effective incident management without building a large security operations center.

A practical initial model includes:

People

Incident owner
Technical responder
Management escalation point
Privacy/legal contact where relevant

Technology

Centralized cloud logging
IAM monitoring
Endpoint protection
Vulnerability scanning
Security alerting
Secure backup

Process

Incident reporting channel
Severity matrix
Escalation process
Incident register
Response procedures
Recovery process
Corrective-action tracking

Evidence

Maintain enough evidence to demonstrate:

Detection → Assessment → Response → Recovery → Closure → Improvement

As the company grows, it can add SIEM, 24×7 monitoring, dedicated incident response, forensic capability, and external response providers.

33. Relationship With Other ISMS Documents

Document	Relationship
Information Security Policy	Establishes overall information-security direction
Risk Management Procedure	Provides risk assessment and treatment methodology
Incident Register	Records security incidents
Cloud Incident Response Procedure	Provides cloud-specific response activities
Data Breach Procedure	Handles privacy/data-breach requirements
Vulnerability Management Procedure	Handles vulnerability-related issues
Supplier Incident Response Procedure	Handles supplier incidents
Cloud Backup and Recovery Procedure	Supports recovery of cloud services
Business Continuity Plan	Supports business continuity
Disaster Recovery Plan	Supports technical recovery
Corrective Action Register	Tracks remediation
Risk Register	Records significant residual risks
Supplier Monitoring Procedure	Addresses supplier-related monitoring
Lessons Learned Register	Records improvement opportunities

34. Internal Audit Checklist

An auditor can verify:

Information-security incident-management policy is approved.
Incident roles and responsibilities are defined.
Incident reporting mechanisms exist.
Events and incidents are distinguished.
Incident classification criteria exist.
Escalation requirements are defined.
Incident-response procedures exist.
Evidence preservation is addressed.
Confidentiality of incident information is addressed.
Supplier incidents are covered.
Cloud incidents are covered.
Personal-data incidents are assessed.
Legal/regulatory obligations are considered.
Business continuity and recovery are integrated.
Incident records are maintained.
Significant incidents receive root-cause analysis.
Corrective actions are tracked.
Lessons learned are captured.
Incident-response exercises are performed where appropriate.
Management receives appropriate incident information.
Incident trends are reviewed.
The ISMS is improved based on incident experience.

35. ISO 27001 Connection

Information-security incident management should be implemented as part of the organization’s risk-based ISMS.

The organization should establish the applicable requirements through:

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

This policy establishes the governance framework. It does not by itself demonstrate that incident management is operating effectively.

Operational evidence may include:

Incident records
Investigation records
Security alerts
Logs
Escalation records
Containment evidence
Recovery evidence
Notification records
Corrective actions
Lessons learned
Incident exercises

36. Final Information Security Incident Management Audit Trail

A complete incident-management lifecycle should produce:

Security Event
→ Reported
→ Validated
→ Classified
→ Assigned
→ Escalated
→ Contained
→ Evidence Preserved
→ Investigated
→ Impact Assessed
→ Eradicated
→ Recovered
→ Communications Completed
→ Residual Risk Assessed
→ Corrective Actions Assigned
→ Lessons Learned
→ Management Review
→ Incident Closed
→ ISMS/Risk/Controls Improved

37. Final Principle

Effective Information Security Incident Management = Detect + Report + Assess + Contain + Investigate + Recover + Learn + Improve

The objective 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 residual risk remains, what corrective actions were taken, and how the incident improved the organization’s security controls.

ISO/IEC 27001