ISO 27001:2013 Information Security

Management System
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 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 a 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 an 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.
Example:
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

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 provide
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 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.
Example:

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
 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.
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 a 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.
Examples:
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

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. 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.
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.
Example:
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.

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 effect information security at all levels within the organization

Resource needs

The results of an internal audit should result in 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 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
In the previous version ISO 27001:2005, 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) ‘preserves 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 emphasises that the ISMS is part of and integrated with the organisation’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 organisation. There is only small but significant difference: previously the standard could be used to
assess conformance now it is to assess the organisation’s ability to meet the organisation’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 organisation. It goes on
to require the assessment and treatment of information security risks tailored to the needs of the
organisation. 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
The 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.
The 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.

The 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.
The 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 the requirements for ‘documented information’. The new standard refers to “documented
information” rather than “documents and records” and requires that they be 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 mandates the carrying out of information security risk assessments at
planned intervals and the implementation of an information security risk treatment plan.
The 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;
The Clause 8.2 deals with the performance of information security risk assessments at planned intervals,
or when significant changes are proposed or occur; and
The 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 backwards 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 learnt. 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. The 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 the 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 depends 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 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 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 how to decrease the risks and how to
maintain it in an accepted
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 being 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 being 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 sub-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 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 fulfil 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, labelling,
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 labelled 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 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 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 protection of
information in systems and applications in networks and its supporting information processing facilities.
Controls cover 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, 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 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 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.