Safeguard 5.6 Centralize account management: evidence

Safeguard 5.6 centralize account management: what the requirement asks

Safeguard 5.6 asks for accounts to be managed from one central place, a directory or identity service, rather than separately inside each application or system. It sits in the Users asset class and the Govern security function, and CIS assigns it to Implementation Groups 2 and 3 but not IG1. Organizations that only need essential cyber hygiene can defer it, but organizations with more operational complexity or sensitive data should treat it as a baseline expectation.

When accounts are scattered across applications, access tends to outlive the person it was granted to. A leaver may be removed from the HR system and the email tenant but keep a local login to a finance tool, a database or a legacy portal. Passwords and MFA settings also drift from application to application, so one system may accept weak passwords and no second factor while another enforces both. The CIS Controls Assessment Specification measures this through coverage across assets, not the mere existence of a directory. An organization can own a directory and still score poorly if most of its applications authenticate locally. The reader's first task is therefore to list which assets and applications authenticate against the central source and which do not. Two obstacles usually make the requirement hard. Legacy applications may not support federation protocols such as SAML 2.0, OpenID Connect or LDAP, which forces either an upgrade, a gateway in front of the application or a documented exception. Local accounts also persist beside the directory, often as break-glass, vendor or service logins. The Assessment Specification lists Safeguards 1.1 (enterprise asset inventory) and 2.1 (software inventory) as prerequisites because they produce the list of assets and applications that the coverage measure needs. Confirm both inventories are current before estimating coverage, and ask the auditor which local accounts they expect to see documented as exceptions.

Which accounts and assets centralize account management covers

Coverage under Safeguard 5.6 is only as meaningful as the scope behind it. The decisions below determine which accounts must authenticate through the central directory and which assets form the denominator the assessor counts against. Settle them in writing before measuring.

User accounts on endpoints and servers

Local user accounts on workstations, laptops and servers are where centralization most often stops short. Decide whether domain or directory logon is mandatory on each operating system, and which local accounts remain as documented exceptions, such as break-glass access. Check that each endpoint and server joins the directory, and that logon attempts against local accounts are restricted where the platform allows. Confirm the list of exceptions with the people who own those systems.

SaaS and internal applications

Every application that keeps its own user store is a candidate for centralization, including SaaS tools and internally built systems. Federation through single sign-on or provisioning through SCIM covers most of them, but some applications only support local accounts. List each application, record whether it authenticates through the central identity service, and note how provisioning and deprovisioning reach it. Applications without federation support need a documented reason and a compensating control.

Network and cloud administration consoles

Firewalls, switches, hypervisors, cloud control planes and management consoles often carry separate administrator logins that bypass the directory. These accounts carry the highest privilege, so they belong in scope even when the platform is managed by a different team. Confirm which consoles accept directory authentication, which rely on local break-glass accounts, and who approves each local account. Treat console scope as a review item for the network and cloud owners, not only the identity team.

Third-party and contractor accounts

Accounts held by vendors, contractors and managed service providers often sit outside the employee directory. Decide whether they are issued directory identities, federated from the partner's own identity provider, or kept as local accounts. Each route changes who can disable access and how quickly. Ask each provider how it removes its staff from your systems, and record the answer in the scope register alongside the contract owner.

Asset inventory as the denominator

Coverage is measured against a list of assets, so the enterprise asset inventory from Safeguard 1.1 defines the denominator. Assets missing from that inventory are invisible to the measurement, which inflates the apparent coverage. Reconcile the inventory against directory-joined systems and investigate any gap. Dates, counts and tooling for the inventory belong to the Control 1 pages, so use the same source of truth here.

Software inventory and excluded assets

The software inventory from Safeguard 2.1 identifies which applications need central authentication. Each exclusion, whether for a legacy system, a standalone appliance or an application under replacement, needs a recorded reason, an owner and a review date. Assessors look for that register because undocumented exclusions read as gaps. Ask the auditor which exclusion evidence they expect before the measurement period starts.

Wider scope at IG2 and IG3

Safeguard 5.6 applies at IG2 and IG3, where enterprises usually hold more sensitive data and more regulated systems. Those organizations tend to widen scope to cover privileged consoles, production databases, and systems that hold regulated records. Decide early whether the regulated environment sits inside the same measurement, since mixing scopes weakens the coverage figure. Confirm the target scope with the security and compliance leads who will defend it.

How assessors test centralized account management coverage

This table walks through how an assessor measures Safeguard 5.6 under the CIS Controls Assessment Specification: three measures combined into one coverage figure. Read each row as a step in the test, with the evidence to prepare and the gaps that most often lower the result. The main takeaway is that coverage is measured against a complete inventory, so an incomplete asset or application list makes every other measure harder to pass.

Test element	What the assessor does	Evidence to prepare	Common findings
Population (denominator)	Builds the set of assets and applications in scope from the Safeguard 1.1 asset inventory and the Safeguard 2.1 software inventory	Current asset and software inventories with owners, dates of last validation and a stated scope boundary	Inventories missing cloud workloads, SaaS tools or network devices, which shrink the denominator and hide gaps
Sampling of assets and applications	Selects a sample from the population and tests each sampled item against the central directory or identity service	A complete list the sample can be drawn from, plus the ability to show the item's authentication path on request	Samples drawn only from managed systems, so unmanaged corners go untested
Measure 1: Accounts sourced from the central directory	Checks whether user accounts for sampled systems exist in the central directory rather than only as local accounts	Directory exports or query results for the sampled systems, matched to the account lists on each system	Local accounts on servers, network devices or appliances with no directory record
Measure 2: Authentication through the central service	Checks whether sign-in to sampled applications and systems goes through the directory or identity service	Directory-bound authentication logs, single sign-on logs or LDAP bind records for the sampled items	Applications that accept direct passwords alongside single sign-on, or fall back to local login
Measure 3: Provisioning and deprovisioning from the central source	Checks whether account creation, change and removal in sampled applications are driven from the central source	Provisioning logs, SCIM or connector sync records and deprovisioning events tied to HR or access request changes	Manual account creation in applications, or leavers still active after removal from the directory
Coverage metric	Combines the three measures into one coverage figure across the population	A worked calculation showing numerator, denominator and the sampling method used	Coverage figures that count only the systems that passed, without recording how many were out of scope
Exceptions and compensating records	Reviews any system excluded from central management and whether the exclusion is documented and approved	Signed exception records with owner, reason, compensating controls and review date	Undocumented exclusions, or exceptions that never expire

Implementing centralized account management step by step

This sequence moves accounts from scattered local and application logins to one directory or identity service, with each step producing an artifact that an assessor can trace back to the Safeguard 5.6 measure of coverage across assets.

Confirm the asset and software inventories
Before anything is connected, the organization checks that its enterprise asset inventory (Safeguard 1.1) and software inventory (Safeguard 2.1) are current, because the CIS Controls Assessment Specification lists both as prerequisites for measuring Safeguard 5.6. The IT operations or asset management owner reconciles both lists against what is actually running, including cloud workloads and SaaS applications. The step is complete when the team can produce a list of every asset and application that authenticates users, with an owner recorded for each. That list becomes the denominator for the coverage measure later in the sequence.
Choose the authoritative directory
The organization selects the one directory or identity service that will be the source of truth for user accounts and groups, such as an LDAP-based directory or an identity provider. The identity or security architecture owner documents the decision, including which accounts are in scope (employees, contractors, service accounts that can be centralized) and which are excluded with a reason. The output is an approved architecture decision record that names the directory, its administrators and the groups that control access. Without this record, later steps tend to create a second source of truth.
Connect identity sources and brokered providers
Existing identity sources, such as HR-driven user stores, cloud tenant directories or external identity providers, are connected to the chosen directory or broker. Keycloak can broker logins to existing OpenID Connect or SAML 2.0 identity providers, and Zitadel can accept sign-ins from external providers over OpenID Connect, SAML 2.0 or LDAP, so applications do not need to trust each provider separately. The integration engineer tests a sample of users from each source. The output is a source connection register listing each source, its protocol, its owner and the date of the last successful test.
Federate applications through single sign-on
Each application in the software inventory is configured to authenticate against the central service rather than maintaining its own password store. Applications that support OpenID Connect, OAuth 2.0 or SAML 2.0 are moved first, because Keycloak and similar services support those standards. Applications that cannot federate are recorded for later handling. The application owner signs off on a login test for each application. The output is an application federation register that maps each application to its authentication method and status, which is the first evidence an assessor will ask for when measuring coverage.
Configure SCIM provisioning and deprovisioning where supported
For applications that hold their own user records, provisioning and removal are automated where the application supports it. The authentik 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 when they lose access. The identity engineer configures one connector per application and tests a joiner, mover and leaver case. The output is a provisioning configuration record and test log. Applications without SCIM support are added to a manual provisioning procedure with a named owner.
Migrate or retire local accounts
Local accounts that remain on servers, network devices, appliances and applications are reviewed one by one. Each is either migrated to the central directory, disabled, or kept as a documented exception, such as break-glass or a vendor-required local account tied to a Safeguard 5.5 service account record. The system owner records the decision and the reason. The output is an exception register with an owner, a justification and a review date for every local account that cannot move, along with a removal log for accounts retired. Assessors commonly test this register against what they find on the systems.
Measure coverage against the inventory
The final step compares the application and asset lists from the first step against the federation, provisioning and exception registers. Coverage is measured as the share of inventoried assets and applications that authenticate through the central service, or that appear on the exception register with an approved reason. The CIS Controls Assessment Specification defines three measures for Safeguard 5.6 combined into one coverage metric, so the team should confirm the exact measures in the specification before reporting. The output is a coverage report, reviewed by the control owner, with gaps assigned to owners and tracked until closed. Independent assessors test this report against the systems themselves.

Evidence that proves centralized account management

An assessor testing Safeguard 5.6 looks for proof that the directory is the source of truth, that applications actually depend on it, and that exceptions are known and owned. The six artifacts below connect those three points, and each one needs a refresh schedule so it still reflects the environment when the assessor arrives.

Authoritative directory configuration

Export the configuration of the directory or identity service that holds the accounts, including the realm or domain, the user sources it reads, the authentication policy and who holds administrative rights in it. Record the scope in writing: which user populations sit in the directory and which do not, such as local break-glass accounts. An assessor will ask whether any other store can create or enable accounts, so the export should show that identity lifecycle changes happen only here. Schedule the export monthly and attach each version to a change ticket, so the file history shows when the scope or policy changed.

Connected applications and authentication methods

Maintain a register of every application that relies on the central directory, listing the protocol it uses (OpenID Connect, SAML 2.0, LDAP or another method), its owner and whether it accepts logins only through the central service. Applications that still hold local passwords are the main gap Safeguard 5.6 is designed to expose, so mark each one as integrated, pending or exempt. Reconcile this register against the software inventory built for Safeguard 2.1, since an application missing from the register is usually one nobody has tied to identity. Refresh the register whenever a new application is approved.

SCIM sync and deprovisioning logs

Provisioning logs show whether joiners, leavers and role changes reach target applications without manual steps. Where SCIM is used, the authentik SCIM provider pushes user and group creations, changes and deletions to target applications and runs a full sync every hour, so the logs should show create, update and delete events with timestamps. Pull a sample of removals and compare each deprovisioned user against the HR or access request that triggered it. Retain these logs under the same retention rule as the audit logs, and confirm that the logging setting is enabled before the audit period starts.

Coverage report reconciled to inventories

The coverage report is the measurement the assessment specification uses for Safeguard 5.6, so it needs to show what share of assets and applications authenticate through the central service. Build it by joining the enterprise asset inventory from Safeguard 1.1, the software inventory from Safeguard 2.1 and the connected-application register, then counting how many entries use central authentication. Every unexplained gap should appear as a line item. Regenerate the report at a fixed cadence, such as monthly, and keep the input extracts so the numerator and denominator can be reproduced.

Exception register with owners and review dates

Some systems cannot yet use central authentication, such as legacy appliances, embedded devices or vendor-managed tools. Each one belongs in an exception register that names the system, the local account types it uses, a compensating control such as a privileged access vault or restricted network path, a named owner and a review date. The register is where an assessor checks whether gaps are known and managed rather than forgotten. Require a change ticket to add, extend or close an exception, and confirm that expired exceptions escalate to the owner.

Periodic access review records

Periodic review records show that someone looked at the central directory and the connected applications, compared them with approved access, and acted on what they found. Record the reviewer, the date, the population reviewed, the findings and the removals or exceptions they produced. Tie each review to the coverage report and exception register so one review can explain both the numbers and the decisions behind them. Keep the review cadence documented in your access policy, and keep the signed records with the evidence set, not in a personal folder.

What centralized account management costs to meet

This table breaks down the cost components of meeting Safeguard 5.6 and shows who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to build a quote request, since the open-source directory and identity options carry no license fee but the surrounding work does not disappear. The main takeaway is that integration coverage across applications, not the software itself, usually sets the size of the effort.

Cost component	One-time or recurring	What drives it up or down
Directory and identity software (FreeIPA, Keycloak, Zitadel, authentik)	Licensing: none for the named open-source options. Hosting and infrastructure: recurring	Number of hosted instances, high availability design and the infrastructure you run them on. Confirm license terms for any add-on or commercial edition you choose.
Licensing for commercial SaaS applications that federate with the central directory	Recurring	Number of applications that must authenticate centrally and whether your current contracts include SSO or SCIM provisioning features. Confirm with each vendor.
Engineering time for integration and migration	One-time, with later changes	Application count, legacy applications that cannot use OpenID Connect, SAML 2.0 or SCIM, and the number of identity sources to broker.
Legacy federation gaps and workarounds	One-time, with recurring upkeep	Applications with local accounts that cannot be disabled centrally. Each gap needs a documented exception or a rebuild, and each exception adds review work.
Evidence upkeep (coverage reports, provisioning logs, exception register)	Recurring	How often coverage is measured against the asset inventory from Safeguards 1.1 and 2.1, and whether reports are generated automatically from the directory or assembled by hand.
External testing or review of the central directory	Recurring, usually per engagement	Scope of the review, the number of connected applications and whether the assessment covers identity configuration, MFA enforcement and deprovisioning. Ask for a fixed-scope written proposal.
Auditor sampling effort	Recurring, per assessment cycle	Number of populations the auditor samples (joiners, leavers, application lists), and whether you can produce complete, dated records without manual reconstruction.

Open-source tools that produce centralized account management evidence

Safeguard 5.6 is satisfied when accounts are created, changed and removed from one central place. The four open-source platforms below cover different parts of that job: a directory, a single sign-on service, an identity provisioning layer and an identity broker. Choose based on where your accounts live today and which applications must be connected.

FreeIPA for directory-based accounts

FreeIPA is built on the 389 Directory Server, a multi-master LDAPv3 directory that stores users, groups, hosts and other network objects. It gives administrators one place to define accounts and groups, with centralized access control and delegated administration through its web UI and command line tools. For Safeguard 5.6, the evidence is the directory itself: a list of user and group objects, a record of who holds delegated rights, and the host and service enrollments that depend on it. Confirm that your Linux hosts, network services and internal applications can authenticate against LDAP or Kerberos before you commit.

Keycloak for single sign-on

Keycloak provides single sign-on so users authenticate with Keycloak rather than separately with 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. Assessors looking for central management will want to see that application access is granted and revoked through Keycloak, with an export of realms, clients and role assignments as evidence. Check that every application you need to govern supports one of these protocols, because applications that cannot be federated will keep local accounts that fall outside the central record.

authentik for user and group 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. This matters for Safeguard 5.6 because removing a person from a central group should remove their access elsewhere without a manual ticket. Evidence includes the provider configuration, sync logs and records of deprovisioning events. Confirm which of your target applications accept SCIM 2.0 and whether they support the group operations you need, since provisioning depends on each application's own SCIM implementation.

Zitadel for 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. Applications trust Zitadel alone rather than each provider separately. The evidence is the list of configured identity providers, the broker configuration and login records. Zitadel is licensed under AGPL-3.0-only, which requires that modified versions offered over a network be made available in source form to their users. Have counsel review that obligation before you modify the code, and confirm which external providers and application protocols your environment requires.

Who does what: your team, an implementation partner and the auditor

Your organization owns Safeguard 5.6. The directory or identity service is your system of record for who holds an account, which groups they belong to and when access is granted or removed. Those decisions stay with your people, even when an outside party builds the platform. Assessors will ask who approves access, who can change directory groups and how exceptions are recorded, so these answers must come from your own governance.

Directory ownership: Name an accountable owner for the directory or identity broker, with defined administrators and a change process.
Access decisions: Approve which applications are connected to central identity and which roles map to which groups.
Exception register: Record every account or application that authenticates outside the central directory, with an owner, a reason and a review date.
Coverage reporting: Review the share of in-scope assets and applications that use central identity, using the asset and software inventories from Safeguards 1.1 and 2.1.
Joiner, mover and leaver rules: Document how directory changes follow HR or contract events.

Before engaging any partner, confirm that these owners and approvals exist in writing, because an assessor will test them regardless of who configured the system.

Where centralized account management usually falls short

Safeguard 5.6 is measured by how much of the estate authenticates through one directory or identity service, so most shortfalls come from accounts and applications that sit outside that path. The cards below cover the gaps assessors and internal reviewers find most often, with a practical fix for each.

Service and local accounts bypass the directory

Local administrator accounts on servers, network devices and appliances, plus service accounts embedded in scripts, often authenticate outside the directory. These accounts are easy to miss because they never appear in a user list. Check each asset against the directory's account list and record which local accounts remain by design. Where a platform can bind to LDAP or accept federated sign-in, move it to the directory and keep only a documented break-glass local account.

Applications accept direct passwords alongside SSO

Many applications keep a local password login next to single sign-on, so a user can authenticate with a password that the directory never governs. Disabling a directory account then leaves a working credential behind. For each application, confirm whether local login can be turned off or restricted to a named break-glass group. Where the application supports OpenID Connect or SAML 2.0, set the directory or broker as the only login path and test that a disabled user is refused.

Deprovisioning that is never tested

Teams often assume that removing a user from the directory removes access everywhere. In practice, connectors fail silently, groups are not mapped, and applications keep local copies of accounts. Pick a sample of leavers and movers each quarter, then confirm access is gone in every connected application. Where SCIM is used, check that create, change and delete events reach the target and that the scheduled full sync corrects drift.

Asset inventory that does not match directory scope

Safeguard 5.6 is measured against assets, so an asset inventory that is larger than the directory's coverage produces a gap by definition. Inventories built from Safeguards 1.1 and 2.1 often list devices and software that were never joined to the directory, such as lab hosts or SaaS tools bought outside IT. Reconcile the asset and software inventories against directory-joined systems, then record each unjoined asset with an owner and a plan to join it or retire it.

Exceptions without owners or review dates

Every exception to central management needs a reason, an accountable owner and a date for review. Without those fields, temporary exceptions become permanent and assessors cannot tell an accepted risk from an oversight. Keep a register of exceptions that lists the asset or application, the business reason, the compensating controls such as MFA or restricted network access, the owner, and the next review date. Review the register on the same cycle as the account inventory.

Coverage measured once, not continuously

A coverage figure taken at audit time describes one moment and says little about the months before or after. New applications, cloud accounts and contractor onboarding can each add accounts outside the directory between reviews. Automate a recurring coverage report that compares the asset inventory with directory-joined assets and flags new gaps. Keep the reports as dated evidence so an assessor can see the trend, not a single snapshot.

Questions buyers ask about Safeguard 5.6 cost, effort and outsourcing

How much effort does it take to meet Safeguard 5.6?

The effort depends mainly on how many applications, directories and account sources you have today, not on the Safeguard itself. Safeguard 5.6 asks that accounts be managed from one central directory or identity service, so the work splits into a one-time build and a recurring operating cost. The one-time build covers deploying the central service, connecting existing directories, and onboarding each application to it. The recurring cost covers keeping provisioning links working, reviewing exceptions, and maintaining group and role mappings as people join, move and leave. The CIS Controls Assessment Specification ties this Safeguard to inventories of enterprise assets and software, so an incomplete inventory adds effort before any integration starts. Ask any provider to split its quote into build and run phases and to state which applications are assumed in scope.

How long does migration to central account management take?

No duration can be stated without knowing your environment, so ask for an estimate built from a written scope. The main drivers are the number of applications to onboard, whether each one supports standard protocols such as SCIM, OpenID Connect, SAML 2.0 or LDAP, and how many user sources must be merged. Applications that accept federated sign-on or automated provisioning move quickly. Legacy applications that only hold local accounts, or that need custom connectors, take longer and often need a decision on whether to keep a local break-glass account. Change approval windows, testing cycles and the number of business owners who must sign off also set the pace. An illustrative plan might group applications into waves by risk and integration type, then migrate each wave after testing. Confirm the wave plan and acceptance criteria before accepting any timeline.

What does the work require from our own staff?

Your staff must supply knowledge and approvals that no outside team can provide alone. Identity and access owners need to define who belongs to which groups and roles, and which person approves access to each application. Application owners must confirm how each system authenticates users, which accounts are local, and which must remain. Your directory administrators must grant the integration accounts the rights needed to read and provision users. Security and compliance leads need to agree on the evidence they will keep. Plan for time from these people during design, testing and cutover, and name a single owner for the central service after handover. Ask the implementation partner to list each role it expects from your team, with the hours or meeting cadence it assumes.

Can an in-house team meet Safeguard 5.6 without an outside partner?

Yes, an in-house team can meet the Safeguard if it has the skills to operate a directory or identity service, configure provisioning, and document the result. An outside partner is useful when the team lacks hands-on experience with the chosen platform, has limited capacity during the migration, or needs independent testing and evidence preparation. Open-source options such as FreeIPA, Keycloak, authentik and Zitadel each require configuration and ongoing operation inside your own infrastructure. DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms in your environment and runs fixed-scope engagements agreed in writing, with ongoing support available as a retainer. DeployOpen does not issue audit reports or certifications, so an independent auditor must still assess the result. Compare an internal plan and an external quote against the same written scope.

Is IG2 required for an organization to adopt Safeguard 5.6?

Safeguard 5.6 is assigned to Implementation Groups 2 and 3, and not to Implementation Group 1. That means an organization that has only the IG1 baseline does not need this Safeguard to claim IG1, but an organization that adopts the IG2 Safeguards must include it. Implementation Groups are based on the organization's size, complexity and the sensitivity of the data it holds, so the decision depends on your profile. CIS defines IG2 as adding Safeguards for enterprises with more operational complexity that often hold sensitive information. Confirm your Implementation Group with your governance function or the CIS Controls Implementation Groups guidance before scoping. Regulators, customers or contracts may require the Safeguard even where your CIS group does not, so check those obligations separately.

What will an auditor ask to see for Safeguard 5.6?

An assessor will typically ask to see evidence that accounts are managed from one central service and that the coverage described in the Safeguard is complete. Expect requests for an inventory of assets and software that shows which systems are in scope, the central directory or identity service configuration, and a list of applications integrated with it. Assessors often look for provisioning and deprovisioning records, the process for granting and removing access, and a list of exceptions with approvals and compensating controls. The CIS Controls Assessment Specification measures coverage across assets, so a current mapping of applications to central authentication is central to the evidence. Ask your auditor which evidence format and sampling approach it expects before the review begins.

Which parts of the work do organizations usually outsource?

Organizations most often outsource the platform build, application integrations, and evidence preparation, because these require specialized skills and time that internal teams may not have. Common examples include deploying the directory or identity service, configuring SCIM or federation for target applications, testing failover and access reviews, and documenting the configuration. Organizations usually keep ownership of access policy, role design, approvals, and the decision to retire local accounts. Independent assessment is always separate from implementation work. Ask each provider to state which deliverables it owns, which items you retain, and how handover is tested.

How DeployOpen works on this

DeployOpen plans and implements centralized account management for Safeguard 5.6 inside your own infrastructure, using self-hosted open-source identity platforms. We prepare the systems and evidence that show accounts are managed from one directory or identity service, while your organization owns the control and an independent assessor reviews it.

How we scope

Engagements are fixed-scope, with the in-scope asset classes, applications and identity sources agreed in writing before work starts.
The written scope names which applications must receive accounts from the central directory and which must be excluded.
Scope records prerequisite inputs for Safeguard 5.6, including the enterprise asset and software inventories that the assessment specification relies on.

How we build

We deploy the chosen directory or identity service in your cloud accounts, data centers or air-gapped network.
Provisioning connectors are configured so user and group creations, changes and removals propagate to target applications.
We test joiner, mover and leaver cases and record the results so coverage can be measured against the agreed scope.

How we hand over

You receive configuration documentation, a coverage report mapping applications to the central identity source, and test records.
Runbooks explain how administrators add applications, review exceptions and respond to failed provisioning.
Your team owns the controls and the evidence; DeployOpen does not issue audit reports or certifications, and independent assessors review the results.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, agreed separately from the initial scope.
Retainers can cover platform patching, periodic coverage checks and updates when new applications join the central identity source.
Ask any proposal to confirm which assessment evidence is refreshed, how often, and who in your team receives it.