Essential Cybersecurity Controls (ECC – 2 : 2024), Control 1-9-5 requires timely and verifiable removal of access when an individual no longer needs it — for example on termination or role change — and this post shows how to build an automated, auditable deprovisioning workflow with IAM tools to meet that requirement in an operational, small-business context.
What Control 1-9-5 requires (practical interpretation for Compliance Framework)
At a Compliance Framework level, Control 1-9-5 expects a defined single source of truth for identity state (normally the HR or contractor management system), automated propagation of state changes to access control systems, documented SLA for revocation (commonly 24 hours for terminations, immediate for privileged accounts), and retained evidence (logs/attestations) showing the access removal occurred. The implementation must cover human users, contractors, and non-human identities (service accounts, API keys), and include special handling for legal holds or ongoing investigations.
Designing an automated deprovisioning workflow
An effective design has four building blocks: (1) a canonical identity source (HRIS such as BambooHR, Workday, or Google Workspace directory) that emits events; (2) an identity provider (IdP) and provisioning engine (Okta, Azure AD with SCIM, JumpCloud) that normalizes and enforces state; (3) connectors/playbooks to downstream apps and infrastructure (SaaS via SCIM, AD via PowerShell, cloud providers via CLI/API); and (4) logging and attestation (SIEM, immutable storage, and an access review cadence). Model the workflow as a termination/event pipeline: HR event -> IdP workflow -> immediate disabling of access -> removal/rotation of credentials -> confirmation and logging. Include exception channels (legal hold, privileged break-glass) and human approval gates where required by policy.
Technical implementation steps (concrete)
Implement the pipeline in these technical steps: 1) Configure your HRIS as the source of truth and create a termination/job-change webhook or scheduled sync. 2) Configure SCIM or provisioning connectors in your IdP so that user.accountEnabled (or equivalent) maps to downstream accounts. 3) Enforce role-to-group mapping in the IdP so role changes remove relevant groups. 4) Add playbooks for infrastructure: run an AD disable script, disable SSO session tokens, revoke OAuth grants for SaaS, and rotate or delete cloud API keys. 5) Record proof: capture date/time/user/event-id from HRIS and IdP, and collect downstream API confirmation responses into an audit artifact (S3, WORM storage, or SIEM). 6) Periodically run access recertification and orphaned-account reports.
Example commands and APIs you can use
Small technical snippets you can adapt: to disable an AD account with PowerShell: Import-Module ActiveDirectory; Set-ADUser -Identity "jdoe" -Enabled $false; Remove-ADPrincipalGroupMembership -Identity "jdoe" -MemberOf (Get-ADGroup -Filter '{Name -like "SaaS-*"}'). For AWS, list and disable user keys: aws iam list-access-keys --user-name jdoe; then aws iam update-access-key --user-name jdoe --access-key-id ABC123 --status Inactive or aws iam delete-access-key. For Microsoft Entra (Azure AD) via MS Graph, PATCH /users/{id} with {"accountEnabled": false}. For SCIM-enabled SaaS apps, sending a PATCH to /Users/{id} to set "active": false will normally deprovision: ensure you use SCIM 2.0 and check each app's deprovision behavior (disable vs delete). Automate these with serverless functions (AWS Lambda, Azure Functions) triggered by the IdP, or use the IdP's native Workflows engine.
Small-business scenario: a concrete workflow
Imagine a 75-person company using BambooHR (HRIS), Okta (IdP), Google Workspace, and AWS. Implementation steps: configure BambooHR to POST a termination webhook to an Okta inbound Workflows endpoint. Okta workflow sets the user's "status" to DEPROVISIONING, removes group memberships, and pushes a SCIM "active=false" to Google Workspace and other SaaS. A Lambda (subscribed to an Okta webhook) runs an AWS playbook to deactivate IAM console access and rotate/delete access keys for that username, and writes a JSON audit record to an S3 bucket with event timestamps and API responses. The security team receives a Slack notification for privileged accounts so they can verify any exception. Monthly, a scheduled job queries Okta and AWS for active accounts that have no corresponding HR record and generates a report for remediation.
Compliance tips and best practices
Tips to ensure you meet Control 1-9-5: enforce one authoritative identity source; codify SLAs in policy (e.g., termination = immediate disable, credential removal within 24 hours); instrument every automated step with idempotent playbooks and explicit success/failure logs; implement periodic orphaned-account scans and quarterly attestation; treat service accounts differently—use managed identities and short-lived credentials (OIDC tokens, AWS STS) rather than long-lived keys; and maintain an exception registry with documented approvals and audit trails. Test the workflow quarterly with simulated terminations and review the audit artifacts to make sure the evidence would satisfy an auditor.
Risks of not implementing automated deprovisioning
Failure to automate and verify deprovisioning leads to stale and orphaned credentials, increased insider risk, data exfiltration opportunities, and persistent footholds that attackers can use for lateral movement. For compliance, the organization risks failed audits, regulatory fines, and contractual penalties. Operationally, manual offboarding is slow and error-prone; a single leftover cloud key or SaaS session can allow exfiltration or ransomware escalation long after an employee leaves.
Summary: to meet ECC – 2 : 2024 Control 1-9-5 you need a documented, automated deprovisioning pipeline anchored on a single HR source of truth, integrated IdP provisioning (SCIM/SSO), playbooks for infrastructure credentials, and robust logging/attestation. For small businesses this can be achieved with commercial IdPs (Okta/Azure AD/JumpCloud), HRIS webhooks, a few serverless playbooks to handle cloud APIs, and regular testing and reporting — all of which reduce risk and provide the audit evidence required by the Compliance Framework.
