ISO 27001:2022 Clause 4 Context of the organization

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.

LEGISLATION	IS 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, 2008	Legislation 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.

1.Customer:
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

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

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

1.Overview
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 preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.