ISO 27001

Media coverage of security incidents is increasing: whereas in the past information security incidents were only reported in selected specialist publications, today they are reported almost daily in mainstream newspapers. The increase in such incidents is not surprising, given that everyone is constantly connected to everyone else as a result of ever-increasing networking and digitalisation. In addition to the ever-increasing number of incidents, another consequence of this development is that information security incidents are much larger in scale than in the past, when the degree of connectivity and the number of users were much smaller. Today, when major information security incidents become public, the number of people affected is often in the millions – for example, many online services are used by a very large number of people.

As the number of such incidents continues to rise, regulators around the world are issuing more and more new regulations that require a methodical approach to dealing with such incidents. What is usually required is a systematic approach to proactively managing not only incidents in particular, but all aspects of information security in general in an orderly manner. This is called an Information Security Management System. The common abbreviation is ISMS, which we will use in the following. The international standard ISO 27001 describes such an ISMS.

Establish and operate an ISMS with ISO 27001: This is what it is all about

But what exactly is an ISMS? And what is information security? And how is information security different from IT security?

Let’s start with the basic terminology: information security deals with the protection of all information in an organisation, whether it is analogue on paper or digital in an IT system. IT security is a sub-discipline of information security and deals with measures to protect information technology systems. In other words: Information security is the overarching concept that deals with the ‘big picture’, while IT security focuses specifically on the protection of IT systems and services.

The two terms are often used interchangeably – but the distinction is important: information security should not be seen as just a task for IT. On the contrary, it is a classic cross-functional task that should involve not only IT, but also many other departments such as HR, Finance or Procurement, as well as any third parties involved. Third parties can include service providers and customers, but also other interested parties such as regulators or other stakeholders. The groups of people involved in the ISMS are called stakeholders in the jargon of the standard.

ISO 27001 and the triangle of information security

In the context of ISO 27001, the triangle of information security is often referred to as the three protection objectives of confidentiality, integrity and availability. Some publications also refer to the so-called primary protection objectives, but the international standard ISO 27001 does not use this term.

Protecting information from loss of confidentiality means ensuring that only authorised people have access to it. Loss of confidentiality occurs when unauthorised persons have been able to gain access to protected information. This is referred to as a confidentiality compromise information security incident.

The integrity protection objective describes the intention to protect data and information from deliberate or accidental falsification. Ensuring integrity means that data and information remain unchanged during storage and/or transport. If this is no longer guaranteed, i.e. data has been tampered with, this is called a loss of integrity – and a corresponding information security incident has occurred.

Ensuring availability means ensuring that authorised people have access to data and information when they need it. Attacks on availability are often carried out by ransomware Trojans, which encrypt data and information, preventing authorised people from accessing it. This is known as an availability impacting information security incident.

ISO 27001 and its most important protection goals

In addition to the three protection objectives of confidentiality, integrity and availability, the operation of an ISMS may aim to achieve other protection objectives. Examples include authenticity, which refers to the unquestionable authenticity of information or entities, or non-repudiation, which means that the sending or transmission of information cannot be denied. Another example is accountability. This means that the responsibility for a value, such as information, can be attributed to an entity without any doubt.

Finally, the 2022 version of ISO 27001 explicitly mentions cybersecurity and data protection in its title. In the context of ISO 27001, cybersecurity describes the use of technology and processes to protect information and the systems in which it is stored from attack.

In the context of ISO 27001 – as in the context of the General Data Protection Regulation (GDPR) – data protection describes protection against the improper processing of personal data and the right to informational self-determination.

Information security management: definition and explanations

Next, let’s look at the term Information Security Management System (ISMS): an unwieldy word in itself, but what does it mean?

Often this term refers to an IT system, e.g. an application to map the necessary processes for an ISMS, but this is not the real meaning of the term. The term refers primarily to the interaction of principles, planning activities, clearly assigned responsibilities, processes/procedures and resources. These elements together make up an ISMS. Consequently, an ISMS is primarily a methodical approach to establishing, maintaining and developing information security in an organisation with appropriate resources.

Of course, any reasonably modern organisation will not do this with paper and pencil, but will use one or more IT systems for this purpose – but first and foremost an ISMS describes a methodical approach that includes the elements mentioned – and not an IT system that supports the necessary processes.

The ISO standard and the Deming circle for continuous improvement

The same applies to other types of management systems, such as quality management or environmental management systems. All ISO management systems follow the Deming Cycle, also known as the PDCA Cycle. Often referred to as the original model of continuous improvement and named after its inventor, William A. Deming, the Deming Cycle divides any improvement activity into four phases: Plan, Do, Check and Act. In the Plan phase, a plan is drawn up to achieve a specific goal. In the Do phase, the plan is implemented; in the Check phase, the results are checked against the goal. Finally, in the Act phase, there is an opportunity to readjust in the event of deviations from the planned goal – before a new cycle begins. William A. Deming demonstrated that the maturity and quality of processes increase over time when the PDCA approach is followed. All ISO management system standards, including ISO 27001 on information security management, are based on Deming’s circle.

ISMS and their scope of application

An Information Security Management System always has a defined scope. The parts of an organisation that are covered by the specifications of the ISMS are called the scope. For example, the scope may cover one or more locations of an organisation, or it may include specific technologies. The parts of the organisation covered by the scope are subject to the requirements of the ISMS – all others are not. In smaller organisations the scope often covers the whole organisation, whereas in larger organisations there may well be several ISMSs – or even areas not covered by an ISMS.

An information security officer is not mandatory for an ISMS

Responsibility is one of the aspects that the standard addresses at various points. Contrary to popular belief, ISO 27001 does not require ISMS operators to appoint an Information Security Officer. Instead, the standard requires that responsibility for information security is appropriately embedded within an organisation. In this context, it is natural to establish and fill the role of Information Security Officer – often referred to as ISB or ISO (Information Security Officer).

However, the holder of this role is not solely responsible for the information security of an organisation. Instead, the role should be designed to coordinate all information security activities. In other words, the ISB(s) is “accountable” in the sense of a holistic end-to-end responsibility, all other stakeholders are “responsible” for their respective individual tasks that arise in the context of ISMS operation. In other words: The ISB is responsible, but at the same time all other stakeholders are responsible for the implementation of the ISMS. All stakeholders should receive regular training to make them aware of their contribution to an effective ISMS.

ISO 27001 and its essential components

The international standard ISO 27001 consists of two main parts. On the one hand, there are the chapters 4-10 of the standard, often referred to as the “normative minimum requirements”. Any organisation claiming that its ISMS conforms to the standard – for example, in the context of a certification audit – must meet all the requirements in chapters 4-10 of the standard.

ISMS operators cannot therefore choose to omit one or other of the standard’s requirements – this would inevitably lead to a major discrepancy in a certification. You can read more about ISO 27001 certification below.

The second major part of ISO 27001 is the so-called “Annex A”. This part of the standard contains a list of possible measures that can be used to address identified information security risks.

Although Annex A is considered normative, contrary to popular belief, it is not mandatory to implement all of the controls in Annex A. The list of controls in Annex A is not exhaustive. In contrast to the normative minimum requirements (chapters 4-10 of the standard), all of which must be implemented if conformity with the standard is claimed, Annex A measures can, should and may also be excluded (“scoped out”).

This can be done, for example, if no risk has been identified for which the measure could be required. Conversely, the implementation of a control does not necessarily require an explicitly documented risk. See below for more information on information security risk management.

In addition, controls may be implemented for other reasons. Examples include contractual obligations entered into by the ISMS operator, or legal requirements that make the implementation of a control mandatory. Good practice”, i.e. the fact that the implementation of a certain measure is considered to be common practice, can also be a reason for implementation. We will return to the implementation of (Appendix A) controls later.

The overall objective of an ISMS within the framework of ISO 27001

The overall objective of an ISMS is to preserve and maintain confidentiality, integrity and availability by appropriate means. “Reasonable means” means that the effort expended on those means – essentially the actions taken – should be proportionate to the results they are intended to achieve.

For example, investing in an encryption solution to encrypt data with a low need for protection may not meet this requirement; the protection objective may be achieved by other measures that may be more cost-effective.

It should be noted that ISO 27001 does not require or prescribe an absolute level of information security. For example, nowhere in the standard is there a mandatory requirement to encrypt sensitive data. Often the implementation of the appropriate measure from Annex A on encryption will be obvious – but the standard does not explicitly require that encryption is mandatory. This example is for illustration only – and applies by analogy to all other technical and organisational measures.

ISO 27001 as the basis for certifications

ISO 27001 is the basis for conformity assessment, i.e. certification. ISMS operators can have their organisation’s information security management system assessed against the standard and, if it passes, receive a certificate attesting to its compliance.

It is important to understand what exactly is being certified. It is not a product, a service, a data centre or an application – it is the organisation that is the focus of the certification. An ISO 27001 certificate attests to a systematic and methodical approach to managing information security to the extent described and in accordance with the requirements of the standard.

Although it is often suggested, often in an advertising context, that an ISO 27001 certificate is a product certification, this is not the case. Although specific products, services, data centres, sites, departments or even applications are always included in the scope of a certificate, it is always the organisation, or at least part of it, and its methodical approach to information security that is certified.

ISO 27001: Scope of the ISMS and scope of the certificate may differ

We have already explained the concept of the scope of an ISMS above. It is important to distinguish between the concepts of “scope of the ISMS” and “scope of the certificate”. In principle, the scope of the ISMS and the scope of the certificate can be different; this can be the case, for example, if an organisation has defined an ISMS scope covering several sites, but only wants to have one of these sites certified. In this case, the scope of the certificate will only cover a subset of the ISMS scope.

In smaller organisations, the ISMS scope and the certificate scope are often congruent. In English there is only the word “scope” for both – so it is recommended to always add which scope is meant – the “scope of ISMS”, the scope of the ISMS, or the “scope of certification”, the scope of the certification. Therefore, during certification audits, only those issues that are within the scope of the certificate will be examined – all other issues will be ignored.

Systematically protect values and assets with ISO 27001

The overall objective of ISO 27001 is to identify elements worth protecting – the standard refers to these as values in German and assets in English – and to protect them appropriately in terms of the protection objectives mentioned. Values or assets can be, for example, all information, documents, services, hardware and software worth protecting, but also intangible values such as reputation and standing. The basic consideration is always to first identify the assets worth protecting based on the defined scope of the ISMS.

Many technology-focused organisations perform this asset analysis based solely on technology components – e.g. servers and cloud services. Such an approach only partially meets the intent of the standard; of course, data and information worth protecting are processed on servers and/or cloud services.

However, the focus of consideration should be primarily on the data and information itself that is worth protecting. A data and information based approach ensures that no important information asset is forgotten. It also enables the ISMS operator to become aware of the ‘crown jewels’ of their own organisation.

In a second step, the focus can and should be on the IT systems that contain this data and information. Part of asset identification is the analysis of the protection needs of the data – in terms of the protection objectives of confidentiality, integrity and availability. Once assets have been identified, information security risk management is carried out for those assets – and based on the results, one or more risk management measures are implemented.

Managing information security risks with ISO 27001

ISO 27001 promotes a risk-based approach where information security risks are regularly assessed and managed through a defined information security risk management process. The overarching process is called information security risk management, which consists of two activities: risk assessment and risk handling.

The risk assessment itself is divided into three activities: identification, analysis and evaluation of risks. The standard specifies the ‘what’ – it says that these activities should be carried out, but not exactly how. The “how” is at the discretion of the ISMS operator. This can be based on recommendations from the ISO 27000 series of standards – ISO 27005 describes a possible risk management approach. Alternatively, any other framework can be used, such as the US NIST Risk Management Framework. The important thing is that the requirements of the standard are met – not how.

In information security risk management, the first step is to conduct a risk assessment based on an organisation’s assets or values. The relevant risks are identified, analysed and assessed. The risk treatment is then based on the results.

In principle, it is recommended that the risk assessment of a risk is rigorously completed before the risk treatment begins. This ensures that no unnecessary measures are taken that may not have been necessary upon closer examination during the assessment.

Options for risk management according to ISO 27001

The standard provides several options for risk management: Risks or their impact can be reduced. This is usually done by implementing controls – often one or more controls from Annex A of ISO 27001. In addition, further measures may be required and implemented – these are often referred to as ‘custom controls’.

The implemented controls are listed in the Statement of Applicability (SOA), together with information on the status of implementation and a justification for the inclusion of the control. The SOA also lists the measures from Appendix A that have not been implemented – a justification for why a measure has not been implemented must be provided.

Another way of addressing risk under ISO 27001 is through risk prevention. For example, a risk-triggering business process is changed in such a way that the risk no longer occurs in that form. This may be particularly useful if the risk is associated with a very large potential loss.

Risk transfer usually involves a third party, such as an insurance company, guaranteeing to pay the financial consequences of a loss. Often, this is only a viable option if the expected impact of the risk is purely financial and not immaterial damage such as to reputation or public image.

Finally, there is the option of consciously accepting risk. Here, care should be taken to make an informed decision. This means that the impact of the risk and the probability of its occurrence should be realistically assessed in order to avoid prematurely accepting the risk. The best way to achieve this is to have the risk assessed by several people, if possible, and to have the risk acceptance approved by different levels of the organisation, depending on the level of damage. As a rule of thumb, the higher the expected loss and the higher the probability of occurrence, the higher up in the organisation’s hierarchy the decision-maker should be who approves risk acceptance.

Risk treatment plan allows flexible design

A risk treatment plan formulates the measures to be taken to deal with each risk. There are no formal specifications for this risk treatment plan; the standard specifications are limited to stating that a risk treatment plan should be maintained, without specifying exactly what it should contain. ISMS operators therefore have some flexibility in the design of this document.

ISO 27001 and Annex A: Dealing with individual measures in detail

The previous sections have already covered some of the risk management measures, specifically those from Annex A of ISO 27001. In principle, Annex A of ISO 27001 is prescriptive. However, this does not mean that every single control has to be implemented. We have already explained above that individual controls can be excluded for good reasons. This follows directly from chapter 6.1.3 d) of the standard.

Furthermore, it is even possible to “scope out” the entire Appendix A, i.e. declare it not applicable and use another framework instead – e.g. the NIST Cyber Security Framework. This is often recommended where organisations have other requirements (e.g. SOC 2) in addition to ISO 27001 and cannot or do not want to implement a separate set of controls for each requirement.

The standard requirements 6.1.3 b) and c) open up this possibility. In this context, the comments on the above-mentioned standard requirements are particularly important. These state that “organisations (…) can design measures as required or select them from any source”. Furthermore, 6.1.3 c) describes Annex A as a “list of possible information security measures”.

The commentary goes on to say that the measures listed are not necessarily exhaustive. This results in the possibility – and sometimes the necessity – to implement own measures (“custom controls”). And these custom controls can either be created by the ISMS operator or taken from another set of controls, such as the NIST Cyber Security Framework.

If an ISMS operator decides to use a different set of controls, it is still necessary to compare the defined controls with Annex A of ISO 27001 to ensure that no required controls have been omitted. The justification for omitting measures from Annex A can then be, mutatis mutandis, that other alternative measures have been selected that fulfil the same purpose.

ISO 27001 and the documentation requirement

In the previous chapters we have looked in detail at individual aspects of the standard. The question arises as to how corresponding evidence is to be kept within the framework of certification. Basically, the operation of an ISMS goes hand in hand with a minimum of documentation. Specifications – i.e. guidelines, procedures, other documents – must be set down in writing, released and communicated to the affected stakeholders.

The standard speaks here of steering documented information. This does not necessarily mean that the amount of documented information is important. Short and comprehensible specifications are always preferable to long prose texts. If you look at the specifications documents from the perspective of the people who are supposed to comply with the specifications, the idea of “less is more” immediately comes to mind. Approval processes can and should be streamlined and not over-bureaucratised.

In addition to the requirements, evidence of the application of these requirements must also be kept – the so-called “records”. For example, one requirement might be to regularly check highly privileged user access to particularly sensitive information. It seems immediately clear that the requirement alone is useless – if it is not implemented.

The implementation must be documented as evidence. A bon mot of auditors to be mentioned here is “not documented, not done” – which means that what was not documented was not done. ISMS operators should therefore make sure to create appropriate documentation (“records”) as proof of implementation. The standard does not say how this should be done and in what form. ISMS operators are free to decide how the records are kept. The evidence is often kept in the form of tickets, but written documentation with pen and paper can also meet the standard.

ISMS operators can determine the type and manner of documentation themselves

Here, too, the principle applies that “documented information” should be kept – but the standard does not explicitly say what this should be and what it should look like. This in turn allows ISMS operators a certain degree of freedom. Organisations can determine the type and scope of the documented information themselves. The standard even explicitly mentions in the commentary on standard requirement 7.5.1 that the scope of documented information of an ISMS can differ from organisation to organisation. Reasons given include the size of the organisation and the complexity of the processes.

Basically, the leaner the documentation, the better.

It is therefore by no means the case that a start-up has the same documentation requirements as a large corporation. Rather, as an ISMS operator, you have some leeway – which you should make use of. A certain pragmatism is advisable in order to keep the documentation as lean as possible – and not to over-bureaucratise the ISMS.

Conclusion: Operating and certifying an ISMS is a task for many stakeholders.

In summary, the establishment and operation of an ISMS is primarily an organisational task – not an inherently IT issue. The key to success is to embed the processes as widely as possible in the chosen area of application of the ISMS – and to involve as many stakeholders as possible who are assigned to the area of application.

The success of an ISMS stands and falls with its acceptance within the organisation and the recognition of the added value it brings to the organisation as a whole and to its individual stakeholders. Stakeholders who are aware of the importance of their contribution to maintaining and continuously improving the level of information security will behave responsibly and integrate the requirements of an ISMS into their daily business.

This fulfils one of the core requirements of ISO 27001 – the distribution of tasks and responsibilities across as many shoulders as possible. If this is achieved, successful certification of the ISMS is usually “only” the result of well-rehearsed ISMS processes.