ISO 27001 – Annex A.9: Access Control

What is Annex A.9?

Annex A.9 is all about access control procedures. The aim of Annex A.9 is to safeguard access to information and ensure that employees can only view information that’s relevant to their work. This guide will take you through everything you need to know about Annex A.9.

Annex A.9 is divided into four sections and you will need to work through each one. They are Access Controls, User Access Management, User Responsibilities and Application Access Controls.

What is the objective of Annex A.9.1?

Annex A.9.1 is about business requirements of access control. The objective in this Annex A control is to limit access to information and information processing facilities.

It’s an important part of the information security management system (ISMS) especially if you’d like to achieve ISO 27001 certification. Lets understand those requirements and what they mean in a bit more depth.

A.9.1.1 Access Control Policy

An access control policy must be established, documented and reviewed regularly taking into account the requirements of the business for the assets in scope.

Access control rules, rights and restrictions along with the depth of the controls used should reflect the information security risks around the information and the organisation’s appetite for managing them. Put simply access control is about who needs to know, who needs to use and how much they get access to.

Access controls can be digital and physical in nature, e.g. permission restrictions on user accounts as well as limitations on who can access certain physical locations (aligned with Annex A.11 Physical and Environment Security). The policy should take into account:

• Security requirements of business applications and align with the information classification scheme in use as per A.8 Asset Management;
• Clarify who needs to access, know, who needs to use the information – supported by documented procedures and responsibilities;
• Management of the access rights and privileged access rights (more power – see below) including adding, in life changes (e.g. super users/administrators controls) and periodic reviews (e.g. by regular internal audits in line with requirement 9.2.
• Access control rules should be supported by formal procedures and defined responsibilities;

Access control needs to be reviewed based on change in roles and in particular during exit, to align with Annex A.7 Human Resource Security.

A.9.1.2 Access to Networks and Network Services

The principle of least access is the general approach favoured for protection, rather than unlimited access and superuser rights without careful consideration.

As such users should only get access to the network and network services they need to use or know about for their job. The policy therefore needs to address; The networks and network services in scope for access; Authorisation procedures for showing who (role based) is allowed to access to what and when; and Management controls and procedures to prevent access and monitor it in life.

This also needs to be considered during onboarding and offboarding, and is closely related to the access control policy itself.

What is the objective of Annex A.9.2?

Annex A.9.2 is about user access management. The objective in this Annex A control is to ensure users are authorised to access systems and services as well as prevent unauthorised access.

A.9.2.1 User Registration and Deregistration

A formal user registration and deregistration process needs to be implemented. A good process for user ID management includes being able to associate individual IDs to real people, and limit shared access IDs, which should be approved and recorded where done.

A good on-boarding and exit process ties in with A7 Human Resource Security to show quick and clear registration/deregistration along with avoidance of reissuing old IDs. A regular review of ID’s will illustrate good control and reinforces ongoing management.

That can be tied in with the internal audits noted above for access control audits, and periodic reviews by the information asset or processing application owners.

A.9.2.2 User Access Provisioning

A process (however simple and documented) must be implemented to assign or revoke access rights for all user types to all systems and services. Done well it ties in with the points above as well as the broader HR Security work.

Provisioning and revoking process should include; Authorisation from the owner of the information system or service for the use of the information system or service; Verifying that the access granted is relevant to the role being done; and protecting against provisioning being done before authorisation is complete.

User access should always be business led and access based around the requirements of the business. This might sound bureaucratic but it doesn’t need to be and effective simple procedures with role based access by systems and services can address it.

A.9.2.3 Management of Privileged Access Rights

A.9.2.3 is about managing usually more powerful and higher ‘privileged’ levels of access e.g. systems administration permissions versus normal user rights.

The allocation and use of privileged access rights has to be tightly controlled given the extra rights usually conveyed over information assets and the systems controlling them. For example the ability to delete work or fundamentally affect the integrity of the information. It should align with the formal authorisation processes alongside the access control policy.

That could include; system by system clarity on privileged access rights (which can be managed inside the application); allocation on a need-to-use basis not a blanket approach; A process and record of all privileges allocated should be maintained (alongside the information asset inventory or as part of the A.9 evidence; and the competence of users granted the rights must be reviewed regularly to align with their duties.

This is another good area to include in the internal audit to demonstrate control.

One of the biggest contributory factors to failures or breaches of systems is inappropriate and blanket use of system administration privileges with human error leading to more damage or loss than if a ‘least access’ approach were taken.

Other good practice relating to this area includes the separation of the systems administrator role from the day to day user role and having a user with two accounts if they perform different jobs on the same platform.

A.9.2.4 Management of Secret Authentication Information of Users

Secret authentication information is a gateway to access valuable assets. It typically includes passwords, encryption keys etc. so needs to be controlled through a formal management process and needs to be kept confidential to the user.

This is usually tied into employment contracts and disciplinary processes (A.7) and supplier obligations (A13.2.4 and A.15) if sharing with external parties.

Procedures should be established to verify the identity of a user prior to providing new, replacement or temporary secret authentication information. Any default secret authentication information provided as part of a new system use should be changed as soon as possible.

A.9.2.5 Review of User Access Rights

Asset owners must review users’ access rights at regular intervals, both around individual change (on-boarding, change of role and exit) as well broader audits of the systems access.

Authorisations for privileged access rights should be reviewed at more frequent intervals given their higher risk nature. This ties in with 9.2 for internal audits and should be done at least annually or when major changes take place.

A.9.2.6 Removal or Adjustment of Access Rights

As outlined above access rights of all employees and external party users to information and information processing facilities need to be removed upon termination of their employment, contract or agreement, (or adjusted upon change of role if required).

A good exit policy and procedures dovetailed in with A.7 will also ensure this is achieved and demonstrated for audit purposes when people leave.

What is the objective of Annex A.9.3?

Annex A.9.3 is about user responsibilities. The objective in this Annex A control is to make users accountable for safeguarding their authentication information.

A.9.3.1 Use of Secret Authentication Information

This is simply about making sure that users follow the policies and will therefore tie in with A7 Human Resource Security for contracts, user education for awareness and compliance, as well as common sense practices.

These include: Keep any secret authentication information confidential; Avoid keeping a record of it that can be accessed by unauthorised parties; Change it whenever there is any suggestion of possible compromise; select quality passwords with sufficient minimum length and strength to follow broader password policy controls in Annex A.9.4.

What is the objective of Annex A.9.4?

Annex A.9.4 is about system and application access control. The objective in this Annex A control is to prevent unauthorised access to systems and applications.

A.9.4.1 Information Access Restriction

Access to information and application system functions must be tied into the access control policy. Key considerations should include:

These include:

• Role-based access control (RBAC);
• Levels of access;
• Design of “menu” systems within applications;
• Read, write, delete and execute permissions;
• Limiting output of information; and
• Physical and/or logical access controls to sensitive applications, data and systems.

The auditor will check to see that considerations have been made for limiting access within systems and applications that support access control policies, business requirements, risk levels and segregation of duties.

A.9.4.2 Secure log-on Procedures

Access to systems and applications must be controlled by a secure log-on procedure to prove the identity of the user.

This can go beyond the typical password approach into multi-factor authentication, biometrics, smart cards, and other means of encryption based on the risk being considered.

Secure log on should be designed so it cannot be easily circumvented and that any authentication information is transmitted and stored encrypted to prevent interception and misuse.

ISO 27002 guidance is significant around this topic, as are specialist bodies like the National Cyber Security Centre (NCSC). Additional tips include:

• Log-on procedures should be designed so that they cannot be easily circumvented and that any authentication information is transmitted and stored encrypted to prevent interception and misuse.
• Log-on procedures should also include a display stating that access is for authorised users only. This is designed to support cybersecurity legislation such as the
• Computer Misuse Act 1990 (UK).
• Both a successful and unsuccessful log-on and log-off should be logged in a secure manner to provide forensic evidential ability and alerts for unsuccessful attempts and possible lock-outs should be considered.
• Depending on the nature of the system access should be restricted to certain times of day or periods of time and potentially even be restricted according to location.

In practice, the business needs and information at risk should drive the log on and log off procedures. It is not worth having 25 steps to log on, then have rapid time outs etc if staff are then unable to do their job well and spend a disproportionate amount of time in this loop.

A.9.4.3 Password Management System

The purpose of a password management system is to ensure quality passwords meet the required level and are consistently applied.

Password generation and management systems provide a good way of centralising the provisioning of access and they serve to reduce the risk of people using the same login for everything, as illustrated in this little story of what happens when a customer contacts our team about a forgotten password!

As with any control mechanism, password generation and management systems need to be carefully implemented to ensure adequate and proportionate levels of protection.

Wherever possible users should be able to choose their own passwords as this makes them easier to remember than machine-generated ones, however, it needs to be up to a certain level of strength.

There are lots of conflicting views on password management systems and password policies so we encourage organisations to look at the frequently changing best practices and adopt approaches based on the risk appetite and culture of the organisation.

As mentioned above, NCSC is a good place to review the latest practices or simply ask us to introduce you to one of our partners for help.

A.9.4.4 Use of Privileged Utility Programmes

Utility computer programmes that might be capable of overriding system and application controls need to be carefully managed.

Powerful system and network utility programs can create an attractive target for malicious attackers and access to them must be restricted to the smallest number of people. As such utility programmes can be easily located and downloaded from the internet it is also important that users are restricted in their ability to install any software as much as possible weighed against business requirements and risk assessment. Use of utility programmes should be logged and monitored/reviewed periodically to satisfy auditor requests.

A.9.4.5 Access Control to Program Source Code

Access to program source code must be restricted. Access to program source code and associated items (such as designs, specifications, verification plans and validation plans) should be strictly controlled.

Programme source code can be vulnerable to attack if not adequately protected and can provide an attacker with a good means to compromise systems in an often covert manner. If the source code is central to the business success it’s loss can also destroy the business value quickly too.

Controls should include consideration for:

• As few people as possible having access
• Keeping source code off operational systems (only compiled code)
• Access to source code being as restricted as possible (deny-by-default)
• Access to source code being logged and the logs periodically reviewed
• Strong and strict change control procedures
• Frequent audits and reviews

Why is Annex A.9 important?

Annex A.9 is probably the most talked about clause in the whole of Annex A, and some would argue it’s the most important.

This is because your whole Information Security Management System (ISMS) is based on making sure the right people have access to the right information at the right time. Getting that right is one of the keys to success, but getting it wrong can have a huge impact on your business.

Imagine if you accidentally gave access to confidential employee information to the wrong people, like revealing what everyone in the business gets paid for example.

The consequences of getting this part wrong can be significant, so it’s worth spending sufficient time thinking it all through.