PT-6(2): Exemption Rules

PT-6(2): Exemption Rules requires you to periodically review every Privacy Act exemption your system of records claims, confirm each exemption is still lawful and necessary, verify it was issued through regulation, and ensure the exemption is correctly described in the System of Records Notice (SORN) ¹. Operationalize it by maintaining an exemption inventory, a repeatable legal/regulatory validation check, and evidence that your SORN stays aligned.

Key takeaways:

• Keep a current list of all claimed Privacy Act exemptions per system of records, tied to the SORN ¹.
• Validate that each exemption is still appropriate, still necessary, and actually promulgated as a regulation ¹.
• Treat SORN accuracy as a control outcome, not a documentation afterthought ¹.

PT-6(2): exemption rules requirement is a privacy governance control that sits at the boundary of legal authority and operational reality. Teams often document “we claim exemptions” once during initial system onboarding, then never revisit whether the exemptions still fit how the system works today. That gap is what this control targets.

The requirement is narrow but operationally demanding: you must review the exemptions your system of records claims and prove three things. First, the exemptions remain appropriate and necessary under law. Second, the exemptions were promulgated as regulations. Third, the exemptions are accurately described in the system’s SORN ¹. For a CCO, GRC lead, or privacy program owner, the goal is straightforward: make exemption claims traceable, reviewable, and auditable.

This page gives you requirement-level implementation guidance you can put into a control procedure quickly: who owns what, how to run the review, what to save as evidence, and what auditors typically challenge. It also includes a practical execution plan and the failure modes that cause rework during assessments.

Requirement: PT-6(2) Exemption Rules (what it means)

You must perform a recurring review of all Privacy Act exemptions claimed for a system of records to confirm:

1. the exemptions remain appropriate and necessary in accordance with law,
2. the exemptions have been promulgated as regulations, and
3. the exemptions are accurately described in the System of Records Notice (SORN) ¹.

This is not a one-time documentation task. The control expects you to show that exemptions are continuously justified as the system’s purpose, data uses, interfaces, and sharing patterns evolve.

Regulatory text

“Review all Privacy Act exemptions claimed for the system of records … to ensure they remain appropriate and necessary in accordance with law, that they have been promulgated as regulations, and that they are accurately described in the system of records notice.” ¹

Operator translation: maintain a documented review workflow that (a) checks the legal basis and necessity of each exemption, (b) confirms the exemption is backed by an actual regulation (not a preference or legacy statement), and (c) reconciles what you claim internally with what the SORN says publicly.

Who it applies to (entity + operational context)

Entity types in scope:

• Federal information systems
• Contractor systems handling federal data ¹

Operational context that triggers PT-6(2):

• You have a “system of records” subject to the Privacy Act and publish (or support publication of) a SORN.
• The system claims one or more Privacy Act exemptions (full or partial) for categories of records, use cases, or functions.
• You change system functionality, data sources, matching activities, disclosures/routine uses, retention, or access pathways in ways that could affect whether an exemption is still appropriate.

Typical control owners (pick and document one accountable owner):

• Privacy Officer / SAOP / Chief Privacy Officer
• System Owner (accountable for system behavior and documentation accuracy)
• Agency counsel or privacy counsel (approver for “appropriate and necessary” determinations)
• Records management lead (input to retention/disposition changes that may affect the rationale)

Plain-English interpretation (what examiners want to see)

Assessors generally look for four outcomes:

• Completeness: you can name every exemption claimed by the system of records and where it appears in the SORN.
• Validity: each exemption ties to a regulatory basis and is not “informal.”
• Continued fit: the exemption still matches the system’s actual use and disclosures, not a legacy architecture.
• Accuracy: the SORN description is current, consistent, and specific enough to match practice ¹.

If any of these fail, teams end up with “paper exemptions” that do not hold up during a privacy review, incident response, FOIA/PA requests, or an assessment.

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

Step 1: Create an exemption inventory per system of records

Build a single table (spreadsheet, GRC tool, or system register) with at least:

• System of records name and owner
• SORN identifier and current publication date/version
• Each claimed exemption (full/partial, by record category if applicable)
• Where the exemption is described in the SORN (section/page/paragraph reference)
• “Promulgated as regulation” reference (cite the exact regulatory instrument internally)
• Rationale summary: why it is appropriate and necessary for the system’s purpose
• Last review date, reviewers, approval authority, next review trigger

Practical note: Many programs track exemptions at a program level. PT-6(2) is system-of-records specific. Your inventory must tie exemptions to the SORN for that system ¹.

Step 2: Define review triggers (don’t rely only on a calendar)

Your procedure should require a review when any of these change:

• New data sources, new data elements, or new matching/linking
• New routine uses/disclosures or new third-party sharing
• Material workflow changes (case management, investigations, identity resolution)
• New access populations (contractors, partners, new agency components)
• Changes to retention schedules or disposition practices

Keep one “standing” periodic review as well, but make change-driven reviews mandatory because they are easier to defend in an audit and catch drift earlier.

Step 3: Run the exemption review using a short decision checklist

For each exemption, collect inputs and answer:

1. Is it still legally available for this system/record category? Document counsel’s position in a memo or approval record.
2. Is it still necessary and appropriate for how the system operates now? Tie the rationale to current data uses and disclosure paths.
3. Was it promulgated as a regulation? Confirm the exemption is backed by the appropriate regulatory action and you can point to it in your internal package.
4. Does the SORN accurately describe it? Reconcile the SORN language to the current exemption claim and the actual system behavior ¹.

If any answer is “no,” open a tracked remediation item: update SORN, stop claiming the exemption, or adjust practices to match the claimed exemption. Avoid “we’ll fix later” with no ticket or due date; that is where assessors mark the control ineffective.

Step 4: Update the SORN or internal claims, then close the loop

PT-6(2) explicitly requires accurate SORN description ¹. Your change control should ensure:

• Draft updates are reviewed by privacy + counsel + system owner.
• Publication steps and effective dates are tracked.
• The system owner confirms operational alignment (what the system does matches the SORN).

Step 5: Make it auditable (package evidence on a per-system basis)

Create a “PT-6(2) evidence packet” per system of records with consistent naming. This reduces scramble during assessments.

Where Daydream fits naturally: Daydream can track control ownership, link exemption inventory entries to SORN artifacts, and produce a repeatable evidence packet for PT-6(2) so you are not rebuilding the trail every review cycle.

Required evidence and artifacts to retain

Keep artifacts that prove both design (you have a process) and operation (you ran it and acted on results):

Core artifacts

• Exemption inventory (current) with ownership and review metadata
• Written procedure/SOP for exemption reviews and triggers
• Review report or completed checklist for the most recent cycle
• Approval record from privacy counsel/authorized official for each exemption’s continued appropriateness/necessity
• SORN copy/version and mapping to exemptions claimed
• Change tickets showing SORN updates, exemption changes, or system changes tied to review outcomes ¹

Supporting artifacts

• Architecture/data flow summary used in the review (to show reviewers evaluated current practice)
• Disclosure/routine use register entries relevant to exemptions
• Record retention/disposition references used during the necessity analysis

Common exam/audit questions and hangups

Expect these questions and pre-answer them in your evidence packet:

• “Show me every exemption this system claims and where it is described in the SORN.”
• “How do you confirm the exemption is promulgated as a regulation?”
• “What changed since the last review, and did you re-evaluate exemptions after the change?”
• “Who can approve continuing to claim an exemption, and where is that documented?”
• “Does your system behavior match what the SORN says about exemptions?” ¹

Hangups that cause findings:

• Reviews performed but not documented.
• SORN language out of date relative to actual data sharing.
• No proof that the exemption is grounded in regulation, versus policy preference.

Frequent implementation mistakes (and how to avoid them)

1. Treating exemptions as static.
   Fix: add change-driven triggers tied to SDLC and privacy change control.

2. No mapping between exemption claim and SORN text.
   Fix: store a direct reference to the SORN section for each exemption entry.

3. Legal review happens verbally.
   Fix: require a signed memo, approval in a ticket, or recorded decision in a governance tool.

4. SORN updates are “somebody else’s job.”
   Fix: assign an accountable owner for SORN accuracy and make SORN reconciliation a required step in the review workflow ¹.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the source data. Treat risk as assessment and operational exposure: if exemptions are inaccurate or unsupported, you can face adverse assessment results, forced remediation, delays in system authorizations, and heightened scrutiny during privacy incidents or request handling. The immediate operational risk is loss of defensibility: you cannot explain why access, amendment, or disclosure rights were limited for a given record set.

Practical 30/60/90-day execution plan

First 30 days (stand up the control)

• Assign a single accountable control owner and document RACI across privacy, counsel, system owner, and records.
• Build the exemption inventory for each in-scope system of records; map each exemption to SORN sections.
• Publish a short SOP: triggers, reviewers, approval authority, and evidence to retain ¹.

Days 31–60 (run the first review and remediate obvious gaps)

• Execute the exemption review checklist for highest-risk systems first (systems with frequent sharing, many interfaces, or recent changes).
• Validate “promulgated as regulation” support for each exemption and capture the reference in the packet.
• Open and track remediation items for SORN misalignment or unclear rationales; assign owners and due dates.

Days 61–90 (institutionalize and make it repeatable)

• Integrate review triggers into SDLC/change management so privacy exemption review is prompted by system changes.
• Standardize the PT-6(2) evidence packet format and storage location.
• Dry-run an audit: have someone unfamiliar with the system use the packet to answer the common audit questions without extra meetings. If they cannot, tighten the artifacts.

Frequently Asked Questions

Do we need PT-6(2) if we don’t claim any Privacy Act exemptions?

If the system of records claims no exemptions, document that determination and keep evidence that a review was performed and found none. The control is about reviewing exemptions claimed for the system of records ¹.

What does “promulgated as regulations” mean in practice?

You should be able to point to the formal regulatory basis that established the exemption claim, not a local policy statement. Keep that reference in your evidence packet and ensure the SORN description matches the promulgated scope ¹.

Who should approve that an exemption remains “appropriate and necessary”?

Assign approval authority to your privacy counsel or designated legal authority, with the system owner attesting to current system operations. Auditors want a clear decision record tied to accountable roles ¹.

How do we handle exemptions that are technically valid but no longer match how the system operates?

Treat it as a control failure until corrected. Either update the system/SOPs to align with the exemption rationale or update the SORN and stop claiming the exemption that no longer fits ¹.

What’s the minimum evidence that satisfies PT-6(2) in an assessment?

An assessor typically needs an exemption inventory, a documented review procedure, proof the review occurred, legal/authorized approval outcomes, and a current SORN that accurately describes the exemptions claimed ¹.

We are a contractor hosting a federal system. Who owns the SORN alignment work?

The agency typically publishes the SORN, but you still need operational controls to provide accurate inputs and to reconcile your system behavior to the SORN’s exemption descriptions. Document the interface with the agency owner and retain correspondence or tickets that show the review and updates ¹.

Footnotes

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