ISO27001 explained – A5 Organizational controls

The information security standard ISO 27001 consists of a main structure and an annex of recommended controls. The recommended controls are further explained in an additional standard ISO 27002. The main structure explains how a well-functioning ISMS (Information Security Management System) should be set up and maintained. The controls are specific actions that organisations should take against specific risks.  ISO 27002 was last updated in 2022, and we have created this article summarising the updated set of 93 security controls.

The latest set of controls has 93 controls, and is thus smaller than the ISO 27001:2013 set of controls that is summarized here.  In a dedicated blogpost, we have summarised the changes and provide more detail on ISO 27002:2022.

ISO 27002:2022 is divided into four chapters.  For this reason, we have created the following four blog posts:

1. Organizational controls (chapter 5) – This article
2. People controls (chapter 6)
3. Physical controls (chapter 7)
4. Technological controls (chapter 8)

Learn faster with our YouTube channel

You can also learn how to implement organizational controls directly from our full ISO 27001 course on YouTube. Discover the other chapters on our YouTube channel covering the full ISO27001 series.

Implementing Organizational Controls

Annex A5 contains 37 ‘organisational’ controls. They are intentionally high‑level: the standard tells you what needs to be in place, but you choose how to implement it in a way that fits your organisation. The quickest way to make these controls audit‑ready is to focus on three things:

1. an overall procedures document (how you implement each A5 control),
2. an annual calendar (when recurring checks happen),
3. evidence (real artefacts that prove you actually do what you wrote down).

A useful thought process is: existence → execution → effectiveness. Existence is your documented approach (policy/procedure/template). Execution is a completed instance (a filled template, a meeting note, a register entry). And effectiveness is your follow‑up (actions, improvements, or a justified “no change needed”).

If you’re implementing ISO 27001 in a small or mid‑size organisation, you do not need 37 separate policies. Instead, aim for:

• 1 Information Security Policy based on the template
• 1 Acceptable Use or Staff Security Rules that all staff members are trained with – see template
• 1 InfoSec procedures (IS procedures) document covering all A5, A6, A7 and A8 controls – see our template
• 4-5 registers: Risk register, Asset register (with Access matrix), Supplier register, Incident register – explore the templates
• 1 annual calendar: dates for reviews (policy review, access review, supplier review, internal audit, business continuity test)

Official Information (5.1 – 5.8)

Policies for information security (5.1)
Create an Information Security Policy that states containing your information security objectives, principles (risk-based, least privilege, security by design) and governance (who approves, how often reviewed). This document needs to contain a high-level policy and refer to any low-level policy (such as the acceptable use policy). It needs to be be approved by management and regularly reviewed: put a yearly review into your annual plan (and allow ad‑hoc review after major changes/incidents). If any changes are made, management needs to give their approval. Remember that the policies should be shared with internal and external stakeholders (e.g., available to customers upon request). For example, see how the ICT Institute IS policy looks like.

Evidence: approved policy

Information security roles and responsibilities (5.2)
Include a table in the IS procedures with two or more roles and responsibilities with impact on information security (processes, activities). This is your IS team. Make sure there is one person that is responsible of “communications relevant to the ISMS” and . Roles and responsibilities should be realistic and suit your organization.

Evidence: contained in IS procedure, proof people were informed who they can contact from the IS team (within IS rules / onboarding checklist)

Segregation of duties (5.3)
To prevent any misuse of company assets, the “power” to fully control a sensitive activity should not lie with the same person. The best way to implement this is to split important tasks in doing and checking, or approving and initiating (and log sensitive activities). For example:

• payments: create invoice vs. approve payment
• development: developer vs. reviewer (other developer)

If segregation is not feasible (very small team), mitigate with logging + management review, and document the justification.

Evidence: approval logs, a completed access request showing separate approver (e.g., approved PRs)

Management responsibilities (5.4)
Management needs to make sure all employees and contractors are aware of and follow the organization’s information security policy. In practice, make IS rules/Acceptable Use rules mandatory , for instance, as a clause to the employment contract. Rules should use ‘must’, not ‘should’ for applicable items. Management should lead by being an example and show that Information Security is both useful and necessary (e.g., by organizing security awareness trainings).

Evidence: signed IS rules, management (e.g. CTO in the IS team) communication as email announcement or kick-off message during onboarding

Contact with authorities (5.5)
It should be clear who is responsible for contacting authorities (e.g. law enforcement, regulatory bodies, supervisory authorities), which authorities should be contacted (e.g. which region/country), and in what cases this needs to happen. Document the contact list and responsible in the IS procedures.

Evidence: section in IS procedures

Contact with special interest groups (5.6)
To make sure that the latest information security trends and best practices are kept up with, good contact with special interest groups should be maintained by personnel with ISMS tasks.  Document a list of sources in the procedures. Examples of such groups are the PVIB, IAPP, industry symposia or conferences and our own LinkedIn group Information Security NL.

Evidence: find and store one relevant news item in a evidence folder or repository + discuss the news item in your next InfoSec team meeting

Threat intelligence (5.7)
By collecting and analyzing information about threats to your organization, you have a better idea of which protection mechanisms need to be put in place to protect against the threats that are relevant to your organization. Computer chip manufacturers need to prepare for targeted IP-theft attacks by state actors, but for a small SaaS-provider, company-branded phishing emails are a greater threat. In practice, define your threat intel sources (open advisories + vendor security bulletins + CVE feeds).

Evidence: a captured advisory + a ticket/meeting note showing the decision it triggered, or why it was relevant to discuss in the IS team meeting

Information security in project management (5.8)
Information security should be considered and documented in all projects in the form of requirements. These requirements can stem from business, legal, and compliance with other standards or regulations. If you have project management handbooks or templates, an information security chapter should be included. The easiest way to implement it is to include mandatory “security & privacy” chapters in project plans – check our project template.

Evidence: a recent project plan with filled-in sections + any resulting tasks (supplier review, update to privacy policy, etc.).

Assets and labelling (5.9 – 5.14)

Inventory of information and other associated assets (5.9)
The organization should have identified of all information- and information processing assets. All the assets must be drawn up in an inventory, which should be properly maintained. Knowing what assets there are, their importance, where they are, and how they are handled is essential in identifying and predicting risks. It might even be mandatory for legal obligations or insurance purposes.
All assets in the inventory, so of the whole company if the inventory is complete, must have an owner. Thanks to asset ownership, assets are watched and taken care of through their whole lifecycle. Similar assets may be grouped and the day to day supervision of an asset may be left to a so-called custodian, but the owner remains responsible. Asset ownership must be approved by management.

Acceptable use of information and other associated assets (5.10)
There should be well-document rules for accessing information assets where users should be aware how to handle assets according to classification labels, and follow them. We advise to first implement control 5.12 an 5.13 below, so that you have a classification in place and a concrete labeling system. For this control, define a table of your confidentiality levels where you describe 1) how to store, 2) whom to share with, 3) how to send and 4) any physical storage. This is a good place to define the way you expect staff to use tools to share information, such as SharePoint, which you should mention explicitly. Since there is no universal standard for classification, it is also important to have knowledge of classification levels of other parties, since they will most likely differ from yours.

Evidence: include this in your Staff Rules.

Return of assets (5.11)
When an employee or external party may no longer access an asset due to, for example, the end of employment of agreement, they must return the asset to the organization. There should be a clear rule for this, which has to be known by all involved (i.e., signed IS rules). Make sure to include in the staff rules the return of assets, such as laptops, phones and badges. For this, you will need to have an asset register implemented. Non-tangible assets that are important for operations, like non-documented specific procedure for a critical asset, should be documented and returned as such (consider it as a information assets, like user access to services).

Evidence: IS rules, offboarding checklist + example of returned asset

Classification of information (5.12)
Certain information is considered to be sensitive due to e.g. monetary or legal value, and has to remain confidential while other information is less crucial. Define 3-4 classes of confidentiality levels in your IS rules document: public – any information already on the internet, free to share; internal – information with business value, only within the company and employee access as needed; confidential – high business/strategic/personal value, always to be protected and shared as needed. Make sure to include who can access, where it may be stored, how to share and retention expectations.  The confidentiality levels should cover information from non-existent to severely impacting the organization’s survivability.

Evidence: classification table in the IS rule + examples of a classified document assets (document labels)

Labelling of information (5.13)
Not all information falls in the same category, as discussed in 5.12 above. It is, therefore, important to label all information in accordance to their classification. When information is handled, stored, or exchanged it may be vital to know the classification of the object. Describe in the IS rules how to apply the confidentiality labels on documents and files, and decide how to treat unlabeled documents such as from external sources, e.g., confidential by default. Be aware that this can be useful to ill-intentioned individuals as a direction to interesting items. Decide where labels appear: title page,  document footer or header, or even file name prefix, SharePoint labels, physical labels.

Evidence: your IS rules + a labelled document, or a screenshot of your DLP settings.

Information transfer (5.14)
There should be a protocol for all types of information sharing, including digital documents, physical documents, video, but also by word of mouth. Clear rules on how information can be safely shared helps lower the risk of information contamination and leaks. The best way to implement this control is to include such rules within the staff IS rules document where you define which communication channels to use. For example, MS Teams for communication with colleagues, while WhatsApp or signal for non-business-related communication with clients or colleagues, or confidential reports must be handed in in person (not via mail); similarly, source code may only be accessed on git-based repositories.
Information that is shared between the organization and external parties needs to be preceded by an information transfer agreement. This way, the source, content, confidentiality, transfer medium, and destination of the information transfer is known by and agreed upon by both parties.

Evidence: procedure in IS Rules and examples of typical communication channels

Identity and access management (5.15 – 5.18)

Access control (5.15)
An access control policy should be in place to define how access is managed, and who is allowed to access what. The rules per asset lie with the asset owners, who set up requirements, restrictions, and rights for the access to “their” asset. We advise to define a role-based access control method (RBAC) where access to assets is granted on a ‘need-to-know’ and ‘need-to-use’ basis. One way to implement them is by defining an access matrix with roles as rows, assets as columns and access level as values (see our template). Be sure to include access review in the yearly schedule. If you are new to access control, take a look at our Introduction to Information Access.

Evidence: access matrix, ISMS schedule

Identity management (5.16)
To assign access rights to assets and networks and keep track of who actually does the accessing, users need to be registered under an ID. When an employee leaves an organization, the ID and access to it should be removed. When an employee only needs to be denied access, the access of the ID can be limited. Even though using another employee’s ID might be quicker and easier to access something, this should not be allowed by management in most cases. Sharing ID’s removes the link between an access limitation and an employee, and makes it nearly impossible to keep the right person responsible for their actions. Assigning, altering, and ultimately deleting an identity is often called the identity lifecycle. In practice, describe your lifecycle in the IS Procedures, for example, whether each employee gets an email address as their unique identity.

Evidence: accounts registry, onboarding record, account creation

Authentication information (5.17)
Secret authentication, such as passwords and access cards, must be managed in a formal process. Other important activities that should be stated in the IS Rules are, for example, forbidding users to share secret authentication information. Giving new users a password that has to be changed on first use should be in the and having all systems authenticate with secret information (password on PC, swiping access card for doors), should be described in the IS Procedures. We recommend to use password managers, where it is is easy and secure to enforce password policies.

Evidence: signed rules + proof of enforcement (MFA enabled)

Access rights (5.18)
Management should have a system in place for the provisioning and revoking of access rights. It is advised to create certain roles based on activities certain types of employees perform, and give the same basic access rights to them. Part of having a system in place is having repercussions for attempted unauthorized access. Employees have no need to try to access places they should not, since access rights can easily be requested from the asset owner and/or management.
Often, roles change and employees leave the company, constantly changing access needs. Asset owners should regularly review who may access their asset, while role changing or leaving should trigger an access rights review by management. Since privileged access rights are more sensitive, they should be reviewed more often. We strongly advise to schedule a yearly or half-year access review, and log the changes in each review. Once a contract or agreement has been terminated, the access rights of the receiving party should be removed. For this, include in your offboarding checklist for HR to revoke and delete users.

Evidence: Access review logs

Supplier management (5.19 – 5.23)

Information security in supplier relationships (5.19)
Since suppliers have access to certain assets, organizations need to establish a policy stating requirements for risk mitigation. This policy needs to be communicated to suppliers and agreed upon. Examples of such requirements are pre-determined logistic processes, an incident process obligations for both sides, NDA’s, and documentation of the supplying process.

Read our detailed explanation of the supplier management covering A5.19 to A5.23, and download the free excel template to help you create a register of supplier.

Addressing information security within supplier agreements (5.20)
Every supplier that in any way, directly or indirectly, comes into contact with the organization’s information must follow the set information security requirements and agree to them. Examples are requirements on information classification, acceptable use, and rights to audit. An easily forgotten aspect of an agreement is what to do when the supplier cannot or will not supply anymore. It is important to implement a clause for that.

Managing information security in the ICT supply chain (5.21)
Agreements with suppliers should also state the information security requirements and agreements on ICT services and supply chain. Examples of included requirements are the need to be able to follow items through the supply chain, and that a certain minimal level of security is maintained at every level of the “chain”.

Monitoring, review and change management of supplier services (5.22)
Everyone makes mistakes, and so do suppliers. Whether the mistake happened by accident or deliberately , the result is the same: the organization does not receive exactly what has been agreed upon and trust may decrease. For this reason, organizations should keep an eye on suppliers, and audit them where felt necessary. This way, an organization is aware when a supplier does something out of the ordinary.
Just like with system changes, management needs to control any changes in supplier services. They need to make sure that information security policies are up to date and any changes in the provision of the service itself is managed. A small change in the provided service combined with an outdated information security policy might result in a large new risk. Supplier-side changes can easily occur, for example when the service is enhanced, a new app or system is supplied, or the supplier’s policies and procedures change.

Information security for use of cloud services (5.23)
Cloud suppliers offer a service that, when in use, is more often than not a vital part of an organisation’s infrastructure. Office documents are stored in the cloud, but many SaaS-providers offer their product to their customers via a cloud provider such as Amazon AWS, Microsoft Azure, or Google Cloud.
The risks surrounding this critical part of the organisation should be appropriately mitigated. Organizations should have processes for using, managing, and leaving (exit strategy) a used cloud. Severing ties with a cloud provider often means a new cloud provider is on the horizon, so controlling the purchasing and onboarding onto a new cloud should not be forgotten either. Just like any other third party software, a new cloud environment should allow you to keep your desired level of information security, not compromise it.

Incident Management (5.24 – 5.27)

Information security incident management planning and preparation (5.24)
Organizations need to create and document procedures for information security incidents, and who is responsible for what. This way, should an information security incident occur, it can be handled effectively and quickly. Security incident happen unexpected and can cause quite some chaos, which can be mitigated by having a protocol that is followed by knowledgeable and trained staff.

Assessment and decision on information security events (5.25)
Organizations should have a well document assessment method for security incidents. When a suspicious event occurs, the responsible person is to test the event against the requirements and determine whether there was an actual information security incident. The results of this assessment should be documented, so that they can be used for future reference.

We offer a free excel template for recording information security incidents. You can download it here.

Response to information security incidents (5.26)
This point seems straight forward, but is still important to mention and sometimes hard to do in practice. Once an information security incident occurs, it needs to be responded to following the set-up procedures by the appointed staff. The pre-determined actions should be taken, and the whole process accurately documented. This helps prevent future occurrences and weed out related security vulnerabilities.

Learning from information security incidents (5.27)
Even though incidents are unwanted, they still possess great value. The knowledge gained from solving an incident should be used to prevent similar incidents in the future, and can help identify a possible systematic problem. With additional controls, it is important to keep an eye on the costs; a new control should not cost the organisation more on an annual basis than the incidents it mitigates.

Compliance (5.28 – 5.36)

Collection of evidence (5.28)
Once an accident occurs, the cause is usually not immediately clear. When the cause is an individual or organization, they should be disciplined based on the intention and effect. To link an incident to a cause, evidence needs to be collected. In case of a malicious action, this evidence and the way it was obtained might be used in legal proceedings. To prevent accidental or deliberate destruction of evidence, there should be a clear and safe evidence identification procedure.

Information security during disruption (5.29)
Organizations should determine their requirements for information security continuity in case of a crisis. The easiest choice is to resume standard information security activities as best as possible in an adverse situation. Once the requirements have been determined and agreed upon in management, procedure, plans, and controls should be put in place to resume with an acceptable level of information security in case of a crisis.
As organizations change, the best way to respond to a crisis changes as well. An organization that, for example, doubled in size within a years’ time will most likely benefit from a different response than a year ago. For this reason, the information security continuity controls should be reviewed on a regular basis.

Focussing specifically on 5.29 might require additional effort for many small companies. You can read about our combined, more efficient approach towards 5.29 in our article on Business Continuity.

ICT readiness for business continuity (5.30)
During Business Continuity planning, special attention should be placed on scenarios where IT systems fail. There should be a clear strategy how systems will be restored, who will do this, and how long this may and will take. It should also be clear what “restoring” means in a specific scenario, since having only the core systems running is likely enough for the first week after a complete meltdown.

A Business Continuity and Disaster recovery plan should contain all of the above considerations. Specifically:

• Definitions and business objectives
• Business Impact Analysis (BIA): an overview of your processes, their importance and suitable objectives
• Disaster scenarios: about 4 different realistic disasters, such as ransomware, power failure or office closure
• Verification, review and evaluation: for each scenario how you shall evaluate/test whether the plan works, such as a backup retore test or a tabletop exercise.

Read our detailed explanation of security and business continuity controls, and discover our Business continuity Plan template.

Identification of legal, statutory, regulatory and contractual requirements (5.31)
Requirements come from all places, and are there to be met. Organizations should therefore have an overview of all information security related requirements they need to comply to, and how this is done. Since requirements can change or get added, the requirement compliance overview needs to be kept up to date. An example of changing requirements is when your organization expands to a new country on a different continent. This country is likely to have different laws on privacy, information storage, and cryptography.

Intellectual property rights (5.32)
Intellectual property (IP) rights, also a part of legal compliance, is an area that deserves special attention. IP can be of great value, so it is important to document one’s own intellectual property and the use of other’s intellectual property well. (Accidental) wrong use of other’s IP may result in large lawsuits, and should be prevented at all costs. In practice, this control can be implemented as a procedure in the staff IS rules where staff is aware of how to reference handle copyrighted text and images (e.g., how to reference cited text, photos of people) and the prohibition to use pirated software.

Evidence: procedure in IS rules

Protection of records (5.33)
Any records, be it accounting records or audit logs, should be protected. Records are at the risk of being lost, compromised, or accessed unauthorized. The requirements for the protection of record might come from the organization itself or from other sources such as legislation or insurance companies. For this, strict guidelines should be created and followed.

Privacy and protection of Personal Identifiable Information (PII) (5.34)
Depending on the country or economic space an organization is located in, different legislation on the protection of personal data might apply. To organizations situated in the EU and/or processing personal data of EU citizens, the General Data Protection Regulation (GDPR) applies. Organizations need to make sure they are aware of the requirements set by such legislation, and follow it religiously. The GDPR, for example, mandates conducting data processing agreements, keeping a register of processing activity, and data processing transparency.

We offer a selection of free templates to help you meet GDPR requirements, including templates for a data processing register and data protection impact assessment (DPIA). You can find all our free templates here.

Independent review of information security (5.35)
It is impossible for organizations to objectively review their own information security system. For this reason, organizations should have their information security audited by an independent party on a regular basis, or when large changes occur. This keeps an organization’s view of their information security correct and transparent. An independent party can also be a full-time internal auditor, who has the sole task of performing the internal audits and does not have other conflicting tasks and responsibilities.

Compliance with policies and standards for information security (5.36)
With all these security policies, standards and procedures, it is important for managers to regularly review whether the activities and/or processes they are responsible for are fully compliant. For this to be done correctly, they should be aware of exactly which rules and requirement they need to comply with and check this manually or with an automatic reporting tool.
Information systems need to be regularly reviewed for compliance as well. The easiest and usually most cost-effective way to do this is by means of automated tooling. This tooling can quickly check all the nooks and crannies of a system and report exactly what went/could go wrong. Vulnerability tests such as penetration tests can effectively show any weaknesses, but might actually harm the system when done without caution.

Documented operating procedures (5.37)
Procedures for the operating of equipment should be documented and made available to those using the equipment. From the simple procedure of computer use (from start to shut-down) to the use of more complicated equipment there should be a guide on how to safely and correctly operate it. Due to their importance, the procedures should be treated as formal documents, meaning that any changes should be approved by management.

You made it all the way to the end of the first article! We hope you enjoy the second article just as much. Also, check our detailed articles on controls for security and business continuity, supplier management and our YouTube channel.

Image credit: @johnschno via Unsplash