Clause 4: Context of the organization
As per ISO, the definition of Context of the Organization is “business environment“, “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 organization, public service organization and governmental organization. Also in normal language this concept is also known as business environment, organizational environment or ecosystem of an organization.
Information security management is a major issue worldwide.It describes the behaviours of commercial organizations and government bodies, many of whom are seizing opportunities to analyse 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 an 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 organisation 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 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 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 refers 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 organisation’s overall business is maintained here. There is an explicit requirement to consider both internal and external issues which might impact the organisation’s purpose and affect its ability to achieve the expected outcomes of the ISMS. External and internal issues has 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, organisational and security risk management contexts. Security risk management is applicable across all facets of an organisation’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 is important as they make judgements 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 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:
- risk management takes place in the context of the objectives of the organization;
- 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
- 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 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. Context of 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 in a sufficient extent and on a sufficient level of detail. The next step is the risk identification, that determine 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 controls. In the risk acceptance step, residual risks have to be accepted by managers of the organisation.
For example let us consider a ICT(Information and Communication Technology) system. An ICT system is a software system that processes data for stakeholders. The software system consists of resources that have a location and the system consists of hardware and software. The system is embedded into a direct system environment, which contains stakeholders that have a direct relation to the system. The direct system environment is further embedded into the indirect system environment, which contains stakeholders that have no direct relation to the system. The System Owner owns the ICT system, the Administrator maintains the resources of the software system. The Developers develops software for the ICT system. The system has an Internal Users that works for the System Owner and exchanges data with the ICT system. In addition, External Users work for a Customer of the System Owner. The stakeholder of the indirect environment are the legislator, a set of all relevant laws from a specific country. The template can be instantiated with multiple legislator of all the countries relevant for the ICT system. The domain represents a set of all relevant regulations for, e.g., the finance domain.
The first step is about gathering information about the organization. This can be done by systematically gathering domain knowledge about the direct and indirect system environments based upon the stakeholders’ relations to the system and other stakeholders.
Let us take an example for Administrator.
- Name: Administrator
- Description: The administrator repairs the system and he/she executes maintenance efforts.
- Relations to the ICT system: The administrator has access to the entire data in the system.
- Motivation: The administrator earns money by maintaining the resources of the ICT system.
- Relations to other direct stakeholders: The administrator has a contract with the System Owner to maintain the system. There might also be further contracts, e.g., preventing the administrator from accessing the Customers data.
- Assets: The administrator has no direct assets in the ICT system. However, if the ICT system does not exist, he/she would not earn money. Hence, the system itself could be considered the asset of the administrator.
When the gathering of information about the organization is done,a context establishment as a next step. It consist of the basic criteria, the scope and boundaries and the organization of information security risk management (ISRM).
The basic criteria is instantiated with a set of resources, which have to be elicited before the instantiation. Resources are all relevant elements of an organization to the ISRM. The basic criteria requires further that information assets have to be derived from the set of resources. Afterwards the resulting set of information assets has to be refined to classes of similar information assets. For each of these classes an assessment of security breaches has to be conducted. This shall be done for at least the following kinds of security issues: CIA breaches, financial and business loss, compliance breaches. Afterward criteria have to developed for each class of information assets based on the assessed breaches and losses. Those criteria should include risk evaluation criteria, impact criteria and risk acceptance criteria. The scope and boundaries has to be instantiated with collected information artifacts about organization. These artifacts have to be collected from: business objectives, strategies, information security policies, business processes, organizational functions and structure, legal and contractual requirements, stakeholders and their expectations, socio-cultural environment, and interfaces between environment and organization. For each collected information artifact, it has to be decided whether it shall be included in the scope and boundaries (or not). An information security risk management process has to be defined and documented, as part of the description of the organization of the ISRM. Such a process should contain the stakeholders of the system, the roles they enact, the activities they execute, the relations between stakeholders, roles and the organization, and the records to be kept.
Stakeholder As defined above.
- Rolename: A short name of the role
- Description: A summarizing description of the role
- Stakeholder: A list of stakeholders which can enact the role
- Precondition :Conditions to be fulfilled to enact this role.
- Responsibilities: A description for which assets and resource the role is responsible
- Rights: A description of rights the role has to have to fulfill the responsibilities.
- Excluded roles: A list of roles which are not allowed to be bound to a stakeholder, who enacts the role at hand, at the same time.
2. Resources And Assets
- Name: Identifier for the resource or asset.
- Description: A summarizing description of the resource or asset.
- Stakeholder: A list of stakeholders, which have a relation to the resource or assets. The relation has also to be described
- Identifier: Identifier for the record
- Description: A summarizing description of record
- Template: A template to generate a record
- Activity: A short name of the activity.
- Description: A summarizing description of the activity.
- Precondition: Activities and constrains to be fulfilled before this activity can be executed.
- Affected Stakeholders: A list of stakeholders which are affected by the activity.
- Roles: The roles which are allowed to execute this activity.
- Resources and Assets: A list of resources and assets which are necessary for the activity.
- Records: List of records to be generated when this activity is executed.
- Postcondition: Activities and constrains to be fulfilled after this activity has been executed
The context of organization can include, but is not limited to:
- governance, organisational structure, roles and accountabilities
- The organization should consider what aspects of strategic context are relevant to their situation, and factor these into their risk assessment process. These can include, but are not limited to:
- relevant Governmental legislation, regulation and policy, including responsibility for safeguarding information.
- foreign laws and potential jurisdictional access to information, and
- the potential benefits of outsourcing and other arrangements.
This step is used to comprehensively determine all applicable sources of risk and potential events that could impact Organization business.Each risk should be described in as full a manner as possible, so that decision makers can fully understand the situation. Organization should identify risks to the confidentiality, availability and integrity of Government information subject to their ICT arrangements. The criteria for determining an organization’s risk tolerance should be done during the ‘Establishing the context’ phase of the risk assessment process. Determining risk tolerance will be highly dependent on the organisational context of the Organization and its Top management. The level of tolerance for risk is the sum of the Organization’s risk appetite. The risk tolerance is based on the principle of managing risk to a level that is as low as reasonably practicable, while still allowing scope for flexible and innovative business practices. An organization’s tolerance can be affected by certain changing evaluation criteria. Therefore, an Top Management’s appetite for risk can vary depending upon:
- prevailing political and community sensitivities and expectations.
- the nature of the security incident (e.g. terrorist act, hacking)
- existing or emerging security incidents trends (trusted insider, cyber-attacks)
- strategic or business priorities
- resource availability for treatment, and
- the ability of the organizations or individual to absorb losses.
In most cases determining an organization’s risk tolerance can be understood as a gradient, where the risk may become progressively less tolerable as the risk level is increased. Organizations may also use their security plans as a source of information as the risk tolerance determined as part of that plan should be broadly consistent with risk assessments undertaken for outsourced or offshore arrangements.
Understanding the nature of the relevant or potential threat, criticality and vulnerabilities is an essential component of establishing context. Below are a series of considerations and questions that can facilitate this process:
- How could the confidentiality, integrity and availability of information be affected?
- What is the aggregated value of the information holdings to the Organization?
- What would an unintended disclosure look like? What would an event or incident look like?
- What would be the impact of loss of confidence in the integrity of your information? For example, the integrity of the customer record.
- How could an unintended disclosure of information occur in an outsourced or offshore arrangement? What are the sources of risk? What threats are there?
- When searching for information to inform the risk identification process, agencies should take into account individual agency security plans, as these are a ready source of information on risks to agency information.
Below are the top nine threats to Cloud service as identified by the Cloud Security Alliance’s The Notorious Nine: Cloud Computing Top Threats in 2013. Organization should not limit their consideration exclusively to this list, but use this list to inform their assessment of the use of outsourcing or offshoring information.
- Data Breaches – sensitive internal data is stolen, leaked or accessed by external unauthorised entities.
- Data Loss – the permanent loss or deletion of data by accident or malicious activity.
- Account or Service Traffic Hijacking – external entities eavesdropping on your activities, transactions, manipulating data, return falsified information, through phishing, fraud and exploitation of software vulnerabilities still achieve results.
- Insecure Interfaces and Application Programming Interface (API ) – vulnerable interfaces can be exploited both accidentally and maliciously in an attempt to circumvent security process.
- Denial of service (DoS) – DoS attacks can prevent users from accessing their data or applications, while forcing the victim to consume inordinate amounts of finite system resources.
- Shared Technology Vulnerabilities – Cloud infrastructure (CPU caches, GPU, etc) that is not designed to offer a multi-tenant architecture is vulnerable to scalable sharing practices. This vulnerability is dangerous because it can affect an entire Cloud at once.
- Malicious Insider – a current or former employee, contractor or other business partner who has or had authorised access to an organisation’s network, system, or data and intentionally exceeded or misused that access in a manner that negatively impacts the organisation’s information systems.
- Abuse of Cloud Services – this threat is more an issue for Cloud service providers, but Cloud services can facilitate malicious agendas through the exploitation of Cloud infrastructure.
- Insufficient Due Diligence –entering into ICT arrangements with Cloud services providers without effectively understanding the full scope of the undertaking, its weakness and vulnerabilities.
Due to the evolving nature of technology the threat environment is constantly changing. As a result, there is a need for ongoing oversight and management of the threat environment and its potential impact and consequences
To fully understand the potential of the risks identified, the organization should develop a clear understanding of the vulnerabilities that are apparent from each risk event. This is essential to gauge the consequence and likelihood of these risk events to inform the risk assessment. This process will also help in the prioritisation of the identified risks, and guide the allocation of resources in mitigating their impacts.The organization should consider the following for each identified risk:
- What is the likely outcome of the risk eventuating?
- When and how frequently can the risk happen?
- Where is risk the likely to impact?
- Who could be impacted by the occurrence of the risk event?
- Who are the stakeholders of the risk event? What is the impact to them?
- What catalysts could lead to the risk event?
- How can eventuality of the risk be mitigated?
- How can the consequences of the risk event be mitigated?
- How reliable is the information that this risk assessment is being based upon?
Once the range of relevant risks has been identified, the risk assessment process should determine the level of risk. To achieve this, the potential consequences of the risk event, the likelihood of it occurring, and the acceptable levels of tolerance should be evaluated holistically. The sources of risk events, and the effectiveness of existing controls to prevent or reduce the consequences of risk events should be considered in assessing the likelihood and consequence levels. This includes the level of oversight and control agencies have on the management of their information. As an example, all Organization information should be assessed in relation to Confidentiality, Integrity and Availability, including aggregation. For each of these areas, risks events must be assessed against the potential of their impact for-Whole of organization, their Department/Agency, and their customer. The chance of the risk event occurring and whether there are extant controls or measures in place to reduce the effects of the event needs to also be considered.
1. Guidance on determining potential consequences
The consequence of unintended disclosure of information will depend on the profile of that information. For example unintended disclosure or compromise of organization’s information could affect the:
- organization’s capacity to make decisions or operate
- privacy and integrity of personal information about employees
- the safety of persons
- public’s confidence in organizations
- market stability and commercial interests
- the competitive process, and
- compliance with legislation.
2. Guidance on determining likelihood
The likelihood is the chance or probability of an event or incident occurring resulting in the unintended disclosure or compromise of organization information. When considering the likelihood, the organization should consider the timeframe in which the risk could potentially occur. The organization may represent likelihood on a predetermined scale, for example, low, medium and high. Alternatively, it can be presented as a percentage.
3. Guidance on rating risk
Determining the risk rating is the sum of combining the defined likelihood and consequence estimations. The risk rating should be between the level of “Extreme” and “Low”. While initial estimations of likelihood and consequence can present risks identified as “extreme” or “low”, the overall risk rating should be the sum of all identified risks calculated together. It is appropriate, when rating risk to use the ‘most credible’ scenario to determine the overall
|Remote||VERY LOW||VERY LOW||LOW||MEDIUM||HIGH|
|Possible||VERY LOW||LOW||MEDIUM||HIGH||VERY HIGH|
|Likely||VERY LOW||LOW||MEDIUM||HIGH||VERY HIGH|
|Almost certain||LOW||LOW||MEDIUM||HIGH||VERY HIGH|
Evaluating the risks of unintended disclosure of organization’s information involves considering the risks within the context of the organization’s risk tolerance and potential treatment options. In some circumstances, the risk of unauthorised access or disclosure of information can be quantified almost entirely in financial terms based on a loss of revenue. In these circumstances, determining the risk is a matter of financial calculation. However, in most circumstances, the should consider a wider range of factors, including the potential reputational cost of a disclosure due to a loss of citizens’ or businesses’ data. In these circumstances, calculating the risk is a more complex process and the acceptance of that risk resides with the agency head. There may be circumstances where the factors for consideration and judgments required are so complex that the risk of is incalculable. If the risk is determined to be incalculable, it will not be possible to manage it and Top Management should not enter into these arrangements.
Security is not absolute. Efforts to treat risks will not remove them completely, but should aim to make the risk levels more tolerable. When selecting risk treatments the allocation of resources should be conducted proportionally to the determined risks rating level. This includes a six step process where organization
- Prioritise intolerable risks.
- Establish treatment options.
- Identify and develop treatment options.
- Evaluate treatment options.
- Detailed design and review of chosen options, including the management of residual risks.
- Communication and implementation.
Example of External issues relevant for ISMS
- 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, 2008||Legislation Covering IT Act 2000 and it amendment 2008, We must ensure that all the requirements of this acts are covered.|
- 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‟.
- 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.
- 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.
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 enquiries putting pressure on our internal resources and IT and IS systems.
Example of Internal issues relevant for ISMS
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 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 are recruited form 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 is 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 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 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:
- shareholders/owners of the business
- government agencies/regulators
- emergency services (e.g., firefighters, police, ambulance, etc.)
- employee families
- 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 organisation to consider their needs and expectations. However, these needs and expectations are only those relevant to the 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. 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 with their individual expectations.
Their Requirements are as follows:
- To Provide products, services and maintenance support in accordance with contractual requirements.
- To provide products, services and maintenance support in the event of any disruption.
- To Provide provide products, services and maintenance support in accordance with applicable legal requirements.
- 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).
- To provide products, services and maintenance support atany time (24/7/365).
- ISO 27001 Compliance
- 99.9% Availability of Systems
- Meeting SLA (4hr response – contact centre)
- PCI DSS Requirements 9 & 12
- To provide products, services and maintenance support that add value.
2. End Users
Our products and services interact with various groups of end users.
Their Requirements are as follows:
- Products and services that we directly provide, and those that our customers provide (using our systems), are available when required.
- Our products and services are reliable and simple (to use).
- There is a simple and effective process to enable lone workers to specify accurate, complete and up-to-date personal details.
- Our products and services adequately protect personal data (contact details) and sensitive personal data (medical details).
- We can support our products and services at all times.
- In the event of disruption, we can continue operation of products and services that we directly provide, and continue to provide support for those that customers provide (using our systems).
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.
Their Requirements are as follows:
- 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.
- We develop software in accordance with any mutually agreed schedule.
- Our relationship is not adversely affected by the departure or absence of any of our workers.
- We comply with any confidentiality and non-disclosure agreements.
- We provide required training, to enable the reseller to sell our products and services.
- We efficiently expedite orders.
- 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
Their Requirements are as follows:
- We purchase their products and/or services.
- Where applicable, we provide complete and accurate information when we require their technical support.
- Where applicable, we subscribe to their technical support.
- Adherence to contractual agreements
- Adherence to payment terms
We currently have approximately 30 employees, in roles of management, software development, computer and telephony engineering, sales, telemarketing, account management, finance and administration.
Their Requirements are as follows:
- The company is profitable and provides secure work.
- The company provides a safe and appropriate work environment.
- The company provides required training and support.
- The company clearly specifies its requirements and expectations of workers.
- Workers believe that they can positively contribute to the success of the company.
- The company facilitates dialogue with workers so that they are aware of their contribution.
- The company protects their personal information.
- The company pays fairly for work.
- The company provides opportunities for continuity of employment
- The company provides opportunities for advancement
If fines or damages were the result 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.
Their Requirements are as follows:
- The Company should be meeting policy requirements
- The Company should be making timely payment of premiums
- The company should be reporting changes in circumstances
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.
Their Requirements are as follows:
- 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. Organisations such as the Direct Marketing Association (DMA) have security requirements that we would need to follow.
Their Requirements are as follows:
- Membership requirements
- Meeting standards to which the organization adheres
- Provision of guidance
- Terms and Conditions for the workers
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.
Their 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 its 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 organisation. 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 organisations in meeting their security requirements and planning for ISMS implementation, for the organisation 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 organisation’s security requirements, the organisation 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 organisation as a whole, or parts of the organisation. Use boundaries and applicability information to clarify the scope of your organization’s ISMS. The selected ISMS scope should be critical to the organisation 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 organisational known risks. For example, in a financial institution, the risks of unauthorised access of online transactions may give critical impact to its business operations. Thus, the ISMS scope for this financial institution can be defined as online transaction services. Examples of questions that can guide organisations when defining the ISMS scope and boundaries:
- Which service in your organisation will be covered by the ISMS?
- How and why is the selected service critical to your organisation?
- What are the characteristics of the selected service; i.e. business, the organisation, its locations, assets and technologies to be included in the ISMS?
- Will you require external parties to abide by your ISMS?
- Are there any interfaces or dependencies between activities performed by the organisation; 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, organisations 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 organisational business objectives.In order to identify ISMS scope and boundaries, organisations should perform the following activities:
- Consider the organisation’s information security requirements which have been identified in Clause 4.1 – Define Information Security Requirements;
- Consider any interfaces and dependencies between activities performed by the organisation, and those that are performed by other organisations;
- Consider critical services that can cause major impact to the organisation and/or nation arising from losses of confidentiality, integrity or availability;
- Define the organisational scope and boundaries;
- Define Information Communication Technology (ICT) scope and boundaries,
- Define physical scope and boundaries; and
- Integrate elementary scope and boundaries to obtain the ISMS scope and boundaries.
For clarity, organisations 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 has been found to meet the standards requirements.
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 are 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 clients 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) are 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 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 where in 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 then 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.
Scoping is a critical part of planning the roll-out and implementation of an information security management system (ISMS). An organisation 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. Scope will be shaped by:
- the business of an organisation
- the needs and expectations of relevant interested parties
- the organisational structures that are currently in place.
It is important to correctly define and agree 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 organisation 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 organisation. However, in most Higher Education environments it would be difficult to tackle the whole organisation in one go. Similarly, it would be an almost impossible task to certify the entire organisation against a ISO/IEC 27001 standard or other standards like PCI DSS. Thus the organisation 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 organisation in achieving its business objectives. It is important to understand which of these the organisation considers to be most important, and so a risk-based, prioritised approach should be taken to scoping. In order to establish that assets are actually worth protecting, the organisation should justify why each asset requires protecting. 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, 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 regulatory environment
- changes/updates to standards and/or third party requirements
- change in organisation (e.g. organisation structure changes)
- identification of non-conformities and/or incidents indicating incorrect scope
- 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 organisation.”
Cloud services may be defined as “A shared computer-based storage solution for data that is based in a virtualized computer environment.” Cloud services can describe any shared environment, which can be provided both locally or outsourced.
All organisations 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 organisation 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 organisation’s IT solution, or to use cloud storage or services. Economies of scale means 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 organisation.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 organisations. 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 organisation to decide how it may be assured that services provided are of an appropriate standard.
Understanding an organisation’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 authorisation: it is essential to make sure the rules and regulations for who can access what are clearly defined. If the organisation is allowing contractors into buildings, it should understand who has the keys or access codes; and who ensures the staff are trained and things are secure. Out of hours office cleaning staff often have more physical access to an organisation than even the most trusted day staff. Access to IT systems and data should also be considered.
- Disclosure and privacy: the organisation should define and categorise 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 apply 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 organisation.
- At the end of the business relationship, how will it be possible for the organisation’s information to be extracted from the third party environment in a usable form?
- What provisions (if any) are in place for compensating the organisation 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 e- mail, 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 at the 3rd floor of MSTC LTD H.O. having its address at 225C, AJC Bose Road, Kolkata-700 020. It also includes the following :
- Law, HR and Admin functions associated with e-commerce.
- DR site located at 607 Raheja Centre, Nariman Point, Mumbai – 400 021.
- 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 organisations.
- Privately owned equipment used in the course of employment with the County Council
- The Contact Centre
- Telephony network
Areas not covered by the ISMS
- Organisations for which Lancashire County Council is merely the accountable body
4.4 Information security management system
The organization must establish, implement, maintain and continually improve an information security management system, 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 which 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 an 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. Analysing 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:
- awareness of the need for information security;
- assignment of responsibility for information security;
- incorporating management commitment and the interests of stakeholders;
- enhancing societal values;
- risk assessments determining appropriate controls to reach acceptable levels of risk;
- security incorporated as an essential element of information networks and systems;
- active prevention and detection of information security incidents;
- ensuring a comprehensive approach to information security management; and
- continual reassessment of information security and 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 includes three main dimensions: confidentiality, availability and integrity. Information security involves the application and management of appropriate security measures that involves 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.
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.
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 form 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:
- identify information assets and their associated information security requirements
- assess information security risks and treat information security risks
- select and implement relevant controls to manage unacceptable risks and
- 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:
- identified information assets and their value;
- business needs for information processing, storage and communication; and
- 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 a risk, the organization should decide 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:
- applying appropriate controls to reduce the risks;
- knowingly and objectively accepting risks, providing they clearly satisfy the organization’s policy and criteria for risk acceptance;
- avoiding risks by not allowing actions that would cause the risks to occur;
- 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:
- requirements and constraints of national and international legislation and regulations;
- organizational objectives;
- operational requirements and constraints;
- their cost of implementation and operation in relation to the risks being reduced, and remaining proportional to the organization’s requirements and constraints;
- 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.
- 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 projects requirements specification and design stage. Failure to do so can result in additional costs and less effective solutions, and maybe, in the worst case, 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 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:
- analysing and evaluating the existing situation to identify areas for improvement;
- establishing the objectives for improvement;
- searching for possible solutions to achieve the objectives;
- evaluating these solutions and making a selection;
- implementing the selected solution;
- measuring, verifying, analysing and evaluating results of the implementation to determine that the objectives have been met;
- 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 review 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 programme, 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.
If you need assistance or have any doubt and need to ask any question contact me at: firstname.lastname@example.org. You can also contribute to this discussion and I shall be happy to publish them. Your comment and suggestion is also welcome.