ISO 27001:2022 Clause 6 Planning

by Pretesh Biswas

Audio version of the article

An understanding of risk and the application of risk assessment methodology is essential to being able to efficiently and effectively create a secure computing environment. The fundamental precept of information security is to support the mission of the organization. All organizations are exposed to uncertainties, some of which impact the organization in a negative manner. The organization must manage these uncertainties. Managing uncertainties is not an easy task. Limited resources and an ever-changing landscape of threats and vulnerabilities make completely mitigating all risks impossible. Therefore, the organization must have a tool set to assist them in sharing a commonly understood view with IT and business managers concerning the potential impact of various IT security-related threats to the mission. This toolset needs to be consistent, repeatable, cost-effective and reduce risks to a reasonable level. Risk management is nothing new. There are many tools and techniques available for managing organizational risks. There are even a number of tools and techniques that focus on managing risks to information.

6 Planning

6.1 Actions to address risks and opportunities

6.1.1 General

While planning for the information security management system, the organization must consider the internal and external issues as identified in Clause 4.1 (Understanding the organization and its context) and the requirements of the interested parties relevant to information security referred to in 4.2 (Understanding the needs and expectations of interested parties) to determine its risks and opportunities. The organization must ensure the information security management system can achieve its intended outcomes, prevent, or reduce, undesired effects and achieve continual improvement. The organization must plan adequate actions to address these risks and opportunities. The organization must also plan to integrate and implement the actions into its information security management system processes and evaluate the effectiveness of these actions.

6.1.2 Information security risk assessment

The organization must define and apply an information security risk assessment process by establishing and maintaining information security risk criteria that include the risk acceptance criteria and criteria for performing information security risk assessments. The organization must ensure that repeated information security risk assessments produce consistent, valid, and comparable results. The organization must identify information security risks. The organization must apply the information security risk assessment process to identify risks associated with the loss of confidentiality, integrity, and availability for information within the scope of the information security management system and must identify the risk owners. The organization must analyze information security risks to assess the potential consequences that would result if the risks identified were to materialize and also assess the realistic likelihood of the occurrence of the risks identified, and determine the levels of risk. The organization must evaluate information security risks to compare the results of risk analysis with the risk criteria established and prioritize the analyzed risks for risk treatment. The organization must retain documented information (keep records) about the information security risk assessment process.

6.1.3 Information security risk treatment

The organization must define and apply an information security risk treatment process. It must select appropriate information security risk treatment options, taking account of the risk assessment results. It must determine all controls that are necessary to implement the information security risk treatment options chosen. The organization can choose to design controls as required or identify them from any source. It can compare the controls it has determined necessary to implement with the list of controls listed in Annex A of ISO 27001 . While determining controls for the organization, it must verify that no necessary controls have been omitted or overlooked. Annex A contains a list of possible information security controls.. The controls listed in Annex A are not exhaustive and additional control objectives and controls may be included if needed. The organization must produce a Statement of Applicability that contains the necessary controls and justification for inclusions, whether they are implemented or not, and the justification for exclusions of controls from Annex A. The organization must formulate an information security risk treatment plan, and obtain the risk owner’s approval of the information security risk treatment plan and acceptance of the residual information security risks. The organization must retain documented information(keep records) about the information security risk treatment process.The information security risk assessment and treatment process in ISO 27001 is aligned with the principles and generic guidelines as given in ISO 31000

What Is Risk With Respect To Information Systems?

ISO 27000 defines Risk as “effect of uncertainty on objectives”, where the effect is a deviation from the expected – positive or negative and  Uncertainty is the state, even partial, of deficiency of information related to understanding or knowledge of, an event, its consequence, or likelihood. Risk is often characterized by reference to potential events and consequences, or a combination of. these, Risk is often expressed in terms of a combination of the consequences of an event including changes in the circumstances and the associated likelihood of occurrence. In the context of information security management systems, information security risks can be expressed as the effect of uncertainty on information security objectives. the information security risk is associated with the potential that threats will exploit vulnerabilities of an information asset or group of information assets and thereby cause harm to an organization

.Risk is the potential harm that may arise from some current process or from some future event. Risk is present in every aspect of our lives and many different disciplines focus on risk as it applies to them. From the IT security perspective, risk management is the process of understanding and responding to factors that may lead to a failure in the confidentiality, integrity or availability of an information system. IT security risk is the harm to a process or the related information resulting from some purposeful or accidental event that negatively impacts the process or the related information. Risk is a function of the likelihood of a given threat-source’s exercising a particular potential vulnerability and the resulting impact of that adverse event on the organization.

Threats

According to ISO 27001, Threats can be defined as “potential cause of an unwanted incident which may result in harm to a system or organization”. It has also be defined as “The potential for a threat source to accidentally trigger or intentionally exploit a specific vulnerability.” Threat source can be defined as “Intent and method targeted at the intentional exploitation of a vulnerability  a situation and method that may accidentally trigger a vulnerability.”
The threat is merely the potential for the exercise of a particular vulnerability. Threats in themselves are not actions. Threats must be coupled with threat-sources to become dangerous. This is an important distinction when assessing and managing risks, since each threat-source may be associated with a different likelihood, which, as will be demonstrated, affects risk assessment and risk management. It is often expedient to incorporate threat sources into threats.

Vulnerability:

ISO 27001 defines Vulnerability as the” weakness of an asset or control that can be exploited by one or more threats.” The vulnerability can also be defined as a flaw or weakness in system security procedures, design, implementation, or internal controls that could be accidentally triggered or intentionally exploited and result in a security breach or a violation of the system’s security policy. The vulnerability can be a flaw or weakness in any aspect of the system. Vulnerabilities are not merely flaws in the technical protection provided by the system. Significant vulnerabilities are often contained in the standard operating procedures that systems administrators perform, the process that the help desk uses to reset passwords, or inadequate log review. Another area where vulnerabilities may be identified as at the policy level. For instance, a lack of a clearly defined security testing policy may be directly responsible for the lack of vulnerability scanning.

How Is Risk Assessed?

The principal reason for managing risk in an organization is to protect the mission and assets of the organization. Therefore, risk management must be a management function rather than a technical function. It is vital to manage risks to systems. Understanding risk, and in particular, understanding the specific risks to a system allow the system owner to protect the information system commensurate with its value to the organization. The fact is that all organizations have limited resources and risk can never be reduced to zero. So, understanding risk, especially the magnitude of the risk, allows organizations to prioritize scarce resources.
Risk is assessed by identifying threats and vulnerabilities, then determining the likelihood and impact of each risk. It’s easy, right? Unfortunately, risk assessment is a complex undertaking, usually based on imperfect information.

Identifying Threats
As was alluded to in the section on threats, both threat-sources and threats must be identified. Threats should include the threat-source to ensure accurate assessment. Some common threat-sources include:

• Natural Threats—floods, earthquakes, hurricanes
• Human Threats—threats caused by human beings, including both unintentional (inadvertent data entry) and deliberate actions (network-based attacks, virus infection, unauthorized access)
• Environmental Threats—power failure, pollution, chemicals, water damage

Individuals who understand the organization, industry, or type of system (or better yet all three) are key in identifying threats. Once the general list of threats has been compiled, review it with those most knowledgeable about the system, organization, or industry to gain a list of threats that applies to the system.
It is valuable to compile a list of threats that are present across the organization and use this list as the basis for all risk management activities. As a major consideration of risk management is to ensure consistency and repeatability, and organizational threat list is invaluable.

  Identifying Vulnerabilities
Vulnerabilities can be identified by numerous means. Different risk management schemes offer different methodologies for identifying vulnerabilities. In general, start with commonly available vulnerability lists or control areas. Then, working with the system owners or other individuals with knowledge of the system or organization, start to identify the vulnerabilities that apply to the system. Specific vulnerabilities can be found by reviewing vendor websites and public vulnerability archives, such as Common Vulnerabilities and Exposures or the National Vulnerability Database. If they exist, previous risk assessments and audit reports are the best places to start. Additionally, while the following tools and techniques are typically used to evaluate the effectiveness of controls, they can also be used to identify vulnerabilities:

• Vulnerability Scanners – Software that can examine an operating system, network application or code for known flaws by comparing the system (or system responses to known stimuli) to a database of flaw signatures.
• Penetration Testing – An attempt by human security analysts to exercise threats against the system. This includes operational vulnerabilities, such as social engineering
• Audit of Operational and Management Controls – A thorough review of operational and management controls by comparing the current documentation to best practices (such as ISO 17799) and by comparing actual practices against current documented processes.

It is invaluable to have a base list of vulnerabilities that are always considered during every risk assessment in the organization. This practice ensures at least a minimum level of consistency between risk assessments. Moreover, vulnerabilities discovered during past assessments of the system should be included in all future assessments. Doing this allows management to understand that past risk management activities have been effective

Relating Threats to Vulnerabilities
One of the more difficult activities in the risk management process is to relate a threat to a vulnerability. Nonetheless, establishing these relationships is a mandatory activity, since the risk is defined as the exercise of a threat against a vulnerability. This is often called threat-vulnerability (T-V) pairing. Once again, there are many techniques to perform this task. Not every threat-action/threat can be exercised against every vulnerability. For instance, a threat of “flood” obviously applies to a vulnerability of “lack of contingency planning”, but not to a vulnerability of “failure to change default authenticators.”

 Defining Likelihood
Determining likelihood is fairly straightforward. It is the probability that a threat caused by a threat-source will occur against a vulnerability. In order to ensure that risk assessments are consistent, it is an excellent idea to utilize a standard definition of likelihood on all risk assessments. Be very careful in setting up the likelihood definitions. A qualitative scale that can be used to assess the likelihood of a risk eventuating. This ensures that risks can be assessed in a consistent manner by providing workshop participants with a standardized framework for assigning a likelihood rating. Where information is available about the frequency of an incident in the past it should be used to determine the likelihood of the risk eventuating. However, where such information does not exist it does not necessarily mean that the likelihood of the risk eventuating is low. It may merely indicate that there are no controls in place to detect it or that the agency has not previously been exposed to the particular risk. The most important thing is to make sure that the definitions are consistently used, clearly communicated, agreed upon, and understood by the team performing the assessment and by organizational management.

Defining Impact
In order to ensure repeatability, the impact is best defined in terms of impact upon availability, impact upon integrity and impact upon confidentiality. All impacts need to be seen in a business context, and be informed by the business. The effect of a risk event materializing should be assessed using the approved risk rating scales. If a risk has multiple potential consequences then the impact with the largest effect must be used to rate the risk. However, where multiple consequences for a single risk are assessed at the same level the impact may be evaluated as being higher than the individual impact statements (e.g., a risk that has two moderate impacts might be judged to have a significant impact when they are combined). Rating the impact of a risk should include a consideration of any possible knock-on effects of the consequences of the identified risks, including cascade and cumulative effects.

Assessing Risk
Assessing risk is the process of determining the likelihood of the threat being exercised against the vulnerability and the resulting impact from a successful compromise. When assessing likelihood and impact, take the current threat environment and controls into consideration. Likelihood and impact are assessed on the system as it is operating at the time of the assessment. Do not take any planned controls into consideration. 

Risk Assessment Process

A risk assessment process is designed to enable Organizations to systematically identify, analyze and evaluate the information security risks associated with an information system or service together with the controls required to manage them. The process has incorporated the Establish Context phase into the risk assessment process. This ensures that risks are analyzed and evaluated within the relevant business context. The output of the risk assessment process is a report that captures the information security risks associated with the information system or service taking into consideration the agency’s business context.

1.Establishing the Context

During a risk assessment, it is essential to establish the business and technical context of the information system being reviewed. Establishing the context ensures that the business’s objectives are captured and that the internal and external factors that influence the risks are considered. It also sets the scope for the rest of the process.
Business Context
Meet with the business owner of the information system to establish the business context. During the meeting the business owner is responsible for identifying and defining the:

• Information Classification – the official information stored, processed and/or transmitted by the information system must be assigned an official classification .
• Business Processes Supported – the business processes and objectives supported by the information system. This should include any secondary, dependent or supporting processes.
• Users of the System – the different types of users of the information system. This should include the level of privileges they require to perform their duties or to use the system. Users may include business users, operations support staff and external users of services such as members of the public or another staff.
• Security and Compliance Requirements – the confidentiality, integrity, availability (CIA) and privacy requirements of the system together with any relevant laws and/or regulations that need to be met by it.
• Information Protection Priorities – the business owner’s prioritization of the confidentiality, integrity, availability, and privacy of the information stored, processed or transmitted by the information system.

Technical Context
Establish a technical context to provide a basic understanding of the security posture of the information system. A risk assessment may be performed for an information system that is already in production or as part of the development life cycle of a new information system. The following provides guidance on who should be involved in establishing the technical context:

• Service Owner – the service owner (or their nominated delegate) is responsible for identifying the components and defining the boundaries of an information system that is the scope of the risk assessment.
• Enterprise or Solution Architect – the Architect is responsible for identifying the components and defining the boundaries of an information system that is within the scope of the risk assessment.
• Subject Matter Experts – ICT operations staff responsible for the ongoing support and maintenance of the information system that is within the scope of the risk assessment.

The technical context discussions should focus on identifying the following attributes of the information system to provide an understanding of the overall security profile of the system:

• Logical Architecture – a system and component level view of the logical architecture of the information system. This should include the security domains where system components are located, the system interfaces and information flows (i.e., where and how data is stored, transmitted and processed).
• System Components – the hardware and software components that the information system is comprised of. This should include all direct and indirect components including servers, switches, firewalls, operating systems, applications, and databases.

2 Risk Identification

The risk identification phase seeks to create a comprehensive list of events that may prevent, degrade or delay the achievement of the business’s objectives. Comprehensive identification is critical because a risk that is not identified at this stage will not be included in the risk analysis phase. Although there are numerous tools and techniques that can be used to facilitate the identification and analysis of risks it is recommended that a multidisciplinary workshop discussion be used. The workshop should include the business and service owners (or their nominated delegates) and subject matter experts from both the business and ICT. In order to manage risk, the potential threats to the information systems need to be identified. This is achieved by defining risk scenarios. Risk scenarios are methods of determining if any risks exist that could adversely affect the confidentiality, integrity, or availability of the information system and therefore affect the business objectives. They generally consist of a threat exploiting a vulnerability resulting in an undesirable outcome.  This approach can ensure that all the possible threats to the information system are considered, whilst ensuring that only those that are applicable are actually assessed.
The following provides an overview of the techniques that should be used to ensure that comprehensive lists of relevant risk are identified:

• People with appropriate knowledge should be involved in the identification of risks. Discussions must include the business owner and subject matter experts who can provide relevant and up-to-date information during the process; and
• Group discussions and workshops to facilitate the identification and discussion of the risks that may affect the businesses objectives.

When identifying risk, it is important to clearly describe it so that it can be assessed and evaluated. For example, assessing the likelihood and impact of a risk stated as: “Fraud may occur” is difficult if not impossible. However, assessing the same risk stated as: “An employee commits fraud resulting in financial loss and reputation damage as fraud detection processes are not robust” is more straightforward. Therefore the description of risks identified should use the following structure (or a variation of it, providing that the three elements are included):

(Uncertain event) occurs, leading to (effect on objectives), as a result of (definite cause).

For example:

• A hacker gains unauthorized access to information stored in the system by performing a brute force password guessing attack. They use the information to commit identity fraud that leads to an investigation by the Privacy Commissioner, and reputation damage to the Organization. The attack is successful because the system does not enforce strong passwords or account lockout policies and does not log failed login attempts.
• The loss of a laptop leads to official information being disclosed to an unauthorized party, and reputation damage as disk encryption has not been enabled on all laptop devices.

Once the risk description has been defined and documented consideration should be given to the risk drivers. Capturing the risk drivers is useful when identifying and selecting controls to manage the risk. The business and technical context normally inform the risk drivers, for example, a risk may only exist because the information system is Internet-facing. It is important to also note that there may be multiple risk drivers related to risk.

Although the risk statement captures the consequences (i.e., the effect on objectives) of the risk eventuating it is useful to document them separately as well. The consequences should be stated in business not technical terms. For example:

• Reputation damage to the Organization;
• IN CONFIDENCE information is disclosed to an unauthorized party;
• Breach of the IT Act 2000;
• Service delivery is impacted due to a loss of productivity;
• Loss of confidence in the service by key stakeholders.

3. Risk Analysis

Once the relevant risks have been identified the likelihood and impact of them eventuating must be assessed and rated. Typically the likelihood and impact of a risk eventuating are rated using a qualitative scale.

1. Impact Assessment
   Assess the impact of the risk eventuating with no controls in place. This will inform the gross risk rating and enable the effectiveness of any current controls that reduce the impact of a risk event that occurs to be assessed. Although there may be multiple impact statements documented for risk, only one impact rating can be assigned to the risk. As a result, the highest-rated impact statement should be used to determine the impact rating of the risk.
2. Likelihood Assessment
   Assess the likelihood of the risk eventuating with no controls in place. This will inform the gross risk rating and enable the effectiveness of any current controls that reduce the likelihood of a risk event occurring to be assessed. Where historic information is available about the frequency of an incident’s occurrence it should be used to help determine the likelihood of the risk eventuating. However, it must be noted that the absence of such information does not necessarily mean that the likelihood of the risk eventuating is low. It may merely indicate that there are no controls in place to detect that it has occurred.
3. Risk Rating 
   The risk rating is evaluated using a risk matrix. The risk rating without any controls in place have been assessed is called the gross risk. Typically risks that are assessed as being 1 to 3 on the rating scale without any controls in place are considered acceptable to the business and may not require the implementation of any controls to manage them. However, because the risk is rarely static they should be added to the agency’s risk register so that they can be monitored and re-assessed on a regular basis to ensure that the likelihood and/or impact do not change.

Controls Identification and Assessment
Regardless of whether the risk assessment is being performed for an information system that is in production or as part of the development life cycle process for a new information system, there will already be controls in place to reduce the likelihood and/or impact of some of the risks that have been identified. A control can reduce the risk by reducing the likelihood of an event, the impact, or both. Assessing the effect that the control has on the overall risk leads to determining the residual risk rating. The figure below can be used to identify the effect each type of control has on the likelihood or impact of a risk. Typically deterrent and preventive controls reduce the likelihood of a risk eventuating whereas detective and corrective controls reduce the impact should it eventuate.

The following provides a brief description and some example for each type of control

• Deterrent Controls – are intended to discourage a potential attacker. For example, establishing an information security policy, a warning message on the login screen, a lock or security cameras.
• Preventive Controls – are intended to minimize the likelihood of an incident occurring. For example, a user account management process, restricting server room access to authorized personnel, configuring appropriate rules on a firewall or implementing an access control list on a file share.
• Detective Controls – are intended to identify when an incident has occurred. For example, review of server or firewall security logs or Intrusion Detection System (IDS) alerts.
• Corrective Controls – are intended to fix information system components after an incident has occurred. For example, data backups, SQL transaction log shipping or business continuity and disaster recovery plans.

It is recommended that a multidisciplinary workshop be used to identify and assess the controls that are currently in place to reduce the likelihood and/or impact of the risks eventuating. The business owner and subject matter experts who can identify and describe the current controls that are in place to manage the identified risks must be involved in assessing their efficacy. Where information is available that provides evidence about the effectiveness of the current controls it should be considered during the controls assessment phase.
During the risk assessment, a control may be identified as being ineffective, not sufficient or simply not relevant to the risk it is supposed to be mitigating. If this is the case, an analysis should be performed to determine whether it should be removed and replaced by another more suitable control or whether it should remain in place and be supplemented with additional controls. The residual risk rating is derived by assessing the effect that the current controls have on the gross risk and using the risk matrix.

4. Risk Evaluation

Once the risk analysis has been completed the residual risks can be evaluated against the risk tolerance levels. Risk evaluation seeks to assist the business owner in making decisions on which risks requirements treatment, and the priority for implementing a risk response. Residual risks that are assessed as being low on the rating scale are generally considered to present an acceptable level of risk to the business and do not require any further evaluation. However, because the risk is rarely static they should be added to the risk register so that they can be monitored and assessed on a regular basis to ensure that the likelihood and/or impact do not change.
All residual risks that are evaluated as being between medium or higher on the rating scale need to be evaluated and prioritized. Typically the higher the risk rating is the higher its priority. However, there may be two or more risks with the same risk rating. If it is not clear which risks have a higher priority the information protection priorities defined by the business owner when establishing the business context for the system should be used to determine the priority for the implementation of additional controls.

Statement of Applicability

Having conducted the risk assessment and taken decisions regarding the treatment of those assessed risks, the results need to be documented. This produces two documents:

• Statement of Applicability, and
• Risk Treatment Plan.

The first lists all the controls listed in Annex A of ISO 27001 and documents whether or not they have been applied within the ISMS, and also identifies additional controls that have been applied. The second maps the selected treatments (and the measures by which they are to be implemented) to the specific risks they are intended to address and is, in effect, a control implementation plan. The Statement of Applicability forms the main link between your risk assessment and the information security you have implemented. The purpose of the Statement of Applicability is to document which controls (security measures) from ISO 27001 Annex A (and thereby the ISO 27002 standard for information security) you will implement, the reason they have been chosen – and for those that have not been chosen – the justification for their exclusion. While the standard does not directly specify this, it has become good practice to also include the following in the Statement of Applicability document:

• The status of implementation for existing controls
• A link to the control documentation or a brief description of how each control is implemented
• A cross-reference to the sources of other requirements, necessitating the controls chosen

Thus, by preparing a good quality Statement of Applicability, you will have a thorough and full overview of which controls you need to implement, why they are implemented, how they are implemented, and how well they are implemented. The two primary sources for the Statement of Applicability are the risk assessment and Annex A of the standard (in reality the Table of Contents of the ISO 27002 standard). Other sources are the controls that currently exist in the organization and external security requirements that the organization has to comply with.

Drafting the Statement of Applicability

As the controls are selected, the Statement of Applicability (SOA) can start being drawn up. This SoA is documentation of the decisions reached on each control in light of the risk assessment and is also an explanation or justification of why any controls that are listed in Annex A have not been selected. This exercise, of reviewing the list of controls and documenting the reasons numbering as in Annex A of the Standard and this statement explains which controls have been adopted, and identifies those which have not been adopted, and sets out the reasons for these decisions. able to coordinate the implementation of the complete range of information security controls. A separate forum for information security coordination has not been created as it is considered more effective for this to be handled through the management
The Statement of Applicability will also list those additional controls that the organization has determined, following its risk assessment, are necessary to counter specifically identified risks. These controls should be listed, either within those control sections whose objectives are supported by the additional controls, or within additional control sections added after those contained in lSO 27001 Appendix A. These additional controls should adopt the Appendix A numbering scheme. it would also be worth documenting how the additional controls were selected.

Road to Statement of Applicability

1. Identify and Analyse Risks

To ensure that the controls that are implemented reflect the risks that the organization faces, a risk analysis must be undertaken. The risk analysis starts with an identification of the risks. The identification consists of the following activities

1. Identify the risks associated with the loss of:
   • Confidentiality
   • Integrity
   • Availability
2. Identify the risk owners. Secondly, the risks must be analyzed and evaluated. The analysis consists of the following activities:
3. Assess the potential consequences that would result if the risks identified were to materialize
4.  Assess the realistic likelihood of the occurrence of the risks identified
5. Determine the levels of risk
6. Compare the analyzed risks with the organization’s risk acceptance criteria and establish priorities for treatment

Select Controls

Where the analysis has determined that the risks are not acceptable, proper action must be taken. The risk treatment options typically are:

1. Applying appropriate controls
2. Knowingly and objectively accepting risks
3. Avoiding risks, or
4. Sharing the associated business risks with other parties, e.g. insurers or suppliers

For those risks where the option a) above is chosen, proper controls must be selected. Fortunately, ISO 27002 provides us with a very good catalog of controls for the treatment of risks as well as good guidance on how to implement the controls. In addition to the risk analysis, numerous other sources may come into play when you select controls. Other sources may be:

• Industry-specific regulatory requirements
• Contractual security requirements
• Corporate or Group security requirements which a subsidiary must adhere to

It is recommended that if the organization wishes to adhere to ISO 27001, the Statement of Applicability is organized according to ISO 27002 and that the various other security requirements are then mapped into the ISO 27002 framework. The Statement of Applicability should for each chosen control document:

1. The source of the requirement which has led to the selection of the control
2. The maturity or level of compliance of the control
3. A reference to where in the source the need for this control is stated OR The reason that the control has not been selected
4. A short description of the control or a reference to where the control is described

Analyze Gaps

While this is not a strict requirement of the ISO 27001 standard, it is recommended that once the required controls have been selected, a gap analysis is performed to establish the current state of the implementation of the controls. To ensure the evaluation of the controls is consistent and coherent

1. Writing the Statement of Applicability

After having selected the controls and performed a gap analysis on the selected controls, we now have all the information needed to write the Statement of Applicability itself. It is recommended that a structured tool is used to document the Statement of Applicability. That way, it will be possible to work with the content of the Statement of Applicability and, for instance, sort and filter based on compliance level, the source for requirements, and other parameters. Examples of relevant tools to write the Statement of Applicability are spreadsheets, databases, etc. It should be noted, that the Statement of Applicability must not be a one-off exercise, but must be updated when there are changes to the controls, to the compliance level, or to the requirements that necessitate the controls.

2. Plan Risk Treatment

As noted in the introduction, the Statement of Applicability is a very central document in the information security management system. After the initial version of the Statement of Applicability has been developed, it will be used both when developing the risk treatment plan and when implementing the controls that have been selected during the ‘Select Controls’ activity. The risk treatment plan could be said to be the organization’s security implementation plan, and the primary goal of the plan is to achieve the organization’s security goals.
When planning the implementation the following factors should be considered:

1. What will be done?
2. What resources will be required?
3. Who will be responsible?
4. When will it be completed?
5. How will the results be evaluated?

Another important factor to consider when planning the security implementation is the importance of the controls that are being implemented, so the security activities must be prioritized according to:

• The consequences associated with the risks
• The likelihood of the risks
• Legal and other regulatory requirements

3. Implement Controls

Once the risk treatment planning has been done, the actual security work starts. Depending on how wide the gap is between the actual and the necessary security levels, this might be both a work-intensive and time-consuming task. Therefore it is not unusual to see risk treatment plans that stretch several months or even years. During the implementation of the controls, the maturity of the ISMS is improved, and therefore the Statement of Applicability must be updated according to this progress.

4. Maintaining the Statement of Applicability

As noted above, the Statement of Applicability must be continually updated, and previous major updates should be kept so that the improvements in control implementation and compliance can be documented. Also, as the organization’s risk management approach matures, it is likely that recurring risk assessments may result in updates to the overall risk picture and therefore also to the Statement of Applicability. An updated Statement of Applicability is very useful to document the overall implementation level of the ISMS as well as the effectiveness of the controls that have been implemented.

Risk Treatment

According to its definition, Risk Treatment is the process of selecting and implementing measures to modify risk. The purpose of assessing risk is to assist management in determining where to direct resources. There are four basic strategies for managing risk: mitigation, transference, acceptance, and avoidance.  For each risk in the risk assessment report, a risk management strategy must be devised that reduces the risk to an acceptable level for an acceptable cost. For each risk management strategy, the cost associated with the strategy and the basic steps for achieving the strategy must also be determined.

1.Mitigation
Mitigation is the most commonly considered risk management strategy. Mitigation involves fixing the flaw or providing some type of compensatory control to reduce the likelihood or impact associated with the flaw. Common mitigation for a technical security flaw is to install a patch provided by the vendor. Sometimes the process of determining mitigation strategies is called control analysis.

2. Transference
Transference is the process of allowing another party to accept the risk on your behalf. This is not widely done for IT systems, but everyone does it all the time in their personal lives. Car, health, and life insurance are all ways to transfer risk. In these cases, the risk is transferred from the individual to a pool of insurance holders, including the insurance company. Note that this does not decrease the likelihood or fix any flaws, but it does reduce the overall impact (primarily financial) on the organization.

3.Acceptance
Acceptance is the practice of simply allowing the system to operate with a known risk. Many low risks are simply accepted. Risks that have an extremely high cost to mitigate are also often accepted. Beware of high risks being accepted by management. Ensure that this strategy is in writing and accepted by the manager(s) making the decision. Often risks are accepted that should not have been accepted, and then when the penetration occurs, the IT security personnel are held responsible. Typically, business managers, not IT security personnel, are the ones authorized to accept risk on behalf of an organization.
The measures (i.e. security measurements) can be selected out of sets of security measurements that are used within the Information Security Management System (ISMS) of the organization. At this level, security measurements are verbal descriptions of various security functions that are implemented technically (e.g. Software or Hardware components) or organizationally (e.g. established procedures).

4. Avoidance
Avoidance is the practice of removing the vulnerable aspect of the system or even the system itself. For instance, during a risk assessment, a website was uncovered that let vendors view their invoices, using a vendor ID embedded in the HTML file name as the identification and no authentication or authorization per vendor. When notified about the web pages and the risk to the organization, management decided to remove the web pages and provide vendor invoices via another mechanism. In this case, the risk was avoided by removing the vulnerable web pages

Steps for Risk Treatment

1. Identification of Options

Having identified and evaluated the risks, the next step involves the identification of alternative appropriate actions for managing these risks, the evaluation, and assessment of their results or impact, and the specification and implementation of treatment plans. Since identified risks may have varying impacts on the organization, not all risks carry the prospect of loss or damage. Opportunities may also arise from the risk identification process, as types of risk with positive impact or outcomes are identified. Management or treatment options for risks expected to have positive outcome include:

• starting or continuing an activity likely to create or maintain this positive outcome;
• modifying the likelihood of the risk, to increase possible beneficial outcomes;
• trying to manipulate possible consequences, to increase the expected gains;
• sharing the risk with other parties that may contribute by providing additional resources which could increase the likelihood of the opportunity or the expected gains;
• retaining the residual risk.

Management options for risks having negative outcomes look similar to those for risks with positive ones, although their interpretation and implications are completely different. Such options or alternatives might be:

• to avoid the risk by deciding to stop, postpone, cancel, divert or continue with an activity that may be the cause for that risk;
• to modify the likelihood of the risk trying to reduce or eliminate the likelihood of the negative outcomes;
• to try modifying the consequences in a way that will reduce losses;
• to share the risk with other parties facing the same risk (insurance arrangements and organizational structures such as partnerships and joint ventures can be used to spread responsibility and liability); (of course one should always keep in mind that if a risk is shared in whole or in part, the organization is acquiring a new risk, i.e. the risk that the organization to which the initial risk has been transferred may not manage this risk effectively.)
• to retain the risk or its residual risks;
  In general, the cost of managing risk needs to be compared with the benefits obtained or expected. During this process of cost-benefit judgments, the Risk Management context established in the first process (i.e. Definition of Scope and Framework) should be taken into consideration. It is important to consider all direct and indirect costs and benefits whether tangible or intangible and measured in financial or other terms.

More than one option can be considered and adopted either separately or in combination. An example is the effective use of support contracts and specific risk treatments followed by appropriate insurance and other means of risk financing. In the event that available resources (e.g. the budget) for risk treatment are not sufficient, the Risk Management action plan should set the necessary priorities and clearly identify the order in which individual risk treatment actions should be implemented.

2. Development of Action Plan

Treatment plans are necessary in order to describe how the chosen options will be implemented. The treatment plans should be comprehensive and should provide all necessary information about:

• proposed actions, priorities or time plans,
• resource requirements,
• roles and responsibilities of all parties involved in the proposed actions,
• performance measures,
• reporting and monitoring requirements.

Action plans should be in line with the values and perceptions of all types of stakeholders (e.g. internal organizational units, outsourcing partner, customers, etc.). The better the plans are communicated to the various stakeholders, the easier it will be to obtain the approval of the proposed plans and a commitment to their implementation.

3. Approval of Action Plan

As with all relevant management processes, initial approval is not sufficient to ensure the effective implementation of the process. Top management support is critical throughout the entire life-cycle of the process. For this reason, it is the responsibility of the Risk Management Process Owner to keep the organization’s executive management continuously and properly informed and updated, through comprehensive and regular reporting

4. Implementation of Action Plan

The Risk Management Plan should define how Risk Management is to be conducted throughout the organization. It must be developed in a way that will ensure that Risk Management is embedded in all the organization’s important practices and business processes so that it will become relevant, effective, and efficient.
More specifically, Risk Management should be embedded in the policy development process, in business and strategic planning, and in change management processes. It is also likely to be embedded in other plans and processes such as those for asset management, audit, business continuity, environmental management, fraud control, human resources, investment, and project management. The Risk Management plan may include specific sections for particular functions, areas, projects, activities, or processes. These sections may be separate plans but in all cases, they should be consistent with the organization’s Risk Management strategy (which includes specific RM policies per risk area or risk category). The necessary awareness of and commitment to Risk Management at senior management levels throughout the organization is mission-critical and should receive close attention by:

• obtaining the active ongoing support of the organization’s directors and senior executives for Risk Management and for the development and implementation of the Risk Management policy and plan;
• appointing a senior manager to lead and sponsor the initiatives;
• obtaining the involvement of all senior managers in the execution of the Risk Management plan.

The organization’s board should define, document, and approve its policy for managing risk, including objectives and a statement of commitment to Risk Management. The policy may include:

• the objectives and rationale for managing risk;
• the links between the policy and the organization’s strategic plans;
• the extent and types of risk the organization will take and the ways it will balance threats and opportunities;
• the processes to be used to manage risk;
• accountabilities for managing particular risks;
• details of the support and expertise available to assist those involved in managing risks;
• a statement on how Risk Management performance will be measured and reported;
• a commitment to the periodic review of the Risk Management system;
• a statement of commitment to the policy by directors and the organization’s executive.

Publishing and communicating a policy statement of this type demonstrate to the organization’s internal and external environment the commitment of the executive board to Risk Management and clearly specifies roles and accountability on a personal level. The directors and senior executives must be ultimately responsible for managing risk in the organization. All personnel is responsible for managing risks in their areas of control. This may be facilitated by:

• specifying those accountable for the management of particular risks, for implementing treatment strategies and for the maintenance of  controls;
• establishing performance measurement and reporting processes;
• ensuring appropriate levels of recognition, reward, approval, and sanction.

As it becomes apparent, the actual implementation of security measurements for the underlying IT platform is not part of this activity. Rather, the implementation of action plans is concerned with the actions to be performed to reduce the identified risks. The work necessary at the level of the technical implementation of security measures is conducted within the ISMS, that is, outside the Risk Management process. Last but not least, an important responsibility of the top management is to identify requirements and allocate necessary resources for Risk Management. This should include people and skills, processes and procedures, information systems and databases, money, and other resources for specific risk treatment activities. The Risk Management plan should also specify how the Risk Management skills of managers and staff will be developed and maintained.

5. Identification of Residual Risks

Residual risk is a risk that remains after Risk Management options have been identified and action plans have been implemented. It also includes all initially unidentified risks as well as all risks previously identified and evaluated but not designated for treatment at that time.
As highlighted in the Controls Identification and Assessment section there are different types of controls that can be implemented to reduce the identified risks to an acceptable level. It is important to ensure that any recommended control will reduce the residual risk. For example, if a risk has a residual risk rating of 15 (i.e., a likelihood of Almost Never and an impact of Severe) recommending a control that reduces the likelihood of the risk eventuating will not reduce the residual risk. However, recommending a control (or a combination of controls) to reduce the impact of the risk eventuating will.

Examples of recommended controls to reduce residual risks to an acceptable level are:

• Implement appropriate access control lists on shares, folders, and files to ensure only authorized personnel can access information stored within the folders.
• Review the patch management process to ensure that it includes all operating systems, applications and firmware. Ensure monthly maintenance windows are defined and agreed with the business to ensure that patches are implemented regularly and in a timely manner.
• Implement additional servers and load balancing hardware to ensure that the service scales to meet the businesses requirements and that it meets the availability requirements in the event of a server failure.
• Implement an operational procedure to test the restoration of data from the backup media to ensure that critical data can be restored.

It is important for the organization’s management and all other decision-makers to be well informed about the nature and extent of the residual risk. For this purpose, residual risks should always be documented and subjected to regular monitor-and-review procedures.

Communicating Risks and Risk Management Strategies

Risk must also be communicated. Once risk is understood, risks and risk management strategies must be clearly communicated to organizational management in terms easily understandable to organizational management. Managers are used to managing risk, they do it every day. So presenting risk in a way that they will understand is key. Ensure you do not try to use “fear, uncertainty, and doubt.” Instead, present risk in terms of likelihood and impact. The more concrete the terms are, the more likely organizational management will understand and accept the findings and recommendations. There must be a two-way dialogue between the stakeholders with a focus on consultation rather than a one-way information flow. Effective communication between stakeholders is essential to ensure that risks are understood and decisions about risk response selection are appropriate. The perception of risk can vary significantly. Stakeholders are likely to make judgments on the acceptability of the risk-based on their own experience of it, therefore it is important to ensure that their perceptions of the risk, as well as their perceptions of the benefits, are identified and documented and the underlying reasons for their position are clearly understood and addressed. Information about risk may be distributed to a large number of different stakeholders within the agency. To be effective, all information relating to the management of risks should be:

• Clear and Concise – ensure that the information can be understood by all recipients and does not overwhelm them with extraneous detail;
• Useful – any communication related to risk must be relevant. Technical information that is too detailed or sent non-technical recipients will likely impede, rather than enable, a clear view of risk;
• Timely – timely communications enable decisions and actions to be taken at the appropriate time in the risk management process;
• Targeted – information must be communicated at the right level of aggregation and adapted for the audience to enable informed decisions to be made. However, the aggregation of the information must not hide the root cause of a risk;
• Controlled – information related to risks should be made available on a need-to-know basis.

Only parties with a genuine need should have access to risk reports, risk management plans, and the risk register. With a quantitative risk assessment methodology, risk management decisions are typically based on comparing the costs of the risk against the costs of risk management strategy. A return on investment (ROI) analysis is a powerful tool to include in the risk assessment report. This is a tool commonly used in business to justify taking or not taking a certain action. Managers are very familiar with using ROI to make decisions. With a qualitative risk assessment methodology, the task is somewhat more difficult. While the cost of the strategies is usually well known, the cost of not implementing the strategies is not, which is why a qualitative and not a quantitative risk assessment was performed. Including a management-friendly description of the impact and likelihood of each risk and risk management strategy is extremely effective. Another effective strategy is showing the residual risk that would be effective after the risk management strategy was enacted.

6.2 Information security objectives and planning to achieve them

The organization must establish information security objectives at relevant functions and levels. The information security objectives must be consistent with the information security policy. If practicable it must be measurable. It must take into account applicable information security requirements, and results from risk assessment and risk treatment. It must be monitored, communicated and updated as appropriate.  The organization must retain documented information on the information security objectives and must be made available as a doucmented information.
When planning how to achieve the quality objectives, the organization must determine what will be done; what resources will be required; who will be responsible; when it will be completed; how the results will be evaluated.

Set Objectives

Sect. 6.2 of the standard essentially boils down to the question; ‘How do you know if your information security management system is working well?’ To do this you need to arrive at a set of objectives keeping in mind the clause. 4.1, 4.2, 4.3, and 6.1 and determine how you will evaluate and measure performance against each of those objectives. Consider the objectives you want to achieve as an organization in relation to information security. Some examples could be

• “Delivery of a secure, reliable cloud service for users and other interested parties who need confidence and assurance the platform is fit for their purpose of sharing and working with sensitive information.”
• “Provide a pragmatic digital paperless ISMS for staff (and other interested parties who need to access it), integrated into their day-to-day work practices to ensure it becomes a habit for good performance, not an inhibitor to getting their work done.”

How can you write measurable objectives?

Plans by their nature are largely concerned with change or an effort to maintain valued aspects of the current situation. The extensive process of information collection and analysis, consultation, validation, and priority setting is used to identify where you think the effort needs to be focused. When it comes to writing these into objectives, there should be a clear logic between objectives and the goal they are pursuing. Objective statements will follow a general form: ‘To do what, for whom, by when?’. Careful selection of the language used to express objectives can provide a clearer intention of what will be done and what you hope to achieve. Strong, clear verbs describe the ‘do’ component and are the key to setting the tone and commitment of the objective. The list of verbs below provides some examples of words that are action-oriented applied to common interventions.
Caution is recommended against the over-use of words such as ‘develop’, ‘facilitate’ or ‘support’. These are less descriptive and can dull the tone of a plan if over-used. However, they should not be replaced with inferior, vaguer words or at the other extreme, technical terms or jargon. Avoid words like ‘enhance’, ‘commit’, which are not specific and hence more difficult to measure. Also, avoid multiple verb use for objectives: For example:
Not: ‘To explore opportunities to increase access to…’
Try: ‘To increase access to …’
In this case, ‘exploring opportunities’ is probably a step towards ‘increasing accesses. However, you don’t need to include the steps you will take to achieve your objective in the objective statement. If it warrants it, this will be described at the strategy level (which, as stated above, are the actions taken to reach these objectives). Words like ‘explore’, ‘discuss’, ‘commence’, seek, and ‘encourage’ are often used in this way and should be avoided. If these words cannot be eliminated in favor of a more direct word, the likelihood is that you are describing a strategy, not an objective, or you are not clear enough in your own mind about what you propose to do.

How can you keep your objectives consistent?
One of the challenges of plan writing is creating a consistent relationship between plan statements so that they are pitched at a consistent level. It is confusing if an objective in one part of a document is a broad statement while in another it is quite specific (more like a strategy). One way of checking whether your objectives are pitched at the right level is to ask ‘why?’ The answer will test the theory behind your objective and should lead you to a health and wellbeing goal – whether stated or implied. If the goal is more than one step away from the statement, the likelihood is that is pitched at a strategic level. The verbs used might not provide any clues to the appropriate level. Words like ‘increase’ and ‘decrease’ are also likely to be used at the goal level and a strategic level. However, at a goal level ‘increase’ is likely to be applied to the quality of life and ‘decrease’ to the incidence of illness or disease. At a strategy level, both are likely to be applied to features of service systems or standards. Other words might fit an objective or strategy level; however, some will suggest that the statement is better included as a strategic level.

How can I check my objectives?
A good way to test your objectives is to use the SMART technique. SMART statements have the following characteristics.
S- specific: it indicates clear action on a determinant, population group, and setting.
M- measurable: it includes features that will help you tell whether it has succeeded.
A- attainable: it can be realistically achieved on time and within available resources.
R- relevant: it is a logical way to achieve your goals.
T- time-framed: it indicates a timeframe for action.

Determine the metrics system

Once you have those objectives, consider the key things that should and shouldn’t be happening if you were to meet each one of them and how you would go about measuring those things. For example, a key measure of success could be the availability of systems for customers to use. So you can have an uptime objective of 99.5% (or SLA with customers) as one of the measures we track each month using our uptime monitoring systems. When you are thinking about what to measure have in mind the three key principles that run through ISO27001 of Confidentiality, Availability, and Integrity. So, for example, some of the things we looked at to measure ourselves against were;

• System uptime with a target of 99.5% (availability)
• Any failures in our backups with a target of none (integrity)
• Number of corrective actions with a target of none (all)

The philosophy of ISO 27001 is the PDCA management cycle (Plan-Do-Check-Act). The concept of measurement is also best explained through this PDCA cycle:

• In the Plan phase, you need to set the objectives
• In the Do phase, you must figure out how to measure up to which point your objectives are achieved
• In the Check phase you need to start the actual measurement, and finally
• In the Act phase, once you realized you haven’t achieved your objectives (which is very often the case), you need to make certain improvements

So how can you measure backup or firewall? The secret lies in setting objectives which are easy to measure – you might have heard of the S.M.A.R.T. concept: objectives need to be Specific, Measurable, Achievable, Relevant, and Time-based.

• So, what would it look like for the firewall? Something like ‘We want our firewall to stop 100% of unwanted network traffic’. Is it measurable? Yes – you will find out, sooner or later, whether some unwanted traffic has passed through the firewall.
• Another example – backup. The objective could be ‘We want to achieve our loss of data is a maximum of 6 hours.’ Measurable? Yes – and you don’t have to wait for data loss to happen, you can test your backup and see how much of the data you can restore.
• An example of the objective for the whole ISMS could be ‘We want to decrease the number of information security incidents by 50% in the next year’. Again, pretty specific and therefore measurable.

Setting the objectives and measuring them is a rather new and unexplored aspect of information security. It is very often considered as an overhead because of the lack of knowledge in the first place, not so much because of practical reasons.

Here is the example of the Information Security objectives

S. No.	Parameter	Objective	Periodicity	Responsible Team
1	Average Minor  Non-conformities per AUDIT Cycle (per department)	<=5	Every 6 months (Post Audit)	ISMS
2	Impact on assets/human resources  due to  Fire Accidents	=100% compliance	Every 6 months	ISMS
3	Internet Downtime (on Working days in working hours)	>=99% availability	Every 6 months	IT Team
6	Infected file status (new + still infected) count because of virus and spyware	<=3	Every 6 months	IT Team
5	Overall High priority Incidence Occurrence Rate Admin +Facilities IT HR(should include incidents related to POSH) Customer Delivery/Project	<=5 <=5 <=5 <=5	Every 6 months (Pre-audit)	ISMS
6	Customer Satisfaction on Internal infrastructure	>=90%	Every 6 months (Pre- Audit)	Support/ Delivery/ IT
7	License Issues	=100% compliance	Every 6 months	IT
8	IP/Legal issues	=100%  compliance	Every 6 months	Management/ Directors
9	Repetition of Audit Findings in next Internal Audit	<=2	Every 6 months (Post Audit)	ISMS
10	Count of residual risks	<=10	Every 6 months (Pre-audit)	ISMS
11	Full back up failures	<=2 times	Every 6 months	IT Team
12	Downtime due to power failure (during working hours)	<=6 hours	Every 6 months	Admin team
13	Number of employees relieved/ terminated without execution of HR Exit checklist	=100% compliance	Every 6 months	HR team
14	Security testing for all projects	=100% compliance	Every 6 months	Delivery team

Information security key performance indicators

A key performance indicator (KPI) is a metric used to evaluate factors that are crucial to the success of an organization. It differs from an objective in that an objective is something you want to achieve, while a KPI is something used to verify if your efforts are leading you toward the defined objective. For example, if 60 mph is the speed objective, the speedometer helps you to achieve and maintain this speed. In a scenario where decision-makers are surrounded by information and have limited resources to work on objectives, to define those most relevant (the KPIs) and how and when they should be presented is a good way to help monitor results and make proper decisions. Besides the verification, if one is on course to achieve the proposed objectives, KPIs may be used to support ISO 27001 by helping to communicate the importance of information security management and objectives. Though there are many criteria you can use for KPI selection, some aspects are common to them, and they can make your task easier:

• Business relevant: the indicator should be aligned to clear business objectives or legal requirements, which makes it easier for people to understand why it should be measured and evaluated. ISO 27001 has some requirements that may be attended by the use of indicators related to effectiveness and compliance, but an organization should consider efficiency indicators, too; for example, the Return On Security Investment (ROSI) can show how well the resources are Used to support security planning.
• Process integrated: activities to collect the necessary data for a KPI should add the least amount of work possible, compared to the usual activities required to deliver the product/service, and the information (e.g., marking a step as completed or recording the time to perform an activity) needed should be in the same forms already used by the process.
• Assertive: the indicator should be capable of pinpointing relevant issues (e.g., process steps, organizational areas, resources, etc.) that need attention. For example, a KPI related to the number of failed login attempts explicitly limits the scope to the login process.

Examples of performance indicators

The following examples cover a complete PDCA (Plan-Do-Check-Act) sequence, showing how different indicators can be used to get a full view of the performance of the processes related to information security management.

1. Plan
Percent of business initiatives supported by the ISMS: indicator that shows the ISMS’s level of alignment and integration with the business. The higher the value, the more optimized the ISMS resources, since management resources are being used over more aspects of the organization. You can use the ISMS Scope Document, compared to all services/processes of the organization, to obtain this information.

• Percent of information security initiatives containing cost/benefit estimates: an indicator that shows the organization’s maturity on risk treatment. The higher the value, the more the risk treatment decisions are based on facts. You can use the Risk Assessment and Treatment Report and the Risk Treatment Plan, compared to all security initiatives implemented, to obtain this information.
• Percent of agreements with information security clauses: indicator that shows how services and products, provided by you or supplied to you, are legally supported considering information security aspects (e.g., availability, confidentiality, integrity, and continuity). The higher the value, the better supported your relationships with clients and suppliers are. You can use Non-Disclosure Agreements and SLAs with information security clauses, compared to all agreements related to services and products, to obtain this information.

2. Do
The number of security-related service downtimes: downtimes related to information security issues directly reflect the effectiveness of the ISMS. This information can be obtained from operational reports. Duration of service interruptions: as important as the number of downtimes, the average duration of downtimes is an important measurement of ISMS effectiveness. This information can be obtained from operational reports. Incident resolution time: another important measurement of ISMS effectiveness, this information can be obtained from operational reports.

3. Check
Percent of controls assessment performed: an indicator that gives you a view of how many security measures are being reviewed. The higher the value, the more controls are being analyzed in terms of effectiveness, efficiency, and opportunities for improvement. You can use the Risk Treatment Plan, compared to Training Plans, Incident Logs, Audit Reports, and Management Review Minutes, to obtain this information.

4. Act
The number of improvement initiatives: an indicator that shows the proactivity of an organization’s ISMS with respect to changes in the environment and the opportunities identified. Changes with the objective to improve results or prevent losses, instead of correct errors or problems, are good examples that reflect a high value on his KPI. You can use the Audit Reports and Management Review Minutes to obtain this information.

Proper monitoring to improve results and avoid problems

Organizations are under constant pressure to achieve results and to do so, it is essential that they can count on proper navigational instruments that can show them if they are on the right course and allow timely adjustments. But, it is also essential that these instruments are well-chosen and calibrated, or else you may find yourself attacking the wrong problems and turning a bad situation into something worse.

Example of Objective and plan

Hacking and Unauthorized Interception

Developing an IS Objectives plan
The purpose of an‟ IS Objectives plan‟ is to set out how an intended action will be achieved, who will undertake it and how it will be measured.
Objectives to be achieved

• Issues to be addressed
  Our current firewalls are old and are insufficient to prevent new threats. “Hacking and Unauthorised Interception‟ – This is the deliberate interception or collection of data or voice traffic on our network. Competitors or thieves seek to gather personal information that enables them to commit fraud. Although we have not detected this happening as yet, it is a real and present concern. The main ways this is done are:
  • External parties gaining access to our IT systems
  • Staff finding ways to access restricted information internally
• Proposed Actions
  Replace our existing external firewalls with Enterprise-grade products that offer state-full inspection capabilities. The design must contain the most advanced firewall capabilities, including:
  • proxies (including SOCKS)
  • stateful inspection or dynamic packet filtering
  • network address translation
  • virtual private networks
  • Internet Protocol version 6 or other non-Internet Protocol versions 4 protocols
  • network and host intrusion detection technologies
• External Firewall deployment steps
  Prepare:  Ensure network diagrams are up to date
  Configure:
  1. Select and acquire firewall hardware and software as above
  2. Acquire firewall documentation, training, and support
  3. Install firewall hardware and software
  4. Configure IP routing
  5. Configure firewall packet filtering
  6. Configure firewall logging and alert mechanism

     Test:

  1. Test the firewall system
  2. Install the firewall system
  3. Phase the firewall system into operation
• Internal Intellectual Property control deployment steps
  Implement internal Intellectual Property Controls based on information signatures.
  Prepare:
  1. Information signatures identification – credit card details, personal information.
  2. Assign approved locations for information types
  3. Approve staff access structure
  4. Select and acquire agents and management application

     Configure:

  1. Implement tracking agents onto PC’s and servers
  2. Acquire firewall documentation, training, and support
  3. Configure physical server
  4. Configure logging and alert mechanisms

     Test: Test the system
     Deploy: Enable the live the IP system

• Accountability
  John Bishop IT Manager is responsible for the approval of this plan. Chris Flood, IT Analyst is responsible for plan implementation.
• Resources and responsibilities
  1. Management will provide a budget (to be set) for the purchase of new Firewalls, the budget is still pending. The objective is on hold.
  2. IT will project manage the process, but a specialist supplier will undertake this work.
• Completion schedule:  Implementation Resource Estimates
  The following rough-order-magnitude timeframes represent the calendar time required by staff/supplier to implement each of the practices described in the “Proposed Actions section‟.
  1. Design the firewall system 3 months
  2. Acquire firewall hardware and software 2 months
  3. Acquire firewall documentation, training, and support 1 month
  4. Install firewall hardware and software 1 month
  5. Configure IP routing 1 week
  6. Configure firewall packet filtering 3 weeks
  7. Configure firewall logging and alert mechanisms 2 weeks
  8. Test the firewall system 2 weeks
  9.  Install the firewall system 1 week
  10.  Phase the firewall/IP system into operation 2-3 months
• Evaluating results
  1. Internal and external penetration testing (undertaken by a third party) will be undertaken to ensure a successful deployment.

6.3 Planning of change

When the organization determines the need for change to the Information security management system (ISMS) the change must be carried out in a planned systematic manner.

The continuity and effectiveness of your ISMS must be substantially maintained in the event of significant changes in your ISMS or organization, e.g., management, information system, ownership, Assets, Security environment, relocation, technology, product, the shift in stakeholders, etc. Changes must be carefully planned so as not to disrupt your organizations’ ongoing capability and responsibility to effectively meet customer and regulatory requirements. In such instances, change control would require:

• careful planning of nature and timeline for the changes.
• determining the impact or outcome of such changes;
• ensuring adequate resources are available to implement the change;
• top management authorization
• change deployment and follow-up
• review of the ISMS by top management after changes are affected.

The ISO 27001:2022 requirements provide a strong basis for a management system for determining and implementing controls for information security risk treatment in an information. Once the organization has identified its context and interested parties and then identified the processes that support this linkage. Once processes are determined, an organization will need to identify the risks associated with these processes. To achieve the benefits associated with the determination of risks, changes may be needed. These changes can be related to any element of the process, such as inputs, resources, persons, activities, controls, measurements, outputs, etc. Changes are intended to be beneficial to the organization and need to be carried out as determined by the organization. In addition, consideration of newly introduced risks needs to be taken into account. There may be changes in ISMS due to Security Incident, feedback form stakeholders, stakeholder’s complaint, Vulnerability Management, Employee feedback, Innovation, determined risk, determined opportunity, Internal audit results, Management review results, Identified nonconformity.

The changes may occur in for example Processes, Technology, Security Incidents, Documented information, Tooling, Equipment, employee training, supplier selection, supplier management, and others. To achieve the benefits associated with changes, the organization should consider all types of changes that may need to occur. The successful management and control of these changes have become a core requirement within the organization’s ISMS. Some changes need to be carefully managed while others can be safely ignored. In order to sort through this, the organization should consider a method to prioritize. To determine the priority, the organization should consider a methodology that allows them to take into account:

• Consequences of the change
• Likelihood of the consequence
• Impact on Information Security
• Impact on interested parties
• Impact on Information Security objectives
• Effectiveness of processes that are part of the ISMS
• Steps to implement changes
• Define the specifics of what is to be changed
• Have a plan (tasks, timeline, responsibilities, authorities, budget, resources, needed information, others)
• Engage other people as appropriate in the change process
• Develop a communication plan (appropriate people within the organization, customers, suppliers, interested parties, etc. may need to be informed)
• Use a cross-functional team review the plan to provide feedback related to the plan and associated risks
• Train people
• Measure the effectiveness
• Prior to making a change, the organization should consider unintended consequences.

After making a change the organization should monitor the change to determine its effectiveness and to identify any additional problems that might be created. Records of some changes may be needed as part of the Information Security Management System

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.