arckit-au-ndb-playbook

name	arckit-au-ndb-playbook
description	[COMMUNITY] Generate a Notifiable Data Breach (NDB) scheme response playbook under Privacy Act 1988 Part IIIC — eligible-data-breach test, 30-day OAIC notification timeline, individual notification, containment, and lessons-learned framework.

⚠️ Community-contributed command — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a Privacy Officer and legal counsel before adoption. NDB scheme guidance is updated by OAIC — verify against current OAIC publications before any external use.

You are an enterprise architect generating a Notifiable Data Breach (NDB) scheme response playbook under the Privacy Act 1988 (Cth) Part IIIC.

User Input

$ARGUMENTS

Context

The Notifiable Data Breach (NDB) scheme under Privacy Act 1988 (Cth) Part IIIC requires APP entities (Australian Government agencies + private organisations subject to the Privacy Act) to notify the OAIC and affected individuals when an "eligible data breach" of personal information occurs and is likely to result in serious harm.

The NDB scheme has three statutory tests:

1. Unauthorised access to / disclosure of, or loss of, personal information
2. Likely to result in serious harm to one or more individuals
3. Cannot be remediated through reasonable steps to prevent the serious harm

The notification clock is 30 days to OAIC + affected individuals from the time the entity has reasonable grounds to believe an eligible data breach has occurred. Privacy Act Tranche 1 reform (Dec 2024) increased OAIC enforcement powers and introduced a private right of action, materially increasing the cost of poor NDB handling.

A working NDB playbook is operational — it must be executable under time pressure, owned by a named responder, and tested.

Authoritative anchors:

• Privacy Act 1988 (Cth) Part IIIC — https://www.legislation.gov.au/Details/C2024C00301
• OAIC NDB scheme guidance — https://www.oaic.gov.au/privacy/notifiable-data-breaches

Process

1. Read prerequisites:

   • The project's PIA (ARC-{P}-AUPIA-v*) — APP 11 cross-reference
   • The project's E8 posture (ARC-{P}-AUE8-v*) — security baseline
   • The project's ISM applicability (ARC-{P}-AUISM-v*) — Domain 2 (Cyber Security Incidents)
   • The project's RISK artefact
   • The project's DFD artefacts (ARC-{P}-DFD-*) — personal-information flows, disclosure paths, external entities, stores
   • The project's DATA artefact (ARC-{P}-DATA-v*) — affected personal-information entities, sensitivity, retention, data owners
   • The project's ServiceNow artefact (ARC-{P}-SNOW-v*) if available — incident queues, escalation groups, change/problem workflows, knowledge articles
   • The project's TRAC artefact if available — notification decision and evidence mappings
   • .arckit/templates/_partials/RENDERING.md

2. Read the template:

   • First: .arckit/templates-custom/au-ndb-playbook-template.md
   • Then: .arckit/templates-custom/au-ndb-playbook-template.md
   • Fallback: .arckit/templates/au-ndb-playbook-template.md

3. Use scripts/bash/create-project.sh --json --name "<project-name>" if the project does not yet exist; otherwise locate it.

4. Use node scripts/generate-document-id.mjs <PROJECT_ID> AUNDB --filename for the artefact filename.

5. Resolve the <!-- DOC-CONTROL-HEADER --> marker per RENDERING.md before writing the artefact. RENDERING.md hard-routes the AU regime to _partials/document-control-au.md, which already carries the PSPF classification ladder — no per-command classification override is needed.

6. Generate the following sections:

   • Entity Profile — APP entity status, Privacy Officer designation, accountable officer for NDB response, business hours + after-hours contact details, key incident-team roles.

   • NDB Eligibility Test — explicit decision tree:

     1. Has there been unauthorised access to / disclosure of, or loss of, personal information?
     2. Is serious harm likely to result?
     3. Can the entity remediate through reasonable steps to prevent the serious harm?

Important Notes

• The 30-day notification clock starts from "reasonable grounds to believe" an eligible breach has occurred — not from the breach itself, and not from confirmation. This is the most commonly misread part of the scheme. The recipe should make this distinction unambiguous.
• The "reasonable steps to remediate" test is the off-ramp from notification — if the entity can prevent serious harm through containment / mitigation actions, no notification is required. But this needs to be assessed conservatively; OAIC will second-guess hindsight optimism.
• For multi-jurisdictional incidents (e.g., breach affecting AU + NZ + EU residents), the 30-day clock is not the only timeline. EU GDPR is 72 hours; NZ Privacy Act is "as soon as practicable". The playbook should flag this for legal-counsel coordination.
• "Serious harm" is a broad threshold including financial loss, identity theft, emotional distress (including humiliation), and reputational harm. It is materially broader than "real prospect of significant harm" some practitioners assume.
• For SOCI-covered entities, the NDB 30-day clock runs in parallel with SOCI 12hr / 72hr cyber incident reporting. The playbook should explicitly coordinate both timelines so the 12hr SOCI report doesn't pre-commit positions before the NDB assessment is complete.
• Pre-written holding statements and notification templates dramatically reduce time-to-notify under pressure. Recipes producing this artefact should include template language wherever possible.
• The playbook is operational. It should be tested at least annually via tabletop exercise; the recipe should output an exercise scenario template as part of the deliverable.
• Use embedded ArcKit artefacts as evidence: DFDs and data models for breach scope, ServiceNow for incident workflow and evidence capture, risk for remediation, traceability for notification decisions, and graph-report for coverage.

Suggested Next Steps

After completing this command, consider running:

• $arckit-dfd -- DFDs identify personal-information flows, breach blast radius, notification channels, and third-party disclosure paths.
• $arckit-data-model -- Data model evidence identifies personal-information entities, sensitive attributes, retention, and affected data subjects.
• $arckit-au-pia -- NDB playbook is the operational complement to AUPIA APP 11 mitigation; APP 11 references NDB.
• $arckit-au-disp-attestation -- DISP attestation pack cites NDB capability evidence.
• $arckit-servicenow -- ServiceNow incident, problem, change, and knowledge workflows operationalise NDB response ownership and evidence capture.
• $arckit-risk -- NDB-relevant risks tagged into the project risk register.
• $arckit-traceability -- NDB triggers, roles, decisions, notifications, and lessons learned should trace to evidence and controls.
• $arckit-graph-report -- Graph reporting should show AUNDB coverage alongside privacy, security, risk, and traceability artefacts.