ISO 27001: form-free, but documentation is required

ISO 27001 does not specify how comprehensive your documentation should be, as long as you can demonstrate that your processes work and are being followed. In this blog, we list which documents you need according to ISO 27001:2022 and provide practical tips for each section to keep them workable. You can also use this blog as an ISO 27001 checklist for an internal or external audit.

Compulsory documentation in accordance with ISO 27001:2022

These are documents and registrations that you must have demonstrably. Without this basis, you simply won't get through an audit.

Scope of the ISMS (4.3)

The scope shows which parts of your organization fall under the ISMS. Think of departments, processes, locations, systems and services. This is not only important for the auditor, but will also appear on your certificate. This way, stakeholders can immediately see how far your ISMS reaches. A simple example:

“Information security related to advising, designing, developing, integrating, maintaining and operating mobile and web applications for, among other things, processing personal health information and providing associated external hosting services.”

Make sure the scope is clear and practical so that everyone understands exactly what is being included.

Information Security Policy and Objectives (5.2, 5.3 & 6.2)

Here you define what information security means for your organization. The policy provides direction. Make sure management knows and has approved this policy. Remember that this policy document must also be communicated within the organization and available to relevant stakeholders (if applicable). You can overcome this with a management statement.

In addition, it is important that management periodically obtains and communicates information about the performance of the management system. In practice, this often happens via Q-meetings, periodic IB meetings or management reports. These reports provide input for the management review, as required in chapter 9.3 of ISO 27001. The organization must demonstrate that this information is actually assessed by top management and that these results in decisions or improvement actions.

Risk analysis, risk treatment and risk methodology (6.1.2)

You must be able to show how to identify, assess and treat risks. This is not just about the end result, but also about the method you use. The risk analysis is the core of your entire ISMS. Everything you do must logically result from this. Do you want to know how to do it? You read that here.

Statement of Applicability — 6.1.3D

In the statement of applicability, you specify which measures in Annex A you apply and which you do not, including substantiation. This document is used intensively during audits and must always be up to date. In addition, this document is often requested by stakeholders so that they can see the scope of your certification.

Risk Treatment Plan (6.1.3E)

It states what measures you are taking, who is responsible and when they were implemented or planned. Not everything has to be finished, but you must show that you consciously make choices and have arranged follow-up.

Objectives (6.2)

In addition to the risk treatment plan, your information security objectives must also be available as documented information. These objectives make concrete what you want to achieve with information security and provide direction for improvements. Consider a goal such as: “Reduce the number of security incidents caused by phishing by 30 percent within 12 months” or “All employees undergo annual security awareness training.” Make sure the objectives are measurable, have an owner and are evaluated periodically. This shows that information security is not a one-off action, but part of your business operations.

Certificate of Competence (7.2D)

You must be able to show that the people who are involved in information security know what they are doing. You demonstrate that with concrete documentation. Think of diplomas and certificates, but also training courses, attendance lists, e-learning results or internal knowledge sessions.

In addition, you can include experience: minutes of progress or assessment interviews, project plans someone has participated in, or defined roles and responsibilities within the ISMS. What matters is that an auditor can see: this person demonstrably has the knowledge and experience that suits his or her role.

Operational Planning and Control (8.1)

You record which activities you carry out, who is responsible for them and how often this happens. Think of periodic checks on authorizations so that only the right people have access to systems. This also includes annual components such as the management review and the internal audit. In addition, you can record monthly or quarterly checks, such as a clean desk and clear screen check or a review of log files. By planning and documenting these types of recurring tasks, you show that you structurally control information security and do not become active just before an audit.

Information Security Risk Assessment Results (8.3)

Not only the method, but also the results of your risk analyses must be demonstrable. Auditors want to see that risks are reviewed periodically and not identified once.

Monitoring and measuring results (9.1)

You must show how to measure and monitor whether your information security works. This can be done via KPIs, reports, controls or evaluations.

Internal Audit Program and Audit Results (9.2)

In fact, an internal audit program is your own audit plan. Here you record when you carry out internal audits, which parts of the ISMS you review and who performs the audit. The goal is to periodically check whether your agreements are still correct and whether they are being complied with in practice.

The audit results are the results: findings, areas for improvement and any deviations. You don't have to have everything solved immediately, but you need to show that these points have been recorded, discussed and planned. For example, you really use the internal audit as a preparation for the external audit, instead of as a mandatory check list.

Management review results (9.3)

Top management must be demonstrably involved in the ISMS. The management review shows that risks, performance, incidents and improvements are discussed at board level. You demonstrate that you comply with this by, for example, keeping minutes or interview reports where all parts of the standard are covered.

Anomalies and corrective actions (10.1)

If something goes wrong, you should register and monitor these anomalies. It's not about being flawless, it's about showing that you're learning and improving. Make sure you also have evidence of the results of corrective actions.

Expected documentation (based on ISO 27002/Annex A)

These documents are not literally mandatory, but auditors expect them if they are relevant to your organization and risks.

‍

A.5 Organizational control measures

This chapter is about policy, agreements and responsibilities. Here, auditors mainly check whether you have made clear choices and recorded them. This is set out in the information security policy that we discussed above (5.2).

A.5.9 Inventory of information and other related assets

You make an inventory list of information and other assets (including owners - such as laptops, phones, etc.).

A.5.10 Acceptable Use of Information and Assets

You record how employees interact with information and resources such as laptops, mobile phones and systems. For example, an acceptable use policy that states what is allowed and what is not allowed, such as private use, installation of software, or use of external storage.

A.5.12 Classification of information

This document describes how information is organized based on confidentiality, availability, and integrity. A practical example is a classification scheme with labels such as public, internal, confidential, and strictly confidential, including what that means for storage and sharing.

A.5.14 Transfer of information

You document how information is shared securely, both internally and externally. Think about agreements about encryption, secure e-mail or portals and avoiding unsecured channels. You can link this to your classification policy: how can I distribute confidential or internal documents?

A.5.15 Access Security

This document describes the principles for access to systems and information. For example, the principle of least privilege and the use of strong authentication. In an access policy, for example, you combine the control measures A5.15 and A5.18.

A.5.18 Access rights

Here you specify how access rights are granted, changed and revoked. An example is an authorization procedure upon commencement of employment, change of position, and termination of employment.

A.5.19 Information security in supplier relationships

You document how you deal with suppliers and what security requirements you set. Think of a supplier policy or standard security clauses in contracts.

A.5.23 Information security when using cloud services

For example, a security policy for cloud services explains how to assess and manage cloud suppliers. For example, agreements about data location, backups and exit strategies.

A.5.24/A.5.26 Planning, preparing and responding to information security incidents

You describe how incidents are recognized, reported, dealt with and evaluated. This is often an incident response procedure with an incident register as proof.

A.5.31 Legal, Statutory, Regulatory and Contractual Requirements

You record how to identify and comply with laws and regulations. This includes an overview of relevant legislation such as AVG, NIS2 and contractual obligations.

A.5.32 Intellectual Property Rights

Here you'll describe how to deal with copyright, licensing, and information ownership. For example, agreements about software licenses and the use of content.

A.5.34 Privacy and Personal Data Protection

This document describes how personal data is protected. Examples include a privacy policy, data breach procedure and link to AVG obligations (such as drawing up a register of processing operations).

A.5.37 Documented operating procedures

Here you record how critical processes (related to information security) are carried out. These can be work instructions for management, monitoring or change management.

A.6 Human control measures

This chapter focuses on awareness, responsible behavior and ensuring information security throughout the employment relationship: from inflow to outflow of employees.

A.6.1 Screening

You must specify how employee screening takes place prior to employment. When screening components are used, such as requesting a Statement of Conduct (VOG), the organization must also be able to demonstrate this, for example by establishing screening criteria and proof that the screening has actually been carried out.

A.6.2 Terms of employment

Employment contracts or similar agreements must explicitly focus on responsibilities related to information security. This ensures that employees are aware of their obligations with regard to confidentiality and to handle information safely.

A.6.4 Disciplinary procedure

The organization must have a documented disciplinary process for violations of information security policies. These agreements are often laid down in a code of conduct, employee handbook or employment contract and make it clear what consequences can follow in the event of non-compliance.

A.6.5 Responsibilities after termination or change of employment

Upon termination of employment or change of position, it must be demonstrated that employees have been made aware of their continuing responsibilities with regard to information security. This may be evident, for example, from a letter of resignation, exit statement or other recorded communication.

‍

A.6.6 Confidentiality and Confidentiality Agreements

‍The organization must determine what confidentiality or nondisclosure agreements are necessary to protect information. These agreements must be documented, signed by employees and other relevant stakeholders and reviewed periodically for timeliness and suitability. In practice, this involves confidentiality clauses in employment contracts, separate NDAs or contractual agreements with third parties.
‍

A.6.7 Remote work

The organization documents how employees work safely at home or at remote locations. This includes agreements about the use of VPN, private equipment and physical security of workplaces.

A.7 Physical control measures

This is about protecting physical assets and workplaces.

A.7.7 Clear desk and clear screen

You record how workplaces are left behind, for example in a clear desk and clear screen policy. For example, guidelines for cleaning up documents and locking screens.

A.7.10 Storage media

You describe how physical and digital storage media are managed and disposed of. For example, procedures for destroying hard drives or USB sticks.

A.8 Technological control measures

This chapter is about technical measures and IT security.

A.8.9 Configuration Management

For example, a configuration management policy specifies how systems are set up and managed. A practical example is a baseline configuration for servers and networks.

A.8.10 Deleting information

You describe how information is securely deleted. For example, procedures for deleting data when depreciating equipment.

A.8.13 Information backup

You document how backups are created, tested, and restored. Auditors often want to see proof of backup schedules and test results here.

A.8.15 Logging/A.8.16 Activity Monitoring

You record which events are logged and how logs are reviewed. For example, agreements about retention periods and monitoring.

A.8.24 Using Cryptography

For example, you set up a cryptography policy that states how and when encryption is applied. Think of laptop encryption, backups and data traffic.

A.8.25 Securing during the development cycle

When you develop, describe how security is included in design, construction and testing. For example, you describe code reviews and security tests in a software development policy.

A.8.27 Secure System Architecture and Technical Principles

You document the principles for secure IT architecture. Think network segmentation, redundancy, and minimal internet exposure.

Tip for all ISO 27001 documentation

ISO 27001 does not require as many documents as possible, but for documentation that matches your organization and risks. You must be able to live up to everything you write down. And you have to be able to prove everything you do.

Are you unsure whether your documentation is sufficient for certification? Then an ISO 27001 check or internal audit is often the fastest way to gain insight. This will immediately show you where you are already in the right place and where you can still take steps towards a certification such as ISO 27001. Schedule an informal, free consultation below.

‍