ASD ISM 1940 Restrict service accounts from privileged groups
What it says
Service accounts are not members of the Domain Admins, Enterprise Admins or other highly privileged security groups.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishService accounts shouldn't join Domain or Enterprise Admins for security.
Service accounts are special kinds of user accounts used by applications or services to interact with the system. It's critical to keep these accounts out of high-level admin groups because if they're hacked, attackers could gain the keys to your entire system, leading to major data breaches or disruptions.
Free. Save your status, tasks and notes.
Why it matters
Unrestricted service accounts in admin groups could lead to complete system compromise, causing data loss, service disruption, or financial damage.
How to implement
IT team should create a separate list of all service accounts in the organisation.
This can be done by reviewing the user directory and identifying accounts assigned to applications or services, rather than humans.
System administrator should ensure these accounts aren't part of any high-level groups like Domain Admins.
This involves checking group memberships and removing any service accounts found in these sensitive groups.
Managers should work with IT to label and document the purpose of each service account.
They need to write down what each account does and which systems it interacts with to ensure they are accounted for and properly managed.
IT security should set up regular reviews of service account access.
Periodically, perhaps quarterly, they should verify that no service accounts have been unintentionally granted high-level access.
HR and IT should collaborate on a policy for creating new service accounts.
There should be clear criteria for why and when a new service account is needed, ensuring they aren't created with unnecessary access rights.
Keep it running
Regularly check and adjust group memberships; service accounts often don't need admin access but may get it by mistake over time.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
the list of all service accounts: Request documentation that lists all service accounts including their roles and usage.
Look at
whether each account is clearly documented with its purpose and associated application.
Good evidence
a comprehensive list that matches known systems and uses.
- Check 2 of 5What an auditor asks for
Ask for
the group membership report: Obtain a report showing current group memberships of service accounts.
Look at
the specific groups each service account is a member of.
Good evidence
No service accounts are listed in Domain Admins, Enterprise Admins or similar groups.
- Check 3 of 5What an auditor asks for
Ask for
review logs or meeting records: Request evidence of periodic reviews of service account access.
Look at
records that show these reviews occur at regular intervals.
Good evidence
Documented records with dates and actions taken if any service accounts were found with improper access.
- Check 4 of 5What an auditor asks for
Ask for
about service account creation procedures: Inquire about the policies in place for creating new service accounts.
Look at
whether there is a documented process ensuring new accounts are evaluated for necessity and least privilege.
Good evidence
A policy document explaining the criteria and procedures for creating service accounts.
- Check 5 of 5What an auditor asks for
Ask for
to see monitoring reports or alerts: Request logs that capture any changes in service account group memberships.
Look at
any alerts or follow-up actions taken when such changes occur.
Good evidence
Alerts trigger investigations, and any unsuitable changes are quickly reversed.
Mappings
Closest match in ISO/IEC 27001: A.5.18, Managing access rights to information assets, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.5.18.
ISM-1940 requires that service accounts are not members of Domain Admins, Enterprise Admins, or other highly privileged AD security groups. This is a specific application of ISO/IEC 27001:2022 Annex A 5.18, which requires access rights to be provisioned, reviewed, modified, and removed in line with access control rules across information assets. Annex A 5.18 covers the full access-rights lifecycle and many asset types, while ISM-1940 is focused on a particular access-right (privileged AD group membership) for service accounts.
This control partially meets A.8.2.
ISM-1940 requires that service accounts are not members of highly privileged Active Directory groups (e.g., Domain Admins/Enterprise Admins). This is a specific implementation of ISO/IEC 27001:2022 Annex A 8.2, which requires organisations to restrict and manage the allocation and use of privileged access rights more broadly. Annex A 8.2 covers privileged access across users, systems, and processes, while ISM-1940 targets a concrete AD group-membership restriction for service accounts.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.