Should organisations include service accounts in ISO 27001 access reviews?

Why Service Accounts Belong in Access Reviews

Service accounts are not administrative edge cases, they are access-bearing identities with real permissions, trust relationships, and credential paths. In an iso 27001 programme, the review question is whether access is current, necessary, and appropriately authorised, which means excluding service accounts creates blind spots in the identity estate and weakens the control’s completeness. That includes accounts used by applications, batch jobs, integrations, and automation.

When organisations treat access reviews as a people-only exercise, they often miss accounts that service account security depends on: shared credentials, non-expiring passwords, or highly privileged integrations that nobody actively owns. A review that excludes these identities can pass on paper while leaving the highest-risk access untouched.

ISO 27001 is framework-based, not user-based. The practical reading is that any identity that can authenticate, inherit privilege, or touch information assets should be in scope for periodic review, including service accounts that support production systems, cloud workloads, or third-party interfaces. Where the account’s purpose is unclear, the review should surface ownership and business justification before access is renewed.

What a Complete Review Needs to Check

A useful service-account review is not just “does this account exist?”, but “what does it do, who owns it, and what would break if it were removed?” For accounts used by applications or automation, the reviewer should confirm the business function, the technical owner, the systems it reaches, and whether the privileges still match the minimum necessary access. That is especially important for accounts that can reach multiple environments or sensitive data stores.

Where accounts are long-lived or difficult to rotate, review findings should feed into remediation rather than being logged and forgotten. NHIMG’s Guide to NHI Rotation Challenges is relevant here because stale credentials often persist precisely when teams assume “service” equals “stable.” Stability is not the control objective; controlled change and accountability are.

For organisations with large estates, a review process also needs a repeatable inventory view. NHI lifecycle management matters because provisioning, rotation, offboarding, and recertification are linked. If the account cannot be tied back to an owner or an application lifecycle, the review should not simply approve it by default.

How to Treat Service Accounts as Audit Evidence, Not Exceptions

Service accounts should be handled as normal reviewable access unless there is a documented reason they are out of band. That means they should appear in the access review population, have a reviewer, and be judged against the same access necessity test as human accounts. Excluding them because they are “technical” is usually a control design weakness, not a risk acceptance decision.

That principle is echoed by Access Reviews and Certification Guide, which emphasises completeness, risk context, and closing the loop on findings. In practice, the strongest evidence is not a spreadsheet row marked reviewed, but a demonstrable decision trail showing who validated the account, what access was retained, and what was removed or remediated.

The review should also align to surrounding identity controls. IAM and IGA basics are relevant because access certification, entitlement governance, and least privilege all rely on the same underlying truth: if an identity can act in the environment, it is part of the access estate and must be governed accordingly.

Risk and Threat Considerations

Service accounts often concentrate risk because they are designed for continuity, not friction. Long-lived credentials, broad entitlements, and weak ownership make them attractive targets for lateral movement, persistence, and quiet misuse, especially when the account is embedded in an application or automation path that operators rarely inspect.

Failure mechanism: Review programmes that exclude service accounts leave unexamined access paths in production systems, so excessive privilege and stale credentials survive certification cycles. Attackers or accidental misuse can then rely on those unattended identities to reach sensitive systems without triggering the same scrutiny as user accounts.

Impact: A single overlooked service account can undermine the control’s assurance value, expand blast radius, and delay detection of misuse. In regulated environments, that gap can also become an audit finding because the control was applied to people but not to the full identity population.

Practitioner Guidance

What to prioritise: Include every service account that can authenticate to a system, especially those with privileged or cross-environment access. If the account is excluded, there should be a documented, time-bound exception with an owner and a review date.

What to verify: Confirm the account’s business purpose, technical owner, authentication method, last use, and privilege scope before renewal. If nobody can explain why it exists, the safest default is to suspend review approval until ownership and necessity are established.

Practitioner takeaway: The question is not whether a service account is “human enough” for the review, it is whether it can still exercise access. If it can, it belongs in scope.

Related resources from NHI Mgmt Group

• How should organisations run ISO 27001 user access reviews without creating audit noise?
• How should organisations implement ISO 27001 access reviews across human and machine identities?
• What breaks when access reviews do not include cloud service accounts and projects?
• Should organisations treat service accounts like human users in access reviews?