Skip to content

Incident response + breach notification

The ecosystem-wide playbook for security incidents and the path to NDPC breach notification.

NDPA §40 + GAID 2025 require notification to NDPC within 72 hours of becoming aware of a personal-data breach, and notification to affected data subjects "without undue delay" if there's high risk to their rights.

Definitions

  • Security incident: any event suggesting unauthorised access, alteration, or destruction of data — irrespective of impact. Includes near-misses.
  • Personal-data breach: a confirmed incident that compromises confidentiality, integrity, or availability of personal data.

Every breach is an incident; not every incident is a breach.

On-call + escalation

  • Each product owns its first-line on-call for product-specific incidents. Documented in each product's security.md.
  • Cross-cutting / multi-product / ZevID-level incidents escalate to the DPO + Engineering Lead (named below).
  • DPO: see policies/dpo.md.

Phases

1. Detect

Sources of detection:

  • Application errors / unexpected error spikes (Sentry-equivalent + uptime monitoring).
  • Anomalous auth patterns (login_events table review, account-lockout spikes).
  • Anomalous ZPIP calls (zpip_token_log patterns).
  • External reports (security researcher disclosure, partner notification, user complaint).

2. Triage (within 1 hour of detection)

Engineering Lead + product on-call meet to assess:

  • Confirmed unauthorised access? Yes → potential breach.
  • Personal data involved? Which categories?
  • Estimated scope (how many users, what data fields)?
  • Containment options.

Decision: incident or breach?

3. Contain (immediate, before 24 hours)

  • Revoke compromised credentials, tokens, sessions.
  • Patch the vulnerability or block the attack path.
  • Preserve forensic evidence (DB snapshots, logs).
  • Note: containment takes priority over notification — get the bleeding stopped first.

4. Notify (the 72-hour clock)

If confirmed breach:

  • NDPC notification: filed within 72 hours of becoming aware (not 72 hours of breach occurring). DPO drafts; Legal reviews; Engineering Lead provides technical detail.
  • Data subject notification: only required if high risk to rights (large volume, sensitive categories, financial impact). Drafted by DPO + Comms.

Template notifications live in docs/policies/breach-notification.md (TBD — DPO to author; pending entry in Policies index).

5. Remediate + post-mortem

  • Root cause analysis.
  • Permanent fix shipped + verified.
  • Post-mortem document filed with the DPO.
  • Per-product change-log.md updated if controls changed as a result.

The 72-hour clock — operational details

The clock starts the moment a Zev staff member becomes aware of "facts indicating a personal-data breach has occurred." Awareness = reasonable suspicion, not confirmation.

If we're not sure whether to notify:

  • Default to notifying. Late notification is worse than over-notification.
  • DPO has discretion to delay if assessment is genuinely ongoing — but the delay is recorded with reasoning.

Records

Every incident (breach or not) gets a record:

  • Date of detection.
  • Source of detection.
  • Triage decision (incident vs breach).
  • Scope (users affected, data categories).
  • Notifications made (NDPC, subjects, dates).
  • Resolution + post-mortem reference.

Records are retained 7 years. NDPC may audit them.

Drills

Cadence TBD. Each product participates in a tabletop drill at least once per year. DPO observes.