Best Practice ISO 27001 Required Documentation

ISO/IEC 27001 implementation best practices are provided through strict implementation guidelines that have been accumulated and evolved over a decade plus. The benefits of regularly maintaining the ISMS implementation through audits and corrective actions are highly attractive.

Recently I visited Amsterdam and I was fascinated by one unexpected part of my trip. The windmills located in the Zaanse Schans, more specifically the wind powered sawmill that is a rich element of Dutch history. Invented at the end of the 16^th century by Cornelis Corneliszoon van Uitgeest, a farmer seeking a better way to cut trees into beams revolutionized the Dutch ship building industry. Before wind powered sawmills, hand sawing and plaining 60 beams would take 120 working days, but only 4 to 5 days utilizing the power of wind. As a result the Dutch amassed the largest fleet of ships both merchant and military in the world. If not for one man, all this amazing historic technology would have been lost. In 1850 a collection of 21 building plans for 5 different types of Dutch windmills was published by G. Krook.

Wind powered sawmills and ISO 27001 documentation?

The ISO/IEC 27001 Standard is an excellent blueprint for implementing and maintaining a high quality ISMS in any organization, because the Standard identifies and defines specific requirements to meet. The Standard clearly provides a best practice attitude through strict implementation guidelines that have been accumulated and evolved over a decade plus. The benefit is when properly implemented and maintained regularly through audits and corrective actions, the information in your trust will be secure and protected. This doesn‘t ensure that you are 100% impregnable, but it will improve the confidence of the decision makers and stakeholders in your organization, as well as the people you do business with.

The best practices I mentioned are critical components of the required documents and records you need to organize and maintain. Many of the documents are policies and procedures that must be taught to staff members and followed on a daily basis.

Here‘s a comprehensive list of the documents you need to comply with ISO/IEC 27001.

Scope of the ISMS (ISO 27001, clause 4.3)

Begin your implementation process with this critical document as it outlines the work to follow. The organization may already have something documented regarding the ISMS, but a revision is a good idea. The document must clearly define the following:

• the information you intend to protect,
• where the information is stored (internal servers, cloud storage, data center, etc.),
• how the information is accessed (interfaces and dependencies),
• who can access the information and at what levels

Another key piece to completing the requirements for the document is identifying the internal and external issues that could influence your ISMS (ISO 27001, clause 4.1). The risk assessment you will perform will provide more context, so you may want to review and adjust your scope after the risk assessment is complete. Be sure to include the information security roles and responsibilities (ISO 27001, clause 5.3), as well as determine the necessary resources (ISO 27001, clause 7.1) and capabilities (ISO 27001, clause 7.2).

Pro tip #1: The Scope can be an independent document, but merging the document with the Information Security Policy and including references to the interested parties (stakeholders) and their requirements will better align the ISMS for the 27001 implementation.

Information Security Policy (ISO 27001, 5.2) and Objectives (ISO 27001, 6.2)

The Information Security Policy is often a misunderstood document in the organization and what to include can be wide ranging depending on the ISMS scope. According to ISO 27001 the primary purpose of the InfoSec policy is for the senior management to define what they want to achieve in regards to securing information and that the ISMS is aligned with the strategic goals of the company. When creating such a document, a best practice is to keep the objectives clear and concise so that they are easily understood by all parties involved.

Pro tip #2: Try not to be too finite with the details in the Information Security Policy, because the majority of the granular details will come in form of other required documentation.

ISO 27001 outlines the following for the document:

• The policy must be specific to the organization, so just like in school, copying someone else’s paper isn’t a good idea.
• The policy must define the framework for setting the information security objectives, including how the objectives are proposed, approved and reviewed.
• The policy needs to state the senior management commitment to meet the requirements of all interested parties and the commitment to continually improve the ISMS.
• Continuous communication of the policy within the organization and to the appropriate interested parties is required.
• Regular review of the policy to keep currant is also required.

Pro tip #3: Assign one influential individual in the organization to be the owner of the Information Security Policy with the responsibility of keeping the document up to date and continuously communicating those updates to all relevant parties.

Methodology for Risk Assessment and Treatment (ISO 27001, 6.1.2)

Where the previous two documents had several more requirements and specifics added in the 2013 revision of ISO 27001, the clause 6.1.2 Information security risk assessment is more generalized than the 2005 version. Basically you can choose to use any methodology you want for the risk assessment, as long as it is documented and consistent throughout the organization. When creating this document be sure to define whether the method is qualitative or quantitative and fulfills the following requirements of clause 6.1.2:

1. How you will identify risks associated with the loss of confidentiality, integrity and availability for information within the scope of the information security management system.
2. How you will evaluate the likelihood and impact of realized risks.
3. How you will calculate the risks in order to ensure that repeated information security risk assessments produce consistent, valid and comparable results.
4. How you will identify the risk owners.
5. How you will establish the risk levels and risk acceptance criteria.

Given these 5 requirements for the risk assessment, choosing a methodology can be a daunting task unless you have significant experience operating under a particular method and furthermore, that method fits with the organization’s business objectives as mentioned previously. Due to this fact, the required methodology from the 2005 version, asset-based risk assessment, which is identifying the risks based on assets, threats and vulnerabilities, continues to be prevalent throughout the industry today.

The 2005 version, as well as the 2013 revision, includes the concept of asset owner as a control in Annex A. Where the two versions differ on this concept is the 2005 requires the identification of asset owners both during the risk assessment process and as control A.7.1.2 in Annex A, but the 2013 revision doesn’t have this requirement in the risk assessment process and only as control A.8.1.2 in Annex A.

The 2013 revision introduces the concept of risk owner, “a person or entity with the accountability and authority to manage a risk” (defined in ISO 27000:2013 and ISO 31000). Some experts believe the risk owner was introduced in 2013 because the asset owners weren’t in positions of authority to resolve potential risks. We believe that assigning asset owners and risk owners creates a cooperative effort for risk mitigation in organizations potentially doubling the efficiency and effectiveness of the work.

Pro tip #4: Accurately assigning risk owners is a vital piece of the risk management process, and therefore should be someone invested in preventing the identified risks from occurring (i.e. stakeholder). The risk owner/stakeholder needs to have the authority to secure the resources required for executing the risk mitigation strategies designed in the risk treatment.

The risk owners are especially important when you begin the risk treatment implementation, because they will most likely be the individuals who determine the acceptable and unacceptable risks. The risk treatment is utilized to treat (manage) the unacceptable risks by:

• Reducing the risk through control implementation
• Transferring the risks to a third party
• Avoiding the risk entirely by stopping or changing a business process or activity
• Accepting the risk for now, possibly because the cost of damage incurred is less than invest

Producing the report(s) for the risk assessment (ISO 27001, 8.2) and the risk treatment are also key ingredients to fulfilling the requirements.

We are Stiki – Information Security Consultancy, the creators of Risk Management Studio, which is a software toolkit built on the foundation of the asset-based risk assessment methodology. We learned the hard way that organizing and executing all the requirements of the properly managed ISMS through a spreadsheet risk management system is extremely tedious and mistake prone.

Since 2005 Risk Management Studio (RM Studio) has been aiding organizations in the management of information security risks and compliance of ISO/IEC 27001 Standard. The RM Studio software application provides an intuitive and easy to use systematic approach for the risk assessment and risk treatment requirements of the ISO 27001 Standard.

Statement of Applicability (ISO 27001, 6.1.3 d)

First, the ISO 27001 Standard includes Annex A, a comprehensive list of 114 information security objectives and controls suggested by the International Organization for Standardization (ISO). Utilizing the Annex A controls, also referred to as ISO/IEC 27002 Standard, which includes the implementation guidelines for each control, is a proven means of mitigating risks, but you may want to supplement additional controls according to the organization’s business needs.

The Statement of Applicability (SoA) is the primary document in the ISMS that identifies the controls applicable to your business and why you are implementing or not said controls for risk mitigation. The SoA is based on the findings from the risk assessment and the risk treatment, where the appropriate controls are assigned to each risk identified in the risk assessment. The SoA document is formed by determining the status of each control along with an accurate justification for the inclusion (implemented or not) or exclusion of each control. The control status options are:

• Implemented – control is in place in the organization and designed to mitigate risks
• Not implemented – control isn’t in place, but the organization plans to implement
• Not applicable – control doesn’t fit in the organization

The Statement of Applicability document is crucial to your success in the certification audit, because the auditor, who expects to see in action what is written in the SoA, while visually inspecting the control implementations in your organization.

Pro tip #5: Performing a gap analysis on the Annex A controls before assigning controls to identified risks is an efficient strategy for determining the status of each control across the organization. Often you will need to implement a single control to mitigate risks threatening multiple assets.

Risk Treatment Plan (ISO 27001, 6.1.3 e, 6.2)

The Risk Treatment Plan is the documented action plan the organization will follow to

This is the purpose of Risk Treatment Plan – to define exactly who is going to implement each control, in which timeframe, with which budget, etc. I would prefer to call this document ‘Implementation Plan’ or ‘Action Plan’, but let’s stick to the terminology used in ISO 27001.

Once you’ve written this document, plan on preparing a summary of your findings for management approval, because without their commitment and money to implement all the controls that you have planned, you won’t be able to complete the ISO 27001 implementation project. And after receiving the management approval or suggested revisions to the plan, prepare for the long road to finish the job.

Stiki – Information Security and Risk Management Studio

Stiki – Information Security’s 23 years as a consultancy and our decade plus work as risk management software engineers has provided us with a vast amount of knowledge and expertise, which we have continuously poured into RM Studio’s software development. Our latest release, available at riskmanagementstudio.com, version 5.1 includes a new feature for document storage and control linking that provides our users with an efficient process for managing these required documents. The new version also includes several other new features including the new web-based extension module for stakeholders, where the risk managers using RM Studio can now assign tasks to the stakeholders via an intranet webpage and monitor the tasks through email notification. For more information visit our latest release notes summary here.