What SOX user access removal requires and why auditors test it
Imagine a compliance lead two weeks before a SOX ITGC test of terminations. The auditor has pulled a sample of leavers from the HR system and wants proof that each person's access to the general ledger, the consolidation tool and the database behind them was removed on or near their last day. User access removal requires management to disable or remove access to financially significant applications, databases and infrastructure promptly when an employee or contractor leaves or changes role, and to keep evidence that the removal happened. Auditors test it because a former employee who still holds a working login can post, approve or alter financial data, and the control only holds if the organization can show it closes that door every time.
The risk sits in the link between access and financial reporting. PCAOB AS 2110 lists unauthorized access to data and improper changes to data among the IT risks to internal control over financial reporting, and access that persists after termination is a direct route to both. When the auditor plans the audit under AS 2201, a weak removal control also means reliance on automated controls in that area becomes harder to justify, because those automated controls depend on the access restrictions working. That is why removal failures often surface as deficiencies that spread beyond a single application.
Removal is a common point of failure because the process crosses systems that rarely agree. The HR system records the termination date, but the application, database and directory accounts are created and maintained separately, sometimes by a different team, and a manual ticket may be the only bridge between them. Contractors often sit outside HR records entirely, shared and service accounts have no named owner to disable, and a role change can leave old entitlements in place because nobody removes the previous role. Confirm with your own environment which system is the authoritative source for leaver status, which accounts exist outside the directory, and how a transfer is handled, since each gap is where auditors will look first.
Which systems, people and events fall in SOX removal scope
Removal scope is set by the financial reporting risk each system carries, not by a single list of applications. The cards below cover the systems, identities and events that auditors expect management to define before they test whether access was removed on time.
In-scope applications and databases
Start from the applications that generate, process or summarize financially significant data, then add the databases behind them, since direct database access can change figures without passing through the application. Auditors will ask how the in-scope list was built and whether it matches the systems named in the ICFR scoping documentation. Confirm that each application's user store and each database's local accounts are included, not only the front-end login.
Operating systems and infrastructure
Access to servers, hypervisors, network devices and cloud consoles can reach financial data even when no finance user holds an application login. Removal scope should cover the directories and identity sources that feed those systems, such as the directory service that authenticates administrators. Ask whether local operating system accounts on in-scope hosts are removed as part of the same process or tracked separately.
Terminations, transfers and contractor end dates
Removal scope is not limited to resignations. Involuntary terminations, role changes that leave old access in place, and contractor engagements that end on a fixed date all create access that should be revoked. Each event type needs its own trigger in HR or vendor management records, because a transfer that is never reported to IT will not start a removal. Ask which event types feed the removal process and who owns each trigger.
Leaves of absence and suspensions
Employees on extended leave or under suspension still hold active credentials, and auditors often ask how that access was handled during the absence. Decide whether access is disabled, reduced or left in place, and document the rule. The decision matters for the leaver population definition: a person who is inactive but not terminated may still fall outside a termination report and be missed in testing. Confirm the policy and the owner who applies it.
Service, shared and generic accounts
Service accounts that run jobs and shared accounts used by several staff members are often excluded from a people-based leaver list. They still carry access to financial systems and can outlive the people who set them up. Decide whether these accounts are in scope, assign an owner to each one, and define how their access is reviewed when that owner leaves. Ask for the inventory of such accounts as part of the scope evidence.
Defining the leaver population
The population of leavers is the set of people and accounts the auditor will compare against access records, so its definition controls the test. Specify the date range, the source system for terminations, and whether identities from identity providers, HR systems and vendor lists are merged. Auditors commonly ask how completeness of that population was confirmed. Ask the process owner to show how the report was generated and reconciled.
How auditors compare termination lists with access records
Auditors test whether leavers lost access on time by building a population first, then sampling from it. They ask HR or the ticketing system for a complete list of employees and contractors who left or changed roles during the period, and they confirm that list is complete before using it. A common check is to compare the list against payroll terminations or badge deactivations for the same window. If the population is missing people, a clean sample proves nothing, so the completeness check is where many tests start to fail. Confirm with your HR and identity teams which report is the system of record for terminations, who generates it, and whether contractors appear in it at all.
From the complete population, the auditor selects a sample of leavers and traces each one to removal dates in every in-scope application, database and directory. Under PCAOB AS 2201, testing operating effectiveness combines inquiry of personnel, observation of operations, inspection of documentation and re-performance of the control. For access removal, that usually means interviewing the access administrator, inspecting the removal tickets or directory logs, and sometimes re-running the deprovisioning step in a test environment. The standard does not set a number of days for removal. The threshold is whatever management documented in the control design, so the policy must state the deadline, the trigger and the owner. Decide that deadline before the audit period starts, because an auditor will measure against the written design, not a deadline set after the fact.
Expect the auditor to ask how automated deprovisioning fits this test. Where an identity platform pushes deletions to downstream applications, for example through a SCIM provider such as the one in authentik, the auditor may test the provisioning configuration and its logs as well as individual samples. Confirm which applications sit outside the connector, since those accounts will need manual removal evidence. Also confirm how the platform handles a sync failure, because a missed deletion that is only caught by a periodic full sync may still fall outside your documented deadline.
How an assessor tests user access removal
This table walks through each step an external auditor or internal auditor takes to test leaver access, from the design walkthrough to inquiry, with the evidence requested at each step. Read it as a checklist of what to have ready before fieldwork, and note the failure patterns that most often turn a clean design into an exception.
| Test step | What the assessor does | Evidence requested | Where it usually fails |
|---|---|---|---|
| Design walkthrough | Traces how a leaver's termination reaches HR, IT and the application owner, and who triggers each removal. | Written procedure, HR offboarding workflow, named owners for each in-scope application. | Procedure names HR as the trigger but no step covers contractors or accounts outside the directory. |
| Termination population completeness | Checks that the list of leavers and contractor exits is complete for the period under test. | HR termination report, contractor end-date report, reconciliation to the period start and end. | HR report omits contractors, rehires or transfers, so the population is incomplete before any sample is drawn. |
| Sample of leavers traced to removal | Selects leavers from the population and traces each to the date access was disabled in every in-scope application. | Termination ticket or HR record, system audit log showing disable date, last login date. | Access disabled days or weeks after the termination date with no documented exception. |
| Inspection of disabled accounts | Reviews that sampled accounts are disabled or deleted, not only hidden, and that no active role assignments remain. | Account status export from the directory and application, role or group membership listing. | Account marked disabled while group memberships, API tokens or shared-role access stay active. |
| Secondary application check | Looks beyond the primary ERP or ledger to reporting tools, databases, file shares and admin consoles tied to financial data. | List of in-scope secondary systems, deprovisioning records for each, or a documented reason they are excluded. | Terminated users still active in a reporting tool, database login or spreadsheet server that was never added to the offboarding checklist. |
| Access log review | Inspects logs for any sign of use after the termination date. | Authentication logs for sampled leavers covering the period between termination and disable. | Logs are not retained long enough to cover the test period, so the assessor cannot confirm no post-termination logins. |
| Inquiry | Asks application owners and HR how the process works in practice and how they learn of exits that happen outside normal channels. | Interview notes, owner confirmations, description of any emergency or same-day termination path. | Answers differ from the written procedure, for example owners say they rely on a manual email. |
How to implement timely removal step by step
This sequence turns leaver removal from an informal habit into a documented process that auditors can trace from an HR termination to the closed account in each in-scope system. Each step produces an artifact that proves the control was designed and operates as written.
Define the leaver trigger from HR
Agree with HR which events start removal: resignation, termination, end of contract, transfer to a role without the same access, and extended leave. Document the source system, the field or status that marks a leaver, and who receives the notice. The step is done when HR and IT sign a short trigger definition and the feed of leaver records is confirmed to reach the access team. Ask HR to confirm which employment types, such as contractors and agency staff, appear in that feed, because gaps usually sit there.
Inventory in-scope systems and removal methods
List every financially significant application, database, operating system, network component and shared account that holds user access, following the scope set by management's ICFR assessment. For each system, record the owner, the account store it uses (directory, local accounts or application users) and the removal method, whether automated through an identity provider, a scripted process or a manual ticket. The output is a system inventory with a removal method per row, reviewed by the control owner. Systems with only manual removal are the first candidates for automation.
Map identity sources and single sign-on paths
Trace how users reach each in-scope system. Where a central directory, single sign-on provider or identity broker controls login, disabling the central identity can cut off access to every application that depends on it. Where an application keeps its own user table, removal must be done there as well. Record which accounts sit outside the central identity, such as local administrator or database logins, because these typically need a separate removal step. The output is a dependency map that shows which removal actions reach which systems.
Automate deprovisioning where the platform supports it
For systems that accept automated provisioning, configure the connector or provisioning protocol so that deleting or disabling a user in the identity source propagates to the application. Open-source identity platforms can handle this for some targets. For example, the authentik SCIM provider pushes user and group deletions to target applications and runs a full sync every hour, so the team should confirm that the target application honors deprovisioning messages. Test with a dummy leaver account, then record the configuration and the test result. Manual steps remain for any system the connector cannot reach.
Set and document the removal timeframe
Write the removal deadline into the control design, measured from the effective termination date or from the HR notice, and specify separate expectations for high-risk privileged accounts if the organization chooses them. Confirm the deadline with the control owner, internal audit and the external auditor before the control is relied on, because the timeframe is the test criterion. Keep the approved document with its version history. The control is ready when the written timeframe, approvers and effective date are on file.
Execute removals and record the evidence
When a leaver record arrives, the access team disables or removes each account in the inventory, using the automated path where it exists and a ticket for manual steps. Each ticket should name the employee, the systems, the completion time and the person who performed the action. Retain configuration screenshots and automated logs for automated paths, since these show the mechanism worked as designed. The step is complete when every in-scope account for a leaver shows a closed state with a traceable ticket or log entry.
Reconcile HR terminations against system accounts
At a set frequency, compare the list of HR terminations in the period with active accounts in each in-scope system. Any active account that belongs to a terminated person, or any terminated person with an active account, becomes an exception with an owner and a due date. Keep the population, the filter criteria and the comparison output, because auditors will ask whether the list used to test removals is complete. The reconciliation report, signed by the reviewer, is the artifact that proves removals were checked, not just assumed.
Investigate exceptions and document follow-up
For each reconciliation exception, determine whether the account was used after the termination date by reviewing authentication and activity logs where available. Record the finding, the corrective action, any impact on financial data and the root cause, such as a missed feed or a contractor outside the HR system. Feed recurring causes back into the trigger definition and the inventory. The step closes when each exception has a documented resolution and an owner has signed off, and the remediation approach is discussed with the auditor before year end.
Evidence that passes for each removal control
The HR system is usually the first record that a person has left or changed roles, so auditors use its termination list as the population they test against. The list proves who was separated and on what effective date. It does not prove that any system access was removed, so it is the starting point for the test rather than the evidence of removal itself.
- Effective date fields: Confirm the record shows the separation date that drives access removal, not only the date the form was entered.
- Contractors included: Confirm contractors and temporary staff appear in a feed or a separate list, since they are often missing from HR exports.
- Role changes captured: Confirm transfers that remove prior duties are recorded, because access tied to the old role is a removal event too.
- Change history retained: Keep prior versions or audit logs of edited records so an auditor can see when a date was corrected.
- Completeness check: Keep a count or extract date showing the list was pulled for the full period under audit.
Before fieldwork, confirm with HR which report the auditor will receive and whether the period covers the full audit window.
Ticketing records show that removal was requested, approved and worked by a named person. For a leaver, the ticket links the HR event to the revocation action. Auditors read these tickets to confirm that the request came from an authorized source and that the work was closed with a timestamp and a result.
- Request source: Show that the request came from HR, a manager or an automated workflow, with the trigger recorded.
- Timestamps: Record when the request was opened, when access was revoked and when the ticket was closed.
- Scope of revocation: List each application, directory group and infrastructure account removed, not just a general closure note.
- Ticket linkage: Tie each ticket to the employee identifier so it can be matched to the termination list.
- Exception handling: Keep approval records for any late removal, with the reason and the compensating step taken.
A ticket that says "access removed" with no system list, date or operator will usually be rejected, so ask the auditor which fields they will sample.
Identity provider logs record when accounts were disabled, deleted or removed from groups, and when a removed user last signed in. They are the strongest evidence that central access actually changed, provided the logs are complete and retained for the audit window. The logs prove event timing and actor, which is the detail auditors look for when they check for logins after separation.
- Disable and delete events: Retain events that show account disablement and group removal with timestamps.
- Last login records: Check that no successful sign-in occurs after the effective separation date for sampled leavers.
- Provisioning events: Where the identity provider pushes deprovisioning to applications, keep the connector logs showing the downstream action.
- Log retention: Confirm log storage covers the full audit period and that exports are protected from alteration.
- Time synchronization: Confirm the identity provider and the target systems use synchronized clocks, so timestamps can be compared.
Auditors will not accept central logs as proof for applications that authenticate locally, so confirm which systems sit outside single sign-on before relying on them.
Application user listings are exports of accounts that exist in each in-scope system, including status and role assignments. They show the current state of access and are the record auditors compare against the termination list. A listing proves that a leaver's account is absent or disabled at the time it was taken, which is why its date and completeness matter.
- Export date and parameters: Record when the listing was produced, by whom and with what filters, so it can be reproduced.
- Coverage of local accounts: Include database accounts, operating system users and application-local logins, not only the single sign-on population.
- Status fields: Show whether each account is active, locked or disabled, and confirm disabled accounts still carry no active roles.
- Shared and service accounts: Flag any leaver who is known to have held shared credentials, since those require a separate removal step.
- Reproducibility: Keep the query or report definition so the auditor can rerun it and confirm the population is complete.
Before sending a listing, compare its row count with the source system and confirm the export was not filtered to active users only.
Reconciliation reports compare the termination list against application and directory records and document each difference with its resolution. They are the control evidence that a periodic check happens and that exceptions are worked, not just that removals occurred. Auditors use them to judge whether the removal control detects failures and whether the people performing it are independent of the access they review.
- Defined frequency: Set and document how often the comparison runs, and keep evidence that each run occurred.
- Matched population: Show the leaver list, the application listing and the match logic used, with unmatched records listed.
- Exception resolution: Record each difference, the owner, the action taken and the closure date.
- Reviewer evidence: Show who reviewed the report and their sign-off, with the review dated.
- Independence: Confirm the reviewer does not hold the access being checked or administer the systems under review.
A reconciliation with no recorded exceptions over a long period invites questions, so confirm the auditor expects to see the matching logic in addition to the clean result.
How open-source identity platforms support removal evidence
An identity platform can make removal faster and easier to prove, but only when it sits between HR records and financial applications. The cards below cover four open-source options and the checks each one needs before an auditor can rely on its records.
authentik SCIM provisioning
The authentik SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0. It also runs a full sync every hour and deprovisions users from the target when they lose access to the application. For removal evidence, confirm that a termination in the source directory reaches each in-scope application, and test whether the sync log shows the removal date. A full hourly sync reduces drift but does not replace checking that the target actually disabled the account.
FreeIPA central user directory
FreeIPA uses 389 Directory Server as a multi-master LDAPv3 directory that stores users, groups, hosts and other network objects. Access control and delegated administration run through its web UI and command line tools. Removal evidence depends on who holds the delegated rights to disable accounts, so list those administrators and confirm that disabling a user in FreeIPA blocks sign-in to the Linux hosts and applications that authenticate against it.
Keycloak single sign-on
Keycloak provides single sign-on, so users authenticate with Keycloak instead of each application. It supports OpenID Connect, OAuth 2.0 and SAML 2.0, and can broker logins to existing OpenID Connect or SAML 2.0 identity providers. Disabling a user in Keycloak removes the single sign-on path for every connected application at once. Auditors will still ask whether local application accounts, API tokens and service credentials were also removed, so test those paths separately.
Zitadel identity brokering
Zitadel acts as a central identity broker, so users sign in through external providers such as Google, Microsoft Entra ID or Okta over OpenID Connect, SAML 2.0 or LDAP. Applications trust Zitadel instead of each provider. Removal then has two points of failure: the employee's account at the external provider and the brokered link in Zitadel. Confirm that terminating the upstream account blocks brokered sign-in, and that the Zitadel record is updated in the same cycle.
Licensing and support obligations
The four products use different licenses: authentik is MIT, FreeIPA is GPL-3.0-or-later, Keycloak is Apache-2.0 and Zitadel is AGPL-3.0-only. License terms affect how you may modify, distribute and host each platform, and therefore who must maintain the patches and the audit trail. Ask counsel to confirm obligations for your deployment model, and confirm vendor support terms in writing, because open-source licenses do not guarantee support for SOX evidence.
Confirm behavior in your environment
Vendor documentation describes what each product is designed to do, but your configuration, connectors and target applications determine what happens to a removed user. Test each in-scope path with a named test account, record the timestamps for the source change, the sync or revocation, and the target disablement, and retain the results for the auditor. Document any application that does not support deprovisioning and assign a compensating review for it.
What meeting user access removal costs
This table breaks down the cost components of keeping access removal timely and provable under SOX, showing who is paid, whether each cost is one-time or recurring, and what pushes it up. Use it to build a quote request, since no figures are published here and each cost depends on your environment. The main takeaway is that open-source identity tools reduce license spend but leave integration, reconciliation and audit evidence costs in place.
| Cost component | Who is paid | One-time or recurring | What drives it |
|---|---|---|---|
| Identity tooling or licenses | Software vendor, or none for open-source platforms | Recurring for commercial licenses; open-source removes license spend only | Number of users, applications and directories; support subscriptions if you buy them |
| Connector and HR feed integration | Implementation partner or internal engineers | One-time, with later maintenance when systems change | Number of in-scope applications, quality of HR termination data, and how many use custom APIs |
| Deprovisioning workflow build and testing | Implementation partner or internal engineers | One-time, then change work as applications change | Whether removals flow automatically through SCIM or require manual tickets, and how many exceptions you handle |
| Periodic termination reconciliation | Internal control owner, IT operations or co-sourced staff | Recurring at the frequency you set, often monthly or quarterly | Contractor volume, number of directories and applications, and how often HR and access records drift |
| Auditor sampling and testing | External auditor | Recurring each audit cycle | Population size of terminations, number of in-scope systems tested, and how well evidence is already organized |
| Readiness review or external testing | Consultant, co-sourced internal audit or security testing firm | Often one-time before an audit, or periodic | Scope of systems reviewed, first-year maturity of the process, and whether findings from prior audits remain open |
Who owns removal, who implements it, and what the auditor checks
The organization owns the removal control. Management designs the termination policy, decides which applications and infrastructure fall inside SOX ITGC scope, assigns owners for each system, and performs the reconciliation that shows whether access was removed on time. An implementation partner or auditor can support these tasks, but neither can accept the risk that a former employee keeps access to a ledger. Management also has to be able to explain the control in its own words during a walkthrough.
- Termination policy: Define who triggers removal, the deadline for each access type, and what happens to shared and service accounts.
- Scope list: Keep a current list of in-scope applications, databases, operating systems and directories with named system owners.
- Reconciliation review: Compare the HR termination and transfer list against active accounts on each in-scope system, then document follow-up on exceptions.
- Exception handling: Record every late or missed removal, its cause, and the corrective action with a reviewer's sign-off.
- Retained evidence: Keep the reconciliation outputs, reviewer sign-offs and exception logs so they can be produced for the auditor without rebuilding them.
Before engaging anyone, confirm that a named manager can explain each step of the control and point to the evidence it produces.
An implementation partner prepares the systems and evidence that the organization's control depends on. For removal, that usually means connecting the HR source of truth to the identity platform, configuring automated deprovisioning to target applications, and building exports that show accounts, disabled dates and group memberships. The partner works inside the client's own infrastructure and hands over documentation, but it does not approve removals, sign reconciliations or represent the control's operating effectiveness.
- Integrations: Connect the HR system, directory and in-scope applications so that terminations flow through a documented path.
- Automation: Configure provisioning and deprovisioning rules, for example with an identity provider's SCIM provider that pushes deletions to target applications.
- Evidence exports: Build scheduled reports of active and disabled accounts that the organization's reviewer can compare against the termination list.
- Runbooks: Document the configuration, change history and manual fallback steps for systems that cannot be automated.
- Testing support: Help the organization test a sample of removals before the audit period, without replacing management's own testing.
Confirm in the statement of work who will maintain the configuration after go-live and who owns the exports if the partner's engagement ends.
The external auditor tests whether the removal control operated effectively during the period. Under PCAOB AS 2201, testing combines inquiry, observation, inspection of documents and re-performance. For removal, the auditor typically takes the termination population for the period, selects a sample of leavers and transfers, and checks that each one's access ended by the defined deadline. The auditor also evaluates whether the reconciliation population is complete and whether the reports used are reliable.
- Population checks: Test that the termination list is complete by comparing it with other sources such as payroll or contractor records.
- Sampling: Select leavers and transfers and inspect account status and disable timestamps on each in-scope system.
- Report reliability: Assess how the company's access reports are generated, which may involve testing the underlying query or export logic.
- Independence limits: The auditor may not design, implement or operate the removal control or its automation, and may not prepare the evidence it tests.
- Reporting: The auditor issues the attestation or opinion on ICFR. Only the independent auditor issues it, not a partner.
Confirm with the auditor, before fieldwork, which populations and samples they expect and how they want exports produced.
Where removal controls usually fail and how to close each gap
Removal controls rarely fail in one place. They fail where the list of people who should lose access does not match the systems that grant it, and where nobody checks the two against each other. The cards below name the gaps auditors most often find and the closing action for each.
Contractors missing from HR feeds
Contractors, consultants and temporary staff usually sit outside the HR system that drives joiner, mover and leaver events. Their accounts persist after the engagement ends because no termination event fires. Check whether every contractor account has a named sponsor and an end date, and whether that end date triggers removal without anyone remembering to file a ticket.
Local accounts outside the identity provider
Financially significant applications, databases and servers often keep local user stores that the central identity provider never touches. Disabling the directory account leaves the local login active. Inventory every application that authenticates locally, and confirm that the leaver process covers each one or that local logins are disabled at the source.
Manual tickets without reconciliation
A leaver ticket that is closed without anyone comparing it to the live access list proves only that a ticket was filed. Auditors will compare termination listings with access records and look for accounts still active after the leaver date. Add a periodic reconciliation between the termination list and the enabled accounts in each in-scope system, with the reviewer's sign-off retained.
Role changes that keep prior access
When someone moves to a new team, access is often added for the new role and the old access is never removed. The result is accumulated privilege that no current manager intended. Make the mover process remove prior role grants as a required step, and confirm that the access list for the new role is the only list that survives the transfer.
Shared accounts with no owner
Shared and service accounts often hold database or application rights that remain usable after the people who knew the password have left. Nobody is accountable for disabling them, so they outlast every leaver event. Record a named owner for each shared account, rotate its credentials when that owner leaves, and confirm the account appears on the access review population.
Removal without a centralized directory
Where each application runs its own user store, removal means logging into every system and deleting the account by hand. Some teams automate this with provisioning connectors, which push deletions from a central source to target applications. Ask which in-scope applications support automated deprovisioning, which need manual steps, and who evidences each one.
Questions buyers ask about user access removal
What drives the cost of user access removal work for SOX ITGC?
The cost depends mainly on how many financially significant systems are in scope, how many of them have their own local accounts instead of central sign-on, and how much of the HR-to-IT termination flow already exists. Cost components are the time spent mapping in-scope applications, databases and infrastructure, integrating the HR source with directories and identity tools, configuring deprovisioning for each application, and building the evidence that shows removals happened on time. Fixed-scope engagements are priced from a written scope, so ask any provider to list each application, each integration and each evidence report included. Recurring costs include quarterly or monthly reconciliation of termination lists against access records and keeping integrations working after upgrades. DeployOpen does not publish a price list; a quote follows from the agreed scope.
How long does it take to implement timely access removal?
Duration follows scope rather than a fixed period. Timing depends on how many applications and directories need connectors, whether a central identity provider already exists, how clean the HR and directory data is, and how many change windows the business allows for production systems. Applications that accept automated provisioning move faster than those that need manual steps or vendor tickets. Agree on a written timeline with milestones for the HR feed, the directory, each in-scope application and the evidence process before work starts. Confirm with your own change calendar and the auditor's testing period how much time must pass with the control operating before the audit window opens.
What do HR and IT teams need to provide for access removal?
HR must send a reliable, timely signal for every termination, transfer and leave, and it must be the same signal that auditors will compare against access records. IT needs the authoritative list of in-scope applications, the owner of each application, the account types in use (named, shared, service and local), and approval of who may disable or delete accounts. Practical inputs include a clear definition of the termination effective date, a process for contractors whose end dates live in a vendor system or a project tracker, and a named contact for emergency removals. Without these inputs, removals depend on manual emails and the population the auditor samples is hard to define.
Can our own team implement SOX access removal in-house?
Yes, many organizations do this internally, and the decision depends on skills and capacity rather than on whether the work is possible. An internal team needs experience with directory services, SCIM or other provisioning standards, application administration and audit evidence. The work is continuous: new applications, reorganizations and upgrades all change the population that must be covered. Some organizations keep ownership of the controls and the reviews while bringing in an implementation partner to build and document the integrations. An external auditor or certification body issues any report or opinion, and management still owns the control. Ask any partner to state which parts it builds, which parts you must operate and which evidence you keep.
What do auditors sample when testing user access removal?
Auditors typically start with a population of terminations and transfers from the HR or contractor records for the period, then select samples and trace each one to the access record in every in-scope application. They also check that the termination list is complete by comparing it against the directory and application accounts, which is why unmatched active accounts often become findings. For each sample they look for evidence of the removal date, the person who performed or approved it, and whether it happened within the timeframe the company defined. Under PCAOB AS 2201, testing combines inquiry, observation, inspection of documents and re-performance, so keep the termination records, system logs and reconciliation reports that support each step. Confirm the exact sample sizes and period with your auditor.
How should we handle contractors and temporary staff in access removal?
Contractors often fall outside the HR feed, so they are the most common gap in removal testing. Bring contractor identities into the same directory and assign each one an end date tied to the contract or the sponsoring manager. Require a named sponsor who confirms the end of engagement, and make the account expiry automatic where the identity platform allows it. Vendors that operate your systems should also have their access removed when their contract ends, which links this topic to SOX ITGC for cloud and outsourced IT. Keep a separate list of contractors with their sponsors and end dates so the population can be reconciled to access records during the audit.
How do we handle legacy applications that cannot be integrated?
Legacy applications with local accounts or no provisioning interface need a documented workaround rather than an assumption that removal happens. Options include a manual removal procedure with a ticket, a checklist that the system owner signs, a scheduled report of active accounts compared with the termination list, or placing the application behind a central sign-on layer so that disabling the central identity removes access. Keycloak can provide single sign-on through OpenID Connect or SAML 2.0 for applications that support those protocols, and Zitadel can broker sign-in from external providers. Each option must be tested for the accounts it covers, and the reconciliation must cover local accounts that bypass sign-on. Confirm with each application vendor which account types it supports before committing to a design.
Which open-source tools can automate access removal evidence?
Several self-hosted tools cover parts of the flow. FreeIPA uses 389 Directory Server as a multi-master LDAPv3 directory that stores users, groups and hosts, with centralized access control and delegated administration. authentik's SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0, runs a full sync every hour and deprovisions users who lose access. Keycloak provides single sign-on for applications that support its protocols. Tools produce logs and sync results, but they do not decide which accounts are in scope or which removals are acceptable. Confirm each product's support for your specific applications, its licensing terms and its logging before you rely on it as evidence.
How DeployOpen scopes and prepares removal evidence
DeployOpen plans, implements and documents self-hosted identity and access platforms inside your own infrastructure, so access removal for financial applications can be automated and evidenced. We prepare systems and evidence for your assessment, while your organization owns the control and an independent auditor performs the testing.
How we scope
- Engagements are fixed-scope, with the in-scope applications, directories and termination sources agreed in writing before work starts.
- We list which financially significant systems receive automated deprovisioning and which still depend on manual removal tickets.
- Scope documents name each system owner, the HR source of truth and the evidence the auditor will request.
- Ongoing support, upgrades and periodic checks are available as a retainer after the initial scope is delivered.
How we build
- We configure identity sources so leavers and role changes flow from HR records into the directory without manual copying.
- Where supported, we set up SCIM provisioning so user deletions and group removals reach target applications automatically.
- We test removal end to end with test accounts, confirming that disabled users lose access to each in-scope application.
- We document configuration settings and confirm with each platform's current documentation which deprovisioning behaviors are supported.
How we hand over
- We deliver a runbook covering the removal workflow, exception handling for contractors and emergency terminations.
- We provide reports that compare termination records against account status in each system, formatted for auditor inspection.
- We document the test results, configuration baselines and change records that show the control operated as designed.
- Your team receives training on monitoring, reviewing exceptions and maintaining the removal process after handover.
How we support
- A retainer can cover platform upgrades, configuration changes and periodic re-testing of removal paths as systems change.
- We help you prepare responses to auditor requests for termination samples, including reconciling exceptions with your HR records.
- Support covers remediation of gaps found in removal testing, with the fix and retest recorded in the evidence file.
- We do not issue audit reports or attestations. Your independent auditor makes that determination based on the evidence we help prepare.
