Safeguard 5.5: Establish and Maintain an Inventory of Service Accounts

Safeguard 5.5 requires you to create and keep current a complete inventory of service accounts, including where they exist, what they can access, who owns them, and why they exist. To operationalize it quickly, define what “service account” means in your environment, discover them across platforms, record required attributes, and run a recurring review that catches new or orphaned accounts. (CIS Controls v8)

Key takeaways:

• A service account inventory is a control, not a spreadsheet; it needs defined scope, ownership, and a recurring update mechanism. (CIS Controls v8)
• The fastest path is: define → discover → normalize → approve/attest → monitor and reconcile. (CIS Controls v8)
• Evidence matters as much as design; keep snapshots, change logs, and review sign-offs tied to the inventory. (CIS Controls v8)

Service accounts are one of the most common “quiet” pathways to material access: they run jobs, integrate systems, and keep production services alive. They also tend to be shared, poorly documented, and exempted from normal user lifecycle controls. Safeguard 5.5: establish and maintain an inventory of service accounts requirement exists to remove that ambiguity by forcing an accountable list: what service accounts exist, where they are, what they can do, and who is responsible for them. (CIS Controls v8)

For a CCO or GRC lead, the operational challenge is that service accounts span identity platforms (AD/Entra ID), cloud IAM roles and service principals, databases, CI/CD systems, endpoints, network devices, and third-party SaaS. Teams also disagree on definitions (service accounts vs. shared admin vs. app identities), which causes inventory gaps and audit friction.

This page gives requirement-level implementation guidance you can hand to IAM, IT Ops, Security Engineering, and application owners. The emphasis is on fast scoping, repeatable discovery, minimum required data fields, durable evidence, and the exam questions you will get when an assessor tests whether your inventory is complete and maintained. (CIS Controls v8)

Requirement summary (Safeguard 5.5)

Goal: Maintain an authoritative, current inventory of service accounts so you can control, review, and retire them on purpose rather than by accident. (CIS Controls v8)

Working definition (use for policy and scoping): A service account is a non-human identity used by an application, workload, integration, or automated process to authenticate and perform actions in systems. Include local accounts used by services, cloud service principals, IAM roles for workloads, and database/application “run-as” identities where authentication occurs. (CIS Controls v8)

Regulatory text

Framework excerpt: “CIS Controls v8 safeguard 5.5 implementation expectation (Establish and Maintain an Inventory of Service Accounts).” (CIS Controls v8)

Operator interpretation: You must (1) identify service accounts across your environment, (2) document them in a maintained inventory, and (3) operate a process that keeps the inventory accurate over time as systems change. The control fails if the inventory is incomplete, stale, lacks ownership, or cannot be shown as “maintained” through recurring evidence. (CIS Controls v8)

Primary sources: CIS Controls v8 and CIS Controls Navigator v8. (CIS Controls v8) (CIS Controls Navigator v8)

Who it applies to (entity + operational context)

Entity types: Enterprises and technology organizations adopting CIS Controls v8 for security governance, customer assurance, or internal risk management. (CIS Controls v8)

Operational contexts where 5.5 becomes urgent:

• Hybrid identity: AD plus cloud identity, where service accounts exist in both directories and drift occurs.
• Cloud-native stacks: Workloads use service principals/roles; ownership is often unclear.
• CI/CD and automation: Build agents, deployment bots, and pipeline secrets create high-impact identities.
• Third-party integrations: SaaS connectors and API clients act like service accounts and need inventory treatment even when created in a third party’s console.

Plain-English interpretation (what “good” looks like)

A “good” implementation means you can answer these questions quickly and consistently:

1. What service accounts exist right now? (complete list, not “best effort”) (CIS Controls v8)
2. What do they access and with what privileges? (system scope + entitlements) (CIS Controls v8)
3. Who owns each one and what business service depends on it? (accountability) (CIS Controls v8)
4. How do you know the list stays current? (recurring discovery and reconciliation evidence) (CIS Controls v8)

If you can’t prove “maintained,” auditors will treat the inventory as a point-in-time artifact and push on completeness.

What you actually need to do (step-by-step)

1) Set scope and definitions (make it testable)

Deliverables:

• Standard definition of service account, plus boundary cases: shared admin accounts, break-glass accounts, app/API tokens, SaaS integration identities. (CIS Controls v8)
• System scope list for where service accounts may exist: directory services, cloud IAM, OS local accounts, databases, Kubernetes, CI/CD, ITSM tools, network devices, SaaS admin portals. (CIS Controls v8)

Practical decision rule: if an identity authenticates non-interactively or is used by automation, treat it as in-scope until explicitly excluded with rationale.

2) Establish inventory data fields (minimum viable, audit-ready)

Create an inventory schema and don’t let it sprawl. Start with required fields you can populate reliably:

Field	Why auditors care
Unique identifier (name + system)	Prevents duplicates and “same name, different place” confusion
Platform/system of record	Shows where it lives and who administers it
Account type (service account, service principal, IAM role, local svc)	Enables consistent control testing
Owning team + accountable owner	Enables approvals, reviews, and clean termination
Business purpose / service dependency	Justifies existence; supports risk acceptance if high privilege
Privilege level / roles / groups	Drives risk rating and review depth
Authentication method (keys/certs/password/managed identity)	Ties to secret management and rotation controls
Creation date + last used (if available)	Detects dormant/orphaned accounts
Review status + last review evidence link	Proves “maintained”

3) Discover service accounts across platforms (build completeness)

Use multiple discovery methods because no single system sees everything:

• Directory/IAM exports: AD/Entra ID service accounts, non-interactive users, service principals, workload identities.
• Cloud IAM: roles attached to workloads, cross-account roles, automation roles.
• Endpoint and server scans: local users running services, scheduled tasks, daemons.
• CI/CD systems: build users, deploy bots, PATs tied to automation.
• Database/application inventories: DB users used by apps, middleware service credentials.
• Third-party SaaS: integration users, API clients, connector identities.

Operational tip: run discovery first, then negotiate exclusions. Starting with exclusions guarantees gaps.

4) Normalize and de-duplicate (turn findings into one list)

You need one “authoritative” inventory view, even if the source data lives in multiple systems.

Actions:

• Map each discovered identity to the inventory schema.
• Merge duplicates (same identity referenced across tools).
• Tag unclear identities as “unconfirmed” with an owner assignment and due date in your workflow tool.

5) Assign ownership and require attestation

Every account needs an accountable owner (person) and an owning team (function). If ownership can’t be assigned, treat it as an issue and drive remediation.

Attestation workflow:

• App/platform owners confirm: purpose, privilege, dependency, and whether the account is still required.
• Security/IAM confirms: correct classification and baseline controls (for example, no interactive login if not required).

6) Define “maintain” as an operating cadence and trigger events

CIS expects maintenance, so define it in control language that an auditor can test. (CIS Controls v8)

Recommended operating model:

• Event-driven updates: creation, privilege change, key rotation, ownership change, decommissioning.
• Recurring reconciliation: compare inventory to system exports; investigate deltas; record outcomes.
• Exception handling: documented risk acceptance for accounts that must remain high privilege, legacy auth methods, or third-party constraints.

7) Monitor for drift and orphaned accounts

Minimum controls to keep the inventory honest:

• Alerts or reports for newly created service accounts and privilege escalations.
• A queue for “no owner,” “no purpose,” and “dormant” accounts.
• Retirement process: disable → validate dependent services → remove credentials → delete (where safe).

8) Map the requirement to control operation and evidence capture

CIS 5.5 commonly fails on evidence, not intent. Build evidence capture into the process so it happens by default. Recommended control: “Map 5.5 to documented control operation and recurring evidence capture.” (CIS Controls v8) (CIS Controls Navigator v8)

Daydream fit (earned mention): If you struggle to keep ownership, attestations, and recurring evidence organized, Daydream can track the control, schedule evidence requests, and keep a clean audit trail linked to each inventory snapshot.

Required evidence and artifacts to retain

Keep artifacts that prove both existence and maintenance:

• Service account inventory export (current snapshot) with required fields. (CIS Controls v8)
• Discovery inputs (system exports, scripts output, SaaS admin reports) used to build the inventory. (CIS Controls v8)
• Reconciliation records showing deltas identified and resolved (tickets, change records, approvals). (CIS Controls v8)
• Ownership attestations (sign-offs, workflow approvals) tied to specific accounts or batches. (CIS Controls v8)
• Exception register for out-of-standard accounts, with rationale and compensating controls. (CIS Controls v8)
• Change history for the inventory (who changed what, when, and why). (CIS Controls v8)

Common exam/audit questions and hangups

Assessors tend to test 5.5 by sampling systems and asking you to prove completeness and upkeep.

Typical questions:

• “Show me all service accounts for this critical application and where they are recorded.” (CIS Controls v8)
• “How do you detect new service accounts created outside the standard request process?” (CIS Controls v8)
• “Pick three service accounts. Who owns them, and when were they last reviewed?” (CIS Controls v8)
• “How do you know this inventory is complete for cloud roles and service principals?” (CIS Controls v8)
• “What happens when the owner leaves the company?” (CIS Controls v8)

Hangups that cause findings:

• Inventory exists but lacks owners, privileges, or business purpose.
• Inventory is accurate only for AD, not cloud IAM, SaaS, or databases.
• No evidence of reconciliation or review; only a static spreadsheet.

Frequent implementation mistakes (and how to avoid them)

1. Treating service accounts as “IT-only”
   Fix: require application owner attestation for purpose and dependency. (CIS Controls v8)

2. Letting the inventory become a dumping ground
   Fix: enforce minimum required fields; route incomplete records to remediation workflow.

3. Ignoring third-party and SaaS identities
   Fix: include SaaS integrations/API clients in scope; record the third party system as the platform of record.

4. No operating trigger for updates
   Fix: tie inventory updates to change management and IAM requests; add event-driven and recurring reconciliation.

5. “We have a list” with no evidence trail
   Fix: store snapshots, approvals, and reconciliation results in a system that preserves history (ticketing, GRC, or Daydream). (CIS Controls v8)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this safeguard. (CIS Controls v8)
Risk-wise, unmanaged service accounts create high-impact access paths: orphaned credentials, excessive privileges, and hard-to-trace automation actions. From a governance standpoint, the most common audit risk is inability to demonstrate that the inventory is maintained through routine operation and evidence.

Practical 30/60/90-day execution plan

Day 0–30: Stand up the minimum viable inventory

• Publish the service account definition and scope list. (CIS Controls v8)
• Agree on required inventory fields and where the inventory will live.
• Run discovery on highest-risk platforms first (directory/IAM, cloud IAM, CI/CD).
• Create initial inventory snapshot and tag “unknown owner/purpose” items for follow-up.

Day 31–60: Establish ownership, reviews, and reconciliation

• Assign owners and owning teams for all in-scope accounts.
• Launch an attestation cycle for critical systems and high-privilege accounts.
• Implement delta reporting: new accounts, privilege changes, and accounts with missing fields.
• Document the operating procedure and evidence capture steps. (CIS Controls v8)

Day 61–90: Prove “maintained” and reduce drift

• Run your first full reconciliation cycle and close exceptions with tickets and approvals.
• Integrate inventory updates into joiner/mover/leaver and change management workflows.
• Define retirement criteria and start decommissioning unneeded service accounts.
• Package evidence: inventory snapshots, reconciliation outputs, and attestation records for audit readiness. (CIS Controls v8)

Frequently Asked Questions

What counts as a “service account” in cloud environments?

Include service principals, workload identities, and IAM roles used by automation or applications to authenticate and act in systems. Record them in the same inventory with platform, owner, purpose, and privileges. (CIS Controls v8)

Do we need one tool, or can the inventory be a spreadsheet?

A spreadsheet can work for a small environment, but auditors will still expect proof it is maintained with version history, approvals, and reconciliation evidence. If you cannot preserve an audit trail in a spreadsheet, move the inventory to a system that can. (CIS Controls v8)

How do we handle service accounts owned by third parties or managed services?

Keep them in your inventory with the third party named as the operating party and an internal accountable owner for oversight. Track purpose, access, and how you request changes or termination from the third party. (CIS Controls v8)

What if we cannot determine the owner for legacy service accounts?

Treat “no owner” as a remediation item with a defined workflow: assign investigation, validate dependencies, and either establish ownership with attestation or retire the account. Document the outcome and keep the ticket as evidence. (CIS Controls v8)

How do we prove the inventory is “maintained”?

Keep dated inventory snapshots plus records showing you reconciled the inventory against source systems and resolved differences. Attestation sign-offs and change tickets linked to inventory updates are strong evidence. (CIS Controls v8)

Can we exclude certain account types from scope?

You can, but write the exclusion criteria down and document why the excluded identities do not function as service accounts in your environment. Exclusions without rationale often become audit findings during sampling. (CIS Controls v8)