ISO 27001:2013 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.

This example shows a possible policy statement with goals and objectives.

Example of Security Policy

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.


Example of Scope Statements

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.
Example: The text added to the scope statement as a result of identifying applicable legislation is shown in the following example.

Scope and Purpose
The company is committed to protecting its information and that of its customers. To achieve this goal, the company has implemented an Information Security Management System in accordance with ISO 27001: 2013 and the rules and regulations that are part of Information Technology Act, 2000 also know as IT Act. 
The company’s ISMS is applicable to the following areas of the business:
• Finance department
• Internal IT systems and networks used for back-end business (such as email, timesheets, contract development and storage, and report writing)
(Note: IT systems and networks on which company software is developed and stored are part of the Software Development ISMS.)

 Example of Additional Scope Text

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, as shown in the following table:
  • 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.
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.

Example of Asset Table with Placeholder Columns for Assessment Information

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.
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.
In the following example, the Risk Summary column describes the threat and vulnerability. The CIA profile classifies the asset’s confidentiality, integrity, and availability.

Example of Risk Identification

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.

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.
If you used a table similar to the one in the preceding examples, your result after completing this step might look like the following example:

Example of 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

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. For additional help with creating a Risk Treatment Plan and a Statement of Applicability, refer to the two sets of examples that follow.

Examples of Risk Treatment Plan:
If you used a table as described in the preceding steps, the control analysis portion of your Risk Treatment Plan could be covered by the Control column and the Sufficient Control column, as shown in the following example. Any risks that you transfer to others or that you choose to accept as they are should also be recorded in your treatment plan.

The remaining Risk Treatment Plan requirements could be met by adding this table and by explaining the methods used for treating risk and the time frame in which the controls will be implemented to a Risk Assessment Methodology document, like the one you created in step 5.

Example of Statement of Applicability:

The following is an excerpt of a Statement of Applicability document. The Reference column identifies the location where the statement of policy or detailed procedure related to the implementation of the control is documented.

Example of Statement of Applicability

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.
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.
The number of policies, procedures, and records that you will require as part of your ISMS will depend on a number of factors, including the number of assets you need to protect and the complexity of the controls you need to implement. The example that follows shows a partial list of one organization’s set of documents:

Mandatory documents and records required by ISO 27001:2013

  • Scope of the ISMS (clause 4.3)
  • Information security policy and objectives (clauses 5.2 and 6.2)
  • Risk assessment and risk treatment methodology (clause 6.1.2)
  • Statement of Applicability (clause 6.1.3 d)
  • Risk treatment plan (clauses 6.1.3 e and 6.2)
  • Risk assessment report (clause 8.2)
  • Definition of security roles and responsibilities (clauses A.7.1.2 and A.13.2.4)
  • Inventory of assets (clause A.8.1.1)
  • Acceptable use of assets (clause A.8.1.3)
  • Access control policy (clause A.9.1.1)
  • Operating procedures for IT management (clause A.12.1.1)
  • Secure system engineering principles (clause A.14.2.5)
  • Supplier security policy (clause A.15.1.1)
  • Incident management procedure (clause A.16.1.5)
  • Business continuity procedures (clause A.17.1.2)
  • Statutory, regulatory, and contractual requirements (clause A.18.1.1)

And here are the mandatory records:

  • Records of training, skills, experience, and qualifications (clause 7.2)
  • Monitoring and measurement results (clause 9.1)
  • Internal audit program (clause 9.2)
  • Results of internal audits (clause 9.2)
  • Results of the management review (clause 9.3)
  • Results of corrective actions (clause 10.1)
  • Logs of user activities, exceptions, and security events (clauses A.12.4.1 and A.12.4.3)

Non-mandatory documents
There are numerous non-mandatory documents that can be used for ISO 27001 implementation, especially for the security controls from Annex A. However, I find these non-mandatory documents to be most commonly used:

  • Procedure for document control (clause 7.5)
  • Controls for managing records (clause 7.5)
  • Procedure for internal audit (clause 9.2)
  • Procedure for corrective action (clause 10.1)
  • Bring your own device (BYOD) policy (clause A.6.2.1)
  • Mobile device and teleworking policy (clause A.6.2.1)
  • Information classification policy (clauses A.8.2.1, A.8.2.2, and A.8.2.3)
  • Password policy (clauses A.9.2.1, A.9.2.2, A.9.2.4, A.9.3.1, and A.9.4.3)
  • Disposal and destruction policy (clauses A.8.3.2 and A.11.2.7)
  • Procedures for working in secure areas (clause A.11.1.5)
  • Clear desk and clear screen policy (clause A.11.2.9)
  • Change management policy (clauses A.12.1.2 and A.14.2.4)
  • Backup policy (clause A.12.3.1)
  • Information transfer policy (clauses A.13.2.1, A.13.2.2, and A.13.2.3)
  • Business impact analysis (clause A.17.1.1)
  • Exercising and testing plan (clause A.17.1.3)
  • Maintenance and review plan (clause A.17.1.3)
  • Business continuity strategy (clause A.17.2.1)

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.

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.
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 nonconformities 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.

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

In the previous version ISO 27001:2005, the PDCA model was in the Introduction section. In ISO 9001:2013, the section on the PDCA model has been removed. The reason for this is that the requirement is for continual improvement and PDCA is just one approach to meeting that requirement. There are other approaches, and organizations are now free to use them if they wish. 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 no longer refers to any ‘model’, just requirements, and it now states explicitly the objective of an information security management system (ISMS) ‘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 contents of an ISMS continues to be made up of the usual components i.e. Policy, Resources, Management Processes, Information security risk assessment and treatment, Statement of Applicability, Documented Information and ISM processes deemed relevant to the organization. There is the only small but significant difference: previously the standard could be used to assess conformance now it is to assess the organization’s ability to meet the organization’s own information security requirements. The compatibility clause 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 compares to the implementation of security controls in the 2005 edition. This, too, is a much shorter clause compared to the previous edition. In particular, there is no reference to the exclusion of controls in Annex A. Clause 1.2 Application (and exclusion) which was there in the previous version has been deleted. This is a significant change – 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

Unlike the 2005 edition, there are no terms and definitions included. All the common terms and definitions from Annex SL are included plus additions, changes, and deletions from the 2012 edition of ISO/IEC 27000. 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:2013 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

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-conformant with the standard.
The final requirement (Clause 4.4) is to establish, implement, maintain and continually improve the ISMS in accordance with the requirements the standard.

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.

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 of people involved
  • Awareness of and communication with interested parties
  • Requirements for document management

Finally, there are requirements for ‘documented information’. The new 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. They are not summarized in a clause of their own, as they are in ISO/IEC 27001:2005.

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 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.
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. Clause 9.2, (Internal audit) requires is similar to its counterpart in ISO  27001:2005. However, the requirement holding management responsible for ensuring that audit actions are taken without undue delay has been removed, as it is effectively covered by the requirements in Clause 10.1. The requirement that auditors shall not audit their own work has also been removed, as it is covered by the requirement to ensure objectivity and impartiality (Clause 9.2 e).
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 nonconformities and take action, as applicable, to control and correct the nonconformity and deal with the consequences. The second is to determine whether similar nonconformities exist, or could potentially occur. Although the concept of preventive action has evolved there is still a need to consider potential nonconformities, 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 nonconformities 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

ISO 27002:2013

The Information Security standard ISO 27002:2013 is the “Code of Practice for Information Security Controls”. The document provides best practice recommendations and guidance for organizations selecting and implementing information security controls within the process of initiating, implementing and maintaining an Information Security Management System (ISMS). The establishment and implementation of an ISMS depend on a strategic orientation of the organization and is influenced by a number of aspects including its needs, objectives, security requirements, the organizational processes used, the size and the structure of the organization. An ISMS such as specified in ISO 27001 is an integrated part of the organization’s processes and overall management structure, with the main objective to ensure the necessary levels of confidentiality, integrity, and availability of information. This objective is achieved by applying a supporting risk management process within the ISMS and by implementing a suite of information security controls as part of the risk treatment under the overall framework of a coherent management system. The normative requirements of ISMS are addressed in clauses 4 to 11 of 27001:2013 that define the ISMS. Furthermore, organizations need to consider the set of 144 controls which are found in Annex A of the same standard.
In ISO 27002, you will find more detailed guidance on the application of the controls of Annex A including areas such as policies, processes, procedures, organizational structures and software, and hardware functions. All these information security controls may need to be established, implemented, monitored, reviewed and improved, where necessary, to ensure that the specific established security and business objectives of the organization are met. ISO 27002 provides general guidance on the controls of ISO 27001 and should be combined and used with other standards of the information security management system family of standards, including ISO 27003 (implementation), ISO 27004 (measurement), and ISO 27005 (risk management).

ISO 27002 applies to all types and sizes of organizations, including public and private sectors, commercial and non-profit that collect, process, store and transmit information in many forms including electronic, physical and verbal. This standard should be used as a reference for the consideration of controls within the process of implementing an Information Security Management System based on ISO 27001, it implements commonly accepted information security controls and develops the organization’s own information security management guidelines. The standard contains 14 security control clauses, collectively containing a total of 35 main security categories and 114 controls.

In each section of the ISO 27002 standard, there is a security control category that contains:

  • a control objective stating what is to be achieved;
  • one or more controls that can be applied to achieve the control objective;
  • implementation guidance and any other pertinent information useful for understanding the controls and implementation process.

If you want to create the foundations of information security in your organization and devise its framework, you should use ISO 27001; whereas if you want to focus on the implementation controls, you should use ISO 27002. So by implementing ISO 27001 correctly, an organization will have a management system that will assist in efficiently planning, implementing, monitoring, reviewing and improving information security in scope. On the other hand, ISO 27002 can assist to implement and maintain controls to achieve objectives for all requirements as required by ISO 27001. For every risk situation identified in ISO 27001, ISO 27002 will give a set of controls on how to decrease the risks and how to maintain it at an acceptable level. 

Key clauses of ISO  27002:2013

ISO 27002 is organized into the following main clauses:
The standard contains 14 security control clauses, collectively containing a total of 35 main security categories and 114 controls.

  • Clause 5: Information Security Policies
  • Clause 6: Organization of Information Security
  • Clause 7: Human Resource Security
  • Clause 8: Asset Management
  • Clause 9: Access Control
  • Clause 10: Cryptography
  • Clause 11: Physical and Environmental Security
  • Clause 12: Operations Security
  • Clause 13: Communication Security
  • Clause 14: System Acquisition, Development, and Maintenance
  • Clause 15: Supplier Relationships
  • Clause 16: Information Security Incident Management
  • Clause 17: Information Security Aspects of Business Continuity Management
  • Clause 18: Compliance

Section 0: Introduction

This lays out the background, mentions three origins of information security requirements, notes that the standard offers generic and potentially incomplete guidance that should be interpreted in the organization’s context, mentions information and information system lifecycles, and points to ISO/IEC 27000 for the overall structure and glossary for ISO27k.

Section 1: Scope

The standard gives recommendations for those who are responsible for selecting, implementing and managing information security. It may or may not be used in support of an ISMS specified in ISO 27001.

Section 2: Normative references

ISO 27000 is the only standard considered absolutely indispensable for the use of ISO 27002. However, various other standards are mentioned in the standard, and there is a bibliography.

Section 3: Terms and definitions

All the specialist terms and definitions are now defined in ISO 27000 and most apply across the entire ISO27k family of standards.

Section 4: Structure of this standard

Security control clauses
Of the 21 sections or chapters of the standard, 14 specify control objectives and controls. These 14 are the ‘security control clauses’.
There is a standard structure within each control clause: one or more first-level subsections, each one stating a control objective, and each control objective are supported in turn by one or more stated controls, each control followed by the associated implementation guidance and, in some cases, additional explanatory notes. The amount of detail is responsible for the standard is nearly 90 A4 pages in length.
35 control objectives
ISO 27002 has some 35 control objectives (one per ’security control category’) concerning the need to protect the confidentiality, integrity, and availability of information. The control objectives are at a fairly high level and, in effect, comprise a generic functional requirements specification for an organization’s information security management architecture. Few would seriously dispute the validity of the control objectives, or, to put that another way, it would be difficult to argue that an organization need not satisfy the stated control objectives in general. However, some control objectives are not applicable in every case and their generic wording is unlikely to reflect the precise requirements of every organization, especially given the very wide range of organizations and industries to which the standard applies.  This is why ISO 27001 requires the SoA (Statement of Applicability), laying out unambiguously which information security controls are or are not required by the organization, as well as their implementation status.
114  controls
Each of the control objectives is supported by at least one control, giving a total of 114. However, the headline figure is somewhat misleading since the implementation guidance recommends numerous actual controls in the details. The control objective relating to the relatively simple subsection 9.4.2 “Secure log-on procedures”, for instance, is supported by choosing, implementing and using suitable authentication techniques, not disclosing sensitive information at log-on time, data entry validation, protection against brute-force attacks, logging, not transmitting passwords in clear over the network, session inactivity timeouts, and access time restrictions. Whether you consider that to be one or several controls is up to you. It could be argued that ISO 27002 recommends literally hundreds of distinct information security controls, although some support multiple control objectives, in other words, some controls have several purposes. Furthermore, the wording throughout the standard clearly states or implies that this is not a totally comprehensive set. An organization may have slightly different or completely novel information security control objectives, requiring other controls (sometimes known as ‘extended control sets’) in place of or in addition to those stated in the standard.

Section 5: Information security policies

The Information Security Policies clause addresses the need to define, publish and review different types of policies required for information security management

5.1 Management direction for information security

Objectives: To provide management direction and support for information security in accordance with business requirements and relevant laws and regulations.
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” as specified in ISO 27001 section 5.2.

Section 6: Organization of information security

The Organization of Information Security clause addresses the need to define and allocate the necessary roles and responsibilities for information security management processes and activities. This includes controls related to the definition of information security roles and responsibilities, segregation of duties, contact with authorities, contact with special interest groups, information security in project management and mobile devices and teleworking.

6.1 Internal organization

Objectives: To establish a management framework, to initiate and control the implementation and operation of information security within the organization.
The organization should lay out the roles and responsibilities for information security, and allocate them to individuals. Where relevant, duties should be segregated across roles and individuals to avoid conflicts of interest and prevent inappropriate activities. There should be contacts with relevant external authorities (such as CERTs and special interest groups) on information security matters. Information security should be an integral part of the management of all types of project.

6.2 Mobile devices and teleworking

Objectives: To ensure the security of teleworking and the use of mobile devices.
There should be security policies and controls for mobile devices (such as laptops, tablet PCs, wearable ICT devices, smartphones, USB gadgets, and other Boys Toys) and teleworking (such as telecommuting, working-from-home, road-warriors, and remote/virtual workplaces).

Section 7: Human resource security

The Human Resource Security clause addresses the required controls for processes related to staff recruiting, their job during employment and after the termination of their contracts. These considerations should include information security coordination, allocation of information security responsibilities, authorization processes for information processing facilities, confidentiality agreements, contact with authorities, contact with special interest groups, independent review of information security, identification of risks related to external parties, addressing security when dealing with customers, addressing security on contractors’ agreements, etc.

7.1 Prior to employment

Objectives: To ensure that employees and contractors understand their responsibilities and are suitable for the roles for which they are considered.
Information security responsibilities should be taken into account when recruiting permanent employees, contractors and temporary staff (e.g. through adequate job descriptions, pre-employment screening) and included in contracts (e.g. terms and conditions of employment and other signed agreements defining security roles and responsibilities, compliance obligations, etc.).

7.2 During employment

Objectives: To ensure that employees and contractors are aware of and fulfill their information security responsibilities.
Managers should ensure that employees and contractors are made aware of and motivated to comply with their information security obligations. A formal disciplinary process is necessary to handle information security incidents allegedly caused by workers.

7.3 Termination and change of employment

Objectives: To protect the organization’s interests as part of the process of changing or terminating employment.
Security aspects of a person’s departure from the organization, or significant changes of roles within it, should be managed, such as returning corporate information and equipment in their possession, updating their access rights, and reminding them of their ongoing obligations under privacy and intellectual property laws, contractual terms etc. plus ethical expectations.

Section 8: Asset management

The Asset Management clause addresses the required responsibilities to be defined and allocated for the asset management processes and procedures. The owner of the assets and other parts involved in this matter should be identified to be held accountable for assets’ security, including classification, labeling, and handling of information; and information processing facilities should be identified and maintained. Moreover, this clause addresses controls on management of removable media, disposal of media, and physical media transfer.

8.1 Responsibility for assets

Objectives: To identify organizational assets and define appropriate protection responsibilities.
All information assets should be inventoried and owners should be identified to be held accountable for their security. ‘Acceptable use’ policies should be defined, and assets should be returned when people leave the organization.

8.2 Information classification

Objectives: To ensure that information receives an appropriate level of protection in accordance with its importance to the organization.
Information should be classified and labeled by its owners according to the security protection needed, and handled appropriately.

8.3 Media handling

Objectives: To prevent unauthorized disclosure, modification, removal or destruction of information stored on media.
Information storage media should be managed, controlled, moved and disposed of in such a way that the information content is not compromised.

Section 9: Access control

The Access controls clause addresses requirements to control access to information assets and information processing facilities. The controls are focused on the protection against accidental damage or loss, overheating, threats, etc. This requires a documented control policy and procedures, registration, removal and review of user access rights, including here physical access, network access and the control over privileged utilities and restriction of access to the program source code.

9.1 Business requirements of access control

Objectives: To limit access to information and information processing facilities.
The organization’s requirements to control access to information assets should be clearly documented in an access control policy and procedures. Network access and connections should be restricted.

9.2 User access management

Objectives: To ensure authorized user access and to prevent unauthorized access to systems and services.
The allocation of access rights to users should be controlled from initial user registration through to removal of access rights when no longer required, including special restrictions for privileged access rights and the management of passwords (now called “secret authentication information”) plus regular reviews and updates of access rights.

9.3 User responsibilities

Objectives: To make users accountable for safeguarding their authentication information.
Users should be made aware of their responsibilities towards maintaining effective access controls e.g. choosing strong passwords and keeping them confidential.

9.4 System and application access control

Objectives: To prevent unauthorized access to systems and applications.
Information access should be restricted in accordance with the access control policy e.g. through secure log-on, password management, control over privileged utilities and restricted access to the program source code.

Section 10: Cryptography

The Cryptography clause addresses policies on cryptographic controls for protection of information to ensure proper and effective use of cryptography in order to protect the confidentiality, authenticity, integrity, non-repudiation, and authentication of the information. It also includes the need for digital signatures and message authentication codes and cryptographic key management.

10.1 Cryptographic controls

Objectives: To ensure proper and effective use of cryptography to protect the confidentiality, authenticity and/or integrity of information.
There should be a policy on the use of encryption, plus cryptographic authentication and integrity controls such as digital signatures and message authentication codes, and cryptographic key management.

Section 11: Physical and environmental security

The Physical and Environmental Security clause addresses the need to prevent unauthorized physical access, damage and interference to the organization’s information and information processing facilities. Controls cover to physically secure the perimeter of office rooms and facilities, protection against external and environmental threats, prevent loss, damage, theft or compromise of assets, protect the equipment from power failures, cabling should be protected from interception or damage, maintenance of equipment, etc.

11.1 Secure areas

Objectives: To prevent unauthorized physical access, damage and interference to the organization’s information and information processing facilities.
Defined physical perimeters and barriers, with physical entry controls and working procedures, should protect the premises, offices, rooms, delivery/loading areas, etc. against unauthorized access. Specialist advice should be sought regarding protection against fires, floods, earthquakes, bombs, etc.

11.2 Equipment

Objectives: To prevent loss, damage, theft or compromise of assets and interruption to the organization’s operations
“Equipment” (meaning ICT equipment, mostly) plus supporting utilities (such as power and air conditioning) and cabling should be secured and maintained. Equipment and information should not be taken off-site unless authorized and must be adequately protected both on and off-site. Information must be destroyed prior to storage media being disposed of or re-used. Unattended equipment must be secured and there should be a clear desk and clear screen policy.

Section 12: Operations security

The Operations security clause addresses the organization’s ability to ensure correct and secure operations. The controls cover the need for operational procedures and responsibilities, protection from malware, backup, logging and monitoring, control of operational software, technical vulnerability management, information systems audit considerations.

12.1 Operational procedures and responsibilities

Objectives: To ensure correct and secure operations of information processing facilities.
IT operating responsibilities and procedures should be documented. Changes to IT facilities and systems should be controlled. Capacity and performance should be managed. Development, test and operational systems should be separated.

12.2 Protection from malware

Objectives: To ensure that information and information processing facilities are protected against malware.
Malware controls are required, including user awareness.

12.3 Backup

Objectives: To protect against loss of data.  
Appropriate backups should be taken and retained in accordance with a backup policy.

12.4 Logging and monitoring

Objectives: To record events and generate evidence.
System user and administrator/operator activities, exceptions, faults and information security events should be logged and protected. Clocks should be synchronized.

12.5 Control of operational software

Objectives: To ensure the integrity of operational systems.
Software installation on operational systems should be controlled.

12.6 Technical vulnerability management

Objectives: To prevent exploitation of technical vulnerabilities.
Technical vulnerabilities should be patched, and there should be rules in place governing software installation by users.

12.7 Information systems audit considerations

Objectives: To minimize the impact of audit activities on operational systems.
IT audits should be planned and controlled to minimize adverse effects on production systems or inappropriate data access.

13 Communications security

The Communication Security clause addresses the organization’s ability to ensure the protection of information in systems and applications in networks and its supporting information processing facilities. Controls cover the security of information in networks and connected services from unauthorized access, transfer policies, and procedures, secure transfer of business information between the organization and external parties, the information involved in electronic messaging, the need for confidentiality or non-disclosure agreements.

13.1 Network security management

Objectives: To ensure the protection of information in networks and its supporting information processing facilities.
Networks and network services should be secured, for example by segregation.

13.2 Information transfer

Objectives: To maintain the security of information transferred within an organization and with any external entity.
There should be policies, procedures, and agreements (e.g. non-disclosure agreements) concerning information transfer to/from third parties, including electronic messaging.

Section 14: System acquisition, development, and maintenance

The System Acquisition, Development and Maintenance clause covers controls for identification, analyses and specification of information security requirements, securing application services in development and support processes, technical review restrictions on changes to software packages, secure system engineering principles, secure development environment, outsourced development, system security testing, system acceptance testing and protection of test data.

14.1 Security requirements of information systems

Objectives: To ensure that information security is an integral part of information systems across the entire lifecycle. This also includes the requirements for information systems which provide services over public networks.
Security control requirements should be analyzed and specified, including web applications and transactions.

14.2 Security in development and support processes

Objectives: To ensure that information security is designed and implemented within the development lifecycle of information systems.
Rules governing secure software/systems development should be defined as policy. Changes to systems (both applications and operating systems) should be controlled. Software packages should ideally not be modified, and secure system engineering principles should be followed. The development environment should be secured, and outsourced development should be controlled. System security should be tested and acceptance criteria defined to include security aspects.

14.3 Test data

Objectives: To ensure the protection of data used for testing.
Test data should be carefully selected/generated and controlled.

15: Supplier relationships

The Supplier Relationships clause addresses controls for supplier’s relationship issues, including here information security policies and procedures, addressing security within supplier agreements, communication, and awareness about technology supply chain and service delivery management.

15.1 Information security in supplier relationships

Objectives: To ensure the protection of the organization’s assets that is accessible by suppliers.
There should be policies, procedures, awareness, etc. to protect the organization’s information that is accessible to IT outsourcers and other external suppliers throughout the supply chain, agreed within the contracts or agreements.

15.2 Supplier service delivery management

Objectives: To maintain an agreed level of information security and service delivery in line with supplier agreements
Service delivery by external suppliers should be monitored, and reviewed/audited against the contracts/agreements. Service changes should be controlled.

Section 16: Information security incident management

The Information Security Incident Management clause covers controls for responsibilities and procedures, reporting information and security weaknesses, assessment of and decision on information security events, response to information security incidents, learning from information security incidents, and collection of evidence.

16.1 Management of information security incidents and improvements

Objectives: To ensure a consistent and effective approach to the management of information security incidents, including communication on security events and weaknesses.
There should be responsibilities and procedures to manage (report, assess, respond to and learn from) information security events, incidents and weaknesses consistently and effectively, and to collect forensic evidence.

Section 17: Information security aspects of business continuity management

The Business Continuity Management clause addresses the organization’s ability to counteract interruptions to normal operations, including the availability of information processing facilities, verify, review and evaluate information security continuity, implementing information security continuity, and planning information security continuity.

17.1 Information security continuity

Objectives: Information security continuity should be embedded in the organization’s business continuity management systems.
The continuity of information security should be planned, implemented and reviewed as an integral part of the organization’s business continuity management systems.

17.2 Redundancies

Objectives: To ensure availability of information processing facilities.
IT facilities should have sufficient redundancy to satisfy availability requirements.

Section 18: Compliance

The Compliance clause addresses the organization’s ability to remain in compliance with regulatory, statutory, contractual, and security requirements, including: identification of applicable legislation and contractual requirements, intellectual property rights, protection of records, privacy and protection of personally identifiable information, regulation of cryptographic controls, independent review of information security, compliance with security policies and standards, and technical compliance review.

18.1 Compliance with legal and contractual requirements

Objectives: To avoid breaches of legal, statutory, regulatory or contractual obligations related to information security and of any security requirements. 
The organization must identify and document its obligations to external authorities and other third parties in relation to information security, including intellectual property, [business] records, privacy/personally identifiable information and cryptography.

18.2 Information security reviews

Objectives: To ensure that information security is implemented and operated in accordance with the organizational policies and procedures.
The organization’s information security arrangements should be independently reviewed (audited) and reported to management. Managers should also routinely review employees’ and systems’ compliance with security policies, procedures etc. and initiate corrective actions where necessary.


Back to Home Page

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

Leave a Reply

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

You are commenting using your 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