The ISO 27001 certification, policy by policy

At some point during its activity, perhaps depending on size or maturity level, or rather based on industry requirements or customer requests, a company might decide to implement an ISMS (Information Security Management System) and obtain the ISO 27001 certification. This marks the beginning of an empowering, although intimidating journey.

Why empowering?

Going through an ISO 27001 implementation means that people in your company must work closely together towards that end, as most everyone will need to be involved in the process at one stage or the other. Across departments, team members will have to question their processes and their day-to-day work to make sure they are doing the right thing in the right way from a security perspective. Some things may need to change, which means that employees will have to take part in security awareness training sessions. Others will be involved in evidence collection: can your company prove that it is operating securely? One thing's for sure: everyone in the company will have to CARE. It is empowering and meaningful to care about your place of work and the people you serve as a business.

Why intimidating?

If you've never dealt with regulatory standards before, you might find the text hard to distill in terms of “to-do items" — it's not necessarily vague, but not that specific either. Its purpose is to offer guidelines that are general enough to encompass the particularities of each organization. The standard references quite a few documents that the company may need to create from scratch and then adhere to. On top of it all, the entire process ends with an audit, which means that an external entity will analyze your work and judge its value.

There's help out there!

There are many comprehensive resources available regarding ISO implementation, and all of them will point to documents that need to be created — be it policies, procedures, or other lists and registers. It's important to understand that some of them will be mandatory for ANY organization getting certified, while others will be mandatory only for some, depending on identified risks. Keep in mind that some of these policies might exist in your organization even before considering implementing the standard.

Below is the list of documents that any organization must create:

• ISMS scope document (cl. 4.3)
• Information Security Policy (cl. 5.1, 5.2, 5.3, 6.2)
  • defines how security objectives will be set, and it may include the objectives themselves
  • should include roles and responsibilities
• Risk assessment process definition (cl. 6.1.2)
  • describes how risk assessment is done
• Statement of Applicability (cl. 6.1.3)
  • for each control from the Annex, the company must state whether it applies to them or not
• Risk treatment process (cl. 6.1.3)
  • describes how addressing risk is done

Then there will be the documented results of performing certain actions:

• Risk assessment results - performed regularly (cl. 8.2)
  • contains the results of the risk assessment
• Risk treatment plan - performed regularly (cl. 6.1.3, cl. 8.3)
  • contains the plan to address identified risk
• Evidence of competence of persons doing work that affects information security performance (cl 7.20)
• Evidence of monitoring and measurement results (cl 9.1)
• Evidence of audit results (9.2)
• Evidence of the results of management reviews (9.3)
• Evidence of nonconformities encountered and subsequent actions taken; evidence of the results of any corrective action (cl 10.1)

And then there's the Annex

The risks identified during risk assessment can and should be addressed with controls provided by the Standard in Annex A. As some of these controls mandate that other policies, procedures, or documents are created, we can conclude that these will only be required when they help mitigate an identified risk. These additional documents are:

• Mobile device policy (A.6.2.1)
• Teleworking (Remote working) policy (A.6.2.2)
• Disciplinary process (A.7.2.3)
• Inventory of assets (A.8.1.1)
• Acceptable use of assets (A.8.1.3)
• Information labeling policy (A.8.2.2)
• Handling assets policy (A.8.2.3)
• Management of removable media policy (including disposal of media) (A.8.3.1)
• Access control policy (A.9.1.1)
• User access management policy (A.9.2.1, A.9.2.2, A.9.2.4)
• Use of cryptographic controls policy (A.10.1.1)
• Use, protection and lifetime of cryptographic keys (A.10.1.2)
• Working in secure areas (A.11.1.5)
• Clear desk and clear screen policy (A.11.2.9)
• Operating procedures (A.12.1.1)
• Backup policy (A.12.3.1)
• Installation of software policy (A.12.5.1)
• Information transfer policy (A.13.2.1)
• Secure development policy (A.14.2.1)
• Change control procedures (A.14.2.2)
• Secure systems engineering policy(A.14.2.5)
• IS Policy for supplier relationships (A.15.1.1)
• Information Security incidents response policy (A.16.1.1, A.16.1.5)
• Information security continuity policy (A.17.1.2)
• Legislation and contractual requirements (A.18.1.1)
• IP (A.18.1.2)

If you're a company that's just beginning to consider developing an ISMS and getting certified, you might need help creating some or all of these documents. Cyscale offers quite a few of them out-of-the-box, giving you the possibility to use them as templates and add customizations to your needs, or to just use them as they are.

Easy & continuous compliance for ISO 27001, with a set of battle-tested policies to jumpstart your ISMS

Photo by Scott Graham