ISO 27001 Annex A 8.2 Privileged Access Rights

Home / ISO 27001 Annex A Controls / ISO 27001 Annex A 8.2 Privileged Access Rights

ISO 27001 Privileged Access Rights

I am going to show you what ISO 27001 Annex A 8.2 Privileged Access Rights is, what’s new, give you ISO 27001 templates, show you examples, do a walkthrough and show you how to implement it. I show you exactly what changed in the ISO 27001:2022 update and exactly what you need to do for ISO 27001 certification.

What is ISO 27001 Annex A 8.2?

ISO 27001 Annex A 8.2 Privileged Access Rights is an ISO 27001 Annex A control that wants you to make sure you have controls in place to manage privileged access rights.

Purpose

The purpose of ISO 27001 Annex A 8.2 Privileged Access Rights is to ensure only authorised users, software components and services are provided with privileged access rights.

Definition

The ISO 27001 standard defines ISO 27001 Annex A 8.2 as:

The allocation and use of privileged access rights should be restricted and managed.

ISO 27001:2022 Annex A 8.2 Privileged Access Rights

Implementation Guide

General Guidance

Privileged access is the access that people, software or services have that allows them to do things that normal users cannot do and that could cause the most harm. This level of access is used to manage and configure systems and to allow people to perform administrative tasks. We need people to have this level of access but we do not want everyone to have it. The risk of granting this level of access to someone that doesn’t know what to do with it or should not have it is that they could break something, stop something working or carry out activities that are, shall we say, bad.

Your starting point for this control is to implement a topic specific policy on access control and include in that policy your approach to privilege access. The ISO 27001 Access Control Policy Template is already written for you and ready to go and includes a great free Access Control Policy Example PDF.

When implementing this control use common sense and be practicable. We are working here on the principle of segregation of duty. We do not want the person with the access to authorise the access and where possible the person with access should not have conflicting access. Rather, separate out your privilege accounts logically where it makes sense and you are able to do so. An example would be to separate out those with the access to the databases from those with access to the logging and monitoring. This prevents things like that ability to do something then change the logs to cover it up.

I find the use of role based access as a technique is a great tool here. Understanding what roles you need, defining them and then allocating people to roles based on need.

Authorisation Process

Implement a process of authorisation that separates those requiring access from those that grant it. Keep a record of all accounts with privilege access. Consider placing time limits on their use or allocating expiry dates.

Review Access Requirements

Regular reviews of people’s access should form part of your normal operating rhythm. This also applies to privilege accounts. A process to check who has what and if they still need it.

Use of privilege accounts

Ideally we want a situation where privilege accounts are only used when needed to perform privileged actions and normal accounts are used in normal day to day operations for the user. It doesn’t have to be this, as this is best practice, but the ideal is some way to distinguish when the user is in privilege mode. It will reduce the likelihood of an information security incident.

This level of account really should be logged and monitored for audit purposes.

Generic accounts

You should really discourage the use of generic administrative accounts. We want to be able to tie actions back to an individual. If you simple have to have a generic account then my recommendation is to manage it as an exception and record it in the risk register. Mange it via risk management, even if that is accepting the risk.

ISO 27001 Templates

ISO 27001 templates have the advantage of being a massive boost that can save time and money so before we get into the implementation guide we consider these pre written templates that will sky rocket your implementation. This ISO 27001 Toolkit has been specifically designed so you can DIY your ISO 27001 certification, build your ISMS in a week and be ISO 27001 certification ready in 30 days.

DO IT YOURSELF ISO 27001

All the templates, tools, support and knowledge you need to do it yourself.

ISO 27001 Toolkit Business Edition

How to pass an audit

Time needed: 1 day

How to comply with ISO 27001 Annex A 8.2

  1. Have policies and procedures in place

    Write, approve, implement and communicate the documentation required for privileged access rights.

  2. Assess your privilege use requirements and perform a risk assessment

    Identify what your requirements are for privileged access and then perform a risk assessment.

  3. Implement controls proportionate to the risk posed

    Based on the risk assessment implement controls proportionate that risk assessment and the needs of the business.

  4. Keep records

    For audit purposes you will keep records. Examples of the records to keep include changes, updates, monitoring, review and audits.

  5. Test the controls that you have to make sure they are working

    Perform internal audits that include the testing of the controls to ensure that they are working.

Top 3 Mistakes People Make

The top 3 mistakes people make for ISO 27001 Annex A 8.2 are

1. Having generic accounts

Having generic accounts is not always a bad thing but having them because you are lazy is. Try to eliminate them and where you do require them manage via risk management. This means recording them on the risk register and managing the risk, even if managing the risk is accepting the risk and recording the decision.

2. Laptop Administrator Accounts

This common mistake actually relates to end points and the default position of providing all users administrative control over those devices by default. Again, this is usually lazy management and again, as above, if required manage it via risk management. Auditors check and will want a justification and don’t just do it because it is easy or you have always done it. This level of access really does negate a lot of the end point controls that you are going to rely on.

3. Your document and version control is wrong

Keeping your document version control up to date, making sure that version numbers match where used, having a review evidenced in the last 12 months, having documents that have no comments in are all good practices.

ISO 27001 Controls and Attribute Values

Control typeInformation
security properties
Cybersecurity
concepts
Operational
capabilities
Security domains
PreventiveConfidentialityProtectIdentity and access managementProtection
Integrity
Availability