Safeguard 5.1 account inventory: requirements and evidence

What Safeguard 5.1 asks for and why an account inventory is the first control to get right

If an auditor or a customer questionnaire asks for your account inventory, you need one list of every account the enterprise manages, covering user, administrator and service accounts, with at least the person's name, username, start and stop dates and department. Safeguard 5.1 also requires that each active account is validated as authorized at least quarterly. That is the whole ask. The difficulty lies in building the list and keeping it true. CIS places this Safeguard in the Users asset class and the Identify security function, and it appears in all three Implementation Groups, so it is part of IG1 essential cyber hygiene that every enterprise is expected to meet. Start by confirming which systems count as sources of accounts: the primary directory, any second directory, SaaS applications with local logins, cloud consoles, network devices and CI/CD tools.

Orphaned and unknown accounts are the reason this Safeguard matters. An account that belongs to a former employee, a retired contractor or a deleted project is a credential an attacker can use without triggering any review, because nobody is watching it. The inventory is also a dependency for much of the rest of Control 5 and Control 6. The CIS Controls Assessment Specification lists Safeguard 2.1, the software inventory, as a prerequisite because it produces data the measurement needs, and six other Safeguards list 5.1 as a prerequisite, including Safeguards 5.3, 5.4 and 6.3. A weak inventory makes dormant-account checks, administrator separation and access reviews unreliable, so the work done here carries forward.

What usually makes this hard is that accounts are spread across directories, SaaS applications and cloud consoles, and many of them were created outside the directory team's process. Local application accounts, shared service logins and accounts created for vendors often never appear in a central list. Ask your team to produce a count of accounts per system and compare it with the directory's user count before writing any policy. The gap between the two numbers is your first remediation backlog. Where your identity platform supports it, provisioning connectors such as the authentik SCIM provider documentation can push user lifecycle changes to target applications, which reduces the number of accounts that exist outside the authoritative source.

Which accounts and systems fall inside the inventory

Safeguard 5.1 is only as complete as its scope. Each category below changes how many records the inventory holds and how much work the quarterly validation takes, so decide them in writing before the first count.

User, administrator and service accounts

The Safeguard names user, administrator and service accounts as the minimum population. Administrator accounts sit on the same list but carry more risk, so flag them separately in the inventory. Service accounts are often missed because no person logs in to them, yet they still hold credentials. Record at least the person's name, username, start and stop dates and department for each entry. Check that a service account has an owner, because an unowned account cannot be validated as authorized.

Local accounts on enterprise assets

Local accounts on laptops, servers, network devices and appliances are part of the enterprise's account population even when no directory knows about them. Run discovery against each asset class, including built-in and break-glass accounts. Local accounts are the usual gap between a directory-based count and the real total. Ask the asset owner to confirm which local accounts were created by the build process and which were created by people.

SaaS and cloud identities

Accounts in SaaS applications and cloud consoles are enterprise accounts, whether or not they come from the central directory. Accounts created by a business team through an application's own sign-up or invitation flow are the most common blind spot. Include cloud access keys and API tokens that act as identities. Confirm whether each application's account list can be exported, and record where the authoritative list lives.

Third-party and contractor accounts

Accounts held by contractors, consultants, vendors and managed service staff belong in scope when the enterprise manages them. Record the sponsoring employee, the contract end date and the systems each account reaches. These accounts tend to outlive the engagement, so the quarterly validation should confirm each one still has an active business need. Accounts a provider manages entirely inside its own tenant may sit under a service provider review instead, so document that boundary.

Effect on the quarterly review

Every scope decision sets the size of the list that must be validated at least quarterly. A wider scope gives more complete coverage but more accounts to confirm, so automated feeds from the directory and application exports reduce manual effort. The assessment specification scores the Safeguard as failing when no inventory exists or it was last updated more than three months ago, so a stale list fails even if it is complete. Confirm with the assessor how they will sample accounts.

How an assessor tests Safeguard 5.1

This table walks through how an assessor works through Safeguard 5.1 against the CIS Controls Assessment Specification, from confirming that an inventory exists to testing its completeness and accuracy. Read each row as a question the assessor asks, the evidence they expect in response, and where organizations most often fall short.

Test step	What the assessor checks	Evidence expected	Common finding
Confirm the inventory exists	A written account inventory is present and was not missing when the assessment began	The inventory file, export or directory report with its fields visible	No consolidated inventory; accounts exist only across separate directories and applications
Check the update date	The inventory was last updated no more than three months before the assessment	Change history or timestamp showing the last validation	Inventory last refreshed many months earlier, scored as failing
Check the required fields	Each record shows the person's name, username, start and stop dates and department	Sample records with all four required fields populated	Blank stop dates or departments on contractor and leaver records
Cover all account types	User, administrator and service accounts are all in scope of the inventory	Inventory rows tagged by account type, plus the service account list	Service accounts and local administrator accounts missing from the inventory
Sample from directories and applications	Accounts sampled from the directory and from individual applications match the inventory	Directory export and application user lists for the same sample period	Application-local accounts that never reached the directory or the inventory
Test completeness	Every enabled account found in the sample appears in the inventory	Reconciliation between directory exports and inventory rows	Orphaned accounts left behind by former employees or retired projects
Test accuracy	Recorded owners, departments and dates match the source systems and HR records	Spot-check results against HR records and directory attributes	Department values out of date after reorganizations or role changes
Check quarterly validation	Active accounts were confirmed as authorized at least once per quarter, with the reviewer named	Signed or logged review records, with the reviewer and the accounts approved or removed	Reviews done once at setup and never repeated; contractor accounts never reviewed

How to build the account inventory in six steps

This sequence takes you from scattered account stores to one inventory that records every managed account with the minimum fields, classifies each one, reconciles it against HR and software records, and gives someone the job of validating it every quarter.

Identify every account store in scope
Start by listing each place where accounts are created or stored: the central directory, cloud tenant identity services, SaaS applications with local logins, network devices, servers with local accounts, databases and any file or ticketing systems that keep their own user lists. The IT or identity team usually owns this list, with input from application owners. It is done when every store has a named owner and a note on whether it is centralized or local. Ask your assessor which stores they expect to see, because local accounts on devices are the most common gap.
Pull accounts with the minimum fields
Export accounts from each store into one working list. For every account, record at least the person's name, username, start date, stop date and department, as Safeguard 5.1 requires. Where a store does not hold start or stop dates or department, flag those rows rather than guessing. Blank fields are the most common reason an inventory fails measurement, so track how many records are incomplete. The output is a single consolidated file with one row per account and a column showing its source store.
Classify user, administrator and service accounts
Tag every row as a user account, an administrator account or a service account. Administrator accounts are those with elevated rights on any system, and service accounts are those used by applications, scripts or automated jobs rather than a person. Accounts that fit more than one category should be split so each identity has a single classification. Record the owner for each service account now, because the IG2 inventory in Safeguard 5.5 builds on this step. The output is a classified list where every account has exactly one type.
Reconcile against HR and the software inventory
Compare the consolidated list with the HR system of record to confirm that each active person has an account and that each account belongs to someone still employed or contracted. Then compare service and application accounts with the software inventory from Safeguard 2.1, which the assessment specification names as a prerequisite because it typically surfaces applications that hold their own accounts. Unmatched accounts go into an exceptions list with an owner for each. The output is a reconciled inventory and a short exceptions log with a named resolver for every item.
Assign the quarterly validation owner
Name one accountable person for the quarterly validation of active accounts, and a deputy. The owner signs off that each active account is authorized, typically by asking the department head or application owner to confirm the accounts they sponsor. Record who approves the inventory and where it is stored, so the review can be shown later. The assessment specification scores an inventory as failing when it was last updated more than three months ago, so the calendar and reminder should sit with this owner. The output is a documented role, a deputy and a review schedule.
Record the output of each step
Keep a dated record of each step: the list of stores, the export and its field completeness, the classification rules, the reconciliation results and exceptions, and the validation sign-off. Store these in the change or evidence system your auditor will access. This record is what shows the inventory is complete, accurate and maintained, which are the metrics the assessment specification uses. Where tooling such as an identity provider or directory generates reports, keep the report alongside the sign-off rather than replacing the sign-off with it.

Why Safeguard 2.1 and the software inventory come first

The assessment specification lists Safeguard 2.1, the software inventory, as a prerequisite for measuring Safeguard 5.1, because the software inventory typically produces the data the account measurement needs. In practice, an account inventory is hard to complete without knowing which applications, directories, administrative consoles and service integrations exist and which of them hold their own user stores. If the software inventory is incomplete, the account inventory will miss accounts that live inside those applications, and the completeness metric that assessors use will be weak from the start. Plan the software inventory first, or at least in parallel with a defined handoff, so that every application in scope has an owner before anyone starts listing its accounts.

Six other Safeguards list Safeguard 5.1 as a prerequisite, including Safeguards 3.3, 5.3, 5.4 and 6.3. This matters for sequencing because later work depends on the account inventory being accurate. Dormant account handling under Safeguard 5.3 needs a list of accounts to test for inactivity, and administrator separation under Safeguard 5.4 needs a list of who holds privileged rights. Assign one accountable owner for the account inventory, usually in identity or IT operations, and agree in writing which team supplies the application data. Ask your implementation partner or internal team to show which systems were included in the software inventory and which were excluded, with the reason for each exclusion. That record is often the first thing an assessor asks for.

Evidence that passes a Safeguard 5.1 review

An assessor testing Safeguard 5.1 looks for one connected body of evidence: an inventory that exists, is complete and was updated recently, plus proof that someone checked it. The cards below cover the inventory export, the quarterly validation record, the reconciliation to authoritative sources and the change history that keeps the inventory current between reviews.

Dated account inventory export

The core artifact is a dated export listing every account the enterprise manages, with at least the person's name, username, start and stop dates and department, and the account type (user, administrator or service). Assessors check that the export carries a generation date, that it covers every directory and application in scope, and that it is stored in a form that can be reproduced later. An export that is undated or only exists as a spreadsheet edited by hand weakens the entire package. Ask the operator to confirm which systems feed the export before the review starts.

Quarterly validation record

Safeguard 5.1 requires that active accounts be validated as authorized at least quarterly. The validation record should name each reviewer, the date of review, the accounts they confirmed, and the accounts they disabled, changed or escalated. A record that shows only a checkmark on the inventory, with no actions taken, gives an assessor little reason to believe the review occurred. Keep the sign-off tied to a named owner who can explain an unfamiliar account.

Reconciliation to directory and HR records

Completeness is tested by reconciling the inventory against the authoritative sources: the directory, identity provider and application user stores on one side, and HR records for joiners, movers and leavers on the other. Every directory account should appear in the inventory, and every inventory entry should match a live account or a documented retirement. Discrepancies, such as an application login with no matching person, are the findings most likely to fail the metric for accuracy. Record each discrepancy with its resolution date.

Change log between audits

An inventory that is correct on the day of review but stale a month later will not satisfy the expectation that it is kept current. The change log records each account creation, change of department, disablement and deletion, with the date and the approving ticket or request. Identity platforms that push provisioning events to target applications, such as the authentik SCIM provider, can make this log largely automatic, but the organization still needs to confirm that events reached every connected application. Ask the team to show the log for at least one full quarter.

Software inventory as a prerequisite

The CIS assessment specification lists the software inventory in Safeguard 2.1 as a prerequisite for measuring Safeguard 5.1, because applications that hold their own user stores are a common source of accounts missing from a directory-based list. Include the application inventory in the evidence package so the assessor can see which systems were in scope for account collection. A reviewer who finds an application outside the inventory will question the completeness of the whole account list. Confirm that each application with local accounts appears in both inventories.

Open-source platforms that keep the account inventory current

authentik is an identity provider that can act as a SCIM 2.0 client for downstream applications. Its SCIM provider pushes user and group creations, changes and deletions to target applications, so an account added or removed in the source system is reflected in the connected applications without manual steps. For the account inventory, this matters because an application that is updated automatically is far less likely to hold accounts that nobody remembers creating. The provider also runs a full sync every hour and deprovisions users from the target when they lose access to the application, which corrects drift that individual change events may have missed.

Event-driven changes: creations, updates and deletions are pushed to each connected application.
Hourly full sync: a periodic full reconciliation catches differences between authentik and the target.
Deprovisioning on loss of access: users who no longer have access are removed from the target application.
Scope limits: the provider covers only applications that support SCIM and are configured as targets, so local accounts in other systems still need inventory coverage.

Confirm the authentik license (MIT) against the version and edition in your environment, and confirm which target applications support SCIM 2.0 before you plan the inventory around this provider.

What meeting Safeguard 5.1 costs in money and effort

Most of the cost of Safeguard 5.1 is people's time, not software. The first large expense is one-time discovery and reconciliation: someone has to pull account lists from the directory, every SaaS application, cloud consoles, network devices, databases and service accounts, then match each entry to a named person, username, start and stop dates and department. Where those records are missing or inconsistent, the reconciliation takes longer than the extraction. Open-source tools such as the directory services and provisioning platforms named elsewhere on this page can remove license spend, but they do not remove engineering time to configure connectors, map identities and resolve duplicates. Ask any implementation partner to price discovery and reconciliation separately from tooling so you can see where the effort sits.

The recurring cost is the quarterly validation that each active account is still authorized, plus the evidence upkeep that comes with it. Each cycle needs an owner to export the inventory, obtain sign-off from managers or data owners, remove or disable accounts that no longer have a business reason, and keep the signed records with the dated inventory, because the assessment specification fails the Safeguard when the inventory is more than three months old. Auditors and assessors usually test by sampling accounts and tracing them back to approvals and HR or contractor records, so the sample size and the number of populations they choose will change how much evidence you must hand over. Confirm with your assessor how they will sample before you design the review workflow.

Several factors push cost up: the number of separate account stores, SaaS sprawl where teams sign up for tools outside central procurement, and contractor churn, which creates accounts with short lifecycles and unclear sponsors. Each additional store multiplies reconciliation work, and each departing contractor adds a stop-date record that must be captured on time. Costs fall when the enterprise routes identity through one directory or identity provider, when joiner, mover and leaver events drive account creation and removal automatically, and when account owners are named in the inventory from day one. When you request a quote, ask for the effort split between discovery, reconciliation, quarterly cycles and assessor support, and ask which items recur every year and which are one-time.

Where account inventories usually fail

Most account inventories fail in predictable places: the accounts nobody lists, the spreadsheets nobody refreshes, and the records nobody can tie back to people. Each gap below weakens the evidence an assessor uses to score Safeguard 5.1, so each card ends with the action that closes it.

Service accounts left out

Service accounts often run scheduled jobs, integrations and database connections, and they rarely appear in a list built from staff directories. Safeguard 5.1 names service accounts explicitly, so an inventory that covers only people fails on scope before anyone checks its contents. Action: query every directory, database, cloud IAM and application for non-human principals, then add each one with an owner and purpose.

Inventory older than three months

The CIS Controls Assessment Specification scores Safeguard 5.1 as failing when the inventory was last updated more than three months ago. A workbook that was accurate at the last audit can fail the next assessment without a single account changing. Action: set a recurring calendar entry for the quarterly review and record the date of each update in the inventory itself.

No owner for validation

The quarterly check that each active account is authorized needs a named person who is accountable for completing it. When the inventory belongs to everyone, it is updated by no one, and the reviewer cannot show who approved an account's continued access. Action: assign one accountable owner for the inventory and a named approver for each department's accounts, and keep the sign-off record.

Shadow SaaS accounts

Teams sign up for SaaS tools with work email addresses, and those accounts sit outside the directory and outside the inventory. Because no identity system creates or removes them, they outlive the employee who opened them. Action: review SSO logs, expense records and OAuth consent grants to find SaaS accounts, then bring each one into the inventory or disable it.

Accounts that do not reconcile to HR

The minimum fields for each account include the person's name, username, start and stop dates and department. If the inventory cannot be matched to the HR system of record, leavers and transfers go unnoticed and the stop date stays blank. Action: reconcile the inventory against HR records each quarter, and list every account that has no matching person as an exception with an owner.

Who owns the inventory, who can help, and where the auditor stops

The organization owns Safeguard 5.1. It must decide what counts as an account, name an accountable owner for the inventory, and run the quarterly validation that confirms each active account is still authorized. No partner or tool can make those decisions on the organization's behalf. The Safeguard asks for records of every account the enterprise manages, including user, administrator and service accounts, with at least the person's name, username, start and stop dates and department. Someone inside the business must be able to say why each account exists and who approved it.

Accountable owner: Assign a named role, such as the head of identity or IT operations, and give it authority to require account owners to respond.
Scope decision: Write down which systems, directories and cloud tenants feed the inventory, and who is responsible for each source.
Quarterly validation: Record who reviewed each active account, the date, the decision (keep, change or disable) and the follow-up.
Change records: Keep a dated trail for joiners, movers and leavers so the start and stop dates can be proven.
Policy alignment: Tie the inventory process to the written access and account management policy the organization already runs.

Before relying on this tab, confirm that the inventory has a named owner and that the last validation cycle produced signed or recorded decisions.

Questions buyers ask about the Safeguard 5.1 account inventory

Can we build the Safeguard 5.1 account inventory in-house?

Yes, most organizations can build the inventory themselves, provided someone owns the list and can pull account data from every system that issues logins. The inventory has to cover user, administrator and service accounts, and each record needs at least the person's name, username, start and stop dates and department. The hard part is rarely the spreadsheet. It is finding every place an account exists, including directories, cloud consoles, SaaS applications, databases and network devices. Bring in outside help when the account sources are scattered across many platforms or when no one has authority to close unknown accounts. Confirm with your own team who owns each source before you start.

How much effort does the initial account inventory take, and what drives it?

No researched figure is available for effort, so treat any number a vendor gives you as an estimate to test. The main drivers are the number of account sources, how many accounts are orphaned or undocumented, whether accounts already flow through a central directory, and how many owners must confirm each entry. An organization with one identity provider and clean HR records will finish far sooner than one with local accounts on hundreds of hosts. Ask any partner for a written scope that lists the systems in scope, the data fields collected and the owners who must sign off.

What does the quarterly validation of active accounts require?

The quarterly validation requires that each active account in the inventory is confirmed as authorized by a named owner, and that the inventory itself is current. The CIS Controls Assessment Specification fails Safeguard 5.1 when no inventory exists or when it was last updated more than three months ago, so the review cadence matters. A workable routine has a dated review record, an owner sign-off for each account, a list of accounts removed or changed, and a log of who approved each decision. Confirm the exact review scope and owner roles with your internal audit or compliance lead before you set the schedule.

Can open-source tools produce the evidence for Safeguard 5.1?

Open-source tools can produce much of the evidence, mainly by making the directory the source of truth and recording reviews. FreeIPA uses 389 Directory Server as a multi-master LDAPv3 directory that stores users, groups and hosts, with centralized access control and delegated administration. authentik's SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0 and runs a full sync every hour, which helps keep downstream applications aligned with the inventory. midPoint access certification campaigns let designated reviewers keep, change or revoke access within a set timeframe, which produces a review record. Confirm each tool's fit against your own account sources, because no single tool covers every system.

Does Safeguard 5.1 depend on other Safeguards?

Yes, the inventory works best alongside the software inventory. The CIS Controls Assessment Specification lists Safeguard 2.1, the software inventory, as a prerequisite for measuring Safeguard 5.1 because it typically produces data the measurement needs. Six other Safeguards list Safeguard 5.1 as a prerequisite, including Safeguards 3.3, 5.3, 5.4 and 6.3, so gaps here affect later work. Plan the account inventory with the asset and software inventories in mind, and confirm the dependency mapping against the current assessment specification before relying on it.

What does a partner need from our team to start?

A partner needs named owners, read access to account sources and a decision on who approves account removals. Under a fixed-scope engagement, scope, deliverables and timelines are agreed in writing before work starts, so your team should provide a list of systems that issue accounts, the HR or joiner-mover-leaver data source, and the people who will sign quarterly reviews. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue audit reports or certifications, and your independent auditor or certification body makes that determination. Ask any partner to confirm in writing what it will and will not deliver.

Who is responsible for the account inventory after the project ends?

Your organization remains responsible for the account inventory and its quarterly validation after any implementation project ends, because it owns its controls. An implementation partner can set up the process, sources and evidence trail, and ongoing support, upgrades and testing are available as retainers. Decide before the handover who will run each quarterly review, who maintains the directory connectors and who records exceptions. Confirm these responsibilities in the written scope so the review cycle does not lapse after the first cycle.

How DeployOpen prepares the Safeguard 5.1 inventory

DeployOpen starts Safeguard 5.1 work by agreeing in writing which account sources fall inside scope. For most enterprises that list includes the directory that holds user identities, the identity provider that federates them into business applications, administrator accounts on servers and network devices, cloud tenant accounts, and the service accounts that scripts and integrations use. Each source is recorded with its owner, its system of record and the fields it can supply, so the inventory has a defined boundary before any data is pulled. The client decides the boundary, and DeployOpen documents it in the fixed-scope agreement so the client and its independent assessor can see exactly what the inventory claims to cover.

Where the client's estate calls for it, DeployOpen integrates self-hosted open-source identity tools inside the client's own infrastructure. Depending on the design, that can mean FreeIPA with 389 Directory Server as the central store for users and groups, authentik's SCIM provider pushing account changes to target applications and removing access when a user loses it, and midPoint access certification campaigns that give named reviewers a set period to keep, change or revoke access. The deliverables are configured connectors, a sync or export job that writes the account fields the Safeguard requires (name, username, start and stop dates and department), and a documented review routine. Confirm with the vendor and your own environment which connectors and sync behaviors apply to your versions before committing to a design.

The evidence DeployOpen prepares is the account inventory itself, a record of each quarterly validation showing that every active account was confirmed as authorized by its owner, and the change history that shows when accounts were added or removed. Assessors measure the inventory against the CIS Controls Assessment Specification for completeness and accuracy and check that it was updated within the window the specification sets, so the validation calendar matters as much as the first export. DeployOpen prepares this evidence; it does not issue assessments, and the organization owns the control. The independent auditor or assessor the organization engages decides whether the evidence meets the Safeguard, and that decision is the one that counts for any report or certificate.

Safeguard 5.1 Establish and maintain an inventory of accounts