Each organization is unique in its security needs and capabilities, and ISO 27001 does not seek to change that fact. The standard guides the adoption of appropriate processes and practices to improve, clarify, and maintain information security as an integral part of day-to-day operations. By documenting the existence of these actions and promptly acting on them, the demonstration of compliance becomes pretty straightforward.
Understanding the context of the organization is a very first step. External and internal issues and stakeholders must be identified and the role of these entities assessed, as parts of the wholeness. The requirements may also include industry-specific regulation and beyond that — national, European-wide or even international legislation.
In this article we highlight the key requirements of the ISO 27001 security standard, as well as the mandatory documentation that a company must have and act on, in order to gain a formal certification status. There are two main types of documentation: formal documentation, which is directly required by ISO 27001, and then organization-specific documentation, which the company itself has identified as necessary for the effectiveness of its own information security management system. The latter type of documentation can also be called organization’s own requirements.
This blog post focuses specifically on the formal documentation required by the ISO 27001 standard.
Defining the scope
Perceiving the scope of the information security management system requires a description of the products and services produced by the organization (“What is it that we do?”) and where they are being produced. In practice, documentation of the scope means determining the information that needs to be protected.
This document is typically a brief one. Its contents can also be incorporated to a security policy, thereby eliminating the need to maintain a separate document. In most cases, the scope covers the entire organization and all physical locations — however conditions exist where it is impractical or even impossible for a particular process, system or part of the organization to be thoroughly covered.
The scope definition also defines systems, processes and other assets that are left outside the scope. Outscoped elements include those that the organization cannot control (such as certain tools provided by third parties) or have access to the their confidential information.
Information security policy
The information security policy is a concise statement made by the top management, stating that the organization is committed to operating within common rules and constraints, to process its own and information handed over to it in a secure manner, and of the will to act and implement the principles of continuous improvement. The information security policy also contains concrete security objectives that all security work aims to achieve. This document serves as a cornerstone for other, lower-level policies such as the access control and remote work policies.
In addition to writing the information security policy, it is also an integral part of the whole that its contents are communicated throughout the organization and to all relevant parties.
Organizational roles, responsibilities and authorities
This document describes the information security related roles that exist in the organization, as well as their corresponding responsibilities and authorities for information security tasks and functions. In a certification audit, a typical expectation is a clear-cut organization chart with high-level responsibilities and authorities for each role. External roles and responsibilities are defined in agreements (or agreement annexes) with each external party. A more detailed and lower description of roles and corresponding descriptions is part of organization’s own requirements.
Access control policy
Access control policy contains documentation regarding the organization’s data access control rules, rights and restrictions. The document can deal with business requirements for the permitted use of certain data and information systems or also, for example, the technical side of electronic access control. The contents can be applied to logical or physical access controls – however, ISO 27001 recommends that these two categories be considered together.
Inventory of assets
In the context of ISO 27001, an asset means “anything that has any value to the organization.” This includes equipment, software, processes, buildings, machinery, contracts, partners, outsourced services, taxi cards — the list could go a long way. All assets must be identified and listed (hint: this will in any case be done in the context of information security risk assessment, so the necessary information should be directly available through it.) Any asset can in some way affect confidentiality, integrity and availability, so they need to be included in this document.
Supplier security policy
The security of confidential information cannot be guaranteed, if the unsecure practices of a subcontracting supplier partner expose information to theft or complete destruction. Subcontracting chains can extend beyond several levels and therefore a wide range of control measures are required.
The supplier security policy document defines how potential suppliers are selected and screened, how supplier-related risk assessments are performed, what security clauses are included in contracts, how compliance or non-compliance is monitored and enforced, how contracts are amended, how suppliers are removed access to systems at the end of contract periods, and so on.
It is a good idea to reflect supplier relationship management with certain realities. A dictated-style policy that throws all responsibilities off the buyer’s shoulders does not promote supplier relationships. Similarly, a small company is not very easily able to dictate policies to a significantly larger supplier — even if in the role of the paying customer.
It is desirable to seek and establish collaborative practices that promote and maintain close relationships with suppliers who have access to classified information. Not to be forgotten that some suppliers have little or no impact on overall security; it is worth focusing primarily on those suppliers that are highlighted in the risk assessments.
Business continuity procedures
As a minimum requirement, this documentation must cover how security breaches, disruptions and significant changes to business operations should be handled. In practice, the organization must create, document, implement, and maintain processes to ensure business continuity. During a formal audit, theoretical examples of various disturbances may be presented and the documentation must cover the effective steps to ensure continuity of operations.
Statement of Applicability
Also known as SOA, the Statement of Applicability is one of the most relevant documents of the ISO 27001. It is a practical guide for the implementation of all security plans for an organization. SOA determines which security controls fit into the organization’s management system and how the controls are implemented. Respectfully, it is also determines which controls will not be introduced, along with an exhaustive justification for doing so.
That's not all, folks
In addition to the documents reviewed here, there are a handful of mandatory documents that are required for ISO 27001 certification. Additionally, records must be kept of e.g. training, skills, experience and qualifications, results of the management review and logs of user activities, exceptions, and security events.
This list of documents may seem longish, but at the outset it is often noticed that lots of this material already exists in organizations. At the beginning of the certification process it is crucial to carefully identify any possible shortcomings and gaps in the processes and current documentation, and to create a clear plan of what still needs to be done in order for the certification to succeed fluently.
Case: How we helped kicker.cloud achieve ISO 27001 certification
This is a case-study about the certification path of kicker.cloud, a very small startup company, its SaaS product and high ambitions aiming towards a global market. kicker.cloud encountered the same issues so many others have faced before and will in the future – the dreaded procurement Excel-sheets with seemingly endless amounts of security requirements that need to be addressed before any business deals can go ahead.
3rd party library management – SCA – various frameworks and requirements
Yhä useampi standardi, viitekehys ja asiakasvaatimus edellyttää – peräti huutaa – kirjastonhallinnan perään. Huutaa siksi että modernit sovelluskehitysmenetelmät ovat täysin riippuvaisia ulkoisista kirjastoista eli riippuvuuksista.
Practical guidance on risk in the context of ISO 27001
Within the context of ISO 27001, risk comes up as a topic all over the place. The standard itself, as most of ISO standards nowadays
Internal audit – Using internal or external resources?
As part of the ISO/IEC 27001 certification process, organizations must conduct regular internal audits to ensure compliance and identify areas for improvement. One common dilemma faced by businesses is whether to conduct these audits internally or engage an external company to do it.
