Privacy impact assessments before launching a new agency system

Reference article · 5 min read

A privacy impact assessment is a written analysis of what a system does with personal information, completed before the system holds any. It overlaps with a security review but asks a prior question. Security asks whether data is protected from people who should not have it. A privacy assessment asks whether the agency should collect the data at all, who will see it, how long it will exist, and what residents are told about it.

The practice has federal roots. Section 208 of the E-Government Act of 2002 directs federal agencies to conduct privacy impact assessments for systems that collect information in identifiable form, and most published templates descend from it. State and local requirements are far less uniform. Some states run a central privacy office with a mandatory process, some cities and counties require one only for surveillance technology, and many agencies have no written requirement at all. Confirm your obligations with counsel, your records officer, and state policy before treating any template as sufficient.

The questions a good assessment answers

What is collected, element by element. Not "resident contact information" but the actual fields: name, date of birth, address, driver license number, photograph, location, device identifier. Include free text fields and attachments, because staff will put sensitive information in them. Note the source of each: the resident, another agency, a commercial data source, or the system's own matching.
Why each element is needed. Tie every field to a program or legal purpose. Fields that exist only because the product ships with them cost nothing to turn off before go-live.
Who can see it. Roles inside the agency, support staff at the vendor, and anyone reached through an integration. "Everyone with a login" is a finding, not an answer.
Who it is shared with. Other departments, other jurisdictions, state and federal partners, and any recipient named in a sharing agreement, with the instrument authorizing each flow.
How long it is kept, and what disposal means. Disposal covers backups, audit logs, exports on staff workstations, and vendor copies.
What notice residents receive. The form language, the website privacy notice, the sign at a counter or on a pole.

Retention and public records exposure

Retention is where new systems drift away from policy. State records schedules set how long records must be kept and often when they should be destroyed, while software tends to default to keeping everything indefinitely. Ask whether the product can delete on a schedule, whether deletion works record by record or only in bulk, and whether deleted data clears backups within a defined window.

Public records exposure is the companion question. What an agency collects is presumptively disclosable under state open records law unless an exemption applies, and exemptions differ by state and record type. A camera system, permit portal, or case management platform can create a request workload nobody budgeted for. The assessment should name the exemptions the agency expects to rely on and confirm the system can search, export, and redact well enough to answer one.

Making the assessment a gate, not a memo after go-live

Threshold screen at intake. A one page form asking whether the effort touches personal information. A "yes" triggers the full assessment.
Privacy requirements in the solicitation. Ask for the data inventory, hosting locations, subprocessors, deletion behavior, and audit logging as requirements, not scored extras.
Draft the assessment during evaluation. Use the finalists' actual answers. Gaps found here are still negotiable.
Sign-off before go-live. The system owner, counsel, the records officer, and the security lead sign. Configuration that contradicts the assessment gets fixed first.
Reassess on defined triggers. A new integration, a new data element, a new sharing agreement, a new analytics or AI feature, or a change in hosting.

What to ask vendors and what to require in the contract

A data dictionary. Every field the product stores, including ones the agency will not use.
Named subprocessors and hosting locations. Including support, analytics, and any subcontractor that can reach production data.
Deletion mechanics. Scheduled deletion, legal hold, and a stated timeline for clearing backups.
Limits on vendor use. No secondary use, no resale of de-identified data, no training of models on agency data without written permission.
Vendor access and logging. How support staff reach agency data, under what approval, and whether the agency sees those logs.
Audit logs the agency can read. Who viewed which record, kept long enough to investigate a complaint.
Breach notification and exit terms. A defined notice period, return of data in a usable format, and certified destruction of vendor copies.

Proposal language is not binding. Move the answers that matter into the contract or an attached data protection exhibit.

Where requirements differ, and how to start

Rules follow the data type as much as the jurisdiction. Criminal justice information carries CJIS Security Policy obligations, health information may fall under HIPAA, student records under FERPA, motor vehicle records under the Driver's Privacy Protection Act, federal tax information under IRS Publication 1075, and substance use disorder treatment records under 42 CFR Part 2. Surveillance technology ordinances in some cities and counties separately require a published use policy and governing body approval before acquisition. With no template of its own, an agency can borrow structure from the NIST Privacy Framework or the Fair Information Practice Principles. These authorities change, so verify current text with the official source and your counsel.

Start with the threshold form and one completed assessment on a project already in flight, reusing the security questionnaire, the retention schedule, and the sharing agreements on file. Keep a register of finished assessments so the next team has an example.

HQT works with state and local agencies on system design, integration, and procurement support, including documenting data flows, access, and retention behavior before a platform goes live.

Frequently asked questions

What is the difference between a privacy impact assessment and a security assessment?

A security assessment examines controls: authentication, encryption, patching, monitoring, and whether the system resists attack. A privacy impact assessment examines the data itself: what is collected, why, who can see it, who it is shared with, how long it is kept, and what residents are told. The two overlap on access control and logging, and many agencies run them on the same schedule, but one does not substitute for the other.

Are state and local agencies required to complete privacy impact assessments?

It depends on the state, the agency, and the type of data. Section 208 of the E-Government Act of 2002 imposes the requirement on federal agencies, and some states have adopted comparable requirements through statute or statewide IT policy, while many local agencies have only internal policy or none at all. Some cities and counties also require an assessment specifically for surveillance technology before acquisition. Confirm the current requirement with your counsel and your state privacy or IT office.

When should a privacy impact assessment be done during a procurement?

Screen at project intake to decide whether an assessment is needed, put the privacy questions into the solicitation as stated requirements, and draft the assessment during evaluation using the finalists' actual answers. Anything unacceptable found at that point is still negotiable, and gaps found after award usually are not. The signed assessment should be a condition of go-live.

Who signs off on a privacy impact assessment?

Typically the system owner or program manager who is accountable for the data, plus agency counsel, the records officer or retention authority, and the security lead. Agencies with a privacy officer route it through that office as well. The value of multiple signatures is that retention, disclosure, and legal authority each get reviewed by the person who will answer for them later.

Does the assessment need to be updated after the system goes live?

Yes, on defined triggers rather than on a calendar alone. Common triggers include a new integration, a new data element, a new data sharing agreement, a new analytics or AI feature, and a change in where the vendor hosts or processes the data. Recording the trigger list in the original assessment makes the update obligation clear to whoever inherits the system.