ISO 27001:2022 Information Security Management System

by Pretesh Biswas

Overview of an Information Security Management System

Information security is the protection of information to ensure:

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

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

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

The standards set forth the following practices:

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

These practices form the framework within which you will establish an ISMS.

1 Purchase a copy of the ISO/IEC standards

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

2 Obtain management support

As described in ISO/IEC 27001, management plays an important role in the success of an ISMS.
What you need: Management responsibility section of ISO 27001. Management must make a commitment to the establishment, implementation, operation, monitoring, review, maintenance, and improvement of the ISMS. Commitment must include activities such as ensuring that the proper resources are available to work on the ISMS and that all employees affected by the ISMS have the proper training, awareness, and competency.
Results: Establishment of the following items demonstrates management commitment:

  • An information security policy: this policy can be a standalone document or part of an overall security manual that is used by an organization.
  • Information security objectives and plans: again this information can be a standalone document or part of an overall security manual that is used by an organization
  • Roles and responsibilities for information security: a list of the roles related to information security should be documented either in the organization’s job description documents or as part of the security manual or ISMS description documents.
  • Announcement or communication to the organization about the importance of adhering to the information security policy.
  • Sufficient resources to manage, develop, maintain, and implement the ISMS.

In addition, management will participate in the ISMS Plan-Do-Check-Act [PDCA] process, as described in ISO 27001 by:

  • Determining the acceptable level of risk. Evidence of this activity can be incorporated into the risk assessment documents, which are described later in this guide.
  • Conducting management reviews of the ISMS at planned intervals. Evidence of this activity can be part of the approval process for the documents in the ISMS.
  • Ensuring that personnel affected by the ISMS are provided with training, are competent for the roles and responsibilities they are assigned to fulfill, and are aware of those roles and responsibilities. Evidence of this activity can be through employee training records and employee review documents.

3 Determine the scope of the ISMS

When management has made the appropriate commitments, you can begin to establish your ISMS. In this step, you should determine the extent to which you want the ISMS to apply to your organization.
What you need:
You can use several of the “result” documents that were created as part of step 2, such as:

  • The information security policy
  • The information security objectives and plans
  • The roles and responsibilities that are related to information security and were defined by the management

In addition, you will need:

  • Lists of the areas, locations, assets, and technologies of the organization that will be controlled by the ISMS.
  • What areas of your organization will be covered by the ISMS?
  • What are the characteristics of those areas; its locations, assets, technologies to be included in the ISMS?
  • Will you require your suppliers to abide by your ISMS?
  • Are there dependencies on other organizations? Should they be considered?

Your goals will be to cover the following:

  • the processes used to establish the scope and context of the ISMS.
  • the strategic and organizational context

Important: Keep your scope manageable. Consider including only parts of the organization, such as a logical or physical grouping within the organization. Large organizations might need several Information Security Management Systems in order to maintain manageability. For example, they might have one ISMS for their Finance department and the networks used by that department and a separate ISMS for their Software Development department and systems.
Results: A documented scope for your ISMS.
When you have determined the scope, you will need to document it, usually in a few statements or paragraphs. The documented scope often becomes one of the first sections of your organization’s Security Manual. Or, it might remain a standalone document in a set of ISMS documents that you plan to maintain. Often the scope, the security policy, and the security objectives are combined into one document.

4 Identify applicable legislation

After you have determined the scope, identify any regulatory or legislative standards that apply to the areas you plan to cover with the ISMS. Such standards might come from the industry in which your organization works or from state, local, or federal governments, or international regulatory bodies.
What you need: Up-to-date regulatory or legislative standards that might be applicable to your organization. You might find it helpful to have input and review from lawyers or specialists who are knowledgeable about the standards.
Results: Additional statements in the scope of the ISMS. If your ISMS will incorporate more than two or three legislative or regulatory standards, you might also create a separate document or appendix in the Security Manual that lists all of the applicable standards and details about the standards.

5 Define a method of risk assessment

Risk assessment is the process of identifying risks by analyzing threats to, impacts on, and vulnerabilities of information and information systems and processing facilities, and the likelihood of their occurrence. Choosing a risk assessment method is one of the most important parts of establishing an ISMS. To meet the requirements of ISO 27001, you will need to define and document a method of risk assessment and then use it to assess the risk to your identified information assets, make decisions about which risks are intolerable and therefore need to be mitigated, and manage the residual risks through carefully considered policies, procedures, and controls.
ISO does not specify the risk assessment method you should use; however, it does state that you must use a method that enables you to complete the following tasks:

  • Evaluate risk based on levels of confidentiality, integrity, and availability. Some risk assessment methods provide a matrix that defines levels of confidentiality, integrity, and availability and provides guidance as to when and how those levels should be applied,
  • Set objectives to reduce risk to an acceptable level
  • Determine criteria for accepting the risk
  • Evaluate risk treatment options.

There are many risk assessment methods you can choose from, such as those that are prevalent in your industry. For example, if your company is in the oil industry, you might find there are risk assessment methods related to that industry.

When you have completed this step, you should have a document that explains how your organization will assess risk, including:

  • the organization’s approach to information security risk management
  • criteria for information security risk evaluation and the degree of assurance required

6 Create an inventory of information assets to protect

To identify risks and the levels of risks associated with the information you want to protect, you first need to make a list of all of your information assets that are covered in the scope of the ISMS.
What you will need:
You will need the scope that you defined in step 3 and input from the organization that is defined in your scope regarding its information assets.
Result:
When you have completed this step, you should have a list of the information assets to be protected and an owner for each of those assets. You might also want to identify where the information is located and how critical or difficult it would be to replace. This list should be part of the risk assessment methodology document that you created in the previous step.
Because you will need this list to document your risk assessment, you might want to group the assets into categories and then make a table of all the assets with columns for assessment information and the controls you choose to apply.
The following example shows an asset table.

7 Identify risks

Next, for each asset you defined in the previous step, you will need to identify risks and classify them according to their severity and vulnerability. In addition, you will need to identify the impact that loss of confidentiality, integrity, and availability may have on the assets.
To begin identifying risks, you should start by identifying actual or potential threats and vulnerabilities for each asset. A threat is something that could cause harm. For example, a threat could be any of the following:

  • A declaration of the intent to inflict harm or misery
  • Potential to cause an unwanted incident, which may result in harm to a system or organization and its assets
  • The intentional, accidental, or man-made act that could inflict harm or an act of God (such as a hurricane or tsunami)

A vulnerability is a source or situation with a potential for harm (for example, a broken window is a vulnerability; it might encourage harm, such as a break-in). A risk is a combination of the likelihood and severity or frequency that a specific threat will occur.
What you will need:

  • The list of assets that you defined in the previous step
  • The risk assessment methodology you defined in step 5

For each asset, you should identify vulnerabilities that might exist for that asset and threats that could result from those vulnerabilities. It is often helpful to think about threats and vulnerabilities in pairs, with at least one pair for each asset and possibly multiple pairs for each asset.
Results:
For each asset, you will have a threat and vulnerability description and, using your Risk Assessment methodology, you will assign levels of confidentiality, integrity, and availability to that asset.
If you used a table for step 6, you can add this information to that table, as shown in the following example.

8 Assess the risks

After you have identified the risks and the levels of confidentiality, integrity, and availability, you will need to assign values to the risks. The values will help you determine if the risk is tolerable or not and whether you need to implement a control to either eliminate or reduce the risk. To assign values to risks, you need to consider:

  • The value of the asset being protected
  • The frequency with which the threat or vulnerability might occur
  • The damage that the risk might inflict on the company or its customers or partners

For example, you might assign values of Low, Medium, and High to your risks. To determine which value to assign, you might decide that if the value of an asset is high and the damage from a specified risk is high, the value of the risk should also be high, even though the potential frequency is low. Your Risk Assessment Methodology document should tell you what values to use and might also specify the circumstances under which specific values should be assigned. Also, be sure to refer to your Risk Assessment Methodology document to determine the implication of a certain risk value. For example, to keep your ISMS manageable, your Risk Assessment Methodology might specify that only risks with a value of Medium or High will require control in your ISMS. Based on your business needs and industry standards, risk will be assigned appropriate values.
What you will need:

  • Lists of assets and their associated risks and CIA levels, which you created in the previous step.
  • Possibly input from management as to what level of risk they are willing to accept for specific assets.

Results:
When you have completed your assessment, you will have identified which information assets have intolerable risk and therefore require controls. You should have a document (sometimes referred to as a Risk Assessment Report) that indicates the risk value for each asset. In the next step, you will identify which controls might be applicable for the assets that require control in order to reduce the risk to tolerable levels. This document can either be standalone or it can be part of an overall Risk Assessment document that contains your risk assessment methodology and this risk assessment.

9 Identify applicable objectives and controls

Next, for the risks that you’ve determined to be intolerable, you must take one of the following actions:

  • decide to accept the risk, for example, actions are not possible because they are out of your control (such as natural disaster or political uprising) or are too expensive.
  • transfer the risk, for example, purchase insurance against the risk, subcontract the activity so that the risk is passed on to the subcontractor, etc.
  • reduce the risk to an acceptable level through the use of controls.

To reduce the risk, you should evaluate and identify appropriate controls. These controls might be controls that your organization already has in place or controls that are defined in the ISO 27002  standard.
(Note: An examination of the controls that you already have in place against the standard and then using the results to identify what controls are missing is commonly called a “gap analysis.”)
What you will need:

  • Annex A of ISO 27001. This appendix summarizes controls that you might want to choose from.
  • ISO 27002, which provides greater detail about the controls summarized in ISO 27001.
  • Procedures for existing corporate controls

Results:
You should end up with two documents by completing this step:

  • A Risk Treatment Plan
  • A Statement of Applicability

The Risk Treatment Plan documents the following:

  • the method selected for treating each risk (accept, transfer, reduce)
  • which controls are already in place
  • what additional controls are proposed
  •  the time frame over which the proposed controls are to be implemented

The Statement of Applicability (SOA) documents the control objectives and controls selected from Annex A. The Statement of Applicability is usually a large table in which each control from Annex A of ISO/IEC 27001 is listed with its description and corresponding columns that indicate whether that control was adopted by the organization, the justification for adopting or not adopting the control, and a reference to the location where the organization’s procedure for using that control is documented. The SOA can be part of the Risk Assessment document, but usually, it is a standalone document because it is lengthy and is listed as a required document in the standard.

10 Set up policy, procedures and Documented Information to control risks

For each control that you define, you must have corresponding statements of policy or in some cases a detailed procedure. The procedure and policies are used by affected personnel so they understand their roles and so that the control can be implemented consistently. The documentation of the policy and procedures is a requirement of ISO 27001.
What you will need:
To help you identify which procedures you might need to document, refer to your Statement of Applicability. To help you write your procedures so that they are consistent in content and appearance, you might want to create some type of template for your procedure writers to use.
Results:
Additional policy and documented Information. (The number of documents you produce will depend on the requirements of your organization.) Some of these procedures might also generate records. For example, if you have a procedure that all visitors to your facility must sign a visitors log, the log itself becomes a record providing evidence that the procedure has been followed.

11 Allocate resources and train the staff

Adequate resources (people, time, money) should be allocated to the operation of the ISMS and all security controls. In addition, the staff who must work within the ISMS (maintaining it and its documentation and implementing its controls) must receive appropriate training. The success of the training program should be monitored to ensure that it is effective. Therefore, in addition to the training program, you should also establish a plan for how you will determine the effectiveness of the training.
What you will need:

  • A list of the employees who will work within the ISMS
  • All of the ISMS procedures to use for identifying what type of training is needed and which members of the staff or interested parties will require training
  • Management agreement to the resource allocation and the training plans.

Results:
Specific documentation is not required in the ISO/IEC standards. However, to provide evidence that resource planning and training has taken place, you should have some documentation that shows who has received training and what training they have received. In addition, you might want to include a section for each employee that lists what training they should be given. Also, you will probably have some type of procedure for determining how many people, how much money, and how much time needs to be allocated to the implementation and maintenance of your ISMS. It’s possible that this procedure already exists as part of your business operating procedures or that you will want to add an ISMS section to that existing documentation.

12 Monitor the implementation of the ISMS

To ensure that the ISMS is effective and remains current, suitable, adequate, and effective, ISO 27001 requires:

  • Management to review the ISMS at planned intervals. The review must include assessing opportunities for improvement, and the need for changes to the ISMS, including the security policy and security objectives, with specific attention to previous corrective or preventative actions and their effectiveness.
  • Periodic internal audits. The results of the reviews and audits must be documented and records related to the reviews and audits must be maintained.

What you will need:
To perform management reviews, ISO 27001 requires the following input:

  • results of ISMS internal and external audits and reviews
  • feedback from interested parties
  • techniques, products, or procedures which could be used in the organization to improve the effectiveness of the ISMS
  • preventative and corrective actions (including those that might have been identified in previous reviews or audits)
  • incident reports, for example, if there has been a security failure, a report that identifies what the failure was, when it occurred, and how it was handled and possibly corrected.
  • vulnerabilities or threats not adequately addressed in the previous risk assessment
  • follow-up actions from previous reviews
  • any organizational changes that could affect the ISMS
  • recommendations for improvement

To perform internal audits on a periodic basis, you need to define the scope, criteria, frequency, and methods. You also need the procedure (which should have been written as part of step 10) that identifies the responsibilities and requirements for planning and conducting the audits, and for reporting results and maintaining records.
Results:
The results of a management review should include decisions and actions related to:

  • Improvements to the ISMS
  • Modification of procedures that affect information security at all levels within the organization
  • Resource needs
  • The results of an internal audit should result in the identification of nonconformity and their related corrective actions or preventative actions. ISO 27001 lists the activity and record requirements related to corrective and preventative actions.

13 Prepare for the certification audit

If you plan to have your ISMS certified, you will need to conduct a full cycle of internal audits, management review, and activities in the PDCA process. The external auditor will first examine your ISMS documents to determine the scope and content of your ISMS. Then the auditor will examine the necessary records and evidence that you implement and practice what is stated in your ISMS.
What you will need:

  • All of the documents that you created in the preceding steps.
  • Records from at least one full cycle of management reviews, internal audits, and PDCA activities, and evidence of responses taken as the result of those reviews and audits.

Results:
The results of this preparation should be a set of documents that you can send to an auditor for review and a set of records and evidence that will demonstrate how efficiently and completely you have implemented your ISMS.

14 Ask for help

As you can see, establishing, implementing, and maintaining an ISMS can require a lot of work—especially in its formative stages. If you are new to management systems or specifically to information security management systems, you can consider hiring us to guide you through the process. Our familiarity with the requirements of an ISMS and the suggested controls in the IEO standards can save you time and money and will ensure that you will achieve effective security practices and possibly a successful ISMS certification.

ISO 27001:2013 structure

Clause 0: Introduction

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

Clause 1: Scope

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

Clause 2: Normative references

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

Clause 3: Terms and definitions

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

ISO and IEC maintain terminology databases used in ISO 27000/27001 at the following addresses:
— 1SO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at https://www.electropedia.org

Clause 4: Context of the organization

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

Clause 5: Leadership

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

Clause 6: Planning

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

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

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

Clause 7: Support

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

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

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

Clause 8: Operation

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

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

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

Clause 9: Performance evaluation

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

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

Clause 10: Improvement

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

Annex A Information security controls reference

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

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

5 Organizational controls

5.1 Policies for information security

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

The purpose of this control is to ensure continuing suitability, adequacy, effectiveness of management direction and support for information security in accordance with business, legal, statutory, regulatory and contractual requirements.Management should define a set of policies to clarify their direction of, and support for, information security. At the top level, there should be an overall “information security policy” A document needs to be created, containing how the organization manages information security objectives. This document needs to be approved by management, and needs to contain both high- and low-level policies. Once the policies are in place, they need to be reviewed regularly. The best approach to this is to set a regular meeting and plan an extra meeting in between should the situation require it. If any changes are made, management needs to give their approval. The policies should be shared with internal and external stakeholders.

5.2 Information security roles and responsibilities

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

The purpose of this control is to establish a defined, approved and understood structure for the implementation, operation and management of information security within the organization. The policy needs to define who is responsible for what asset, process, or information security risk activity. It is important that the assignment is done clearly and for all assignments. Make sure that the roles and responsibilities suit your organization; a small team of five probably does not need a full time security officer.

5.3 Segregation of duties

Control
Conflicting duties and conflicting areas of responsibility should be segregated.

The purpose of this control is to reduce the risk of fraud, error and bypassing of information security controls. To prevent any misuse of company assets, the “power” to fully control a sensitive activity should not lie with the same person. The best way to implement this is to log all activities and split important tasks in doing and checking or approving and initiating. This prevents fraud and error, e.g. in the case of having one person create and sign all company cheques.

5.4 Management responsibilities

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

The purpose of this control is to ensure management understand their role in information security and undertake actions aiming to ensure all personnel are aware of and fulfill their information security responsibilities. Management needs to make sure all employees and contractors are aware of and follow the organization’s information security policy. They should lead by being an example and show that Information Security is both useful and necessary.

5.5 Contact with authorities

Control
The organization should establish and maintain contact with relevant authorities.

The purpose of this control is to ensure appropriate flow of information takes place with respect to information security between the organization and relevant legal, regulatory and supervisory authorities. It should be clear who is responsible for contacting authorities (e.g. law enforcement, regulatory bodies, supervisory authorities), which authorities should be contacted (e.g. which region/country), and in what cases this needs to happen. A quick and adequate response to incidents can greatly decrease the impact, and may even be mandatory by law.

5.6 Contact with special interest groups

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

The purpose of this control is to ensure appropriate flow of information takes place with respect to information security.To make sure that the latest information security trends and best practices are kept up with, good contact with special interest groups should be maintained by personnel with ISMS tasks. Such groups can be asked for expert advice in certain cases, and be a great source for improving one’s own knowledge.

5.7 Threat intelligence

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

The purpose of this control is to provide awareness of the organization’s threat environment so that the appropriate mitigation actions can be taken. Reacting to threats does little to prevent their first materialized occurrence. By collecting and analyzing information about threats to your organization, you have a better idea of which protection mechanisms need to be put in place to protect against the threats that are relevant to your organization. Computer chip manufacturers need to prepare for targeted IP-theft attacks by state actors, but for a small SaaS-provider, automated phishing mails are a greater threat.

5.8 Information security in project management

Control
Information security should be integrated into project management.

The purpose of this control is to ensure information security risks related to projects and deliverables are effectively addressed in project management throughout the project life cycle. To assure a successful organization wide ISMS implementation, information security should be considered and documented in all projects in the form of requirements. These requirements can stem from business, legal, and compliance with other standards or regulations. If you have project management handbooks or templates, an information security chapter should be included.

5.9 Inventory of information and other associated assets

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

The purpose of this control is to identify the organization’s information and other associated assets in order to preserve their information security and assign appropriate ownership. The organization should have identified of all information- and information processing assets. All the assets must be drawn up in an inventory, which should be properly maintained. Knowing what assets there are, their importance, where they are, and how they are handled is essential in identifying and predicting risks. It might even be mandatory for legal obligations or insurance purposes.
All assets in the inventory, so of the whole company if the inventory is complete, must have an owner. Thanks to asset ownership, assets are watched and taken care of through their whole life cycle. Similar assets may be grouped and the day to day supervision of an asset may be left to a so-called custodian, but the owner remains responsible. Asset ownership must be approved by management.

5.10 Acceptable use of information and other associated assets

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

The purpose of this control is to ensure information and other associated assets are appropriately protected, used and handled. There should be well-document rules for accessing information assets. Users of the asset should be aware of the information security requirements regarding asset use, and follow them. For the handling of assets, procedures should be in place as well. Personnel need to understand the labeling of assets, and know how to handle different levels of classifications. Since there is no universal standard for classification, it is also important to have knowledge of classification levels of other parties, since they will most likely differ from yours.

5.11 Return of assets

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

The purpose of this control is to protect the organization’s assets as part of the process of changing or terminating employment, contract or agreement. When an employee or external party may no longer access an asset due to, for example, the end of employment of agreement, they must return the asset to the organization. There should be a clear policy for this, which has to be known by all involved. Non-tangible assets important to current operations such as specific knowledge that is not yet documented should be documented and returned as such.

5.12 Classification of information

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

The purpose of this control is to ensure identification and understanding of protection needs of information in accordance with its importance to the organization. Certain information is considered to be sensitive due to e.g. monetary or legal value, and has to remain confidential while other information is less crucial. The organization should have a policy in place on how to handle classified information. The accountability to classify information assets lies with its owner. To distinguish between the importance of different classified assets, it can be useful to implement several levels of confidentiality from non-existent to severely impacting the organization’s survival.

5.13 Labeling of information

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

The purpose of this control is to facilitate the communication of classification of information and support automation of information processing and management. Not all information falls in the same category, as discussed in 5.12 above. It is, therefore, important to label all information in accordance to their classification. When information is handled, stored, or exchanged it may be vital to know the classification of the object. The labels should be easily recognizable. The procedures should give guidance on where and how labels are attached in consideration of how the information is accessed or the assets are handled depending on the types of storage media..

5.14 Information transfer

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

The purpose of this control is to maintain the security of information transferred within an organization and with any external interested party. Information is shared inside and outside the organization. There should be a protocol for all types of information sharing, including digital documents, physical documents, video, but also by word of mouth. Clear rules on how information can be safely shared helps lower the risk of information contamination and leaks. Information that is shared between the organization and external parties needs to be preceded by an information transfer agreement. This way, the source, content, confidentiality, transfer medium, and destination of the information transfer is known by and agreed upon by both parties. Business communication often happens by means of electronic messaging. Organizations are advised to have an overview of approved types of electronic messaging and should document how these are protected and may be used.

5.15 Access control

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

The purpose of this control is to ensure authorized access and to prevent unauthorized access to information and other associated assets. An access control policy should be in place to define how access is managed, and who is allowed to access what. The rules per asset lie with the asset owners, who set up requirements, restrictions, and rights for the access to “their” asset. Frequently used terms in an access control policy are need-to-know and need-to-use, where the former restricts the access rights only to information an employee needs to perform their task and the latter restricts the access rights only to information processing facilities needed to perform the task.

5.16 Identity management

Control
The full life cycle of identities should be managed.

The purpose of this control is to allow for the unique identification of individuals and systems accessing the organization’s information and other associated assets and to enable appropriate assignment of access rights. To assign access rights to assets and networks and keep track of who actually does the accessing, users need to be registered under an ID. When an employee leaves an organization, the ID and access to it should be removed. When an employee only needs to be denied access, the access of the ID can be limited. Even though using another employee’s ID might be quicker and easier to access something, this should not be allowed by management in most cases. Sharing ID’s removes the link between an access limitation and an employee, and makes it nearly impossible to keep the right person responsible for their actions. Assigning, altering, and ultimately deleting an identity is often called the identity life cycle.

5.17 Authentication information

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

The purpose of this control is to ensure proper entity authentication and prevent failures of authentication processes. Secret authentication, such as passwords and access cards, must be managed in a formal process. Other important activities that should be stated in the policy are, for example, forbidding users to share secret authentication information, giving new users a password that has to be changed on first use, and having all systems authenticate a user by requiring a user’s secret authentication information (password on PC, swiping access card for doors).
If password management systems are used, they need to provide good passwords and strictly follow the organizations secret authentication information policy. The passwords themselves should be stored and transmitted securely by the password management system.

5.18 Access rights

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

The purpose of this control is to ensure access to information and other associated assets is defined and authorized according to the business requirements. Management should have a system in place for the provisioning and revoking of access rights. It is advised to create certain roles based on activities certain types of employees perform, and give the same basic access rights to them. Part of having a system in place is having repercussions for attempted unauthorized access. Employees have no need to try to access places they should not, since access rights can easily be requested from the asset owner and/or management. Organisations and their employees are not static. Roles change or employees leave the company, constantly changing access needs. Asset owners should regularly review who may access their asset, while role changing or leaving should trigger an access rights review by management. Since privileged access rights are more sensitive, they should be reviewed more often. Once a contract or agreement has been terminated, the access rights of the receiving party should be removed.

5.19 Information security in supplier relationships

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

The purpose of this control is to maintain an agreed level of information security in supplier relationships. Since suppliers have access to certain assets, organizations need to establish a policy stating requirements for risk mitigation. This policy needs to be communicated to suppliers and agreed upon. Examples of such requirements are predetermined logistic processes, an incident process obligations for both sides, Non Disclosure Agreements, and documentation of the supplying process.

5.20 Addressing information security within supplier agreements

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

The purpose of this control is to maintain an agreed level of information security in supplier relationships. Every supplier that in any way, directly or indirectly, comes into contact with the organization’s information must follow the set information security requirements and agree to them. Examples are requirements on information classification, acceptable use, and rights to audit. An easily forgotten aspect of an agreement is what to do when the supplier cannot or will not supply anymore. It is important to implement a clause for that.

5.21 Managing information security in the ICT supply chain

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

The purpose of this control is to maintain an agreed level of information security in supplier relationships. Agreements with suppliers should also state the information security requirements and agreements on ICT services and supply chain. Examples of included requirements are the need to be able to follow items through the supply chain, and that a certain minimal level of security is maintained at every level of the “chain”.

5.22 Monitoring, review and change management of supplier services

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

The purpose of this control is to maintain an agreed level of information security and service delivery in line with supplier agreements. Everyone makes mistakes, and so do suppliers. Whether the mistake happened by accident or deliberately , the result is the same: the organization does not receive exactly what has been agreed upon and trust may decrease. For this reason, organizations should keep an eye on suppliers, and audit them where felt necessary. This way, an organization is aware when a supplier does something out of the ordinary. Just like with system changes, management needs to control any changes in supplier services. They need to make sure that information security policies are up to date and any changes in the provision of the service itself is managed. A small change in the provided service combined with an outdated information security policy might result in a large new risk. Supplier-side changes can easily occur, for example when the service is enhanced, a new app or system is supplied, or the supplier’s policies and procedures change.

5.23 Information security for use of cloud services

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

The purpose of this control is to specify and manage information security for the use of cloud services. Cloud suppliers offer a service that, when in use, is more often than not a vital part of an organisation’s infrastructure. Office documents are stored in the cloud, but many SaaS-providers offer their product to their customers via a cloud provider such as Amazon AWS, Microsoft Azure, or Google Cloud. The risks surrounding this critical part of the organisation should be appropriately mitigated. Organizations should have processes for using, managing, and leaving (exit strategy) a used cloud. Severing ties with a cloud provider often means a new cloud provider is on the horizon, so controlling the purchasing and on boarding onto a new cloud should not be forgotten either. Just like any other third party software, a new cloud environment should allow you to keep your desired level of information security, not compromise it.

5.24 Information security incident management planning and preparation

The purpose of this control is to ensure quick, effective, consistent and orderly response to information security incidents, including communication on information security events. Organizations need to create and document procedures for information security incidents, and who is responsible for what. This way, should an information security incident occur, it can be handled effectively and quickly. Security incident happen unexpected and can cause quite some chaos, which can be mitigated by having a protocol that is followed by knowledgeable and trained staff.

5.25 Assessment and decision on information security events

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

The purpose of this control is to ensure effective categorization and prioritization of information security events. Organizations should have a well document assessment method for security incidents. When a suspicious event occurs, the responsible person is to test the event against the requirements and determine whether there was an actual information security incident. The results of this assessment should be documented, so that they can be used for future reference.

5.26 Response to information security incidents

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

The purpose of this control is to ensure efficient and effective response to information security incidents. This point seems straight forward, but is still important to mention and sometimes hard to do in practice. Once an information security incident occurs, it needs to be responded to following the set-up procedures by the appointed staff. The pre-determined actions should be taken, and the whole process accurately documented. This helps prevent future occurrences and weed out related security vulnerabilities.

5.27 Learning from information security incidents

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

The purpose of this control is to reduce the likelihood or consequences of future incidents. Even though incidents are unwanted, they still possess great value. The knowledge gained from solving an incident should be used to prevent similar incidents in the future, and can help identify a possible systematic problem. With additional controls, it is important to keep an eye on the costs; a new control should not cost the organisation more on an annual basis than the incidents it mitigates.

5.28 Collection of evidence

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

The purpose of this control is to ensure a consistent and effective management of evidence related to information security incidents for the purposes of disciplinary and legal actions. Once an accident occurs, the cause is usually not immediately clear. When the cause is an individual or organization, they should be disciplined based on the intention and effect. To link an incident to a cause, evidence needs to be collected. In case of a malicious action, this evidence and the way it was obtained might be used in legal proceedings. To prevent accidental or deliberate destruction of evidence, there should be a clear and safe evidence identification procedure.

5.29 Information security during disruption

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

The purpose of this control is to protect information and other associated assets during disruption. Organizations should determine their requirements for information security continuity in case of a crisis. The easiest choice is to resume standard information security activities as best as possible in an adverse situation. Once the requirements have been determined and agreed upon in management, procedure, plans, and controls should be put in place to resume with an acceptable level of information security in case of a crisis.
As organizations change, the best way to respond to a crisis changes as well. An organization that, for example, doubled in size within a years’ time will most likely benefit from a different response than a year ago. For this reason, the information security continuity controls on a regular basis.

5.30 ICT readiness for business continuity

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

The purpose of this control is to ensure the availability of the organization’s information and other associated assets during disruption. During Business Continuity planning, special attention should be placed on scenarios where IT systems fail. There should be a clear strategy how systems will be restored, who will do this, and how long this may and will take. It should also be clear what “restoring” means in a specific scenario, since having only the core systems running is likely enough for the first week after a complete meltdown.

5.31 Identification of legal, statutory, regulatory and contractual requirements

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

The purpose of this control is to ensure compliance with legal, statutory, regulatory and contractual requirements related to information security. Requirements come from all places, and are there to be met. Organizations should therefore have an overview of all information security related requirements they need to comply to, and how this is done. Since requirements can change or get added, the requirement compliance overview needs to be kept up to date. An example of changing requirements is when your organization expands to a new country on a different continent. This country is likely to have different laws on privacy, information storage, and cryptography.

5.32 Intellectual property rights

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

The purpose of this control is to ensure compliance with legal, statutory, regulatory and contractual requirements related to intellectual property rights and use of proprietary products Intellectual property (IP) rights, also a part of legal compliance, is an area that deserves special attention. IP can be of great value, so it is important to document one’s own intellectual property and the use of other’s intellectual property well. (Accidental) wrong use of other’s IP may result in large lawsuits, and should be prevented at all costs.

5.33 Protection of records

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

The purpose of this control is to ensure compliance with legal, statutory, regulatory and contractual requirements, as well as community or societal expectations related to the protection and availability of records. Any records, be it accounting records or audit logs, should be protected. Records are at the risk of being lost, compromised, or accessed unauthorized. The requirements for the protection of record might come from the organization itself or from other sources such as legislation or insurance companies. For this, strict guidelines should be created and followed.

5.34 Privacy and protection of Personal Identifiable Information (PII)

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

The purpose of this control is to ensure compliance with legal, statutory, regulatory and contractual requirements related to the information security aspects of the protection of PII. Depending on the country or economic space an organization is located in, different legislation on the protection of personal data might apply. To organizations situated in the Qatar and/or processing personal data in Qatar, Qatar has implemented Law No. (13) of 2016 Concerning Personal Data Protection. Organizations need to make sure they are aware of the requirements set by such legislation, and follow it religiously. The Law, for example, mandates conducting data processing agreements, keeping a register of processing activity, and data processing transparency.

5.35 Independent review of information security

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

The purpose of this control is to ensure the continuing suitability, adequacy and effectiveness of the organization’s approach to managing information security. It is impossible for organizations to objectively review their own information security system. For this reason, organizations should have their information security audited by an independent party on a regular basis, or when large changes occur. This keeps an organization’s view of their information security correct and transparent. An independent party can also be a full-time internal auditor, who has the sole task of performing the internal audits and does not have other conflicting tasks and responsibilities.

5.36 Compliance with policies and standards for information security

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

The purpose of this control is to ensure that information security is implemented and operated in accordance with the organization’s information security policy, topic-specific policies, rules and standards. With all these security policies, standards and procedures, it is important for managers to regularly review whether the activities and/or processes they are responsible for are fully compliant. For this to be done correctly, they should be aware of exactly which rules and requirement they need to comply with and check this manually or with an automatic reporting tool. Information systems need to be regularly reviewed for compliance as well. The easiest and usually most cost-effective way to do this is by means of automated tooling. This tooling can quickly check all the nooks and crannies of a system and report exactly what went/could go wrong. Vulnerability tests such as penetration tests can effectively show any weaknesses, but might actually harm the system when done without caution.

5.37 Documented operating procedures

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

The purpose of this control is to ensure the correct and secure operation of information processing facilities. Procedures for the operating of equipment should be documented and made available to those using the equipment. From the simple procedure of computer use (from start to shut-down) to the use of more complicated equipment there should be a guide on how to safely and correctly operate it. Due to their importance, the procedures should be treated as formal documents, meaning that any changes should be approved by management.

6.0 People control

6.1 Screening

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

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

6.2 Terms and conditions of employment

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

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

6.3 Information security awareness, education and training

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

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

6.4 Disciplinary process

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

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

6.5 Responsibilities after termination or change of employment

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

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

6.6 Confidentiality or non-disclosure agreements

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

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

6.7 Remote working

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

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

6.8 Information security event reporting

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

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

7.0 Physical controls

7.1 Physical security perimeter

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

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

7.2 Physical entry controls

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

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

7.3 Securing offices, rooms and facilities

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

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

7.4 Physical security monitoring

Control
Premises should be continuously monitored for unauthorized physical access.

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

7.5 Protecting against physical and environmental threats

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

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

7.6 Working in secure areas

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

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

7.7 Clear desk and clear screen

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

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

7.8 Equipment siting and protection

Control
Equipment should be sited securely and protected.

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

7.9 Security of assets off-premises

Control
Off-site assets should be protected.

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

7.10 Storage media

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

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

7.11 Supporting utilities

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

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

7.12 Cabling security

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

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

7.13 Equipment maintenance

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

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

7.14 Secure disposal or re-use of equipment

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

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

8.0 Technological controls

8.1 User endpoint devices

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

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

8.2 Privileged access rights

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

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

8.3 Information access restriction

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

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

8.4 Access to source code

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

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

8.5 Secure authentication

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

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

8.6 Capacity management

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

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

8.7 Protection against malware

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

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

8.8 Management of technical vulnerabilities

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

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

8.9 Configuration management

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

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

8.10 Information deletion

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

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

8.11 Data masking

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

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

8.12 Data leakage prevention

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

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

8.13 Information backup

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

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

8.14 Redundancy of information processing facilities

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

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

8.15 Logging

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

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

8.16 Monitoring activities

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

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

8.17 Clock synchronisation

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

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

8.18 Use of privileged utility programs

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

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

8.19 Installation of software on operational systems

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

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

8.20 Network security

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

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

8.21 Security of network services

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

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

8.22 Segregation in networks

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

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

8.23 Web filtering

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

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

8.24 Use of cryptography

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

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

8.25 Secure development life cycle

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

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

8.26 Application security requirements

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

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

8.27 Secure system architecture and engineering principles

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

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

8.28 Secure coding

Control
Secure coding principles should be applied to software development.

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

8.29 Security testing in development and acceptance

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

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

8.30 Outsourced development

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

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

8.31 Separation of development, test and production environments

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

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

8.32 Change management

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

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

8.33 Test information

Control
Test information should be appropriately selected, protected and managed.

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

8.34 Protection of information systems during audit and testing

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

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

Back to Home Page

If you need assistance or have any doubt and need to ask any questions contact me at 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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s