ISO 27001 mandatory documents and records (clause 7.5)

Which ISO 27001 mandatory documents and records must you produce before certification?

ISO 27001 requires documented information under clause 7.5, and a certification body will expect to see named records such as the Statement of Applicability, the risk treatment record and the information security policy before it audits anything. The organization owns, writes and maintains these documents. An accredited certification body only audits them and, if the system conforms, certifies it. Consultants and implementation partners can draft and organize the material, but the signed decisions inside it must come from your own management. The exact set depends on your scope, your risk assessment results and the controls you chose. Clause 6.1.3 d) ties the Statement of Applicability to the risk treatment process, so every control you include or exclude needs a justification that traces back to a risk. Clause 7.5 has three subclauses: general requirements, creating and updating, and control of documented information. Together they cover what you must create, how you format and review it, and how you keep it available, versioned and protected. Confirm with your certification body how it wants the scope statement and the risk records presented, since requirements for presentation vary.

The 93 Annex A controls in the 2022 edition go further than the required list. Controls such as A.5.37, which asks for documented operating procedures for information processing facilities, generate runbooks, change records, access reviews and log extracts that auditors sample during an audit. Plan these as a second layer of evidence rather than an afterthought. Decide early which system will hold each document and record, who approves changes to it, and how old versions are retained. Ask your certification body and any prospective implementation partner to show you a sample document set and an evidence index before you sign a contract. That review usually reveals gaps in ownership and version control faster than any readiness checklist.

Which documents ISO 27001 names, and where each one is required

ISO 27001 does not hand you a fixed list of documents. Each requirement names the information it needs, and the auditor traces those requirements back to a document or record. The six cards below cover the items auditors ask for first, with the clause that requires each one.

Statement of Applicability

The Statement of Applicability is required by clause 6.1.3 d). It lists each Annex A control, states whether it is applied or excluded, and gives the reason and current implementation status for each. Auditors compare it against your risk treatment decisions, so every exclusion needs a stated reason tied to a risk. Confirm that the version in circulation matches the latest approved revision and carries an owner and date.

Information security policy and topic policies

Clause 5.2 requires an information security policy, and Annex A.5.1 asks for topic-specific policies approved by management. Auditors check that these are approved, published, communicated to relevant personnel and interested parties, and reviewed at planned intervals and after significant changes. Ask for evidence of acknowledgement, such as sign-off records, and confirm each policy names an owner and a review date.

Risk assessment and risk treatment records

Clauses 6.1.2 and 6.1.3 set the rules for risk assessment and risk treatment, and clauses 8.2 and 8.3 require them to be carried out in operation. Auditors look for a risk register showing identified risks, assessed levels, chosen treatments, and risk owners, plus evidence that the assessment was repeated. Check that results from the risk treatment plan feed into the Statement of Applicability.

Operating procedures

Annex A.5.37 asks that operating procedures for information processing facilities be documented and made available to the staff who need them. Auditors sample procedures such as backup, change, and access provisioning, then ask who can reach them and whether they match current practice. Confirm each procedure has a version, an owner, and a clear location that the people running the task can access.

Internal audit and management review records

Clause 9.2 requires an internal audit programme, and clause 9.3 requires management review with defined inputs and results. Auditors ask for the audit schedule, the audit reports, the auditor selection rationale, and minutes that show management reviewed performance and decided actions. Check that the records show who attended, what was reviewed, and which decisions were recorded.

Nonconformity and corrective action records

Clause 10.2 requires you to react to nonconformities, correct them, deal with consequences, and review whether the corrective action worked. Auditors trace a sample of nonconformities from audit findings through root cause analysis to closure. Confirm each record shows the cause, the action, the responsible owner, and the evidence that the fix was effective, not only that a ticket was closed.

How to build a Statement of Applicability that auditors accept

The Statement of Applicability (SoA) is the document that shows which Annex A controls your organization has selected, why each one is included or excluded, and where each included control stands in implementation. It is required by clause 6.1.3 d) of ISO/IEC 27001:2022, which sits inside the risk treatment process. For every Annex A control, the SoA needs three things: whether the control applies, the justification (a risk it treats, a legal or contractual obligation it meets, or a documented reason it does not apply), and the implementation status. Auditors read the SoA first because it is the map they use to pick samples for the rest of the visit.

The SoA has to trace back to your risk treatment decisions. Each included control should link to one or more risks in your risk register and to the treatment option chosen for that risk, and each risk treatment should point to controls that address it. Auditors commonly raise findings where a control is marked as implemented but no risk supports it, where an exclusion has a weak or missing justification, or where the SoA lists a control that the operating records do not show. Before sign-off, run a two-way check: start from each risk and confirm its controls appear in the SoA, then start from each SoA entry and confirm a risk or obligation explains it. Confirm with your certification body how it expects the SoA version, approval date and change history to be presented, because requirements for those details vary by assessor.

The organization owns the SoA and its approval. Someone with authority over the ISMS, usually an executive named in your policy, must review and approve it, and the approval must be recorded under your document control process. An implementation partner or consultant can draft the SoA, propose justifications and map existing evidence to each control, but it cannot approve the SoA or accept residual risk on your behalf. Ask any partner to show, in writing, which decisions remain with your staff, and keep the approved version, its prior versions and the reasons for each change where the documented information is held.

How to version, approve and publish documented information

This sequence turns a draft document into a controlled, approved and published version that people use, and it keeps a clear trail of which version was in force at any point. It is the working method behind the control requirements in clause 7.5.

Assign a named owner and draft the document
Before drafting starts, record a named owner for each document. The owner is the person accountable for its accuracy and currency, usually someone who runs the process or system it describes. The owner drafts the content, gives it a document identifier and a version number such as 0.1, and records the purpose, scope and intended audience. Done means the draft sits in the controlled repository with its owner, identifier and status set to draft.
Check the draft against the risk assessment
Reviewers compare the draft with the risk assessment and risk treatment records to confirm that each risk the document relies on is addressed and that the controls it describes match those in the Statement of Applicability. Gaps go back to the owner as tracked comments. Done means the reviewer has recorded that the draft is consistent with the risk treatment decisions, and any open points are logged against the draft.
Obtain approval from the accountable role
The approver is the role with authority over the subject. Information security policies are normally approved by top management, while operating procedures are often approved by the manager of the process they govern. The approver reviews the final draft and records the decision, the approval date and the version number. Done means the document carries an approved version with a date and the name or role of the approver, and the approval is stored with the document history.
Publish to the people who need it
Publish the approved version to the location where the affected personnel and relevant interested parties can find it, and make sure it is not hidden behind access that excludes them. Notify the audience of the change and, where the policy calls for it, collect acknowledgements. Confirm the publication location is the only one people use, so that no stale copies circulate. Done means the publication date is recorded, the notice has gone out, and acknowledgement records exist for the audience that must acknowledge.
Schedule the periodic review
Set a review date for each document, based on the organization's own review cycle and the need for the content to stay accurate. The owner is reminded before the date, and the review checks whether the content still matches current systems, roles, risks and the Statement of Applicability. Done means the review is either recorded as unchanged with a new review date, or it triggers a new draft that starts the sequence again.
Update after significant change
Changes to the organization, its technology, its suppliers, its legal obligations or its risk picture can make a document inaccurate before its scheduled review. When such a change happens, the owner raises an update and the document returns to drafting. The change is linked to the trigger that caused it, such as a new system or a risk treatment decision. Done means the updated draft records what changed, why, and which trigger prompted it.
Retire superseded versions
When a new version is approved and published, the earlier version is withdrawn from the working location and marked as superseded, with its effective period recorded. Retained copies are kept for the period the organization sets, so that auditors can see which version applied at a given time. Done means only the current approved version is visible to users, and the archive can show what was in force on any past date.

Where to keep ISMS documents: wiki, document repository or GRC tool

A wiki suits teams that want policies, procedures and risk records written as linked pages that anyone with access can read and edit. XWiki, licensed under LGPL-2.1-or-later, is an example of this model that you can run inside your own infrastructure, so ISMS content stays under your control. Its version control is the feature most relevant to clause 7.5.3, because the platform keeps every change to a page and lets you compare versions and roll back to an earlier one.

Change history: Each edit records what changed, when and by whom, which gives you the change trail an assessor will ask to see for a policy or the Statement of Applicability.
Version comparison: Reviewers can compare any two versions side by side to confirm what changed between approved revisions.
Rollback: Restoring an earlier version is possible, but the rollback itself should be governed by an approval step you document, so restoration is not mistaken for an unapproved edit.
Access control: Permissions are set per space or page, so you can separate who edits policies from who only reads them. Confirm the exact rights model in the current release against your own access design.
Approval workflow: Wikis do not necessarily enforce review and sign-off on their own, so plan the approval record separately if you need it.

Before you commit, confirm the current release's version history, permission model and export options against your own access and retention requirements.

What certification auditors check in your document set

Auditors do not grade the prose of your policies. They sample documents and records and test whether they agree with each other, carry clear version and approval history, and match what staff and systems actually do. The six checks below are the ones that most often decide whether a document set passes at the first audit visit.

Consistency across the SoA and risk treatment

The Statement of Applicability required by clause 6.1.3 d) must match the risk treatment plan and the policies it cites. Auditors pick a Annex A control marked as applied, then trace it back to a risk, a treatment decision and a written policy or procedure. A control marked as applied with no matching risk entry, or a risk with no treated outcome, is a common finding. Check that every justification in the SoA points to a document that exists.

Version control and approval dates

Auditors check that each policy and procedure shows a version, an owner, an approval date and the approver's name or role. They look for a change history that matches the approval dates, so a v2.1 policy with an approval date before the v2.0 change signals a broken process. Confirm that superseded versions are retained or archived and that the current version is the only one shown to staff.

Staff access to current procedures

A.5.37 expects operating procedures to be documented and available to personnel who need them. Auditors may ask a system administrator or service desk analyst where the current procedure lives and then open it. They check whether the link works, whether the document is the approved version and whether access rights match the roles that need it. Ask a non-specialist on your team to find one procedure during your own readiness check.

Records retained across the certification cycle

A certification cycle lasts three years, with at least one audit in every calendar year under ISO/IEC 17021-1. Auditors expect records such as internal audit reports, management review minutes, risk assessment outputs and corrective action logs to exist for the period they cover. Confirm your retention rules, since a record that was deleted or overwritten before the next visit cannot be shown as evidence. The certification body will confirm the exact sampling period in its audit plan.

Document changes after nonconformities

When an earlier audit or internal audit raised a nonconformity, auditors check that the related document changed in a traceable way. They trace the corrective action under clause 10.2 to a revised policy, procedure or record with a new version and date. A corrective action that closes a finding but leaves the old document unchanged will be questioned. Look for a link from each nonconformity record to the document it affected.

Audit method and certification body procedures

Auditors plan sampling using the guidance in ISO/IEC 27007 and the certification body's own procedures, which apply the audit principles of ISO 19011. Sampling choices vary by auditor and by risk, so you cannot predict which documents will be selected. Ask your certification body for its audit plan and its document request list before stage 1, and confirm which version of ISO/IEC 27006-1 it applies to your certification.

Who owns the documents, who drafts them and who checks them

Your organization owns every document and record in the ISMS. Management approves the information security policy and the Statement of Applicability, and the people who run each process are accountable for the procedures and records they produce. Clause 7.5 expects you to decide what documented information is needed, how it is created and updated, and who may read, change or retain it. No outside party can make those decisions on your behalf, and an auditor will ask staff directly how they use the documents.

Approval and ownership: Name an owner for each policy and procedure, and record who approved each version and when.
Statement of Applicability: Management must sign off the SoA, including the justification for every Annex A control included or excluded.
Records in daily use: Risk assessment results, internal audit reports, management review minutes and corrective action records are created by your staff during operation.
Access decisions: Your administrators set who can view, edit and approve each document, and they keep the access list current as people join and leave.
Review cadence: Staff schedule and carry out reviews at planned intervals and after significant changes.

Before accepting any draft, confirm that each named owner understands the document and can show it operating in practice.

Document problems that delay certification

Auditors rarely fail an ISO 27001 certification because a document is missing. They find documents that contradict each other, cannot show who approved them, or cannot prove when they were written. The six problems below are the ones that most often turn into nonconformities, and each has a preventive check the organization can run before the audit.

Statement of Applicability out of step with treatment

The Statement of Applicability is required by clause 6.1.3 d), so it must record each Annex A control, whether it is applicable, and why. A common failure is an SoA that marks a control as implemented while the risk treatment plan assigns that risk to a different control or to nothing. Before the audit, trace every risk in the treatment plan to at least one SoA entry, and check that each control marked as applicable points to an owner and to evidence that exists today.

Policies approved by no one with authority

Control A.5.1 expects the information security policy and topic-specific policies to be approved by management, published, communicated and acknowledged. Auditors often find policies signed by a project lead or left in draft with an approval field blank. Record the approver's name and role on each policy, keep the approval in the document history, and confirm that the approver holds the authority to commit the organization to the policy.

Duplicate copies across tools

When the same procedure lives in a wiki, a shared drive and an email attachment, staff follow whichever copy they find first, and the versions drift apart. Auditors look for one controlled source for each document and ask staff which copy they use. Choose a single system of record, retire other copies with a pointer to the controlled version, and verify that the copy staff open during an audit walk-through is the approved one.

Undocumented exclusions

Any control excluded from the SoA needs a written justification, and the exclusion must not conflict with the risk assessment or with what the organization actually does. Teams often exclude controls by omission, leaving no reason on file, or exclude a control whose underlying risk is still open. Review each exclusion against the risk register, record the reason in the SoA, and have the risk owner sign off the change.

Records created retrospectively with backdated dates

Risk assessment reports, management review minutes and internal audit reports must show when they were produced and by whom. Records written weeks after the meeting, or edited to carry an earlier date, are a serious integrity problem because the auditor cannot verify the timeline. If a record is late, say so in the document and keep the actual creation date. Keep the version history intact so the true sequence of events remains visible.

Approved versions editable by everyone

Clause 7.5.3 expects documented information to be protected from loss of integrity, and approved versions need write access limited to named owners. When every staff member can edit the approved policy, the auditor cannot be sure the text they read is the text management approved. Restrict edit rights to document owners, keep approvals as a separate step, and review the access list at each planned review. Self-hosted wikis such as XWiki keep a version history that supports this check.

Questions buyers ask about ISO 27001 documents and records

Which ISO 27001 documents are mandatory and which are only recommended?

Clause 7.5 requires documented information wherever the standard says so, and several items are named explicitly, including the Statement of Applicability required under clause 6.1.3 d), the information security risk treatment process, and the records of risk assessment and treatment results. Annex A adds its own explicit requirements, such as an information security policy and topic-specific policies under A.5.1 and documented operating procedures under A.5.37. Everything else is a judgment call: the organization decides what it needs to show that the management system works. The certification body decides whether the set is sufficient. Confirm the exact list against the standard itself and ask your certification body to walk through it before you write anything.

Can a small team maintain the ISO 27001 document set without a consultant?

Often yes, but the effort depends on how many systems, suppliers and locations the scope covers. A small team usually needs one named owner for the document set, a short list of policies that match how the company actually works, and a simple way to show approval, review dates and version history. The parts that must stay in-house are the decisions: the risk criteria, the risk treatment choices, the Statement of Applicability and the management review. A consultant can speed up drafting, but a document that describes controls nobody operates will fail at audit. Ask a consultant to show you the draft documents they would produce and check who will maintain them after the engagement ends.

How long does the document work take, and what drives the effort?

No duration is fixed by the standard, so the effort is driven by the factors you control. The main drivers are the size and complexity of the scope, how many systems and suppliers the procedures must cover, how much of your current practice is already written down, and how many approval rounds your leadership requires. Documents that describe real, existing practice take less time than documents that invent a process first and then need to be operated. Build the timeline from your own scope and ask any implementation partner for a written plan with named deliverables before work starts.

Is a wiki enough to hold ISO 27001 documented information?

A wiki can meet clause 7.5 if it provides what the standard asks for: controlled creation and update, identification of approved versions, retention of older versions, and restricted access to the people who need it. Tools such as XWiki keep page versions with a record of what changed, when and by whom, and let users compare and roll back versions. BookStack offers an audit log for administrators that can be filtered by activity and date range. Neither product decides the control design for you. Confirm with your certification body how it will check approval, version identification and access, and test a restore and an access review before the audit.

How often must ISO 27001 documents be reviewed?

ISO 27001 does not set one review interval for every document. Policies under A.5.1 must be reviewed at planned intervals and after significant changes, and the organization sets those intervals. Operating procedures under A.5.37 need to stay accurate as systems change, so their review is tied to change activity. The Statement of Applicability should reflect the current risk treatment decisions, so it changes whenever those decisions change. Document a review schedule, record each review, and confirm with your certification body that the intervals you chose are defensible for your risk profile.

Can a partner write the Statement of Applicability for us?

A partner can prepare a draft, but the organization must own the decisions in it. The Statement of Applicability records which Annex A controls apply, why, and how each one is implemented, which follows from your risk assessment and risk treatment. A partner that drafts it still needs your leadership to approve the content, and your team must be able to explain every exclusion to an auditor. DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports or certificates. Confirm with your certification body that it accepts a drafted Statement of Applicability, and keep the approval record yourself.

Who checks whether the document set is good enough for certification?

Only the accredited certification body does. It tests the documents during the audit, looking at whether they match the systems in operation and whether the records prove the processes ran. Your consultant or implementation partner can check readiness, and your internal audit under clause 9.2 can find gaps, but neither issues a certificate. Ask your certification body which documents it will request at stage 1 and which samples it will check at stage 2, and make sure the answer is in writing.

How DeployOpen prepares your document set and evidence

DeployOpen prepares the document set and records that clause 7.5 expects, inside your own infrastructure, so your team can show how documented information is created, approved, versioned and controlled. We prepare systems and evidence; your organization owns the policies, the Statement of Applicability and every decision in them, and an independent certification body decides whether the ISMS is certified.

How we scope

We agree in writing which documented information is in scope, including the Statement of Applicability, policies, operating procedures and risk records.
Engagements are fixed-scope, so deliverables, responsibilities and timelines are fixed before work starts.
We confirm which self-hosted platforms will hold documents, and who in your organization approves each document type.

How we build

We configure a self-hosted wiki or documentation platform with approval workflows, owners, review dates and access groups for each document class.
We set up version history so every change to a policy or procedure records what changed, when and by whom.
We draft document templates for the Statement of Applicability linkage, risk records and internal audit records, for your owners to review and adopt.

How we hand over

We deliver a document register that lists each controlled document, its owner, version, review interval and location.
We hand over access control settings, audit log configuration and a short runbook so your team can operate the platform.
We document how records are retained and where evidence for each clause 7.5 expectation can be found during an audit.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
We can review document changes and access logs with your compliance lead before a certification body visit, if that is in the written scope.
Questions about certification bodies, audit timing or certificate scope are referred to the organization and its chosen certification body.