ISO 27001 Annex A 8.2 Management of privileged access rights
What it says
The allocation and use of privileged access rights shall be restricted and managed.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishControl and limit who gets special access to sensitive systems to keep them secure.
This control is about managing who gets special access to sensitive parts of your computer systems. If you don't handle it properly, unauthorised people might get into critical areas, which could lead to data leaks or system breakdowns, jeopardising your business's security and reputation.
Free. Save your status, tasks and notes.
Why it matters
If privileged access is not tightly managed, attackers can gain control over vital systems, leading to data theft, operational disruptions, and reputational harm.
How to implement
IT managers should identify which team members need special access to sensitive systems.
Start by listing roles that require heightened access, like system administrators, and ensure they have a justifiable reason for needing it.
HR and the IT manager should work together to approve who gets special access.
Create a standard process for requesting and approving these access rights, aligning with policies like the OAIC guidelines on personal data protection.
The IT department should set up systems to automatically expire special access rights when they are no longer needed.
For example, use automated reminders and software tools to review and revoke access after a specified time, ensuring compliance with CPS 234 requirements.
Make sure all staff with special access rights are aware of their responsibilities.
Regularly train these individuals about the significance of their access and the privacy obligations under the Privacy Act 1988.
The IT manager should routinely audit privileged access rights.
Conduct regular checks, especially after staff changes, to ensure that only those who should have special access actually have it, following ASD Essential Eight guidelines.
Keep it running
Regularly review and adjust privilege allocations, ensuring access matches current roles and requires justification for changes.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
A list of users with privileged access rights.
Look at
The names, roles, and justifications for access.
Good evidence
Ensure that only necessary personnel have access, with clear rationales provided.
- Check 2 of 5What an auditor asks for
Ask for
Documentation on the access approval process.
Look at
How requests are submitted, reviewed, and approved.
Good evidence
Include a formal procedure with evidence of compliance and adherence to policies.
- Check 3 of 5What an auditor asks for
Ask for
Records of expired access rights.
Look at
How often rights are reviewed and revoked.
Good evidence
Show a systematic and recent audit trail of access rights changes.
- Check 4 of 5What an auditor asks for
Ask for
How users are informed of their privileged access rights and responsibilities.
Look at
Training materials and records of trainings completed.
Good evidence
Provide clear evidence of regular training sessions aligned with their access privileges.
- Check 5 of 5What an auditor asks for
Ask for
Logs of privileged access activities.
Look at
The completeness and frequency of log entries.
Good evidence
Show consistent and thorough documentation of when and what systems were accessed.
Mappings
Closest match in ASD Essential Eight: E8-MF-ML2.1, Multi-factor authentication for privileged users of systems, which this control covers in full and more.
ASD Essential Eight: 12 mappings
This control is broader than E8-MF-ML2.1.
E8-MF-ML2.1 requires MFA to authenticate privileged users of systems. ISO/IEC 27001:2022 Annex A 8.2 requires privileged access rights to be restricted and managed, and MFA is a key mechanism that strengthens control over the use of those rights. Annex A 8.2 covers broader privileged access governance (allocation, restriction, and ongoing management) beyond authentication, while E8-MF-ML2.1 focuses specifically on stronger authentication for privileged users.
This control is broader than E8-RA-ML1.1.
E8-RA-ML1.1 requires organisations to validate privileged access requests when they are first requested. Annex A 8.2 requires privileged access rights to be restricted and managed across their allocation and use, covering broader privileged access governance. E8-RA-ML1.1 is one specific control activity within that broader management lifecycle (initial validation/provisioning decision).
This control is broader than E8-RA-ML1.2.
E8-RA-ML1.2 requires a specific administrative practice: privileged users must use separate dedicated privileged accounts only for privileged tasks. ISO/IEC 27001:2022 Annex A 8.2 requires privileged access rights to be allocated, used, restricted and managed, which is broader governance over privileged access. E8-RA-ML1.2 is one concrete mechanism that helps satisfy the broader privileged access management expectations in Annex A 8.2.
- E8-RA-ML1.3Prevent privileged user accounts from accessing internet, email and web servicesBroader than
This control is broader than E8-RA-ML1.3.
E8-RA-ML1.3 requires a specific restriction: privileged accounts are prevented from accessing internet, email and web services except where authorised. Annex A 8.2 requires organisations to restrict and manage the allocation and use of privileged access rights more generally, which includes (but is not limited to) limiting where and how privileged accounts can be used. E8-RA-ML1.3 is a concrete, specific implementation that would sit under the broader governance intent of Annex A 8.2.
This control is broader than E8-RA-ML1.4.
E8-RA-ML1.4 requires that privileged accounts authorised to access online services are restricted to the minimum necessary access for duties. ISO/IEC 27001:2022 Annex A 8.2 broadly requires that privileged access rights are allocated and used in a restricted and managed manner, which encompasses limiting privileged accounts' online service access.
- E8-RA-ML1.7Prevent privileged user accounts from logging on to unprivileged environmentsBroader than
This control is broader than E8-RA-ML1.7.
E8-RA-ML1.7 requires a specific restriction: privileged accounts (excluding local administrator accounts) cannot log on to unprivileged operating environments. ISO/IEC 27001:2022 Annex A 8.2 requires that privileged access rights are allocated and used in a restricted and managed manner, covering broader governance and controls for privileged access. E8-RA-ML1.7 is one concrete technical restriction that would support compliance with Annex A 8.2, but Annex A 8.2 extends beyond logon context to cover the overall management of privileged rights.
This control is broader than E8-RA-ML2.1.
Annex A 8.2 requires privileged access rights to be restricted and managed across their allocation, use, and ongoing governance. E8-RA-ML2.1 relates by mandating a specific lifecycle management rule: privileged access must be disabled after 12 months unless explicitly revalidated. The Essential Eight control is a concrete review/recertification cadence, while Annex A 8.2 is broader and also covers initial authorisation, role/need-to-know decisions, monitoring, and revocation triggers beyond a 12-month period.
This control is broader than E8-RA-ML2.2.
E8-RA-ML2.2 requires privileged access to be disabled after 45 days of inactivity. Annex A 8.2 requires organisations to restrict and manage the allocation and use of privileged access rights across their lifecycle. Disabling inactive privileged access in E8-RA-ML2.2 is one specific privileged access management practice that supports meeting the broader governance intent of Annex A 8.2.
- E8-RA-ML3.3Just-in-time administration is used for administering systems and applications.Broader than
This control is broader than E8-RA-ML3.3.
E8-RA-ML3.3 requires JIT administration, a specific method for controlling the allocation and use of privileged access by making it time-bound and on-demand. ISO/IEC 27001:2022 Annex A 8.2 requires privileged access rights to be restricted and managed across their lifecycle, which can be achieved through multiple methods including JIT. E8-RA-ML3.3 is therefore a specific implementation approach within the broader expectations of Annex A 8.2.
This control is broader than E8-RB-ML2.1.
E8-RB-ML2.1 requires a specific privileged-access restriction: privileged accounts (excluding backup administrators) must not be able to access other users' backups. ISO/IEC 27001:2022 Annex A 8.2 relates by requiring that privileged access rights are allocated and used in a restricted and managed way, which would encompass restricting privileged access to backup repositories. However, Annex A 8.2 is broader and does not explicitly call out backup separation or the backup administrator exception found in E8-RB-ML2.1.
This control is broader than E8-RM-ML3.3.
E8-RM-ML3.3 mandates restrictions on who can modify Microsoft Office Trusted Locations, specifically allowing only privileged users who verify macros. Annex A 8.2 calls for the allocation and management of privileged access across the organisation, making E8-RM-ML3.3 a more specific application within a broader privileged access management framework.
This control partially meets E8-RA-ML3.1.
E8-RA-ML3.1 requires privileged access to systems, applications and data repositories to be limited to what is necessary for duties. ISO/IEC 27001:2022 Annex A 8.2 requires privileged access rights to be allocated and used in a restricted and managed way across their lifecycle. Annex A 8.2 is broader because it includes management practices (allocation, use, control and oversight), while E8-RA-ML3.1 focuses specifically on limiting privileges to duty necessity.
ASD Information Security Manual: 55 mappings
This control is broader than ISM-0443.
ISM-0443 requires that temporary access is not granted to systems handling caveated or sensitive compartmented information. ISO/IEC 27001:2022 Annex A 8.2 requires privileged access rights to be restricted and managed, which can include limiting or disallowing time-bound/temporary privileged access. Annex A 8.2 applies to privileged access generally (not necessarily temporary access, nor tied to SCI/caveats), whereas ISM-0443 is a specific prohibition based on information sensitivity.
This control is broader than ISM-0445.
ISM-0445 requires privileged human users to be issued a dedicated privileged account used solely for privileged duties. ISO/IEC 27001:2022 Annex A 8.2 (Management of Privileged Access Rights) is broader, covering how privileged rights are allocated, restricted, reviewed, and managed across the organisation. ISM-0445 is a specific privileged-access management measure (separation of admin and standard accounts) that would contribute to meeting Annex A 8.2 but does not cover all its management expectations.
This control is broader than ISM-0447.
ISM-0447 requires that foreign nationals (except seconded foreign nationals) are not granted privileged access to systems that process, store or communicate AGAO data. ISO/IEC 27001:2022 Annex A 8.2 requires privileged access rights to be restricted and managed, which can include eligibility criteria such as citizenship/nationality. ISM-0447 is a specific nationality-based restriction for a defined data/system scope, whereas Annex A 8.2 is a broader privileged-access governance control covering all privileged access allocation and use.
This control is broader than ISM-0611.
ISM-0611 requires that gateway system administrators are assigned the minimum privileges required to perform their duties. ISO/IEC 27001:2022 Annex A 8.2 requires privileged access rights to be restricted and managed, covering allocation, use, and ongoing control of these rights across the organisation. ISM-0611 is a specific least-privilege requirement for a particular admin cohort (gateways) within the broader privileged access management expectations of Annex A 8.2.
This control is broader than ISM-0616.
ISM-0616 requires separation of duties for gateway administrative activities, dividing administrative functions between different personnel. Dividing these duties restricts the privileged access rights each gateway administrator holds, which directly supports the restriction and management of privileged access rights required by Annex A 8.2. Annex A 8.2 covers the allocation and use of privileged access across all systems, while ISM-0616 addresses only how gateway administrative duties are split.
This control is broader than ISM-0629.
ISM-0629 requires that shared gateway components between different security domains are managed by administrators from the higher security domain or an agreed third party. Annex A 8.2 requires privileged access rights to be restricted and managed, which is directly relevant to controlling who can administer gateway infrastructure spanning domains. Annex A 8.2 is about managing privileged access generally, while ISM-0629 is a specific assignment of administrative control for cross-domain gateway shared components.
This control is broader than ISM-1175.
ISM-1175 requires privileged user accounts (unless explicitly authorised) to be prevented from accessing the internet, email and web services. ISO/IEC 27001:2022 Annex A 8.2 is broader, requiring the allocation and use of privileged access rights to be restricted and managed across the organisation. ISM-1175 is a specific control measure within the wider privileged access management practices described by Annex A 8.2.
This control is broader than ISM-1249.
ISM-1249 requires server applications to use separate user accounts and least privilege to perform their functions. Annex A 8.2 broadly requires privileged access rights to be restricted and managed, covering allocation, use, and governance of elevated permissions across the organisation. ISM-1249 is a specific service-account/run-time privilege control, while Annex A 8.2 encompasses processes beyond server applications.
This control is broader than ISM-1263.
ISM-1263 requires unique privileged user accounts to be used for administering individual server applications. Annex A 8.2 relates because it requires privileged access rights to be restricted and managed, which commonly includes avoiding shared administrator accounts and ensuring accountability. ISM-1263 is a specific implementation pattern within the broader privileged access governance required by Annex A 8.2.
This control is broader than ISM-1507.
ISM-1507 requires organisations to verify (validate) privileged access requests when they are first raised, focusing on the authorisation decision point. Annex A 8.2 requires privileged access rights to be restricted and managed across their allocation and use. ISM-1507 is one specific control activity within the broader ISO requirement to manage privileged access rights end-to-end.
This control is broader than ISM-1612.
ISM-1612 requires that break glass accounts are only used for specific authorised activities. This is narrower than Annex A 8.2 because Annex A 8.2 broadly requires the allocation and use of all privileged access rights to be restricted and managed, across the organisation. ISM-1612 is a specific privileged-access usage rule focused on a high-risk privileged account type (break glass) and its permitted emergency use cases.
This control is broader than ISM-1620.
ISM-1620 requires a specific mechanism for securing privileged accounts by placing them in the AD Protected Users security group. Annex A 8.2 requires organisations to restrict and manage the allocation and use of privileged access rights more broadly. ISM-1620 is one concrete implementation that supports privileged access restriction, but it does not on its own cover the full management expectations in Annex A 8.2 (e.g. approval, review, and governance of privileged rights).
This control is broader than ISM-1647.
Annex A 8.2 requires privileged access rights to be restricted and managed through their lifecycle. ISM-1647 relates by requiring privileged access to be disabled after 12 months unless revalidated, which is a specific periodic review and revocation mechanism for privileged rights. ISM-1647 is a prescriptive subset (time-based revalidation), whereas Annex A 8.2 also encompasses broader privileged access management practices such as approval, logging, just-enough access and event-based revocation.
This control is broader than ISM-1648.
ISM-1648 requires a specific administrative action: disabling privileged access after 45 days of inactivity. Annex A 8.2 requires privileged access rights to be restricted and managed more broadly across allocation and use. ISM-1648 is a concrete lifecycle/housekeeping mechanism that fits within the broader privileged access management expectations of Annex A 8.2.
This control is broader than ISM-1649.
ISM-1649 requires the use of just-in-time administration for system administration, reducing persistent privileged access. Annex A 8.2 requires privileged access rights to be restricted and managed across their allocation and use. JIT administration is one concrete mechanism for managing privileged access, making ISM-1649 a specific subset of the broader privileged access management requirement in Annex A 8.2.
This control is broader than ISM-1685.
ISM-1685 requires that critical account credentials (break glass, local administrator and service accounts) are long, unique, unpredictable and managed. Annex A 8.2 requires privileged access rights to be restricted and managed, focusing on authorisation and governance of privileged rights rather than credential strength. Strong, well-managed privileged credentials under ISM-1685 strengthen the effectiveness of privileged access management under Annex A 8.2, but do not cover its full allocation/use lifecycle requirements.
This control is broader than ISM-1688.
ISM-1688 requires that unprivileged user accounts cannot log on to privileged operating environments. ISO/IEC 27001:2022 Annex A 8.2 requires privileged access rights to be restricted and managed, covering broader governance of privileged entitlements and their use. ISM-1688 is a specific restriction pattern (blocking unprivileged logons to privileged environments) that can be implemented as one mechanism under Annex A 8.2.
This control is broader than ISM-1689.
ISM-1689 specifically requires blocking privileged account logons to unprivileged environments. Annex A 8.2 broadly addresses managing and limiting privileged access, under which ISM-1689's specific constraint can be a subset.
This control is broader than ISM-1827.
Annex A 8.2 requires privileged access rights to be restricted and managed, including controlling the allocation and use of administrative credentials. ISM-1827 relates by requiring dedicated domain administrator accounts for administering domain controllers that are not used to administer other systems, reducing exposure and misuse of highly privileged credentials. ISM-1827 is a specific credential segregation practice for domain controller administration, while Annex A 8.2 is broader across all privileged roles, systems and access right types.
This control is broader than ISM-1835.
ISM-1835 requires privileged Active Directory (AD) accounts to be configured as sensitive so they cannot be delegated, reducing the risk of credential forwarding and impersonation in AD/Kerberos flows. Annex A 8.2 requires an organisation to restrict and manage the allocation and use of privileged access rights, which includes applying technical controls that prevent misuse of privileged credentials (such as disallowing delegation for high-privilege identities). Annex A 8.2 is broader across all systems and privileged right types, while ISM-1835 is a specific Australian Government ISM hardening requirement for AD privileged account configuration.
This control is broader than ISM-1842.
Annex A 8.2 requires privileged access rights to be restricted and managed so only authorised entities can perform high-impact actions. ISM-1842 relates by mandating that dedicated privileged service accounts are used to add machines to the domain, controlling and limiting a specific privileged function in Active Directory. ISM-1842 is a narrow, task-specific implementation for domain join operations, whereas Annex A 8.2 covers privileged access management holistically across functions and platforms.
This control is broader than ISM-1846.
ISM-1846 requires that the Pre-Windows 2000 Compatible Access group has no user accounts, removing an obsolete mechanism that can grant overly broad directory read access. This is a specific implementation of Annex A 8.2 (management of privileged access rights) because it constrains and manages a high-impact access assignment within Active Directory. Annex A 8.2 is broader, covering allocation and use of privileged rights generally across systems, not just this single legacy group.
This control is broader than ISM-1883.
ISM-1883 requires least-privilege restrictions specifically for privileged accounts that are authorised to access online services. ISO/IEC 27001:2022 Annex A 8.2 requires organisations to restrict and manage the allocation and use of privileged access rights in general. ISM-1883 fits within Annex A 8.2 as a more specific privileged access management requirement targeted at online service access.
This control is broader than ISM-1898.
ISM-1898 requires Secure Admin Workstations for administrative activities to reduce the likelihood of privileged access being abused or stolen via standard endpoints. ISO/IEC 27001:2022 Annex A 8.2 requires privileged access rights to be restricted and managed, focusing on how privilege is granted and controlled. Secure Admin Workstations support Annex A 8.2 by reducing credential exposure and providing a controlled environment for using privileged rights, but they do not by themselves define privileged rights management processes.
This control is broader than ISM-1927.
ISM-1927 requires that access to AD DS domain controllers and related identity servers is limited to privileged users who genuinely require it. ISO/IEC 27001:2022 Annex A 8.2 requires that the allocation and use of privileged access rights is restricted and managed across the organisation. ISM-1927 is a concrete, technology-specific application of privileged access management focused on identity infrastructure, whereas Annex A 8.2 is broader and does not single out identity servers.
This control is broader than ISM-1934.
ISM-1934 requires periodic (at least annual) review of DCSync permissions and removal if there is no ongoing requirement. Annex A 8.2 requires privileged access rights to be restricted and managed, covering governance across allocation, use and ongoing control. ISM-1934 is a specific privileged-access management practice for one particularly sensitive privilege (DCSync), fitting within the broader Annex A 8.2 requirement.
This control is broader than ISM-1936.
ISM-1936 requires that Active Directory user accounts do not use the sIDHistory attribute, reducing the risk of unintended or covert privilege inheritance through SID mapping. This relates to Annex A 8.2 because disabling/avoiding sIDHistory is a specific technical measure that helps restrict and manage privileged access rights in identity systems. Annex A 8.2 is broader and covers governance and controls for privileged access allocation and use across systems, not just sIDHistory in AD.
This control is broader than ISM-1939.
Annex A 8.2 requires privileged access rights to be restricted and managed, including limiting who holds highly privileged permissions. ISM-1939 relates by requiring minimisation of membership in Domain Admins, Enterprise Admins and other highly privileged groups. ISM-1939 is narrower and specific to certain AD groups, while Annex A 8.2 applies to privileged rights across all systems, applications and privilege models.
This control is broader than ISM-1940.
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.
This control is broader than ISM-1941.
ISM-1941 requires that computer accounts are not members of Domain Admins, Enterprise Admins or other highly privileged security groups. This is a specific restriction on the allocation of privileged access rights in Active Directory and contributes directly to Annex A 8.2, which requires the allocation and use of privileged access rights to be restricted and managed. Annex A 8.2 covers privileged access management for all users, systems and processes, while ISM-1941 addresses only computer account group membership.
This control is broader than ISM-1942.
ISM-1942 requires that the Active Directory Domain Computers group is not a member of any privileged or highly-privileged security groups. This relates directly to Annex A 8.2, which requires organisations to restrict and manage the allocation and use of privileged access rights (including through group membership). Annex A 8.2 is broader, covering the full lifecycle and governance of privileged access, while ISM-1942 is a specific directory-group hygiene constraint aimed at preventing unintended privilege for computer accounts.
This control is broader than ISM-1946.
ISM-1946 requires that unprivileged user accounts do not have write access to certificate templates to prevent unauthorised changes to PKI issuance settings. This relates to Annex A 8.2 because restricting who can change certificate templates is a specific instance of managing and restricting privileged access rights to sensitive security functions. Annex A 8.2 is broader as it covers the governance and restriction of privileged access rights across systems and use cases, not just certificate template write permissions.
This control is broader than ISM-1949.
ISM-1949 mandates dedicated, non-reused accounts for administering AD FS servers to control and segregate privileged access. Annex A 8.2 requires privileged access rights to be restricted and managed more generally across the organisation. ISM-1949 is a technology-specific, concrete control that fits within the broader privileged access management expectations of Annex A 8.2.
This control is broader than ISM-1952.
ISM-1952 requires that privileged user accounts are not synchronised between Microsoft AD DS and Microsoft Entra ID to reduce the risk of cloud compromise leading to on-premises privileged access (and vice versa). ISO/IEC 27001:2022 Annex A 8.2 requires privileged access rights to be restricted and managed across the organisation, which can include controlling how privileged identities are provisioned and where they exist. ISM-1952 is a specific technical identity-architecture constraint that sits under the broader governance and management expectations of Annex A 8.2.
This control is broader than ISM-1958.
Annex A 8.2 requires privileged access rights to be restricted and managed, including controlling where and how highly privileged rights can be used. ISM-1958 relates by imposing a specific constraint on accounts with DCSync permissions, preventing them from logging on to unprivileged operating environments to reduce credential theft and misuse. ISM-1958 is a targeted, AD-specific segregation control for one privileged permission set, while Annex A 8.2 is broader across all privileged rights and platforms.
This control is broader than ISM-2048.
ISM-2048 requires that non-administrative users are prevented from altering their own profile permissions or privileges in software that supports multiple roles. ISO/IEC 27001:2022 Annex A 8.2 relates by requiring privileged access rights to be restricted and managed, which commonly includes preventing self-service privilege changes by non-admins. Annex A 8.2 is broader because it covers the allocation, use, and governance of privileged rights across the organisation, not just the specific control of blocking non-admin self-modification in applications.
This control is broader than ISM-2128.
ISM-2128 requires limiting the ability to install, load or modify kernel-mode code to privileged users who need it for their functions. ISO/IEC 27001:2022 Annex A 8.2 requires privileged access rights to be restricted, including governing powerful technical privileges like loading drivers or kernel extensions. Annex A 8.2 is broader, whereas ISM-2128 is a focused instantiation of that principle.
This control partially meets ISM-1650.
Annex A 8.2 requires privileged access rights to be restricted and managed, which typically includes accountability mechanisms around privileged operations. ISM-1650 relates by requiring central logging of privileged user account and security group management events to monitor and detect inappropriate privilege changes. ISM-1650 is focused on audit logging, while Annex A 8.2 is broader and includes authorisation, assignment, and restrictions on use.
This control partially overlaps ISM-0407.
ISM-0407 requires a secure, life-of-system record for each user covering authorisation, access grant dates, access level, reviews, changes and withdrawal. Annex A 8.2 relies on strong governance of privileged access allocation and use, and secure access records provide the audit trail and accountability needed to demonstrate privileged access was properly approved, reviewed and adjusted. Annex A 8.2 focuses on restricting and managing privileged rights, whereas ISM-0407 focuses on maintaining evidence of access decisions for all users (not only privileged users).
This control partially overlaps ISM-0415.
ISM-0415 requires strict governance over shared user accounts and unique identification of each person who uses them to maintain accountability. ISO/IEC 27001:2022 Annex A 8.2 restricts and manages privileged access rights, which often includes constraining the use of shared administrative accounts and ensuring their use is controlled. The overlap is strongest where shared accounts are privileged, but ISM-0415 applies to shared accounts generally (privileged or not) and is specifically about user attribution, whereas Annex A 8.2 is primarily about privileged-right allocation and use controls.
This control partially overlaps ISM-0446.
ISM-0446 requires that foreign nationals (including seconded foreign nationals) are not granted privileged access to systems processing, storing or communicating AUSTEO or REL data. Annex A 8.2 requires privileged access rights to be restricted and managed, which is one of the mechanisms an organisation would use to prevent privileged access being granted to ineligible cohorts (such as foreign nationals). Annex A 8.2 is broader and generic (covering all privileged access management), while ISM-0446 is a specific eligibility restriction tied to nationality/secondment status and AUSTEO/REL systems.
This control partially overlaps ISM-1250.
Annex A 8.2 requires privileged access rights to be restricted and managed to ensure elevated capabilities are tightly controlled. ISM-1250 relates by requiring that server application run-as accounts have limited access to the underlying server file system, effectively reducing privileges granted to service accounts. ISM-1250 is a least-privilege implementation for application accounts on servers, while Annex A 8.2 is broader and also covers human administrator privileges, approval processes and ongoing governance of privileged rights.
This control partially overlaps ISM-1487.
Annex A 8.2 requires privileged access rights to be restricted and managed, including limiting who can perform high-impact administrative actions. ISM-1487 relates by restricting the ability to write/modify macro Trusted Locations to privileged users responsible for validating macros, which is a privileged capability within Microsoft Office configuration. ISM-1487 is focused on macro security and content control in a specific feature set, whereas Annex A 8.2 covers privileged access rights across all systems and administrative functions.
This control partially overlaps ISM-1508.
Annex A 8.2 requires the allocation and use of privileged access rights to be restricted and managed. ISM-1508 establishes that privileged access to systems and resources is limited to necessary duties, demonstrating overlap with Annex A 8.2's intent on constraining privileged rights to essential duties.
This control partially overlaps ISM-1591.
ISM-1591 requires suspension or removal of access when malicious activity is detected to contain harm quickly. Annex A 8.2 restricts and manages privileged access rights, which reduces the impact of malicious actions and makes it easier to target and revoke high-risk access quickly. ISM-1591 is about reactive removal/suspension on detection, while Annex A 8.2 is preventative governance over privileged access allocation and use.
This control partially overlaps ISM-1604.
ISM-1604 requires restricting access to the administrative interface used to manage the isolation mechanism, reducing who can administer the hypervisor/virtualisation layer. Annex A 8.2 supports this by requiring privileged access rights to be restricted and managed, which is the governance mechanism that should determine and enforce who may administer the isolation mechanism. ISM-1604 is more prescriptive about hardening the isolation mechanism itself, while Annex A 8.2 focuses on privileged access allocation and control.
This control partially overlaps ISM-1614.
ISM-1614 mandates changing break glass credentials after emergency access to mitigate credential exposure risk. Annex A 8.2 relates by requiring restricted and managed privileged access rights, which include managing break glass accounts.
This control partially overlaps ISM-1706.
Annex A 8.2 requires privileged access rights to be restricted and managed to prevent misuse of elevated permissions. ISM-1706 relates by limiting what privileged user accounts can do with backups, specifically preventing access to their own backups (except backup administrators), which constrains a sensitive privileged capability. ISM-1706 is a narrow control focused on backup access restrictions, while Annex A 8.2 covers privileged access rights across all resources and administrative activities.
This control partially overlaps ISM-1932.
Annex A 8.2 requires privileged access rights to be restricted and managed to reduce the risk of misuse or compromise. ISM-1932 relates by requiring minimisation of service accounts configured with SPNs in Active Directory, which directly constrains a common form of privileged or high-impact authentication configuration. ISM-1932 is narrower and technology-specific (AD SPNs/service accounts), while Annex A 8.2 applies to privileged access rights more generally across systems and platforms.
This control supports ISM-0078.
ISM-0078 requires that systems handling AUSTEO/AGAO data remain under the control of an Australian national working for or on behalf of the Australian Government. Annex A 8.2 (Management of Privileged Access Rights) supports ISM-0078 by restricting and managing privileged access so that only appropriately authorised (and, for ISM-0078 purposes, Australian-national) administrators can exercise control over those systems. Annex A 8.2 does not address nationality or sovereign control requirements, but it provides the access-governance mechanism that helps enforce them.
This control depends on ISM-0432.
ISM-0432 requires documenting system access requirements, including for sensitive resources, in a system security plan. Annex A 8.2 requires the allocation and use of privileged access rights to be restricted and managed, which depends on having clear, documented privileged access requirements per system. The ISO control drives operational management of privileged access, whereas ISM-0432 is about ensuring the requirements are formally recorded for that system.
This control depends on ISM-1392.
ISM-1392 requires that only approved users can modify approved files and write to approved folders when path rules are used for application control. Annex A 8.2 focuses on restricting and managing privileged access rights allocation and use. ISM-1392 supports Annex A 8.2 by reducing where privileged write/modify rights are effective, but Annex A 8.2 also covers broader privileged access governance beyond file/folder path restrictions.
This control depends on ISM-1565.
ISM-1565 requires annual, tailored privileged user training so administrators and other privileged users understand secure and approved use of elevated access. ISO/IEC 27001:2022 Annex A 8.2 requires privileged access rights to be restricted and managed across their allocation and use. Training mandated by ISM-1565 supports Annex A 8.2 by ensuring privileged users understand processes such as least privilege, approval boundaries, and safe admin practices, but Annex A 8.2 is fundamentally an access-rights governance and control requirement rather than a training requirement.
This control depends on ISM-1948.
ISM-1948 requires CA Certificate Manager approval before enabling certificate templates that let requesters supply SANs, limiting a common path to certificate abuse and privilege escalation. Annex A 8.2 requires privileged access rights to be restricted and managed, which includes administrative capabilities over AD CS, certificate template publishing, and enrolment permissions. ISM-1948 provides a concrete administrative control point that helps manage privileged actions in the PKI/AD CS domain, but Annex A 8.2 is broader and not specific to certificates or SAN handling.
This control depends on ISM-2113.
ISM-2113 requires AI applications to obtain human approval before executing risky actions. Annex A 8.2 restricts and manages privileged access rights, which supports limiting who can approve high-risk AI actions and preventing AI agents from operating with uncontrolled privilege. Annex A 8.2 focuses on privilege allocation and use, while ISM-2113 focuses on enforcing a human approval checkpoint regardless of privilege model.
ASD Essentials for enterprise IT: 7 mappings
- IT.PRO-05.1Restrict administration to dedicated, hardened environments isolated from unprivileged user workloadsBroader than
This control is broader than IT.PRO-05.1.
IT.PRO-05.1 requires administrative activities to be performed only from dedicated, hardened environments that are isolated from unprivileged user workloads. This is a specific restriction on how privileged access rights are used, which Annex A 8.2 requires to be restricted and managed. Annex A 8.2 is broader, also covering the allocation and ongoing management of privileged access rights.
- IT.PRO-05.2Require explicit session establishment and time-bound grants for privileged actionsBroader than
This control is broader than IT.PRO-05.2.
IT.PRO-05.2 requires explicit session establishment controls before privileged actions are permitted, including time-bound privilege grants. This is a specific way of restricting and managing the use of privileged access rights, as Annex A 8.2 requires. Annex A 8.2 is broader, also covering who is allocated privileged access rights and how those rights are managed.
- IT.PRO-12.2Restrict account and role management and privileged functions to authorised administrative rolesBroader than
This control is broader than IT.PRO-12.2.
IT.PRO-12.2 requires that only authorised administrative roles are given permissions to create, modify or delete accounts and roles, and to access privileged functions or applications. This is a specific restriction on the allocation of privileged access rights, which Annex A 8.2 requires to be restricted and managed. Annex A 8.2 is broader, also covering how the use of privileged access rights is managed over time.
- IT.PRO-01.1Design systems with telemetry, least privilege, data protection and minimal attack surfacePartially overlaps
This control partially overlaps IT.PRO-01.1.
IT.PRO-01.1 requires systems to be designed securely, including minimising required and default privileges alongside enforcing authorised access, protecting data and reducing exposed services and functionality. Its privilege minimisation outcome overlaps directly with ISO/IEC 27001 Annex A 8.2, which requires the allocation and use of privileged access rights to be restricted and managed. IT.PRO-01.1 applies least privilege at design time as one of several secure design outcomes, while Annex A 8.2 governs the ongoing allocation and use of privileged access rights.
- 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 in line with current roles, duties and business requirements. Applied to privileged accounts, this review is part of restricting and managing privileged access rights under Annex A 8.2. IT.PRO-12.1 also covers non-privileged access, while Annex A 8.2 goes further on privileged access, including how such rights are allocated and how their use is controlled.
- 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 needed for defined operational functions. For administrative accounts this restricts the allocation of privileged access rights, which is central to Annex A 8.2. IT.PRO-12.3 applies least privilege to every account type, while Annex A 8.2 focuses on privileged access and also covers managing its use.
This control depends on IT.PRO-05.3.
IT.PRO-05.3 requires all administrative or management actions that modify systems, configurations or controls to be recorded with the associated user, timestamp and target. Recording administrative actions provides accountability for the use of privileged access, which supports the management of privileged access rights under Annex A 8.2. Annex A 8.2 focuses on restricting and managing privileged access rights, while IT.PRO-05.3 addresses only the recording of administrative activity.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.
Get help with this control
ISO 27001 training
Mindset Cyber runs PECB-accredited ISO/IEC 27001 training that maps directly to the controls in this library.