This post explains how to design, configure, and operate Identity and Access Management (IAM) and automated deprovisioning workflows to satisfy the personnel-security expectation behind PS.L2-3.9.2 (NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2), with practical, technical steps, small‑business examples, and evidence-gathering guidance for auditors.
What PS.L2-3.9.2 requires and the objective
The core objective of PS.L2-3.9.2 is to ensure that when personnel are terminated or transferred, their authorizations to access Controlled Unclassified Information (CUI) and organizational systems are revoked or adjusted promptly and auditable. For Compliance Framework implementers this means: define an identity lifecycle, automate removal or role change of privileges, capture audit evidence, and ensure device/secret reclamation where needed.
Designing the identity lifecycle and automation architecture
Start by mapping all identity consumers and trust boundaries (cloud IdP, on‑prem AD, AWS, G Suite, GitHub, VPN, PAM, MDM). Define canonical identity source (usually HRIS: Workday, BambooHR, ADP). Implement an authoritative HR → IAM flow: HR event (termination/transfer) → webhook or SCIM call → identity provider (Okta, Azure AD, Google Cloud Identity) → downstream SCIM/provisioning connectors and automation scripts to on‑prem and cloud services. Use role‑based access control (RBAC) and dynamic/attribute-based groups so the HR attribute change (title, active=false) triggers automatic group membership changes rather than manual per-application edits.
Example implementation - small business
Example: A 50‑employee small business using Azure AD, Intune, and AWS. Configure Workday (or BambooHR) to emit a termination webhook to a small Azure Function. The function calls Microsoft Graph to set account "accountEnabled": false, removes user from Azure AD groups, calls Intune to wipe corporate devices, and calls an AWS Lambda (with cross-account role) to deactivate IAM console access and set access keys to Inactive. Use Azure AD dynamic groups for role membership so when jobTitle changes, group membership adjusts automatically and downstream permissions follow suit.
Key technical steps and scripts to automate deprovisioning
Implement these concrete actions in your automation playbook: 1) disable console login (set accountEnabled=false or update-login-profile to disable password), 2) deactivate/deactivate API/secret keys (AWS access keys -> Inactive; GitHub personal access tokens via API), 3) remove from privileged groups and revoke group-based entitlements, 4) revoke OAuth tokens and clear SSO sessions (IdP session revocation APIs), 5) initiate MDM wipe for corporate devices, 6) rotate any shared secrets/credentials the user had access to (shared vault passwords), and 7) create an evidence bundle (system logs, automation runbook outputs, HR event record) stored in your compliance repository. Example AWS CLI commands: aws iam update-login-profile --user-name alice --no-password-reset-required (or delete), and aws iam update-access-key --user-name alice --access-key-id AKIA... --status Inactive.
Integration points, connectors, and tools
Use standard connectors to reduce custom code: SCIM for user lifecycle to SaaS apps, SAML/SSO for centralized authentication, provisioning connectors for Okta/Azure AD/OneLogin, and MDM APIs (Intune/Jamf) for device control. For secrets and privileged accounts use a PAM or secrets manager (CyberArk, HashiCorp Vault, AWS Secrets Manager) and automate rotation when a user loses entitlement. For small teams, SaaS products with built‑in life‑cycle automation (Okta Workflows, Microsoft Power Automate, Zapier for HR events) plus simple scripts and stored logs are often sufficient and cost-effective.
Operational policies, SLAs, and audit evidence
Establish written policies and SLAs: e.g., "Terminate: immediate disable on HR termination event; automation to run within 15 minutes; full deprovisioning evidence stored within 24 hours"; "Transfers: change role and access within 24 hours, with attestation." Document exceptions (legal hold, retained access for continuity) and add approval steps for exceptions. For audit evidence, collect: HR record of action, IdP system logs showing account change, scripts/logs that show API responses, MDM wipe confirmations, and downstream system logs (AWS CloudTrail, Okta System Log). Retain logs per your compliance retention requirements and the Compliance Framework guidance.
Risks of not automating or implementing properly
Failure to promptly revoke access creates significant risks: orphaned accounts enable exfiltration of CUI, lateral movement by former employees or compromised accounts, stealthy persistence via long-lived API keys, and failing audits or contract penalties. For small businesses, a single unrevoked admin key can result in ransomware, data exposure, and loss of DoD contracts. Additionally, manual processes increase human error and inconsistent evidence trails, making demonstrating compliance difficult.
Compliance tips and best practices
Best practices: implement least privilege and group-based entitlements, prefer suspension over deletion for forensic needs, perform quarterly access attestation and monthly privileged-access reviews, test deprovisioning workflows in a staging environment, maintain a documented incident/rollback plan, encrypt and centralize your evidence store, and perform periodic simulated terminations to verify the automation end‑to‑end. Keep a short, auditable SLA for termination actions (immediate/within hours) and ensure HR, IT, and Security responsibilities are clearly owned and communicated.
In summary, meeting PS.L2-3.9.2 requires building an authoritative HR→IAM lifecycle, automating deprovisioning across all identity consumers (cloud, on‑prem, PAM, MDM), collecting complete audit evidence, and enforcing policy with SLAs and regular attestations; for small businesses this is achievable with SCIM/connectors, simple serverless functions, and careful documentation—reducing risk, improving security posture, and producing the evidence auditors require.
