A.8.2 Privileged access rights: requirements and evidence

What ISO 27001 A.8.2 privileged access rights asks for

ISO/IEC 27001:2022 control A.8.2 Privileged access rights requires the organization to restrict and manage how privileged access rights are allocated and used, so that only authorized users, software components and services hold them. In practice, an auditor will expect a documented decision about who may hold administrative rights on each system, a way to grant and withdraw those rights, and proof that privileged rights are used only for their intended purpose. The control covers far more than a short list of domain administrators. It reaches database owners, cloud tenant administrators, network device accounts, CI/CD service accounts and the API keys that automated jobs use to change production.

The risk is access that outlives its need. Standing administrative rights, where an engineer keeps domain admin or root permanently rather than when a task requires it, widen the damage from a single phished password. Shared administrator accounts make it impossible to tell who did what. Access also accumulates: people move teams, keep the rights from earlier roles and never lose them. Legacy systems are the usual obstacle, because older applications often have a built-in admin account with no individual identity, and nobody is clearly the owner of the admin roles on a platform that several teams operate. Confirm, for each critical system, who approves privileged grants and who reviews them, before the audit asks.

A workable first step is an inventory of privileged accounts across identity providers, directories, cloud consoles and key applications, followed by a rule that each administrator uses a separate, named admin identity for privileged work. Ask your certification body or auditor which evidence they expect for this control, since the ISO/IEC 27002:2022 guidance describes the intent but leaves the implementation to you. The organization owns the decision, and an implementation partner can help build the inventory and the approval workflow, but only the independent auditor will judge whether the control works.

Which accounts, systems and third parties fall under A.8.2

A.8.2 applies to every privileged path inside the ISMS scope, not only the domain administrator group. The organization decides the boundary in its scope statement and Statement of Applicability, then evidences each privileged path that falls inside it, including the accounts that act without a person behind them.

Cloud consoles and tenant roles

Owner, global administrator and billing roles in cloud consoles often sit outside the directory that staff normally use, so they are easy to miss. List every tenant, subscription and project in scope, then record who holds top-level roles and whether those roles are assigned to named individuals or granted through groups. Check that root or break-glass credentials are stored under dual control and that each use is logged.

Directories and identity providers

Domain administrators, directory schema administrators and identity provider administrators can change access for the whole estate, which makes them the highest-impact accounts in the scope. Confirm which directory services and identity providers are in scope, who belongs to each administrative group, and whether delegated administration is limited to specific organizational units. Review these memberships on a fixed schedule and keep the evidence.

Hypervisors, databases and network devices

Hypervisor management consoles, database superuser accounts and network device administrator logins each form a separate privileged path that an assessor may sample. Inventory the local and shared accounts on each platform, identify which are used by people and which by automation, and confirm that interactive administration goes through an approved route. Shared accounts that cannot be tied to one person are a common finding and need either retirement or compensating controls.

Service accounts and automation identities

Service accounts, API tokens and workload identities run without a person at the keyboard, yet many hold broad rights. Decide which of them count as privileged, record their owners, and state how their credentials are issued, rotated and revoked. An assessor will ask who approved each one and whether its scope matches its job. Include automation that changes production systems, since its rights are still privileged even when no one logs in.

CI pipelines and deployment runners

Continuous integration and deployment pipelines often hold credentials that can push code, change infrastructure or read secrets. Map which pipeline jobs run with elevated rights, which runners execute them, and who can change pipeline definitions. Changes to those definitions can grant access as effectively as a new administrator account, so approvals and logs for pipeline configuration belong in the evidence set.

Vendor and contractor administrators

Managed service providers, software vendors and contractors who administer systems in scope hold privileged access that the organization does not directly control. Name each external party in the SoA's supplier arrangements, record the accounts they use, and confirm how access is requested, time-limited and removed when the engagement ends. Contracts should state what evidence the supplier provides, since the organization remains responsible for the access its suppliers hold.

How assessors test privileged access rights

This table walks through each test an auditor typically performs for A.8.2, the evidence requested for it and the findings that appear most often. Use it to check your own privileged access records before an assessment, since gaps in approvals, separation or review records are where audits usually stall.

Test area	What the assessor does	Evidence requested	Common findings
Privileged account sample	Selects a sample of administrative, root, domain and cloud owner accounts and checks each one against the directory and platform admin lists	Exported lists of privileged accounts and groups with dates, owners and status, taken from the source systems	Accounts that exist in platforms but not in the register, or the reverse
Allocation approvals	Traces each sampled grant back to a request and an approver with authority over the system	Access requests, tickets or workflow records showing business reason, approver and grant date	Grants with no approval, or approvals given by the person receiving the rights
Separate admin accounts	Checks whether administrators use a dedicated privileged identity for admin work and a standard account for everyday tasks	Naming convention, account pairs, and logs showing which identity performed admin actions	Administrators who carry out routine email or browsing under their admin identity
Time-limited elevation	Tests whether elevated rights are granted for defined windows and removed afterwards, where the organization uses this model	Elevation request and approval logs, session start and end times, and removal records	Standing elevation that never expires, or elevation sessions with no recorded justification
Dormant privileged accounts	Compares last logon or last use data for privileged accounts against the organization's inactivity rule	Last-use reports, and the decision recorded for each account that exceeds the rule	Admin accounts unused for long periods that remain enabled with no owner
Periodic access review	Confirms that reviewers examined privileged rights at the set interval and decided to keep, change or revoke them	Review campaign records, reviewer names, decisions, and evidence of revocations carried out	Reviews that were planned but never recorded, or reviews that approved everything without changes
Monitoring of privileged use	Samples logs to check that privileged sessions and changes are attributable to a named person	Audit log extracts for privileged actions, linked to individual identities	Shared administrator accounts where actions cannot be traced to one person

Implementing A.8.2 in a sequence that produces evidence

The sequence below moves from knowing which privileged rights exist to showing, with dated records, that each right was granted, used and reviewed under an owner's decision. Each step names the artifact an assessor can sample.

Inventory privileged roles and accounts
Build a complete list of every role, group, account and service identity that carries administrative or elevated rights across cloud consoles, operating systems, directories, databases, network devices and business applications. Include break-glass accounts and service accounts, since assessors often find these outside the main directory. Pull the lists from the systems themselves rather than from memory or old spreadsheets, and record the source and date of each extract. The output is a role register with one row per privileged right, its system, its holders and whether it is shared. The step is done when someone outside the project can reproduce the list from the stated sources.
Assign a named owner to each role
Give every entry in the register a single accountable owner, usually a system or business owner who can decide whether the right is still needed. Owners approve requests, confirm holders during reviews and answer for misuse. Record the owner, their deputy and the date of assignment in the register. Where a role has no clear owner, treat that as a finding to resolve before any elevation is granted, because an unowned privilege cannot be reviewed. The output is the register with an accountable owner on each line and a signed acceptance from each owner that they understand the duty.
Define approval and allocation rules
Write the rules for who may request each privileged role, who approves it, what justification is required and how long the grant may last. Separate the duties so that the person who requests a privilege is not the sole approver of it, and tie approval to the role owner's decision. Describe how emergency access is requested, approved after the fact and withdrawn. Keep the rules in the access control policy so that they are version controlled. The output is the approved rule set and a sample of approval records showing the request, the decision, the approver and the timestamp for each grant.
Separate administrative accounts from daily accounts
Require administrators to use a dedicated privileged account for administrative work and a standard account for email, browsing and routine tasks. Name privileged accounts so that they are easy to identify in logs, and block them from interactive use of general productivity tools where the platform allows. Remove standing administrative rights from everyday accounts. Confirm the change system by system, because some legacy applications still assume one identity. The output is a list of administrative accounts mapped to their named holders, plus configuration evidence showing that daily accounts no longer hold the rights.
Introduce time-limited elevation where feasible
For roles that do not need standing rights, move holders to just-in-time elevation, where a privilege is granted for a defined period after approval and then expires. Where a platform cannot do this, record the reason, document the compensating control, such as tighter logging or more frequent review, and add the system to the review schedule. Confirm with each platform vendor what its elevation features support before committing to a design. The output is the elevation configuration, the list of systems where standing rights remain with recorded reasons, and logs showing that elevations were granted and expired.
Log and monitor privileged activity
Turn on logging for privileged sign-ins, role changes, elevation events and high-impact administrative commands, and send them to a central store that administrators cannot quietly edit. Link each logged action to the named account and, where possible, to the approval record that authorized it. Set up alerts for unexpected privilege grants and for use outside approved windows. The output is a sample of privileged events traced from an approval record to a logged action, which shows an assessor that the control operates and not just that it is documented.
Schedule periodic reviews and record decisions
Run access certification campaigns at a set interval that the organization defines in its policy. Each designated reviewer decides whether every privileged holding should be kept, changed or revoked, and the decision is recorded with a reason. Revoked rights are removed and the removal is verified in the system. Discrepancies between the register and the systems are investigated and logged. The output is a signed review decision for each role, the evidence that revocations were carried out, and the list of exceptions with their approvers. This closed loop is what turns the register into assurance.

Evidence that passes A.8.2 privileged access audits

An assessor testing A.8.2 Privileged access rights looks for a complete, current picture of who holds elevated rights, why they hold them and how that use is recorded and reviewed. The cards below cover the artifacts that tie those facts together, along with the refresh cadence and sign-off each one needs between audits.

Privileged role register

A register lists every role, group or permission set that grants privileged capability, such as domain administration, database owner, cloud root or firewall change rights. For each entry, record the system, the scope of the rights, the business owner and the approver. Assessors use it as the baseline, so check that it matches what the directory and cloud IAM actually grant, not only what the policy describes. Refresh it whenever a new system is onboarded and export it at least quarterly, signed by the system owner.

Approval records for elevation

Each grant of a privileged right should trace to a request that names the person, the right, the reason, the duration and an approver who is not the requester. Keep the ticket or workflow record with its timestamps. Check a sample of recent grants against the register: a privileged account without a matching approval is the first finding most assessors raise. Ask your team to confirm whether approvals are stored in the directory, the ticketing system or both.

Admin account inventory with owners

List every administrative account, including named admin accounts, service accounts and break-glass accounts, with a named human owner and a purpose. Shared or orphaned administrative accounts are hard to justify because nobody can answer for their use. Reconcile the inventory against directory exports each month, and have the owner of each account confirm it is still needed. Retain the reconciliation output as evidence of ongoing management.

Separation of admin and daily accounts

Assessors look for evidence that privileged work happens under separate accounts from everyday email and browsing. Show the naming convention, the list of users with a separate admin identity and the policy that forbids using admin accounts for routine tasks. Sample a few admins and confirm their administrative sessions originate from the controlled path your policy defines, not from their standard workstation session.

Elevation and privileged session logs

Logs show when privileged rights were used, by whom, on which system and what changed. Collect authentication events, role assignment changes, sudo or elevation records and privileged session recordings where your tooling provides them. Forward them to a central store with protected retention, so administrators cannot alter their own trail. Ask your team to confirm that the retention period in the logging design matches the period your policy commits to.

Signed periodic review records

A periodic review is the evidence that rights are still justified. For each privileged role, a designated reviewer records a decision to keep, change or revoke every assignment, with a date and signature. Access certification campaigns in tools such as midPoint can produce these records, and the decisions and revocations should appear in the logs. Assessors check that reviews happened on schedule, that revocations were actually executed and that reviewers were not reviewing their own access.

Open-source tools that produce A.8.2 evidence

midPoint is an identity governance and administration platform licensed under EUPL-1.2+. Its access certification campaigns put designated reviewers in front of access items, such as role assignments, and ask them to decide within a set timeframe whether to keep, change or revoke each one. For A.8.2, this matters because privileged rights tend to accumulate over time, and a periodic review gives the organization a documented decision on who still needs administrative access and why.

Campaign records: Each campaign run can show who was reviewed, which items were in scope, who decided and when.
Revocation decisions: Items marked for removal produce a traceable record that the access was taken away, which is the evidence an assessor samples.
Designated reviewers: Assigning privileged roles to a named reviewer, separate from the administrator, supports segregation of duties.
Scope selection: Campaigns can be aimed at administrative roles specifically, so the review population matches the privileged access inventory.
Reporting: Confirm which report formats and exports your version produces, since the review file itself is what goes into the evidence folder.

The EUPL-1.2+ license permits use without a license fee, but the cost of configuring, integrating and running campaigns sits with the implementing team. Confirm capabilities, supported versions and export formats in your own environment before scoping the work.

What meeting A.8.2 costs in money and effort

This table breaks down the cost components of meeting A.8.2 Privileged access rights, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No figures are given because none were supplied, so use the drivers and quote questions to compare written proposals. The main takeaway is that role design and recurring access reviews usually cost more over time than the tooling itself.

Cost component	One-time or recurring	Who is paid or who spends effort	Drivers and what to ask for in a quote
Tooling and licenses	Recurring if commercial, one-time setup otherwise	Software vendor or the organization's own team	Self-hosted open-source directory and identity tools such as FreeIPA or authentik may remove license spend, but hosting, patching and support still apply. Ask whether the quote includes licenses, hosting and upgrades separately.
Role design and admin account separation	One-time, with periodic revision	Implementation partner and internal IAM or platform engineers	Driven by the number of systems, existing role sprawl and how many admin groups exist today. Ask for a written inventory of privileged roles and the agreed separation model.
Time-limited elevation workflows	One-time build, recurring operation	Platform engineers and service desk staff	Cost rises with the number of approval paths and emergency access procedures. Ask how break-glass access is designed, logged and reviewed.
Access certification campaigns	Recurring, usually on a set schedule	Designated reviewers, managers and system owners	Effort grows with the count of privileged assignments and the number of reviewers. Ask what the campaign produces: decisions, revocations and retained evidence.
Evidence upkeep	Recurring	Internal control owner, sometimes supported by a partner	Driven by how automatically logs, group membership exports and approval records are captured. Ask which evidence is generated by the system and which must be collected by hand.
Technical testing of privileged access	Recurring or periodic	Independent security testers or internal red team	Scope depends on how many admin paths exist across cloud, directory and network systems. Ask which privilege escalation paths are in scope and what retesting is included.
Auditor sampling effort	Recurring at each audit cycle	Certification body auditors, with staff time from the organization	Auditors sample privileged accounts and their approvals. Cleaner records and a current register of admin accounts reduce sampling and follow-up questions. The certification body sets its own fees, so ask it directly.
Organization-owned decisions	Recurring	The organization's leadership and control owners	The organization owns the access policy and risk acceptance. An implementation partner can prepare systems and evidence, but cannot make these decisions or issue any assurance.

Who does what for A.8.2: your team, a partner and the auditor

Your organization owns the control. A.8.2 asks that privileged access rights are restricted and managed so that only authorized users, software components and services hold them, and deciding who qualifies is a management responsibility that cannot be delegated to an outside party. Your security and IT leaders define what counts as privileged in your environment, approve each grant, and make the periodic review decisions that keep or remove rights.

Role definitions: Write down which roles, groups and system accounts carry administrative rights, and what each one may do.
Approvals: Record who authorized each elevation, when, and for what business reason.
Separate admin accounts: Decide when administrators use a dedicated privileged identity instead of their everyday account.
Review decisions: Name the reviewers, set the review frequency, and keep, change or revoke each right with a documented reason.
Policy and procedure: Maintain the access control policy that the Statement of Applicability refers to for this control.

Before engaging anyone, confirm that you can name the owner of each privileged role and show a review record signed by someone with the authority to revoke access.

Common A.8.2 gaps and how to close them

Auditors testing A.8.2 usually find the same few weaknesses: privileged access that was granted for a reason and never revisited, accounts nobody owns, and reviews that happen on paper only. The cards below cover the gaps we see most often, what an assessor will look for, and the practical fix for each.

Shared administrator accounts

When several engineers log in with one root or domain admin account, the log shows only that the account was used, not who used it. An assessor will ask how each privileged action traces to a named person. Fix it by issuing a separate, named administrative account to each person who needs one, keeping daily work on a standard account, and requiring individual sign-in to administrative consoles. Check whether any shared credential still exists in a password vault or runbook.

Admin rights granted and never removed

Administrative rights are often added for a migration, an incident or a contractor and then left in place. Over time this produces access accumulation that no one can explain. Fix it by attaching an end date or review trigger to every elevation and by removing rights when the task closes. Compare current group memberships with the approved list at least once a quarter and record what was removed.

No owner for privileged roles

A privileged role with no named owner has no one to approve new members, answer for its use or decide when it should be retired. Assessors look for a documented owner per role or system and evidence that the owner approved the current membership. Fix it by maintaining a register of privileged roles, each with an accountable owner, the approval rule for joining it and the systems it controls.

Service accounts with standing rights

Service accounts and automation credentials often hold broad rights that never expire and whose passwords rarely change. Because no person signs in with them, they escape review. Fix it by inventorying every service account, scoping each to the operations it performs, assigning an owner, and rotating its secret on a defined schedule. Confirm whether the account can be used interactively and disable that path where it is not needed.

Reviews without recorded decisions

Access reviews that end in a meeting or an email thread without a decision for each item do not show that anyone checked anything. An assessor will ask for the reviewer, the date, each access item and whether it was kept, changed or revoked. Fix it by running reviews as campaigns in which a named reviewer must decide on every item within a set timeframe, and by keeping the exported decisions as evidence. Access certification features in tools such as midPoint support this pattern.

No link between HR offboarding and access removal

When an employee or contractor leaves, privileged access often survives because the HR ticket never reaches the team that removes accounts. Fix it by triggering deprovisioning from the same source that records departures, and by testing that a leaver loses administrative access from every connected application. Keep the removal timestamps. Connectors such as the authentik SCIM provider can push deletions to target applications, but you should confirm how each application handles them.

Questions buyers ask about A.8.2 before hiring help

How much effort does A.8.2 privileged access take to implement?

The effort depends mostly on how many privileged accounts, systems and administrator groups exist today and how many of them are shared or undocumented. A.8.2 asks that the allocation and use of privileged access rights are restricted and managed, so the work covers inventorying who holds admin rights, separating administrator accounts from everyday accounts, approving new grants and reviewing them on a schedule. A small environment with a few systems and one identity source is far quicker to bring under control than a estate with local admin rights on every laptop and server. No fixed effort figure is supplied for this control, so ask any partner to estimate from your own inventory and to state the assumptions in a written scope before work starts.

How long does a privileged access project usually run?

Duration follows the same drivers as effort: the size of the estate, the number of identity sources, whether approval workflows already exist and how much change the administrators will accept. Most projects move through a discovery phase, a design phase for roles and approvals, a rollout phase for separate admin accounts and time-limited elevation, and a first review cycle that produces evidence. No duration is supplied for this topic, so treat any timeline you receive as provisional until the inventory is complete and the deliverables are listed in the written scope.

What does the work need from our administrators and control owners?

The work needs named owners who can decide which roles exist, who may hold them and how long elevation may last. Administrators must agree to use separate accounts for privileged tasks and to request elevation through the approved path. Control owners must confirm the access review cadence and sign off on exceptions. Expect the first weeks to involve workshops and review of current role assignments, not only configuration changes. Ask your provider to list these owners and the hours they are expected to give in the scope document.

Can a small team implement A.8.2 without outside help?

A small team can implement A.8.2 alone if it has one person who understands the identity platform, a short list of systems, and time to write the procedure and run the first review. The harder parts are usually consistency across systems and keeping evidence over time. Teams that run their own identity platform often find the initial design manageable but struggle to run periodic reviews and produce records when an auditor asks. Decide early which tasks stay internal and which need a second pair of hands.

Which parts of A.8.2 are worth outsourcing?

Outside help is most useful for the parts that need experience across many systems: designing the role model, configuring a self-hosted identity platform, wiring provisioning and deprovisioning, and setting up access certification campaigns in a tool such as midPoint. The organization should keep the decisions that define its risk, namely who may hold privileged rights, the approval rules and the review decisions. Ask for the deliverables in writing, including the procedure, configuration records and the evidence set your auditor will expect.

Can an implementation partner sign off that A.8.2 is met?

No. An implementation partner prepares systems, configuration and evidence, but the organization owns its controls and only an independent auditor or certification body can issue an audit result or certificate. DeployOpen operates on this basis: it prepares the systems and evidence for an assessment, and the assessor decides whether the control is met. Before hiring anyone, confirm in writing that the provider does not claim to certify or attest the control, and ask who will test the evidence independently.

What should we ask for in a written quote for A.8.2 work?

Ask for a scope that lists the systems in scope, the identity sources, the roles to be designed, the number of review campaigns and the evidence each deliverable produces. Request the assumptions behind any effort figure and the responsibilities of your own staff. Confirm what happens after handover, including whether ongoing reviews, upgrades or retesting are covered by a separate retainer. DeployOpen does not publish a price list, so a quote follows from the written scope you agree.

How DeployOpen scopes and prepares A.8.2 evidence

DeployOpen works on A.8.2 inside the client's own infrastructure, so the organization keeps ownership of its controls, its privileged accounts and its evidence. We plan, build, document and hand over the privileged access setup, while the organization decides who holds administrative rights and an independent auditor or certification body issues any report or certificate.

How we scope

Agree in writing which systems, directories, cloud accounts and administrative tools fall under the privileged access review.
Inventory existing administrator groups, shared accounts and standing elevated roles before any change is proposed.
Confirm with the organization who approves privileged access requests and who performs the periodic reviews.

How we build

Configure separate administrative accounts so daily work and privileged work do not share one identity.
Set up time-limited elevation and group-based delegation in the directory, using tools such as FreeIPA where it fits the environment.
Configure access certification campaigns in a tool such as midPoint so designated reviewers keep, change or revoke privileged assignments on a set schedule.

How we hand over

Deliver written procedures for granting, using, reviewing and removing privileged access, mapped to the organization's own control text.
Provide logs and review records that show who held privileged rights, when they were used and when they were withdrawn.
Document the evidence set and its location so the organization's internal audit or external auditor can test A.8.2 directly.

How we support

Ongoing support, upgrades and continuous testing of the privileged access setup are available as a retainer.
Retesting after platform upgrades or organizational changes, such as new administrators or cloud accounts, can be added to the retainer scope.
Engagements are fixed-scope, so any change to the privileged access scope is agreed in writing before work starts.