Incident Management Policy

Document Number: ISMS-POL-INC-01

Classification: L1 — Policy (Domain)

Version: 0.1.0

Effective Date: February 20, 2026

Author: Lucas Shin — Security Director

Approved By: Richard — CISO

Next Review Date: February 2027

Parent Policy: Information Security Policy (ISMS-POL-ISP-01)

1. Purpose

This policy establishes the framework for detecting, reporting, assessing, responding to, and learning from information security incidents across Cybercraft.

It ensures that security events are handled consistently, evidence is preserved, business impact is minimised, and lessons learned are incorporated into continuous improvement of the ISMS.

2. Scope

2.1 Applicable Incidents

This policy covers all information security incidents affecting:

• Cybercraft's M365 tenant and Entra ID environment
• BYOD devices accessing corporate data
• Third-party SaaS tools used for business operations
• Client data processed by or on behalf of Cybercraft
• CA100 Appliances deployed at client sites (if within ISMS scope)

2.2 Incident Types

2.3 Out of Scope

• IT service disruptions without security implications (covered by Business Continuity Policy, Business Continuity Policy, ISMS-POL-BCP-01)
• Client-side incidents in client-owned infrastructure (reported to client per engagement agreement)

3. Roles and Responsibilities

4. Incident Classification

4.1 Severity Levels

4.2 Escalation Matrix

5. Incident Lifecycle

🏗️ Incident Response Flow

graph TD
    D["Phase 1\nDetection & Reporting"] --> T["Phase 2\nTriage & Assessment"]
    T --> C["Phase 3\nContainment & Response"]
    C --> I["Phase 4\nInvestigation &\nEvidence Collection"]
    I --> R["Phase 5\nRecovery & Remediation"]
    R --> L["Phase 6\nPost-Incident Review\n(Lessons Learned)"]
    L -->|"Improvement actions"| D

5.1 Phase 1 — Detection & Reporting

Automated detection sources:

Manual reporting:

• All personnel must report suspected security events to the Security Director within 24 hours via Teams message or email
• Reports should include: what was observed, when, affected systems/data, and any actions already taken

5.2 Phase 2 — Triage & Assessment

Upon receiving a report or alert, the Security Director shall:

1. Verify the event — confirm whether it is a genuine security incident or a false positive
2. Classify the severity (per §4.1)
3. Assess scope — determine affected users, data, and systems
4. Escalate per the escalation matrix (§4.2)
5. Document initial assessment in the Incident Register (§7)

5.3 Phase 3 — Containment & Response

Containment actions are proportionate to severity and may include:

BYOD-specific incident response procedures are detailed in Monitoring & Incident Response Procedure.

5.4 Phase 4 — Investigation & Evidence Collection

The Security Director shall:

1. Collect evidence from relevant sources:
   • Entra ID sign-in and audit logs
   • Microsoft Defender incident reports
   • Intune compliance and audit logs
   • M365 Unified Audit Log (UAL)
   • SaaS provider audit logs (where available)
2. Preserve evidence — export logs with timestamps and store securely in a designated M365 Private Channel (Confidential classification)
3. Maintain chain of custody — document who accessed evidence, when, and for what purpose
4. Timeline reconstruction — build a chronological sequence of events from first indicator to detection

5.5 Phase 5 — Recovery & Remediation

1. Restore affected services and accounts to normal operation
2. Verify containment effectiveness — confirm the threat is eliminated
3. Re-enable blocked accounts/devices after verification
4. Implement immediate compensating controls if root cause cannot be immediately resolved
5. Communicate resolution to affected parties

6. Post-Incident Review (Lessons Learned)

6.1 Review Process

6.2 Review Outputs

Each Post-Incident Review shall produce:

• Root cause analysis — why the incident occurred
• Effectiveness assessment — how well detection and response performed
• Gap identification — controls that failed or were absent
• Improvement actions — specific, assigned, time-bound corrective actions
• Policy/procedure updates — if the incident reveals gaps in existing policies

6.3 Aggregate Review

• All incidents (including Severity 3–4) are reviewed in aggregate during quarterly management reviews
• Trend analysis: incident types, frequency, response times, recurring root causes
• Results feed into the annual risk assessment and ISMS improvement cycle

7. Incident Register

The Security Director shall maintain an Incident Register recording:

• Incident ID and date
• Reporter and detection source
• Description and classification (severity)
• Affected assets, users, and data
• Containment and response actions taken
• Evidence collected and storage location
• Root cause and lessons learned (for Severity 1–2)
• Improvement actions and status
• Closure date

The Incident Register is stored in a Confidential M365 Private Channel accessible only to the Security Director and CISO.

8. External Notification

8.1 Client Notification

If an incident affects client data:

• Notify the client within 72 hours of confirming data impact (or as specified by the client engagement agreement, whichever is sooner)
• CEO approves all client-facing incident communications
• Notification includes: nature of the incident, data affected, actions taken, and contact information

8.2 Regulatory Notification

• If a data breach triggers notification obligations under applicable privacy legislation (e.g., NZ Privacy Act 2020), the CEO and CISO determine the notification approach
• Legal advice may be sought for significant breaches

8.3 Law Enforcement

• Engagement with law enforcement is approved by the CEO on advice from the CISO
• Evidence preservation takes priority over investigation speed

9. Compliance Mapping

10. Document Control

Review Schedule

• Quarterly: Incident trend analysis, aggregate review of Severity 3–4 incidents
• Annually: Full policy review, process effectiveness assessment
• Ad-hoc: After any Severity 1 incident, or upon significant changes to the threat landscape or organisational structure

[End of Policy Document]