ISO 27001:2022 Clause 4 Context of the organization

by Pretesh Biswas

Audio version of the article


Clause 4: Context of the organization

As per  ISO, the definition of Context of the Organization is “business environment“, a “combination of internal and external factors and conditions that can have an effect on an organization’s approach to its products, services and investments and interested Parties“. The concept of Context of Organization is equally applicable to Not-for-profit organizations, public service organizations, and governmental organizations. Also in normal language, this concept is also known as the business environment, organizational environment, or ecosystem of an organization.

Information security management is a major issue worldwide. It describes the behaviors of commercial organizations and government bodies, many of whom are seizing opportunities to analyze their records of customer and citizen personal information. Merging this with volumes of traded ‘anonymized’ data, these organizations aim to harvest new insights, seeking competitive advantages and efficiencies. There is also a wider black market trade that includes personal account IDs and passwords, credit card details, commercial intellectual property, and sensitive financial data. The value of that information is motivating theft, funding organized crime, satisfying nation-state espionage, and driving the evolution of globally-dispersed technical threats to challenge established operational principles and practices. Organizations are increasingly embracing online opportunities to promote their business and consolidate their position in the marketplace through the use of mobile device applications and social networking presence. Mobile devices and ‘the internet of things’ have dissolved traditional organizational perimeters and are dispersing information both geographically and logically across the internet. This presents a wide exposure to diverse and sophisticated technical threats.

Clause 4 requires an organization to establish the context of its ISMS. It has to determine its needs and expectations and those of interested parties and decide the scope of the ISMS. The new “context” clause requires an understanding of the organization and its needs, determine external and internal issues and consider interested parties and their requirements. Requirements of interested parties may include legal and regulatory requirements and contractual obligations. Context determines the information security policy and objectives and how the organization will consider risk and the effect of risk on its business. An appropriate scope for the ISMS is now required. This clause in part addresses the depreciated concept of preventive action and in part establishes the context for the ISMS. It meets these objectives by drawing together relevant external and internal issues (i.e. those that affect the organization’s ability to achieve the intended outcome(s) of its ISMS) with the requirements of interested parties to determine the scope of the ISMS. It should be noted that the term ‘issue’ covers not only problems, which would have been the subject of preventive action in the previous standard, but also important topics for the ISMS to address, such as any market assurance and governance goals that the organization might set for the ISMS. Note that the term ‘requirement’ is a ‘need or expectation that is stated, generally implied or obligatory. Combined with Clause 4.2, this in itself can be thought of as a governance requirement, as strictly speaking an ISMS that did not conform to generally-accepted public expectations could now be ruled non-conformant with the standard. The final requirement (Clause 4.4) is to establish, implement, maintain and continually improve the ISMS in accordance with the requirements of the standard.
To establish an ISMS the organization needs to define the ISMS which includes the following steps:


4.1 Understanding the organization and its context

The organization must determine its external and internal issues which should be relevant to its purpose and can affect its ability to achieve the intended outcome of its information security management system. While determining these issues the organization can refer to establishing the external and internal context of the organization as given in Clause 5.3 of ISO 31000:2009. ISO 31000 is a standard that provides guidelines for risk management, and this is what it suggests could be included when identifying internal and external issues. Please note that ISO 31000 gives guidelines only; therefore, they are not mandatory.


The idea of the context of the organization’s overall business is maintained here. There is an explicit requirement to consider both internal and external issues which might impact the organization’s purpose and affect its ability to achieve the expected outcomes of the ISMS. External and internal issues have to be determined that are relevant to the organization’s purpose and that affect its ability to achieve the intended outcome(s) of its information security management system. There are expectations that these considerations and resulting conclusions will need to be documented. To reinforce the theme that runs throughout the Annex SL there is a note referencing ISO 31000 Risk management – Principles and guidelines. Here you have to understand your organization and its context. Identify and understand your organization’s context before you establish its information security management system (ISMS).  Identify the internal issues that are relevant to your organization’s purpose and consider the influence these issues could have on its ability to achieve the outcomes that its ISMS intends to achieve. You have to determine the influence your internal stakeholders could have. Determine the influence your approach to governance could have.  Determine the influence your organization’s capabilities could have.  Determine the influence your organization’s culture could have. Determine the influence your organization’s contracts could have. You have to identify the external issues that are relevant to your organization’s purpose and consider the influence these issues could have on its ability to achieve the outcomes that its ISMS intends to achieve. You have to determine the influence environmental conditions could have. Determine the influence key trends and drivers could have.  Determine the influence external stakeholders could have.


An organization’s risk assessment process should address the strategic, organizational, and security risk management contexts. Security risk management is applicable across all facets of an organization’s functions, or activities. In particular, the risk assessment needs to be appropriate to the prevailing and emerging risk environment. Establishing the context is critical as it sets the basis on which all subsequent risk assessment activities are conducted. The Step in establishing the context could include:

1. Communication & Consultation

Communication and consultation with external and internal stakeholders should take place during all stages of the establishing Organizational context. Therefore, plans for communication and consultation should be developed at an early stage. These should address issues relating to the ISMS itself, its causes, its consequences (if known), and the measures being taken to treat it. Effective external and internal communication and consultation should take place to ensure that those accountable for implementing the management process and stakeholders understand the basis on which decisions are made, and the reasons why particular actions are required. A consultative team approach may:

  • help establish the context appropriately;
  • ensure that the interests of stakeholders are understood and considered;
  • help ensure that risks are adequately identified;
  • bring different areas of expertise together for establishing context;
  • ensure that different views are appropriately considered when determining organizational context, defining risk criteria and in evaluating risks;
  • secure endorsement and support for a treatment plan;
  •  enhance appropriate change management during the whole  process; and
  • develop an appropriate external and internal communication and consultation plan.

Communication and consultation with stakeholders are important as they make judgments based on their perceptions. These perceptions can vary due to differences in values, needs, assumptions, concepts, and concerns of stakeholders. As their views can have a significant impact on the decisions made, the stakeholders’ perceptions should be identified, recorded, and taken into account in the decision-making process. Communication and consultation should facilitate truthful, relevant, accurate, and understandable exchanges of information, taking into account confidential and personal integrity aspects.

2. Establishing the context of ISMS

By establishing the context, the organization articulates its objectives, defines the external and internal parameters to be taken into account when managing risk, and sets the scope and risk criteria for the remaining process. While many of these parameters are similar to those considered in the design of the Information Security management framework, when establishing the context for the ISMS processes, they need to be considered in greater detail and particularly how they relate to the scope of the particular management process.

3. Establishing the external context

The external context is the external environment in which the organization seeks to achieve its objectives. Understanding the external context is important in order to ensure that the objectives and concerns of external stakeholders are considered when developing its Security risk criteria. It is based on the organization-wide context, but with specific details of legal and regulatory requirements, stakeholder perceptions, and other aspects specific to the scope of the Information Security management process. The external context can include, but is not limited to:

  • the social and cultural, political, legal, regulatory, financial, technological, economic, natural and
  • competitive environment, whether international, national, regional or local;
  • key drivers and trends having an impact on the objectives of the organization;
  • and relationships with, perceptions and values of external stakeholders.

4. Establishing the internal context

The internal context is the internal environment in which the organization seeks to achieve its objectives. The Information Security management process should be aligned with the organization’s culture, processes, structure, and strategy. Internal context is anything within the organization that can influence the way in which an organization will manage its Security risk. It should be established because:

  1. risk management takes place in the context of the objectives of the organization;
  2. objectives and criteria of a particular project, process or activity should be considered in the light of objectives of the organization as a whole; and
  3. some organizations fail to recognize opportunities to achieve their strategic, project or business objectives, and this affects ongoing organizational commitment, credibility, trust, and value.

It is necessary to understand the internal context. This can include, but is not limited to:

  • governance, organizational structure, roles, and accountabilities;
  • policies, objectives, and the strategies that are in place to achieve them;
  • capabilities understood in terms of resources and knowledge (e.g. capital, time, people, processes, systems, and technologies);
  • the relationships with and perceptions and values of internal stakeholders;
  • the organization’s culture;
  • information systems, information flows and decision-making processes (both formal and informal);
  • standards, guidelines, and models adopted by the organization and form and extent of contractual relationships.

5. Establishing the context of the risk management process

The objectives, strategies, scope, and parameters of the activities of the organization, or those parts of the organization where the risk management process is being applied, should be established. The management of risk should be undertaken with full consideration of the need to justify the resources used in carrying out risk management. The resources required, responsibilities and authorities, and the records to be kept should also be specified. The context of the risk management process will vary according to the needs of an organization. It can involve, but is not limited to:

  • defining the goals and objectives of the risk management activities;
  • defining responsibilities for and within the risk management process;
  • defining the scope, as well as the depth and breadth of the risk management activities to be carried out, including specific inclusions and exclusions;
  • defining the activity, process, function, project, product, service or asset in terms of time and location;
  • defining the relationships between a particular project, process or activity, and other projects, processes or activities of the organization;
  • defining the risk assessment methodologies;
  • defining the way performance and effectiveness is evaluated in the management of risk;
  •  identifying and specifying the decisions that have to be made;
  • and identifying, scoping or framing studies needed their extent and objectives, and the resources required for such studies.

Attention to these and other relevant factors should help ensure that the risk management approach adopted is appropriate to the circumstances, to the organization, and to the risks affecting the achievement of its objectives.

6. Defining risk criteria

The organization should define criteria to be used to evaluate the significance of the risk. The criteria should reflect the organization’s values, objectives, and resources. Some criteria can be imposed by, or derived from, legal and regulatory requirements and other requirements to which the organization subscribes. Risk criteria should be consistent with the organization’s management policy, be defined at the beginning of any management process, and be continually reviewed. When defining risk criteria, factors to be considered should include the following:

  • the nature and types of causes and consequences that can occur and how they will be measured;
  • how likelihood will be defined;
  • the time-frame of the likelihood and/or consequence;
  • how the level of risk is to be determined;
  • the views of stakeholders;
  • the level at which risk becomes acceptable or tolerable;
  • and whether combinations of multiple risks should be taken into account and, if so, how and which combinations should be considered.

The ISO 27001 standard is structured according to the “Plan-Do-Check-Act” (PDCA) model. In the Plan phase, an ISMS is established, in the Do phase the ISMS is implemented and operated, in the Check phase the ISMS is monitored and reviewed, and in the Act phase, the ISMS is maintained and improved. In the Plan phase, the scope and boundaries of the ISMS, its interested parties, environment, assets, and all the technology involved are defined. In this phase also the ISMS policies, risk assessments, evaluations, and controls are defined. Controls in the ISO 27001 are measures to modify risk. The context of the organization starts with a gathering of information about the organization. The next activity is the context establishment. This initial step is important for all following steps and is responsible, whether the risk management can be implemented to a sufficient extent and on a sufficient level of detail. The next step is risk identification, which determines the potential loss. Then risk estimation tries to rate the consequences of loss on a qualitative or quantitative scale as well as the likelihood of occurrence. The risk evaluation step compares the level of risks against the risk acceptance criteria, defined during the context establishment. Then, the risk treatment step sets up the controls. In the risk acceptance step, residual risks have to be accepted by managers of the organization.


Example of External issues relevant for ISMS

  1. Legal and regulatory.
    XXX recognize there are legal and regulatory requirements over and above the requirements as established by our internal requirements.
1. Contract law A contract is a legally enforceable exchange of promises. Any agreement we enter into must follow a set format or it could be invalid
2. Information Technology Act 2000 and its Amendment, 2008Legislation Covering IT Act 2000 and its amendment 2008, We must ensure that all the requirements of these acts are covered.

2. Cultural

  • Personal data – There is a known external demand for personal data (especially financial i.e. Credit card details, address details and dates of birth) and significant inducements can be offered to staff for the collection of information this could affect “confidentiality‟.
  • Hacking and unauthorized interception of communications is an issue we know about targeting contact centers, this could affect “confidentiality”.
  • Wages in our industry are low and so bribery is an ever-present threat, this could affect “confidentiality‟.

3. Connectivity

  • Power and connectivity – utility failures are common and have occurred in the past. We have had power cuts due to local power demand increases that have interrupted mains power (new building and expanding businesses: the infrastructure cannot cope). IT connectivity has also been interrupted by this high demand. This could impact on ‘integrity’.
  • International clients are also expecting state-of-the-art technology, fast connection speeds for sales and call handling report visibility (statistics). This has an impact on our commitments contained in our service level agreements. 

4. Location

  •  Physical location, our location is in an area of high criminality (due to many hi-tech businesses located nearby) and adjacent offices have been attacked by thieves which could have an impact on “confidentiality‟.
  • Environmental – no particular flooding or storm damage is anticipated.

5. Competition

Employees could take XXX or customer information to a competitor. There are many competitors located close to our office. Staff can often move from our company to a competitor quickly. This could affect “confidentiality‟.

6. Economic pressures

  • It is understood that when some of our competitors are under pressure for new revenue, they may be more likely to illicit sources of information on our customers from our key employees. This could also entail poaching key members of staff and securing access to confidential information. The loss of a key member of staff with the customer data they have access to could impact us heavily. This could affect  “confidentiality‟ and the viability of XXXX.
  • In tight financial times, customers are seeking cost-saving alternatives, we are therefore seeing a large increase in sales inquiries putting pressure on our internal resources and IT and IS systems.

Example of Internal issues relevant for ISMS

1.Information systems

Some of our systems are old and due to be replaced. New systems will be more complex and possibly harder to support. Possible “integrity‟ issues.

2. Organization’s culture

Historically our company has been sales driven, the need to bring in work has outweighed other considerations such as “confidentiality‟. This has resulted in a misalignment between its strategic direction and IS policy. The integration of IS into the organization‟s sales processes may not be strictly adhered to and top management support to demonstrate leadership in IS may be compromised when large orders are at stake.

3. Relationships and perceptions and values of internal stakeholders

  • Historically we have had a high turnover in staff and this means staff could take data with them on departure. We understand that the skill sets of our call center staff are limited and as such documented processes and guidance are more important. Also comprehending the nature of IS policies and their importance and consequences may not be fully recognized and hence information security incidents are more likely.
  • Many skills and decision-making authorities are restricted to a very few senior staff who know each other very well, this has led to a competence and documentation „gap‟ through informality.

4. Human Resource Security and Capabilities (knowledge)

The high staff turnover has caused XXXX difficulties in retaining core knowledge, such as system support and customer relations. This may cause issues. Staff is recruited from the local workforce and because of the low wages and skills expectation, they may not be well off financially or well educated. This may leave them more vulnerable to bribery and corruption.

5. Governance, organization and roles and responsibilities

As a small company, responsibilities have been retained by a small management team. As we grow this may be difficult to achieve but is needed.

6. Standard working procedures and guides

Processes have not been documented because of their retention and ownership by senior individuals only. As we grow this lack of documentation may cause problems.

7. Contractual relationships with our suppliers

As a small new business, our purchasing power and influence are restricted; as we are not able to include IS requirements in contracts, also some suppliers do not have formal contracts with us. Hence the scope of our ISMS excludes all IS outsourced processes. As ‘Data Cleansing’ is a current outsourced process, this naturally causes our clients concerns around “Confidentiality‟ and “Integrity‟.


4.2 Understanding the needs and expectations of interested parties

The organization must determine the interested parties and their requirement that are relevant to and can be addressed through the information security management system. The requirements of interested parties may include legal and regulatory requirements and contractual obligations.


The organization shall determine interested parties that are relevant to the information security management system and the requirements of these interested parties relevant to and it can be addressed through information security. The organization must identify all of the parties that have an interest in your organization’s ISMS. and must also identify their requirements including their needs and expectations.  Let’s start with understanding what interested parties are – they are nothing else but stakeholders, i.e., persons or organizations that can influence your information security/business continuity or persons or organizations that can be affected by your information security or business continuity activities. So, typically, interested parties could include:

  • employees
  • shareholders/owners of the business
  • government agencies/regulators
  • emergency services (e.g., firefighters, police, ambulance, etc.)
  • clients
  • employee families
  • media
  • suppliers and partners
  • … and anyone else that you consider important for your business.

How can you identify them? Just ask your top executives, as well as heads of departments about who is important for their business, and then assess whether they could be interested in your information security or business continuity. Also, chances are that your existing documentation (e.g., business plans) already contains such information.
Having identified its interested parties, there are now demands on an organization to consider their needs and expectations. However, these needs and expectations are only those relevant to information security. There are expectations that these interested parties and their requirements will need to be documented. Previously the involvement of interested parties was restricted to feedback and communication; now they are at the heart of the ISMS. There is a note clarifying that legal and regulatory requirements and contractual obligations may be included in the requirements of interested parties. The identification of interested parties is not as important as the second step: identification of their requirements. Here’s why it is important: you need to know what all the interested parties want from you, and you need to figure out how to satisfy all these requirements in your ISMS. For example, shareholders want the security of investment and a good return, clients want you to comply with security clauses in the contracts you signed with them, government agencies want you to comply with information security continuity laws and regulations, the media want quick and accurate news related to your incidents, etc. However, you have to be more specific than this – you have to specify exactly which laws and regulations, which security or continuity clauses exist in the contracts, and so on. The best way to collect this information is to study their written requirements (legislation, contracts, etc.) and/or interview their representatives. Once you have all this information, you will need to “configure” your information security or business continuity to be compliant with your stakeholder expectations – this means you’ll have to identify the requirements before you start developing the details of your ISMS.  A good practice is to write a procedure that defines who is in charge of identifying all the interested parties and their legal, regulatory, contractual, and other requirements and interests; such a procedure also needs to define who is in charge of updating this information and how often this is done. If you work in a larger organization, such organizations usually have compliance departments or compliance officers – they would be the most natural department/person to do this kind of a job. If not, you can try to negotiate whether your legal department could do this job – if not them, then you, the information security or business continuity coordinator, will have to do it yourself. Once the requirements are clearly identified, you need to define who is in charge of complying with them – these responsibilities could be very different: IT department would be in charge of complying with technical requirements, human resources department for, e.g., confidentiality statements, information security coordinator with new policies and procedures, etc.


Examples of Understanding the Needs and Expectations of Interested Parties

The interested parties that are relevant to the ISMS of XXX have been determined below their individual expectations.

Requirements are as follows:

  1. To provide products, services, and maintenance support in accordance with contractual requirements.
  2. To provide products, services, and maintenance support in the event of any disruption.
  3. To Provide provide products, services and maintenance support in  accordance with applicable legal requirements.
  4. To Provide provide products, services, and maintenance support in accordance with any additional, applicable industry, third party or end-user requirements (e.g. NHS Digital, IGSoC approval).
  5. To provide products, services, and maintenance support at any time (24/7/365).
  6. ISO 27001 Compliance
  7. 99.9% Availability of Systems
  8. Meeting SLA (4hr response – contact center)
  9. PCI DSS Requirements 9 & 12
  10. To provide products, services, and maintenance support that add value.

2. End Users
Our products and services interact with various groups of end-users.
Requirements are as follows:

  1. Products and services that we directly provide, and those that our customers provide (using our systems), are available when required.
  2.  Our products and services are reliable and simple (to use).
  3. There is a simple and effective process to enable lone workers to specify accurate, complete and up-to-date personal details.
  4. Our products and services adequately protect personal data (contact details) and sensitive personal data (medical details).
  5. We can support our products and services at all times.
  6. In the event of a disruption, we can continue the operation of products and services that we directly provide, and continue to provide support for those that customers provide (using our systems).

3, Partners:
These may be agents or system partners, recruitment companies, or others. Their reputations may be damaged if we have a breach, we may be damaged if they have a breach. Our contracts with some key partners may have or need IS clauses.
Requirements are as follows:

  1. We provide any correct and complete technical information that they require, to enable them to amend, enhance, and rectify any faults in, their Application Programming Interface (API), in order to enable us to develop software that communicates and exchanges data with their API, in accordance with our requirements.
  2. We develop software in accordance with any mutually agreed schedule.
  3. Our relationship is not adversely affected by the departure or absence of any of our workers.
  4. We comply with any confidentiality and non-disclosure agreements.
  5. We provide required training, to enable the reseller to sell our products and services.
  6. We efficiently expedite orders.
  7. Adherence to contractual agreements

4. Suppliers and Contractors
Even a supplier may be affected by an incident if our use of their systems results in negative publicity for the supplier they may not want to supply us. Data suppliers may not trust us with marketing lists
Requirements are as follows:

  1. We purchase their products and/or services.
  2. Where applicable, we provide complete and accurate information when we require their technical support.
  3. Where applicable, we subscribe to their technical support.
  4. Adherence to contractual agreements
  5. Adherence to payment terms

5. Employees
We currently have approximately 30 employees, in roles of management, software development, computer and telephony engineering, sales, telemarketing, account management, finance, and administration.
Requirements are as follows:

  1. The company is profitable and provides secure work.
  2. The company provides a safe and appropriate work environment.
  3. The company provides the required training and support.
  4. The company clearly specifies its requirements and expectations of workers.
  5. Workers believe that they can positively contribute to the success of the company.
  6. The company facilitates dialogue with workers so that they are aware of their contribution.
  7. The company protects their personal information.
  8. The company pays fairly for work.
  9. The company provides opportunities for continuity of employment
  10. The company provides opportunities for advancement

6. Insurers
If fines or damages were the results of an incident (breach of contract or regulator) this would affect profits and so investors and owners. Our insurer may be liable to contribute depending on insurance wording.
Requirements are as follows:

  1. The Company should be meeting policy requirements
  2. The Company should be making timely payment of premiums
  3. The company should be reporting changes in circumstances

7. Management/Shareholders
Breaches could affect our share price or our investors could withdraw. The professional reputation of the company and its management could be questioned if we had a breach.
Requirements are as follows:

  1. Return on capital

8. Trade bodies/associations
Although we are not members of any trade bodies/associations we may seek to join at a later date. Organizations such as the Direct Marketing Association (DMA) have security requirements that we would need to follow.
Requirements are as follows:

  1. Membership requirements
  2. Meeting standards to which the organization adheres
  3. Provision of guidance
  4. Terms and Conditions for the workers

9. Regulators
We are not directly subject to any industry-specific regulatory authority, but we are subject to various legal requirements from applicable legislation.

10. Government agencies
With recent government breaches, government departments have to be squeaky clean, they have not inspected us yet but may in the future. The governments IL2/3/4 requirements around IS may affect us if we take on that sort of work.
Requirements are as follows:

If a breach broke the law we could be fined, face restrictions or directors face imprisonment.

10)  Media / Commentators
Interest in Information Security is growing, we should expect any incident to be reported and suffer bad publicity, perhaps suffering the loss of customers as a result.


4.3 Determining the scope of the information security management system

The organization must determine the boundaries and applicability of the information security management system to establish its scope. When determining this scope, the organization should take into account the external and internal issues referred to in 4.1; It must also take into account the requirements of its interested parties identified in clause 4.2; It must consider the interfaces and dependencies between activities performed by the organization, and those that are performed by other organizations. ISO 27001 requires you to write a document for the ISMS scope.


ISMS scope and boundaries determine the extent to which the ISMS is applied in an organization. Scoping is a critical part of planning the roll-out and implementation of an information security management system (ISMS). Identifying the right ISMS scope is crucial because it will assist organizations in meeting their security requirements and planning for ISMS implementation, for the organization e.g. determining resources, timeline, and budget required. Figure out what your organization’s ISMS should apply to and what its boundaries should be. However, if the scope is not accurately defined, this will result in unnecessary wastage of resources (in terms of time, cost, and effort) because, when risk assessment exercises are conducted on different scopes, it will result in inaccurate identification of information security risks. Furthermore, if the ISMS scope is not aligned with the organization’s security requirements, the organization may find that ISMS is a waste of time and resources; thus not valuing the benefits of implementing it. The scope of ISMS can be defined in terms of the organization as a whole, or parts of the organization. Use boundaries and applicability information to clarify the scope of your organization’s ISMS. The selected ISMS scope should be critical to the organization in meeting its business objectives. In general, the ISMS scope should cover the end-to-end process to deliver services and/ or produce products. It should cover the complete elements of people, process and technology, and relevant assets within the process. The ISMS scope should be derived from organizational known risks. For example, in a financial institution, the risks of unauthorized access to online transactions may give a critical impact on its business operations. Thus, the ISMS scope for this financial institution can be defined as online transaction services. Examples of questions that can guide organizations when defining the ISMS scope and boundaries:

  1. Which service in your organization will be covered by the ISMS?
  2. How and why is the selected service critical to your organization?
  3.  What are the characteristics of the selected service; i.e. business, the organization, its locations, assets, and technologies to be included in the ISMS?
  4. Will you require external parties to abide by your ISMS?
  5.  Are there any interfaces or dependencies between activities performed by the organization; and those performed by another? Should they be considered?

The amount of effort required to implement ISMS is dependent upon the magnitude and complexity (among others) of the scope to which it is to be applied. Nevertheless, organizations should consider factors such as information security and business requirements, expectations from stakeholders, and the expected resources when defining the ISMS scope. To ensure that the ISMS is implemented effectively, it should be viewed as an enabler to achieve organizational business objectives. In order to identify ISMS scope and boundaries, organizations should perform the following activities:

  1. Consider the organization’s information security requirements which have been identified in Clause 4.1 – Define Information Security Requirements;
  2. Consider any interfaces and dependencies between activities performed by the organization, and those that are performed by other organizations;
  3. Consider critical services that can cause a major impact on the organization and/or nation arising from losses of confidentiality, integrity or availability;
  4. Define the organizational scope and boundaries;
  5. Define Information Communication Technology (ICT) scope and boundaries,
  6. Define physical scope and boundaries; and
  7. Integrate elementary scope and boundaries to obtain the ISMS scope and boundaries.

For clarity, organizations may seek the advice of a Certification Body (CB) on the proposed ISMS scope and boundaries, as and when the need arises. Ensure that the ISMS scope is documented and approved by the top management. Control your organization’s ISMS scope document.


Purpose of formal scope definition

The scope definition serves the purpose of stating exactly what it is that an organization does that is certified to be effectively controlled by the requirements of the standard. Without a formal scope definition, the statement of an organization being ISO 27001 certified could mean a great deal or not much at all. The scope statement should state exactly what it is that an organization does that is certified to the standard.
A bad Example of scope could be XYZ company’s information security system.
This provides no details as to what products or services the company provides that have been found to meet the requirements of the standards.

An Example for scope could be The development, operation, and administration of the scheduling and planning Software as a Service platform provided by company XYZ.
This scope statement tells us that the fictional organization has been certified in not just the operation and administration of its SaaS platform, but also the development as well. This also means that the people and information systems associated with the development, operation, and administration of the system are in scope and need to meet the requirements of the standard as well. In the event this fictional company also provided other services, such as consulting, there should be no confusion or assumption that this separate service meets the requirements of the standard as it is not documented in the formal scope and wouldn’t have been subject to the certification audit.


Strategies for Determining and Defining the boundaries of your ISMS

  • First – Understanding your organization and the issues that are most relevant to it, and the needs and expectations of people and organizations who have the most interest in it. Please note that the requirements of people and organizations interested in your company should include any legal or regulatory requirements your organization is subject to. For example – if your company provides financial consulting, it would make sense to ensure that the people, processes, systems, and information involved with your client’s data is in scope. It would also make sense to ensure that your company is not in violation of any laws or regulations specific to financial consulting, or to the countries/states/counties, etc. you operate your business in. It would not make sense for the same business to have a scope that only includes their sales department, who do not have access to or influence on any customer data or its security. In short, you want to be sure you are meeting the requirements and/or wishes of those who have the most influence on the ability to reach the organization’s goals.
  • After considering the details and parties most relevant to your organization and its goals, you should have a good idea of what information should be within the scope of your system.
  •  Now the boundaries of the ISMS must be determined, which can be thought of as a perimeter serving as a demarcation between a trusted controlled environment, and the outside world.
  • In many cases, the easiest and safest way to determine your boundaries is to include the whole organization. All of its people, processes, systems, and physical locations would be included. For smaller organizations with a single office, or those only offer one product or service, it will most likely be less resource-intensive to take this approach. Determining the people and processes to be included in this case is easy, as it is everyone who is part of the organization. Similarly, the physical perimeter for your location(s) is also easily identifiable.
  • Determining the logical boundaries for your data network can be aided by identifying where the demarcation points for entry and exit exist, or where your organization has control and visibility of the network and where it does not.
  • If it exists, an organizational chart may easily identify the departments/people that are involved with the specific product or service that is in scope. However, if there are individuals that are out of scope but occupy the same offices or buildings, they will have to be treated the same as any other person outside of scope and controlled as such. This could include separate physical areas secured to only allow in-scope personnel to have access, separate information systems, putting contracts in place with other organizational units to define and enforce information security-related requirements, etc. Any physical locations wherein scope personnel work from,  or that are involved with the data and systems used for the in-scope good or service will need to be included in the scope.
  • For limited scopes, a strategy for determining the logical boundaries of the ISMS is to create a high-level data flow chart that illustrates a logical mapping of the associated data. It isn’t necessary to identify each unique server/ router/ switch/ storage array etc. at this point. For example, if you have 27 database servers in geographically diverse locations where in-scope data could end up, just identify database servers as a single point on the map. Start with all of the possible ways the data enters your systems/buildings, all of the potential places it will go to be stored/ processed/archived, and all possible exit points. Also, note the possible ways it can get between these locations. After you have created the high-level map you can go back and drill down each potential system the data could end up at to each unique instance of the resource in order to end up with a comprehensive list of the systems that would need to be in scope. Working with this list of systems, you can then identify the physical locations they reside, methods of transport between them, and individuals with access to these systems.
  • Narrowing the scope of your ISMS can reduce its initial cost in resources, or potentially, increase it. Being able to roll out the ISMS at a single location can certainly be much less daunting than implementing at multiple, but due to the ease with which data networks can cross-organizational and geographical boundaries, it may not be realistic. I suggest that you should first determine what it is that your organization does that would have the greatest benefit for your interested parties by being controlled by an ISO 27001 certified ISMS, and then working from there to identify the people, processes, systems, and data that are involved in it.
  • The feasibility and sensibility of limiting the scope of your ISMS will greatly depend on the specifics of your organization and its context. The key point to remember is that, with a limited scope, organizational assets outside of the scope must be treated the same as those external to your company.

Different scopes

Scoping is a critical part of planning the roll-out and implementation of an information security management system (ISMS). An organization is often sub-divided into smaller ISMS scopes (e.g. an ISMS relating to a particular project, service, audit or policy, etc). In either case, the scope determines the boundaries and applicability of information security management and controls. The scope will be shaped by:

  • the business of an organization
  • the needs and expectations of relevant interested parties
  • the organizational structures that are currently in place.

It is important to correctly define and agree with the scope with the relevant senior stakeholders at the outset, so as to manage expectations, agree in advance what is (and is not) to be achieved, and ensure that applicable security requirements for relevant systems are identified and implemented. An organization will typically have multiple scopes relating to information security. For example, the overall scope for information security is likely to be considered as the entire organization. However, in most Higher Education environments it would be difficult to tackle the whole organization in one go. Similarly, it would be an almost impossible task to certify the entire organization against an ISO/IEC 27001 standard or other standards like PCI DSS. Thus the organization should consider having multiple, smaller, scopes, each of which is tailored to the protections required for the information it encompasses. For example, the scope of a PCI DSS audit is determined by protecting only payment cardholder data. Starting with a reduced scope (as opposed to trying to tackle too much too quickly) may also increase the chances of success, and of achieving the objectives of the ISMS in a reasonable time. Examples of scopes include:

  • scope of an ISMS for the purposes of ISO/IEC 27001 certification
  • scope to which a policy applies
  • system components potentially affecting the security of cardholder data for PCI DSS compliance
  • scope of an audit
  • scope of specific information security projects and services
  • scope of responsibility in contractual agreements.

How to define the scope of an ISMS

1. Identify what needs to be protected
One of the first questions to ask is “what needs to be protected”? It is likely that there will be many information assets that need to be protected in order to support the organization in achieving its business objectives. It is important to understand which of these the organization considers to be most important, and so a risk-based, prioritized approach should be taken to scoping. In order to establish that assets are actually worth protecting, the organization should justify why each asset requires protection. The scope of an ISMS may initially be defined to include only specific processes, services, systems, or particular departments. Success stories can then be presented as a business case for expanding the scope of the ISMS or creating another, separate scope with different requirements and protections. In order to make the scope entirely clear, especially to third parties, it is a useful exercise to identify what is not in scope (e.g. the activities of the HR department). Either way, the scope should clearly define what is being included, based on the business objectives and information assets to be protected, and it should be clear that anything else is out of scope.

2. Monitor and review
The scope of an ISMS, policy, audit or project is not static and may evolve over time as circumstances, threats, technologies, and requirements develop. Therefore scoping is not something that should be done once at the beginning of a project and then forgotten about. Rather, the scope should be monitored and reviewed at regular intervals and/or in the light of significant changes. In the event of an audit (be it for internal control or certification purposes) one of the first things an auditor should do is to review and assess the appropriateness of the scope. Factors that might affect/change the scope of an ISMS include:

  • time dependencies: e.g. the scope of a particular ISMS and/or security project may only be applicable for a particular time period
  • change in the regulatory environment
  • changes/updates to standards and/or third-party requirements
  • change in the organization (e.g. organization structure changes)
  • identification of non-conformities and/or incidents indicating the incorrect scope
  • the overall maturity of ISMS (scope may increase over time)
  • change in processes and practices (e.g. ceasing certain activities)
  • outsourcing services.

Outsourcing and third parties

Outsourced may be defined as “Any element that is not wholly controlled, managed, built, implemented and maintained by staff employed by the organization.”
Cloud services may be defined as  “A shared computer-based storage solution for data that is based on a virtualized computing environment.” Cloud services can describe any shared environment, which can be provided both locally or outsourced.
All organizations will outsource some activities to third parties. Some third parties are taken so much for granted that, when questioned, staff do not remember them – e.g. the cleaning teams, waste removal contractors, and potentially accountants or auditors. Their activities may not be under scrutiny, yet they may have the highest levels of access.
There are many reasons why an organization may want or need to outsource some (or all) of its IT provision. As information technology changes and evolves extremely quickly, it can be more cost-effective to outsource some of an organization’s IT solution or to use cloud storage or services. Economies of scale mean that large data warehouse-style storage facilities can offer cheap storage and extremely good availability. Externally hosted services may also provide specialist IT knowledge and support that is not available within the organization. If managed properly, outsourced IT or cloud technology carries no greater risk and arguably less risk than managing an in-house IT environment. However, poorly sourced or managed outsourcing, or inappropriate cloud provision, can be extremely risky. When cloud services are used, there can be multiple parties involved in the production of the overall service. For example, infrastructure and software services can be provided by different organizations. Scoping in this context will involve having a clear understanding of the system components involved and the security responsibilities of each service provider. These security requirements should be included in any contractual agreements. Responsibility for implementing security may be outsourced, but the accountability cannot be, and so it is, therefore, important to understand the scope of an ISMS in this context. Put simply, when it comes to meeting certain security requirements, outsourced functions or processes will be in scope for an ISMS, but the suppliers are unlikely to be. It is up to the organization to decide how it may be assured that the services provided are of an appropriate standard.
Understanding an organization’s relationship with third parties is extremely important to ensure security for the business and the information that it holds, especially where information security may be put at risk by third party activities, even though their activities are not obviously related to information (e.g. cleaners). When working with any third party, it is important for information security that the following are defined:

  • Legal responsibility, accountability, and insurance: all the parties’ responsibilities must be detailed and understood. Running through a risk assessment process will uncover many areas where accountability needs to be defined. Disaster planning and incident response is also a good way of verifying that ownership and insurance responsibilities are correctly scoped.
  • Access and authorization: it is essential to make sure the rules and regulations for who can access what are clearly defined. If the organization is allowing contractors into buildings, it should understand who has the keys or access codes; and who ensures the staff is trained and things are secure. Out of hours office cleaning staff often have more physical access to an organization than even the most trusted day staff. Access to IT systems and data should also be considered.
  • Disclosure and privacy: the organization should define and categorize the information that is being used and shared, and specify the applicable rules and regulations.
  • Contract terms: The terms of contracts with third parties should be clearly defined to make sure that all parties are clear on the expectations of the work to be conducted, and sanctions or liabilities in the event of default are assigned.

When selecting a third party, questions such as the following should be considered:

  • What data are going to be on the outsourced system? Do the data include any sensitive information, or have special requirements?
  • What laws or regulations applicable to the service provider who is supplying the IT provision? If it is a company outside of the EU, how will that interact with the requirements of the data which it will handle? Where will the data itself be stored?
  • Who needs access to the IT solution? Is it something that needs a lot of physical involvement or does it not need any attention for many months?
  • Are there restrictions on who administers the system? Who will the administrators be and who controls the access rights?
  • Where is the system physically housed? Is the facility secured, who is it shared by, and who controls the access?
  • Does the outsourced service provider themselves outsource any of their provision (e.g. off-site back-ups)?
  • How do they manage the security controls which their third parties are handling?
  • What service level is expected or provided? What levels of assurance for confidentiality, availability, and integrity of data are there? Check the policies in place within your organization.
  • At the end of the business relationship, how will it be possible for the organization’s information to be extracted from the third party environment in a usable form?
  • What provisions (if any) are in place for compensating the organization for the impact of a business continuity incident or disaster (e.g. loss or exposure of information)?

Examples of Scope

1. Voice Connect design, develop, supply and support the following:
Integrated telephony and multiple media computer messaging products and services;
An Alarm Receiving Centre (ARC) that provides a lone worker monitoring service;
A Payment Portal that enables a cardholder to use a touch-tone phone to make payments.

2. The company is committed to protecting its information and that of its customers. To achieve this goal, the company has implemented an Information Security Management System in accordance with ISO/IEC 27001: 2013. The company’s ISMS is applicable to the following areas of the business:

  • Finance department
  • Internal IT systems and networks used for back-end business (such as email, timesheets, contract development and storage, and report writing)
    (Note: IT systems on which company software is developed and stored are part of the Software Development ISMS. Refer to the Software Development Security Manual for more information.)

3. The ISMS offers protection to all information processed stored in the E-commerce servers or transmitted through it and desktops connected to E-commerce servers through a dedicated LAN.
The e-commerce server and the desktops are located on the 3rd floor of MSTC LTD H.O. having its address at 225C, AJC Bose Road, Kolkata-700 020. It also includes the following :

  1. Law, HR and Admin functions associated with e-commerce.
  2. DR site located at 607 Raheja Centre, Nariman Point, Mumbai – 400 021.
  3. Development Server located at the 3rd floor of MSTC LTD H.O. having its address at 225C, AJC Bose Road, Kolkata-700 020

4. This ISMS applies to all information assets used or supported by Lancashire County Council in the course of its business. In the main, this refers to the information and record-keeping systems of the five Directorates and the three Direct Service Organisations but the specific areas covered by the ISMS are as follows.
Areas covered by this ISMS:

  • Corporate network and all assets connected to it including Pensions Scheme
  • All hardware-software and information records held by employees or agents of Lancashire County Council for Lancashire County Council business purposes
  • People’s Network
  • The LGFL network
  • Shared sites where facilities are supported by Lancashire County Council
  • Facilities owned by Lancashire County Council and connected to its networks but operated from the premises of other organizations.
  • Privately owned equipment used in the course of employment with the County Council
  • The Contact Centre
  • Telephony network

Areas not covered by the ISMS

  • LCDL
  • Organizations for which Lancashire County Council is merely the accountable body
  • Schools

4.4 Information security management system

The organization must establish, implement, maintain and continually improve an information security management system which must include the processes and their interaction, in accordance with the requirements of this International Standard.


Organizations of all types and sizes:

  1. collect, process, store, and transmit information;
  2. recognize that information, and related processes, systems, networks, and people are important assets for achieving organization objectives;
  3. face a range of risks that may affect the functioning of assets; and
  4. address their perceived risk exposure by implementing information security controls.

All information held and processed by an organization is subject to threats of attack, error, nature (for example, flood or fire), etc., and is subject to vulnerabilities inherent in its use. The term information security is generally based on information being considered as an asset that has a value requiring appropriate protection, for example, against the loss of availability, confidentiality, and integrity. Enabling accurate and complete information to be available in a timely manner to those with authorized needs is a catalyst for business efficiency. Protecting information assets through defining, achieving, maintaining, and improving information security effectively is essential to enable an organization to achieve its objectives, and maintain and enhance its legal compliance and image. These coordinated activities directing the implementation of suitable controls and treating unacceptable information security risks are generally known as elements of information security management. As information security risks and the effectiveness of controls change depending on shifting circumstances, organizations need to:

  1. monitor and evaluate the effectiveness of implemented controls and procedures;
  2. identify emerging risks to be treated; and
  3. select, implement and improve appropriate controls as needed.

To interrelate and coordinate such information security activities, each organization needs to establish its policy and objectives for information security and achieve those objectives effectively by using a management system.
An Information Security Management System (ISMS) consists of the policies,  procedures, guidelines, and associated resources and activities, collectively managed by an organization, in the pursuit of protecting its information assets. An ISMS is a systematic approach for establishing, implementing, operating, monitoring, reviewing, maintaining, and improving an organization’s information security to achieve business objectives. It is based upon a risk assessment and the organization’s risk acceptance levels designed to effectively treat and manage risks. Analyzing requirements for the protection of information assets and applying appropriate controls to ensure the protection of these information assets, as required, contributes to the successful implementation of an ISMS. The following fundamental principles also contribute to the successful implementation of an ISMS:

  1. awareness of the need for information security;
  2. assignment of responsibility for information security;
  3. incorporating management commitment and the interests of stakeholders;
  4. enhancing societal values;
  5. risk assessments determining appropriate controls to reach acceptable levels of risk;
  6. security incorporated as an essential element of information networks and systems;
  7. active prevention and detection of information security incidents;
  8. ensuring a comprehensive approach to information security management; and
  9. continual reassessment of information security and the making of modifications as appropriate.


Information is an asset that, like other important business assets, is essential to an organization’s business and consequently needs to be suitably protected. Information can be stored in many forms, including digital form (e.g. data files stored on electronic or optical media), material form (e.g. on paper), as well as unrepresented information in the form of knowledge of the employees. Information may be transmitted by various means including courier, electronic or verbal communication. Whatever form information takes, or the means by which the information is transmitted, it always needs appropriate protection. In many organizations, information is dependent upon information and communications technology. This technology is often an essential element in the organization and assists in facilitating the creation, processing, storing, transmitting, protection, and destruction of information.

Information security

Information security includes three main dimensions: confidentiality, availability, and integrity. Information security involves the application and management of appropriate security measures that involve consideration of a wide range of threats, with the aim of ensuring sustained business success and continuity and minimizing impacts of information security incidents. Information security is achieved through the implementation of an applicable set of controls, selected through the chosen risk management process and managed using an ISMS, including policies, processes, procedures, organizational structures, software, and hardware to protect the identified information assets. These controls need to be specified, implemented, monitored, reviewed, and improved where necessary, to ensure that the specific information security and business objectives of the organization are met. Relevant information security controls are expected to be seamlessly integrated with an organization’s business processes.


Management involves activities to direct, control and continually improve the organization within appropriate structures. Management activities include the act, manner, or practice of organizing, handling, directing, supervising, and controlling resources. Management structures extend from one person in a small organization to management hierarchies consisting of many individuals in large organizations. In terms of an ISMS, management involves the supervision and making of decisions necessary to achieve business objectives through the protection of the organization’s information assets. Management of information security is expressed through the formulation and use of information security policies, procedures, and guidelines, which are then applied throughout the organization by all individuals associated with the organization.

Management system

A management system uses a framework of resources to achieve an organization’s objectives. The management system includes organizational structure, policies, planning activities, responsibilities,  practices, procedures, processes, and resources.
In terms of information security, a management system allows an organization to:
a) satisfy the information security requirements of customers and other stakeholders;
b) improve an organization’s plans and activities;
c) meet the organization’s information security objectives;
d) comply with regulations, legislation and industry mandates; and
e) manage information assets in an organized way that facilitates continual improvement and adjustment to current organizational goals.

Process approach

Organizations need to identify and manage many activities in order to function effectively and efficiently. Any activity using resources needs to be managed to enable the transformation of inputs into outputs using a set of interrelated or interacting activities – this is also known as a process. The output from one process can directly from the input to another process and generally this transformation is carried out under planned and controlled conditions. The application of a system of processes within an organization, together with the identification and interactions of these processes, and their management, can be referred to as a “process approach”.


Establishing, monitoring, maintaining and improving an ISMS

An organization needs to undertake the following steps in establishing, monitoring, maintaining and improving its ISMS:

  1. identify information assets and their associated information security requirements
  2.  assess information security risks and treat information security risks
  3. select and implement relevant controls to manage unacceptable risks  and
  4. monitor, maintain and improve the effectiveness of controls associated with the organization’s information assets.

To ensure the ISMS is effectively protecting the organization’s information assets on an ongoing basis, it is necessary for mentioned steps to be continually repeated to identify changes in risks or in the organization’s strategies or business objectives.

2. Identifying information security requirements
Within the overall strategy and business objectives of the organization, its size, and geographical spread, information security requirements can be identified through an understanding of:

  1. identified information assets and their value;
  2. business needs for information processing, storage and communication; and
  3. legal, regulatory, and contractual requirements.

Conducting a methodical assessment of the risks associated with the organization’s information assets will involve analyzing: threats to information assets; vulnerabilities to and the likelihood of a threat materializing to information assets; and the potential impact of any information security incident on information assets. The expenditure on relevant controls is expected to be proportionate to the perceived business impact of the risk materializing.

3. Assessing information security risks
Managing information security risks requires a suitable risk assessment and risk treatment method which may include an estimation of the costs and benefits, legal requirements, the concerns of stakeholders, and other inputs and variables as appropriate. Risk assessments should identify, quantify, and prioritize risks against criteria for risk acceptance and objectives relevant to the organization. The results should guide and determine the appropriate management action and priorities for managing information security risks and for implementing controls selected to protect against these risks. Risk assessment should include the systematic approach of estimating the magnitude of risks (risk analysis) and the process of comparing the estimated risks against risk criteria to determine the significance of the risks (risk evaluation). Risk assessments should be performed periodically to address changes in the information security requirements and in the risk situation, e.g. in the assets, threats, vulnerabilities, impacts, the risk evaluation, and when significant changes occur. These risk assessments should be undertaken in a methodical manner capable of producing comparable and reproducible results. The information security risk assessment should have a clearly defined scope in order to be effective and should include relationships with risk assessments in other areas, if appropriate.

4. Treating information security risks
Before considering the treatment of risk, the organization should decide the criteria for determining whether or not risks can be accepted. Risks may be accepted if, for example, it is assessed that the risk is low or that the cost of treatment is not cost-effective for the organization. Such decisions should be recorded. For each of the risks identified following the risk assessment, a risk treatment decision needs to be made. Possible options for risk treatment include:

  1. applying appropriate controls to reduce the risks;
  2. knowingly and objectively accepting risks, providing they clearly satisfy the organization’s policy and criteria for risk acceptance;
  3. avoiding risks by not allowing actions that would cause the risks to occur;
  4. sharing the associated risks to other parties, e.g. insurers or suppliers.

For those risks where the risk treatment decision has been to apply appropriate controls, these controls should be selected and implemented.

1.Selecting and implementing controls
Once information security requirements have been identified, information security risks to the identified information assets have been determined and assessed and decisions for the treatment of information security risks having been made, then selection and implementation of controls for risk reduction apply.  Controls should ensure that risks are reduced to an acceptable level taking into account:

  1. requirements and constraints of national and international legislation and regulations;
  2. organizational objectives;
  3. operational requirements and constraints;
  4. their cost of implementation and operation in relation to the risks being reduced, and remaining proportional to the organization’s requirements and constraints;
  5. they should be implemented to monitor, evaluate and improve the efficiency and effectiveness of information security controls to support the organization’s aims. The selection and implementation of controls should be documented within a statement of applicability to assist with compliance requirements.
  6. the need to balance the investment in implementation and operation of controls against the loss likely to result from information security incidents.

The controls specified in ISO/IEC 27002 are acknowledged as best practices applicable to most organizations and readily tailored to accommodate organizations of various sizes and complexities. Other standards in the ISMS family of standards provide guidance on the selection and application of ISO/IEC 27002 controls for the information security management system. Information security controls should be considered at the systems and project requirements specification and design stage. Failure to do so can result in additional costs and less effective solutions, and maybe, in the worst case, the inability to achieve adequate security. Controls can be selected from ISO/IEC 27002 or from other control sets, or new controls can be designed to meet the specific needs of the organization. It is necessary to recognize that some controls may not be applicable to every information system or environment, and might not be practicable for all organizations. Sometimes it takes time to implement a chosen set of controls and during that time the level of risk may be higher than can be tolerated on a long-term basis. Risk criteria should cover the tolerability of risks on a short-term basis while controls are being implemented. Interested parties should be informed of the levels of risk that are estimated or anticipated at different points in time as controls are progressively
implemented. It should be kept in mind that no set of controls can achieve complete information security. Additional management actions should be implemented to monitor, evaluate and improve the efficiency and effectiveness of information security controls to support the organization’s aims. The selection and implementation of controls should be documented within a statement of applicability to assist with compliance requirements.

2. Monitor, maintain and improve the effectiveness of the ISMS
An organization needs to maintain and improve the ISMS through monitoring and assessing performance against organizational policies and objectives and reporting the results to management for review. This ISMS review will check that the ISMS includes specified controls that are suitable to treat risks within the ISMS scope. Furthermore, based on the records of these monitored areas, it will provide evidence of verification, and tractability of corrective, preventive and improvement actions.

3. Continual improvement
The aim of continual improvement of an ISMS is to increase the probability of achieving objectives concerning the preservation of the confidentiality, availability, and integrity of information. The focus of continual improvement is seeking opportunities for improvement and not assuming that existing management activities are good enough or as good as they can. Actions for improvement include the following:

  1. analyzing and evaluating the existing situation to identify areas for improvement;
  2. establishing the objectives for improvement;
  3. searching for possible solutions to achieve the objectives;
  4. evaluating these solutions and making a selection;
  5. implementing the selected solution;
  6. measuring, verifying, analyzing, and evaluating results of the implementation to determine that the objectives have been met;
  7.  formalizing changes.

Results are reviewed, as necessary, to determine further opportunities for improvement. In this way, improvement is a continual activity, i.e. actions are repeated frequently. Feedback from customers and other interested parties, audits, and reviews of the information security management system can also be used to identify opportunities for improvement.


ISMS critical success factors

A large number of factors are critical to the successful implementation of an ISMS to allow an organization to meet its business objectives. Examples of critical success factors include:

1 information security policy, objectives, and activities aligned with objectives;

2. an approach and framework for designing, implementing, monitoring, maintaining, and improving information security consistent with the organizational culture;

3. visible support and commitment from all levels of management, especially top management;

4. an understanding of information asset protection requirements achieved through the application of information security risk management ;

5. an effective information security awareness, training, and education program informing all employees and other relevant parties of their information security obligations set forth in the information security policies, standards, etc., and motivating them to act accordingly;

6. an effective information security incident management process;

7. an effective business continuity management approach; and

8, a measurement system used to evaluate performance in information security management and feedback suggestions for improvement. An ISMS increases the likelihood that an organization will consistently achieve the critical success factors required to protect its information assets.


Back to Home Page

If you need assistance or have any doubt and need to ask any questions contact me at You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

ISO 27001:2022 Information Security Management System

by Pretesh Biswas

Audio version of the article


Overview of an Information Security Management System

Information security is the protection of information to ensure:

  • Confidentiality: ensuring that the information is accessible only to those authorized to access it.
  • Integrity: ensuring that the information is accurate and complete and that the information is not modified without authorization.
  • Availability: ensuring that the information is accessible to authorized users when required.

Information security is achieved by applying a suitable set of controls (policies, processes, procedures, organizational structures, and software and hardware functions). An Information Security Management System (ISMS) is the way to protect and manage information based on a systematic business risk approach, to establish, implement, operate, monitor, review, maintain, and improve information security. It is an organizational approach to information security.
ISO publishes two standards that focus on an organization’s ISMS:

  • The code of practice standard: ISO 27002. This standard can be used as a starting point for developing an ISMS. It provides guidance for planning and implementing a program to protect information assets. It also provides a list of controls (safeguards) that you can consider implementing as part of your ISMS.
  • The management system standard: ISO 27001. This standard is the specification for an ISMS. It explains how to apply ISO/IEC 27002. It provides the standard against which certification is performed, including a list of required documents. An organization that seeks certification of its ISMS is examined against this standard.

The standards set forth the following practices:

  • All activities must follow a method. The method is arbitrary but must be well defined and documented.
  • A company or organization must document its own security goals. An auditor will verify whether these requirements are fulfilled.
  • All security measures used in the ISMS shall be implemented as the result of risk analysis in order to eliminate or reduce risks to an acceptable level.
  • The standard offers a set of security controls. It is up to the organization to choose which controls to implement based on the specific needs of their business.
  • A process must ensure the continuous verification of all elements of the security system through audits and reviews.
  • A process must ensure the continuous improvement of all elements of the information and security management system. (The ISO 27001 standard adopts the Plan-Do-Check-Act [PDCA] model as its basis and expects the model will be followed in an ISMS implementation.)

ISO 27001:2022 structure

Clause 0: Introduction

This Standard provides requirements for establishing, implementing, maintaining and continually improving an information security management system. The organization will implement the information security management as a strategic decision influenced by its needs objectives, security requirements, processes , its size and structure of the organization. The introduction also draws attention to the order in which requirements are presented, stating that the order does not reflect their importance or imply the order in which they are to be implemented. The Introduction refers to just requirements instead of any models, and it now states explicitly the objective of an information security management system (ISMS) is to preserve the confidentiality, integrity, and availability of information by applying a risk management process and gives confidence to interested parties that risks are adequately managed’. It also emphasizes that the ISMS is part of and integrated with the organization’s processes and overall management structure; this reinforces a key message – the ISMS is not a bolt-on to the business. It reinforces this by stating that information security is considered in the design of processes, information systems, and controls. . The compatibility with other management system standards remains and is tangibly demonstrated and reinforced by the adoption of Annex SL.

Clause 1: Scope

The purpose of this clause is to state the applicability of the standard through the requirements to establish, implement and continually improving an ISMS within the context of the organization. It goes on to require the assessment and treatment of information security risks tailored to the needs of the organization. This is a generic standard and is applicable to all organization irrespective of its size , nature and type. To claim conformity to this standard exclusions are not acceptable.

Clause 2: Normative references

The only normative reference is to ISO/IEC 27000, Information technology — Security techniques — Information security management systems — Overview and vocabulary.

Clause 3: Terms and definitions

There are no terms and definitions included. All the terms and definitions given in ISO/IEC 27000 apply which includes the the common terms and definitions given in Annex SL are included. A comparison should be made and where necessary, further clarification sought from the other documents referenced. However, please ensure that you use a version of ISO/IEC 27000 that was published after ISO/IEC 27001:2022 otherwise it will not contain the correct terms or definitions. This is an important document to read. Many definitions, for example ‘management system’ and ‘control’, have been changed and now conform to the definitions given in the new ISO directives and ISO 31000. If a term is not defined in ISO/IEC 27000, please use the definition given in the Oxford English Dictionary. This is important, otherwise, confusion and misunderstanding may be the result

ISO and IEC maintain terminology databases used in ISO 27000/27001 at the following addresses:
— 1SO Online browsing platform: available at
— IEC Electropedia: available at


Clause 4: Context of the organization

This clause that in part addresses the depreciated concept of preventive action and in part establishes the context for the ISMS. It meets these objectives by drawing together relevant external and internal issues i.e. those that affect the organization’s ability to achieve the intended outcome of its ISMS with the requirements of interested parties to determine the scope of the ISMS. It should be noted that the term ‘issue’ covers not only problems, which would have been the subject of preventive action in the previous standard, but also important topics for the ISMS to address, such as any market assurance and governance goals that the organization might set for the ISMS.
Note that the term ‘requirement’ is a ‘need or expectation that is stated, generally implied or obligatory’. Combined with Clause 4.2, this in itself can be thought of as a governance requirement, as strictly speaking an ISMS that did not conform to generally-accepted public expectations could now be ruled non-conformance with the standard.You must identify the “relevant” requirements of interested parties and determine which will be addressed through the ISMS .
The final requirement (Clause 4.4) is to establish, implement, maintain and continually improve the ISMS including the process needed and their interaction in accordance with the requirements the standard.


Clause 5: Leadership

This clause places requirements on ‘top management’ which is the person or group of people who directs and controls the organization at the highest level. Note that if the organization that is the subject of the ISMS is part of a larger organization, then the term ‘top management’ refers to the smaller organization. The purpose of these requirements is to demonstrate leadership and commitment by leading from the top. A particular responsibility of top management is to establish the information security policy, and the standard defines the characteristics and properties that the policy is to include. Finally, the clause places requirements on top management to assign information security-relevant responsibilities and authorities, highlighting two particular roles concerning ISMS conformance to ISO  27001 and reporting on ISMS performance.


Clause 6: Planning

Clause 6.1.1 (General) works with Clauses 4.1 and 4.2 to complete the new way of dealing with preventive actions. The first part of this clause (i.e. down to and including 6.1.1 c)) concerns risk assessment whilst Clause 6.1.1 d) concerns risk treatment. As the assessment and treatment of information security risk is dealt with in Clauses 6.1.2 and 6.1.3, then organizations could use this clause to consider ISMS risks and opportunities.
Clause 6.1.2 (Information security risk assessment) specifically concerns the assessment of information security risk. In aligning with the principles and guidance given in ISO 31000, this clause removes the identification of assets, threats, and vulnerabilities as a prerequisite to risk identification. This widens the choice of risk assessment methods that an organization may use and still conforms to the standard. The clause also refers to ‘risk assessment acceptance criteria’, which allows criteria other than just a single level of risk. Risk acceptance criteria can now be expressed in terms other than levels, for example, the types of control used to treat risk. The clause refers to ‘risk owners’ rather than ‘asset owners’ and later requires their approval of the risk treatment plan and residual risks.In also requires organizations to assess consequence, likelihood, and levels of risk.

Clause 6.1.3, (Information security risk treatment) concerns the treatment of information security risk. It refers to the ‘determination’ of necessary controls rather than selecting controls from Annex A. Nevertheless, the standard retains the use of Annex A as a cross-check to make sure that no necessary control has been overlooked, and organizations are still required to produce a Statement of Applicability (SOA). The formulation and approval of the risk treatment plan is now part of this clause.
Clause 6.2, ( Information security objectives and planning to achieve them) concerns information security objectives. It uses the phrase “relevant functions and levels”, where here, the term ‘function’ refers to the functions of the organization, and the term ‘level’, its levels of management, of which ‘top management’ is the highest. The clause defines the properties that an organization’s information security objectives must possess. Information security objectives must be monitored and made “available as documented information”

Clause 6.3 (Planing of change) is about how to ensure that changes in ISMS is in planned manner.Since it does not specify any processes that must be included, so you should determine how you can demonstrate that changes to the ISMS have indeed been planned.


Clause 7: Support

This clause begins with a requirement that organizations shall determine and provide the necessary resources to establish, implement, maintain and continually improve the ISMS. Simply expressed, this is a very powerful requirement covering all ISMS resource needs. The Support clause identifies what is required to establish, implement and maintain and continually improve an effective ISMS, including:

  • Resource requirements
  • Competence in terms of education, training and experience of people involved in Information security performance
  • Awareness of Information security policy, security performance and implication of not conforming with the ISMS requirements.
  • communication on what, when, with whom, how to with interested parties.

Finally, there are requirements for ‘documented information’. The standard refers to “documented information” rather than “documents and records” and requires that they are retained as evidence of competence These requirements relate to the creation and updating of documented information and to their control. There is no longer a list of documents you need to provide or particular names they must be given. The new revision puts the emphasis on the content rather than the name. Note that the requirements for documented information are presented in the clause to that they refer to.


Clause 8: Operation

The organization must plan, implement and control the processes needed to meet information security requirements and to implement the actions determined in the standard.The organization must establish criteria for processes to implement actions identified in Clause 6, and to control those processes in line with the criteria. They are required to control “externally provided processes, products or services” relevant to the ISM The organization must perform information security risk assessments at planned intervals, and shall also implement the information security risk treatment plan. This clause deals with the execution of the plans and processes that are the subject of previous clauses. Organizations must plan and control the processes needed to meet their information security requirements including:

  • keeping documents
  • management of change
  • responding to adverse events
  • the control of any outsourced processes

Operation planning and control also mandate the carrying out of information security risk assessments at planned intervals and the implementation of an information security risk treatment plan.
Clause 8.1 deals with the execution of the actions determined in Clause 6.1, the achievement of the information security objectives and outsourced processes;
Clause 8.2 deals with the performance of information security risk assessments at planned intervals, or when significant changes are proposed or occur; and
Clause 8.3 deals with the implementation of the risk treatment plan.


Clause 9: Performance evaluation

The organization shall evaluate the information security performance and the effectiveness of the information security management system. The organization shall conduct internal audits at planned intervals to provide information on whether the information security management system conforms to the organization’s own requirements and to the International Standard requirements.

The first paragraph of Clause 9.1 (Monitoring, measurement, analysis, and evaluation) states the overall goals of the clause. As a general recommendation, determine what information you need to evaluate the information security performance and the effectiveness of your ISMS. Work backward from this ‘information need’ to determine what to measure and monitor, when who and how. There is little point in monitoring and making measurements just because your organization has the capability of doing so. Only monitor and measure if it supports the requirement to evaluate information security performance and ISMS effectiveness. Note that an organization may have several information needs, and these needs may change over time. For example, when an ISMS is relatively new, it may be important just to monitor the attendance at, say, information security awareness events. Once the intended rate has been achieved, the organization might look more towards the quality of the awareness event. It might do this by setting specific awareness objectives and determining the extent to which the attendees have understood what they have learned. Later still, the information need may extend to determine what impact this level of awareness has on information security for the organization.A comparable and reproducible method for monitoring, measurement, analysis and evaluation should be selected to give a valid result.
Internal audits and management review continue to be key methods of reviewing the performance of the ISMS and tools for its continual improvement. he requirements include conducting internal audits at planned intervals, plan, establish, implement and maintain an audit programme(s), select auditors and conduct audits that ensure objectivity and impartiality of the audit process.
In Clause 9.3 (Management review),  rather than specify precise inputs and outputs, this clause now places requirements on the topics for consideration during the review. The requirement for reviews to be held at planned intervals remains but the requirement to hold the reviews at least once per year has been dropped.


Clause 10: Improvement

Due to the new way of handling preventive actions, there are no preventive action requirements in this clause. However, there are some new corrective action requirements. The first is to react to nonconformity and take action, as applicable, to control and correct the nonconformity and deal with the consequences. The second is to determine whether similar nonconformity exist, or could potentially occur. Although the concept of preventive action has evolved there is still a need to consider potential nonconformity, albeit as a consequence of an actual nonconformity. There is also a new requirement to ensure that corrective actions are appropriate to the effects of the nonconformity encountered. The requirement for continual improvement has been extended to cover the suitability and adequacy of the ISMS as well as its effectiveness, but it no longer specifies how an organization achieves this


Annex A Information security controls reference

Information security controls can be categorized into 4 groups or theme. These are:

  1. people, if they concern individual people;
  2. physical, if they concern physical objects;
  3. technological, if they concern technology;
  4. otherwise they are categorized as organizational.

5 Organizational controls

5.1 Policies for information security

Information security policy and topic-specific policies should be defined, approved by management, published, communicated to and acknowledged by relevant personnel and relevant interested parties, and reviewed at planned intervals and if significant changes occur.

The purpose of this control is to ensure continuing suitability, adequacy, effectiveness of management direction and support for information security in accordance with business, legal, statutory, regulatory and contractual requirements.Management should define a set of policies to clarify their direction of, and support for, information security. At the top level, there should be an overall “information security policy” 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.

5.2 Information security roles and responsibilities

Information security roles and responsibilities should be defined and allocated according to the organization needs.

The purpose of this control is to establish a defined, approved and understood structure for the implementation, operation and management of information security within the organization. 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.

5.3 Segregation of duties

Conflicting duties and conflicting areas of responsibility should be segregated.

The purpose of this control is to reduce the risk of fraud, error and bypassing of information security controls. 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.

5.4 Management responsibilities

Management should require all personnel to apply information security in accordance with the established information security policy, topic-specific policies and procedures of the organization.

The purpose of this control is to ensure management understand their role in information security and undertake actions aiming to ensure all personnel are aware of and fulfill their information security responsibilities. 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.


5.5 Contact with authorities

The organization should establish and maintain contact with relevant authorities.

The purpose of this control is to ensure appropriate flow of information takes place with respect to information security between the organization and relevant legal, regulatory and supervisory authorities. 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.

5.6 Contact with special interest groups

The organization should establish and maintain contact with special interest groups or other specialist security forums and professional associations.

The purpose of this control is to ensure appropriate flow of information takes place with respect to information security.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.

5.7 Threat intelligence

Information relating to information security threats should be collected and analysed to produce threat intelligence.

The purpose of this control is to provide awareness of the organization’s threat environment so that the appropriate mitigation actions can be taken. 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.

5.8 Information security in project management

Information security should be integrated into project management.

The purpose of this control is to ensure information security risks related to projects and deliverables are effectively addressed in project management throughout the project life cycle. 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.


5.9 Inventory of information and other associated assets

An inventory of information and other associated assets, including owners, should be developed and maintained.

The purpose of this control is to identify the organization’s information and other associated assets in order to preserve their information security and assign appropriate ownership. 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 life cycle. 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.

5.10 Acceptable use of information and other associated assets

Rules for the acceptable use and procedures for handling information and other associated assets should be identified, documented and implemented.

The purpose of this control is to ensure information and other associated assets are appropriately protected, used and handled. 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.

5.11 Return of assets

Personnel and other interested parties as appropriate should return all the organization’s assets in their possession upon change or termination of their employment, contract or agreement.

The purpose of this control is to protect the organization’s assets as part of the process of changing or terminating employment, contract or agreement. 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.

5.12 Classification of information

Information should be classified according to the information security needs of the organization based on confidentiality, integrity, availability and relevant interested party requirements.

The purpose of this control is to ensure identification and understanding of protection needs of information in accordance with its importance to the organization. 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 survival.


5.13 Labeling of information

An appropriate set of procedures for information labeling should be developed and implemented in accordance with the information classification scheme adopted by the organization.

The purpose of this control is to facilitate the communication of classification of information and support automation of information processing and management. 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. The labels should be easily recognizable. The procedures should give guidance on where and how labels are attached in consideration of how the information is accessed or the assets are handled depending on the types of storage media..

5.14 Information transfer

Information transfer rules, procedures, or agreements should be in place for all types of transfer facilities within the organization and between the organization and other parties.

The purpose of this control is to maintain the security of information transferred within an organization and with any external interested party. 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.

5.15 Access control

Rules to control physical and logical access to information and other associated assets should be established and implemented based on business and information security requirements.

The purpose of this control is to ensure authorized access and to prevent unauthorized access to information and other associated assets. 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.

5.16 Identity management

The full life cycle of identities should be managed.

The purpose of this control is to allow for the unique identification of individuals and systems accessing the organization’s information and other associated assets and to enable appropriate assignment of access rights. 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 life cycle.


5.17 Authentication information

Allocation and management of authentication information should be controlled by a management process, including advising personnel on the appropriate handling of authentication information.

The purpose of this control is to ensure proper entity authentication and prevent failures of authentication processes. 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.

5.18 Access rights

Access rights to information and other associated assets should be provisioned, reviewed, modified and removed in accordance with the organization’s topic-specific policy on and rules for access control.

The purpose of this control is to ensure access to information and other associated assets is defined and authorized according to the business requirements. 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.

5.19 Information security in supplier relationships

Processes and procedures should be defined and implemented to manage the information security risks associated with the use of supplier’s products or services.

The purpose of this control is to maintain an agreed level of information security in supplier relationships. 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 predetermined logistic processes, an incident process obligations for both sides, Non Disclosure Agreements, and documentation of the supplying process.

5.20 Addressing information security within supplier agreements

Relevant information security requirements should be established and agreed with each supplier based on the type of supplier relationship.

The purpose of this control is to maintain an agreed level of information security in supplier relationships. 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.


5.21 Managing information security in the ICT supply chain

Processes and procedures should be defined and implemented to manage the information security risks associated with the ICT products and services supply chain.

The purpose of this control is to maintain an agreed level of information security in supplier relationships. 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”.

5.22 Monitoring, review and change management of supplier services

The organization should regularly monitor, review, evaluate and manage change in supplier information security practices and service delivery.

The purpose of this control is to maintain an agreed level of information security and service delivery in line with supplier agreements. 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.

5.23 Information security for use of cloud services

Processes for acquisition, use, management and exit from cloud services should be established in accordance with the organization’s information security requirements.

The purpose of this control is to specify and manage information security for the use of cloud services. 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 on boarding 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.

5.24 Information security incident management planning and preparation

The purpose of this control is to ensure quick, effective, consistent and orderly response to information security incidents, including communication on information security events. 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.


5.25 Assessment and decision on information security events

The organization should assess information security events and decide if they are to be categorized as information security incidents.

The purpose of this control is to ensure effective categorization and prioritization of information security events. 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.

5.26 Response to information security incidents

Information security incidents should be responded to in accordance with the documented procedures.

The purpose of this control is to ensure efficient and effective response to information security incidents. 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.

5.27 Learning from information security incidents

Knowledge gained from information security incidents should be used to strengthen and improve the information security controls.

The purpose of this control is to reduce the likelihood or consequences of future incidents. 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.

5.28 Collection of evidence

The organization should establish and implement procedures for the identification, collection, acquisition and preservation of evidence related to information security events

The purpose of this control is to ensure a consistent and effective management of evidence related to information security incidents for the purposes of disciplinary and legal actions. 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.


5.29 Information security during disruption

The organization should plan how to maintain information security at an appropriate level during disruption

The purpose of this control is to protect information and other associated assets during disruption. 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.

5.30 ICT readiness for business continuity

ICT readiness should be planned, implemented, maintained and tested based on business continuity objectives and ICT continuity requirements.

The purpose of this control is to ensure the availability of the organization’s information and other associated assets during disruption. 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.

5.31 Identification of legal, statutory, regulatory and contractual requirements

Legal, statutory, regulatory and contractual requirements relevant to information security and the organization’s approach to meet these requirements should be identified, documented and kept up to date.

The purpose of this control is to ensure compliance with legal, statutory, regulatory and contractual requirements related to information security. 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.

5.32 Intellectual property rights

The organization should implement appropriate procedures to protect intellectual property rights.

The purpose of this control is to ensure compliance with legal, statutory, regulatory and contractual requirements related to intellectual property rights and use of proprietary products 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.


5.33 Protection of records

Records should be protected from loss, destruction, falsification, unauthorized access and unauthorized release.

The purpose of this control is to ensure compliance with legal, statutory, regulatory and contractual requirements, as well as community or societal expectations related to the protection and availability of records. 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.

5.34 Privacy and protection of Personal Identifiable Information (PII)

The organization should identify and meet the requirements regarding the preservation of privacy and protection of PII according to applicable laws and regulations and contractual requirements.

The purpose of this control is to ensure compliance with legal, statutory, regulatory and contractual requirements related to the information security aspects of the protection of PII. 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 Qatar and/or processing personal data in Qatar, Qatar has implemented Law No. (13) of 2016 Concerning Personal Data Protection. Organizations need to make sure they are aware of the requirements set by such legislation, and follow it religiously. The Law, for example, mandates conducting data processing agreements, keeping a register of processing activity, and data processing transparency.

5.35 Independent review of information security

The organization’s approach to managing information security and its implementation including people, processes and technologies should be reviewed independently at planned intervals, or when significant changes occur.

The purpose of this control is to ensure the continuing suitability, adequacy and effectiveness of the organization’s approach to managing information security. 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.

5.36 Compliance with policies and standards for information security

Compliance with the organization’s information security policy, topic-specific policies, rules and standards should be regularly reviewed.

The purpose of this control is to ensure that information security is implemented and operated in accordance with the organization’s information security policy, topic-specific policies, rules and standards. 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.

5.37 Documented operating procedures

Operating procedures for information processing facilities should be documented and made available to personnel who need them.

The purpose of this control is to ensure the correct and secure operation of information processing facilities. 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.


6.0 People control

6.1 Screening

Background verification checks on all candidates to become personnel should be carried out prior to joining the organization and on an ongoing basis taking into consideration applicable laws, regulations and ethics and be proportional to the business requirements, the classification of the information to be accessed and the perceived risks.

The purpose of this control is to ensure all personnel are eligible and suitable for the roles for which they are considered and remain eligible and suitable during their employment An information security management system needs a policy for screening all new or promoted employees, including consultants and temporary staff. This is to ensure that employees are competent and trustworthy. The policy needs to take into account both local legislation and regulations and the role of the new employee to insure that screening is sufficient but not disproportionate. Some roles within an organisation may require a higher level of screening, for example if employees will be handling confidential information. For information security roles in particular, screening should also include necessary competences and trustworthiness, and this should be documented accordingly.

6.2 Terms and conditions of employment

The employment contractual agreements should state the personnel’s and the organization’s responsibilities for information security.

The purpose of this control is to ensure personnel understand their information security responsibilities for the roles for which they are considered. Before beginning work, the employee needs to be aware of the organisation’s information security policy, including information security roles and responsibilities. This could be communicated via a signed code of conduct or similar method. The employees’ contracts should also include the organisation’s relevant information security policy, including a confidentiality agreement if the employee will be have access to confidential information.

6.3 Information security awareness, education and training

Personnel of the organization and relevant interested parties should receive appropriate informationbsecurity awareness, education and training and regular updates of the organization’s information security policy, topic-specific policies and procedures, as relevant for their job function.

The purpose of this control is to ensure personnel and relevant interested parties are aware of and fulfill their information security responsibilities. Employees need information security training when they join the organisation of change roles. Longer serving personnel also need to have their awareness maintained with regular training and communication. The training needs to be relevant to the role. For many staff, this will include basics such as reminders about password security and social-engineering attacks. For technical staff or those handling confidential material more in-depth education will be required for their specific role.

6.4 Disciplinary process

A disciplinary process should be formalized and communicated to take actions against personnel and other relevant interested parties who have committed an information security policy violation.

The purpose of this control is to ensure personnel and other relevant interested parties understand the consequences of information security policy violation, to deter and appropriately deal with personnel and other relevant interested parties who committed the violation. A policy for the disciplinary process following a confirmed information security policy violation should be in place. The disciplinary procedure should be proportionate and graduated, with actions that depend on the severity of the incident, the intention, whether it was a repeat offence and importantly whether the employee was adequately trained. Many recorded security incidents will be the result of a policy violation and should to lead to disciplinary action. This is important to remember because staff should avoid reporting security incidents through fear of disciplinary action.


6.5 Responsibilities after termination or change of employment

Information security responsibilities and duties that remain valid after termination or change of employment should be defined, enforced and communicated to relevant personnel and other interested parties.

The purpose of this control is to protect the organization’s interests as part of the process of changing or terminating employment or contracts. Information security responsibilities do not end when employment is changed or terminated. The employee’s terms and conditions of employment should contain confidentiality agreements, which require the employee to respect the confidentiality of information after they have left the organisation. When an employee leaves, they may also leave information security roles vacant. To maintain continuity of security, management must identify these roles so that they can be transferred.

6.6 Confidentiality or non-disclosure agreements

Confidentiality or non-disclosure agreements reflecting the organization’s needs for the protection of information should be identified, documented, regularly reviewed and signed by personnel and other relevant interested parties.

The purpose of this control is to maintain confidentiality of information accessible by personnel or external parties. If the confidentiality of information is sufficiently high, it may need to be protected by legally enforceable terms. In this case, confidentiality agreements can be used, setting out the information covered, the responsibilities of all parties, the duration of the agreement and the penalties should the agreement be broken. These protect the information from disclosure after the employee has left the organisation for a given time period.

6.7 Remote working

Security measures should be implemented when personnel are working remotely to protect information accessed, processed or stored outside the organization’s premises.

The purpose of this control is to ensure the security of information when personnel are working remotely. Remote working has become standard at many organisations, giving both organisations and employees more flexibility. There are however information security implications for remote working, which should be considered and documented. The remote working policy should outline where and when remote working in permitted, device and equipment provision, authorized access and what information may be accessed remotely. Of particular importance are policies governing the use of strange networks and the risk that friends, family or strangers may overhear or see confidential information.

6.8 Information security event reporting

The organization should provide a mechanism for personnel to report observed or suspected information security events through appropriate channels in a timely manner.

The purpose of this control is to support timely, consistent and effective reporting of information security events that can be identified by personnel. Employees sometimes encounter information security incidents during their daily work. Incidents can instances such as include human errors, confidentiality breaches, malfunctions, suspected malware infections and non-compliance with the IS policy or the law. The first step in identifying, fixing and preventing incident re occurrence is reporting. Employees therefore need a reporting channel and to be aware of its existence.


7.0 Physical controls

7.1 Physical security perimeter

Security perimeters should be defined and used to protect areas that contain information and other associated assets.

The purpose of this control is to prevent unauthorized physical access, damage and interference to the organization’s information and other associated assets. The first step when protecting a physical space is to define its perimeter. Sensitive or critical areas within the perimeter can then be identified. The perimeter must be sufficiently physically secure to protect the contents, with alarms and intruder detection systems. If necessary a monitored reception can control access. The image at the top of this article is an example of a zone plan showing perimeter and secure areas.

7.2 Physical entry controls

Secure areas should be protected by appropriate entry controls and access points.

The purpose of this control is to ensure only authorized physical access to the organization’s information and other associated assets occurs. Only authorized persons should be able to gain entry to assets and information. The level of restrictions depends on the organizational requirements. Things to consider include personal identification and logging who accesses the premises. A procedure should be in place for receiving visitors to establish their identity, where they are can go and if they must be accompanied. Deliveries also present a risk, both because delivery areas need to be secured and to prevent delivery personnel entering restricted areas.

7.3 Securing offices, rooms and facilities

Physical security for offices, rooms and facilities should be designed and implemented.

The purpose of this control is to prevent unauthorized physical access, damage and interference to the organization’s information and other associated assets in offices, rooms and facilities. Offices need to be secured with digital or physical keys. In general, detailed directories and maps should not be openly accessible as these can highlight the location of sensitive assets.

7.4 Physical security monitoring

Premises should be continuously monitored for unauthorized physical access.

The purpose of this control is to detect and deter unauthorized physical access. Monitoring can deter intruders and detect intrusion. Guards, cameras and alarms all monitor against unauthorized access. The design of any monitoring system should be considered confidential. Regular testing is required to ensure that the system works. Camera surveillance systems and other monitoring systems that collect personal information or may be used to track individual may require special consideration under data protection laws. For example, camera surveillance may require a data protection impact assessment under GDPR legislation.


7.5 Protecting against physical and environmental threats

Protection against physical and environmental threats, such as natural disasters and other intentional or unintentional physical threats to infrastructure should be designed and implemented.

The purpose of this control is to prevent or reduce the consequences of events originating from physical and environmental threats Natural or man made disasters and physical attacks threaten information security and business continuity. The level of these risks is highly dependent on location. Floods, fires and large storms are the most likely risks, but the risk from earthquakes, civil unrest and terrorist attacks can also be considered in risk assessments.

7.6 Working in secure areas

Security measures for working in secure areas should be designed and implemented.

The purpose of this control is to protect information and other associated assets in secure areas from damage and unauthorized interference by personnel working in these areas. The existence and purpose of secure environments should only be shared on a need-to-know basis. They should be kept locked, with access limited to authorized persons. Generally, lone-working should be discouraged, for both safety and for security purposes.

7.7 Clear desk and clear screen

Clear desk rules for papers and removable storage media and clear screen rules for information processing facilities should be defined and appropriately enforced.

The purpose of this control is to reduce the risks of unauthorized access, loss of and damage to information on desks, screens and in other accessible locations during and outside normal working hours. Sensitive information left on desks, screens, printers and whiteboards can be accessed by anyone. a clear desk and screen policy defines how and where information can be accessed. A basic policy includes no printed documents left unattended, either at work spaces or printers (clear desk) and locked device screens (clear screen). More detailed policies may be required for sensitive information, for example that information cannot be viewed on a screen in an open environment.

7.8 Equipment siting and protection

Equipment should be sited securely and protected.

The purpose of this control is to reduce the risks from physical and environmental threats, and from unauthorized access and damage. Careful citing of equipment can minimize a host of risks: not just unauthorized access but also the risks due to environmental factors, spilled food and drink, vandalism, and degradation due to light or humidity. The protection required will depend on the sensitivity of the equipment.


7.9 Security of assets off-premises

Off-site assets should be protected.

The purpose of this control is to prevent loss, damage, theft or compromise of off-site devices and interruption to the organization’s operations. Devices, including private devices (bring-your-own-devices), still need protection when they leave the premises. Basics include appropriate physical protection such as covers and theft prevention by not leaving devices unattended. The organization should be aware of what devices are used off premises, by whom, and what information is being accessed or used when off-site.

7.10 Storage media

Storage media should be managed through their life cycle of acquisition, use, transportation and disposal in accordance with the organization’s classification scheme and handling requirements.

The purpose of this control is to ensure only authorized disclosure, modification, removal or destruction of information on storage media. Information stored in any media format brings the risk of unauthorized access, and loss of information integrity through modification or degradation, loss, destruction or removal. Media should therefore be safely stored and eventually securely destroyed. Policies governing the management of removable media should cover what information can be stored on removable media, the registration and tracking of such media, how it should be safely stored to prevent unauthorized access or degradation, and how it should be transported. When storage is no longer required, secure destruction is necessary. This may be performed by an external party.

7.11 Supporting utilities

Information processing facilities should be protected from power failures and other disruptions caused by failures in supporting utilities.

The purpose of this control is to prevent loss, damage or compromise of information and other associated assets, or interruption to the organization’s operations due to failure and disruption of supporting utilities. Power failures can immediately compromise a business’s activities. Less obviously, telecommunications and air conditioning will all interrupt digital activities, and failures of gas, sewage or water supplies will prevent employees from working on-site. Inspection and alarms systems can identify actual or potential failures. Continuity plans should identify back-up options and emergency contact details for service providers.

7.12 Cabling security

Cables carrying power, data or supporting information services should be protected from interception, interference or damage.

The purpose of this control is to prevent loss, damage, theft or compromise of information and other associated assets and interruption to the organization’s operations related to power and communications cabling. Information and data are transferred via cables, while computers, security systems and environmental controls all require power, supplied by cabling. The former can be intercepted and outages of either can compromise information security and business continuity. The degree of security required depends on the organization, and in many cases will be managed by building facilities providers or telecoms and utilities companies. Basic protections include using cabling conduits or cable floor covers to prevent damage, and locked access to utility access and entry points.


7.13 Equipment maintenance

Equipment should be maintained correctly to ensure availability, integrity and confidentiality of information.

The purpose of this control is to prevent loss, damage, theft or compromise of information and other associated assets and interruption to the organization’s operations caused by lack of maintenance. Equipment maintenance introduces two information security considerations: poorly maintained equipment risks the loss of information; while equipment servicing or maintenance can expose information to external or unauthorized parties. Regularly serviced and updated equipment is less likely to require riskier repairs or to lead to outages. When repairs are required, care should be taken in choosing service providers and checking their work.

7.14 Secure disposal or re-use of equipment

Items of equipment containing storage media should be verified to ensure that any sensitive data and licensed software has been removed or securely overwritten prior to disposal or re-use.

The purpose of this control is to prevent leakage of information from equipment to be disposed or re-used. Equipment that is no longer in use may still have licensed software installed or stored sensitive data. This also applies to equipment that requires repair, and should be a consideration when deciding whether to use external repair services. Standard delete functions may not be adequate to remove sensitive information. Instead, specialist destruction, deletion or overwriting methods reduce the risk of residual information remaining on the storage media. Remember to remove physical labels or markings too!


8.0 Technological controls

8.1 User endpoint devices

Information stored on, processed by or accessible via user endpoint devices should be protected.

The purpose of this control is to protect information against the risks introduced by using user endpoint devices. User endpoint devices are any devices from which information can be accessed, processed or where information can be saved. They include laptops, smartphones and PCs. A policy for user endpoint devices should include registration, physical, password and cryptographic protection, and responsible use. Responsible use includes controlling who has access to the device, installation of software, regularly updating the operating system and backing device up. An organisation may require a specific policy for bring-your-own-device to prevent disputes and the information security risks associated.

8.2 Privileged access rights

The allocation and use of privileged access rights should be restricted and managed.

The purpose of this control is to ensure only authorized users, software components and services are provided with privileged access rights.The allocation of privileged or admin access rights to users, software components and systems should be done on a case-by-case basis and only as needed. This means that there needs to be a policy in place determining when access rights can be granted and when they should expire or be revoked. when privileged access rights are granted, the user should understand what they are for and when they should be used. The first step is that privileged users should always be aware that they have admin access rights. These rights should not be used for day-to-day tasks, which should always be done with standard access accounts. Privileged access should only be used when administrator tasks are being conducted.

8.3 Information access restriction

Access to information and other associated assets should be restricted in accordance with the established topic-specific policy on access control.

The purpose of this control is to ensure only authorized access and to prevent unauthorized access to information and other associated assets. Access to information and other assets should be based on business need, with access restricted to particular users. Information should not be accessible to anonymous users to prevent untraceable and unauthorized access. This is important to preserve the confidentiality of information, to monitor its use, and to prevent modification and distribution.

8.4 Access to source code

Read and write access to source code, development tools and software libraries should be appropriately managed.

The purpose of this control is to prevent the introduction of unauthorized functionality, avoid unintentional or malicious changes and to maintain the confidentiality of valuable intellectual property. Source code needs to be kept secure to prevent unwanted changes and to keep the code confidential. The employees role and business need determines if they have read and write access. Limiting access to read-only for the majority of staff helps to protect the integrity of the code. For the same reason, developers should use development tools that control activities, rather than having direct access to the source code repository.


8.5 Secure authentication

Secure authentication technologies and procedures should be implemented based on information access restrictions and the topic-specific policy on access control.

The purpose of this control is to ensure a user or an entity is securely authenticated, when access to systems, applications and services is granted Secure authentication helps to guarantee that a user is who they say they are. The required strength of authentication is dependent on the classification of the information. Usernames and passwords provide a basic level of authentication, which can be strengthened using cryptographic or bio metric controls, smart cards or tokens, or other multi factor authentication. Login screens should show the minimum amount of information possible to avoid providing help to unauthorized persons. All login attempts should be logged, successful or not, so that attacks or unauthorized usage can be identified.

8.6 Capacity management

The use of resources should be monitored and adjusted in line with current and expected capacity requirements.

The purpose of this control is to ensure the required capacity of information processing facilities, human resources, offices and other facilities. Capacity management covers all of human resources, office space and other facilities, not just information processing and storage. Future requirements should be taken into account in business and security planning, particularly if asset acquisition has a long lead time. Cloud computing often allows flexible capacity management. In contrast, physical facilities and personnel may require more strategic planning. Optimization of physical and digital information storage, deletion of old data, and optimized batch processing and applications will mean that existing capacity is more efficiently used.

8.7 Protection against malware

Protection against malware should be implemented and supported by appropriate user awareness.

The purpose of this control is to ensure information and other associated assets are protected against malware. Malware detection software (e.g. virus scanners) provides some protection, but it is not the only was to protect against malware. Protection also includes information security awareness, access controls and change management controls to prevent malware being installed or causing problems. As a first line of defense, malware detection software needs to be installed and updated regularly. However, a policy to prevent unauthorized software installation, the use of suspicious websites, the download of files from remote sources and vulnerability detection are equally as important. Finally, the security risks can be reduced by actively planning for a malware attack. Keeping abreast of new malware, isolating critical environments, and making business continuity plans should an attack occur will all help maintain business continuity in the event of an attack.

8.8 Management of technical vulnerabilities

Information about technical vulnerabilities of information systems in use should be obtained, the organization’s exposure to such vulnerabilities should be evaluated and appropriate measures should be taken.

The purpose of this control is to prevent exploitation of technical vulnerabilities.The management of technical vulnerabilities can be divided into three categories: identification, evaluation and action. In order to identify vulnerabilities, assets must be inventoried with details of the supplier, version, deployment state and responsible owner. The vendor may provide information on vulnerabilities, but the owner should identify additional resources that monitor and release information about vulnerabilities and methods to identify vulnerabilities, such as pen-testing. When a vulnerability has been identified, the risk and urgency need to be assessed, as well as the potential risks of applying an update or patch. Updates can often be used to take action against vulnerabilities, but may not always adequately fix the problem and can introduce new issues. If no update is available or the update is considered inadequate, measures such as work arounds, isolation from the network and increased monitoring may be sufficient to mitigate the risk.


8.9 Configuration management

Configurations, including security configurations, of hardware, software, services and networks should be established, documented, implemented, monitored and reviewed.

The purpose of this control is to ensure hardware, software, services and networks function correctly with required security settings, and configuration is not altered by unauthorized or incorrect changes. Software, hardware, service and networks need to be configured to function correctly with the security settings considered necessary to protect the organisation. The configuration should be based on business need and known threats. As with all secure systems, privileged access should be limited and unnecessary functions disabled. Configuration changes should follow the change management procedure and be fully approved and documented.

8.10 Information deletion

Information stored in information systems, devices or in any other storage media should be deleted when no longer required.

The purpose of this control is to prevent unnecessary exposure of sensitive information and to comply with legal, statutory, regulatory and contractual requirements for information deletion. Information should not be kept for longer than necessary in order to reduce the information security exposure risk, to optimism resource use and to comply with laws . Approved secure deletion software should be used to ensure permanent deletion and certified disposal providers should be used for physical media. The deletion method used by cloud service providers should be checked by the organisation to ensure it is adequate. Maintaining a record of deletion is useful in the event of a data leak.

8.11 Data masking

Data masking should be used in accordance with the organization’s topic-specific policy on access control and other related topic-specific policies, and business requirements, taking applicable legislation into consideration.

The purpose of this control is to limit the exposure of sensitive data including PII, and to comply with legal, statutory, regulatory and contractual requirements. Only the minimum amount of data required for a task should be available in search results. In order to achieve this, personal data should be masked (or anonymized or pseudononymized) to hide the identity of the subjects. This may be required by laws.

8.12 Data leakage prevention

Data leakage prevention measures should be applied to systems, networks and any other devices that process, store or transmit sensitive information.

The purpose of this control is to detect and prevent the unauthorized disclosure and extraction of information by individuals or systems. Monitoring and detecting unauthorized attempts to disclose or extract data are key to prevention. When an attempt is detected, measures such as email quarantine or access blocks can be activated. Other methods, such as policies and training about uploading, sharing or accessing data should be used to address the risks of staff leaking data.


8.13 Information backup

Backup copies of information, software and systems should be maintained and regularly tested in accordance with the agreed topic-specific policy on backup.

The purpose of this control is to enable recovery from loss of data or systems. The organisation needs a specific policy on back-ups, which covers method, frequency and testing. When developing the policy, the organisation should consider points such as ensuring the completeness of back-ups and restores, the business needs of back-ups, where and how they are stored, and how the back-up system is tested. The back-up system should be considered as part of the business continuity plans and be adequate to meet the continuity requirements.

8.14 Redundancy of information processing facilities

Information processing facilities should be implemented with redundancy sufficient to meet availability requirements.

The purpose of this control is to ensure the continuous operation of information processing facilities. Any organisation needs a system architecture that is sufficient to satisfy the business availability requirements. Redundancy ensures availability by having spare capacity in case of system failure, and often requires duplicate systems such as power supplies. Adequate redundancy that can be spun up when necessary forms an important part of business continuity planning and should be tested regularly.

8.15 Logging

Logs that record activities, exceptions, faults and other relevant events should be produced, stored, protected and analysed.

The purpose of this control is to record events, generate evidence, ensure the integrity of log information, prevent against unauthorized access, identify information security events that can lead to an information security incident and to support investigations. Logging records events, generates evidence, ensures the integrity of log information, can help to prevent against unauthorized access, identifies information security events and supports investigations. A logging plan needs to identify what information should be logged (e.g. user ID) and can cover events such as system access attempts, changes, transactions, or file access, among other things. The logs must be protected even from privileged users so that they cannot be deleted or changed. The logs need to be monitored and analysed to detect patterns or incidents that may be information security incidents.

8.16 Monitoring activities

Networks, systems and applications should be monitored for anomalous behavior and appropriate actions taken to evaluate potential information security incidents.

The purpose of this control is to detect anomalous behavior and potential information security incidents. The aim of monitoring is to detect anomalous behavior and to identify potential information security incidents. The monitoring system could cover network traffic, system access, logs and use of resources. Monitoring can help to identify system failures or bottlenecks, activity associated with malware, unauthorized access, unusual behavior, and attacks such as denial of service attacks.


8.17 Clock synchronisation

The clocks of information processing systems used by the organization should be synchronized to approved time sources.

The purpose of this control is to enable the correlation and analysis of security-related events and other recorded data, and to support investigations into information security incidents. Clock synchronization is important to ensure that the timing of an information security incident is reliably recorded. On-premises systems should use a network time protocol (NTP) to ensure synchronisation. Cloud service providers generally handle timing for logging. However, on-premises clocks may not be perfectly synchronised with the Cloud provider’s clock. In this case, the difference should be recorded and monitored.

8.18 Use of privileged utility programs

The use of utility programs that can be capable of overriding system and application controls should be restricted and tightly controlled.

The purpose of this control is to ensure the use of utility programs does not harm system and application controls for information security. A utility program may be capable of overriding system and application controls. The usage of and access to utility programs should therefore be tightly restricted, with unique user identification and logging of usage.

8.19 Installation of software on operational systems

Procedures and measures should be implemented to securely manage software installation on operational systems.

The purpose of this control is to ensure the integrity of operational systems and prevent exploitation of technical vulnerabilities Software installation can introduce vulnerabilities in operating systems. To minimize this risk, software should only be installed by authorized persons. The software should be from trusted and maintained sources or fully tested if developed internally. Previous versions should be kept and all changes logged so that roll-back is possible if required.

8.20 Network security

Networks and network devices should be secured, managed and controlled to protect information in systems and applications.

The purpose of this control is to protect information in networks and its supporting information processing facilities from compromise via the network. Networks must be secure enough to protect the information passing over them. To keep them secure, they need to be kept up to date and monitored, with the option to limit both connections to authenticated devices and what traffic can pass over the network. A method to isolate the network may be useful should the network come under attack.


8.21 Security of network services

Security mechanisms, service levels and service requirements of network services should be identified, implemented and monitored.

The purpose of this control is to ensure security in the use of network services. Network security services cover everything from the provision of a simple connection and bandwidth to complex services such as firewalls and intrusion detection systems. The level of security required will depend on business need. When the required security is identified it needs to be implemented and monitored. This is often done by third party network service providers. Access authorization procedures and access means such as VPNs should be considered when setting up network security services.

8.22 Segregation in networks

Groups of information services, users and information systems should be segregated in the organization’s networks.

The purpose of this control is to split the network in security boundaries and to control traffic between them based on business needs. Large networks can be split into several domains. This means that different security levels can be applied to each domain, with limited access to different parts of the business network. The networks can be fully physically separated or digitally separated using logic networks. Wireless networks do not have physical boundaries and should therefore be considered as external connections until a gateway such as a VPN has been passed when sensitive data is being accessed.

8.23 Web filtering

Access to external websites should be managed to reduce exposure to malicious content.

The purpose of this control is to protect systems from being compromised by malware and to prevent access to unauthorized web resources. Not every website on the internet is innocent. Some contain illegal information and others distribute malware. Blocking the IP addresses of suspicious websites can reduce the risks. However, not every malicious website can be blocked, so filtering must be accompanied by rules and awareness training on appropriate and responsible internet use.

8.24 Use of cryptography

Rules for the effective use of cryptography, including cryptographic key management, should be defined and implemented.

The purpose of this control is to ensure proper and effective use of cryptography to protect the confidentiality, authenticity or integrity of information according to business and information security requirements, and taking into consideration legal, statutory, regulatory and contractual requirements related to cryptography. The use of cryptography needs to carefully be managed, with consideration of the required level of protection, key management, encryption of endpoint devices and how cryptography might impact content inspection (e.g.malware scanning). Key management requires a process generating, storing, archiving, retrieving, distributing, retiring and destroying cryptographic keys.


8.25 Secure development life cycle

Rules for the secure development of software and systems should be established and applied.

The purpose of this control is to ensure information security is designed and implemented within the secure development life cycle of software and systems. Secure development covers the construction of services, architecture, software and systems. A key aspect is the separation of development, test (approval) and production environments with secure repositories for source code. Security should be a consideration right from the specification and design phase, with checkpoints built into the project plan and planned testing. The developers must also be aware of secure coding guidelines and be able to prevent, find and fix vulnerabilities.

8.26 Application security requirements

Information security requirements should be identified, specified and approved when developing or acquiring applications.

The purpose of this control is to ensure all information security requirements are identified and addressed when developing or acquiring applications. Organisations need to identify and specify the security requirements for applications, then determine them using a risk assessment. The requirements are determined by the security classification level of the information passing through the application. Requirements can include access controls, protection level, encryption, input and output controls, logging, error message handling, resilience against attack and legal requirements. Security requires particular consideration if the application performs transactions of information or orders and payments.

8.27 Secure system architecture and engineering principles

Principles for engineering secure systems should be established, documented, maintained and applied to any information system development activities.

The purpose of this control is to ensure information systems are securely designed, implemented and operated within the development life cycle. Architectural and engineering principles ensure that systems are designed, implemented and operated securely throughout their development life cycle. Secure system principles analyse what security controls are needed and how they should be applied. Good practice, practical considerations about the cost and complexity and how new features can be integrated into existing systems should also be taken into account.

8.28 Secure coding

Secure coding principles should be applied to software development.

The purpose of this control is to ensure software is written securely thereby reducing the number of potential information security vulnerabilities in the software. Practicing secure coding helps to ensure that code is written to minimize vulnerabilities. Secure coding principles can be used to promote best practice and set minimum standards in the organisation. These should take into account current real-world threats, the use of controlled environments for development and ensuring the competence of developers. Secure coding should also include management of updates and maintenance, particularly checking who is responsible for maintaining codes from external sources.


8.29 Security testing in development and acceptance

Security testing processes should be defined and implemented in the development life cycle.

The purpose of this control is to validate if information security requirements are met when applications or code are deployed to the production environment. Security testing should be an integral part of development testing. This includes testing of secure configuration of operating systems (e.g. firewalls), secure coding and security functions (such as access). The tests need to be scheduled, documented and have criteria to determine acceptable results.

8.30 Outsourced development

The organization should direct, monitor and review the activities related to outsourced system development.

The purpose of this control is to ensure information security measures required by the organization are implemented in outsourced system development. When development is outsourced, information security requirements need to be communicated to and agreed by the outsourced developer and monitored by the outsourcing organisation. Licensing and intellectual property ownership, testing and evidence of testing, and contractual rights to audit the development process are examples of security considerations that should be agreed between the parties.

8.31 Separation of development, test and production environments

Development, testing and production environments should be separated and secured.

The purpose of this control is to protect the production environment and data from compromise by development and test activities. Testing and development activities can cause unwanted changes or system failure, which could compromise the production environment if it is not adequately protected. The degree of separation between testing and production will depend on the organisation, but environments need to be separated and clearly labelled, so that testing or actions such as compiling cannot take place in the production environment. Changes should be monitored, with careful control over who has access to each environment. No one should have the ability to make changes to both the testing and production environment without prior review and approval.

8.32 Change management

Changes to information processing facilities and information systems should be subject to change management procedures.

The purpose of this control is to preserve information security when executing changes. The confidentiality, availability and integrity of information can all be compromised when introducing infrastructure or software or making major changes to an existing one. A formal process of documentation, testing, quality control and implementation can reduce the risks. Documentation of testing and contingency planning are important in the run-up to implementation, particularly to ensure that new software does not negatively impact the production environment. Operating guides and procedures may need to be altered after the changes have been made.


8.33 Test information

Test information should be appropriately selected, protected and managed.

The purpose of this control is to ensure relevance of testing and protection of operational information used for testing. There are two key considerations for test information: it should be close enough to operational information to ensure the test results are reliable, but it should not contain any confidential operational information. If sensitive information must be used for testing, it should be protected, modified or anonymised before being used, and should be deleted immediately after testing.

8.34 Protection of information systems during audit and testing

Audit tests and other assurance activities involving assessment of operational systems should be planned and agreed between the tester and appropriate management.

The purpose of this control is to minimize the impact of audit and other assurance activities on operational systems and business processes. The operational systems should not be unduly affected by audits or technical reviews. To prevent excessive disturbance, the audits should be planned with agreed timing and scope. Read-only access will prevent accidental changes to systems during an audit, and all access should be monitored.


Back to Home Page

If you need assistance or have any doubt and need to ask any questions contact me at You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.