ISMS/03-procedures/security-incident-handling-procedure.md

Title: Security Incident Handling Procedure Document ID: [PROC-INCIDENT-001] Version: 0.1 Draft Status: Draft Owner: CISO (Paul Jenkins) Approver: CISO (Paul Jenkins) Classification: Internal Effective date: [DD Month YYYY] Review date: [DD Month YYYY]

Security Incident Handling Procedure

Purpose

This procedure defines how BlackDice should report, assess, contain, investigate, communicate, and close information security incidents.

Scope

This procedure applies to suspected or confirmed security incidents affecting in-scope people, information, systems, services, suppliers, or customers.

Trigger / When Used

Use this procedure when:

• a security event may represent an incident
• a user reports suspicious activity or weakness
• monitoring or telemetry identifies potentially malicious or unauthorised behaviour
• a supplier or customer notifies BlackDice of a security issue affecting in-scope operations

Procedure Steps

1. Record the reported event or issue and assign an initial handler or coordinator.
2. Perform initial triage to determine whether the issue is likely to be a security incident and assess urgency.
3. Classify the incident according to the approved severity approach and determine immediate containment needs.
4. Contain the incident where feasible while preserving evidence and avoiding unnecessary disruption.
5. Investigate the cause, affected assets, timeline, impact, and whether customer, supplier, privacy, or regulatory considerations apply.
6. Escalate internally and externally as required, including legal, privacy, customer communication, management, and supplier interfaces where relevant.
7. Coordinate eradication and recovery actions, including validation that risk has been reduced to an acceptable level.
8. Record lessons learned, required corrective actions, and any updates needed to risks, controls, or documentation before closure.

Inputs

• incident report or alert
• logs, telemetry, and evidence
• asset and ownership information
• relevant contact and escalation details

Outputs / Records

• incident record
• incident severity and status updates
• evidence and investigation notes
• recovery and communication record
• lessons learned and corrective actions

Roles and Responsibilities

• [Role] must coordinate incident handling and escalation.
• Personnel must report incidents promptly and cooperate with the response.
• System and service owners must support containment, investigation, and recovery.
• Management must support critical decisions and communications.

Escalation / Exceptions

Escalate immediately where:

• there is actual or suspected customer impact
• there is possible personal data compromise
• critical production services are at risk
• regulatory, contractual, or public communication may be required

Emergency deviations from normal process must be documented retrospectively if immediate action is necessary.

Related Documents

• Incident Response Policy
• Breach Notification Procedure
• Corrective Action Procedure
• Incident Register Template

Version Control

Version	Date	Description of Change	Author
0.1 Draft	[DD Month YYYY]	Initial draft.	[Name or Role]