Dejan Kosutic Updated: March 29, 2023, according to the ISO 27001 2022 revision.
Access control is usually perceived as a technical activity that has to do with opening accounts, setting passwords, and similar stuff – and it is true: access control does include all these things, but access control doesn’t begin as a technical thing. It begins as a business decision.
Let’s see what ISO 27001 requires: it defines access control in sections A.5 and A.8 of Annex A, a total of seven controls, which means this topic is obviously very important. Let’s see what these controls look like.
Security controls covering access control in ISO 27001:
- A.5.15 Access control
- A.5.16 Identity management
- A.5.17 Authentication information
- A.5.18 Access rights
- A.8.2 Privileged access rights
- A.8.3 Information access restriction
- A.8.4 Access to source code
Organizational requirements of access control (section A.5)
This subsection requires you to establish and implement rules for physical and logical access control to information and information-related assets. In effect, this means you have to set the rules first, and only then allow the users to access information, either in physical or logical form.
You can set the access rules in several ways, but typically there are two approaches: the first approach is that you define user profiles (where you define the level of access for each user profile), and then based on each job title you assign an appropriate user profile to that job title. For example, you can define that you have user profile A (with access to basic applications, services, and locations), and user profile B (with access to all basic + more sensitive systems, and locations) – then you can define a rule where everyone in the company uses user profile A, while only some privileged users (e.g., administrators, managers, etc.) use user profile B.
The second approach is that you define that owners of assets (i.e., networks, applications, services, locations, etc.) have to approve the access to certain users each time they need to access those assets – this second approach is, of course, much more time consuming. In reality, the combination of these two approaches is very often used, as I’ll explain later on.
By the way, an Access Control Policy can focus only on information systems, or both on the information systems and the physical access to secure areas – the standard allows both approaches. In reality, approving the access to a physical area doesn’t have too many differences compared to approving the access to an information system. Read also: Physical security in ISO 27001: How to protect the secure areas.
You also have to define how you require the users to register in your systems (e.g., handling user IDs), how you assign them the access (provisioning of access or revoking the access), how you manage the authentication data (e.g., how you provide the initial passwords, smart cards, etc.), how you allow access that is outside of the regular rules (privileged access), and how the users will keep their authentication information secret (e.g., protect their passwords).
Finally, there has to be a process of removal of all access rights when someone is leaving the company or adjusting them when a person changes their position in the company. Too many times it has happened that people have access to some systems a couple of years after they have left a company, only because no one has remembered to close this access.
By the way, you can define all those rules in the same Access Control Policy, or you can develop separate documents for that purpose – for example, you might develop a Password Policy where you define how to perform the authentication, or you can develop an IT Security Policy, which defines rules like these: Do not write the passwords down; Do not disclose them to anyone; Do not use the same password in different systems; etc.
Technological requirements of access control (section A.8)
This is where things get technical – you have to ensure that the access to all systems is really compliant with the Access Control Policy, that the access is protected with secure log-on procedures (e.g., use biometrics if passwords are not enough), that passwords in use are complex enough and secure enough, that asset owners should regularly review all the privileged access and decide whether they are still needed, etc.
Further, if your company is developing programs, you should define how to protect the access to the source code – usually, the access is defined through the same Access Control Policy as for all the other access issues.
Finally, you should define how to protect the access to the information when using special software tools that enable access to the information directly, bypassing the standard application or system controls – these are usually administrator and utility programs, mainly used by system administrators. In any case, the use of such tools must be restricted, allowed to be used only in very specific circumstances, and under supervision.
To conclude, to have no access control means to have no security at all – this is one of the main building blocks of information security which has to be technically performed well, but also designed so that it is both secure enough and acceptable to users. What you don’t want to happen is to have a very ambitious plan to change passwords every month, only to find out your employees have completely rejected such a system because they thought it impractical.
To learn how to become compliant with every clause and control from Annex A and get all the required policies and procedures for controls and clauses, sign up for a free trial of Conformio, the leading ISO 27001 compliance software.
