PS-3(4): Citizenship Requirements

PS-3(4): Citizenship Requirements requires you to verify that anyone who can access a covered system meets defined citizenship criteria before access is granted, and to keep proof that the checks occurred. To operationalize it fast, define which systems/data trigger the rule, set the citizenship eligibility standard, embed verification into onboarding and access provisioning, and enforce exceptions through documented approvals.

Key takeaways:

• Define “covered systems/data” and the exact citizenship criteria, then bind them to access decisions (not just hiring policy).
• Build a repeatable verification workflow for employees and third parties, with documented exceptions and compensating controls.
• Keep an evidence bundle that auditors can trace from requirement → population → checks → approvals → access outcomes.

Compliance teams usually stumble on PS-3(4) for one reason: it looks like an HR requirement, but auditors test it as an access control requirement tied to specific systems and data. If your environment processes, stores, or transmits sensitive government or contract-scoped data, you need a deterministic way to (1) identify who is in scope, (2) verify citizenship eligibility before granting access, and (3) prove you did it consistently.

This page gives requirement-level implementation guidance for a CCO, compliance officer, or GRC lead who needs to stand up PS-3(4): citizenship requirements requirement quickly without guessing what evidence will satisfy an assessor. The operational goal is simple: no account gets access to covered systems unless citizenship requirements are satisfied or a formally approved exception exists. That means your workflow must join HR/third-party onboarding, identity and access management (IAM), and system authorization boundaries.

Where teams get burned is informality: “We check passports in recruiting” is not the same as “We can demonstrate that all identities with access to System X met Criteria Y at time of access.” Treat PS-3(4) as a control with an owner, a defined population, a decision rule, and an auditable trail.

Requirement: PS-3(4): Citizenship Requirements (operator view)

Objective: Prevent unauthorized foreign-national access (or other non-eligible access) to systems that process, store, or transmit the defined sensitive data set by verifying citizenship eligibility prior to granting access, and by maintaining auditable evidence.

Why auditors care: This control ties personnel risk to technical access. If your access population includes third-party administrators, offshore support, or contractors, you need a clean way to prove eligibility decisions.

Regulatory text

Excerpt: “Verify that individuals accessing a system processing, storing, or transmitting {{ insert: param, ps-03.04_odp.01 }} meet {{ insert: param, ps-03.04_odp.02 }}.” ¹

What the operator must do:

1. Identify the systems in scope (systems that process/store/transmit the defined sensitive dataset), 2) identify all individuals who can access those systems (including third parties), 3) define the citizenship requirements to be met, and 4) verify and record that each individual meets the requirement before access is granted (and when access changes). ²

Note on the placeholders: NIST expresses organization-defined parameters (ODPs) using placeholders. Your job is to fill them with your organization’s defined sensitive dataset and eligibility criteria, then implement them as a decision rule. ¹

Plain-English interpretation

If someone can log in, administer, support, or otherwise access a covered system, you must confirm their citizenship status meets your defined eligibility rule. You must do this for employees and third parties. You also need to be able to prove it later, with records tied to the identities that actually had access.

This is not satisfied by a generic statement like “we prefer U.S. citizens.” It requires a check that is connected to access enablement for specific systems.

Who it applies to

Entity types (common):

• Federal information systems and programs implementing NIST SP 800-53 controls. ²
• Contractor systems handling federal data where NIST SP 800-53 controls are flowed down via contract, security requirements, or authorization package expectations. ²

Operational context (where this becomes real):

• Systems with privileged administration (cloud consoles, SIEM, EDR, IAM, CI/CD).
• Any production or support access path (VPN, bastions, remote management tools, ticket-based access).
• Third-party support arrangements (managed service providers, SOC providers, ERP admins, data center operators).
• Engineering teams with direct database access or break-glass accounts.

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

Step 1: Define scope triggers (ODP #1)

Create a short scope statement that names the data/system category that triggers citizenship verification (the placeholder in the excerpt). Examples of scope triggers you may define (choose what matches your contract and authorization boundary):

• “All systems within the [Program] authorization boundary.”
• “Systems that process/store/transmit [defined federal dataset].”
• “Privileged access to production systems within [environment].”

Deliverable: PS-3(4) scope statement approved by the system owner and compliance.

Step 2: Define the citizenship eligibility rule (ODP #2)

Document the eligibility criteria (the placeholder in the excerpt) as a rule that can be tested. Examples:

• “U.S. citizens only.”
• “U.S. persons only.”
• “Citizenship restricted by contract/customer requirement.”

Deliverable: Citizenship requirements standard (1 page) with definitions and the authority for the rule (contract clause, customer requirement, internal policy mapped to PS-3(4)).

Step 3: Build the in-scope population list (people + access paths)

You need two views of “who is in scope”:

1. Identity population view: all workforce members and third-party individuals with any account that can reach covered systems.
2. Access path view: where and how access is granted (IAM groups/roles, SSO apps, PAM roles, local accounts, break-glass).

Minimum practice:

• Enumerate all roles/groups that grant access to covered systems.
• Pull a list of users in those roles/groups.
• Include service providers with admin consoles or remote support tooling.

Deliverable: Access population report (export from IAM/PAM) and a mapping to the covered systems list.

Step 4: Embed verification into onboarding and access provisioning

Citizenship verification must be a gate for access, not a background HR activity.

Implement a workflow like this:

1. Intake: HR or third-party onboarding collects citizenship evidence (or an attestation backed by your process).
2. Verification: designated verifier confirms the evidence meets the defined rule.
3. Decision recorded: “Eligible / Not eligible / Exception requested.”
4. Provisioning control: IAM/PAM access is only granted after “Eligible” (or exception approval).
5. Recheck triggers: role change, project assignment change, new system in scope, or access expansion.

Deliverable: Provisioning runbook plus IAM/PAM gating configuration (ticket workflow, access request form, or automated checks).

Step 5: Handle exceptions with approvals and compensating controls

You will eventually face edge cases (critical incident support, specialized third-party expertise, inherited accounts).

Define:

• Who can approve exceptions (system owner + security + compliance is typical).
• Time bounds and review cadence for exceptions (define your own cadence; avoid open-ended exceptions).
• Compensating controls (examples: time-boxed access, session recording via PAM, least privilege, supervised access, segmented environment).

Deliverable: Exception register with documented approvals and compensating controls.

Step 6: Operate the control (recurring checks + drift management)

Operationalize PS-3(4) as an ongoing control:

• Run periodic access reviews for in-scope systems and verify each account has a recorded eligibility decision.
• Detect drift: new accounts added to privileged groups, third-party identities, emergency accounts created during incidents.
• Track remediation to closure.

Deliverable: Control health check log and remediation tickets.

Step 7: Create a “control card” so it runs without heroics

Write a one-page control card that states:

• Objective, owner, systems in scope, population, triggers, steps, exception rules, evidence location, and testing approach. This aligns with common audit expectations for ownership and evidence traceability. ²

If you manage controls in Daydream, store the control card, evidence checklist, and recurring test results in one place so you can answer audits without rebuilding the story each cycle.

Required evidence and artifacts to retain (minimum evidence bundle)

Keep evidence that is traceable to the actual access population. A tight bundle:

• PS-3(4) scope statement (covered systems/data definition). ¹
• Citizenship eligibility rule with definitions and approvers. ¹
• IAM/PAM exports showing the current and prior access population to covered systems (date-stamped).
• Verification records per individual (e.g., HR case ID, third-party onboarding record, verified status), stored securely with access restrictions.
• Access request tickets showing eligibility check completion before provisioning (or automated workflow logs).
• Exception register entries with approvals and compensating controls.
• Periodic access review results and remediation closure proof.

Retention period is usually governed by your contract, internal policy, or program recordkeeping requirements; define it and apply it consistently.

Common exam/audit questions and hangups (what assessors probe)

Expect these questions:

• “Show me the list of systems that process/store/transmit the defined dataset and how you decided scope.” ²
• “Pull the user list for System X admin access. Where is the citizenship verification proof for each person on this list?”
• “How do you ensure a third-party engineer can’t be added to a privileged group without verification?”
• “What happens during incident response when you need emergency access?”
• “How do you handle non-human accounts or shared accounts?”
• “Show evidence this control is operating now, not just documented.”

Hangups that slow audits:

• Verification evidence exists but is not linkable to identities in IAM.
• Third-party staff are verified at the company level, not the individual level.
• Exceptions are granted informally and never reviewed.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	What to do instead
Treating PS-3(4) as an HR hiring check only	Access can change after hiring, and third parties may bypass HR	Make citizenship verification a provisioning gate tied to IAM/PAM
Verifying “contractors at Vendor A” rather than named individuals	Auditors test by identity with access, not by supplier	Verify per individual, store records keyed to identity
No defined “covered systems/data”	Scope becomes untestable and inconsistent	Write a scope statement tied to authorization boundary or contract-defined data
Exceptions via email/Slack	No durable trail or compensating controls	Use an exception register with explicit approvals and time bounds
Ignoring indirect access	Third-party support tools can reach production	Inventory access paths (SSO apps, VPN, remote tooling, consoles)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat this primarily as an assurance and contractual compliance risk rather than a “named penalty” issue. The practical risk is access by ineligible individuals to restricted systems, which can drive authorization failures, contract noncompliance, customer audit findings, and forced access removals that disrupt operations. ²

Practical 30/60/90-day execution plan

Use phases rather than calendar promises. The goal is to get to “auditable and operating” fast, then mature.

First 30 days (stand up the rule + stop the bleeding)

• Name an owner (Security, HR, or GRC) and publish the PS-3(4) control card.
• Define the two ODPs: covered systems/data and citizenship eligibility criteria. ¹
• Identify the highest-risk access paths (privileged access, production admin) and freeze ad-hoc provisioning until verification is in place.
• Create an exception process and register, even if manual at first.

Days 31–60 (operationalize and evidence it)

• Implement workflow gating in your access request process (ticketing + IAM group approvals, or PAM request flow).
• Run your first access population export for covered systems and reconcile it against verification records.
• Remediate gaps: remove access, verify, or log approved exceptions with compensating controls.
• Create the minimum evidence bundle and store it in a single audit-ready repository.

Days 61–90 (make it durable)

• Expand scope coverage to remaining in-scope systems and indirect access paths.
• Add recurring control health checks and a drift detection mechanism (new privileged group members, new third-party accounts).
• Test your exception process during a tabletop (incident response or urgent support scenario).
• Prepare an auditor packet: scope statement, eligibility standard, latest access review, sample verification records, and exception register.

Frequently Asked Questions

Does PS-3(4) apply to third-party personnel, or only employees?

It applies to “individuals accessing a system” in scope, which includes third-party individuals with logical or administrative access. Build the control around identities in IAM/PAM, not employment status. ¹

What counts as “verify” for citizenship requirements?

“Verify” means you perform a check that supports an eligibility decision before granting access and can prove it later. Your method should be documented, consistently applied, and tied to the identity that received access. ¹

Can we rely on a staffing firm’s attestation?

You can incorporate third-party attestations into your process, but auditors will still expect you to demonstrate that each individual with access met the requirement. If you accept attestations, document how you validate them and how you handle disputes or changes.

How do we handle emergency incident access?

Define an exception path with explicit approvers and compensating controls like time-boxed access and PAM session logging. Record the incident ID, approver, duration, and post-incident review outcome in the exception register.

What about non-human accounts (service accounts, automation)?

PS-3(4) targets “individuals,” but auditors will ask how service accounts are managed because they can be used by individuals to access systems. Tie service accounts to an accountable owner, restrict interactive use, and control them through PAM or strong secrets management.

We have a global team. Can we scope PS-3(4) to only certain systems?

Yes, if your defined ODP scope is defensible and documented, such as restricting it to an authorization boundary or systems handling the defined dataset. Then enforce technical segmentation so out-of-scope personnel can’t reach in-scope systems. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5