03.01.01 Account management: requirements and evidence

What 03.01.01 account management requires and why assessors focus on it

03.01.01 requires you to control the full life cycle of every system account: decide which account types are allowed, record who holds each account and what roles and privileges it carries, grant access only on valid authorization, monitor how accounts are used, and disable or remove accounts that expire, go inactive, lose an owner or carry significant risk. If your organization handles CUI under a contract that requires NIST SP 800-171, this is the requirement that touches every user, so expect it to be one of the first things an assessor asks to see. The organization owns the decisions here. An implementation partner can help build the account inventory, the leaver workflow and the inactivity rules, but the policy and the accountability stay with you.

The risk is easy to describe and hard to close. Orphaned accounts left behind by contractors, transferred staff or retired applications give an attacker a valid identity that nobody is watching. Excessive accounts, which accumulate privileges through role changes and never lose them, make every later access decision weaker. The requirement carries six organization-defined parameters that NIST does not fill in for you: the inactivity period before disablement, the time allowed to notify account managers when accounts are no longer needed, the same notice time for terminations and transfers and for changes in usage or need-to-know, the inactivity period before forced logout, and the circumstances that trigger logout. Unless a federal agency specifies them, your organization must assign these values and be ready to defend them. Confirm the values with the contracting agency before you assessment starts.

The hard part is usually the inventory, not the configuration. Accounts live in directories, cloud consoles, applications, network devices and service accounts, and many were created outside any formal process. Leaver and transfer processes often depend on HR notifications that arrive late or not at all. The Rev. 2 equivalent of this requirement is 3.1.1, and CMMC Level 2, which still uses Rev. 2, assesses it as AC.L2-3.1.1 and scores it at 5 points under the 32 CFR 170.24 methodology. Because of that scoring weight, a gap here cannot be carried on a plan of action and milestones for Conditional status under 32 CFR 170.21, so resolve account management gaps before the assessment rather than planning around them.

Which accounts, systems and teams fall under account management

Account management under 03.01.01 only works if the organization first decides which systems, accounts and people it covers. Each decision below widens or narrows the list of accounts an assessor will sample, and each one changes who must be notified and how quickly.

CUI system boundary and enclave

Account management applies to every system that stores, processes or transmits CUI and to the supporting systems that can reach it, such as directories, jump hosts and backup consoles. Decide whether CUI stays in a dedicated enclave or spans the enterprise, because a broad boundary multiplies the accounts in scope. Confirm the boundary in the system security plan before you build the account inventory, so the inventory matches what an assessor will test.

Human user accounts

Every person with a logon to an in-scope system needs a recorded account, a documented authorization and a named owner. Include contractors, temporary staff and vendor personnel who sign in directly, since assessors commonly ask for the name associated with each active account. Confirm that your identity source covers these populations, not only employees.

Service and non-human accounts

Service accounts, scheduled tasks, API keys and application identities are still system accounts under the requirement. They often have no owner and no expiry, which makes them the most common gap in an inventory. Assign each one a responsible person or team, record its purpose, and define how it is disabled when the application it supports is retired.

Privileged and administrative accounts

Administrator accounts carry the highest risk of misuse, so they need their own review cycle and a shorter path to disablement. Confirm which accounts can change security settings, create other accounts or reach CUI in bulk. Track these separately from standard users, because related requirements 03.01.06 and 03.01.07 apply to them and assessors will sample them directly.

Accounts held by external providers

Cloud platforms, managed service providers and SaaS tools may hold accounts that can reach CUI even though you do not operate them. Inventory the provider-side accounts your staff use and confirm how the provider notifies you when someone leaves. Where you cannot change the provider's processes, record the gap and the compensating control in your plan rather than assuming the provider handles it.

HR and identity teams as notification triggers

The 03.01.01 notification timing depends on HR and identity teams passing terminations, transfers and role changes to account managers quickly. Identify the HR system of record, the people who file the change, and the account managers who act on it. Document the notification path and test it with a sample leaver, because an assessor will ask for evidence that the timing is met in practice.

How an assessor tests account management under SP 800-171A

This table maps each SP 800-171A assessment method for 03.01.01 to the objects an assessor looks at, the evidence that satisfies it and the usual gaps. Read it as a checklist of what to prepare before an assessment, since the six organization-defined parameters must be set before any method can pass.

Assessment element	What the assessor looks at	Common gap
Examine: policy and procedures	Access control policy and account management procedures that define account types, approval steps and review criteria	Procedures exist but do not match how accounts are actually created or disabled
Examine: termination and transfer	Personnel termination and transfer procedures showing how account managers are notified	Notification timing is not written down or does not cover transfers
Examine: active account list	List of active system accounts with the named individual tied to each account	Shared, service or orphaned accounts with no named owner
Interview: account managers	Personnel who approve, create and disable accounts, asked how the process runs day to day	Staff describe a process that differs from the written procedure
Interview: system administrators	Administrators asked how they handle inactive accounts, role changes and forced logout	Administrators unaware of the inactivity period set for the system
Test: account management mechanisms	Directory or identity tooling is run to create, modify, disable and remove a test account and to confirm the result	Disabling happens by hand with no record, or the tool does not remove group memberships
ODP check: inactivity period	A defined period after which inactive accounts are disabled	No value is set, so the requirement cannot be met
ODP check: account manager notice	Defined time to notify managers when accounts are no longer required, or users are terminated or transferred	A single notice time is used where separate values were expected
ODP check: usage or need-to-know change	Defined notice time when a user's system usage or need-to-know changes	Changes in role are handled informally with no time limit
ODP check: forced logout	Defined inactivity period and circumstances that require users to log out	Logout settings differ between applications with no stated rule
Illustrative: owner gap	An assessor finds an account with no named owner in the active list	Expect a finding that requires the account to be disabled or assigned

How to implement account management in the order that produces evidence

This sequence builds the account decisions first, then the systems that enforce them, so each step leaves a written record an assessor can examine, interview against and test. Work in this order and the account inventory, ODP values and recurring review become the evidence for 03.01.01 rather than a retrospective reconstruction.

Define allowed and prohibited account types
The security or IT owner of the system writes down which account types are allowed (for example, named user, privileged, service, shared or guest accounts, if your environment uses them) and which are prohibited, with the reason for each. Approval comes from the system owner and the people who will act as account managers. The output is a short signed account type standard that the rest of the steps reference. Done means every account type found later in the environment maps to one entry on the list.
Assign the six ODP values in writing
Under 03.01.01 the organization must assign values to six organization-defined parameters: the inactivity period before disabling, the notice times for no-longer-needed accounts, for terminations and transfers, and for changes in usage or need-to-know, the inactivity period before forced logout, and the circumstances that require logout. NIST does not supply these values, so the system owner and the security lead must choose them and record the rationale. Confirm with any federal customer or contracting agency whether it has already specified values, since that changes who decides. The output is a dated parameter table that the System Security Plan can cite.
Build the account inventory
Export every account from each directory, application, database, cloud tenant, network device and operating system in the boundary, and record the name of the individual associated with each one, its type, its groups and roles, and its privileges. Mark any account with no named owner. The assessment method for this requirement expects a list of active system accounts with the individual tied to each account, so this inventory is the artifact that will be examined. Done means the count of accounts in the inventory matches the counts reported by each source system.
Connect the authoritative source to account creation and removal
Identify the system of record for personnel, usually HR or the identity provider, and connect it to the directory so that joiners, movers and leavers drive account creation, role change and removal. Where an identity platform such as authentik can push user and group changes to target applications over SCIM 2.0, confirm which applications are covered and which still need manual steps. Test the flow with one joiner, one transfer and one leaver, and keep the tickets or logs. Done means each test account is created, changed and removed without a manual copy of its privileges left behind.
Configure inactivity disabling and session logout
Set the inactivity rule in the directory or identity provider using the disabling period chosen in step two, and configure the forced logout period and triggering circumstances in each system that supports them. Where a platform such as FreeIPA, Keycloak or Zitadel is the central source of authentication, configure the setting once there and then verify it per application, since some applications keep their own sessions. Record the configuration screen or export for each system. Done means a test account left idle is disabled on schedule and a test session is ended at the defined point.
Set up notification to account managers
Define who the account managers and designated personnel are for each system, and configure the notice path so that changes in need-to-know, terminations, transfers and accounts no longer required reach them within the notice times set in step two. Use a ticket queue or an automated notification with a retained record of each message. Confirm with the account managers that they have the access to act on each notice. Done means a sample notice for each of the four triggers exists in the logs, with the time it was sent and acknowledged.
Run and record a recurring account review
Schedule a review of the account inventory, privileges and group membership at the frequency the organization sets, and have each account manager confirm or remove every entry for their system. Compare the results with the directory export, log the disabled and removed accounts, and track findings to closure in your POA&M or issue tracker. The output is a signed review record for each cycle. Done means the first cycle is complete and the next date is on the calendar, because an assessor will ask for at least one cycle of evidence.

Setting the six ODP values that the organization must assign

NIST does not assign values to the organization-defined parameters (ODPs) in 03.01.01, so the requirement is not complete until someone sets them. If the federal agency that holds your contract or agreement specifies values, you use those. If it does not, the nonfederal organization must assign them, and the assessor will check that each one is defined and that your practice matches what you recorded. Treat the six values as a documented decision with an owner, a rationale and a review date, not as a setting someone chose during a system build. The first step is to ask the contracting agency in writing whether it specifies any of them, and to record the answer. Where the contract is silent, your system security plan should state each value explicitly.

The six ODPs cover three timing decisions and three triggers. The first is the inactivity period after which accounts are disabled. Record it per account type, because a service account, a privileged administrator account and a standard user account may need different periods, and each should be enforced in the directory or identity provider that creates the account, such as FreeIPA or Keycloak, not only in a policy document. The second, third and fourth are notice times: how quickly account managers and designated personnel must be told when an account is no longer required, when a user is terminated or transferred, and when a user's system usage or need-to-know changes. For each, record the time limit, the trigger event, the person or role who must be notified and the ticket or log entry that proves the notice. Ask your HR and identity teams whether the termination and transfer notice runs through the same workflow, because an assessor will test whether the process actually fires.

The last two ODPs govern inactivity logout and the circumstances that require users to log out. Record the period of expected inactivity after which a user must log out, and list the conditions that force logout, such as end of a work session, a change in the user's role, or a security event. Check that the values you record match the settings you configure in the system, because a mismatch between the plan and the configuration is an easy finding to write. Keep a single register listing all six values, the approver, the date set and the date last reviewed. Confirm with your assessor, or with the agency, how they expect the register to be presented, since the form of evidence is their call.

Evidence that passes an account management review

An assessor testing 03.01.01 looks for artifacts that agree with each other: a procedure that sets the ODP values, an account list that matches it, and logs that show the rules ran. Each item below answers one part of the requirement, and the set only holds up if someone refreshes every item on a set schedule rather than rebuilding it before the assessment.

Account management procedure with ODP values

This is the written procedure that defines allowed and prohibited account types, the criteria for creating and disabling accounts, and the value your organization assigned to each of the six organization-defined parameters. NIST does not assign these values, so a federal agency that leaves them unspecified leaves the organization to set them. Check that every ODP has a number or condition, that the approver and review date are recorded, and that the procedure matches what the systems actually do. An ODP left undefined fails the requirement even when the accounts look clean. Review it at least once a year and after any identity platform change.

Current account list with named owners

An export of every active system account, with the individual associated with each account, its type, its group and role membership, and its privileges. The assessment procedure asks for exactly this pairing of account and person. Shared or service accounts need a named owner and a documented reason. Compare the export against the HR roster and the directory once a month, because orphaned accounts are the most common gap an assessor finds. Keep the export date on every copy so the reviewer knows which snapshot they are looking at.

Provisioning and deprovisioning records

Tickets, approval records or directory audit logs showing that each account was created, changed and removed under the documented criteria. Each record should name the requester, the approver, the authorized need and the date. For a sample of accounts, an assessor will trace from the account back to an approval and forward to the current state. If you use an identity provider that pushes changes to applications, such as the SCIM provider in authentik, keep the sync logs as part of this evidence, since they show the change reached each target system and not only the source directory.

Inactivity disabling reports

Reports from the directory or identity platform listing accounts disabled for inactivity, the inactivity period in force when each was disabled, and any accounts that crossed the threshold but were not disabled. This is where the first ODP, the inactivity period before disabling, becomes testable. Confirm that the report runs on a schedule, that exceptions are approved in writing with an expiry date, and that the threshold in the report matches the threshold in the procedure. An empty report is only evidence if the query actually covers all systems in scope.

Leaver and transfer notification records

Records showing that account managers and designated personnel were told when a person was terminated, transferred or no longer needed an account, and that they were told within the notice times set in the ODPs. Keep the HR event, the notification message, the recipients and the time each was sent, along with the account action that followed. Assessors compare these timestamps against the ODP values, so a procedure that promises one day but records show seven will fail. Pair this with the personnel security evidence for the same people.

Forced logout configuration and settings

Exported configuration showing the inactivity period after which users must log out and the circumstances that trigger a logout, along with a sample screenshot or configuration file from representative systems. Some platforms set this per application, so one global setting may not cover every system in scope. Record each setting value against the matching ODP, and note which systems are excluded and why. Recheck the settings after every major upgrade, because defaults can change between releases.

What meeting 03.01.01 costs in money and effort

This table lists the cost components of meeting 03.01.01 Account management, marks each as one-time or recurring, and names what pushes it up or down. Read it as a checklist for building a quote: most of the spend sits in process design and ODP decisions, integration work and periodic account reviews rather than in software licenses. No dollar figures are given because none are supplied for this requirement.

Cost component	Who is paid or who spends	One-time or recurring	What drives it up or down
Identity platform licenses	Software vendor, if a commercial identity product is chosen	Recurring	User count and feature tier. Self-hosted open source such as authentik, FreeIPA, Keycloak or Zitadel removes this license line, though hosting remains
Self-hosted operating cost	Your infrastructure team or DeployOpen under a written scope	Recurring	Number of high availability nodes, backups, patching windows and monitoring for the directory and identity services
Process design and ODP decisions	Your compliance lead, HR and system owners, with an outside adviser if engaged	One-time, then revisited	Six parameters to set, including inactivity period and notice times. Fewer owners and clear HR triggers shorten this work
HR and application integration	Engineering or implementation partner	One-time per application, plus changes	Number of target applications and whether they support SCIM 2.0, OpenID Connect or SAML 2.0. Standard protocols reduce custom code
Account and privilege inventory	System administrators and application owners	One-time baseline, then recurring	Count of local, service and shared accounts. Accounts with no named owner take the longest to resolve
Periodic account reviews	Account managers and application owners	Recurring	Review frequency set in your ODPs, user churn and how many systems are in scope. Automated reports reduce manual effort
Monitoring and inactivity enforcement	Security operations or platform team	Recurring	Log volume and alert tuning. Automated disablement based on defined inactivity periods lowers manual follow-up
Evidence collection for the assessor	Compliance lead and system owners	Recurring before each assessment	Whether account lists, termination records and review sign-offs are exported from systems or assembled by hand
External review or testing	Independent assessor or security testing firm, if engaged	Periodic	Scope, sampling depth and whether the assessment is self-run or conducted by a third party. Confirm fees and timing in writing with each provider

Which self-hosted open-source tools support account management evidence

Account management under 03.01.01 depends on one identity source of truth that creates, changes and removes accounts across applications. The four tools below cover different parts of that job: provisioning into applications, directory and delegated administration, single sign-on, and brokering external identity providers. Each one produces different evidence, so the choice depends on where accounts originate in your environment.

authentik SCIM provisioning

The authentik SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0. It runs a full sync every hour and deprovisions users from the target when they lose access to the application. That sync history and the deprovisioning records can support the assessor's test that accounts are disabled or removed when access ends. Confirm that the hourly full sync fits your inactivity and disable windows, since the ODP values for those periods are set by your organization, not by the tool. The license is MIT.

FreeIPA central account directory

FreeIPA uses 389 Directory Server as a multi-master LDAPv3 directory that stores users, groups, hosts and other network objects. It provides centralized access control and delegated administration through its web UI and command line tools. Delegation lets you show which administrators can create or disable accounts, and the directory gives a single list of active accounts with the name of each account holder, which an assessor will ask for. FreeIPA does not decide your inactivity rules, so you must configure and document them. The license is GPL-3.0-or-later.

Keycloak single sign-on

Keycloak provides single sign-on, so users authenticate with Keycloak rather than separately in 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. Central sign-on means that disabling an account in one place stops access to every connected application, and session settings in one place make logout behavior easier to show. Confirm that session timeouts and logout triggers match the values you define for 03.01.01. The license is Apache-2.0.

Zitadel identity brokering

Zitadel acts as a central identity broker, so users sign in through external identity providers such as Google, Microsoft Entra ID or Okta over OpenID Connect, SAML 2.0 or LDAP. Applications trust Zitadel alone rather than each provider separately. This matters for 03.01.01 when people leave or move, because removing a user at the external provider must also remove their access through the broker, and your procedure must show that notice to account managers happens within the period you define. Test this path end to end before relying on it. The license is AGPL-3.0-only, which carries source-sharing obligations if you modify and offer the software over a network.

Who owns account management and what partners can take on

Your organization owns requirement 03.01.01 and every decision inside it. Under the Rev. 3 wording, the organization must define allowed and prohibited account types, set the criteria for creating and disabling accounts, and assign the organization-defined parameters (ODPs) for inactivity periods, notice times and logout triggers. NIST does not assign these values, and where a federal agency has not specified them, the nonfederal organization must set them to complete the requirement. Your team also approves each account, signs off on privilege assignments and owns the policy and procedures that an assessor will examine.

Policy and ODP values: Document the inactivity period, notice times and logout circumstances, and record who approved each value.
Account approvals: Keep authorization records showing who approved each account and its intended use.
Role and privilege decisions: Own the group and role membership model and review it at the frequency you define.
Termination and transfer process: Make sure HR and managers trigger notices within your defined time.
Monitoring and response: Review account use and act on disabled, risky or orphaned accounts.

Before you engage anyone, confirm that a named owner in your organization can sign each ODP value and approve each account type.

Where account management usually fails an assessment

Most account management findings trace back to one problem: the organization cannot prove, for every account on every system, who owns it, why it exists and when it should end. The cards below cover the gaps assessors meet most often under 03.01.01, each with the check that closes it.

No authoritative account inventory

Identity providers usually hold a clean list of users, but file servers, databases, network devices, build tools and SaaS admin consoles often keep local accounts that no one has listed. An assessor asks for the list of active system accounts and the name of the individual tied to each one, so a partial list fails the examine step. Pull accounts from every system directly, not only from the directory, and reconcile the two lists before the assessment begins.

Shared and service accounts without owners

Shared logins and service accounts often have no named owner, no documented purpose and no record of who knows the password. Under 03.01.01, every account needs an owner who can be notified and who can approve its continued use. Assign an owner to each shared or service account, store its credentials in a managed vault, and record the purpose in the inventory so the owner can confirm or retire it.

Leavers still holding active access

Account managers are notified of departures through HR tickets, but those tickets rarely reach every application. An account left active in a single tool can remain usable long after the person has gone. Check that termination and transfer events reach each connected system, and test the timing against the notice period your organization defines as an ODP. Sample recent leavers and confirm their access ended in every system where they held an account.

Organization-defined parameters left undocumented

03.01.01 has six organization-defined parameters, including the inactivity period before accounts are disabled and the notice times for terminations, transfers and changes in need-to-know. NIST does not supply these values, so an organization that never writes them down has not completed the requirement. Record each value in the system security plan or the account management procedure, approve it, and make sure the values match what the systems actually enforce.

Inactivity rules not enforced in applications

A policy may require users to log out after a defined period of inactivity, yet many applications keep their own session timers or ignore the platform setting. Assessors test the mechanism, not the policy text, so a rule that exists only on paper fails the test step. Configure the inactivity logout and disable-after-inactivity settings in each application, then verify them by logging in, leaving the session idle and checking the result.

Transfer and role-change notices missing

When someone moves to a new team, their old privileges often stay in place because no one notifies the account manager that their need-to-know has changed. This creates privilege creep that the requirement is meant to prevent. Tie transfer events to a review of existing group memberships, and keep a record showing that the account manager was notified within the defined time. Ask HR and managers to file the change request before the move takes effect, not after.

Questions buyers ask about account management before hiring help

What drives the cost of account management work for NIST SP 800-171?

The cost is driven mainly by how many systems hold or touch CUI, how many account sources exist, and how much of the account life cycle is still manual. Each system with its own local accounts, each directory or identity source, and each application that needs provisioning and deprovisioning adds design and testing work. Costs fall into two groups: one-time work to define account types, roles, approval paths and the six organization-defined parameters, and recurring work to review accounts, run access reviews and keep documentation current. When requesting a quote, ask the provider to list which systems and identity sources are in scope, which parts are design versus integration, what evidence will be produced, and which activities remain the organization's responsibility.

How long does account management work take to finish?

Duration depends on the number of accounts and systems, the depth of integration and how many existing processes must change. A single directory feeding a few applications is a very different job from integrating HR, ticketing and several cloud platforms. Schedules are usually set by the number of integrations and the time needed to agree on the organization-defined parameters, since those values need approval from the people who own the policy. Ask for a written timeline that ties each phase to a named system and a deliverable, and confirm which dependencies (access to identity providers, change windows, HR data feeds) sit with the client.

What does the work need from HR and IT staff?

Account management touches both HR and IT, so the work needs decisions and data from both. HR must confirm the events that start and end access, such as hires, terminations, transfers and role changes, and how quickly those events are communicated. IT must supply the directories, systems and account inventories, approve account types and privilege models, and own the configuration changes. Security or compliance staff must agree on the parameter values, such as inactivity periods and notification times. If these owners are not named early, the work tends to stall at the policy stage rather than the technical stage.

Can a small team handle NIST 800-171 account management in-house?

A small team can do it in-house if the environment is small, accounts come from one or two sources, and someone has time to document decisions and keep evidence current. The harder parts are usually the policy definitions, the parameter decisions, the interviews an assessor will hold with account managers and system administrators, and the ongoing review records. Many small teams find that the technical configuration is manageable while the evidence discipline is not. A useful test is whether the team can produce a current list of active accounts with the name of each account owner and a dated record of the last review, without a special effort.

How does Rev. 2 requirement 3.1.1 differ from Rev. 3 requirement 03.01.01?

Rev. 2 requirement 3.1.1 limits access to authorized users, processes acting on their behalf and authorized devices, and it is assessed under CMMC Level 2 as AC.L2-3.1.1. Rev. 3 requirement 03.01.01 is broader and more specific. It covers the full account life cycle, requires organization-defined parameters such as inactivity periods and notification times, and adds the expectation of monitoring account use and logging users out after set inactivity. NIST classifies the change as significant. Because CMMC Level 2 still uses Rev. 2, defense contractors should confirm which version their contract currently requires before planning the work.

What will an assessor ask for to verify account management?

An assessor will ask to examine the access control policy and procedures, the personnel termination and transfer procedures, the account management procedures, and a list of active system accounts with the name of the person tied to each account. They will interview account managers and system administrators to confirm the process is followed, and they will test the account management mechanisms on the system. Expect requests for evidence of disabled or removed accounts, notification records for departures and role changes, inactivity settings, and records showing that the organization-defined parameters were assigned. Only an independent assessor can give a result, so ask your implementation partner to prepare this evidence and ask the assessor which artifacts they require.

Which parts of account management usually go to an outside partner?

Organizations most often outsource the technical build: connecting identity sources, configuring provisioning and deprovisioning, setting inactivity logout and building account inventories and reports. Policy drafting, parameter decisions and ongoing access reviews usually stay with the organization because they reflect business and risk choices. An implementation partner can prepare systems and evidence, but the organization owns its controls and must run them. Before engaging help, agree in writing on which tasks are included, which artifacts will be delivered, and which owner signs off each parameter value.

How DeployOpen prepares account management for assessment

DeployOpen plans, implements and documents self-hosted open-source identity and account platforms inside your own infrastructure, so the account lifecycle for 03.01.01 can be configured, tested and evidenced. Your organization owns the account management policy and the six organization-defined parameter values, and an independent assessor decides whether the requirement is met.

How we scope

Agree in writing which systems, directories and applications fall inside the 03.01.01 account lifecycle.
Record the six organization-defined parameter values with your team, including inactivity periods and notice times.
Confirm who owns each account type, approval step and termination or transfer notification process before build work starts.

How we build

Configure the identity directory and provisioning flows so account creation, change and removal follow your documented criteria.
Set inactivity disablement and automated deprovisioning to the agreed parameter values, and test them against sample accounts.
Wire inactivity logout and account change notifications so account managers receive alerts within the defined notice times.

How we hand over

Deliver a configuration record and account management procedure mapped to the 03.01.01 determination statements.
Provide exports of active accounts with the named individual tied to each account, prepared for examine and test activities.
Document test results for disablement, deprovisioning and logout so your assessor can reproduce each check independently.

How we support

Offer ongoing support, upgrades and continuous testing of the account platform as a retainer after handover.
Review account lifecycle logs and parameter drift at a cadence agreed in the retainer scope.
Ask your assessor to confirm the evidence format and sampling approach before the assessment window opens.