What Safeguard 6.7 asks for and why centralized access control is hard
Safeguard 6.7 asks for access control to every enterprise asset to be run from a central directory service or single sign-on (SSO) provider wherever the asset supports one. It applies at Implementation Groups 2 and 3, not IG1, so an IG1 organization can treat it as a later goal. If a customer questionnaire or CIS-aligned program asks whether access is centralized, the honest answer is a list of every asset, the directory or SSO service that governs its sign-in, and the assets that cannot yet be integrated, with a plan for each. Safeguard 5.6 is a different question. It concerns centralizing account management, meaning who creates, changes and disables accounts. Safeguard 6.7 concerns where authentication and authorization decisions are made for each asset. An organization can pass one and fail the other, so the two should be evidenced separately.
The risk sits in local accounts and per-application logins. Each application or device that keeps its own user store creates a separate place where a leaver can remain active, a password can be reused, and an access review has to be repeated by hand. Central control shortens that list, but only for assets that accept the central service. Legacy systems, embedded appliances, some industrial and medical devices, and older network gear often support only local accounts, a vendor-specific authentication method, or a protocol the directory cannot serve. For these assets the realistic decision is not whether to integrate but how to compensate: restrict who can reach the asset, record each use of a local account, and document the exception with an owner and an end date. Confirm with each vendor which authentication methods the product supports before assuming integration is possible.
Before estimating effort, build the scope from Safeguards 1.1 and 2.1, the enterprise asset and software inventories that the CIS Controls Assessment Specification lists as prerequisites for measuring 6.7. Without those inventories, the coverage measure has no denominator. Then classify each asset as integrated, integrable with work, or exception. The cost of the work depends mostly on the count of integrations and the number of exceptions, not on the directory product itself. Costs that recur include directory and SSO licensing or hosting, maintaining connectors, and reviewing exceptions. Ask any implementation partner to price integration per asset class, to state what happens to exceptions at each review, and to name who in your organization owns the directory after handover.
Which assets, applications and teams fall under Safeguard 6.7
Safeguard 6.7 applies to enterprise assets in the Users asset class, but the boundary is set by what each system can actually integrate with. The cards below cover the scoping decisions that determine how much work the Safeguard creates and what evidence an assessor will ask for.
Enterprise assets in the Users asset class
Safeguard 6.7 sits in the Users asset class, so the starting point is the set of user-facing systems that let people sign in: workstations, laptops, servers accessed by staff, and business applications. Use the enterprise asset inventory from Safeguard 1.1 to list each one, then mark whether it authenticates against a directory or SSO service today. Scoping decisions made here set the denominator for the coverage metric, so record the rationale for every system left out.
Assets that cannot join a directory
Some devices, appliances and legacy servers have no supported method for directory or SSO integration. Each of these is an exception that the organization must document, not a silent gap. Confirm with the vendor whether a supported LDAP, RADIUS, Kerberos or SAML option exists, and record the compensating controls, such as local account restrictions or network isolation, that apply until the asset can be integrated or retired.
Cloud and SaaS applications
Cloud and SaaS applications are often the largest share of centrally managed access in scope. Check whether each application supports SAML, OpenID Connect or SCIM provisioning, and whether local password logins can be disabled for administrators. Applications that offer only local accounts must be listed as exceptions or moved behind an identity proxy. Treat each tenant or instance as a separate item in the inventory.
Service-provider-hosted systems
Systems run by a service provider still fall within the enterprise's access control obligations. The contract should state whether the provider will federate with the organization's directory or SSO service, and who maintains the integration. Ask providers for their administrative account list and their support access process, since those accounts can bypass central controls if they are not federated. Link these systems to the provider oversight records covered under Control 15.
Identity systems as dependencies
The directory or SSO service becomes a dependency for every system that delegates sign-in to it, so it must appear in scope and in the authentication and authorization systems inventory under Safeguard 6.6. Identify which systems depend on it, how it is backed up, and what happens to sign-in if it fails. Open-source options such as authentik, FreeIPA and Keycloak each serve different parts of this role, and the choice determines which applications can federate with it.
Exception records and their owners
Every asset or application that cannot be centralized needs a dated exception record with a named owner, the reason it cannot integrate, the compensating controls in place, and a review date. Assessors look for these records when they test the coverage measure, and they reveal whether the exception list is shrinking over time. Keep the register in the same system as the asset inventory so the two cannot drift apart.
How an assessor tests centralized access control
This table shows how an assessor approaches Safeguard 6.7 under the CIS Controls Assessment Specification, from prerequisite inputs through sampling to common findings. Read it as a checklist of what to have ready before an assessment, and note that the specification defines what to measure while leaving the method of measurement to the assessor and the organization.
| Assessment area | What the assessor looks for | Where organizations usually fall short |
|---|---|---|
| Prerequisite inputs | Enterprise asset inventory from Safeguard 1.1 and software inventory from Safeguard 2.1 used as the population for testing | Inventories are incomplete, so the assessor cannot confirm which assets should be covered by central access control |
| Measure 1: Enterprise assets in scope | Each in-scope asset that supports central authentication is listed and tied to a directory or SSO source | Assets that were never added to the directory integration or are missing from the inventory entirely |
| Measure 2: Central authentication in use | Sign-on for each in-scope asset actually routes through the directory or SSO provider, confirmed by configuration and test logins | Configuration says central, but a fallback local login still works on the asset |
| Measure 3: Local accounts and exceptions | Local accounts are disabled or justified, and every exception is documented with an owner and a review date | Local accounts left active, and exceptions held in email or memory rather than a register |
| Combined coverage metric | The three measures produce one coverage figure that the assessor recalculates from the sample | Coverage reported by a dashboard that the assessor cannot reproduce from raw records |
| Sampling | Assessor selects a sample of assets across device types and asks for directory and SSO configuration exports, login logs and asset records | Only servers are documented, while network devices, appliances and cloud-hosted assets are left out of the sample |
| Common finding: unlisted assets | Assets present on the network but absent from the central access control population | Devices added outside the normal build process, such as lab hardware or contractor equipment |
| Common finding: undocumented exceptions | Each exception has a stated reason, approver and compensating control | Exceptions granted verbally, with no record of who approved them or when they end |
How to implement centralized access control in sequence
This sequence moves Safeguard 6.7 from a list of assets to a measured coverage figure, so the organization can show which enterprise assets authenticate through a central directory or SSO service and which need documented exceptions. Each step produces an artifact that the next step depends on.
Build the asset and software inventories
Start from the enterprise asset inventory under Safeguard 1.1 and the software inventory under Safeguard 2.1, which the assessment specification lists as prerequisites because they supply the data the 6.7 measurement needs. IT operations owns the work, with input from application owners for systems that do not appear in discovery tools. The step is done when every asset and application has a unique record with an owner and a current status, and you can export both lists for the coverage calculation.
Classify each asset by directory or SSO support
For each device, operating system, network service and application, record whether it can authenticate against a directory service such as LDAP or Active Directory, or delegate sign-in through an SSO provider using a standard protocol. Vendor documentation is the primary source, and the team should test the claim in a lab before marking an asset as supported. The output is a classification column in the inventory with a named test result or vendor reference for each supported entry.
Select the central identity source
Choose the directory or SSO service that will act as the system of record for user identity, based on which assets must be covered and where accounts are already managed. Common options include an existing enterprise directory, a Linux-focused directory such as FreeIPA, or an open-source identity provider such as authentik or Keycloak that federates with an existing directory. Architecture, security and identity leads approve the decision in writing, and the output is a short design note naming the identity source, its high-availability design and the administrators who control it.
Integrate supported assets and applications
Connect each supported asset and application to the chosen identity source, using the protocol that the vendor documents, such as OpenID Connect, SAML, LDAP or RADIUS for applications and directory binding for operating systems. Where a system must also receive account changes automatically, a provisioning tool such as midPoint can create, update and disable accounts on connected systems from user changes and role assignments. Engineers test sign-in and a disabled-account scenario on each integration, and the output is an integration record per system with the test date and result.
Document exceptions with compensating controls
List every asset that cannot use the central identity source, such as legacy devices, embedded systems, appliances with local-only accounts or software with no directory support. For each exception, record the business reason, the owner, the local accounts that remain, and the compensating controls that limit risk, such as restricted network access, separate credentials stored in a managed vault, and scheduled review. Risk owners approve each exception, and the output is an exceptions register that the assessor can read alongside the inventory.
Measure coverage and retain the evidence
Calculate the coverage measure defined in the assessment specification for Safeguard 6.7: the share of enterprise assets that are supported and authenticate centrally, with exceptions shown separately. Confirm the calculation method against the specification before reporting, because it combines three measures into one coverage metric. Retain the dated inventory export, classification results, integration tests, exceptions register and coverage report, and repeat the measurement on a schedule the organization sets. The output is a coverage report that an independent assessor can trace back to source records.
How directories, SSO brokers and provisioning tools fit together
A directory service holds the identities, an SSO provider decides who can sign in to which application, and a provisioning engine keeps accounts in step with role assignments. Safeguard 6.7 is met when access to every enterprise asset that supports it runs from one of these central points rather than from local accounts on each system. In practice, the directory (often Active Directory or an LDAP server) remains the source of truth for who a person is, the SSO layer handles sign-in for applications, and the provisioning layer creates, changes and removes the accounts those applications and systems need. Each component can be open source, but the three roles are distinct, and a single product rarely covers all of them equally well. Confirm with each vendor which of these functions it provides natively and which need integration work.
Applications delegate sign-in when they stop storing passwords themselves and redirect users to the SSO provider. authentik (MIT) illustrates this model: it acts as an identity provider through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so each application is configured as a relying party. For directory-backed environments, Keycloak (Apache-2.0) user federation connects to existing LDAP or Active Directory servers and synchronizes users into Keycloak, so accounts managed in the corporate directory are the ones used for application sign-in. Linux and UNIX hosts follow a different path: FreeIPA (GPL-3.0-or-later) provides single sign-on for those environments through an MIT Kerberos KDC. Before choosing a pattern, list which assets in your Safeguard 6.7 scope can accept federated sign-in and which must keep local authentication, because the Safeguard only applies where the asset supports central control.
A provisioning tool such as midPoint (EUPL-1.2+) closes the loop between role assignments and account state. It creates, updates and deletes accounts on connected systems based on user changes and role assignments, and keeps them aligned through provisioning, live synchronization, scheduled reconciliation and discovery, with separately defined inbound and outbound rules. The practical check is whether a leaver's directory account, SSO access and application accounts are disabled together, and whether reconciliation reports any account that exists on a system without a matching identity. Ask the implementation partner to document the rules for each connected system, since drift between them is where centralized access control usually fails in audit.
Evidence that proves centralized access control
Safeguard 6.7 is measured as coverage: how many enterprise assets authenticate through a central directory or SSO service where they support it. The cards below are the records an assessor will ask for to test that coverage, and each one must stay current between audits rather than being assembled at audit time.
Enterprise asset and software inventories
The coverage denominator starts here. The Safeguard 1.1 asset inventory and Safeguard 2.1 software inventory list every device and application in scope, and the Assessment Specification treats them as prerequisites because they supply the data the measurement needs. Check that each asset record names its owner, its asset class and whether it supports directory or SSO sign-in. Reconcile the inventory against discovery output at a fixed interval so new assets do not silently fall outside the count.
Integration register by source
This register maps each asset and application to the directory or SSO source that authenticates it, such as an LDAP or Active Directory server, a Kerberos realm or an OpenID Connect provider. It is the document that shows the coverage numerator is real. Record the integration method, the owning team and the date the link was last verified. Assets with no entry are the first exceptions to investigate.
Configuration exports
Exports from the identity platform show the mechanism, not just the claim. Keep dated copies of provider definitions, user federation settings, Kerberos or LDAP bind configuration and application client registrations, stored under change control. An assessor can compare a Keycloak realm export or an authentik provider list against the register and confirm that disabled local login is not left open on in-scope systems. Export after every change window.
Central authentication login logs
Login logs prove that assets actually authenticate through the central source during operation. Collect sign-in events from the directory or SSO service and sample them against the integration register, looking for local accounts that authenticate without a central record. Retain these logs under your Control 8 retention rules so the sample period covers the audit window. Confirm that failed and bypassed sign-ins are logged as well as successful ones.
Exception register with approvals
Some assets cannot use central authentication, such as appliances with fixed local accounts or legacy systems. Each one needs an entry with the technical reason, the compensating control, a named risk owner, an approval date and a review date. The Safeguard asks for coverage where supported, so an assessor will treat an undocumented exception as a failure. Review every exception at least at each access review and close it when the platform is replaced.
Periodic coverage reports
The coverage metric is the result, and a dated report is what an assessor reviews. Calculate the share of in-scope assets authenticating centrally, list the exceptions by ID and show the trend from the previous period. Generate the report from the inventory and register rather than by hand, and sign it off by the control owner. Confirm with your assessor which reporting interval and sample size they expect before you build the process.
What centralizing access control costs in money and effort
This table breaks down the cost components of centralizing access control for Safeguard 6.7, showing who is paid, whether each cost is one-time or recurring, and what drives it up. Use it to build a quote request and to decide where an implementation partner's fixed-scope work fits. No prices are given because none were supplied for this topic, so confirm each figure with the vendor or your own environment.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Directory or SSO licensing | Commercial vendor, if a proprietary directory or SSO product is chosen | Usually recurring, confirm with vendor | User count, premium features, and number of connected applications |
| Self-hosted open-source platform | Hosting infrastructure in your cloud or data center, plus staff or partner time | Hosting recurring, software license spend removed | Hosting size, high-availability design, and backup scope |
| Integration engineering | Internal staff or an implementation partner under a written scope | One-time per application, with ongoing change work | Number of applications, protocol support (OIDC, SAML, LDAP, RADIUS), and custom logic |
| Legacy asset remediation | Internal engineering or the owner of each legacy system | One-time, with recurring exceptions | Count of assets that cannot authenticate against a central service and need compensating design |
| Inventory prerequisites (Safeguards 1.1 and 2.1) | Internal asset and software owners, or a partner doing discovery | One-time build, then recurring upkeep | Maturity of existing asset and software inventories and how many unmanaged systems exist |
| Evidence upkeep | Internal compliance or security staff | Recurring | Frequency of access reviews, number of systems in scope, and how well logs and reports are automated |
| Auditor sampling and testing | Independent auditor or assessor, paid under its own engagement | Recurring per assessment cycle | Number of systems sampled, quality of central reports, and whether exceptions are documented |
| Governance and exception handling | Internal owners of identity and application decisions | Recurring | Number of exceptions to central sign-in and the time needed to approve or retire them |
Who owns centralized access control and what a partner can take on
Your organization owns Safeguard 6.7. That means the decision to run access control for each enterprise asset from a central directory or single sign-on service, the list of assets that are exempt because they cannot support central authentication, and the sign-off on every exception. Your team also owns the access policy that defines who may be granted which access, and the review cadence that confirms the central service still reflects reality. A partner can draft these materials, but the accountable owner must approve them and be able to explain them to an assessor.
- Scope decisions: Decide which enterprise assets must authenticate centrally and which are exceptions, with a named owner for each exception.
- Exception approval: Record the business reason, compensating measures and review date for every asset that cannot use central access control.
- Policy ownership: Approve the access control policy and the rules for which directory or SSO service is the source of truth.
- Ongoing review: Confirm that new assets, applications and service providers are onboarded to the central service before they go live.
- Evidence custody: Keep the coverage reports and exception register in your own systems so they remain available after any partner engagement ends.
Check that every exception has a named owner who signed it, and that your team can reproduce the coverage figure without the partner present.
An implementation partner can take on the technical work that makes central access control possible. For example, a partner may integrate applications with an identity provider, configure the directory and SSO stack, set up provisioning rules, and prepare the coverage evidence the assessment specification asks for. Work of this kind is usually scoped in writing, delivered on your infrastructure, and handed over with documentation. The partner prepares systems and evidence. It does not decide which assets are in scope, does not accept risk on your behalf, and does not certify the result.
- Application integration: Connect applications to the chosen identity provider and document the protocol used for each, such as OAuth2, OpenID Connect, SAML or LDAP.
- Identity stack configuration: Configure the directory, SSO and provisioning components inside your own cloud accounts, data centers or air-gapped networks.
- Coverage evidence: Prepare reports that show which enterprise assets authenticate through the central service, with the measurements your team has agreed.
- Handover: Document configuration, runbooks and known exceptions so your staff can operate the stack after the engagement.
- Scope limits: Work is defined by a fixed written scope, so any change to the asset list or the measures is agreed in advance.
Check that the statement of work names the systems covered, the deliverables and who holds administrative credentials after handover.
An independent auditor, assessor or certification body tests whether Safeguard 6.7 is implemented and issues any report or certificate. The auditor samples assets, traces authentication paths, examines the exception register and checks whether the coverage measure is calculated correctly. This testing must be independent of the people who built the system, which is why the auditor cannot be the same firm that performed the implementation work. Note that CIS Controls content itself does not carry a certification, so the outcome depends on the framework your customer or regulator has asked you to map to.
- Sampling: The auditor selects assets and applications and checks whether each authenticates through the central directory or SSO service.
- Exception testing: The auditor reviews exceptions for approval, compensating measures and review dates.
- Measure verification: The auditor recalculates the coverage metric from source data rather than accepting a dashboard at face value.
- Independence rule: A firm that designed or configured the controls being tested should not also issue the assurance opinion on them.
- Report ownership: Only the independent auditor issues the report. Your partner and your team cannot.
Before engaging an auditor, confirm with them in writing how they will sample assets and whether they accept the evidence formats your team plans to produce.
Where organizations fall short on centralized access control
Why do unlisted assets break centralized access control?
Assets that never appear in the inventory are never enrolled in the directory or SSO service, so their local accounts sit outside central control. Safeguard 6.7 asks for access control on every enterprise asset where the asset supports it, which means the asset list is the starting point for the whole measurement. Closing this gap means reconciling the asset inventory from Safeguard 1.1 against directory join records, network discovery results and cloud account listings, then enrolling or retiring each difference. Record the reconciliation date and the owner of each asset class so an assessor can trace the list back to its sources.
How do undocumented exceptions weaken SSO coverage?
Exceptions granted informally, such as a vendor appliance that cannot join the directory, leave assets running on separate credentials with no review date. Over time these exceptions become the largest source of uncontrolled access, and nobody can say which ones are still needed. Close the gap by keeping a written exception register with the asset, the technical reason it cannot use central access control, the compensating control, the approver and a review date. Ask your team to confirm that each exception still has an active justification at every review cycle.
Why do local administrator accounts stay active after enrollment?
Enrolling a device in a directory rarely disables the local administrator account that shipped with it, so an attacker or a careless user can still sign in without central logging or revocation. This matters because the directory cannot revoke a credential it does not manage. Close the gap by inventorying local accounts on each enrolled asset, disabling or renaming built-in administrator accounts where the platform allows it, and storing any break-glass credential in a controlled vault with logged checkout. Confirm the approach against your platform vendor's documentation before changing production systems.
What does shadow SaaS outside SSO look like in practice?
Shadow SaaS is any cloud application that staff sign in to with a personal or team account that the identity team never created or reviewed. These applications bypass central sign-in, MFA enforcement and offboarding, so a departing employee may keep working access for months. Close the gap by pulling sign-in and expense data, cloud audit logs and browser extension reports to list applications in use, then moving each one to federated sign-in or retiring it. Assess each application's ability to use SAML or OpenID Connect before committing to a migration path.
Why does a stale integration register create access gaps?
Integrations such as service accounts, API clients and scheduled jobs often authenticate against applications directly, bypassing the SSO provider the register was supposed to describe. When the register is out of date, reviewers cannot tell which systems depend on local credentials, and retiring a user can break a job nobody knew existed. Close the gap by tying each integration to an owner, the systems it touches and the authentication method it uses, then reviewing the register on a fixed schedule and whenever an application changes. Confirm the register with the teams that run each integration, not only the people who created it.
How should coverage be measured so the result can be repeated?
Coverage measured by hand from spreadsheets or screenshots produces a number that another person cannot reproduce, which weakens it as evidence. The CIS Controls Assessment Specification defines measures for Safeguard 6.7 that are combined into a coverage metric, so the calculation should follow those measures using data that a directory or SSO export can produce. Close the gap by scripting the export on a schedule, storing each dated result, and keeping the query and the source inventory under version control. Ask your assessor which evidence format they accept before you build the process.
Who should own the work to close these gaps?
The organization owns the controls and the coverage decision, usually the identity or IT operations lead with security sign-off. An implementation partner such as DeployOpen can prepare the directory or SSO configuration, build the reconciliation and export scripts, and document the exception register, but it does not decide which exceptions are acceptable or issue any assessment report. Scope the work in writing before it starts, naming the asset classes, the systems to integrate and the evidence each deliverable produces. An independent auditor or certification body then tests the result.
Self-hosted open-source options for central authentication
No single open-source product covers Safeguard 6.7 on its own, so the practical question is which component carries which part of the central access control job. authentik (MIT) is the strongest fit for brokering application logins: it acts as an identity provider through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so web applications delegate sign-in to it instead of keeping their own credential stores. Keycloak (Apache-2.0) fills a similar role and its user federation can connect to an existing LDAP or Active Directory server and synchronize those users into Keycloak, so the corporate directory remains the source of accounts. Choosing between them depends on which protocols your applications speak and where you want the directory of record to sit.
FreeIPA (GPL-3.0-or-later) is the component to evaluate for Linux and UNIX single sign-on. It uses an MIT Kerberos KDC to provide SSO across those hosts, which addresses the part of Safeguard 6.7 that concerns servers and workstations that do not sign in through a web browser. midPoint (EUPL-1.2+) addresses a different gap: it creates, updates and deletes accounts on connected systems from user changes and role assignments, and keeps them aligned through provisioning, live synchronization, scheduled reconciliation and discovery, with separately defined inbound and outbound rules. Accounts that midPoint does not reach still need a manual or documented path, which the assessor will look for.
Before you adopt any of these, confirm each capability against your own environment rather than relying on this summary. Check which of your enterprise assets, including network devices and appliances, can authenticate against a directory or SSO service at all, because the Safeguard applies only where the asset supports it. Test that a sample of accounts, including administrative and service accounts, signs in through the central service and that a disabled account loses access everywhere it is federated. Record the results, the product versions you tested and the assets that remain local, since the Safeguard 6.7 measurement depends on that coverage picture and the vendor documentation is the authority on what each release supports.
How DeployOpen scopes and prepares evidence for Safeguard 6.7
The sequence turns Safeguard 6.7 into a written scope, a central sign-on design running in the client's own infrastructure, and a coverage record that the client's independent assessor can test. DeployOpen prepares the systems and evidence, while the organization owns the control and the assessor issues any report.
Agree the scope in writing
The client and DeployOpen agree which enterprise assets, applications and user populations fall under Safeguard 6.7, and which are excluded and why. The client owns the control and its scope decisions, and DeployOpen confirms the deliverables in a written fixed-scope agreement before work starts. The step closes when both parties sign a scope statement that names the in-scope asset classes, the directories involved and the acceptance criteria for coverage.
Confirm the prerequisite inventories
Coverage cannot be measured without knowing what exists, so the team checks that the enterprise asset inventory (Safeguard 1.1) and the software inventory (Safeguard 2.1) are current enough to list every asset that should authenticate through central access control. Gaps are recorded as open items for the client to close, since the inventories are the client's records. The step closes when the in-scope asset and software lists are reconciled against the directory and any unreconciled items are logged.
Map each asset to its central identity source
For each in-scope asset and application, the team identifies whether it supports centralized sign-in through a directory service or SSO provider and which mechanism applies, such as an OpenID Connect, SAML, LDAP or proxy integration. Assets that cannot take central authentication are recorded with the reason and the compensating control the client chooses. The step closes with a per-asset mapping table reviewed by the client's security owner.
Deploy and integrate self-hosted identity platforms
DeployOpen deploys the chosen self-hosted identity components inside the client's cloud accounts, data centers or air-gapped network, such as an identity provider, a Kerberos-based single sign-on service, or a federation layer that synchronizes users from an existing corporate directory. Where account lifecycle must follow role changes, provisioning tools can be configured with separately defined inbound and outbound rules. The step closes when test sign-ins succeed on each integrated application and the configuration is stored in the client's change control system.
Document the integration register and exceptions
The team builds an integration register listing each application, its identity source, the protocol used, the owner and the date of last verification, along with a formal exception log for any asset that remains outside central access control. Each exception needs an approver named by the client. The step closes when the register and exception log are reviewed with the client and stored where the assessor can request them.
Prepare coverage evidence for the assessor
The team assembles the records that show coverage: the inventory reconciliation, the integration register, configuration exports, sample sign-in logs showing central authentication, and the exception approvals. These are arranged to match the measures in the CIS Controls Assessment Specification for Safeguard 6.7, so the client can show how the coverage metric was calculated. The step closes when the client confirms the evidence pack is complete and reproducible.
Hand over and confirm the independent assessment
DeployOpen delivers the documentation, configurations and evidence pack to the client, and walks the client's team through how each record was produced. DeployOpen does not issue audit reports, attestations or certifications. The client's internal assessor or an independent auditor or certification body tests the evidence and issues any report or certificate. The step closes when the handover is accepted in writing and the client has scheduled its own assessment.
