PS-3(2): Formal Indoctrination

PS-3(2) requires you to verify that every person with access to a system handling classified information that requires formal indoctrination has completed the specific indoctrination(s) for the exact classified compartments/programs they can access. Operationalize it by mapping system data types to indoctrination categories, binding access approvals to indoctrination evidence, and continuously reconciling access lists to indoctrination rosters. ¹

Key takeaways:

• Build a data-type-to-indoctrination “entitlement map,” then enforce it in your access request workflow.
• Treat indoctrination status as a gating attribute for account provisioning, not a training checkbox.
• Evidence must show coverage (who has access) and verification (proof of the right indoctrination for that access).

The ps-3(2): formal indoctrination requirement shows up when your environment processes, stores, or transmits classified information where access is conditioned on formal indoctrination (for example, specific compartments, programs, or handling caveats). The requirement is narrow but unforgiving: you must verify that individuals who can access the system are formally indoctrinated for every relevant type of classified information they can reach on that system. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat indoctrination like an access entitlement dependency. Your control design should answer two questions with evidence: (1) What classified information types on this system require formal indoctrination? (2) For each user with access, can you prove they hold the required indoctrination(s) aligned to their actual access scope? If you cannot show that alignment, auditors usually treat it as a control failure even if you “generally do indoctrinations.”

This page gives requirement-level implementation guidance you can hand to identity, security operations, and program security teams, then test in an assessment.

Regulatory text

“Verify that individuals accessing a system processing, storing, or transmitting types of classified information that require formal indoctrination, are formally indoctrinated for all the relevant types of information to which they have access on the system.” ¹

Operator translation:
You must (a) identify which classified information types in the system require formal indoctrination, (b) identify everyone with any access path to that system (including privileged and indirect access), and (c) verify, with documented proof, that each person’s indoctrination covers the specific types they can access. ¹

Plain-English interpretation (what “verify” means in practice)

“Verify” means you do not rely on assumptions, oral confirmation, or a manager’s email that “they’re read in.” You run a check that compares:

• Access reality: effective entitlements to the system and to in-system data areas, and
• Indoctrination reality: formal indoctrination records for the relevant types of classified information.

The required outcome is no mismatch: nobody has access beyond their indoctrination scope.

Who it applies to

PS-3(2) applies in environments where:

• The system processes, stores, or transmits classified information and
• Some of those classified information types require formal indoctrination as a condition of access. ¹

Entities and operational contexts commonly in scope

• Federal information systems using NIST SP 800-53 as the control baseline. ²
• Contractor-operated systems handling federal classified information under a federal program’s security requirements, where NIST SP 800-53 controls are flowed down or used for assessment readiness. ²

Roles typically touched

• Program security / facility security (custodians of indoctrination records)
• IAM team (provisioning, RBAC/ABAC, privileged access)
• System owners (authoritative system boundary and data types)
• GRC (control ownership, testing, evidence)

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

Use this as your minimum viable operating procedure for ps-3(2): formal indoctrination requirement.

1) Define the system scope and the “indoctrination-relevant” information types

Create (or update) a short System Indoctrination Applicability Statement:

• System name/boundary
• Classified information types present
• Which types require formal indoctrination
• Where those types reside (applications, repositories, shares, specific enclaves)

This becomes your anchor artifact for audits and for access design. ¹

2) Build an entitlement map: information type → required indoctrination(s)

Create a table that ties “what’s in the system” to “what read-in is required.”

Example entitlement map (structure)

Information type in system	Storage location(s)	Access mechanism	Required formal indoctrination	Authoritative record source
[Type A]	[Repo/app]	[Role/group]	[Indoctrination A]	[Security office roster]
[Type B]	[Share/enclave]	[Privileged group]	[Indoctrination B]	[Program roster]

Keep it simple: auditors care that it is correct, owned, and used.

3) Establish authoritative sources for (a) access and (b) indoctrination status

You need two “sources of truth,” even if they live in different teams:

• Access source: IAM directory groups, application role assignments, PAM vault, and any break-glass mechanism that grants entry.
• Indoctrination source: formal indoctrination roster, read-in documentation, or system of record maintained by the responsible security function.

Document owners, update frequency, and how exceptions are handled.

4) Bind access approvals to indoctrination verification (make it a hard gate)

Update your access request workflow so approvers cannot complete provisioning unless:

• The requested access role/group is mapped to indoctrination requirements, and
• The request includes confirmation (or automated check) that the person is already indoctrinated for those information types.

Practical pattern:

• IAM ticket fields: “Requested role/group,” “Mapped indoctrination(s),” “Indoctrination verified by,” “Verification date,” “Evidence reference.”
• Automations: where feasible, make indoctrination status an attribute that gates group membership. If automation is not possible, require a documented manual verification step.

5) Reconcile access vs. indoctrination on a recurring basis

PS-3(2) is not “one-and-done.” You need recurring verification that catches drift:

• Users gain access over time.
• Data locations change.
• People’s need-to-know changes.
• Admin and service access paths get forgotten.

Run a reconciliation that answers:

• Who currently has access (including privileged users)?
• For each person, do we have evidence of indoctrination for every relevant information type they can access?
• What mismatches exist, and how were they remediated?

6) Remediate mismatches with a pre-defined playbook

Have a written decision tree:

• If access is broader than indoctrination: remove/limit access immediately pending resolution.
• If indoctrination exists but evidence is missing: obtain authoritative proof and attach to the record; do not accept informal attestations.
• If indoctrination is needed for mission reasons: initiate formal indoctrination process and track completion before restoring access.

7) Make it assessment-ready: test the control like an auditor would

Before an assessment, sample test:

• Pick a list of users from each role group (including admins).
• For each, show:
  1. their effective access,
  2. the indoctrination requirements for that access, and
  3. the proof of indoctrination meeting those requirements.

If you cannot produce that within a reasonable internal turnaround, your process is not operationalized.

Required evidence and artifacts to retain

Aim for artifacts that prove design + operation.

Design artifacts

• System Indoctrination Applicability Statement (system scope and indoctrination-relevant types)
• Entitlement map (information type → required indoctrination(s))
• Access control procedure showing indoctrination verification as a provisioning prerequisite ¹

Operational artifacts

• Access request tickets showing indoctrination verification step completed
• Indoctrination roster extracts or authoritative confirmations tied to individuals (redact as needed, but keep traceability)
• Periodic reconciliation reports (access list vs. indoctrination list)
• Remediation records for mismatches (access removed, ticket notes, approvals, and closure evidence)

Governance artifacts

• Control owner assignment and RACI
• Evidence collection schedule and storage location
• Exceptions register (if permitted) with compensating controls and expiration criteria

If you use Daydream, set PS-3(2) up as a control with a defined owner, a written procedure, and recurring evidence tasks so reconciliations and tickets land in one place for audit packaging.

Common exam/audit questions and hangups

Assessors tend to press on “verify” and “all relevant types.”

Typical questions:

• “Show me how you determined which classified information types on this system require formal indoctrination.” ¹
• “List everyone with privileged access. Where is the evidence each is read in for the relevant types?”
• “Do service accounts, managed identities, and break-glass accounts have an accountable sponsor with verified indoctrination?”
• “How do you prevent a manager from granting group access to someone who is not indoctrinated?”
• “Show your last reconciliation and the remediation for any mismatches.”

Hangups that trigger findings:

• Indoctrination proof exists but is not linkable to the user identity in the system.
• “Need-to-know” is documented, but indoctrination type coverage is not.
• Admin access is carved out as “IT only,” without mapping to the same indoctrination constraints.

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating indoctrination as generic training.
   Avoidance: Maintain a per-information-type indoctrination mapping tied to access roles. ¹

2. Mistake: Verifying only at onboarding.
   Avoidance: Add periodic reconciliations plus event-driven checks when roles change, privileges are granted, or data types expand.

3. Mistake: Ignoring indirect access paths.
   Avoidance: Include admins, database operators, backup operators, SOC analysts with raw log access, and anyone with “view all” permissions in SaaS apps.

4. Mistake: Evidence lives in email.
   Avoidance: Centralize evidence references in the access ticket and store rosters in a controlled repository with access logging.

5. Mistake: Weak entitlement design.
   Avoidance: Minimize bespoke roles. Fewer roles makes it easier to prove each role’s indoctrination requirements and keep reconciliations clean.

Enforcement context and risk implications

No public enforcement cases were provided in the source material for PS-3(2). ³

Risk still matters operationally:

• A mismatch between access and indoctrination is a policy and authorization boundary failure. It can also become an incident if classified data is accessed by someone lacking the required indoctrination.
• In an assessment, poor verification usually shows up as a repeatable control deficiency because it indicates systemic gaps in access governance and evidence management.

Practical 30/60/90-day execution plan

You asked for a plan you can run quickly. Use these phases as an execution checklist.

First 30 days (stabilize and define)

• Assign a single PS-3(2) control owner in GRC and a technical co-owner in IAM.
• Publish the System Indoctrination Applicability Statement.
• Build the entitlement map for the highest-risk repositories and admin roles first.
• Update access request templates to include mandatory indoctrination verification fields.
• Pull a current access list and run an initial one-time reconciliation against indoctrination rosters; remediate obvious mismatches.

Days 31–60 (embed into workflows)

• Implement hard gates: approval steps or automated checks that block provisioning without verified indoctrination.
• Expand coverage to all applications and data stores in the system boundary.
• Document the reconciliation procedure (inputs, owner, outputs, remediation SLAs as internal targets).
• Stand up an evidence binder in your GRC system (Daydream or equivalent): entitlement map, sample tickets, reconciliation outputs, remediation records.

Days 61–90 (operationalize and test)

• Run a second reconciliation to prove repeatability.
• Perform an internal audit-style sample: pick users across roles, show end-to-end traceability from access → indoctrination requirement → proof.
• Fix edge cases: break-glass, service accounts, external administrators, and inherited group memberships.
• Add change triggers: when new classified info types are introduced or data locations change, require an entitlement map update before access is granted.

Frequently Asked Questions

Does PS-3(2) apply to every system using NIST SP 800-53?

It applies when the system processes, stores, or transmits classified information types that require formal indoctrination. If your system does not handle such information types, document that determination as part of your applicability statement. ¹

What counts as “verification” for indoctrination?

Verification means you can produce authoritative records showing the individual is formally indoctrinated for the relevant information types they can access. A manager attestation without a roster or formal record is rarely sufficient for assessment purposes. ¹

How do we handle privileged administrators who don’t view mission data?

Treat privileged access as potential access to the underlying data and map admin roles to indoctrination requirements unless you can technically enforce separation (for example, admin tooling that prevents data access). Document the technical constraint and test it. ¹

Do third-party contractors need to be included?

Yes, if they are individuals accessing the system and their access could reach classified information types requiring formal indoctrination. Your reconciliation should include all identities with access, regardless of employment status. ¹

What if indoctrination records are held by a different organization (program office/security office)?

Define the authoritative source and a repeatable method to obtain confirmation for audits (for example, roster extracts or controlled confirmations). Then bind that confirmation to your access records so you can show traceability. ¹

How detailed does the mapping need to be if multiple classified types live in one system?

Detailed enough that you can show each user’s access does not exceed their indoctrination coverage. If the system mixes multiple indoctrination-relevant types, role-based segmentation often becomes necessary to keep verification provable. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5

3. NIST SP 800-53 Rev. 5; Source: NIST SP 800-53 Rev. 5 OSCAL JSON