A short AI-narrated film with English captions. Pressing play loads the YouTube player. Watch on YouTube
Overlay: USA Federal Civilian Community Overlay | ArcKit Version: [VERSION]
/arckit:us-privacy-pia produces a federal Privacy Impact Assessment under §208 of the E-Government Act of 2002 and OMB M-03-22. It scopes the personal information lifecycle, applies the Fair Information Practice Principles (FIPPs), captures the Privacy Act of 1974 system-of-records analysis (SORN trigger / coverage / amendment), aligns with NIST SP 800-122 PII handling guidance, and surfaces the AI-specific notice obligations introduced by OMB M-24-10.
The PIA is mandatory when an agency develops or procures information technology that collects, maintains, or disseminates personally identifiable information, or when it initiates a new electronic collection of PII from 10 or more members of the public. It is the artefact that the agency SAOP signs and that is published for public consumption — a missing or incomplete PIA is a Senior Agency Official for Privacy finding.
The doc-type code is USPIA because the plain PIA code is taken by the Canadian overlay (ca-pia).
Reviewed by the SAOP, the System Owner, the agency Privacy Office, General Counsel where SORN triggers are uncertain, and the agency Chief AI Officer where AI is in scope.
Inputs
| Artefact | Purpose |
|---|---|
Requirements (ARC-<id>-REQ-v1.0.md) |
Service description, data requirements (DR-*) |
Data Model (ARC-<id>-DATA-v*.md) |
Entities carrying PII, relationships, retention |
Stakeholders (ARC-<id>-STKE-v1.0.md) |
Subject populations, partner agencies, processors |
Architecture Principles (ARC-<id>-PRIN-v1.0.md) |
Privacy-by-design posture |
Output
- Doc-type:
USPIA - Filename:
ARC-<PID>-USPIA-v1.0.md(project root, single-instance)
Process Overview
- Confirm PIA trigger per E-Gov §208 (new IT with PII; new electronic collection from ≥10 members of the public).
- Build the PII inventory — types, sources, uses, recipients, retention, disposal.
- Apply the FIPPs to the system's data flows.
- Run the Privacy Act SORN analysis — does the system constitute a System of Records? Existing SORN? New / amended SORN required?
- Where AI is in scope, layer the M-24-10 AI-specific notice obligations.
- Route for SAOP signature and public publication.
Regulatory Anchors
- E-Government Act of 2002 §208 — https://www.justice.gov/opcl/e-government-act-2002
- OMB M-03-22 — https://www.whitehouse.gov/wp-content/uploads/2017/11/203-M-03-22-OMB-Guidance-for-Implementing-the-Privacy-Provisions-of-the-E-Government-Act-of-2002-1.pdf
- Privacy Act of 1974 (5 U.S.C. §552a) — https://www.justice.gov/opcl/privacy-act-1974
- NIST SP 800-122 — https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-122.pdf
Example Usage
/arckit:us-privacy-pia 001-citizen-benefits-portal
Common Pitfalls
- Missing SORN trigger when adding a new System of Records. If you can retrieve a record by an individual identifier, you have a System of Records — and the Privacy Act requires a SORN. Treat new SoR creation as a delivery gate.
- Failing to publish the PIA. The PIA is a public document under §208. Internal-only retention is non-compliance.
- Ignoring AI-specific notice obligations. M-24-10 layers additional notice on top of FIPPs notice where AI is involved — these are not interchangeable.
- Confusing PIA with PTA. A Privacy Threshold Analysis is a screen; the PIA is the substantive assessment. Stopping at the PTA when the PIA is required is a common shortcut that fails on review.
Handoffs
us-icam— IAL choice and federation attributes feed PII inventoryus-ai-impact— AI notice obligations carry across both artefactsdata-model— PIA PII inventory must reconcile with the data model