AT-3(5): Processing Personally Identifiable Information

AT-3(5) requires you to identify who in your environment processes personally identifiable information (PII) and give them initial and periodic training on the specific controls they must operate: PII processing controls and transparency controls. To operationalize it quickly, define the “PII processing roles,” assign training content tied to your actual workflows, and retain completion and content-change evidence for audit readiness.

Key takeaways:

• Scope the requirement to real job roles that handle PII, not “all employees by default.”
• Training must cover how to operate your PII controls (collection, use, sharing, retention, disposal) and transparency controls (notices, access/requests, disclosures).
• Evidence is the control: keep rosters, content versions, completion logs, and exceptions with approvals.

Compliance teams usually treat awareness training as a generic HR exercise. AT-3(5) is narrower and more operational: it expects training for the people who actually process PII, and the training must map to the controls those people run day to day. That includes controls that govern how PII is collected, used, shared, stored, retained, and disposed of, plus “transparency controls” that govern what you tell individuals and how you respond to requests.

This requirement shows up in federal information systems and contractor systems handling federal data, often alongside broader privacy and security obligations. Assessors commonly fail teams here for two reasons: (1) the organization cannot show that the right population was trained (the “PII processors” are not clearly defined), and (2) the organization cannot show the training content is specific to the organization’s PII processing and transparency procedures (it’s a generic privacy video with no operational tie-in).

The fastest path to a defensible AT-3(5) implementation is to treat it like a control with defined inputs and outputs: a role-based training matrix, a repeatable training lifecycle (new hire, role change, refresher), and durable evidence that proves both coverage and relevance.

Requirement: at-3(5): processing personally identifiable information requirement (what it means)

AT-3(5) requires you to provide a defined population with initial and periodic training on the “employment and operation” of (a) PII processing controls and (b) transparency controls. The control text is explicit that the training is about operating controls, not just knowing definitions. ¹

In practice, that means:

• You decide which roles are “PII processing roles” in your environment.
• You train those roles on the procedures and systems they use to process PII in a compliant way.
• You refresh that training on a defined cadence, and you retrain when processes or systems change in a way that affects PII handling.

Regulatory text

“Provide {{ insert: param, at-03.05_odp.01 }} with initial and {{ insert: param, at-03.05_odp.02 }} training in the employment and operation of personally identifiable information processing and transparency controls.” ¹

Operator translation: you must (1) name the training audience and (2) deliver both initial and ongoing training that teaches them how to carry out your PII processing and transparency controls in the tools and workflows they actually use.

Who it applies to (scope it correctly)

Entity scope

• Federal information systems.
• Contractor systems handling federal data. ¹

Operational scope (the people and workflows)

Apply AT-3(5) to roles that can create, view, modify, transmit, export, or delete PII, including:

• Customer support and case management teams handling identity, contact, or account data.
• HR and recruiting teams processing employee and applicant PII.
• Security operations and IT admins with access to directories, device telemetry tied to individuals, or ticketing systems.
• Engineering, analytics, and data science roles accessing production datasets containing PII.
• Legal/privacy operations handling data subject requests or disclosure obligations.
• Third-party managers who send PII to third parties (payroll, benefits, CRM, background checks, call centers).

A clean scoping rule for audits: if a role can move PII across a boundary (system boundary, tenant boundary, third-party boundary, or “production to local machine”), it belongs in the AT-3(5) population.

Plain-English interpretation (what “PII processing” and “transparency controls” should cover)

PII processing controls (what staff must be trained to do)

Your training should teach “how we do it here” for:

• Collection and purpose limits: what PII you collect, from whom, and for what permitted purposes.
• Access control in practice: how to request access, how privileged access is handled, and how to avoid shared accounts or insecure exports.
• Data minimization in workflows: what fields are required vs optional, and what to do when someone asks for “extra” data.
• Sharing and transfers: when PII can be shared with a third party, what approvals are required, and what contractual/security checks apply.
• Retention and disposal: where to find retention rules and how deletions, secure disposal, or archival work.
• Incident reporting: what constitutes a suspected privacy incident and how to escalate.

Transparency controls (what staff must be trained to explain or execute)

Train staff on the operational pieces of transparency, such as:

• Notices and disclosures: where privacy notices live, what commitments they make, and what staff must not promise.
• Requests and rights workflows (if applicable to your program): intake, identity verification, routing, response approvals, and response logging.
• Logging and documentation: how you document disclosures, access, and request handling so you can prove compliance later.

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

1) Name the control owner and define the training population

• Assign a single accountable owner (often Privacy, GRC, or Security Awareness).
• Create a “PII Processing Role Register” that lists roles, teams, and the systems they use to process PII.
• Define objective inclusion rules (examples: access to production PII tables; export permissions; casework involving identity verification; third-party file transfers).

Deliverable: Role register + inclusion criteria.

2) Map training modules to the controls people must operate

Build a matrix that ties:

• Role → systems → PII types handled → required procedures → training module(s).

Keep the modules short and job-specific. A support agent needs different training than a database admin. Generic privacy training can be a baseline, but AT-3(5) expects training on operating your controls.

Deliverable: Role-to-training matrix.

3) Create or update training content to reflect your real workflows

Minimum content elements to include:

• Your definition of PII for the program and examples from your environment.
• “Allowed vs not allowed” actions in your tooling (ticketing system, CRM, data warehouse, admin console).
• Approval paths for exports, disclosures, and third-party transfers.
• How to respond to transparency events (requests, inquiries, complaints), including handoffs and required logging.

Practical tip: keep screenshots and “click-path” instructions in an internal runbook, and reference it inside the training.

Deliverable: Training deck/LMS module + linked runbooks.

4) Implement initial training triggers

Initial training should fire when:

• A person is hired into a PII processing role.
• A person transfers into a PII processing role.
• A person receives elevated access that enables PII processing.

Operationalize this with IAM groups and HRIS attributes where possible (automatic assignment), and a manual backstop for exceptions.

Deliverable: Onboarding/access-change training workflow.

5) Implement periodic refresher training and “change training”

Periodic training is the standing refresher cycle you define. Change training is event-driven (new system, new third party, new request workflow, new retention rule, new transparency notice commitments).

Deliverable: Refresher assignment logic + change-management trigger.

6) Make it auditable: evidence, exceptions, and governance

• Track completion, due dates, and overdue escalations.
• Document exemptions (temporary contractors, break-glass admins) with risk acceptance and a remediation date.
• Review the role register and training content when systems, data flows, or notices change.

Deliverable: Training governance procedure + exception log.

7) Use tooling to keep the control “always ready”

Many teams fail because evidence lives in disconnected places. A system like Daydream can help by mapping AT-3(5) to a control owner, an implementation procedure, and recurring evidence artifacts, so audit readiness becomes a monthly maintenance task instead of a scramble. ¹

Required evidence and artifacts to retain (audit-ready list)

Keep these in a single “AT-3(5) evidence folder” with versioning:

• PII Processing Role Register (current + prior versions).
• Role-to-training matrix (current + prior versions).
• Training content (slides, scripts, LMS module exports) with version history and effective dates.
• LMS completion logs for in-scope personnel (initial + refresher), including timestamps and pass/fail if you test comprehension.
• Proof of training assignment rules (screenshots/config export of LMS groups; IAM group mapping; HRIS triggers).
• Change log that shows when training content was updated and why (new system, new notice, process change).
• Exception log with approver, rationale, compensating controls, and closure status.

Common exam/audit questions and hangups

Expect assessors to probe these areas:

• “Who exactly is {{ at-03.05_odp.01 }}?” If you cannot define the population, you will not pass the control intent. Have the role register ready. ¹
• “Show me the training content for a PII processor.” Generic annual security awareness rarely satisfies “employment and operation” of PII controls. ¹
• “How do you ensure new admins get trained before access?” They will test joiner/mover workflows.
• “What happens when the privacy notice or request process changes?” They want to see change training triggers, not ad hoc emails.
• “Prove completion for a sample of users.” Have exportable LMS logs and a clean sampling story.

Frequent implementation mistakes (and how to avoid them)

1. Training “everyone” and calling it done. Over-scoping dilutes role-specific content and makes evidence harder. Scope to actual PII processing roles, then add general awareness separately.
2. No operational tie to systems. If your agents use a CRM and your analysts use a warehouse, the training must reflect the correct do’s/don’ts for each.
3. No definition of transparency controls. Teams cover “privacy basics” but skip notices, request handling, and disclosure logging.
4. Evidence gaps after LMS migration or org changes. Preserve exports and archive prior completion data before system changes.
5. Contractors and third parties forgotten. If they process your PII in your environment, put them in scope and track completions or contractually require equivalent training with proof.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this control enhancement, so this page does not cite specific regulator actions. Practically, weak AT-3(5) execution increases the chance of human-driven privacy incidents: improper disclosure, mishandled requests, unapproved exports, and inconsistent notice commitments. Those failures usually surface first as audit findings and customer trust issues, then as reportable incidents depending on your environment.

Practical 30/60/90-day execution plan

First 30 days: Define scope and build the control skeleton

• Assign control ownership and backup owner.
• Produce the first PII Processing Role Register from HRIS + IAM groups + system access lists.
• Draft the role-to-training matrix with at least one module per major PII workflow (support, HR, IT/admin, engineering/analytics).
• Decide your refresher cadence and define “change training” triggers in change management.

Days 31–60: Build training that matches real workflows

• Create role-specific content and link to internal runbooks for key systems.
• Configure LMS assignments based on roles/IAM groups; document the logic.
• Run a pilot with one high-volume PII team (often Support or HR) and fix gaps.
• Stand up the evidence folder structure and versioning approach.

Days 61–90: Operationalize and make it repeatable

• Roll out to all in-scope roles; track completion and escalate overdue items.
• Implement joiner/mover training gates with IAM/ITSM workflows.
• Add a quarterly control check: reconcile role register vs actual access, review training change log, sample completions.
• If you use Daydream, map AT-3(5) to the control owner, procedure, and recurring evidence artifacts so each cycle produces audit-ready outputs. ¹

Frequently Asked Questions

Does AT-3(5) require training for every employee?

No. It requires training for the defined population that processes PII and must operate PII processing and transparency controls. You can still provide general privacy awareness to everyone, but keep AT-3(5) evidence focused on the in-scope roles. ¹

What counts as “processing” PII for scoping?

Treat it as any role that can collect, access, modify, transmit, export, or delete PII in your systems or workflows. If a person can move PII across a system or third-party boundary, include them in the role register.

Can we use generic annual security awareness training to satisfy AT-3(5)?

Usually not by itself. The text requires training on the “employment and operation” of your PII processing and transparency controls, which implies system- and process-specific instruction. ¹

What evidence does an assessor typically ask for first?

A roster of who was trained, the training content that was delivered, and completion logs for a sample of personnel. If you can also show how people get automatically assigned training when they enter a PII role, reviews tend to go faster.

How do we handle third-party contractors who process PII?

Put them in scope if they process your PII in your environment, and track their completion in your LMS or require equivalent training by contract with documented proof. Keep an exception record if a contractor cannot access your training platform.

What should trigger “change training”?

Any change that affects how staff operate PII controls or meet transparency commitments: new tools, new data flows to a third party, changes to request handling, retention updates, or revised notices and disclosures.

Footnotes

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