All these changes bring a refresh to the controls, giving a vision more aligned with the technological changes of recent years, including cloud‑related topics that had been missing and consolidating some that in one way or another were seen as repetitive. Its structure presents mechanisms that make it easier to search for controls according to different classifications assigned to them.
This structure organizes the controls into 4 categories or clauses:
- Organizational controls (37)
- People controls (8)
- Physical controls (14)
- Technological controls (34)
And each control has documented attributes of different types described below:
| Type of control | #Preventive: the control that aims to prevent an information security incident from occurring |
| #Detective: the control acts when an information security incident occurs | |
| #Corrective: the control acts after an information security incident has occurred | |
| Information security properties | #Confidentiality |
| #Integrity | |
| #Availability | |
| Cybersecurity concepts (taken from ISO/IEC TS 27110) | #Identify |
| #Protect | |
| #Detect | |
| #Respond | |
| #Recover | |
| Operational capabilities | #Governance |
| #Asset_management | |
| #Information_protection | |
| #Human_resource_security | |
| #Physical_security | |
| #System_and_network_security | |
| #Application_security | |
| #Secure_configuration | |
| #Identity_and_access_management | |
| #Threat_and_vulnerability_management | |
| #Continuity | |
| #Supplier_relationship_security | |
| #Compliance_and_legal | |
| #Information_security_event_management | |
| #Ensuring_information_security | |
| Security domains | #Governance_and_ecosystem: includes “Governance of information systems security and risk management” and “Ecosystem cybersecurity management” |
| #Protection: includes “Information technology security architecture”, “Information technology security administration”, “Identity and access management”, “Information technology security maintenance” and “Physical and environmental security” | |
| #Defense: includes “Detection” and “Management of information security incidents” | |
| #Resilience: includes “Continuity of operations” and “Crisis management” |
In this article, an analysis is presented of the organizational controls included in ISO/IEC 27002:2022.
Information security policies (5.1)
This control indicates the need to create a document or set of documents that contain the guidelines on how the organization manages its information security objectives in the different associated processes and technologies. These documents must be approved by management and must contain high‑ and low‑level policies. Once the policies are established, they must be reviewed periodically, preferably annually and whenever the organization, processes, or associated technologies undergo a significant change. The best approach is to set at least one annual meeting or, even better, plan additional meetings throughout the period if the situation requires it. If changes are made, management must give its approval. The policies must be shared with internal and external interested parties, ensuring their reading and understanding.
Information security roles and responsibilities (5.2)
This control indicates that the information security policy, clearly and in documented form, must define who is responsible for each activity, process, or task that poses a risk to information security. This includes all tasks or activities that may influence the confidentiality, integrity, and/or availability of information. It is necessary to ensure that the roles and responsibilities are appropriate for the organization, as also required in clause 5.3 of ISO/IEC 27001:2022. A clear assignment of responsibilities avoids control gaps, duplications, and misunderstandings, and facilitates accountability. The assigned roles must be consistent with the size, structure, and context of the organization, and have explicit support from management.
Segregation of duties (5.3)
To reduce the risk of fraud, errors, or misuse of assets, critical activities must be divided among different people or roles. No person should have total control over an activity that may generate a significant impact on information security; the “power” to fully control a “critical” activity must not be in the hands of the same person. The “critical” activity must not be carried out by the same person. The best way to implement this control is to record all activities and divide important activities into execution, control or approval, and initiation.
Management responsibility (5.4)
Top management must demonstrate a high commitment to information security; this means ensuring that all employees and contractors know, understand, and comply with the organization’s information security policies, standards, and procedures.
In addition to approving policies, management must lead by example, integrating information security into the organizational culture and reinforcing its importance as a business enabler, not as an obstacle; therefore, they must set an example and demonstrate that information security is useful and necessary.
Contact with authorities (5.5)
The organization must clearly define when, how, and who is responsible for contacting the competent authorities (for example, law enforcement, regulatory bodies, supervisory authorities), which authorities must be contacted (for example, in which region/country), in which countries, and in which cases it must be done. A quick and appropriate response to incidents can significantly reduce the impact and may even be legally required.
Contact with special interest groups (5.6)
To ensure up‑to‑date awareness of threats, vulnerabilities, latest trends, and best practices in information security, the organization must encourage personnel with ISMS tasks to maintain good contact with specialized information security groups.
In some cases, these groups may be requested for expert advice and serve as a reference point on information security matters. They may include professional associations, technical communities, government bodies, or incident response teams. Examples of these groups are: IAPP, the LinkedIn security group, ISACA, ISC2, specific government organizations (technology ministries), local, industry, sector, regional and/or global CSIRTs.
Threat intelligence (5.7)
The organization must collect and analyze relevant information about current and emerging threats that may affect its context. This means that reacting to threats does not prevent them from occurring for the first time. By collecting and analyzing information about the organization’s threat environment, a better understanding is gained of the protection mechanisms that must be established to defend against threats relevant to the organization.
This proactive approach allows anticipating attacks, adjusting security controls, and prioritizing resources based on real and relevant threats, instead of reacting only when an incident occurs.
Information security in project management (5.8)
This control indicates that, to ensure the success of ISMS implementation at the organizational level, information security must be considered and documented in the project management plan. Security must be considered and documented in all projects in the form of requirements. These requirements may derive from business and legal activities and from compliance with other standards or regulations. If project management manuals or templates exist, they should include a chapter on information security.
This ensures that new systems, processes, or organizational changes do not introduce unnecessary risks and that security becomes a natural part of project decision‑making.
Inventory of information and other associated assets (5.9)
The organization must identify all information and information‑processing assets; these assets must be collected in an inventory, which must be properly maintained. Knowing what assets exist, their importance, where they are located, and how they are managed is essential to identify and predict risks. It may also be mandatory due to legal, contractual, or insurance requirements. All assets in the inventory—and therefore the entire company if the inventory is complete—must have an owner (that is, a responsible person). Thanks to asset ownership, they can be monitored and managed throughout their lifecycle. Similar activities may be grouped, and daily supervision of an activity may be assigned to a so‑called custodian, but the owner remains responsible. Asset ownership must be approved by management.
Acceptable use of information and other associated resources (5.10)
Clear and documented rules must be established for access to information resources. The users of the resource must know the information security requirements related to the use of the resource and comply with them. Procedures for asset management must also be established. Personnel must understand the labeling of assets and know how to handle the different classification levels (see 5.12). Since there is no universal classification standard, it is also important to know the classification levels of other parties, as they are very likely to differ from those of the organization.
This helps prevent misuse, loss of information, and unnecessary exposure, especially when handling different classification levels or third‑party information.
Asset return (5.11)
Effective processes must be established to ensure that when an employee or an external party should no longer access an asset due, for example, to the termination of employment or a contract, the asset must be deactivated or returned to the organization. Therefore, there must be a clear policy on this matter, which must be known by all involved parties. Intangible assets important for current operations, such as specific knowledge that has not yet been documented, must be documented and handed over to the organization to avoid operational or security losses.
Information classification (5.12)
Some information in the organization is considered sensitive, for example due to its monetary or legal value, and must be confidential, while other information is less important. The organization must have a policy on how to handle information, and for this it must indicate how to classify it. The responsibility for classifying information resources lies with their owner. To distinguish the importance of the different classified assets, it may be useful to apply different confidentiality levels, ranging from none to severe impact on the survival of the organization.
Classification facilitates the application of appropriate controls and ensures that the most sensitive information receives a level of protection consistent with its importance to the organization.
Information labeling (5.13)
Not all information falls into the same category, as mentioned in the previous control. Therefore, it is important to label all information according to its classification. This must occur when information is handled, stored, or exchanged, as during its use it may be essential to know the classification of the object. Unfortunately, this can be useful for malicious individuals, as it becomes a guide to interesting objects, and therefore it is important to be aware of this risk.
Information transfer (5.14)
This control indicates that information, when shared inside and outside the organization, must follow a protocol for all types of information exchange, including digital documents, physical documents, videos, but also word‑of‑mouth (verbal transmission of information). Having clear rules on how to share information securely helps reduce the risk of contamination and loss of information. Information shared between the organization and external parties must be preceded by a transfer agreement. In this way, the source, content, confidentiality, means of transfer, and destination of the information transfer are known and agreed upon by both parties.
Business communication is often carried out through electronic messaging. It is recommended that organizations have an overview of the types of approved electronic messaging and document how they are protected and can be used to transfer information.
Access control (5.15)
This control indicates that there must be an access control policy to define how access is managed and who is authorized to access what. The access rules for each asset are the responsibility of the asset owners, who establish the requirements, restrictions, and access rights to “their” asset. The terms frequently used in an access control policy are need‑to‑know and need‑to‑use, where the first limits access only to the information an employee needs to perform their task, and the second limits access only to the information technology infrastructure where there is a clear need for access to perform their task.
Secondly, access rights must be limited only to the information‑processing facilities necessary to perform the task.
Identity management (5.16)
To assign access rights to assets and networks and to keep track of who actually accesses them, it is necessary to register users with a unique user identifier. When an employee leaves the organization, the user identifier with its access privileges must be removed.
Although using another employee’s identification may be faster and easier to access something, this must not be allowed by management. Sharing user identifiers removes the link between an access limitation and an employee, and makes it almost impossible to hold the correct person accountable for their actions.
Assigning, altering, and ultimately deleting an identity is usually referred to as the identity lifecycle.
Authentication information (5.17)
This control indicates that the secrets used for authentication, such as passwords, access cards, tokens, or other authentication mechanisms, must be managed in a formal and secure process. Other important activities that must be included in the policy are, for example, prohibiting users from sharing secret authentication information, giving new users a different password for each user that must be changed at first use, and ensuring that all systems authenticate a user by requiring their secret authentication information (password on the PC, swiping the access card through doors).
If password management systems are used, they must provide strong passwords and strictly follow the organization’s authentication policy. Passwords themselves must be stored and transmitted securely by the password management system.
Access rights (5.18)
This control indicates that the organization must have a controlled and documented process for granting and revoking access rights. It is advisable to create roles based on the activities performed by certain types of employees and grant them the same basic access rights. The purpose of having an authentication system is to have records of unauthorized access attempts. Employees should not attempt to access places they should not, since access rights can be easily requested from the asset owner and/or management.
Organizations and their employees are not static. Roles change or employees leave the company, which constantly modifies access needs; for this reason, asset owners must periodically review who can access their assets, while role changes or employee departures must trigger a review of access rights by management. Since privileged access rights are more sensitive, they must be reviewed more frequently. Once a contract or agreement is terminated, the access rights of the receiving party must be removed.
Information security in supplier relationships (5.19)
This control indicates that, since suppliers have access to certain assets, organizations need to establish a policy that sets the requirements for mitigating the risks that arise when access to information assets is granted. This policy must be communicated to suppliers and agreed upon. Examples of such requirements are predetermined logistics processes, a mandatory incident process for both parties, confidentiality agreements, and documentation of the supply process.Addressing information security in supplier agreements (5.20)
This control indicates that any supplier that, in some way, directly or indirectly comes into contact with the organization’s information must follow the established information security requirements and accept them. Some examples are requirements on information classification, acceptable use, and audit rights. One aspect easily forgotten in an agreement is what to do when the supplier cannot or does not want to continue providing its product or service. Therefore, it is essential to include specific information security clauses. This ensures that suppliers understand and accept their responsibilities, as well as the consequences of non‑compliance or service termination.Information security in the ICT supply chain (5.21)
This control indicates that agreements with suppliers must also establish information security requirements and agreements regarding ICT services and the supply chain. Examples of included requirements are the need to be able to track products along the supply chain and to maintain a certain minimum level of security at each level or link of the “supply chain”.Monitoring, review, and management of changes in supplier services (5.22)
This control reminds us that everyone makes mistakes, and suppliers do too. Whether the error occurred accidentally or deliberately, the result is the same: the organization does not receive exactly what was agreed, and trust may decrease. For this reason, the organization must monitor suppliers and audit them when deemed necessary. In this way, an organization becomes aware of when a supplier does something out of the ordinary.
As with system changes, management must control any change in supplier services. They must ensure that information security policies are up to date and that any change in the delivery of the service itself is managed. A small change in the service provided, combined with an outdated information security policy, could lead to a new major risk. Changes in the supplier can easily occur, for example, when the service is improved, a new application or system is delivered, or the supplier’s policies and procedures change.
Information security when using cloud services (5.23)
This control indicates that cloud providers offer a service that, when used, is often a vital part of the organization’s infrastructure. For example, Office documents are stored in the cloud, and many SaaS providers offer their product to their customers through a cloud provider such as Amazon AWS, Microsoft Azure, or Google Cloud.
The risks surrounding this critical part of the organization must be properly mitigated. Organizations must have processes to use, manage, and exit (exit strategy) a cloud they use. Breaking ties with a cloud provider often means that a new cloud provider is on the horizon, so the control of procurement and onboarding into a new cloud must not be forgotten. Like any other third‑party software, a new cloud environment must allow maintaining the desired level of information security, not compromising it.
Planning and preparation for information security incident management (5.24)
This control indicates that organizations need to create and document procedures to manage information security incidents, and who is responsible for what, that is, to define the roles and responsibilities within this process. In this way, if an information security incident occurs, it can be managed effectively and quickly. Security incidents occur unexpectedly and can cause a certain level of chaos, which can be mitigated by having a protocol followed by informed and trained personnel.Assessing and deciding on information security incidents (5.25)
This control indicates that the organization must have well‑documented criteria and methods for evaluating information security incidents. When a suspicious event occurs, the responsible person must compare the event with the criteria and determine whether an information security incident has actually occurred. The results of this evaluation must be documented so that they can be used as a reference in the future in cases or situations where criteria or methods for specific events are not documented.Response to information security incidents (5.26)
Once it is confirmed that an information security incident has occurred, the designated personnel must respond to it by following the established procedures. The predetermined measures must be adopted, and the entire process must be precisely documented. This helps contain the incident, restore services, prevent future incidents, and eliminate related security vulnerabilities.Learning from information security incidents (5.27)
Although incidents are an undesirable event, they still have great value for the organization. The knowledge gained from resolving an incident must be analyzed to identify root causes and improvement opportunities, and in this way used to prevent similar incidents in the future, and may help identify a possible systemic problem. With additional controls, it is important to monitor costs; a new control should not cost the organization annually more than the incidents it mitigates.Evidence collection (5.28)
When an incident occurs, the cause is usually not immediately clear; for this reason, evidence must be collected and protected appropriately for later analysis.
When the cause is an individual or an organization, the disciplinary process must be applied depending on the intention and the effect. To link an incident to a cause, the collected evidence must be used. In the case of malicious action, this evidence and the way it was obtained could be used in legal proceedings. To avoid accidental or deliberate destruction of evidence, there must be a clear and secure evidence identification procedure.
Information security during disruption (5.29)
This control addresses the organization’s duty to determine its requirements for the continuity of information security in the event of a crisis. The simplest option is to resume standard information security activities as best as possible in an adverse situation. Once the requirements are determined and agreed upon by management, procedures, plans, and controls must be established to resume information security at an acceptable level in the event of a crisis.
As organizations change, the best way to respond to a crisis also changes. An organization that, for example, has doubled in size within a year will very likely benefit from a different response than the one from a year earlier. For this reason, information security continuity controls must be reviewed and updated periodically.
ICT readiness for business continuity (5.30)
This control indicates that, during Business Continuity planning, special attention must be paid to scenarios in which IT systems fail. There must be a clear strategy on how systems will be restored, who will do it, and how long it may take. It must also be clear what “restore” means in a specific scenario, as it is likely that only basic or critical systems will function during the first week after a total collapse.Identification of legal, regulatory and contractual requirements (5.31)
This control indicates that information security requirements come from multiple sources, including laws, regulations, and contracts, especially when the organization operates in multiple jurisdictions, and they are there to be complied with. Therefore, organizations must have an overview of all the requirements related to information security that they must comply with and how to do so. Since requirements may change or be added, the overview of compliance with the requirements must be kept up to date. An example of changing requirements is when an organization expands into a new country on a different continent, or establishes a contract with a new customer that imposes different security conditions. It is likely that this country has different laws on privacy, information storage, and cryptography, or that the new contract requires conditions or information storage times different from those handled by the organization, or even requires compliance with an information security standard that the organization does not currently have.Intellectual property rights (5.32)
This control addresses intellectual property (IP) rights, which are also part of legal compliance and are an area that deserves special attention. IP can be of great value, so it is important to properly document one’s own intellectual property and the use of that belonging to others. Incorrect (accidental) use of someone else’s IP can lead to major lawsuits and must be avoided at all costs.Records protection (5.33)
This control indicates that all records, whether accounting, process, or audit records, must be protected. Records are at risk of being lost, compromised, or accessed without authorization. Record protection requirements may come from the organization itself or from other sources, such as legislation or insurance companies. For this reason, clear and strict guidelines must be created and followed.Privacy and protection of personally identifiable information (5.34)
This control indicates that, depending on the country or economic area in which an organization is located, different legislation on personal data protection may apply. Organizations located in the EU and/or that process personal data of EU citizens are subject to the General Data Protection Regulation (GDPR). Organizations must ensure that they are aware of the requirements established by such legislation and follow it rigorously. The GDPR, for example, requires data processing agreements, maintaining a record of processing activities, and transparency in data processing. Many countries today have equivalent regulations that seek to achieve the same objective: protecting personal information. All these regulations must be complied with, either because the organization operates in that geographical environment or because it provides services to customers located in those jurisdictions.
It is important to note that, in addition to this control, the controls provided in ISO/IEC 27018 and ISO/IEC 27701 remain valid.
Independent review of information security (5.35)
This control indicates that it is impossible for organizations to objectively review their own information security system. For this reason, organizations must have their information security management system audited by an independent party on a regular basis, or when major changes occur. In this way, the organization maintains a correct and transparent view of the state of its information security. An independent party may also be a full‑time internal auditor whose sole task is to perform internal audits and who has no other conflicting tasks or responsibilities.Compliance with information security policies and standards (5.36)
This control indicates that compliance with all security policies, standards, and procedures must be reviewed periodically to ensure that the activities and/or processes for which they are responsible are being carried out properly. To do this correctly, those responsible must know exactly which standards and requirements they must comply with and verify them manually or with an automated reporting tool.
Information systems must also be reviewed periodically to verify their compliance. The simplest and generally most cost‑effective way to do this is through automated tools. These tools can quickly check every corner of a system and report exactly what has gone wrong or could go wrong. Vulnerability testing, such as penetration testing, can effectively show any weak points, but could actually damage the system if performed without caution.
Documented operating procedures (5.37)
This control indicates that the operating procedures for operational tasks, applications, and equipment must be documented and made available to those who use them. From the simple procedure for using a computer (from startup to shutdown) to the use of more complicated equipment, there must be guidance on how to handle them safely and correctly. Due to their importance, procedures must be treated as formal documents, which means that any change must be approved by management.
References
ISO/IEC 27002:2022, Information security, cybersecurity and privacy protection — Information security controls, https://www.iso.org/standard/75652.html
ISO/IEC 27002:2013, Information technology — Security techniques — Code of practice for information security controls, https://www.iso.org/standard/54533.html
