← All policies

Incident Management Policy

FieldValue
Document IDIRP-001
Version1.0
ClassificationInternal
OwnerLauren ten Hoor (Director, Incident Commander)
Effective date2026-04-30
Next review2027-04-30 (or after every SEV-1/SEV-2 incident)
Parent policyInformation Security Policy (ISP-001)
Operational documentIncident 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

RoleResponsibility
Incident CommanderOverall coordination, severity assignment, decisions, stakeholder communication
Technical LeadForensics, containment, recovery
Communications LeadCustomer and regulator notifications
Data Protection OfficerRegulator 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

SeverityDefinition
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

VersionDateAuthorSummary
1.02026-04-30Lauren ten HoorInitial issue