Privacy Law for Government Contractors

Last reviewed: June 29, 2026

Privacy obligations depend on the contract, the data, and the role

Government contractors often handle information about people: agency employees, service members, veterans, beneficiaries, patients, students, applicants, claimants, program participants, customers, subcontractor personnel, or members of the public. That information may appear in help-desk tickets, case-management systems, eligibility files, research data, call-center notes, background-investigation support, human-resources systems, training records, cloud logs, identity-management tools, or incident-response records.

There is no single privacy law that applies to every contractor in the same way. Applicability depends on the agency, contract language, system, data type, state, sector, performance location, subcontract structure, and the contractor's role. A contractor that merely sells commercial products to an agency may face different privacy obligations than a contractor that operates an agency system of records, processes health information, supports student programs, hosts public-facing forms, or provides cloud services for a government mission.

For GovConCyber purposes, the practical question is not “Which privacy law is famous?” The question is: What privacy duties does this contract, dataset, system, agency relationship, and operating environment create?

Privacy Act work is a special category of contractor risk

The Privacy Act of 1974 can matter when a contractor designs, develops, operates, or supports a system of records on individuals to accomplish an agency function. FAR Part 24 explains that when an agency contracts for the design, development, or operation of a system of records on individuals, the agency must apply Privacy Act requirements to the contractor and its employees working on the contract. FAR 52.224-2 implements that requirement through contract language when the contract specifically identifies the system of records and the work the contractor will perform.

That matters because Privacy Act work is not just ordinary data handling. The contractor may be performing a function that the agency itself would otherwise perform, using records retrieved by personal identifier. The contract may impose restrictions on collection, maintenance, use, disclosure, access, amendment, notices, training, and records practices. Contractors should not assume that possession of agency data automatically makes every dataset a Privacy Act system, but they also should not ignore Privacy Act language when a contract identifies systems of records or agency privacy rules.

Contractor teams should confirm:

• whether the contract identifies a Privacy Act system of records;
• whether the contractor designs, develops, maintains, or operates that system;
• whether employees require privacy training;
• whether the agency has system-of-records notices, handling procedures, or incident instructions;
• whether subcontractors will access or process the records; and
• whether privacy obligations are flowed down and operationalized in system, access, retention, and incident-response processes.

PII is broader than many contract teams think

Personally identifiable information is not limited to Social Security numbers or financial account numbers. Depending on context, PII may include names, addresses, dates of birth, contact information, identifiers, biometrics, login credentials, device identifiers, employment records, health information, education records, location information, case numbers, claim information, or combinations of data that can identify a person.

Government contracts frequently use PII-related terms in clauses, security attachments, privacy impact assessment materials, agency policies, system security plans, records schedules, and incident-reporting instructions. Contractors should treat privacy review as part of contract intake: identify what personal information will be collected or accessed, why it is needed, where it will reside, who can access it, how it will be shared, how long it will be kept, and what happens at closeout.

CUI and privacy often overlap, but they are not the same

Some privacy-sensitive information may also be Controlled Unclassified Information. The CUI Registry includes categories that can capture privacy, health, tax, immigration, law-enforcement, personnel, financial, export-control, and other protected information when a law, regulation, or government-wide policy requires or permits safeguarding or dissemination controls. CUI status changes the safeguarding analysis, but it does not replace privacy analysis.

A contractor may need to ask several questions at once:

• Is the information PII?
• Is it CUI?
• Is it covered defense information under DFARS 252.204-7012?
• Is it protected by a sector law such as HIPAA, GLBA, or FERPA?
• Is it subject to state breach-notification law?
• Is it subject to agency-specific privacy, records, or security instructions?
• Is it subject to contractual limits on use, storage, transfer, subcontracting, or deletion?

The right answer may require both privacy controls and cybersecurity controls. For example, encryption, multifactor authentication, logging, access review, secure disposal, and incident reporting may be cybersecurity requirements, privacy safeguards, contract deliverables, and evidence of responsible risk management.

Sector and state privacy laws may apply through the work being performed

Government-contractor status does not exempt a company from other privacy laws. Depending on the work, a contractor may need to evaluate:

• HIPAA when the contractor handles protected health information for a covered entity, business associate, health plan, provider, or health program.
• GLBA when the work involves financial institutions or covered financial information.
• FERPA when the contractor handles education records for schools or education agencies under conditions that permit contractor access.
• FTC Act risk when a company's privacy or security statements are deceptive or when security practices are alleged to be unfair.
• State privacy and breach laws when personal information about residents is collected, processed, disclosed, or compromised.
• Biometric privacy laws when fingerprints, face geometry, voiceprints, or other biometric identifiers are collected or used.
• State/local contract privacy terms when the customer is a state, local, tribal, territorial, education, or public authority buyer.

The point is not that every law applies to every contractor. The point is that government contracts can put contractors into regulated data roles that they would not otherwise occupy.

Privacy affects cybersecurity program design

A cybersecurity program that protects systems but ignores data rights, minimization, consent, retention, disclosure, and records handling is incomplete for privacy-heavy government work. Contractors should build privacy into security architecture and compliance operations.

Practical design questions include:

• What personal information does the contract actually require?
• Can collection be minimized?
• Can sensitive fields be masked, tokenized, encrypted, segmented, or access-restricted?
• Are privileged users monitored and reviewed?
• Are logs useful for incident response without creating unnecessary privacy exposure?
• Are subcontractors limited to the data needed for their role?
• Are overseas support, remote administration, AI tools, analytics tools, and cloud services permitted for this data?
• Are retention and disposal requirements built into workflows?
• Does the incident-response plan distinguish cyber incidents, privacy incidents, data breaches, and contract notice events?

Breach notification may be contractual, statutory, regulatory, or all three

Privacy incidents can trigger multiple notice paths. A contractor may owe notice to the agency under the contract, to DoD through DIBNet under DFARS 252.204-7012 if covered defense information or covered contractor systems are involved, to affected individuals under state law, to regulators under sector law, to insurers under cyber policies, and to primes or customers under subcontract terms.

Those timelines may not match. Some begin when the contractor discovers an incident; others begin when the contractor reasonably believes an event occurred; others depend on confirmation of unauthorized acquisition or access. Contractors should not wait until the end of a forensic investigation to map reporting obligations.

Subcontractors and tools are part of the privacy boundary

Privacy obligations often fail at the edge: subcontractors, cloud tools, call centers, managed service providers, offshore developers, analytics tools, ticketing systems, AI tools, and temporary staffing. If a third party can access protected information, the contractor should know why, under what authority, under what restrictions, and with what reporting obligations.

Flowdowns should address access limits, use restrictions, security controls, incident notice, return or destruction, audit support, government access, and cooperation with agency or regulatory inquiries. Operationally, prime contractors should maintain a data-flow view that shows where protected information goes and who can touch it.

When to escalate

Contractors should seek legal or agency clarification when:

• the contract references Privacy Act systems, agency privacy rules, or system-of-records notices;
• the data includes sensitive PII, health, financial, education, biometric, law-enforcement, immigration, tax, export-controlled, or personnel information;
• subcontractors, offshore support, AI tools, or non-U.S. hosting may touch protected data;
• breach-notification obligations are unclear or overlapping;
• contract language conflicts with operational practice;
• a proposed use of data goes beyond contract performance; or
• the contractor is preparing representations, certifications, privacy notices, or incident reports.