What PT-2 asks you to prove about PII authority
PT-2 requires your organization to determine and document the authority that permits each defined processing activity involving personally identifiable information, and to restrict that processing to what the authority covers. A PT-2 finding usually means an assessor could not point to a written basis for one or more processing activities, or found that data was being used beyond the basis that was recorded. The risk is concrete: a system that collects, stores or shares PII without a documented authority has no defensible reason to be doing so, and any later question about a use case, a new integration or a data subject complaint becomes hard to answer. PT-2 sits only in the privacy baseline, which applies to a system regardless of its security impact level. A low-impact system that processes PII still needs this control, and a high-impact system does not gain it through its security baseline.
The difficulty is that authority rarely lives in one place. For a given processing activity, the basis may come from a statute, a regulation, a contract with a customer or a data provider, a consent record, or an internal decision made by a product or legal owner. Many systems also process PII for purposes that were added after launch, so the authority for the original design no longer covers the current use. Start by inventorying the processing activities for each system that handles PII, then record for each one the specific authority, the owner who confirmed it and the date it was last reviewed. Ask your counsel or privacy office to confirm which authorities apply in each jurisdiction where you operate, because NIST does not supply that legal analysis. Your assessor will check whether the documented authority matches what the system actually does, so compare the inventory against the data flows and the access permissions in the system's configuration.
Which systems and processing activities PT-2 covers
PT-2 applies to every processing activity that involves PII, so scoping starts with inventory rather than with the control text. The cards below cover the decisions that change the work: which systems count, which data elements count, who owns purposes, how processors fall in, and which related controls draw on the same inputs.
Privacy baseline applies regardless of impact level
SP 800-53B does not place PT controls in the low, moderate or high security baselines. PT-2 sits in the privacy baseline, which applies to a system irrespective of its impact level. A low-impact internal HR tool that holds employee PII is in scope, even though its security baseline is light. Check each system's privacy baseline status before assuming a security baseline covers it.
Systems that process PII
Build the inventory from data flows, not from application lists. Include production databases, analytics warehouses, backups, logs, support ticketing tools, and test or staging copies that contain real records. Each system that creates, collects, stores, uses, shares or deletes PII needs a recorded processing activity, and PT-2 authority must be documented for each one.
Data elements that count as PII
Treat any data element that can identify an individual, alone or combined with other data, as PII. That includes direct identifiers such as names and account numbers, and indirect ones such as device IDs, location traces and job titles in small teams. Data classification must be applied at the element level so that PT-2 authority can be recorded for specific fields, not only for whole databases.
Teams that own processing purposes
Authority depends on purpose, and purposes are usually set by business owners such as marketing, claims, or customer operations, not by IT. Name an accountable owner for each processing activity and require that owner to state the legal or other authority for it. Where ownership is unclear, PT-2 findings tend to appear as gaps in documentation rather than as technical defects.
Third-party processors in scope
PII that a cloud provider, SaaS vendor, payroll bureau or managed service handles on the organization's behalf is still part of the organization's processing activities. Record each processor, the instructions it operates under, and the authority that permits the transfer. Contracts should restrict processing to the documented authority, and the team should confirm how the vendor limits its own secondary use of the data.
Related controls that share PT-2 inputs
PT-2 draws on the same inventory and authority records as PT-3 (processing purposes), PT-5 (privacy notices), PT-6 (system of records notices) and AC-3 (access enforcement), which restricts access to processing. RA-3 (risk assessment) uses the same processing records to evaluate privacy risk. Maintain one processing register that feeds all of them, so that a change in purpose updates the notice, the access rules and the risk record together.
How an assessor tests PT-2
This table maps each SP 800-53A assessment method for PT-2 to what the assessor does, the evidence they request and where findings usually arise. Read it as a preparation checklist: the examine, interview and test objects define what must exist and be demonstrable before fieldwork starts.
| Assessment element | What the assessor does | Evidence requested | Common findings |
|---|---|---|---|
| Examine: PT policy and procedures | Reads the PII processing and transparency policy and procedures and checks that they address determining and documenting processing authority and restricting processing to what is authorized. | Approved PT policy, procedures for authority determination, document version history and the review record. | Procedures describe authorization in general terms but name no owner, trigger or record for a given processing activity. |
| Examine: authority documentation | Checks whether each defined PII processing activity has a recorded legal or other authority, and whether that authority matches the policy. | Register of processing activities linked to statutory, contractual or other authority references. | Processing activities appear in the inventory with no authority field completed, or authority is stated as 'business need'. |
| Interview: personnel with PT responsibilities | Asks privacy, legal, system owner and records staff how they decide whether a new use of PII is authorized and who signs off. | Named roles, responsibility assignments and walkthrough notes from the interviews. | Staff describe different approval paths, and system owners are unaware that a change in purpose needs review. |
| Interview: system owners and developers | Confirms that teams know which PII they hold and that they stop processing outside the authorized set. | Data flow descriptions or system records that the interviewees can explain. | Teams reuse data collected for one purpose in analytics or testing without a documented authority. |
| Test: authorization process for PII processing | Walks through a sample of processing activities, or a recent new one, from request to documented authority and approval. | Tickets, approval records, legal review notes and dated decisions for the sampled activities. | Approvals exist but are dated after processing began, or the authority recorded does not cover the actual data elements. |
| Test: restriction of processing | Checks that technical or procedural limits keep processing within the authorized scope, such as access restrictions or data tagging. | Access control configurations, data tags or classification labels, and records of exceptions. | Restrictions are documented but not configured, so data moves to systems outside the authorized scope. |
| Test: change in authority or purpose | Tests whether changes to a processing activity trigger a review of authority before the change takes effect. | Change records showing a privacy review step and updated authority entries. | Change management has no privacy checkpoint, so new fields or uses are added without updating the authority record. |
Implementing PT-2 in six steps
The sequence turns PT-2 from a policy statement into a working system of record: every PII processing activity has a documented authority, processing is limited to what that authority allows, and the authorization process is tested before an assessor asks for it.
Inventory every PII processing activity
Start by listing the activities that collect, use, store, share, retain or delete PII, grouped by system, business process and data subject group. Involve system owners, business process owners and the privacy office, because system owners often know about a data flow that the privacy office has never seen. The step is done when each activity has a name, an owner, the systems it touches and the PII categories it involves. The output is a draft processing activity inventory that other PT controls can also draw on.
Identify the authority for each activity
For each inventoried activity, the privacy office and legal counsel determine what authority permits the processing. The authority may be a statute, a regulation, a contract, an explicit individual consent or another legal basis, depending on the organization's jurisdiction and sector. Record where the authority comes from and any conditions attached to it. Confirm the legal analysis with counsel rather than relying on the engineering team's reading. The output is an authority determination for each activity, with a reviewer's sign-off.
Record authority in an authorization register
Move the inventory and authority determinations into a single register that links each processing activity to its authority, purposes, owner, systems and approval date. A wiki or document management platform with version history, such as a self-hosted XWiki instance, can hold the register, so that changes to an authority entry are recorded with who changed it and when. The step is done when every activity in the inventory has a complete entry and the register is the only place those authorities are recorded. The output is the authorization register.
Restrict processing to authorized activities
Engineering and operations teams configure systems so that PII is processed only for activities that appear in the register. This can mean access controls that limit which processes or roles can use a data set, data flows that stop at systems not named in the register, and retention or deletion rules tied to the authority. Ask system owners to show where each restriction is enforced, and check a sample of systems against the register. The output is a mapping from each authorized activity to the technical or procedural restriction that enforces it.
Set a review trigger for new processing
Define the events that must send a proposed change back through authorization before it goes live, such as a new data field, a new recipient, a new purpose, a new system or a material change in the legal basis. Add these triggers to change management and project intake so that engineering teams cannot deploy a new processing activity without an authority check. Assign an approver for each trigger type. The output is a written trigger list, the intake or change ticket template that enforces it, and a record of at least one test change routed through it.
Test the authorization process
Test the process the way an assessor would. Interview the people responsible for PII processing and authorization, examine the policy, procedures and register, and sample recent changes to confirm that each new or altered activity was authorized before processing began. NIST's SP 800-53A procedures for PT-2 focus on examining policy and procedures, interviewing responsible personnel and testing the organizational process for authorizing processing. Record gaps as findings with owners and dates. The output is a test record with sampled changes, results and corrective actions. Independent assessors, not the implementation partner, decide whether the control is met.
Evidence that passes a PT-2 assessment
An assessor testing PT-2 looks for a documented authority behind each PII processing activity and proof that processing stays inside it. The artifacts below connect the register, the approval trail, the policy, the people and the technical restrictions, and each should be linked to the system security and privacy plan so the same story holds across the authorization package.
Processing authority register
This is the central list of every PII processing activity in scope, with the legal or other authority that permits each one, the defined purpose, the data categories and the owning system. Assessors use it to check that the organization has determined its authorities and can trace each activity to one. Review it whenever a system, data flow or data category changes, and record the reviewer and date. Confirm that each entry names the same system identifiers used in the system security and privacy plan, so the register and the plan do not diverge.
Authorization records for new processing
Each new or changed PII processing activity should leave a dated approval record showing who reviewed the authority, what was checked, and who accepted the decision. Assessors test the organizational process for authorizing processing by sampling these records against live systems. Keep the request, the legal or policy review, and the sign-off together, and link each record to the register entry it created or updated. A gap between a system that processes PII and the absence of a record is the most common finding to prevent.
PT policy and procedures
The PT policy and procedures document sets out how the organization determines authority, who approves it, how exceptions are handled and how the register is reviewed. Assessors examine it first, so it must describe the process as people actually run it. Record the owner, version, approval date and review cycle in the document itself. Check that the system security and privacy plan points to this policy for the PT controls rather than restating a different process.
Role descriptions for interviews
Assessors interview personnel with PII processing and transparency responsibilities, so the people named in the policy must be able to explain their part. Role descriptions should state who maintains the register, who approves new processing, who reviews legal authority and who checks restrictions. Keep them current when staff move, and confirm that each interviewee can describe a recent authorization from start to finish. Interview answers that contradict the written process weaken every other artifact.
Restriction configurations
Restriction configurations show that processing is limited to what is authorized, through access controls, data tagging, data flow rules and retention settings that match the register. Export the relevant settings and store them with a date, the system version and the change reference. Assessors test whether a system actually blocks use outside the authorized purpose, so compare exports against the register at each review. Record which settings the system security and privacy plan describes as the restriction mechanism for each activity.
What meeting PT-2 costs in money and effort
This table breaks down the cost components of meeting PT-2 by who is paid, whether each cost is one-time or recurring, and what drives it up or down. Use it to scope internal work against outside help and to frame what to ask for in a quote. No figures are given because none were supplied for this control.
| Cost component | Who is paid or who spends effort | One-time or recurring | What drives it |
|---|---|---|---|
| Authority determination | Privacy or legal counsel, internal or external | One-time per activity, then recurring on change | Number of processing activities and jurisdictions that apply |
| Data tagging and restriction engineering | Platform or engineering staff, or an implementation partner | One-time build, then recurring maintenance | Number of systems holding PII and how many data stores need tags |
| Authority register upkeep | Privacy office staff who keep records current | Recurring | Rate of new processing, system changes and legal updates |
| Process testing for authorization | Internal assessors or an independent assessor | Recurring at each assessment cycle | Number of authorization workflows and how often they change |
| External review of authorities | Outside counsel or an independent assessor | Periodic or triggered by change | Jurisdictional complexity and novelty of processing purposes |
| Open-source platform licenses | Little or no license fee for self-hosted open-source components | Recurring support contracts are optional | Choice of components and whether support is bought separately |
| Self-hosted infrastructure | Your cloud or data center team | Recurring | Hosting footprint, backups and environments kept for evidence |
Who owns PT-2 and what an outside partner can take on
Your organization owns PT-2 in full. Someone accountable, usually the privacy officer working with legal counsel, must decide which legal or other authority permits each PII processing activity, and must write that decision down. No outside party can make that determination for you, and no partner can attest to it. Your internal team also decides who may approve new processing and how processing is restricted once authority is documented.
- Authority determinations: Legal counsel identifies the statute, contract, consent or other basis for each processing activity and records the reasoning.
- Approval ownership: Name the role that authorizes new or changed processing before it starts.
- Policy alignment: Tie the authority process to the PT policy and procedures so that assessors can trace one to the other.
- Operational restriction: System owners confirm that processing stays within the documented authority.
- Interview readiness: Staff with PT responsibilities must explain the process consistently when an assessor interviews them.
Before any engagement starts, confirm that a named owner, a backup and a sign-off path exist for every processing activity in scope.
An implementation partner such as DeployOpen can prepare the systems, records and evidence that show your PT-2 process working. The partner does not decide what authority applies and does not sign off on compliance. Work is typically defined in a written, fixed scope that lists deliverables and timelines before work begins.
- Tooling setup: Configure self-hosted platforms that hold the authority register, approvals and change history.
- Data tagging: Build tagging conventions that label PII elements and link them to the processing activities they support, which the control's enhancements describe.
- Register build-out: Draft the structure of the authority register and populate it from the determinations your privacy team supplies.
- Restriction testing: Test whether system access and data flows actually stop processing outside the documented authority, and report the results to you.
- Evidence packaging: Organize records so that the assessor can locate policies, approvals and test results without guesswork.
Ask the partner to state in the written scope which items are deliverables and which remain your decisions, so that no determination is handed off by default.
The independent assessor tests PT-2 against the assessment procedure in SP 800-53A. That procedure uses examine, interview and test methods, and it looks at the policy and procedures, the personnel responsible for PII processing, and the organizational processes for authorizing processing. Only an independent assessor or certification body issues the assessment report or any formal determination of conformance.
- Examination: The assessor reads the PT policy, procedures and authority records to confirm they exist and are current.
- Interviews: The assessor asks responsible personnel how authority is determined and approved.
- Testing: The assessor observes or samples the authorization process and checks that processing matches recorded authority.
- Independence: Your partner prepares evidence, but the assessor must be separate from the team that built the systems.
- Report ownership: The assessor's report, not the partner's documents, is what your stakeholders rely on.
Confirm with your assessor which evidence they expect, how they sample, and whether they accept evidence produced by an implementation partner.
Common PT-2 gaps and how to close them
Most PT-2 findings come from authority that exists on paper but does not bind day-to-day processing. The gaps below share one root cause: the authorization decision is not tied to a specific processing activity, a system and a review point. Each fix turns a general statement into a record an assessor can trace from data to purpose to authority.
Authority recorded as a general statement
A policy sentence saying the organization processes PII lawfully does not show which authority covers which activity. PT-2 asks for the authority behind each defined processing activity, so an assessor will pick one activity and ask for its basis. Build a register with one row per activity, naming the data elements, the system, the authority and the purpose. Check that every row can be traced to a system of record and that the policy points to the register rather than replacing it.
Processing started before authority was checked
Teams often begin collecting or sharing data in a new tool, then ask legal whether they may. PT-2 restricts processing to what is authorized, so the check must come before the first record is processed. Put an authority sign-off in the project intake, and make the production change request reference an approved register entry. Ask engineering for a list of processing that began in the last review period and confirm each has a documented basis.
No trigger for new processing
Authority is often reviewed once, then forgotten when a new integration, analytics job or vendor feed is added. Without a defined trigger, the register drifts away from what the system actually does. Define events that require reassessment, such as a new data element, a new purpose, a new recipient or a new hosting location. Test the trigger by picking a recent change and confirming the register was updated before release.
Data tags missing from copies and backups
PT-2 includes data tagging as an enhancement, and tags that stop at the source database fail as soon as data is exported, cached or restored. Copies in analytics stores, logs and backups can carry PII without the authority attached. Require tags to travel with data through pipelines and ask how restores re-apply them. Sample an export and a backup restore and check whether the authority identifier is still present.
Authority records not reviewed
A register that is never reviewed becomes evidence of an old decision, not a current one. Assign each activity an owner and a review date, and record who approved the basis and when. Remove activities that have been retired, since leftover entries suggest processing that no longer has an authority. Ask the owner of the register to show the last review record for a sample of entries.
Tags enforced by people, not systems
Where tagging depends on engineers remembering to apply a label, processing can run without one. Automation is the enhancement that reduces this risk, because a system can block or flag records lacking an authority tag. Identify which pipelines and access paths can enforce tags automatically, and document where manual steps remain with a compensating review. Confirm with the tool owners which automated checks their platform supports before committing to a design.
PT-2 questions buyers ask before hiring help
How much does it cost to get PT-2 in place before an assessment?
No supplied figure gives a price for PT-2 work, and DeployOpen does not publish a price list. Cost depends on how many processing activities the organization runs, how many systems hold PII, and how much of the legal authority analysis already exists. The main cost components are internal staff time from privacy, legal and system owners, any outside counsel review of the authority citations, and the implementation partner's fixed-scope effort to build the register, tagging and evidence. Ask for a written scope that lists the systems and processing activities covered, the deliverables, and which costs recur, such as periodic reviews of the authority register.
How long does it take to document PT-2 authority for our systems?
No researched duration is available for PT-2 work, so treat any timeline as something to agree in writing. The schedule is driven mainly by how many processing activities need to be inventoried, how quickly legal owners can confirm the authority for each one, and whether data flows across systems are already mapped. Organizations with a current data inventory usually move faster than those building one from scratch. Ask a prospective partner to break the timeline into discovery, authority determination, restriction of processing, and evidence collection, with the client's review points marked.
What does the organization have to provide before outside help starts?
The organization owns the authority decisions, so it must supply the people and documents that establish them. Expect to provide a list of systems and processing activities that touch PII, the data flows between them, existing privacy and records policies, and named owners who can confirm the legal or other basis for each activity. Legal or privacy counsel must make the authority determinations, because an implementation partner can record and structure them but cannot decide them. Access to the systems that enforce processing limits, such as access control and data handling configurations, is also needed to test the restrictions.
Can our own team document PT-2 without an implementation partner?
Yes, if your privacy, legal and system owners can complete the work, and nothing in NIST SP 800-53 requires an outside firm for PT-2. Internal teams are often best placed to know their processing activities, but the work requires a clear authority register, a method for limiting processing to authorized purposes, and evidence that the process runs. Outside help tends to add value when the inventory is incomplete, when systems are self-hosted and spread across several environments, or when staff capacity is limited. Confirm your internal capacity before deciding.
What will an assessor ask to verify PT-2?
An assessor will check the two determination statements that SP 800-53A Rev. 5 defines for PT-2, using the examine, interview and test methods. In practice, they will read the PT policy and procedures, interview the personnel responsible for PII processing and transparency, and test whether the organization's process for authorizing PII processing works as documented. Expect requests for the authority register, evidence that each processing activity maps to an authority, and examples showing that processing is restricted to what is authorized. The NIST CPRT entry for PT-02 is the natural next read for the control text.
How does PT-2 differ from PT-3 and PT-5?
PT-2 asks the organization to determine and document the authority for each PII processing activity and to restrict processing to what that authority permits. PT-3 covers the purposes for processing, how they are identified, documented, described publicly and limited to compatible uses when they change. PT-5 covers the privacy notice given to individuals, including the processing authority and purposes, provided at first interaction in plain language. In short, PT-2 establishes the legal basis, PT-3 defines the purposes that basis supports, and PT-5 tells individuals about both. The three controls share evidence, so one authority register can feed all of them.
Which PT-2 evidence should we prepare first?
Start with the artifacts an assessor is most likely to request. These usually include:
- A register of PII processing activities, each linked to a documented authority and its owner
- The PT policy and the procedure for authorizing new or changed processing
- Records showing that processing is restricted to authorized purposes, such as access rules and data tagging
- Change records showing reviews when processing or authority changes
Treat version history as part of the evidence. Wiki and documentation platforms that keep version history and role-based permissions can show who changed an authority record and when, which helps demonstrate that the register is maintained rather than written once. Confirm with your assessor which formats they accept.
Using data tagging and automation to enforce authority
PT-2 has two control enhancements, and both aim to make the authority decision operate on the data itself rather than living only in a policy document. The first concerns tagging PII so that the processing rules attached to each data element can be applied by systems. In practice, an organization that has documented which authority covers a processing activity still needs a way for a database, data pipeline or application to recognize which records carry which restrictions. Tags, labels or classification attributes on fields, tables and datasets provide that link. The second enhancement concerns automation that restricts processing to the authorized purposes, so that a request outside the documented authority is blocked or flagged by a system instead of relying on a person to notice it.
Before relying on either enhancement, confirm the exact wording in the CPRT entry for PT-02 or in the OSCAL catalog for SP 800-53 Release 5.2.0, because the enhancement titles and text are what an assessor will compare your evidence against. Also note that neither enhancement is allocated to an SP 800-53B baseline. PT-2 sits in the privacy baseline, and the baseline profile does not select its enhancements, so an organization should decide with its privacy office and assessor whether it will implement them voluntarily, adopt them as a risk-based choice, or document why an alternative meets the base requirement. Ask the assessor how they expect a tagging scheme and automated restriction to be evidenced, such as a tag inventory, rule configuration exports and test records showing a blocked request.
For an implementation partner, this is where configuration work and documentation meet. Typical activities include defining a tag taxonomy tied to the authorities recorded under PT-2, configuring the platform to read and enforce those tags, and testing that unauthorized uses fail. Open-source platforms often provide the hooks for this, but the tag values, the rule logic and the review of exceptions remain organizational decisions. Ask any partner to state in the written scope which systems will be tagged, who maintains the tag list, how changes to authority are propagated to enforcement rules, and what test evidence will be delivered. Those answers determine the effort, which recurs whenever a new processing purpose is added.
How DeployOpen prepares PT-2 evidence
The sequence turns PT-2 from an unwritten assumption into a documented authority register, enforced processing restrictions and an evidence set an independent assessor can test. The organization keeps ownership of every legal determination throughout.
Agree the written scope and processing systems
DeployOpen and the organization agree in writing which systems, data stores and processing activities fall within scope, along with deliverables and timelines. The organization names the business owners who will confirm each processing activity. The step closes when the scope document lists every in-scope platform and its hosting location inside the client's own cloud accounts, data centers or air-gapped network.
Inventory PII processing activities
The organization, with DeployOpen providing structure and questionnaires, identifies each activity that processes PII, the categories of data involved, the systems that hold it and the teams that run it. Business owners review the inventory for completeness. The step closes when every activity in scope has a named owner and a documented data flow.
Record the authority for each activity
For each inventoried activity, the organization's legal or privacy function determines and records the authority that permits the processing, such as a statute, regulation, contract or other basis it has identified. DeployOpen can build the register template and capture the entries, but it does not make or validate the legal determination. The step closes when counsel or the privacy lead signs off each entry.
Configure data tagging on self-hosted platforms
DeployOpen configures the self-hosted platforms in the client's environment so that records are tagged with their authorized processing activity, using each platform's own metadata or tagging features where they exist. Where a platform lacks a native capability, the team documents the workaround and asks the client to confirm it fits their design. The step closes when a sample of tagged records matches the register.
Restrict processing to authorized purposes
DeployOpen implements access and workflow restrictions so that PII is used only within the activities the register authorizes, using the platforms' role and permission models and the client's identity provider. Test accounts confirm that out-of-scope use is blocked or logged. The step closes when restriction settings are exported, reviewed by the client and recorded as configuration evidence.
Document authorization procedures and change control
DeployOpen drafts the procedure the organization uses to authorize new PII processing and to update the register when a processing activity changes. The organization approves the procedure and assigns the approvers. The step closes when the procedure, approval records and a sample change request are in the evidence folder.
Assemble the evidence package for the assessor
DeployOpen gathers the register, tagging and restriction configurations, test results, procedures, approval records and interview notes into an evidence package mapped to the PT-2 determination statements in SP 800-53A. The organization reviews the package for accuracy. The step closes when the client hands the package to its independent assessor, who decides what is tested and issues any report. DeployOpen does not issue audit reports, attestations or certifications.
