ASD ISM 1852 Limit unprivileged access to what duties require
What it says
Unprivileged 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 EnglishOrdinary (non-administrative) users get access only to the systems and resources their job actually needs, so that stray or excess access cannot be misused.
This control applies the principle of least privilege to everyday, unprivileged users. It says that a person's ordinary account should only be able to reach the systems, applications, shared folders, databases and other resources they need to do their particular duties or functions, and nothing more. Why it matters: most accounts in an organisation are unprivileged, and most compromises start with one of them, whether through phishing, a reused password or a lost laptop. If that account can open every file share, every application and every record in the business, an attacker inherits all of it. The same over-broad access lets a well-meaning staff member accidentally read, change or leak information that was never part of their job. Keeping unprivileged access tightly scoped to what each role requires shrinks the damage any single account can do and limits how far an intruder can move once inside.
Free. Save your status, tasks and notes.
Why it matters
If unprivileged access is not limited to what duties require, a single compromised or careless user account can expose far more systems and data than it should. Attackers who phish an ordinary staff member gain access to files, applications and records unrelated to that person's role, making lateral movement and data theft easier. Staff may also inadvertently view or alter sensitive information they had no business reason to reach, and the organisation cannot demonstrate to assessors that access to systems and resources is need-based.
How to implement
The security or IT manager, with each business unit lead, documents for every job role the systems and resources (applications, shared folders, databases, records) that role needs to perform its duties, producing a role-to-access matrix that becomes the baseline for unprivileged access.
System administrators configure unprivileged access through role or group-based permissions in Active Directory, Entra ID, the file server and each application, assigning users to roles that carry only the access in the matrix rather than granting permissions directly to individuals.
The IT service desk provisions new starters using the standard access set for their role from the matrix, and requires any request for access beyond that set to name the duty or function that needs it and to be approved by the requester's manager and the resource owner.
HR and IT run a joiner, mover and leaver process in which a role change triggers removal of access tied to the old role as well as the addition of access for the new one, so that access does not accumulate as people move around the organisation.
Resource owners (for shares, applications and data sets) carry out a scheduled review of which unprivileged users hold access to their resource, confirm each user's continuing need against their duties, and have the service desk remove any access that is no longer required.
Keep it running
Day to day, this control lives in the joiner, mover and leaver process and in how access requests are handled. New starters should receive a standard access set for their role rather than a copy of a colleague's account. When someone changes role, access no longer needed for the new duties should be removed, not just added to. Ad-hoc requests for extra access should state the duty or function that requires it and be approved by someone who can judge that need.
Owners of systems, shared drives and applications should periodically confirm that the unprivileged users with access still need it for their work, and remove access that has accumulated over time. Group and role definitions should be kept accurate so that access granted through them stays aligned with actual duties.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the documented mapping of job roles to the systems and resources each role needs.
Look at
Check that it covers the organisation's main systems, shared folders and applications, and that the access listed for each role is tied to the duties of that role.
Good evidence
A current role-to-access matrix exists, has an owner, and the access it grants is clearly justified by the duties of each role rather than being broad by default.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the actual group or role memberships and permissions for a sample of unprivileged users across different roles.
Look at
Compare each user's real access to what the matrix says their role requires, and look for access to resources unrelated to their duties.
Good evidence
Sampled users' effective access matches their role's documented requirements, with any additions supported by a recorded business need.
- Check 3 of 5What an auditor asks for
Ask for
Ask for a sample of access request tickets for unprivileged users, including any requests for access beyond the standard role set.
Look at
Check whether each request states the duty or function requiring the access and shows approval from someone able to judge that need.
Good evidence
Requests consistently record the reason tied to the person's duties and carry appropriate approval before access is granted.
- Check 4 of 5What an auditor asks for
Ask for
Ask for records of recent role changes and departures and the corresponding access changes made.
Look at
Check whether access linked to the previous role was removed when the person moved, not just supplemented, and whether leavers' access was removed.
Good evidence
Mover records show old-role access being removed on transfer, and there is no accumulation of access from previous positions.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the most recent access reviews carried out by owners of shares, applications or data sets for unprivileged users.
Look at
Check whether reviews confirmed each user's continuing need against their duties and whether unnecessary access identified was actually removed.
Good evidence
Reviews are completed on schedule, decisions are recorded per user, and removals resulting from the review can be traced through to the system.
Mappings
Closest match in ASD Essential Eight: E8-RB-ML1.5, Unprivileged user accounts cannot access others' backups, which this control covers in full and more.
ISO/IEC 27001: 3 mappings
This control partially meets A.5.15.
ISM-1852 requires that unprivileged users only have access to systems and resources needed for their duties. Annex A 5.15 requires establishing and implementing rules and procedures to control physical and logical access based on business and information security requirements. ISM-1852 is a specific rule outcome (least privilege for unprivileged access) that would typically be implemented under the broader access control policy and procedures of Annex A 5.15.
This control partially meets A.5.18.
ISM-1852 requires limiting unprivileged access to systems and resources to what duties require. Annex A 5.18 requires access rights to be provisioned, reviewed, modified and removed in line with access control policy, covering the full access-rights lifecycle for information assets. ISM-1852 is one specific access-right outcome (least privilege for unprivileged users) within the broader governance and lifecycle management demanded by Annex A 5.18.
This control partially meets A.8.3.
ISM-1852 requires limiting unprivileged access to only what is required to perform duties. Annex A 8.3 requires restricting access to information and associated assets in accordance with an established access control policy, which applies broadly across user types and asset classes. ISM-1852 is a specific least-privilege application for ordinary users within the wider access restriction requirement of Annex A 8.3.
ASD Essential Eight: 3 mappings
This control is broader than E8-RB-ML1.5.
E8-RB-ML1.5 requires that unprivileged accounts cannot access backups belonging to other accounts. ISM-1852 requires limiting unprivileged access to systems and resources to what is necessary for duties, which would include preventing unnecessary access to other users' backup data. E8-RB-ML1.5 is a specific least-privilege constraint focused on backup access, whereas ISM-1852 applies broadly across systems and resources.
This control partially overlaps E8-RA-ML1.4.
ISM-1852 requires organisations to restrict unprivileged access to only what is required for users and services to do their jobs. E8-RA-ML1.4 restricts privileged accounts authorised to access online services to only what is required for duties, applying least privilege in a specific channel (online services). The controls intersect on limiting access to need-to-know/need-to-do, but ISM-1852 is unprivileged and broad, while E8-RA-ML1.4 is privileged and narrower to online service access.
This control partially overlaps E8-RA-ML3.1.
ISM-1852 requires unprivileged access to systems and resources to be limited to only what users and services need to perform their duties (least privilege for non-admin access). E8-RA-ML3.1 applies the same least-privilege concept but specifically to privileged access across systems, applications, and data repositories. They align on the underlying access minimisation principle, but differ in scope because ISM-1852 is about unprivileged access while E8-RA-ML3.1 is about privileged access.
ASD Essentials for enterprise IT: 2 mappings
- IT.PRO-12.1Periodically review and update access privileges to match current roles and dutiesPartially overlaps
This control partially overlaps IT.PRO-12.1.
IT.PRO-12.1 requires access privileges to be periodically reviewed and updated to match current roles, duties and business requirements; ISM-1852 limits unprivileged access to what users need for their duties or functions, the outcome those reviews maintain.
- IT.PRO-12.3Provision user, administrative and non-person accounts with minimum required privilegesPartially overlaps
This control partially overlaps IT.PRO-12.3.
IT.PRO-12.3 requires user, administrative and non-person accounts to be provisioned with only the minimum access and privileges they need; ISM-1852 limits unprivileged access to what users need for their duties or functions, covering the user account part.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.