What does the checker look for on a service account?

It reads the lines of your export and raises, where the columns support it: 2. owner has left, or owner not recognised; 3. no owner named, or a team named with no accountable person; 4. dormant for more than the threshold; 5. privileged, and orphaned or dormant; 6. password or key not changed within the period, or never; 7. service or system account that allows interactive login; 8. credential stored in code, a config file or a script; 10. not reviewed within the interval; 12. created with no approval recorded. Each finding is a question for the account owner or the reviewer.

Account types

Service account

A named person in the team that runs the application owns it, knows what it can reach and answers the review; a department or a mailbox is not a person.

Who should own a service account, and which ISO/IEC 27001, SOC 2 and PCI DSS clauses apply?

The clauses the checker cites on a service account: ISO/IEC 27001 A.5.15, ISO/IEC 27001 A.5.16, ISO/IEC 27001 A.8.2, SOC 2 CC6.1, PCI DSS 7.2.5, PCI DSS 7.2.5.1, PCI DSS 8.6.1 and PCI DSS 8.6.3. Every clause it cites, across the seven regimes, is in the table below.

How the checker reads it

It is an application or system account: PCI DSS reads it under 7.2.5, 7.2.5.1 and 8.6.1 to 8.6.3, never under the user-account periods.
It needs a named person as owner; a blank owner, a team or a mailbox is finding 3, and an owner who has left by the staff list is finding 2.
The type comes from your type column; when that is blank the checker reads the account name and labels the type assumed from the name, and any finding resting on it is read as a question by the reviewer.

Findings that can apply

9 of 14

2. Owner has left, or owner not recognised: Who owns this account now, and should it still exist?
3. No owner named, or a team named with no accountable person: Which one person is accountable for this account and can say what it is for?
4. Dormant for more than the threshold: Is this account still needed, and if so by whom?
5. Privileged, and orphaned or dormant: Who holds these rights today, and do they still need them?
6. Password or key not changed within the period, or never: When was this credential last changed, and who knows it?
7. Service or system account that allows interactive login: Who signs in to this account interactively, and can interactive login be turned off?
8. Credential stored in code, a config file or a script: Can this credential move into a vault, and who has read the file it sits in?
10. Not reviewed within the interval: Who reviews this account, and when is the next review due?
12. Created with no approval recorded: Where is the request and the approval for this account?

Clauses

11 cited

Regime	Clause
ISO/IEC 27001	ISO/IEC 27001 A.5.15 Access control
ISO/IEC 27001	ISO/IEC 27001 A.5.16 Identity management
ISO/IEC 27001	ISO/IEC 27001 A.8.2 Privileged access rights
SOC 2	SOC 2 CC6.1 Logical access security over protected information assets
PCI DSS	PCI DSS 7.2.5 Application and system accounts least privilege
PCI DSS	PCI DSS 7.2.5.1 Application and system account access reviewed periodically
PCI DSS	PCI DSS 8.6.1 Interactive use of system accounts controlled
PCI DSS	PCI DSS 8.6.3 System account passwords protected against misuse
NIST SP 800-53	NIST SP 800-53 IA-9 Service Identification and Authentication
NIST SP 800-53	NIST SP 800-53 AC-2 Account Management
CIS Controls	CIS Controls 5.5 Establish and Maintain an Inventory of Service Accounts

The first clause, set out

ISO/IEC 27001 A.5.15Access control

Rules that govern both physical entry and logical access to information and associated assets are to be set and applied on the basis of business and information security requirements. Purpose (stated in ISO/IEC 27002:2022): ensures access to information and associated assets is authorized and unauthorized access is prevented. As an Annex A reference control, it is compared with the controls determined in risk treatment (6.1.3 c) and recorded in the Statement of Applicability as included or excluded, with the justification and implementation status (6.1.3 d); implementation guidance is ISO/IEC 27002:2022 5.15.

What an auditor asks to see: Statement of Applicability entry for control A.5.15, showing inclusion or justified exclusion, implementation status and the risks it treats; The topic-specific access control policy, approved and communicated, reflecting owner-defined business and security requirements; Access control rules or role models mapping entities (users, services, devices) to rights, consistent with classification; Evidence of a default-deny design in firewall rules, application roles and cloud IAM policies; Separation of request, approval and administration functions in the access management workflow

Where account lists usually fall short: The access control policy exists but is not reflected in actual system configurations; Default-allow rules persist in network or cloud environments; Non-human entities such as service accounts are left outside the access rules; Access rights are not aligned with classification, so sensitive data is broadly accessible

Source: ISO/IEC 27001:2022 Annex A

A line that reads as this type

the type column left blank, invented values

svc-print-queue | | directory | | yes

See the specimen run