Privacy impact assessments: when one is required and what it contains

The rule, stated exactly

A privacy impact assessment is a document a federal agency has to produce before it builds or buys information technology that handles personal information about the public. The requirement is statutory, it is older than most of the software your team writes, and it has one property that catches vendors by surprise: the agency owes the document, but the agency cannot fill it out. Most of the questions on the form are answerable only by the people who wrote the code and configured the storage.

The governing text is Section 208 of the E-Government Act of 2002, Public Law 107-347, codified as a note at 44 U.S.C. § 3501. Section 208(b)(1)(A) requires an agency to conduct a privacy impact assessment before two things: developing or procuring information technology that collects, maintains, or disseminates information in identifiable form from or about members of the public, and initiating a new collection of information in identifiable form that will be collected, maintained, or disseminated using information technology, where the collection includes information permitting the physical or online contacting of a specific individual and identical questions are posed to ten or more persons. That ten-person number is borrowed from the Paperwork Reduction Act definition of a collection of information at 44 U.S.C. § 3502(3)(A)(i).

Two more clauses shape the practice. Section 208(b)(1)(B)(ii) requires the assessment to be reviewed by the agency chief information officer or an equivalent official. Section 208(b)(1)(B)(iii) requires the agency to make the assessment publicly available, unless publication would raise security concerns or reveal classified or sensitive information. That last clause is the one most technology vendors have never read. Privacy impact assessments are published documents. The Department of Homeland Security posts hundreds of them. Your data flows, your retention decisions, and your sharing arrangements end up on a public web page carrying your customer's name.

The implementing guidance is OMB Memorandum M-03-22, issued September 26, 2003, which is still the source of the required contents. Around it sit OMB Circular A-130 as revised July 28, 2016, whose Appendix II assigns agency duties for managing personally identifiable information; OMB Circular A-108, issued December 23, 2016, which governs Privacy Act review, reporting, and publication; and OMB M-16-24, issued September 15, 2016, which defines the Senior Agency Official for Privacy who usually signs. NIST SP 800-53 Rev. 5 carries the requirement as control RA-8, and its PT control family, PT-1 through PT-8, covers the transparency, authority, and consent obligations an assessment describes. Section 522 of the Consolidated Appropriations Act, 2005, Public Law 108-447, Division H, added a chief privacy officer designation and an independent third-party privacy review at covered agencies.

Who the obligation actually binds

The statute binds agencies. No clause in the Federal Acquisition Regulation orders a contractor to conduct a privacy impact assessment. That is exactly why so many vendors get ambushed by one. The obligation reaches a technology firm through three doors, and each door has a different lock.

The contract. FAR 24.104 prescribes FAR 52.224-1, Privacy Act Notification, and FAR 52.224-2, Privacy Act, whenever the contract requires the design, development, or operation of a system of records on individuals to accomplish an agency function. FAR subpart 24.3 prescribes FAR 52.224-3, Privacy Training, which requires every contractor employee who handles personally identifiable information, has access to a system of records, or designs, develops, maintains, or operates a system of records to complete privacy training before access and at least annually after. FAR 39.106 prescribes FAR 52.239-1, Privacy or Security Safeguards, on information technology contracts that require them.

The authorization package. Privacy documentation travels with the security package. A threshold analysis and, where triggered, the assessment itself sit alongside the system security plan, and an authorizing official who cannot find them will not sign.

The Privacy Act itself. 5 U.S.C. § 552a(m)(1) says that when an agency provides by contract for the operation of a system of records to accomplish an agency function, the agency shall apply the requirements of the section to that system, and the contractor and its employees are considered employees of the agency for purposes of the criminal penalties at § 552a(i). Under § 552a(i), knowing and willful disclosure of a record to a person not entitled to receive it is a misdemeanor carrying a fine of up to $5,000. Subsection (m)(1) puts contractor staff inside that provision. This is not an abstraction that lives with the general counsel. It reaches the engineer who exports a table.

The threshold question comes first

Before the assessment there is a shorter document that decides whether an assessment is needed at all. DHS calls it a privacy threshold analysis and runs it through the DHS Privacy Office under DHS Directive 047-01. The Department of Veterans Affairs runs the same gate under VA Directive 6508. The Department of Defense performs the assessment itself on DD Form 2930 under DoD Instruction 5400.16. The threshold document is short, often only a few pages, and it asks three things: does the system touch personally identifiable information, is a privacy impact assessment required, and is a system of records notice required.

Those last two answers send a program down very different roads. If the system holds personal information but never retrieves records by a personal identifier, the likely outcome is an assessment and no notice. If the system retrieves records by name, Social Security number, or any other identifier assigned to an individual, the definition of a system of records at 5 U.S.C. § 552a(a)(5) is met, and a system of records notice has to exist and be published in the Federal Register under § 552a(e)(4). OMB Circular A-108 requires agencies to send new and modified notices to OMB and to both houses of Congress at least 30 days before implementation, with a 30-day public comment period for new notices. Those are calendar items, not paperwork items. A team that discovers a missing notice two weeks before go-live has lost a quarter.

M-03-22 also names what falls outside. National security systems are excluded. So are systems that do not collect identifiable information about members of the public, and pilots or evaluations where no identifiable information is collected. Systems holding only federal employee information sit outside the E-Government Act trigger, though many agencies assess them anyway by internal policy, and Circular A-130 Appendix II applies personal-information duties regardless of whose information it is. DHS goes further and extends its privacy policy to non-U.S. persons under Privacy Policy Guidance Memorandum 2017-01. Assume nothing from the statute alone. Read the customer's directive.

What the document contains

Agency templates vary in length and layout. The substance does not vary, because it comes from M-03-22, which fixes seven required contents:

• What information is to be collected
• Why the information is being collected
• The intended use of the information
• With whom the information will be shared
• What notice or opportunities for consent are provided to individuals, including whether consent can be granted for particular uses
• How the information will be secured
• Whether a system of records is being created under the Privacy Act

Agency forms expand those seven into thirty to eighty questions. DD Form 2930 walks through the authority to collect, which must be cited by statute or executive order number rather than described; the purpose; the categories of individuals and of records; the sources of each element; sharing inside the department, with other agencies, and with the public; the notice mechanism; redress procedures; technical and administrative safeguards; retention and disposal under an approved records schedule; and a risk analysis with mitigations. Then the system owner, records officer, chief information officer, and senior agency official for privacy sign it.

Artifact	What triggers it	Who signs	Public
Privacy threshold analysis	Any new or materially changed system	Agency privacy office	No, internal gate
Privacy impact assessment	IT handling identifiable information about the public, per Section 208	CIO or senior agency official for privacy	Yes, agency website
System of records notice	Retrieval by personal identifier, 5 U.S.C. § 552a(a)(5)	Privacy official, then OMB and Congress	Yes, Federal Register
Privacy training records	FAR 52.224-3 in the contract	Contractor, per employee, annually	No, but auditable
Records disposition schedule	Any federal record, 44 U.S.C. § 3303a	Agency records officer plus NARA	Yes, general or agency schedule
Breach response terms	Contractor handling agency personal information, OMB M-17-12	Contracting officer incorporates	No

The artifacts that have to exist before the questions can be answered

An assessment is a summary of things that either exist or do not. The questions that are hard to answer are hard because the underlying engineering was skipped, and privacy offices know it. Six artifacts carry almost all of the weight.

A field-level data inventory. Not "the database holds user records." Every table, column, message field, object-key prefix, and cache entry that holds personal information, with the source of each element and whether it was collected directly from the individual or derived from something else. Most teams do not have this and build it during the review. On a system of ordinary size, budget two to three weeks.

A flow map that crosses trust boundaries. Where personal information enters, where it is transformed, where it rests, and where it leaves. Queues, batch jobs, analytics sinks, the exception report that goes to a distribution list, the one-time extract a program office asked for and now expects monthly.

Retention and disposition with a citation. Data in a federal system is a federal record. 44 U.S.C. § 3303a and 36 CFR part 1225 require records to be scheduled, and NARA's general records schedules already cover many categories; GRS 4.2 covers information access and protection records. "We keep everything" is not a schedule. An assessment that reports indefinite retention with no citation comes back marked.

The subprocessor list. Every downstream service: cloud regions, model providers, geocoding lookups, email and messaging vendors, error-tracking tools. Name, purpose, contract path, and where the data physically sits.

Security controls tied to the record, not to the boilerplate. Encryption in transit and at rest is assumed. Reviewers want role-based access with a documented separation of duties, audit logs that capture reads of personal information and not only writes, and evidence that log retention has its own schedule.

A redress path that is implemented. How does a person learn that the system holds information about them, and what happens when they say it is wrong? Where a system of records notice exists, it names the procedure. The software has to actually perform it.

Common findings

Published assessments, inspector general reviews, and agency privacy offices converge on the same short list of defects. They come from ordinary decisions made without a privacy lens.

• Over-collection. fields captured because they were in the source schema, not because the stated purpose needs them.
• Silent derivation. scores, segments, or inferred attributes created about a person and never disclosed in the notice.
• Production data in lower environments. staging and test seeded from live records, usually with a wider access set than production.
• Unbounded logs. request logs carrying identifiers in query strings, kept longer than the records they describe.
• Training data drawn from operations. model tuning on live case text with no stated authority and no disclosure.
• Missing notice coverage. the system retrieves by identifier and no published system of records notice describes it.
• Retention by neglect. no disposition job, no schedule citation, no deletion anyone can demonstrate.
• Undocumented sharing. a recurring extract to another component or a state partner that nobody wrote down.

What getting it wrong costs

Schedule is the first cost and the largest. A privacy office that discovers a missing system of records notice adds sixty to a hundred and twenty days, because publication and comment run on a calendar and the thirty-day advance submission under Circular A-108 cannot be compressed. On a twelve-month period of performance that is a material fraction of the contract, and the slip lands on the vendor's schedule performance even though the document belongs to the agency.

Liability is the second. The Privacy Act's civil remedy at 5 U.S.C. § 552a(g)(4) allows actual damages with a $1,000 statutory minimum per claimant, plus costs and attorney fees, where agency conduct was intentional or willful. The Supreme Court narrowed that twice. Doe v. Chao, 540 U.S. 614 (2004), held that a plaintiff must prove actual damages to reach the $1,000 floor. FAA v. Cooper, 566 U.S. 284 (2012), held that "actual damages" under the Act excludes mental and emotional distress. The criminal exposure at § 552a(i) is narrower in dollars and wider in reach: up to $5,000 for a knowing and willful improper disclosure, extended to contractor employees by § 552a(m)(1).

Contract terms are the third. OMB M-17-12, issued January 3, 2017, directs agencies to place breach reporting and response requirements in contracts where a contractor handles agency personal information. Reporting windows in those clauses are short, and the clock usually starts on discovery rather than on confirmation. A team that waits to be certain before reporting has already missed the window.

Reputation is the fourth and the longest-lived. Assessments are public. So are the inspector general and GAO reports that cite them. A published document describing indefinite retention, undocumented sharing, and no redress path is a permanent public statement about how a vendor builds software, sitting on a .gov domain.

Where AI components raise the bar

A model inside the system changes what the assessment has to say, because the M-03-22 questions map poorly onto learned systems. "What information is collected" now has to cover training-data provenance. "Intended use" has to cover inference outputs that are themselves new personal information about a person. "How is it secured" has to address memorization and extraction, not only access control. "What notice and consent" has to address whether the people whose records trained the model were ever told.

OMB M-25-21, issued April 3, 2025, sets minimum risk management practices for high-impact agency AI use cases and requires public use-case inventories and designated chief AI officers, with M-25-22 covering acquisition. Neither replaces the privacy impact assessment. Both add a second review asking overlapping questions, and agencies increasingly expect the two sets of answers to agree with each other. NIST's AI Risk Management Framework 1.0, released January 2023, and the NIST Privacy Framework 1.0, released January 2020, supply the vocabulary privacy offices use when they push back.

The practical consequence is short. If a model sits anywhere in the data path, the inventory needs a training-data section listing source, authority or license, date range, and whether records were de-identified before use, and the design needs a written, tested answer to whether the model can emit personal information it was trained on. Note also that privacy information is itself a category in the NARA Controlled Unclassified Information Registry under 32 CFR part 2002, so the handling rules stack.

A practical sequence for a firm meeting this the first time

The sequence below assumes a system of moderate size with one agency customer and no prior privacy documentation. Ranges are working estimates, and the two long poles are the notice determination and the signature chain, neither of which a vendor controls.

Start at step one on the day of award rather than at the security review. The most common scheduling mistake is treating the assessment as an artifact that arrives with the system security plan. By that point the architecture is frozen, and a finding that requires changing what the system collects becomes an expensive change order instead of a design decision that would have cost an afternoon.

Two habits shorten every step. Keep the data inventory in version control beside the code, generated from schema wherever the schema allows it, so it is current instead of reconstructed from memory under deadline. And draft in the customer's template from the first day. Translating an internal privacy memo into DD Form 2930 or a DHS template at the end burns a full review cycle for nothing.

How our team handles this

We treat privacy artifacts as engineering deliverables with the same standing as the code. On the systems we build, the data inventory is generated from schema and checked into the repository, retention is enforced by a scheduled job whose comment carries the schedule citation, the flow map is a diagram we can hand to a privacy office without editing, and the draft answers are written in the customer's own template from the start. Our engineers hold seven cloud certifications between them, and fifteen years of production federal delivery across five consulting firms, three of them federal, sit behind that habit. Packages move faster when the vendor arrives with the evidence already assembled and indexed.

Bottom line

An assessment is required when a federal agency develops or procures information technology that handles identifiable information about members of the public, or starts a new identifiable collection using information technology that reaches ten or more people. The agency signs it. The vendor supplies most of it. It contains seven things fixed by OMB M-03-22, expanded into an agency form, and published. The real work is not the writing. The real work is having a field-level inventory, a flow map, a retention schedule with a citation, a subprocessor list, read-access audit evidence, and a working redress path. Teams that build those during design ship on schedule. Teams that discover them during review lose a quarter.

Frequently asked questions