Service Account Audit Checklist: Template, Evidence and Review Steps

A service account audit checklist should verify the account's owner, business purpose, effective permissions, authentication method, activity, dependencies and final disposition. It should also produce evidence that an authorized reviewer actually made a decision, because an audit isn't finished until someone's signed off. An export of account names isn't an audit. It's a starting population.

This guide gives IT leads a working checklist, a copyable audit register, a reviewer decision matrix and a closure procedure for Active Directory, Microsoft Entra, AWS and Google Cloud. You can use it for a quarterly control review or a targeted cleanup after a team or application changes. It won't require a new platform before you can begin.

The complete service account audit checklist

Use this checklist as a review worksheet, not a generic security questionnaire. It's meant to be marked up. Each item needs an owner, a source of evidence and a disposition. Marking an item complete without evidence just moves the uncertainty to the next audit.

An audit can be narrow if a system is under investigation, but its scope must be explicit. If you review only the Microsoft tenant, don't imply that the resulting evidence covers on-premises scheduled tasks or SaaS API users. The control owner should sign off on the population definition before sampling begins.

Copyable service account audit register template

The register below is designed for a spreadsheet, CMDB export or ticketing system. Copy the header row into your preferred tool. Don't put the credential itself in the spreadsheet: store a vault reference or key identifier, never a secret value.

Account or object ID	Source system	Workload	Business approver	Technical custodian	Effective access	Credential reference	Last observed activity	Review decision	Evidence link
svc-orders-sync (example)	Active Directory	Sends approved orders to ERP	Operations lead	Integration team	Database read, ERP write	Vault record ORDERS-SYNC	Confirm from logs	Pending owner approval	Export and change ticket
app-billing-reports (example)	Microsoft Entra	Produces billing reports	Finance lead	Cloud platform team	Read-only reporting grant	Certificate ID only	Confirm from sign-in logs	Review privileges	Grant export and ticket
ci-build-role (example)	AWS IAM	Runs deployment workflow	Engineering lead	DevOps team	Scoped deployment policy	Role, no stored key	Confirm from logs	Retain with review	Role policy and approval

The three rows above are illustrative records, not evidence of real systems. The final register should use immutable identifiers alongside display names because names can be reused or changed. Include an extraction timestamp and the person or automation that generated each source export. A reviewer should be able to reproduce the population later.

Required versus useful fields

CIS Controls Safeguard 5.5 explicitly calls for a service account inventory with a department owner, review date and purpose, and for reviews of active-account authorization at least quarterly. That's a minimum inventory requirement, not a complete risk assessment, and it's easy to mistake one for the other. See the CIS Controls assessment specification for the safeguard and its assessment inputs.

If you still need to build the inventory itself, start with our service account inventory template. Then add a stable identifier, named approver, technical custodian, workload, environment, effective entitlements, credential reference, last observed use, exception reason and evidence link. Those extra fields make decisions actionable, and they're cheap to collect. A team name may satisfy the department field but can't, by itself, explain why an integration still needs broad access.

CSV header to paste:

object_id,identity_type,source_system,environment,workload,purpose,department_owner,business_approver,technical_custodian,backup_contact,effective_permissions,credential_type,vault_reference,last_observed_use,telemetry_coverage,review_date,decision,risk_reason,remediation_ticket,evidence_location,verified_final_state

Don't paste passwords, private keys, refresh tokens or client secrets into this file. A safe evidence record points to protected systems without duplicating sensitive credentials.

How to run the audit from discovery to closure

A service account audit works best as a sequence of decisions rather than a one-time export. Separate discovery, authorization and remediation. The person who knows a workload is business-critical isn't always the person who understands its effective permissions, and that's why you split the questions.

1. Define the population and evidence period

   List directories, tenants, cloud accounts, clusters, SaaS integrations and local services. Name the accountable audit owner and document exclusions. Save the extraction method and timestamp.

2. Reconcile the inventory

   Compare current identities against the register. Flag unknown identities, duplicates, missing owners and accounts that the register claims were retired. Preserve the original export before editing the register.

3. Review actual authorization

   Give the business owner the purpose and dependency question. Give the technical reviewer the permission, credential and activity question. Record their decisions separately when the roles differ.

4. Prioritize findings and change safely

   Route suspected compromise to incident response. For ordinary cleanup, identify dependencies, schedule a change window and prepare a rollback. Don't disable a production identity on inactivity alone.

5. Verify and close

   After an approved change, take a fresh entitlement or account-state export. Attach it to the ticket and record who verified that the workload still works or that the retired access is gone.

Discovery: where service identities hide

Active Directory and Windows. Review conventional domain users running services, scheduled tasks, IIS application pools, group managed service accounts and local service identities. Windows gMSAs have managed passwords, but that doesn't make their privileges or host authorization automatically appropriate. Microsoft describes gMSAs as accounts with automatic password management and simplified service principal name administration. The audit still needs the owning service, the hosts it's allowed to run on and a privilege review.

Microsoft Entra. Inventory enterprise applications, app registrations, service principals and managed identities. Check application permissions, consent grants, directory roles and Azure resource assignments where they're in use. Microsoft's service principal sign-in logs cover nonuser sign-ins by applications and service principals; managed identity sign-ins appear in their own log category. If your tenant's retention doesn't cover the audit period, record the telemetry gap rather than calling the identity inactive.

AWS. Inventory IAM users with long-lived keys, IAM roles used by workloads, cross-account trusts and service roles. IAM Access Analyzer can identify unused roles, IAM user credentials and permissions in its unused-access analyzer. Its findings aren't a complete list of every service identity: service-linked roles aren't analyzed for unused access, so supplement the tool with direct inventory and workload-owner review.

Google Cloud. Enumerate user-managed service accounts by project, inspect role bindings and list user-managed keys. Google Cloud documents a service account key listing method specifically useful for audits. A key listing isn't proof that a key is still used, and a missing key doesn't mean the account lacks other authentication paths. Check workload identity federation and impersonation permissions separately.

SaaS, databases and CI/CD. Find integration users, API principals, deployment bots, database service users and pipeline credentials that aren't represented in the central identity provider. Ask application owners to enumerate locally configured automation. If the SaaS vendor's logs are incomplete, record what can and cannot be verified.

Reconciliation: prove your inventory covers the sources

Treat every export as a population with its own identifier namespace. Match by platform plus immutable ID, not by display name alone. Track identities found in a source but absent from the register, records with no live object and duplicates that might represent the same workload under different names.

For each mismatch, assign a triage owner. An undocumented account should be investigated, not automatically deleted. A record marked retired while its credential still authenticates is a different finding from an account that was disabled but remains in a historical register. Make the distinction visible in the findings log.

Authorization: ask the owner for a decision

Send the reviewer enough context to make a meaningful choice: workload name, purpose, affected systems, effective access, recent activity, current owner and the consequence of disabling it. Ask for a clear decision: retain as-is, retain with restrictions, investigate or retire. Don't accept a blanket "all good" for an entire group when individual privileges differ.

The business approver confirms whether the workload still matters. They aren't judging the permissions. The technical custodian confirms that the credential and entitlements support that workload. That's a separate call. Security or IAM can challenge exceptions, and they should. Where no owner exists, mark the identity unowned and escalate. Don't let the same missing field roll into another quarter.

Permissions and credentials: what to test

Account existence is only the first question. A valid service account can still have privileges far beyond its purpose, a credential stored in an unsafe location or access that can't be traced to one workload. The checks below help you tell those cases apart.

Audit test	Evidence to request	Finding if the test fails	Typical next action
Effective privileges	Role assignments, group expansion, resource policies	More access than documented	Reduce scope with owner sign-off
Credential handling	Vault reference, certificate or key metadata	Unowned or unmanaged credential	Assign custodian and plan replacement
Shared use	Workload map, logs and deployment configuration	Several workloads use one identity	Plan separate identities where feasible
Activity	Authentication and application logs	No observed use or anomalous use	Investigate with workload owner
Decommissioning	Change record, disabled state and dependency check	Retired workload retains active access	Disable through controlled change
Attestation	Reviewer identity, decision and date	Approval can't be reconstructed	Re-run review with evidence

Review effective permissions, not just role names

A role name like "reader" can hide inherited access, while a custom role may include an action the workload doesn't need. Trace direct assignments, group membership, resource policies and delegation or impersonation paths. For identities with administrative reach, the privileged access management software guide covers tools that vault and monitor those credentials. Review what the identity can reach, not only what its primary job calls for.

For a reporting job, compare the data sources it is expected to read with the databases and storage resources it can actually access. For a deployment identity, distinguish the environments it must change from environments it can merely see. If a privilege can't be justified, propose a narrower grant and test it before rollout.

Review credentials without exposing them

Record whether authentication uses a managed identity, workload federation, role assumption, certificate, managed password or long-lived secret. Record the expiry and rotation owner only where those concepts apply. A managed identity doesn't have a human-maintained password, but its permissions and deployment attachment still need review. They're easy to overlook for that reason.

Google Cloud recommends considering workload identity federation rather than service account keys for workloads outside Google Cloud. Microsoft describes gMSAs as using managed passwords. Those approaches reduce manual secret handling, but they don't replace an owner attestation or a privilege check.

Audit decisions and a practical risk queue

Use a small decision vocabulary that keeps downstream tickets unambiguous. It's what lets a ticket say what happens next. A spreadsheet cell that says "reviewed" tells nobody what should happen next, and that's how findings go stale. A decision must identify the approver, the scope of approval and any work that's still outstanding.

Decision	Meaning	Required evidence	Closure rule
Retain	Purpose and access confirmed	Owner approval plus entitlement snapshot	Review date and evidence recorded
Restrict	Workload needed, access too broad	Owner approval plus target permissions	Post-change entitlement check
Investigate	Ownership, activity or purpose unclear	Named investigator and evidence request	Decision revisited after investigation
Retire	Workload no longer authorized	Business approval and dependency assessment	Disable or remove, then verify
Escalate	Suspected abuse or material exposure	Security incident reference	Incident-response process controls next steps

Prioritize by impact and uncertainty. A privileged, externally reachable automation identity with no owner deserves faster investigation than a narrowly scoped identity with a confirmed owner and current evidence. But don't substitute a numeric risk score for the actual dependency review. Scores help sort a queue; they don't authorize production changes, and they're no substitute for talking to the owner.

The safe retirement sequence

Start with a dependency map: scheduled jobs, services, applications, integrations, hosts and recovery procedures that use the identity. Obtain a business decision and a change window. If the platform permits a reversible disablement, use that to test impact before permanent removal when appropriate.

Google Cloud's service account guidance recommends disabling an account before deleting it when usage is uncertain. That distinction matters because deleting a service account and recreating one with the same name creates a different identity. For an account with suspected compromise, follow the incident-response playbook instead of waiting for an ordinary maintenance window.

After the change, verify both sides: the identity no longer authenticates where access was removed, and the authorized workload still functions where it should. Attach fresh evidence, not just the engineer's note that the command completed. A rollback must have an owner and an expiration condition.

What evidence should an auditor receive?

An audit package should let a reviewer trace a selected identity from discovery to decision to verified state. It should also show how the population was built. A polished spreadsheet without original exports won't prove that nothing was left out.

Population evidence: source system list, export timestamp, query or extraction procedure, immutable identifiers and reconciliation results. Keep excluded systems and the reason for exclusion visible; they're part of the story.

Authorization evidence: business purpose, approver, technical custodian, effective permission snapshot and signed or logged decision. For exceptions, include the business justification, risk owner and next review date.

Remediation evidence: ticket, change approval, dependency assessment, implementation timestamp, post-change entitlement export and verification result. If a planned change was deferred, show the accepted exception rather than quietly closing the finding.

Control-operation evidence: the review campaign owner, the list of accounts assigned to each reviewer, outstanding decisions, completion timestamp and a record of follow-up. These elements show the review was actually run, not merely designed.

A compact folder structure can work: population/, reviews/, findings/, changes/ and closure/. Restrict access, because even an export without secrets can reveal sensitive infrastructure relationships. The retention period should come from your organization's policy and audit requirements. It shouldn't come from a universal number in a blog post.

Which standards should the checklist support?

CIS Safeguard 5.5 is especially direct about service account inventory and recurring authorization reviews. Its assessment specification identifies the department owner, review date and purpose as minimum fields. The same CIS page also explains how an assessor can compare the recorded inventory with enumerated service accounts.

NIST SP 800-53's AC-2 account management control addresses account managers, access authorization, account monitoring and review at an organization-defined frequency. Don't confuse that with a universal NIST requirement to audit service accounts quarterly. It isn't one. The quarterly cadence stated here comes from CIS Safeguard 5.5. Your regulator, contract or internal policy may demand a different scope or schedule.

For a security control mapping, attach the exact framework edition and your organization's applicability decision. A checklist can support evidence collection, but it can't certify compliance by itself. If an auditor asks for proof of implementation, they'll care more about the review decisions and verified account state than a control number in a heading.

How often should service accounts be audited?

For organizations using CIS Safeguard 5.5, at least quarterly is the stated baseline for reviewing whether active service accounts are authorized. More frequent review is appropriate when the account is privileged, business-critical, externally exposed or involved in an incident. The faster schedule is a risk-based recommendation, not a separate blanket mandate from CIS.

Make reviews event-driven as well; a schedule alone won't catch every change. An application retirement, vendor offboarding, business owner departure, unexpected credential addition or major permission change should trigger a targeted check. That prevents a long gap between a material change and the next scheduled attestation. You don't want a year-old approval covering a workload that's since changed.

The practical test of cadence isn't the calendar invite. It's whether the owner completed a decision, whether exceptions received tickets and whether the team can show the resulting access state. If those aren't visible, increasing the frequency won't fix the underlying workflow.

Where a lightweight ownership workflow fits

A service account ownership review workflow can help track which account has a nominated owner, which attestation is pending and which decisions need evidence. That's a narrower job than credential rotation, directory discovery or privilege enforcement. It should sit beside those systems, not replace them.

For teams starting with a CSV export, the first useful improvement is often a clear owner nomination and a durable review trail. Don't treat an ownership workflow as proof that an identity's effective permissions have been checked unless the supporting exports and technical review are attached.

Service account audit checklist FAQ

Final takeaway

A reliable service account audit isn't a list of identities with a checkmark. It's a repeatable way to reconcile the population, assign accountability, inspect access, make decisions and prove that risky access was handled. Start with the register and checklist above. Then make the review evidence easy for the next IT lead to reproduce, so they're never guessing who approved what.