What PT-3 asks you to prove about PII purposes
PT-3 requires you to identify and document the purposes for which your system processes personally identifiable information, describe those purposes in public privacy notices and policies, limit processing to purposes compatible with them, and monitor and manage changes to processing through defined mechanisms. An assessor will ask for the purposes list, the public text that describes them, and proof that a change in how PII is used passed through a controlled decision before it went live. The core question is whether the system does only what the documented purposes allow, and whether the organization can show when that answer changed. Purpose creep is the risk PT-3 targets. A field collected for account recovery quietly feeds a marketing segment, or a log retained for security starts serving analytics, and nobody with privacy authority approved the change. The control is hard because purposes do not live in one place. Engineering holds the actual data flows, legal holds the lawful basis and the wording of the notice, and product owns the features that create new uses. Each team can be correct about its own artifact while the combined picture is wrong. Confirm with your privacy office who owns the purpose register, who signs off on changes, and where those decisions are recorded before an assessor asks.
PT-3 sits only in the privacy control baseline in SP 800-53B. It is not allocated to the low, moderate or high security baselines, so it applies to a system regardless of its impact level. A system categorized as low impact that processes PII still needs documented purposes and a matching public notice. The SP 800-53A assessment procedure for PT-3 examines the configuration management plan, the organizational privacy notices and the organizational policies, interviews the personnel with PII processing responsibilities, and tests the processes that authorize new processing. The facts available to us do not give costs or durations for meeting PT-3, so ask any implementation partner or auditor to price the purpose inventory, notice review and change workflow against your own system count and data flows in writing before you commit.
Which systems and data PT-3 scoping covers
PT-3 work expands or shrinks depending on a handful of scoping decisions made before any purpose statement is written. The cards below cover the questions that determine which systems, data sets, third parties and owners fall inside the control, and whether the privacy baseline applies at all.
Systems that process PII
Start with an inventory of systems that create, collect, store, use, share or delete personally identifiable information, including data warehouses, ticketing tools, HR platforms and analytics pipelines. PT-3 is assessed per processing activity, so a system that handles PII only incidentally still needs a stated purpose. Check whether the inventory comes from the configuration management records or from interviews, since assessors will compare the two. Ask who maintains the inventory when a new system is added.
Purposes recorded per system
Decide whether purposes are documented at the level of the whole system or for each data set within it. A single system holding customer contact details for billing and for marketing needs two recorded purposes, each with its own limits. Document the level you choose in the configuration management plan so that assessors can trace purposes back to specific data. Revisit the granularity when systems are consolidated.
Third parties receiving PII
Identify every external party that receives PII, such as payroll processors, cloud hosts, support vendors and analytics providers, and record the purpose under which each one gets data. Disclosures without a stated purpose are the most common gap assessors find when they compare the flow of data with the privacy notice. Include onward transfers that a vendor makes to its own subprocessors. Confirm contract terms match the purposes you document.
Teams that own purpose statements
Assign a named owner for each purpose statement, usually a business process owner working with privacy staff, rather than leaving the statement with IT alone. Owners decide whether a new use is compatible with an existing purpose, which drives the change-management step PT-3 requires. Record who approves changes and who is informed. Ask whether each owner can name the systems and data sets their purpose covers.
Whether the privacy baseline applies
SP 800-53B does not allocate PT controls to the low, moderate or high security baselines. PT-3 belongs to the privacy baseline, which applies to systems irrespective of impact level, so a system categorized as low impact can still fall under PT-3 if it processes PII. Confirm with your privacy office which systems are in scope for the privacy baseline before estimating effort. This decision is separate from security categorization.
Changes to existing processing
Decide how new purposes and changed uses enter the review process before data is used for them. PT-3 expects changes in processing to be monitored and managed through defined mechanisms, so the scope should include the intake route for requests, such as a change ticket or privacy review form. Systems integrated later, such as a new analytics tool, should trigger the same review. Document the trigger events so the process is repeatable during assessment.
How an assessor tests PT-3 purposes
This table compares the three SP 800-53A assessment methods (examine, interview and test) as they apply to PT-3, listing the evidence each one asks for and a finding assessors commonly raise. SP 800-53A gives six determination statements for PT-3, and the table shows how the methods map onto them. Read it as a checklist of what to have ready before an assessor arrives.
| Method and object | Evidence requested | Common finding |
|---|---|---|
| Examine: configuration management plan | Plan sections showing how changes to PII processing are identified, reviewed and approved, with the owner of each change type named | Change control covers system changes but never mentions changes to the purposes for processing PII |
| Examine: organizational privacy notices | Current published notices, dated versions and a list of the processing purposes each one states for the system | Notice lists purposes the system no longer serves or omits a purpose added in a later release |
| Examine: organizational policies | Privacy policy and procedures that require purposes to be documented, limited to compatible uses and reviewed when processing changes | Policy exists but names no owner, review trigger or link to the notice |
| Interview: personnel with PII processing and transparency responsibilities | Consistent answers from product owners, privacy staff and system administrators about why each data element is collected and what the purpose is | Engineers describe a secondary use that no one has recorded as a purpose |
| Test: processes for authorizing PII processing | Records of approvals for new or changed purposes, including the date, approver and the purpose statement approved | Approval happens informally in tickets or chat, with no record that the purpose was checked against the notice |
| Coverage across six determination statements | One evidence set per determination statement, cross-referenced to the examine, interview and test records above | Gaps appear where one statement has evidence but the matching interview or test was never run |
Implementing PT-3 in six steps
This sequence turns PT-3 from a policy statement into a working record: every PII processing activity has a documented purpose, that purpose appears in the public notice, and changes to purpose are caught and reviewed before processing continues.
Inventory PII processing activities
Privacy and system owners list every system, service and business process that collects, stores, uses, shares or deletes personally identifiable information. Include processing by third parties and shadow tools where staff load personal data into spreadsheets or SaaS applications. The step is complete when each activity has a named owner and a system of record, and the inventory is reviewed against the asset list used for the system security and privacy plan.
Record purposes and data elements
For each activity, the privacy office writes down the specific purpose the data serves, the PII data elements involved and the individuals affected. Purposes should be stated concretely enough that an assessor can tell whether a later use falls inside or outside them. The output is a purpose register with one row per activity, linked to the inventory identifier, and signed off by the accountable owner.
Align purposes with notices and the PT policy
Compare each register entry with the public privacy notice, the PT policy and the procedures that staff follow. Where a purpose is missing from the notice or described differently, update the notice text through the normal approval path rather than editing the register to match. The output is an approved notice text that lists the same purposes as the register, plus a short mapping showing which notice section covers which purpose.
Define the compatibility test for new uses
Write the decision rule that governs whether a proposed new use of PII is compatible with the documented purposes. The rule should ask whether the new use is reasonably expected by the individual, whether it relies on the same data elements, and whether it changes the risk to the individual. Legal or privacy review approves the rule and names who decides edge cases. The output is a short, versioned procedure that the people who build and approve data uses can apply without asking the privacy office for each case.
Set a change trigger that reopens purpose review
Connect purpose review to the change process, so that changes to data collection forms, new integrations, new recipients, new analytics or AI use cases, and changes to retention reach the privacy office before deployment. Configuration management and change tickets are the natural trigger points. The step closes when a test change is routed to purpose review and the resulting change record shows the register entry was updated or confirmed as unaffected.
Schedule review of notices and records
Set a recurring review of the purpose register and public notices, with a named owner and a record of each review. Confirm the review interval in the organization's own PT policy, since the researched facts do not set one for PT-3. Each review produces a dated record stating what was checked, what changed and who approved it, which is the evidence an assessor will examine when testing whether processing purposes are kept current.
Evidence that passes a PT-3 review
An assessor testing PT-3 looks for a traceable chain from each processing purpose to the system that performs it, the public notice that describes it, and the approval trail for any change. The cards below are the artifacts that make that chain visible, and each one needs an owner who confirms it stays accurate between assessments.
Purpose register by system
A register that lists every system that processes PII, the purposes for each processing activity, the categories of individuals and data involved, and the date the purpose was last confirmed. Assessors compare it against the system inventory and the privacy notice, so any system missing from the register is a finding. Refresh it when a system is onboarded, retired or repurposed, and have the system owner and the privacy office sign each entry. Confirm with your assessor which level of detail they expect.
Published privacy notice with version history
The privacy notice text as published, with a dated version history showing each revision and the reason for it. PT-3 expects the purposes to be described publicly, so assessors read the notice and check that its stated purposes match the purpose register. Keep prior versions retrievable so you can show what individuals were told at a given date. The privacy officer approves each version before publication.
Compatibility policy and procedure
The policy and procedure that define when a new use of PII is compatible with the original purpose and who decides. This is the document that tells staff how to limit processing to compatible purposes, so it must describe concrete tests, such as whether the new use is reasonably expected by individuals and whether it carries new risk. Review it on the cycle set in your PT policy and record the approver. Assessors examine it first when they test PT-3.
Approval records for changed purposes
Records showing that each new or changed purpose was reviewed and authorized before processing began. Each record should name the system, the old and new purposes, the compatibility assessment, the decision and the approver. Assessors often sample these to confirm that the approval process works in practice, not only on paper. The privacy office owns the log, and the business owner signs each entry.
Configuration management records for processing changes
Change tickets and configuration management records that show when a system's PII processing changed, such as a new data field, a new integration or a new recipient. Tying these records to the purpose register lets an assessor trace a technical change back to an approved purpose. Record the link in the change ticket itself so it survives tool migrations. The system owner and change board approve these records through the normal change process.
Interview-ready owner lists
A current list of the people responsible for PII processing purposes, the systems they own and the privacy decisions they can make. Assessors interview these people, and answers that conflict with the register or notice are a common source of findings. Refresh the list at every staffing change and confirm each owner can explain their systems' purposes in plain language. The privacy office maintains the list and the executive sponsor signs it off.
What meeting PT-3 costs in money and effort
This table breaks down the money and effort behind PT-3 by cost component, showing who is paid, whether the cost is one-time or recurring, what drives it, and how to keep it down. Read it as a checklist for scoping and quoting, since no fee or duration is fixed by NIST and every figure depends on your own system and data flows.
| Cost component | One-time or recurring | What drives it | How to keep it down |
|---|---|---|---|
| Privacy and legal review of purpose statements | One-time, then recurring at review cycles | Number of processing purposes, jurisdictions, and whether purposes overlap or change often | Start from a short purpose inventory, reuse one purpose vocabulary across systems, and ask counsel to review only changed purposes |
| Engineering time to map data flows to purposes | One-time for the initial map, recurring for new systems | Count of systems, interfaces and data stores that hold PII, plus how well current architecture documentation matches reality | Map flows from existing configuration, logs and diagrams before interviews, and tag data stores once so later reviews are incremental |
| Documentation tooling or licenses | Recurring if commercial, one-time setup otherwise | Choice of a commercial privacy management suite versus a self-hosted wiki or document platform, and the number of users who edit records | Self-hosted open-source wiki or documentation tools can hold purpose records with version history, removing per-seat license spend; confirm each tool's license terms before adoption |
| Hosting and administration of self-hosted tools | Recurring | Infrastructure location, backup and access control requirements, and staff time for patching and upgrades | Run the tools on infrastructure you already operate, bring them under your existing patching and backup routines, and document the administration tasks |
| Notice review cycles | Recurring | How often purposes change, how many public privacy notices reference them, and approval steps involving legal and business owners | Link each notice to its purpose record so one update flows to every notice, and set review triggers tied to system changes rather than a fixed calendar |
| Change management for new or altered processing | Recurring, per change | Volume of product and system changes that alter what PII is collected or how it is used | Add a purpose check to existing change request workflows instead of creating a separate approval path |
| Assessor fees | Recurring, per assessment cycle | Scope of the assessment, number of systems covered, and whether PT-3 is assessed alongside other privacy controls | Ask the assessor for a fixed quote based on a written scope and prepare evidence before fieldwork begins |
| Internal evidence upkeep | Recurring | How many versions of purpose records must be retained, interviews assessors will hold, and how quickly records go stale | Keep purpose records in version-controlled tools and assign a named owner for each purpose so evidence is current when examined |
Open-source tools that keep PT-3 evidence current
PT-3 evidence is only as good as the record behind it: the purpose register, the public notice text and the approval trail for changes. The two self-hosted wiki and documentation tools below can hold that record with version history and role-based editing, which gives assessors something concrete to examine. Neither tool decides what a purpose is or whether processing is compatible with it; that remains the privacy function's work.
XWiki version history for purpose records
XWiki, licensed under LGPL-2.1-or-later, keeps every change to a page under version control, recording what changed, when and by whom. Teams can compare any two versions and roll back to an earlier one. For PT-3, host the purpose register and the wording of each public privacy notice as pages, so that every edit to a stated purpose leaves a dated, attributed trail. Check that your chosen deployment retains history for the full period your assessor will sample, and confirm how backups of the wiki database are protected.
Notice history and change trails
A purpose statement changes over time, and PT-3 expects changes in processing to be monitored and managed through defined mechanisms. Use XWiki's comparison view to show what a notice said before and after a new processing activity was added, and link each version to the change request or privacy review that approved it. Illustrative example: a marketing analytics purpose is added to the register, and the diff between versions shows the new wording alongside the approval reference. Confirm that your reviewers can export or print these comparisons for the assessment file.
BookStack roles for purpose editors
BookStack, licensed under MIT, assigns user abilities through roles. Permissions can be overridden per role at the shelf, book, chapter or page level. This lets you create a shelf for privacy documentation where only designated privacy staff hold edit rights to purpose statements, while business owners can comment or read. Document who holds each role and review those assignments on the same cycle as your PT policy, so that edit rights to purpose statements are limited to named, accountable people.
Per-page overrides for restricted content
Page-level overrides in BookStack let you open one sensitive document, such as a register entry for a special category of PII, to a narrower group than its parent book. Use this to keep the entries that describe high-risk processing visible only to the people who must approve them. Test the setup by logging in as a standard user and confirming that restricted pages do not appear in search or navigation. Review overrides periodically, because overrides added for one project often outlive it.
Confirming fit before you rely on them
Before adopting either tool, confirm that it fits your hosting model, authentication standard, backup regime and retention requirements inside your own infrastructure. Check whether its audit logs and version histories meet the evidence depth your assessor expects, and test an export and restore. Neither tool replaces privacy review, legal authority analysis or the judgment needed to decide whether a new use is compatible with an existing purpose. Ask your implementation partner to document this fit assessment in writing, and ask your independent assessor how they will sample the records.
Who owns PT-3 and what to outsource
Your organization owns PT-3 in substance. The privacy office should decide which purposes each processing activity serves, approve any new purpose before data is used for it, and sign off on the public wording of those purposes. Engineering owns the data flow maps that show where PII enters, moves and is stored, because a purpose statement that does not match the real flows will not survive examination. Product and business owners own proposed new uses, since most drift in processing starts with a feature request rather than a policy decision.
- Privacy office: sets and approves the purposes, decides whether a proposed use is compatible with them, and keeps the public privacy notice aligned.
- Engineering: maintains current data flow diagrams and tells the privacy office when a system begins collecting or deriving new categories of PII.
- Product and business owners: submit each new use or change of use for review before launch.
- Legal counsel: confirms that compatibility decisions and notice wording reflect the laws that apply to your sector and jurisdictions.
- Management: assigns these owners in writing and funds the review cycle.
Before engaging anyone outside, confirm that each of these named roles exists and that someone can show a recent approval decision.
An implementation partner can prepare the material PT-3 assessments look for, but it cannot decide what your purposes are. DeployOpen's role in this area is to plan, configure and document the systems that hold the records, using self-hosted open-source platforms in your own environment. Typical preparation work covers the purpose register, the documentation system that holds notices and policies, the change workflow that routes new uses to the privacy office, and the evidence packs that show the workflow ran.
- Purpose register: structures your approved purposes into a register with fields for system, data categories, authority and review date, populated from your decisions.
- Documentation system: configures a wiki or knowledge base so that notices, policies and register entries have owners and version history.
- Change workflow: builds the request, review and approval steps that stop processing from changing without a recorded decision.
- Evidence packs: collects exports, approval records and version histories into a folder the assessor can examine.
- Gap review: compares your current practice against the PT-3 assessment objects and lists what is missing.
When you request a quote, ask which of these items will be delivered as configured systems and which as written decisions, and confirm that the partner will not draft your purpose statements for you.
The independent assessor examines your documents, interviews your people and tests your processes against the SP 800-53A assessment procedure for PT-3. Only the assessor issues the assessment report and its determinations. The assessor is looking for evidence that the purposes were identified, documented, reflected in public notices and monitored for change, and it will sample real decisions to see whether the process actually ran.
- Examine: reviews the configuration management plan, the organizational privacy notices and the organizational policies that address purposes.
- Interview: speaks with the personnel who hold processing and transparency responsibilities, to check that they understand and follow the process.
- Test: observes the processes for authorizing new processing and checks whether a sample of changes went through them.
- Report: records the determinations in the assessment report, which is the document that carries independent weight.
- Independence: the assessor should not have written the purposes, the notices or the workflow it is testing.
Before hiring an assessor, confirm its independence rules in writing and ask which evidence it expects to sample.
Common PT-3 gaps and how to close them
Most PT-3 findings come from purposes that were written down once and then left alone while the system kept changing. The cards below cover the gaps assessors meet most often, the fix for each, and the evidence that shows the fix is working.
Purposes recorded once at launch
The purpose register was completed when the system went live and has not been reviewed since. New data fields, analytics jobs and reporting uses were added later without any change to the recorded purposes. To close this gap, set a review date for each processing activity and compare the register against the current data inventory at every review. Evidence: a dated register with version history, and review records showing which purposes were confirmed or changed.
Notices that outlive their purposes
The public privacy notice lists purposes the system no longer serves, while omitting ones it now performs. PT-3 expects the described purposes to match actual processing. Trace each purpose in the notice to a named processing activity, and trace each activity back to a notice statement. Evidence: a traceability table linking notice text, register entries and the systems that process the data, signed off by the privacy owner.
No defined compatibility test
Teams decide whether a new use of PII is acceptable case by case, with no written criteria. Two reviewers can reach opposite answers for similar requests. Write a short compatibility test that asks whether the new use is related to the original purpose, whether the individual would reasonably expect it, and whether it changes the risk to the individual. Evidence: the approved test, completed records for each request, and decisions that cite the test.
Changes shipped without a purpose check
Engineering releases add a new data field, export or integration without any step that asks whether the purpose changes. This is the most common route by which processing drifts away from what was documented. Add a purpose question to the change request or pull request template for any change that touches PII. Evidence: change tickets that record the purpose assessment, and a sample of releases showing the check was completed before deployment.
Third-party recipients not tied to purposes
PII is shared with processors, analytics providers or partners whose use is not linked to any documented purpose. An assessor will ask why each recipient receives each data category. For every recipient, record the purpose it serves, the data it receives and the contract terms that limit its use to that purpose. Evidence: a recipient list mapped to purposes, with the related agreements and any data flow diagrams that show the transfers.
No named owner for the register
The purpose register belongs to no one, so updates depend on whoever notices a problem. Assign a named owner with authority to pause a new use until its purpose is recorded, and define who must be consulted, such as the system owner, legal counsel and the security team. Evidence: a role assignment in the privacy policy, a documented escalation path and meeting or review minutes showing the owner acted on changes.
PT-3 questions buyers ask before hiring help
How much effort does PT-3 take for one system?
The effort depends on how many distinct purposes the system uses personally identifiable information for, and how well those purposes are already written down. PT-3 asks for the purposes to be identified, documented, described in public privacy notices and policies, and kept aligned with what the system actually does. For one system with a short, stable list of purposes, the work is mostly collection and reconciliation: pulling purposes from data flows, the privacy notice, contracts and configuration, then fixing gaps. For a system with many data uses, integrations or frequent feature changes, the work grows in each area. Ask the provider to break the estimate into inventory, notice review, processing-change procedure and evidence collection so you can see where the hours go.
Can our team implement PT-3 without an outside partner?
Often yes, provided someone owns the privacy function and can work across engineering, legal and product. The organization owns its controls, so internal staff must make the decisions about which purposes are authorized and how notices read. An implementation partner can help prepare systems and evidence, such as building a purpose inventory from configuration and data flows, wiring change requests to a purpose review step, and storing records in a version-controlled wiki or documentation tool. Outside help is most useful when the team lacks privacy engineering experience, when many systems share data, or when the schedule is fixed. Only an independent assessor can test the control and issue findings.
What does PT-3 need from privacy and engineering staff?
PT-3 needs both groups to contribute, with different jobs. Privacy staff or the privacy officer should define the authorized purposes, review the public notices and policies, and decide whether a proposed new use is compatible. Engineers should document how the system processes PII, which fields are collected, where they flow and which features depend on them, and they should build the change mechanism into the release process. Assessors interview people with PT-3 responsibilities, so the named owners must be able to explain the purposes and the change process in their own words. Ask any partner to show which decisions remain with your staff.
How long does PT-3 take to implement?
No duration has been supplied for this control, so treat any timeline as something to confirm in writing. The main drivers are the number of systems in scope, how many purposes each one serves, whether privacy notices already exist and match current processing, whether a change management process already routes data-use changes to privacy review, and how many teams must approve the work. Delays often come from waiting on legal review of notice wording or from discovering undocumented data uses. Ask the provider to list the dependencies and which ones fall on your organization.
Does PT-3 apply to systems outside federal scope?
PT-3 is part of the privacy control baseline in SP 800-53B, which applies to systems regardless of their security impact level. NIST's baselines are written for federal information systems, and FISMA and OMB Circular A-130 are the laws and policies NIST lists as related. A private company, state agency or other organization may still use PT-3 as a reference, for example when a federal contract, a FedRAMP or GovRAMP requirement, or a customer audit asks for it. Whether the control is mandatory for you depends on the contract or regulation that cites it, so confirm that with your legal or contracts team before scoping.
How does PT-3 evidence differ from PT-2 and PT-5?
PT-3 is about purposes: what the organization says it uses PII for, that processing stays within those purposes, and that changes are reviewed. Its evidence includes the configuration management plan, organizational privacy notices and policies, a record of the change process, and records showing personnel can explain the purposes. PT-2 is about authority: the legal or other basis that permits each processing activity, with evidence such as authority mappings and data tagging records. PT-5 is about the privacy notice given to individuals, with evidence such as the notice text, where it appears and when it is shown. The three controls share sources, so one notice or inventory may satisfy parts of each, but assessors test each control against its own determination statements.
What should we request in a fixed-scope quote for PT-3?
Ask for a written scope that names the systems covered, the PII data flows and purposes to be documented, the privacy notices and policies to be reviewed, and the change process to be built or updated. The quote should list deliverables, such as a purpose inventory, a revised notice review record, a change procedure and an evidence index, plus the responsibilities that remain with your staff, including legal review and sign-off. Request assumptions about existing documentation, the number of interviews and review cycles, and how changes to scope are priced. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and prepares evidence for an independent assessor, who issues any report.
How DeployOpen prepares PT-3 purpose evidence
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For PT-3, we help teams set up the systems, records and documentation that show which PII processing purposes exist, how they appear in privacy notices and how changes are controlled, while the organization keeps ownership of its purposes and the independent assessor makes the call.
How we scope
- The written scope names the systems that process PII and the purpose records each one must hold.
- We agree which privacy notices, policies and configuration documents will be examined for PT-3 before work starts.
- Engagements are fixed-scope, with deliverables and timelines set out in writing, and ongoing support is available as a retainer.
How we build
- We configure the wiki or documentation platform so each processing purpose has a controlled, owned page with a named reviewer.
- We set role-based permissions so only authorized privacy staff can approve changes to purpose descriptions and notices.
- We test the approval path for new processing activities so that purpose changes are routed for review before going live.
How we hand over
- We deliver a purpose register, linked privacy notice references and a change log mapped to the PT-3 determination statements.
- We document how version history records what changed, when and by whom, so assessors can compare any two versions.
- We hand over runbooks and an evidence index, and the organization's own privacy staff and independent assessor judge whether the evidence is sufficient.
How we support
- We review the purpose register and notices when systems, data flows or legal requirements change, as the written scope allows.
- We keep platform versions, permissions and backups current through upgrade work agreed in the retainer.
- We help prepare responses for assessor interviews with the personnel who own PII processing and transparency responsibilities.
