ISO27002:2022 explained – 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.

Series structure

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)

Organizational controls

Policies for information security (5.1)
A document needs to be created, containing how the organization manages information security objectives. This document needs to be approved by management, and needs to contain both high- and low-level policies. Once the policies are in place, they need to be reviewed regularly. The best approach to this is to set a regular meeting and plan an extra meeting in between should the situation require it. If any changes are made, management needs to give their approval. The policies should be shared with internal and external stakeholders.

Information security roles and responsibilities (5.2)
The policy needs to define who is responsible for what asset, process, or information security risk activity. It is important that the assignment is done clearly and for all assignments. Make sure that the roles and responsibilities suit your organization; a small team of five probably does not need a full time security officer.

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 log all activities and split important tasks in doing and checking or approving and initiating. This prevents fraud and error, e.g. in the case of having one person create and sign all company cheques.

Management responsibilities (5.4)
Management needs to make sure all employees and contractors are aware of and follow the organization’s information security policy. They should lead by being an example and show that Information Security is both useful and necessary.

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. A quick and adequate response to incidents can greatly decrease the impact, and may even be mandatory by law.

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. Such groups can be asked for expert advice in certain cases, and be a great source for improving one’s own knowledge. Examples of such groups are the PVIB, NGFG, IAPP, and our own LinkedIn group Information Security NL.

Threat intelligence (5.7)
Reacting to threats does little to prevent their first materialized occurrence. 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, automated phishing mails are a greater threat.

Information security in project management (5.8)
To assure a successful organization wide ISMS implementation, 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.

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. Users of the asset should be aware of the information security requirements regarding asset use, and follow them.
For the handling of assets, procedures should be in place as well. Personnel need to understand the labeling of assets, and know how to handle different levels of classifications. 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.

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 policy for this, which has to be known by all involved. Non-tangible assets important to current operations such as specific knowledge that is not yet documented should be documented and returned as such.

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. The organization should have a policy in place on how to handle classified information. The accountability to classify information assets lies with its owner. To distinguish between the importance of different classified assets, it can be useful to implement several levels of confidentiality from non-existent to severely impacting the organization’s survivability.

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. Sadly, this can be useful to ill-intentioned individuals as well as a direction to interesting items. It is important to be aware of this risk.

Information transfer (5.14)
Information is shared inside and outside the organization. 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.
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.
Business communication often happens by means of electronic messaging. Organizations are advised to have an overview of approved types of electronic messaging and should document how these are protected and may be used.

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. Frequently used terms in an access control policy are need-to-know and need-to-use, where the former restricts the access rights only to information an employee needs to perform their task and the latter restricts the access rights only to information processing facilities needed to perform the task. If you are new to access control, take a look at our Introduction to Information Access.

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.

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 policy are, for example, forbidding users to share secret authentication information, giving new users a password that has to be changed on first use, and having all systems authenticate a user by requiring a user’s secret authentication information (password on PC, swiping access card for doors).
If password management systems are used, they need to provide good passwords and strictly follow the organizations secret authentication information policy. The passwords themselves should be stored and transmitted securely by the password management system.

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.
Organisations and their employees are not static. Roles change or 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. Once a contract or agreement has been terminated, the access rights of the receiving party should be removed.

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.

We offer a free excel template to help you create a register of supplier. You can download it here.

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.

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.

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 on a regular basis.

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.

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.

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.

Image credit: @johnschno via Unsplash