What is ISO 27001 Annex A 8.2 – Privileged Access Rights?

ISO 27001 Annex A 8.2 focuses on managing privileged access rights so that powerful administrative or elevated permissions are granted only when necessary, controlled appropriately, and regularly reviewed.

Privileged access is access that allows a user or account to perform actions beyond those available to a normal user.

Examples include the ability to:

Create or delete user accounts
Change security configurations
Modify production systems
Access databases
Change firewall rules
Manage cloud infrastructure
Install system software
Disable security controls
Change access permissions
View highly sensitive information
Modify system configurations
Manage encryption keys
Change audit or logging settings

Common privileged accounts include:

System administrators
Cloud administrators
Database administrators
Network administrators
Security administrators
Domain administrators
Root accounts
Cloud root/owner accounts
Application administrators
Infrastructure administrators
DevOps/SRE administrators

Simple explanation: Give powerful access only to people who need it, only for the required purpose, and make sure that access is controlled, monitored, and reviewed.

Why is ISO 27001 Annex A 8.2 Important?

Privileged accounts can make significant changes to an organization’s technology environment.

If a privileged account is compromised, misused, or incorrectly configured, the impact can be much greater than the compromise of a normal user account.

Example

A normal employee account may allow access to:

Email
HR portal
CRM

A cloud administrator account may allow access to:

Production infrastructure
Databases
Storage
Network configurations
Security settings
Customer environments

The second account therefore requires stronger controls.

Common risks

Risk	Example
Excessive privileges	Developer has unrestricted production access
Shared admin account	Multiple people use one root account
Stale privileges	Former administrator retains access
Credential theft	Admin password stolen through phishing
No MFA	Privileged account protected only by password
Permanent privilege	Admin access remains active all the time
Unauthorized changes	Admin modifies production without approval
Poor monitoring	Privileged activity is not logged
No review	Access rights are never periodically reviewed
Emergency access abuse	Break-glass account used without investigation

Simple principle: The more powerful the access, the stronger the controls should be.

What Does Annex A 8.2 Require?

Organizations should restrict and control the allocation and use of privileged access rights.

The organization should establish appropriate controls for:

Identifying privileged accounts
Defining privileged roles
Authorizing privileged access
Limiting privileges
Using separate administrative accounts where appropriate
Strong authentication
Monitoring privileged activity
Logging privileged actions
Periodic access reviews
Removing unnecessary privileges
Emergency or break-glass access
Managing privileged credentials
Protecting administrative sessions
Controlling third-party privileged access

The objective is not to eliminate privileged access.

Organizations need administrators.

The objective is to ensure that privileged access is:

Necessary → Authorized → Limited → Protected → Monitored → Reviewed → Removed when no longer required

What is Privileged Access?

Privileged access is access that provides elevated capabilities compared with ordinary users.

Examples

A user who can:

Create other users
Delete accounts
Change permissions
Modify firewall rules
Access production databases
Deploy production applications
Change cloud infrastructure
Disable security controls
Modify logging
Access encryption keys

may have privileged access.

Types of Privileged Accounts

Type	Example
Operating system administrator	Windows Administrator
Linux administrator	Root / sudo
Database administrator	PostgreSQL/MySQL admin
Network administrator	Firewall administrator
Cloud administrator	AWS/Azure/GCP administrator
Identity administrator	Microsoft Entra/Google Workspace admin
Security administrator	SIEM/EDR administrator
Application administrator	SaaS platform admin
DevOps administrator	CI/CD or infrastructure administrator
Emergency account	Break-glass account

Not every organization will have all of these.

The organization should identify the privileged accounts that actually exist in its environment.

Normal Access vs Privileged Access

Normal User	Privileged User
Reads email	Creates email accounts
Uses CRM	Changes CRM permissions
Uses application	Changes application configuration
Reads approved documents	Changes document permissions
Uses SaaS platform	Administers SaaS platform
Uses workstation	Changes system configuration
Uses AWS application	Modifies AWS infrastructure

The distinction should be based on what the account can actually do, not simply on the person’s job title.

Activities Required to Implement A.8.2

1. Identify Privileged Accounts

Start by identifying all accounts with elevated permissions.

This may include:

Cloud admin accounts
Domain admin accounts
Database admin accounts
Network admin accounts
Security admin accounts
Application admin accounts
Root accounts
Service accounts with administrative privileges
Emergency accounts

Do not assume that only IT employees have privileged access.

A developer, DevOps engineer, security analyst, or application owner may also have elevated privileges.

2. Create a Privileged Access Register

A simple register can provide strong governance.

Account	System	Privilege	Owner	Approval	MFA	Review
admin01	AWS	Administrator	IT Lead	CTO	Yes	Quarterly
sec-admin	EDR	Security Admin	Security Lead	CISO	Yes	Quarterly
db-admin	Production DB	DBA	DevOps	CTO	Yes	Monthly
gs-admin	Google Workspace	Super Admin	IT	CTO	Yes	Quarterly

The exact fields can be adapted to the organization’s environment.

3. Define Which Roles Need Privileged Access

Not every technical employee needs full administrator rights.

For example:

Developer

May need:

Development environment access
Limited production troubleshooting

May not need:

Organization-wide identity administration
Billing administration
Full security administration

DevOps Engineer

May need:

Infrastructure management
Deployment permissions

May not need:

HR administration
Finance systems
All employee accounts

This is the principle of least privilege.

4. Use Separate Administrative Accounts

Where appropriate, administrators should use separate accounts for administrative activities.

For example:

Normal account

rahul@company.com

Used for:

Email
Slack
Meetings
Documentation

Administrative account

rahul.admin@company.com

Used for:

Cloud administration
Identity administration
Infrastructure changes

This reduces the chance that an ordinary activity such as browsing the internet or opening an email is performed from a highly privileged session.

The exact implementation should reflect organizational risk and technology.

5. Require Strong Authentication

Privileged accounts should receive stronger authentication protection.

MFA should generally be required for important administrative access.

Where supported, organizations may consider stronger methods such as:

Phishing-resistant authentication
Hardware security keys
Passkeys
Strong authenticator-based MFA

The organization should identify its highest-risk administrative accounts and apply appropriate authentication controls.

6. Restrict Privileged Access to What is Necessary

Avoid giving users unrestricted administrator privileges when narrower permissions are available.

Example

Instead of:

Developer → Full AWS Administrator

Consider whether the person actually needs:

EC2 administration
Specific production deployment permissions
Read-only database access
Limited troubleshooting rights

This can substantially reduce risk.

7. Use Just-in-Time or Temporary Privileged Access Where Appropriate

Permanent administrator access increases the attack surface.

Where technology supports it, organizations can use temporary elevation.

Example:

Developer has normal access

↓

Production issue occurs

↓

Access request submitted

↓

Approval obtained

↓

Administrator privilege enabled for 60 minutes

↓

Required work completed

↓

Privilege automatically removed

This is often called Just-in-Time (JIT) privileged access.

It is not mandatory for every startup, but can be valuable for higher-risk environments.

8. Protect Privileged Credentials

Privileged credentials should receive stronger protection.

Consider:

Password managers
MFA
Secure credential storage
Hardware security keys
Credential rotation
Restricted access
Avoiding credentials in scripts
Avoiding credentials in source code
Secret-management systems
Monitoring for credential exposure

Never store administrator passwords or cloud secrets in:

Git repositories
Public documents
Slack messages
Shared spreadsheets
Unprotected text files

9. Control Root and Emergency Accounts

Cloud and enterprise platforms often have highly powerful accounts.

Examples:

AWS root account
Azure Global Administrator
Google Workspace Super Admin
Domain Administrator
Emergency/break-glass accounts

These accounts should receive additional protection.

Possible controls include:

Strong MFA
Restricted use
Secure credential storage
Monitoring
Emergency-use procedures
Periodic review
Alerting when used

A root account should not become an everyday working account.

10. Monitor Privileged Activities

Privileged activity should be logged and monitored according to risk.

Examples include:

Account creation
Permission changes
Firewall changes
Production deployments
Database access
Security-control changes
Logging changes
Configuration changes
Administrative login events

Monitoring is particularly important for high-risk systems.

11. Review Privileged Access Regularly

Privileged access should not be “set and forget.”

Review:

Who has privileged access?
Why do they need it?
Is the privilege still required?
Is the role still correct?
Has the employee changed roles?
Is the account still active?
Are emergency accounts still required?
Are service accounts still necessary?

Example review cycle

Monthly

Critical production privileges

Quarterly

General privileged accounts

Immediately

Employee termination or role change

The actual frequency should be risk-based.

12. Remove Privileges When No Longer Required

When someone:

Leaves the company
Changes role
Moves to another team
No longer supports a system
Finishes a project

their privileged access should be removed or adjusted.

This connects directly with:

A.5.16 Identity Management
A.5.18 Access Rights
A.6.5 Responsibilities After Termination

13. Control Third-Party Privileged Access

External parties may sometimes require administrative access.

Examples:

MSP
Cloud consultant
Security provider
Software vendor
Managed SOC
Infrastructure consultant

The organization should define:

Why access is required
Who approved it
What systems can be accessed
How long access remains active
Authentication requirements
Monitoring requirements
How access is revoked

Avoid permanent unrestricted vendor administrator access unless there is a justified business and security reason.

14. Manage Service Accounts With Privileged Rights

Not all privileged access belongs to humans.

Applications and automation may have privileged accounts.

Examples:

CI/CD deployment account
Infrastructure automation account
Backup account
Monitoring account
Database service account

These should also be:

Identified
Owned
Limited
Protected
Monitored
Reviewed

A service account with excessive privileges can create significant risk.

Startup Example

Imagine a 50-person SaaS startup using:

AWS
GitHub
Google Workspace
Cloudflare
Production databases
CI/CD
EDR
CRM

The company has:

2 DevOps engineers
1 security lead
1 CTO
50 normal users

Instead of giving all technical employees unrestricted administrative access, the startup creates defined roles.

Example

CTO

→ AWS organization administration

→ Identity administration

DevOps

→ Infrastructure administration

→ Deployment permissions

Security Lead

→ EDR/SIEM administration

→ Security configuration

Developers

→ Development environment

→ Limited production permissions

Employees

→ Standard application access

This creates a much clearer privilege model.

Example Privileged Access Matrix

Role	AWS	GitHub	Google Workspace	Production DB	EDR
CTO	Admin	Admin	Admin	High	Admin
DevOps	Admin	Maintainer	Limited	Admin	Limited
Security Lead	Security Admin	Limited	Security Admin	Read/approved	Admin
Developer	Limited	Developer	User	Limited	User
Employee	No Admin	User	User	No Access	User

The exact permissions should be determined by the organization’s requirements and risk assessment.

Privileged Access Approval Example

A practical approval workflow might be:

Employee needs elevated access

↓

Business/technical justification

↓

System owner reviews

↓

Appropriate manager approves

↓

Security/IT verifies privilege level

↓

Access granted

↓

Activity monitored

↓

Access periodically reviewed

↓

Access removed when no longer required

For temporary access:

Request → Approve → Elevate → Use → Automatically Revoke

Privileged Access Risk Assessment

Threat	Vulnerability	Impact	Control
Credential theft	Admin account lacks MFA	High	MFA
Excessive privileges	Full admin access	High	Least privilege
Stale account	Former admin still active	High	Access review
Shared account	Multiple people use root	High	Individual accounts
Insider misuse	No monitoring	High	Logging/monitoring
Vendor compromise	Permanent vendor admin	High	Temporary/restricted access
Secret exposure	Admin password in source code	High	Secret management
Uncontrolled emergency access	Break-glass account unmonitored	High	Alerting/review
Automation compromise	CI/CD has excessive permissions	High	Least privilege/service-account controls

What Evidence Should an Auditor Expect?

An auditor may request evidence such as:

Privileged Access Governance

Privileged Access Policy
Access Control Policy
Privileged Access Procedure
Privileged Access Register
Role/permission matrix

Access Approvals

Access requests
Manager approvals
System-owner approvals
Temporary access approvals
Third-party access approvals

Technical Evidence

MFA configuration
IAM configuration
Cloud IAM reports
Administrator lists
Privileged group membership
PAM/JIT reports where applicable
Authentication logs
Privileged activity logs

Review Evidence

Quarterly privileged-access review
Access certification records
Removed access records
Exception records

Monitoring Evidence

Alerts for privileged login
Root-account alerts
Administrative activity logs
Security investigations

Audit Checklist for A.8.2

Audit Question	Yes/No	Evidence
Are privileged accounts identified?
Is there a privileged-access register?
Are privileged roles defined?
Is privileged access formally approved?
Is least privilege applied?
Are separate admin accounts used where appropriate?
Is MFA enabled for privileged access?
Are root/emergency accounts controlled?
Are privileged activities logged?
Are privileged activities monitored where appropriate?
Are privileged accounts periodically reviewed?
Are privileges removed after role changes?
Are terminated users removed promptly?
Are third-party privileged accounts controlled?
Are privileged service accounts identified?
Are privileged credentials securely stored?
Are temporary privileges used where appropriate?
Are exceptions documented?
Is privileged access to production controlled?
Can the organization demonstrate a recent access review?

Common Mistakes

1. Giving everyone administrator access

This is one of the most common startup problems.

“We are a small team, so everyone needs admin.”

Usually, the better approach is to determine what each role actually needs.

2. Sharing administrator accounts

For example:

admin@company.com

used by five people.

This makes accountability difficult.

Individual administrative identities are generally preferable.

3. Using the root account for everyday work

Highly privileged root accounts should generally be protected and restricted rather than used for routine activities.

4. No MFA for administrators

A privileged account protected only by a password creates unnecessary risk.

5. Permanent production access

Developers may retain production administrator access long after the original reason disappears.

6. No access review

Organizations sometimes create privileged access but never verify whether it remains necessary.

7. Ignoring service accounts

Automation can have extremely powerful permissions.

Service accounts therefore need governance too.

8. Ignoring third-party administrators

External vendors may have privileged access that is forgotten after a project ends.

9. No monitoring

An organization may control who has access but have no visibility into what privileged users actually do.

10. Putting secrets in source code

Cloud keys, passwords, tokens, and other privileged credentials should not be casually stored in repositories.

Practical Startup Implementation Model

A startup can implement A.8.2 using this lifecycle:

1. Identify

Find all privileged human and service accounts.

2. Define

Define what each privileged role is allowed to do.

3. Approve

Require appropriate authorization.

4. Protect

Use MFA, secure credential storage, and other appropriate controls.

5. Limit

Apply least privilege.

6. Monitor

Log and monitor important privileged activity.

7. Review

Periodically review privileged access.

8. Remove

Remove unnecessary privileges immediately when no longer required.

9. Improve

Use incidents, reviews, and audit findings to strengthen controls.

Simple startup formula:
Identify → Approve → Limit → Protect → Monitor → Review → Remove

Policy vs. Process vs. Evidence

Layer	Example
Policy	Privileged access must be restricted and controlled
Standard	Admin accounts require MFA
Process	New privileged access requires system-owner approval
Technical Control	IAM role restricts permissions
Evidence	IAM report showing assigned privileges
Review	Quarterly privileged-access certification
Exception	Temporary elevated access approved for incident response

The objective is to connect the documented requirement with actual technical implementation.

A.8.2 vs A.5.18 Access Rights

These controls are closely related.

A.5.18 – Access Rights

Addresses the broader lifecycle of access rights.

A.8.2 – Privileged Access Rights

Focuses specifically on elevated or administrative access.

Simple distinction

A.5.18: Who can access what?

A.8.2: Who has powerful administrative access, and how do we control it?

A.8.2 vs A.5.15 Access Control

A.5.15

Establishes the overall access-control principles.

A.8.2

Applies stronger, specific controls to privileged access.

Think of it as:

A.5.15 = Access-control framework

A.8.2 = Elevated-access protection

A.8.2 vs A.8.18 Use of Privileged Utility Programs

These controls are also different.

A.8.2

Controls who receives privileged access rights.

A.8.18

Controls the use of powerful system utility programs that may bypass normal application controls.

Examples of privileged utilities include:

System administration tools
Database administration tools
Network utilities
Security configuration utilities

Both controls can apply simultaneously.

Relationship With Other ISO 27001 Controls

Control	Relationship
A.5.15 Access Control	Establishes access-control principles
A.5.16 Identity Management	Manages identities associated with privileged access
A.5.17 Authentication Information	Protects privileged credentials
A.5.18 Access Rights	Manages access rights lifecycle
A.6.3 Awareness and Training	Educates administrators and users
A.6.5 Responsibilities After Termination	Supports prompt privilege removal
A.6.8 Event Reporting	Supports reporting of suspicious privileged activity
A.8.1 User Endpoint Devices	Protects administrator workstations
A.8.3 Information Access Restriction	Restricts access to information
A.8.5 Secure Authentication	Strengthens authentication
A.8.9 Configuration Management	Helps control privileged configuration changes
A.8.15 Logging	Records privileged activity
A.8.16 Monitoring Activities	Supports detection of suspicious activity
A.8.18 Use of Privileged Utility Programs	Controls powerful administrative utilities
A.8.32 Change Management	Controls significant privileged changes

Useful Resources for A.8.2