What Safeguard 5.5 asks for and why service accounts need their own inventory
Safeguard 5.5 requires an inventory of service accounts, and it applies from Implementation Group 2 (IG2) upward, not at IG1. For each service account, the inventory must record at least the owning department, the review date and the purpose, and it must be reviewed at least quarterly so you can confirm every active service account is still authorized. If you have been asked to show this inventory to an auditor, a customer or a regulator, the test is simple: can you name who owns each non-human account, why it exists, and when someone last confirmed it should still be running?
Service accounts are non-human identities. Applications, scripts, scheduled jobs, backup tools and integrations use them to authenticate to databases, directories, cloud APIs and other systems. They are usually created by a project or a vendor installation, they often outlive the people who set them up, and they rarely have a password change or a login that would make them stand out. This is why they escape the user account inventory in Safeguard 5.1: a list built from people and their mailboxes will not show a credential that a batch job uses at 02:00. The risk is not only the account itself but the unowned, unreviewed credential behind it, which may hold broad privileges and no one is watching.
The work is hard for predictable reasons. Accounts were created by people who have left, the naming convention does not say what they do, and the same credential is often shared by several systems, so disabling it breaks something nobody documented. Start by pulling the authentication and authorization system records, since Safeguard 6.6 (the inventory of authentication and authorization systems) typically supplies the data this measurement needs. Then reconcile that export against application configurations and vault entries, assign an owner to each account, and confirm with the owner whether it is still needed. Ask your assessor early which evidence they will accept for the review dates and how they expect you to show the quarterly cycle.
Which service accounts and systems are in scope for the inventory
Safeguard 5.5 applies from IG2, so the first decision is whether your policy scope requires it. Once it does, the work depends on which account populations you count, and the cards below cover the categories that most often get missed. Each one needs an owner, a purpose and a review date before the inventory can pass a quarterly check.
Directory-based service accounts
These are non-human identities created in Active Directory, LDAP or an identity provider to run scheduled tasks, bind applications to the directory or connect integrations. They are usually found by exporting directory objects filtered for accounts that have no human owner or that never sign in interactively. Check that each one has a recorded owning department, a stated purpose and a review date, and that any account with a password that never expires is listed. Directory exports rarely show who owns an account, so the owner field usually needs a manual reconciliation.
Local service accounts on servers and appliances
Many servers, network devices and appliances run services under local accounts that never appear in a central directory. Discovery usually means querying each host's local user and service configuration, or reviewing configuration backups, and reading the account that each service runs as. Confirm that appliance vendors' default service accounts are inventoried and that the account is still needed. These accounts are easy to miss because they often outlive the software that created them.
Database and application accounts
Databases, middleware and business applications often hold their own service logins for connection pools, batch jobs and reporting tools. They are typically found by querying the database's role or user catalog and by reviewing application configuration files for embedded connection credentials. Record which application each login serves, because a shared database login used by several systems makes ownership and removal difficult. Confirm that accounts with administrative privileges inside the database appear in the inventory with the same fields as other service accounts.
Cloud workload identities
Cloud platforms create service identities for virtual machines, functions, containers and managed services, along with access keys issued to those identities. Discovery usually comes from the provider's identity and access management reports and from listing roles that workloads can assume. Check whether each identity is tied to a workload that still exists, whether long-lived access keys remain in use and who approves changes to its permissions. Identities created by infrastructure-as-code templates need an owner recorded in the template or tagging scheme.
CI/CD and automation accounts
Pipeline runners, deployment tools, configuration management and scheduled scripts authenticate with machine accounts, tokens or deploy keys. They are usually discovered by reviewing pipeline definitions, repository and project access settings and the secret stores these tools read from. Record the purpose of each account and which pipelines can use it, since a single token shared across many pipelines is hard to attribute. Secret detection reports from source control can help locate credentials that were committed to repositories, but they do not replace a complete inventory.
Third-party and vendor accounts acting inside the environment
Managed service providers, support vendors and software suppliers may hold accounts that run jobs or access systems on your behalf, sometimes as service accounts rather than named user accounts. Discovery means asking each contract owner and reviewing remote access tools, VPN profiles and vendor-created accounts in your directories. Confirm which vendor owns each account, what the vendor's review cadence is and how access is removed when the contract ends. These accounts are often absent from internal records because the internal team did not create them.
How an assessor tests the service account inventory
This table walks through how an assessor applies the CIS Controls Assessment Specification to Safeguard 5.5, from the existence and currency of the inventory to its completeness and accuracy against live identity data. Read each row as a test step, the evidence it needs and the gap that most often causes a failing result. The main takeaway is that the inventory must be current and must match what the directory actually contains.
| Test step | What the assessor checks | Evidence requested | Where it usually fails |
|---|---|---|---|
| Inventory exists | A service account inventory is present as a defined record, not an informal list or an assumption that accounts are managed elsewhere | The inventory file, register or system export that holds the service account records | No inventory exists, or accounts are tracked only inside individual application configurations |
| Currency | The inventory was last updated within three months, the window the specification uses to score the Safeguard as failing when exceeded | Version history, change log or timestamp on the inventory and the date of the latest review | Last update older than three months, or reviews recorded in a meeting note without changes to the record |
| Required fields | Each entry records at least the owning department, review date and purpose of the account | Sample entries showing all three fields populated for each service account | Owner recorded as an individual who has left, purpose left blank, or review date missing |
| Completeness | Every active service account in the live directory or identity system appears in the inventory | Directory or identity export of service accounts compared line by line with the inventory | Accounts created directly in applications, cloud roles or scripts that never reached the inventory |
| Accuracy | Inventory entries match the live state, including accounts that are disabled, renamed or repurposed | Side-by-side comparison report showing matches, orphans and stale entries | Entries for deleted accounts still listed as active, or accounts whose purpose changed without an update |
| Starting data | Assessors commonly begin with the authentication and authorization system inventory required by Safeguard 6.6, which the specification lists as a prerequisite for measuring Safeguard 5.5 | The Safeguard 6.6 inventory and the directory sources it covers | Identity systems omitted from the Safeguard 6.6 inventory, so service accounts in those systems never reach the comparison |
| Conclusion | Only an independent assessor draws the final conclusion on whether the Safeguard is met, based on the test results | Assessor's working papers and report, issued by the assessor and not by the organization or its implementation partner | Organization treats internal or partner testing as a formal result, which does not replace independent assessment |
How to build the service account inventory step by step
This sequence turns scattered service accounts into a governed inventory with an owner, a documented purpose and a review date for each account, plus a repeatable quarterly check that Safeguard 5.5 assessors can test.
Agree the definition of a service account
Write a short definition in the account management policy that says what counts as a service account in your environment, such as non-human identities used by applications, scheduled jobs, pipelines, integrations and monitoring agents. Name the owner of the policy and the approver. Include rules for who may request a service account and what a request must state. The output is an approved policy section that the inventory can be tested against. Confirm the definition with the teams that run cloud, identity and application platforms so that no class of account is left out.
Export candidate accounts from every source
Pull account lists from directories, cloud identity services, application administration consoles, CI/CD systems, databases and secrets stores. Record the source system, export date and the fields each system provides, such as account name, creation date, last authentication and whether it is enabled. Keep the raw exports unchanged so that the reviewer can trace each row back to its source. The output is a set of dated candidate lists, one per platform. Ask each platform owner which exports are read-only and which need an administrator to run them.
Reconcile candidates against authentication system data
Compare the candidate lists with the inventory of authentication and authorization systems produced under Safeguard 6.6, which the CIS Controls Assessment Specification treats as a prerequisite for measuring Safeguard 5.5. Flag accounts that appear in a system but not in the identity inventory, and identity records that have no matching account. Each unmatched item becomes a ticket for the platform owner. The output is a reconciliation sheet with every candidate either matched or assigned an open action. Repeat this comparison whenever the source systems change.
Assign an owning department and documented purpose
For each reconciled account, record the owning department, a named accountable person and a purpose statement written in one or two sentences. The purpose should say which system the account serves and what it does, such as reading a database for a reporting job. Accounts without an owner or purpose are marked as unauthorized until someone claims them, and the platform team decides whether to disable them. The output is a complete inventory where every active service account has an owner and a purpose.
Set a review date for each account
Give every inventory entry a next review date that falls within the quarterly review cycle the Safeguard requires. Store the date in the inventory so that a report can show which entries are due. Tie the date to the owner so that the reminder reaches the person who can confirm the account is still needed. The output is an inventory with a review date field populated for every row. Assessors check the last update date of the inventory, so keep the inventory in a system that records change history.
Run the first quarterly review
Ask each owner to confirm that the account is active, still required, correctly described and linked to the right system. Remove or disable accounts that are no longer needed, and record the decision and the reviewer's name. Compare the reviewed list against the last export to catch accounts created outside the process. The output is a signed review record and an updated inventory with a new last-reviewed date. The CIS Controls Assessment Specification scores the Safeguard as failing when the inventory is missing or was last updated more than three months ago, so schedule the review before that point.
Set change triggers for new service accounts
Connect account creation to the inventory so that a new service account cannot be active without a record. Options include a request form that creates the inventory entry before the account is provisioned, a provisioning pipeline that writes the owner and purpose to the inventory automatically, and an alert when an account appears in a source system that is not in the inventory. Test the trigger by creating a test account in a non-production environment and confirming the inventory changes. The output is a documented workflow and a test record showing the trigger works.
Evidence that passes a service account inventory review
An assessor testing Safeguard 5.5 looks for proof that the service account inventory exists, is complete and was updated recently. The artifacts below each answer one of those questions, and they only hold up if they are generated or signed on a schedule rather than rebuilt the week of the audit.
Service account inventory export
The core artifact is an export of the inventory with, at minimum, the owning department, the purpose and the review date for every service account. Check that each row maps to a real account in the directory or identity system, and that no field is blank. Keep the export generated from the source system on a schedule, with the generation date recorded in the file, so the document an assessor sees is the one the system produced. An inventory maintained by hand in a spreadsheet is the weakest form of this evidence because it cannot prove completeness on its own.
Dated quarterly review records
Each quarterly review should produce a dated record listing the accounts examined, the reviewer, the decision for each account (keep, change owner, or disable) and a sign-off by the accountable owner. Assessors test whether the reviews happened on time and whether they removed anything, so an empty review with no decisions weakens the case. Store each record in version control or a document system with write-once history so the sign-off dates cannot be changed later.
Discovery export for reconciliation
Pull a list of accounts directly from the directory, identity provider or host systems, then compare it with the inventory. Any account that appears in discovery but not in the inventory is a gap, and any inventory entry with no matching account is stale. Keep the discovery exports with timestamps alongside the reconciliation results. In a self-hosted directory such as FreeIPA, the directory itself is the natural source for this comparison, and the reconciliation can be scripted to run before each review.
Change records for account creation and removal
Every new service account and every decommissioned one should trace to a ticket or change record that names the owner and the purpose. Assessors often sample recent creations and removals to check that the inventory was updated at the same time. Link each change record to the inventory entry, and record the removal date for retired accounts so the inventory shows what was active during a given period, not only what is active today.
Owner list and accountability record
The owner list names the person accountable for each owning department, with contact details and the date the list was last confirmed. It answers the question an assessor asks when a service account has no obvious owner: who decides whether it stays. Confirm that owners have actually acknowledged responsibility for their accounts, and treat any account whose owner has left the organization as a finding to resolve before the next review.
Sample-based walkthrough readiness
Assessors usually pick a sample of service accounts and ask for the full trail for each: the inventory entry, the owner, the purpose, the review record that approved it and the change record that created it. Before an audit, pick a few accounts yourself and confirm that every artifact can be produced within a short time. The gap between a clean inventory and a clean trail is where most findings come from, so test the trail, not only the list.
What meeting Safeguard 5.5 costs in money and effort
This table lists the cost components of building and keeping a service account inventory, who is paid for each one, whether it is one-time or recurring, and what pushes it up. Use it to shape a quote request and to decide which parts to keep in-house. No price or duration figures are supplied for this Safeguard, so confirm effort with your own team and ask any partner for a fixed-scope quote.
| Cost component | Who pays or does the work | One-time or recurring | What drives it up |
|---|---|---|---|
| Tooling or licenses | Organization, through license purchases or self-hosted platform setup | Recurring for commercial licenses; one-time for setup of open-source components | Number of directories, identity providers and applications that must feed one inventory |
| Discovery and reconciliation engineering | Internal platform or identity engineers, or an implementation partner on a fixed scope | One-time, with periodic rework after major changes | Accounts created outside the directory, undocumented scripts and integrations, and multiple cloud tenants |
| Ownership assignment | Application owners and department leads, supported by IT | One-time for the first pass, then recurring as owners change | Service accounts with no named owner, and staff turnover in owning teams |
| Quarterly review by owners | Named owners of each service account, with a reviewer in IT or security | Recurring, at least quarterly | Number of service accounts per owner and how many lack a documented purpose |
| Evidence upkeep | Operations or compliance staff who keep the inventory, review records and change history current | Recurring | How often service accounts are created or retired, and whether the inventory is generated or hand-edited |
| External testing or review | Independent assessor or consultant, if engaged | Recurring when scheduled, one-time for readiness reviews | Scope of the review, the number of environments in scope and whether a prior gap analysis exists |
| Auditor sampling | Independent auditor, billed under its own engagement terms | Recurring with each audit cycle | Sample size the auditor selects and how quickly the team can produce records for the selected accounts |
Open-source tools that support the service account inventory
Each tool below produces or holds data that an assessor can use to test Safeguard 5.5, but none of them is the inventory itself. The organization still needs one register of service accounts with owner, purpose and review date, and each tool helps keep that register accurate.
authentik SCIM provisioning
The authentik SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0 and runs a full sync every hour. When a user loses access to an application, authentik deprovisions that user in the target. This helps keep application-side accounts aligned with the identity source, so the inventory can be checked against what each application actually holds. Confirm with the vendor which fields are synchronized and whether service accounts, which are often not tied to a person, are covered by the sync or must be managed separately.
FreeIPA directory records
FreeIPA uses 389 Directory Server as a multi-master LDAPv3 directory that stores users, groups, hosts and other network objects. Centralized access control and delegated administration let a directory owner record who manages each account and group. Use it as the authoritative place where a service account object can carry an owner and purpose, then export that record into the register. Confirm with the project which attributes can hold owner, purpose and review date, and whether your team needs a custom attribute or a separate field convention.
OpenBao dynamic credentials
OpenBao stores secrets encrypted in one place and generates dynamic, short-lived credentials for systems such as databases. Each credential carries a lease that revokes the secret automatically on expiry, and single secrets or whole trees of credentials can be revoked. For service accounts that authenticate with stored passwords or keys, this shifts the question from who holds a static credential to which role issued a lease. Assessors will still expect the register to name the account and its owner, so confirm with the vendor how lease and role metadata can be exported for review.
GitLab secret detection reports
GitLab Community Edition runs pipeline secret detection on files committed and pushed to a repository, and writes detected secrets to a gl-secret-detection-report.json job artifact in every tier. The report helps find hard-coded service credentials that never appeared in any inventory, which is the gap an assessor is most likely to probe. Treat each finding as a candidate for the register: either the credential belongs to a documented service account, or it must be rotated and the account reviewed. Confirm the scanner's detection coverage for your languages and file types with the vendor before relying on it.
Who owns the inventory, who can help, and where the auditor stops
Your organization owns Safeguard 5.5 in full. The inventory is an operating record of your accounts, and the people accountable for it are the ones who know why each service account exists. Someone on your side must name an owner for every service account, decide who approves each quarterly review, and keep the review cycle running after any outside help has left. An assessor will ask who signed off the inventory and when, so those answers need to come from your staff.
- Account ownership: Assign each service account a named owning department and an accountable person who can confirm its purpose.
- Review approval: Set who approves the quarterly review and record the date and outcome of each review.
- Decommissioning decisions: Decide what happens to accounts that no owner can justify, including disablement and removal from applications.
- Ongoing operation: Keep the inventory current as applications are added, changed or retired, rather than updating it only before an assessment.
- Policy alignment: Confirm that the procedure for service account creation requires an inventory entry before the account is used.
Check that every service account in your inventory has a named human owner and a review date within the last quarter.
An implementation partner can help you build the mechanics of the inventory. Typical work includes discovering service accounts across directories, applications and hosts, reconciling what is found against what owners report, configuring the tooling that exports and timestamps the inventory, and drafting evidence templates for the review record. The partner prepares systems and evidence for your use. It does not decide whether your inventory is complete, and it does not state that Safeguard 5.5 is met.
- Discovery and reconciliation: Gather account data from identity and infrastructure sources and list the differences for your owners to resolve.
- Tooling configuration: Set up exports and scheduled reports from the systems that hold account data, such as directory and identity services.
- Evidence templates: Provide record formats that capture owner, purpose, review date and approval for each review cycle.
- Knowledge transfer: Document the procedure so your staff can run the quarterly review without the partner.
- Independence limit: A partner that prepared the inventory and its evidence should not also test it or issue any conclusion on it.
Confirm in writing which deliverables the partner produces, which remain with your staff, and that the partner will not perform the assessment.
An independent auditor, assessor or certification body is the only party that tests the inventory against the requirement and issues findings or reports. Where your program uses the CIS Controls Assessment Specification as a reference, the assessor checks the completeness and accuracy of the inventory and whether it was updated within the required window. The assessor samples accounts, traces them to their owners and approvals, and compares the inventory to systems it independently identifies. CIS does not certify organizations against the Controls, so the assessor's role depends on the program requesting the review.
- Completeness testing: The assessor compares the inventory against account data it obtains directly from directories, applications and hosts.
- Accuracy testing: The assessor traces sampled entries to owners, purposes and approval records.
- Currency testing: The assessor checks the last update date and the dated review records against the review interval.
- Findings and reports: Only the assessor issues the findings, report or attestation, and the assessor sets its own sampling approach.
- Independence rule: The assessor should not have designed the inventory or prepared its evidence in a way that makes it the author of the test.
Ask the assessor which systems and sample sizes it will use, and whether it accepts evidence prepared by a partner.
Where service account inventories usually fall short
Most service account inventories fail on two measures the assessor applies: whether the inventory exists and is current, and whether it is complete and accurate. The gaps below are where those two measures break down in practice, and each one has a specific check you can run before an assessment.
Accounts without a named owner
A service account with no owning department cannot be reviewed, because nobody is accountable for confirming it is still needed. Safeguard 5.5 requires the owning department for every entry, so an inventory row with a blank or generic owner such as "IT" fails the completeness measure. Check that each account maps to a named team, and that the owner is someone who can answer for its purpose and privileges.
Inventory last updated over three months ago
The assessment specification scores Safeguard 5.5 as failing when the inventory was last updated more than three months ago, so a quarterly review cycle is the minimum to plan around. Teams often keep an inventory that was accurate at audit preparation and then let it drift. Record the review date on every entry and set a recurring calendar reminder tied to the quarter.
Accounts created in consoles and never recorded
Cloud consoles, CI/CD tools and SaaS admin pages let engineers create service accounts and API identities in a few clicks, and those rarely reach the inventory. Completeness is the metric most often failed for this reason. Compare the inventory against identity provider exports, cloud IAM listings and application admin screens, and treat any account found outside the inventory as a gap to fix, not a footnote.
Reviews signed off without checking usage
A quarterly review that only confirms the list still exists does not show that each account is authorized. Reviewers should see the last authentication or API call for each account and the privileges it holds. For example, an illustrative account that last authenticated two years ago but still has write access to a production database should be flagged and removed, even if its name appears in the inventory.
Decommissioned systems leave accounts enabled
When an application or server is retired, its service accounts often stay enabled because nobody linked them to the system's decommissioning checklist. These orphaned accounts remain valid credentials that no owner monitors. Add service account removal to every decommissioning step, and reconcile the inventory against the current list of running systems at each review.
Questions buyers ask about the service account inventory
How much effort does the first service account inventory take?
The effort depends mostly on how many service accounts exist and how many places they are defined. A small estate with a few directories and a handful of scheduled jobs is a short exercise. A large estate, where service accounts sit in directories, cloud IAM roles, database logins, CI/CD runners, scheduled tasks and application configuration files, takes much longer because each account must be found, traced to a running process and matched to an owner. The first build is usually the most expensive part. Ongoing quarterly reviews are smaller, but they only stay accurate if new accounts are added to the inventory when they are created. Ask any provider to break the quote into discovery, reconciliation with existing records and the first review cycle, so you can see where the time goes.
Can our own team build the service account inventory in-house?
Yes, many organizations do. Safeguard 5.5 does not require an outside party, and the organization owns the inventory and the decision to keep each account. The practical question is whether your team can find accounts that nobody remembers creating. Discovery usually needs read access to directories, cloud identity, databases and build systems, plus someone who can ask application teams what each account is for. Teams often choose a hybrid model: internal staff own the register and reviews, while an implementation partner builds the discovery queries, a template and the automated sync. Whichever route you take, the inventory is only credible if the owners named in it are real people who confirm the account is still needed.
What must our team provide before a provider starts?
The provider needs access and decisions, not just time. Expect to supply read-only access to the directory and identity systems in scope, a list of the platforms that run workloads, and a named executive or owner who can resolve disputes over which department owns an account. You will also need to confirm which fields the register must hold, which in this Safeguard are at least the owning department, the review date and the purpose, and how often reviews run, which should be at least quarterly. Agree in writing who approves account removals and how removals are recorded. Without these inputs, the first inventory tends to stall at the ownership step.
How long does a first service account inventory take to build?
The duration depends on the size of the estate, the number of platforms holding service accounts, how well existing records match what is running, and how quickly application owners respond. Organizations with clean directory records and few platforms finish faster. Those with undocumented scripts, shared credentials and accounts created for projects that have ended take longer, because each finding needs investigation before it can be assigned an owner. No duration is quoted here. Ask a provider to state its assumptions about platform count, access and owner availability, and to tie the timeline to a written scope before work begins.
Do organizations in Implementation Group 1 have to build this inventory?
No. In CIS Controls v8.1, Safeguard 5.5 is assigned to Implementation Groups 2 and 3, not to Implementation Group 1. An IG1 organization should still track its accounts, because the Safeguard 5.1 account inventory covers user, administrator and service accounts, and a service account nobody can explain is a common source of access risk. The IG2 extension adds the dedicated service account register, the owner and purpose fields, and the quarterly review. If you are an IG1 organization with a customer or regulator asking for more, confirm with the requester which Implementation Group and framework mapping they expect before you scope the work.
What can an implementation partner do for the audit, and what can it not do?
An implementation partner can design the register, build discovery and reconciliation, configure the sync from identity systems, prepare review evidence and document the process. DeployOpen prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Only an independent auditor, assessor or certification body can issue those. The organization remains responsible for its controls, for the accuracy of the inventory and for the decisions made in each review. Confirm with your assessor, before work begins, which evidence they will sample, such as the register, review records and removal tickets, so the partner builds to that standard.
Which tools help keep a service account inventory current?
Tooling supports the register but does not replace ownership. Directory services such as FreeIPA (GPL-3.0-or-later) store users, groups and other network objects in one place, which gives you a starting point for finding accounts. Secrets managers such as OpenBao (MPL-2.0) can issue dynamic, short-lived credentials and revoke them automatically, which reduces the number of long-lived service accounts that must be tracked. Pipeline secret detection in GitLab Community Edition (MIT) can flag secrets committed to repositories, which often reveals hidden service credentials. Confirm with each vendor which features your edition and deployment include before you rely on them as evidence.
How DeployOpen prepares the service account inventory
DeployOpen plans, builds and documents the service account inventory that Safeguard 5.5 asks for, inside your own infrastructure, as a fixed-scope engagement. DeployOpen prepares the inventory, its sources and its review records; your organization owns the accounts, the approvals and the quarterly attestations.
How we scope
- We agree in writing which directories, cloud accounts, applications and platforms are in scope for the service account inventory.
- We confirm which service accounts exist, who owns each one, and which systems currently issue or consume their credentials.
- We define the required fields (owning department, purpose, review date) and the quarterly review cadence your team will sign off.
How we build
- We configure the identity sources that already hold service account data, such as directory and identity provider records, so the inventory draws from them rather than from manual lists.
- We set up the inventory records and a review workflow that flags any service account whose review date has passed.
- We test the inventory against a sample of live accounts to confirm completeness and accuracy before handover.
How we hand over
- We deliver the inventory, configuration records, review procedure and a runbook that explains how to add or retire a service account.
- We document how the inventory relates to the prerequisite inventory of authentication and authorization systems referenced in the CIS assessment specification.
- We provide the evidence pack (exports, change records and review logs) that your organization or its independent assessor can examine.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer if your team wants help running the quarterly reviews.
- We can update the inventory when new platforms or service accounts are added, under a written change scope.
- Your organization decides whether an independent assessor or auditor reviews the evidence; DeployOpen does not issue reports or certifications.
