86 lines
3.2 KiB
Markdown
86 lines
3.2 KiB
Markdown
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] |
|