# Annex A Annex A of 27001 provides a list of Information Security controls that need to be at least considered as a part of the ISMS process. These controls are detailed in Clauses 5 to 8 of a sister standard to 27001, 27002 ([[The ISO 27000 Family]]). Section 6.1.3 of the standard directs the reader to select risk treatment options as a result of a risk assessment, and identify necessary controls to modify these risks. The mechanism that the user is required to use for this process is to at some point compare their own selected controls with those in Annex A to ensure that "no necessary controls have been omitted". The resultant (and mandatory) document that comes from this is called a Statement of Applicability. This document lists the controls that are being used to treat identified risks, an implementation tracker for these controls, and a justification for the exclusion of any Annex A controls that are not in place. **Annex A controls are not mandatory**. The mandatory requirement is that they are systematically considered and compared against the ultimate selection of controls that are selected, and a justification is provided as to why these Annex A controls have not been selected. ## The shape of controls in 27002 ISO/IEC **27002**:2022 details the controls in more detail, and provides an organisational structure that helps navigate the types of controls (Which we explain below). 27002 is a wonderful opportunity to find a structuring force for considerations of controls in an organisation, because it systematically provides guidance on the implementation of controls that are required for consideration by virtue of the 27001 process. Each control has a layout that will always contain a title, a description of the control, the intended purpose of the control, guidance for it's implementation, and a dedicated section for miscellaneous information. The standard also produces an attribute table that tags loads of 'meta data' that helps categorise that control in myriad ways. This can be a bit windy so these categories, attributes, and themes are expanded on a bit below. ## Categories, Themes, and Attributes Controls have one of four categories, referred to as '**Themes**'. These themes are: | Theme | Coverage | | -------------- | ------------------------------------------------------- | | People | Controls concerning people | | Physical | Controls concerning physical objects | | Technological | Controls concerning technology | | Organisational | Every control that doesn't fit into a different 'theme' | Each control also has five '**Attributes**' that are populated with descriptive hashtags - sort of like metadata, so that each control can be associated with a more precise set of descriptors. The idea is that this makes the data set of a whopping 93 controls a bit more manageable by being searchable using precise terms. Here are the attributes: | Attribute | Summary | | ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Control Type | 'Control Types' aim to communicate at what point the control modifies the risk it targets - is it a control intended to **prevent** an incident, **detect** one that's already occurred or is occurring, or to **correct** course after an incident occurs? | | Information Security Properties | 'Information Security Properties' identify which part of the CIA triad is to be affected or targeted by this control. The CIA Triad identifies the 'security' of information as relating to one of three characteristics. These are **Confidentiality**, **Integrity**, or **Availability**. | | Cybersecurity Concepts | 'Cybersecurity Concepts' refers to the conceptual breakdown of cybersecurity into a framework defined by another ISO Standard called ISO/IEC 27110. It's not dissimilar to other frameworks for procedural cyber security, and the options are '**Identify**, **Protect**, **Detect**, **Respond**, and **Recover**' | | Operational Capabilities | The 'Operational Capabilities' attribute focuses on the regular business functions of an organisation as relating to information security. There are about fifteen of these, and some representative attributes are: '**Physical Security**', '**Supplier Relationship Security**', and '**Legal and Compliance**'. | | Security Domains | The 'Security Domains' is another lens to assess a control against four domains that themselves have sub sets of domain topics. These domains are '**Governance and Ecosystem**', '**Protection**', '**Defence**', and '**Resilience**'. | # Notes > **Annex B** of ISO/IEC **27002**:2022 provides correspondence tables for backwards compatibility with ISO/IEC 27002:2013, so organisations that are migrating can map out controls effectively. This is a function that has largely been ingested into automation for most big solutions to ISMS building - but there are still going to be use cases where this is really helpful.