Incident Management Policy
| Field | Value |
|---|---|
| Document ID | IRP-001 |
| Version | 1.0 |
| Classification | Internal |
| Owner | Lauren ten Hoor (Director, Incident Commander) |
| Effective date | 2026-04-30 |
| Next review | 2027-04-30 (or after every SEV-1/SEV-2 incident) |
| Parent policy | Information Security Policy (ISP-001) |
| Operational document | Incident Response Runbook |
1. Purpose
To define the Company's commitments and minimum standards for managing information-security and privacy incidents, ensuring timely detection, containment, notification, and learning.
2. Scope
All security and privacy incidents affecting Cadences.work systems, sub-processors, or customer data, as defined in §3 below. The detailed operational steps for handling an incident are in the Incident Response Runbook; this Policy sets the framework, commitments, and notification obligations the runbook implements.
3. Definition
A security incident is any event that may compromise the confidentiality, integrity, or availability of the Company's information assets, the production environment, or Customer Personal Data, including:
- Unauthorised access, disclosure, alteration, or destruction of Customer Personal Data;
- Compromise of an administrative credential;
- Loss or theft of a device with persistent access to production;
- Confirmed exploitation of a vulnerability in the codebase or a sub-processor;
- Service outage exceeding one hour in the production environment;
- A sub-processor incident affecting Cadences customer data, notified to Cadences;
- Significant accidental data deletion without recoverability.
A personal data breach under GDPR Article 4(12) is a subset of security incident: a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.
4. Roles
| Role | Responsibility |
|---|---|
| Incident Commander | Overall coordination, severity assignment, decisions, stakeholder communication |
| Technical Lead | Forensics, containment, recovery |
| Communications Lead | Customer and regulator notifications |
| Data Protection Officer | Regulator liaison; GDPR/PDPA assessment |
In the current one-person org, all roles are held by the Director. External advisors (legal counsel, fractional CISO) may be engaged on retainer.
5. Severity levels
| Severity | Definition |
|---|---|
| SEV-1 (critical) | Confirmed breach of Customer Personal Data; data loss with no recovery path; total production outage |
| SEV-2 (high) | Likely breach under investigation; partial outage; admin credential compromise without confirmed data access |
| SEV-3 (medium) | Localised issue; service degradation; vulnerability discovered but no exploitation evidence |
| SEV-4 (low) | No customer impact; phishing attempt against personnel; informational |
The Incident Commander assigns severity at intake and may revise it as new information emerges.
6. Phases
The Company follows a Detect → Triage → Contain → Eradicate → Recover → Notify → Learn model. Operational steps for each phase are in the Incident Response Runbook.
7. Notification commitments
The Company commits to the following notification timelines.
7.1 To customers
Affected customers are notified without undue delay and in any case within 72 hours of confirmation where reasonably possible. Channel: email to the primary admin contact and an in-app banner. Content per DPA §10.
7.2 To EU supervisory authorities
Personal data breaches likely to result in a risk to data subjects' rights are notified to the lead EU supervisory authority (via the EU Representative) within 72 hours of becoming aware (GDPR Art. 33).
7.3 To Singapore PDPC
Notifiable breaches under PDPA Section 26B (≥500 individuals or significant harm) are reported to the PDPC within 72 hours of becoming aware.
7.4 To affected individuals
Direct notification to data subjects is made when the breach is likely to result in high risk to their rights and freedoms (GDPR Art. 34), unless effective measures (e.g. unbroken encryption with keys not exposed) render the data unintelligible to unauthorised parties.
7.5 Holding statements
Where the full scope of an incident is not known within the notification deadline, an interim notification is sent containing what is known, with subsequent updates as more information becomes available.
8. Documentation and post-incident review
For every SEV-1 and SEV-2 incident, the Incident Commander shall produce:
- An incident record capturing timeline, root cause, actions taken, classification, and notifications sent.
- A post-incident review within 14 days of resolution, covering: what happened, what worked, what didn't, and dated action items with owners.
For SEV-3 and SEV-4, a brief incident record is created. Post-incident review is at the Incident Commander's discretion.
Records are retained for at least 5 years in docs/compliance/incidents/.
9. Tabletop exercises
The Company shall conduct at least one tabletop exercise per year using a realistic scenario. The exercise tests detection, containment, customer notification, and post-mortem. Findings are recorded in docs/compliance/incidents/exercises/ and feed back into this Policy and the Runbook.
10. Training and awareness
All personnel shall be trained in incident reporting on joining and at least annually. The training covers: how to recognise an incident, who to contact, the principle of "report first, investigate later," and the prohibition on covering up incidents.
11. Sub-processor incidents
Sub-processor breaches affecting Customer Personal Data are treated as Cadences incidents for the purpose of customer notification. The Company maintains a sub-processor escalation contact list in the Runbook §Contact log.
12. Compliance and references
ISO/IEC 27001:2022 Annex A: A.5.24, A.5.25, A.5.26, A.5.27, A.5.28, A.5.29, A.5.30, A.6.8.
GDPR Articles 33 (notification to authority) and 34 (notification to data subjects).
Singapore PDPA Sections 26A–26D (data breach notification).
Operational document: Incident Response Runbook.
13. Version history
| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0 | 2026-04-30 | Lauren ten Hoor | Initial issue |