Incident Response Policy¶
| Field | Value |
|---|---|
| Status | draft |
| Owner | DIR (incident commander) / COUNSEL (breach-notification calls) |
| Applies to | Security incidents and personal-data breaches across all Partile systems, data, and vendors. |
| Review cadence | Annual; plus after every incident (lessons learned) and any tabletop exercise. |
| Mapped controls | SEC-13 (IR plan incl. breach clock + comms), SEC-11 (audit logging — input to detection). |
| Evidence | ../registers/incident-log.md (pointer register); ../procedures/incident-response-playbook.md; ../counsel-queue.md C19. |
| Exception handling | Deviations from the playbook during a live incident are logged in the post-mortem, not pre-approved. |
Purpose¶
Ensure that when something goes wrong, Partile contains it, meets its legal notification duties, and learns from it — with the 72-hour ICO clock and the physical-safety dimension built in from the start.
What counts as an incident¶
- Confirmed or suspected unauthorized access to systems or data.
- A personal-data breach (loss, unauthorized access/disclosure/alteration).
- A lost/compromised device with access to Partile systems.
- A safety incident arising from the product's online→offline nature (e.g. credible stalking/harassment enabled by a matching/location weakness) — treated with the same urgency as a data breach.
- Secret exposure (a credential committed, leaked, or logged).
Lifecycle¶
Detection → triage/severity → containment → eradication → recovery →
blameless post-mortem. The step-by-step is in
../procedures/incident-response-playbook.md.
Roles¶
DIR is incident commander (today; the role is what is hired into later). INFRA/OPS execute containment/eradication. COUNSEL owns the breach-notification determination. The post-mortem owner is assigned at close.
Breach notification (UK GDPR)¶
- 72 hours to the ICO from awareness where the breach is likely to risk individuals' rights and freedoms (Art 33).
- Without undue delay to affected individuals where the risk is high (Art 34).
- The notification decision is COUNSEL's; the working assumption (queued at
C19) is documented so the clock is never lost waiting for ratification. - Special weight where proximity/travel data is involved — its re-identification risk raises the likelihood that a breach is "high risk".
Evidence & confidentiality¶
Real incident records (PII, exploit detail) are Tier 2 / restricted — never in
this repo (data-classification-and-handling-policy.md). The git
incident-log.md holds only the process and a non-identifying index; the
post-mortem's non-identifying summary and any resulting control changes are
reflected in the control register.
Readiness¶
A tabletop exercise of at least one scenario (e.g. leaked credential; presence-
data exposure) is run before private beta (M2/M3) to validate the playbook. Until
then SEC-13 is not started — the policy/playbook draft does not make it
operational.
Exceptions¶
There are no pre-approved exceptions to the notification clock. Operational deviations during a live incident are documented in the post-mortem and feed the next policy review.