ASD ISM 1508 Restricting privileged access to what duties require
What it says
Privileged access to systems and their resources is limited to only what is required for users to undertake their duties or functions.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishPrivileged accounts should carry only the elevated rights each person's role actually needs on the specific systems and resources they work with, and nothing more.
Privileged access means the powerful permissions that let someone change how a system works: administrator rights on servers and workstations, domain admin, root, database owner, cloud tenancy owner, security-tool admin and similar. This control says those rights must be scoped to what a person genuinely needs to carry out their duties or functions, across the systems they administer and the resources (data, services, configuration) within them. In practice that means a help-desk technician who resets passwords does not also hold domain admin, a database administrator does not have root on every server, and a cloud engineer who manages one workload is not an owner of the whole tenancy. It also means privileged rights are tied to a defined duty, so when the duty ends the access ends with it. Why it matters: privileged accounts are the prize in almost every serious intrusion. Phishing, credential theft and malware all become far more damaging when the compromised account can reach everything. Over-provisioned privilege also magnifies honest mistakes, since a mistyped command or misapplied policy from an all-powerful account can take down systems the person never intended to touch. Keeping privilege tightly matched to duties shrinks the blast radius of both attackers and accidents.
Free. Save your status, tasks and notes.
Why it matters
If privileged access is broader than duties require, a single compromised or careless privileged user can reach systems and resources well beyond their role. An attacker who captures one over-privileged account can move laterally across the environment, disable security controls, exfiltrate sensitive data or deploy ransomware at scale. Staff can also cause outages or data loss on systems they were never meant to administer. Excess privilege is likely to be raised as a significant finding in an ISM assessment, because it undermines the Essential Eight expectation of restricted administrative privileges and weakens most other controls that depend on trustworthy administration.
How to implement
The security or identity team inventories every privileged account and entitlement across servers, workstations, directories, databases, cloud tenancies, network devices and SaaS admin consoles, using directory queries, cloud IAM exports and privileged access management (PAM) discovery tools, and records who holds each and why.
System owners, working with the identity team, define privileged roles per system or platform that list the specific rights and resources each role covers (for example a database administrator role scoped to named database instances), and document which duties or functions justify each role.
IT operations implement the roles technically using role-based groups, scoped administrative units, delegated permissions and cloud IAM roles instead of blanket administrator or owner rights, and remove direct assignment of privilege to individual accounts wherever a role can be used.
The identity team configures just-in-time or on-demand elevation (through a PAM tool, privileged identity management, or sudo-style controls) for duties that need privilege only occasionally, so administrators hold minimal standing rights and check out higher rights for a defined task and time window.
The service desk and HR embed privilege handling in joiner, mover and leaver workflows so that role changes trigger removal of previous privileged rights, contractor privilege is time-boxed to the engagement, and terminations revoke all privileged access on the day of departure.
Keep it running
Day to day, this control lives in how privileged access is requested, granted, changed and removed. Every privileged entitlement should map to a documented duty or function, usually expressed as a role (for example "Windows server administrator", "backup operator", "M365 Exchange administrator") with a defined set of systems and rights. Requests for privilege are approved against that role definition rather than granted ad hoc, and anything outside the standard role needs a specific justification.
Joiner, mover and leaver processes must handle privilege explicitly. When someone changes teams, their old privileged rights are removed, not simply added to. Privileged access for contractors and vendors is scoped to the systems in their engagement and time-limited where possible. Where a task only needs elevated rights occasionally, prefer just-in-time or on-demand elevation over standing privilege, so the normal state is minimal.
Expect drift. Administrators accumulate rights through projects, incident response and convenience. Regular recertification by system owners, plus automated reports that highlight group membership growth, nested admin groups, shared or generic admin accounts and dormant privileged accounts, keep the environment aligned with the control. Deviations found during review should be corrected promptly and the root cause (usually a process gap) fixed.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Request the privileged role definitions or access matrix for a sample of in-scope systems, showing which duties each role serves and the specific rights and resources it covers.
Look at
Check that each privileged role is tied to a real duty or function and that the rights listed are scoped to particular systems or resources rather than global administrator or owner rights by default.
Good evidence
Roles are granular, justified by duties, and there is no catch-all administrator role handed to everyone who needs any elevation.
- Check 2 of 5What an auditor asks for
Ask for
Request a current export of privileged group membership, cloud IAM role assignments and local administrator membership for a sample of systems.
Look at
Compare each account holder's actual privileged rights with the role their position requires, and look for accounts holding privilege on systems outside their remit, nested groups that quietly expand reach, and shared or generic admin accounts.
Good evidence
Every privileged holder maps cleanly to an approved role for their duties, with any exceptions individually documented and approved.
- Check 3 of 5What an auditor asks for
Ask for
Request a sample of recent privileged access requests and approvals, including any granted outside the standard roles.
Look at
Check that each request states the duty or function driving it, was approved by an authorised owner, and that the rights granted match what was requested rather than exceeding it.
Good evidence
Approvals reference a defined role or a specific, time-limited justification, and there are no cases of privilege granted for convenience or 'just in case'.
- Check 4 of 5What an auditor asks for
Ask for
Request evidence of the mover and leaver process for staff and contractors who recently changed roles or departed, alongside the privileged access they previously held.
Look at
Confirm that privileged rights tied to the old role were removed when duties changed and that all privileged access was revoked promptly on departure.
Good evidence
Role changes result in removal, not accumulation, of privilege, and departed users have no remaining privileged entitlements.
- Check 5 of 5What an auditor asks for
Ask for
Request the most recent privileged access recertification results and any remediation tracking from system owners.
Look at
Check that owners actively reviewed each privileged holder against duties, that excess or dormant privilege was identified, and that removals were actually carried out.
Good evidence
Reviews occur on a defined cycle, produce real changes when drift is found, and the number of over-privileged accounts trends down over time.
Mappings
Closest match in ISO/IEC 27001: A.8.2, Management of privileged access rights, which asks for the same thing.
ISO/IEC 27001: 3 mappings
This control is equivalent to A.8.2.
ISM-1508 requires privileged access to be limited to only what is required for users to undertake their duties or functions. ISO/IEC 27001:2022 Annex A 8.2 similarly requires that privileged access rights are restricted and managed, aligning to least privilege for elevated permissions. Both controls focus on constraining and governing privileged rights; Annex A 8.2 is phrased more as governance/management but is materially the same obligation as ISM-1508.
This control partially meets A.5.15.
ISM-1508 requires that privileged access is limited to only what is required for duties or functions. ISO/IEC 27001:2022 Annex A 5.15 is broader because it requires establishing and implementing overall physical and logical access control rules based on business and security requirements. ISM-1508 is one specific rule (least privilege for privileged access) that should be embedded within the wider policy and procedure framework of Annex A 5.15.
This control partially meets A.8.3.
ISM-1508 requires limiting privileged access to what duties require, focusing on elevated permissions. ISO/IEC 27001:2022 Annex A 8.3 is broader by requiring restriction of access to information and associated assets generally in accordance with access control policy, covering both privileged and standard access. ISM-1508 is a specific least-privilege requirement within the broader access restriction expectations of Annex A 8.3.
ASD Essential Eight: 10 mappings
This control is equivalent to E8-RA-ML3.1.
E8-RA-ML3.1 requires privileged access to systems, applications and data repositories to be limited to what is required for users and services to undertake their duties. ISM-1508 states the same requirement by mandating privileged access to systems and their resources is limited to what is required for duties. The scope and intent align closely, making ISM-1508 effectively the ISM equivalent of E8-RA-ML3.1.
This control is broader than E8-RA-ML1.4.
E8-RA-ML1.4 requires privileged accounts to be limited to essential access specifically for online services. ISM-1508 applies the same least-privilege principle to privileged access across systems and resources generally, regardless of whether access is to online services. The primary is a specific subset of ISM-1508 focused on online service access by privileged accounts.
This control partially overlaps E8-RA-ML1.1.
E8-RA-ML1.1 requires organisations to validate privileged access requests upon initial request. This overlaps with ISM-1508 because initial validation should confirm the privileged access being requested is limited to what is required for users and services to perform their duties. ISM-1508 is a broader least-privilege requirement across privileged access generally, while E8-RA-ML1.1 is specifically about validating the request at the start of the access lifecycle.
This control partially overlaps E8-RA-ML1.2.
E8-RA-ML1.2 requires privileged users to use dedicated privileged accounts solely for privileged duties. ISM-1508 requires that privileged access is limited to what is necessary for duties (least privilege), which often pairs with using separate admin accounts to reduce over-privileged day-to-day sessions. ISM-1508 focuses on the level/scope of privileges granted, while E8-RA-ML1.2 focuses on account separation and how privileged access is used.
- E8-RA-ML1.3Prevent privileged user accounts from accessing internet, email and web servicesPartially overlaps
This control partially overlaps E8-RA-ML1.3.
ISM-1508 requires privileged access to be limited to what duties require across systems and resources. E8-RA-ML1.3 relates by preventing most privileged accounts from accessing internet, email and web services unless explicitly authorised, which is a concrete least-privilege restriction on a class of resources. E8-RA-ML1.3 is narrower and channel-specific (online access), while ISM-1508 is broader across all privilege assignments and resources.
- E8-RA-ML1.7Prevent privileged user accounts from logging on to unprivileged environmentsPartially overlaps
This control partially overlaps E8-RA-ML1.7.
ISM-1508 requires that privileged accounts only have and use the access necessary to perform assigned duties. E8-RA-ML1.7 relates by restricting where privileged accounts can log on, reducing exposure by preventing use in unprivileged environments that are more likely to be compromised. E8-RA-ML1.7 is environment-segregation focused, whereas ISM-1508 is broader and covers what rights are granted on systems and resources.
This control partially overlaps E8-RB-ML3.2.
ISM-1508 requires privileged access to be limited to only what is required for users to perform their duties. E8-RB-ML3.2 applies that least-privilege idea to a specific high-risk resource by preventing privileged users from accessing backups that could enable concealment or tampering. E8-RB-ML3.2 is narrower and backup-specific, while ISM-1508 is a general least-privilege requirement across systems and resources.
This control partially overlaps E8-RM-ML3.3.
ISM-1508 requires that privileged access is limited to what is necessary for duties on relevant systems and resources. E8-RM-ML3.3 maps to this by restricting write/modify permissions to Trusted Locations to only those privileged users with defined macro-checking responsibility. E8-RM-ML3.3 is a very specific application-control scenario, while ISM-1508 is a general least-privilege control across all resources.
This control supports E8-RA-ML2.1.
ISM-1508 requires privileged access to remain limited to what duties require, implying ongoing alignment of privilege with role. E8-RA-ML2.1 supports ISM-1508 by enforcing periodic revalidation and disabling privileged access that is no longer justified, reducing privilege creep. E8-RA-ML2.1 is time/review cadence specific, while ISM-1508 states the overarching least-privilege requirement.
This control supports E8-RA-ML3.3.
ISM-1508 requires that privileged access is limited to only what is necessary for a person's duties. E8-RA-ML3.3 supports ISM-1508 by implementing just-in-time administration so elevated permissions exist only when needed and can be time-bound to the task. ISM-1508 is about the entitlement scope, while E8-RA-ML3.3 is a mechanism to minimise standing privilege duration.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.