| name | arckit-au-pia |
| description | [COMMUNITY] Generate a Privacy Impact Assessment (PIA) for Australian Government entities under Privacy Act 1988 s33D, assessing compliance with all 13 Australian Privacy Principles (APPs). |
⚠️ Community-contributed command — not part of the officially-maintained ArcKit baseline. Output should be reviewed by a qualified Privacy Officer, DPO, or legal counsel before reliance. Citations to the Privacy Act 1988 and OAIC guidance may lag current amendments — verify against the source. The Privacy Act 1988 reform (Tranche 2) is under development — monitor for changes.
You are an enterprise architect generating a Privacy Impact Assessment (PIA) for an Australian Government entity or regulated-sector organisation under the Privacy Act 1988 (Cth).
User Input
$ARGUMENTS
Context
Australian Government agencies covered by the Privacy Act 1988 must conduct PIAs for projects that involve new or changed handling of personal information. Section 33D requires agencies to conduct a PIA for all high-privacy-risk activities. The OAIC (Office of the Australian Information Commissioner) publishes the Guide to undertaking privacy impact assessments, which defines the methodology.
Authoritative anchors:
Key Privacy Act 1988 Reform Context:
- Tranche 1 effective December 2024 — enhanced enforcement powers, tiered penalties, private right of action
- AI decision-making notification required from December 2026
- Tranche 2 under development — ~93 remaining proposals from Attorney-General's review
- Small business exemption changes from 1 July 2026
Process
-
Read prerequisites:
projects/000-global/ARC-000-PRIN-*.md (architecture principles, if present)
- The project's REQ artefact — extract data requirements (DR-), NFR-SEC requirements, integration requirements (INT-)
- The project's DATA artefact — extract entity model, PII fields, data flows
- The project's DFD artefacts (
ARC-{P}-DFD-*) — collection, use, disclosure, transfer, retention, and disposal flows
- The project's STKE artefact — extract data subjects, stakeholder privacy expectations
- The project's RISK artefact if available — existing privacy, security, and compliance risks
- The project's TRAC artefact if available — requirement-to-APP-to-control mappings
.arckit/templates/_partials/RENDERING.md
-
Read the template:
- First, check
.arckit/templates-custom/au-pia-template.md (user override)
- Then,
.arckit/templates-custom/au-pia-template.md
- Fallback,
.arckit/templates/au-pia-template.md
-
Use scripts/bash/create-project.sh --json --name "<project-name>" if the project does not yet exist; otherwise locate it.
-
Use node scripts/generate-document-id.mjs <PROJECT_ID> AUPIA --filename for the artefact filename.
-
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.
-
Generate the following sections:
-
Project Description — what the project does, what personal information is involved, why it is needed, who the data subjects are, estimated data volumes.
-
Information Flows — Mermaid data flow diagram showing: collection points, storage locations, processing activities, sharing/disclosure, cross-border transfers, retention/disposal. Mark each flow with the APP that governs it.
-
13 APP Compliance Assessment — one assessment block per Australian Privacy Principle:
- APP 1 — Open and transparent management of personal information
Important Notes
- This is the Australian PIA, not the UK DPIA. The Privacy Act 1988 and 13 APPs replace GDPR and its data protection principles. Do not reference GDPR, ICO, or UK data protection law.
- APP 8 (Cross-border disclosure) is particularly important for cloud-hosted systems — data stored in overseas cloud regions triggers APP 8 obligations even if the cloud provider has Australian data centre options.
- APP 11 (Security) should cross-reference the E8 posture assessment if one exists — the E8 maturity level directly indicates the strength of the "reasonable steps" taken to protect personal information.
- The Privacy Act reform Tranche 1 (December 2024) introduced a private right of action — this materially increases the risk of non-compliance.
- For agencies subject to the Privacy (Australian Government Agencies — Governance) APP Code, additional governance requirements apply (privacy champions, privacy management plans, annual reporting).
- Use embedded ArcKit artefacts as evidence: DFDs for information flows, data models for APP-relevant entities and retention, risk for privacy harms, traceability for APP-control lineage, and graph-report for coverage.
Suggested Next Steps
After completing this command, consider running:
$arckit-dfd -- DFDs identify personal-information collection, use, disclosure, cross-border transfer, and retention flows.
$arckit-data-model -- Data model evidence identifies APP-relevant entities, sensitive information, identifiers, owners, retention, and access controls.
$arckit-au-dss -- PIA findings feed DSS Criterion 7 (Protect users' privacy).
$arckit-au-e8-posture -- APP 11 (security of personal information) informs E8 target maturity level.
$arckit-risk -- Privacy risks surface in the project risk register.
$arckit-traceability -- APP obligations and privacy mitigations should trace to requirements, data entities, risks, and controls.
$arckit-graph-report -- Graph reporting should show AUPIA coverage alongside data-model, risk, traceability, and AU compliance artefacts.