SA-4(11): System of Records

SA-4(11) sits in the System and Services Acquisition (SA) family, so exams tend to look for one thing: proof that privacy requirements are baked into third-party contracting before work starts. The control is narrow but high-impact. If a third party operates a system of records on your behalf, missing contract language can leave you without enforceable rights to require Privacy Act-aligned handling, reporting, and restrictions, even if your internal policies say all the right things.

This page is written for a Compliance Officer, CCO, or GRC lead who has to operationalize SA-4(11) quickly across procurement, legal, privacy, and the system owner community. You’ll translate the requirement into (1) a clear applicability test, (2) standard contract language and templates, (3) a contracting workflow gate, and (4) a minimum evidence bundle that stands up in audits and customer diligence.

Where teams get stuck is not the clause drafting. It’s governance: identifying which buys are actually “system of records” operations, preventing bypasses (purchase cards, task orders, renewals), and keeping evidence consistent across contracts and modifications.

Regulatory text

NIST SP 800-53 SA-4(11) excerpt: “Include [Privacy Act requirements] in the acquisition contract for the operation of a system of records on behalf of an organization to accomplish an organizational mission or function.” ¹

What the operator must do:
If you engage a third party to operate a system of records for your organization (for example, running the platform, processing records, handling user requests, maintaining the application), your acquisition contract must include Privacy Act requirements. Treat this as a hard contracting requirement: the Privacy Act terms must appear in the executed contract (or executed modification) that authorizes the work. ¹

Plain-English interpretation (what SA-4(11) really means)

SA-4(11) is a “put it in the contract” control. Your privacy program cannot rely on policy-only obligations when a third party is operating a system of records for your mission. You must convert privacy requirements into enforceable contract terms, then prove you did it for every in-scope acquisition action (new award, renewal, extension, major modification).

From an audit perspective, SA-4(11) is usually evaluated through contract file inspection. Auditors will not infer compliance from templates or procurement SOPs. They will ask to see the executed agreement for the specific in-scope system and confirm the Privacy Act requirements are included.

Who it applies to (entity and operational context)

Applies to:

• Federal information systems where the organization has a “system of records” and delegates operation to a third party. ¹
• Contractor systems handling federal data where the contractor operates the system of records on behalf of the organization to accomplish a mission or function. ¹

Operational contexts that commonly trigger SA-4(11):

• Managed service providers operating an application that stores and retrieves records about individuals.
• A SaaS provider contracted not only to host, but to operate workflows that create, update, and retrieve records in response to agency processes.
• Call centers or BPO providers running case management platforms for benefits, HR, or enforcement programs.

Common “gray area” to resolve early: hosting vs. operating. If the third party performs operational functions for the system of records (administration, configuration, processing, handling requests), treat it as in-scope and require the clause package.

What you actually need to do (step-by-step)

Step 1: Establish an applicability test you can run in intake

Create a simple intake decision that procurement and system owners can answer consistently:

SA-4(11) applicability questions

1. Does the system contain records that are retrieved by a personal identifier (name, ID number, etc.) as part of normal operations (system of records concept)?
2. Will a third party operate any part of that system on our behalf (not just sell licenses)?
3. Is the work supporting an organizational mission or function (not a purely internal demo or trial)?

If “yes” to (2) and the system meets your organization’s definition of a system of records, SA-4(11) is triggered and the acquisition must include Privacy Act requirements. ¹

Practical tip: put these questions in the PR/PO intake form so you can prove the determination was made.

Step 2: Define your “Privacy Act requirements” clause package

SA-4(11) does not list the exact clauses in the excerpt you were given, so operationally you should define a standard clause package your legal/privacy team approves for system-of-records operations. Keep it modular so it can be inserted into contracts, task orders, and modifications.

A workable clause package usually covers:

• Processing limitations (operate only per written instructions)
• Restrictions on use/disclosure and onward transfer to subcontractors
• Incident reporting and cooperation expectations
• Access controls, audit/inspection support, and recordkeeping
• Data return/disposition at end of service
• Flow-down requirements to subcontractors supporting operations

Your goal is repeatability: the same baseline requirements across all in-scope buys, with tracked deviations.

Step 3: Put a procurement gate in front of award and renewal

Make SA-4(11) a blocking control in the acquisition workflow:

• Trigger events: new award, renewal, extension, option exercise, major scope change, and any modification adding operational responsibilities for an in-scope system.
• Required approvers: Privacy Officer (or privacy counsel), Contracting Officer/Legal, and System Owner (business owner).
• Pass/fail criteria: contract contains the approved Privacy Act clause package (or an approved exception with compensating terms).

This is where teams fail audits: they have the clauses “available,” but there is no enforced gate that prevents an award without them.

Step 4: Build an exception process that auditors can tolerate

You will get requests like “the provider won’t accept the clause” or “we’re using a reseller.” Handle this with an exception memo:

• What requirement is being varied
• Why (commercial constraint, statutory conflict, etc.)
• Risk assessment and compensating controls (for example, tighter operational oversight or a different clause that achieves the same outcome)
• Approval by privacy/legal and the accountable executive

Do not let exceptions live in email threads. Put them in the contract file.

Step 5: Implement “control health checks” so it stays true over time

SA-4(11) is easy to implement once and then drift out of compliance as renewals and new task orders happen. Set a recurring check:

• Sample executed contracts for each in-scope system
• Confirm the clause package is present in the latest executed version (including mods)
• Track gaps to closure with due dates and named owners

Daydream (or any GRC system you already run) is most helpful here as a lightweight control card plus evidence tasking: you assign ownership, define trigger events (award/renewal/mod), and attach the executed contract and approvals as the required evidence bundle.

Required evidence and artifacts to retain

Auditors and customer assessors typically want contract-file proof, not policy statements. Maintain a minimum evidence bundle per in-scope acquisition:

Evidence bundle ¹

• Completed intake / applicability determination (the answers to the scoping questions)
• Executed contract (or executed modification) containing the Privacy Act requirements
• Redlines or negotiation record showing how the final language was agreed (optional but helpful)
• Approval record from privacy/legal and contracting
• Exception memo(s), if any, with compensating controls and approvals
• A contract inventory entry mapping: system name, system owner, third party, contract vehicle, effective dates, and where the executed version is stored

Retention location: one system of record for contracts (contract repository) plus a GRC evidence link. The main failure mode is scattering evidence across email, shared drives, and ticketing systems.

Common exam/audit questions and hangups

Expect these questions and pre-build your answers:

• “Show me the executed contract for System X and point to the Privacy Act requirements.” ¹
• “How do you decide whether an acquisition is operating a system of records?”
• “What prevents a program team from awarding without privacy review?”
• “How do you handle contract renewals and option years?”
• “Show exceptions and who approved them.”
• “Do subcontractors get the same obligations?” (via flow-down language you control in the clause package)

Hangups that slow audits:

• The organization has a template, but cannot show it was used for the sampled contract.
• The contract includes privacy language, but it is generic and not tied to system-of-records operations.
• Modifications added operational services after award, but the privacy terms were never updated.

Frequent implementation mistakes (and how to avoid them)

1. Treating SA-4(11) as a privacy policy task instead of a procurement control.
   Avoidance: make the contract clause package and review gate mandatory for award.

2. Scoping only “systems that store PII” rather than “systems of records operated on our behalf.”
   Avoidance: require the intake to ask about operation and retrieval/record use, not just data type.

3. Forgetting task orders, renewals, and modifications.
   Avoidance: define trigger events explicitly and tie them to contract lifecycle milestones.

4. Letting exceptions be informal.
   Avoidance: written exception memo, stored in the contract file, with approvals.

5. No evidence standard, so every team “documents differently.”
   Avoidance: publish the minimum evidence bundle and enforce it via procurement closeout.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this control. The practical risk is still real: if a third party mishandles records in an in-scope system and your contract lacks Privacy Act requirements, you may have limited contractual remedies, weaker audit rights, and slower incident response. SA-4(11) is designed to prevent that preventable governance failure by making privacy obligations enforceable at the point of purchase. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize)

• Name an owner for SA-4(11) (privacy + procurement joint ownership works well).
• Draft the applicability questions and add them to purchase intake.
• Create the baseline Privacy Act clause package with legal/privacy approval.
• Identify your initial in-scope inventory: systems of records with third-party operators and their contract vehicles.

Days 31–60 (operationalize)

• Add a workflow gate: procurement cannot finalize an award/renewal without the clause package or an approved exception memo.
• Train contracting and program teams on the applicability test and what “operate on behalf of” means in your environment.
• Define the evidence bundle and storage location, then backfill evidence for the highest-risk in-scope contracts.

Days 61–90 (prove it runs)

• Run a control health check: sample recent awards/renewals/mods and confirm the executed language is present.
• Remediate gaps through contract modifications or addenda where feasible.
• Stand up ongoing reporting: in-scope contract count, reviewed vs. pending, exceptions, and remediation status.

Frequently Asked Questions

Does SA-4(11) apply to all third-party software purchases that touch personal data?

It applies when the third party is contracted to operate a system of records on your behalf to perform a mission or function. A simple license purchase may be out of scope, but managed operation or processing services often bring it into scope. ¹

What counts as “operation of a system of records” in practice?

If the third party administers the system, processes records, runs workflows, supports retrieval and updates, or performs ongoing operational tasks beyond selling software, treat it as operation. If you cannot defend the distinction in an audit, scope it in and require the clause package. ¹

Where should the Privacy Act requirements live: MSA, DPA, or SOW?

Put them in the executed agreement structure that governs performance and can be enforced for the operational work (often the MSA plus SOW/task order). The key is that the executed contract for the in-scope work includes the requirements. ¹

What if the third party refuses the Privacy Act clause language?

Use a formal exception memo with legal/privacy approval, document compensating controls, and store it in the contract file. Avoid undocumented “we tried” outcomes; auditors look for approved risk acceptance and enforceable substitutes. ¹

How do we handle subcontractors supporting the prime contractor?

Your clause package should require flow-down of applicable privacy obligations to subcontractors involved in operating the system. Then confirm the prime’s subcontracting terms or attestations during oversight. ¹

What evidence is most persuasive in an audit?

The executed contract (and any modifications) showing the Privacy Act requirements, plus the procurement intake showing the scoping decision and approvals. Templates alone rarely satisfy an examiner if the sampled contract is missing the language. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON