AC-2 Account management: requirements and evidence

What AC-2 account management requires and why assessors focus on it

If an assessment, a contract or an authorization to operate depends on AC-2, the assessor will expect you to show that every account on your system has a known purpose, a named owner and a documented reason to exist, and that accounts are removed when that reason ends. AC-2 requires the organization to define which account types are permitted and prohibited, assign account managers, approve each request, and create, change, disable and remove accounts under criteria it has set. It also asks for ongoing monitoring of account use, prompt notice to managers when a person no longer needs access, periodic reviews of accounts, and alignment with how personnel are terminated or transferred. In plain terms, the control asks whether anyone can explain who holds each account and why.

The risk behind the control is orphaned and excessive accounts: accounts whose owner has left or changed roles, shared or generic accounts nobody can tie to a person, and service accounts that keep privileges long after the job they served is gone. Assessors focus on it because these accounts are a common route for unauthorized access and because weak account records undermine nearly every other access control. AC-2 is selected in the low, moderate and high security control baselines of SP 800-53B but not in the privacy baseline. Confirm the baseline selection for your system category in your own system security plan before you scope the work.

What usually makes AC-2 hard is that accounts are created outside the identity source. Local accounts on servers, application-native users, database logins and vendor portals often exist with no link to the HR joiner, mover and leaver process, so a departure is never reflected in them. Before the assessment, ask your team to list every system where accounts can be created and to confirm which of them an authoritative directory governs. Gaps found at that stage are far cheaper to close than gaps an assessor finds while sampling account lists.

Which accounts, systems and teams fall under AC-2

AC-2 applies to every account that can reach a system in the authorization boundary, whether a person, a process or an outside party uses it. The cards below set out the scoping decisions that determine which accounts, systems and HR or contractor events your account management process must cover. Each decision changes the inventory, the approvals and the evidence an assessor will request.

Human user accounts

Every named person who signs in to a system in scope needs an account record with an assigned account manager, an approval and a documented end date for access. Decide whether shared or generic logins are permitted at all, since AC-2 requires you to define permitted and prohibited account types. Check that the account list can be matched to a named individual, because assessors ask for the name associated with each active and recently disabled account.

Service and system accounts

Application-to-application logins, scheduled jobs, database connections and monitoring agents are accounts too, and they often lack an owner. Decide who the account manager is for each one, how its credentials are created and rotated, and what happens when the application it serves is retired. Treat these accounts as a separate account type in your definitions so they are not approved informally by the teams that happen to deploy them.

Privileged and emergency accounts

Administrator, root and break-glass accounts carry the highest risk and usually need tighter approval, time limits and usage monitoring. Decide which emergency accounts exist, who may activate them, and how activation is logged and reviewed afterward. AC-2 enhancements on temporary and emergency accounts and on atypical usage apply mainly at the moderate and high baselines, so confirm your impact level before deciding how much automation to build.

Systems and applications in the authorization boundary

The account inventory is only as complete as the list of systems it covers. Identify every directory, application, operating system, database and cloud console inside the authorization boundary, and decide whether each one keeps local accounts or takes accounts from a central source. Document any system that stores its own users separately, because those accounts are easy to miss during reviews and removals.

HR and contractor events that trigger lifecycle changes

Hiring, role changes, leave, termination and contract end dates are the events that require account creation, modification or removal. Decide which HR system or contract register is the authoritative source, who is notified when access is no longer needed, and how quickly those notices must reach account managers. AC-2 expects account handling to align with personnel termination and transfer, so map these events to the PS family procedures your organization already runs.

Third-party and external accounts

Vendors, managed service providers, auditors and partner staff often hold accounts that your team does not directly employ. Decide who sponsors each external account, what end date applies, and whether the external party's own identity provider is trusted. Confirm the terms with the third party before access is granted, since AC-20 and AC-2 reviews together determine whether these accounts can stay in place.

How an assessor tests AC-2 under SP 800-53A

This table compares the three SP 800-53A assessment methods for AC-2, showing what the assessor does, the evidence requested and the findings that usually follow. Read each row as a step the assessor takes against the 26 determination statements, since a gap in any one step can produce a finding even when the account process looks sound on paper.

Assessment method	What the assessor does	Evidence requested	Common findings
Examine: active accounts	Compares the list of active system accounts against the approved account list and checks that each account links to a named individual or documented service owner.	Full export of active accounts with the associated individual, account type and last logon date, taken from the directory and each target application.	Shared or generic accounts without an owner, accounts missing from the approved list, and applications that keep local accounts outside the central directory.
Examine: recently disabled accounts	Reviews the list of recently disabled accounts and checks timing against separation and transfer records to confirm removal happened promptly.	Disabled-account report with the associated individual, disable date and the request or HR event that triggered the change.	Leavers whose accounts remained enabled for weeks, or disables recorded without a matching approval or termination ticket.
Examine: approvals and account requests	Samples account requests and checks each one for an assigned account manager, a documented approval and a defined account type before creation.	Request tickets, approval records, account type assignments and the list of account managers for each system.	Accounts created before approval, approvals signed by the requester, or account managers who no longer hold the role.
Interview: account management personnel	Asks the people who create, change and remove accounts how requests are triaged, what triggers a disable and how managers are notified.	Walkthrough notes, runbooks and a short description of who can perform each account action.	Staff describe a process that differs from the written procedure, or cannot say who receives notification when someone changes role.
Test: automated account handling	Runs or observes a sample joiner, mover and leaver cycle to confirm accounts are created, changed and disabled as the process states.	Test records showing the sample account at each step, with timestamps from the directory and target application logs.	Deprovisioning does not reach a connected application, or temporary accounts remain active after their end date.
Test: periodic account review	Checks that a periodic review occurred, that reviewers examined the actual account list and that unneeded accounts were disabled or removed.	Signed review records, the population reviewed, and the follow-up tickets for accounts marked for removal.	Reviews signed without evidence of inspection, or reviews that cover only the directory and miss local application accounts.
Test: monitoring of account use	Checks that account activity is logged and reviewed for inactivity, failed use and atypical behavior, as defined by the organization.	Log samples, alert rules, inactivity thresholds and records of reviewed alerts.	Logs exist but nobody reviews them, or inactivity thresholds are defined in policy but not configured in the system.

How the account lifecycle connects HR events to system access

The account lifecycle under AC-2 is a chain of records, and an assessor will test whether each link exists. A request names the person, the account type and the business reason. An approval from a designated account manager follows, then provisioning creates the account with only the access that was approved. Each change, whether a role addition or a group move, should leave a dated entry that ties back to the request. Disablement and removal close the chain. Assessors usually sample from the current account list and then trace each sampled account backward to its request and approval, so the ticket system, the directory and the application logs must agree on identifiers. Confirm with your assessor which sample sizes and populations they will use, because that determines how complete the trail must be.

The link to personnel termination and transfer is where most gaps appear. AC-2 expects notice to account managers when access is no longer needed, and the personnel security controls expect HR to trigger that notice. Confirm that a termination or transfer in the HR system creates a tracked action against every account the person holds, including accounts in external applications. Automated provisioning can help here. For example, an identity provider's SCIM connector can deprovision a user from a target application when that user loses access, but you should verify which applications your connector covers and how it reports failures. Disabling an account keeps its identifier, history and audit trail, which is usually what an assessor needs to see for a recently departed user. Deleting an account removes that history from the directory, so deletion should follow a retention decision made in advance, not replace disablement as the default.

The account list an assessor receives must carry the name of the individual behind each account, not only a username or service identifier. Shared, service and emergency accounts still need a named responsible person and a documented purpose, because the assessment objects for AC-2 ask for the individual associated with each active and recently disabled account. Build the list from the directory itself, not from a spreadsheet maintained by hand, and record the date of the extract. Ask your assessor whether they expect the list to include disabled accounts from a defined look-back period, and make sure your export keeps those accounts visible. A list that cannot be reconciled to HR records will usually generate findings even when the underlying controls work.

Implementing AC-2 step by step, with the output of each step

This sequence turns AC-2 from a policy statement into a working account lifecycle, where each step leaves a document, configured rule or record that an assessor can examine. Read in order, the outputs show how the organization defines account types, assigns owners, approves requests and removes access, and how it proves that the account list matches the authoritative identity source.

Define permitted and prohibited account types
The control owner, usually the security lead with input from system owners, writes a standard that lists each account type the system may use, such as individual user, privileged administrator, shared, service, guest and emergency accounts. For each type, the standard states who may hold it, the approval it needs, the maximum lifetime and the types that are prohibited. The output is an approved account type standard tied to the system security plan. You know the step is done when every account present in the system maps to one listed type, and any account that does not map is flagged for review.
Assign account managers and document responsibilities
The organization names the account managers for each system and records who approves requests, who provisions accounts, who monitors use and who receives notifications when access ends. A RACI matrix captures these roles for each account type, and the owning business unit signs it. The output is the RACI and a named roster of account managers with their backups. The step is complete when each active account type has at least one accountable owner and assessors can interview those people and get consistent answers about their duties.
Set the approval workflow for account requests
Build a request form and approval path in the ticketing or identity governance tool that the organization already uses. Each request records the requester, the account type, the business justification, the required privileges, the approver and the decision date. Privileged and high-impact requests route to a second approver. The output is a workflow record for every account created, retained in the system's records. You know the workflow works when a sample of recent accounts traces back to an approved request and no account exists without one.
Automate provisioning and deprovisioning where feasible
Where the directory and target applications support it, configure an authoritative source, such as an HR system or a central directory, to drive account creation, change and removal. Open-source options include FreeIPA with 389 Directory Server as a central directory, Keycloak for single sign-on and identity brokering, and the authentik SCIM provider, which pushes user and group creations, changes and deletions to target applications over SCIM 2.0 and deprovisions users who lose access. This supports AC-2(1), automated system account management. The output is a documented connector configuration and a test record showing a created, changed and removed account propagating to a target application. Confirm each connector's capabilities against its current documentation before committing to the design.
Configure monitoring and inactivity handling
Set rules that disable temporary and emergency accounts after their defined expiry, disable accounts that remain unused beyond the inactivity threshold the standard sets, and log account creation, modification, enabling, disabling and removal. These settings address AC-2(2), AC-2(3), AC-2(4) and AC-2(5), and the high baseline adds AC-2(11) and AC-2(12) for usage conditions and atypical usage monitoring. The output is a configured rule set, exported configuration files, and audit log samples that show the events. The step is complete when a test account reaches its expiry or inactivity limit and the system disables it without manual action.
Schedule and record periodic account reviews
Account managers review the account list at the interval the standard defines, confirming that each account still needs its access, that privileges match the role and that no account belongs to a departed or transferred person. The review uses an export of the active account list with the name of the individual associated with each account, the same objects assessors examine under AC-2 in SP 800-53A. Reviewers sign off each decision, and removals are tracked to completion. The output is a dated review record with the reviewer, findings and remediation tickets. You know the step works when the review closes with documented removals or justifications.
Reconcile account lists against the authoritative identity source
Compare the account list in each target system with the authoritative identity source, such as the HR-fed directory, and investigate every difference. Accounts without a matching person, people without accounts where they should have one, and accounts whose status disagrees with the source are logged as exceptions. This reconciliation links the review to the termination and transfer process that AC-2 requires. The output is a reconciliation report with exceptions, owners and closure dates. Ask the independent assessor which reconciliation frequency and evidence format they expect for your system, since their procedures decide what passes.

Evidence that passes an AC-2 assessment

AC-2 assessments rest on a small set of documents and exports that show who holds accounts, who approved them and when they were last reviewed. Each artifact below answers one question the assessor asks, and together they let an assessor trace an account from request to removal.

Account management procedure

The written procedure defines permitted and prohibited account types, names the account managers, sets the approval path and states the criteria for creating, changing, disabling and removing accounts. Assessors check that the procedure matches what the systems actually do, so compare it against a sample of real provisioning records. Keep it under version control and tie each revision to a review date and approver.

Approved account type catalog

This catalog lists every account type the system permits, such as individual user, shared, service, emergency and temporary accounts, with the conditions and owner for each. Assessors use it to confirm that accounts in the directory fall into an approved type and that prohibited types are absent. Review it whenever a new integration introduces a new account pattern.

Active and recently disabled account lists

The active account list must name the individual behind each account, and the recently disabled list must do the same for accounts removed in the review window. Assessors list these objects in SP 800-53A for AC-2 and sample entries against HR records. Schedule an export from the identity provider, store it with a timestamp and reconcile it with the personnel roster each cycle.

Approval and change tickets

Each account creation, privilege change and deletion should trace to a ticket that records the requester, the approving account manager, the justification and the completion date. Assessors pick tickets at random and check that the approval came before provisioning. Make the ticketing system the only path to create accounts so that gaps are visible.

Periodic review sign-offs

Account reviews show that managers confirm each account still needs its access. The sign-off record should list the reviewer, the scope, the accounts removed or changed and the date. Assessors check that the reviews happened at the frequency the organization defined and that findings were acted on. Keep signed exports for the full review cycle and the cycles before it.

Automated provisioning logs

Where an identity platform provisions accounts automatically, its logs show when each account was created, changed or deleted and by which process. The authentik SCIM provider, for example, runs a full sync every hour and deprovisions users from target applications when they lose access. Confirm with your vendor how sync events are logged, forward them to central storage and set a retention period that covers your review cycles.

What meeting AC-2 costs in money and effort

This table compares the cost components of meeting AC-2 account management, who is paid for each, whether it is one-time or recurring, and what moves it up or down. NIST does not estimate compliance costs, so use the table to shape a written scope and quote, not to predict a figure. Open-source identity tools can remove license spend, but the internal and assessment effort remains.

Cost component	Who is paid or who spends effort	One-time or recurring	What drives it up or down
Internal engineering to define and automate account handling	Internal identity or platform engineers, or an implementation partner under a fixed scope	One-time build, then recurring change work	Number of identity sources, number of target applications, and how many AC-2 enhancements (such as AC-2(1), AC-2(2) and AC-2(3)) the impact level selects
Identity tooling or licenses	Software vendor or open-source project; self-hosting shifts spend to infrastructure and support	Commercial licenses recur; open-source licenses carry no license fee but still need hosting and maintenance	Per-user or per-application licensing in commercial products; hosting size and upgrade effort for self-hosted options such as FreeIPA, Keycloak, authentik or Zitadel
Account provisioning and deprovisioning integrations	Internal engineers or an implementation partner building SCIM or directory connectors	One-time per application, then recurring when applications change	Number of applications that need automated lifecycle sync and whether each supports standards-based provisioning
Evidence upkeep and periodic account reviews	Internal account managers and system owners performing reviews and keeping lists current	Recurring, at the review frequency the organization sets	Number of accounts, number of account types, and whether account lists are generated automatically or assembled by hand
External testing or readiness review	Independent security testers or readiness reviewers, engaged by the organization	Usually one-time per assessment cycle, with periodic repeats	Scope of systems in the authorization boundary and whether access control testing is included in the written scope
Assessor sampling effort	Independent assessor, paid by the organization under its assessment engagement	Recurring with each assessment cycle	Number of accounts sampled, quality of account lists and disablement records, and how well termination and transfer notices are documented

Self-hosted open-source tools that produce AC-2 evidence

AC-2 evidence comes from the identity layer: where accounts are created, who approved them, when they are removed and who reviewed them. The four tools below cover different parts of that lifecycle, so most organizations will combine them rather than pick one, and each needs confirmation against their own directory and application estate.

authentik SCIM provider

The SCIM provider pushes user and group creations, changes and deletions from authentik to target applications over SCIM 2.0 and runs a full sync every hour. For AC-2, this is the mechanism that can remove a person's access in connected applications after they lose access in the source, which is the evidence an assessor will ask to see. Check which target applications support SCIM, how orphaned accounts in non-SCIM systems are found, and whether the sync interval meets your removal requirements. Licensed under MIT, so review any enterprise add-ons separately.

FreeIPA and 389 Directory Server

FreeIPA stores users, groups, hosts and other network objects in 389 Directory Server, a multi-master LDAPv3 directory, and provides centralized access control with delegated administration through its web UI and command line tools. Delegation matters for AC-2 because it lets you show which administrators may create, change or disable accounts and which only review them. Confirm how account approval and disablement workflows will be recorded outside the directory, and how the directory is joined to your Linux, Windows and cloud estate. Licensed under GPL-3.0-or-later, which carries copyleft obligations if you modify and distribute the code.

Keycloak single sign-on

Keycloak lets users authenticate once with Keycloak instead of with each application, supporting OpenID Connect, OAuth 2.0 and SAML 2.0, and it can broker logins to existing OpenID Connect or SAML 2.0 identity providers. For AC-2, a central sign-in point gives you one place to disable an account and see which applications it reached, provided applications do not keep local credentials. Confirm which applications still hold local accounts, how brokered identities are linked to internal accounts, and how disabled users are blocked from active sessions. Licensed under Apache-2.0, a permissive license with few distribution obligations.

Zitadel identity brokering

Zitadel acts as a central identity broker so users can sign in through external identity providers such as Google, Microsoft Entra ID or Okta over OpenID Connect, SAML 2.0 or LDAP, without each application trusting each provider separately. For AC-2, this keeps the list of accounts tied to one broker, so a removal at the external provider can be traced into your applications. Confirm how the broker records account creation and linking, and whether the external provider remains the system of record for leavers. Licensed under AGPL-3.0-only, which requires source availability to users who interact with a modified version over a network, so legal review is advisable before hosting it as a service.

Who owns AC-2, who prepares evidence and who issues the opinion

Your organization owns AC-2. That means it decides which account types are permitted, names the account managers, approves account requests, sets the rules for disabling and removing accounts, and accepts the risk when an account exception is granted. These decisions belong to the system owner and the security function, and they must be written down in the access control policy and the system security plan, not left to the administrators who run the tools.

Policy decisions: Define permitted and prohibited account types, such as shared, guest, service and emergency accounts, and the conditions for each.
Named accountability: Assign account managers by name or role and record who may approve each class of access.
Termination and transfer links: Agree with HR which events trigger disablement or manager notification, and how quickly each must happen.
Periodic review: Own the account review schedule, the reviewers and the sign-off record that proves the review happened.
Exceptions: Document any account that cannot follow the standard process, with a justification and a risk acceptance.

Before an assessment, confirm that someone inside the organization can explain each account type and produce the approval and review records without relying on a partner.

Where AC-2 programs usually fall short and how to close each gap

Most AC-2 findings do not come from missing policies. They come from accounts that exist outside the system of record, from decisions that are never written down, and from removals that leave no trace. The cards below pair each gap with a concrete fix and the evidence an assessor would expect to see.

Accounts created outside the identity source

Local accounts created directly on servers, databases or SaaS consoles bypass the approval workflow entirely, so no account manager can be named for them. Check the target application's own user list against the directory of record each quarter, and treat any account without a matching identity as a finding. Central identity platforms such as authentik can push user and group changes to target applications over SCIM 2.0, which narrows the gap but does not remove local accounts that were created before integration. Reconcile every target system against the identity source before calling AC-2 implemented.

Service accounts with no named owner

Service and shared accounts are often created for a batch job or integration and then outlive the people who set them up. SP 800-53A asks assessors to match each active account to a named individual, so an account with no owner fails that check even when it is technically secured. Record an accountable owner, the purpose and the review date in the directory object itself, and disable any account whose owner cannot be confirmed. FreeIPA's centralized directory and delegated administration can hold these attributes alongside users and groups.

Reviews without recorded decisions

A periodic access review that produces no written outcome is hard to defend. Assessors look for a list of accounts, the reviewer's name, the decision for each account (keep, change or remove) and proof that removals were carried out. Export the account list at review time, capture reviewer sign-off in a ticket or workflow record, and keep the completed list with the change tickets that followed. Ask your assessor which review period and reviewer roles they expect, since the control leaves those choices to the organization.

No manager notice on role changes

AC-2 expects the organization to notify account managers when access is no longer needed, including when someone transfers. In practice, HR moves an employee to a new team and the old entitlements persist because nobody told the previous manager. Tie transfer and termination events from the HR system to a workflow that opens a review task for the prior manager and removes access that is no longer justified. Keep the triggering event, the notification timestamp and the manager's response as evidence. Keycloak can broker logins to existing identity providers, which keeps the sign-in source consistent when roles change.

Disabled accounts with no removal record

Accounts that are disabled but never deleted, or deleted without a record, leave assessors unable to confirm that removal followed the agreed criteria. Keep a log of disable and removal actions that names the account, the requesting manager, the reason and the date. Auditing these events is part of the monitoring that AC-2 expects, and it links to the audit logging controls in the AU family. Confirm with your assessor whether they will sample recently disabled accounts, since the assessment method lists them as a test object.

How long, how much effort and what AC-2 needs from your team

How much does it cost to meet AC-2 account management?

No NIST source gives a price for AC-2, and NIST states it does not estimate compliance costs, so the cost is set by scope and by who does the work. The main cost components are internal staff time for account managers, system owners and HR, the identity tooling you run or buy, the work to connect each application to it, and an independent assessment if you need one. Recurring costs include account reviews, access request handling and tool upkeep. To compare quotes, ask each provider to split one-time work (identity integration, process design, evidence setup) from recurring work (periodic reviews, upgrades, support) and to list the number of systems and user populations in scope. Open-source identity components lower license costs, but they do not remove the effort of integration and operation.

How long does AC-2 implementation usually take?

NIST does not set an implementation timeline for SP 800-53 controls, and the duration depends on your environment. The biggest drivers are how many applications and directories need account lifecycle automation, whether accounts are already centralized, how many account types and approval paths you must define, and how much HR process change is needed to notify managers when people leave or move. Manual processes for a small number of systems can be defined in weeks, while integrating many applications and proving a full review cycle takes longer. Ask for a milestone plan that names each system, the owner of each step and the dates agreed in writing before work starts.

Can our team implement AC-2 in-house?

Yes, many organizations implement AC-2 internally, provided they have staff who can design the account lifecycle, operate the identity platform and write the procedures an assessor will read. In-house teams usually need time from identity engineers for provisioning and deprovisioning integrations, from security staff for the account types and approval rules, and from HR for joiner, mover and leaver events. Outside help is most useful for a fixed-scope integration, an independent review of the design before evidence is collected, or a second pair of hands during the first review cycle. Whatever the split, the organization keeps ownership of the control. A partner prepares systems and evidence, and only an independent assessor reports on the control.

What does AC-2 require from system owners and HR?

AC-2 depends on people outside the security team. System owners must confirm which accounts are permitted, who approves access, and which roles need which privileges. HR must send timely notice of terminations and transfers, because AC-2 expects account handling to follow personnel actions. Account managers must be named and must be able to act on requests. Expect a RACI-style agreement that lists these roles, the trigger events, and the response time expected for each. Without this agreement, disabled accounts and recently removed access are hard to show as complete, and the account lists an assessor tests will not match what HR recorded.

What will the assessor request first for AC-2?

Assessors typically start with the account lists, because the SP 800-53A examine objects for AC-2 include the list of active system accounts with the name of the person tied to each account, and the list of recently disabled accounts with the same detail. They will also interview the personnel who hold account management responsibilities. Prepare the account policy that defines permitted account types, the approval records for a sample of requests, the removal records for a sample of leavers and movers, and the periodic review records with their outcomes. Confirm with your assessor which samples and time periods they will select, because the assessment method and scope are their decision.

Can a partner run the periodic AC-2 account reviews for us?

A partner can run or support periodic reviews under a retainer, which is one of the ongoing services DeployOpen offers. The partner can prepare the account extracts, flag dormant or orphaned accounts, route review decisions to the named account managers and keep the records. The organization still decides which access stays, because the control owner must approve it. Confirm in writing which review cycle, which systems and which tasks are included, who signs off each review and how exceptions are recorded. Ask how the reviews produce evidence that an independent assessor can examine.

How DeployOpen scopes and prepares AC-2 evidence

DeployOpen plans, implements and documents self-hosted open-source identity and account management inside your own infrastructure, so the account lists, approvals and removal records an assessor samples are produced by the systems you run. The organization still owns AC-2 and its account management decisions, and only an independent assessor can issue findings or reports.

How we scope

Confirm which systems, applications and account types fall inside the AC-2 boundary and the baseline you are assessed against.
Record the account types you permit and prohibit, and who acts as account managers for each system.
Agree in writing which account lifecycle steps DeployOpen implements and which remain with your own staff.
Fix deliverables, timelines and exclusions in a written, fixed-scope agreement before any work starts.

How we build

Configure directory and identity platforms so account creation, change and removal follow your approval workflow.
Connect target applications to automated provisioning so access is removed when a person leaves the application's scope.
Set up logging of account creation, disablement and use so the audit trail supports later sampling by an assessor.
Test deprovisioning and disablement paths in a non-production environment and document the results for your review.

How we hand over

Export current and recently disabled account lists with the named individual for each account, in the form an assessor requests.
Document the account lifecycle procedure, roles and review cadence in language your control owners can maintain.
Provide a record of the periodic account review, including how exceptions were approved and closed.
Walk through the evidence package with your compliance lead so gaps are known before the independent assessment begins.

How we support

Offer ongoing support, upgrades and continuous testing of the identity platform as a retainer, scoped in writing.
Review account lists and provisioning logs on a schedule agreed with you, flagging orphaned or stale accounts.
Update configuration and documentation when applications, personnel processes or the baseline change.
Confirm with your assessor which evidence formats and sampling periods they will accept before the review period opens.