ISO 27001 Documents Checklist: Policies, the Risk Register and the Statement of Applicability

An ISO 27001 certificate rests on documents and records that prove your security system is real, not claimed. ISO/IEC 27001:2022 names those documents in clauses 4 to 10, and the Statement of Applicability records which of the 93 Annex A controls you use. Get those right, and the audit becomes a check of evidence you hold.

I have watched small IT companies walk into a Stage 1 audit with a 200-page policy pack they bought online and nothing else. The auditor flips through it, asks for the risk register, and the room goes quiet. The policy pack was never the problem. The missing link was the chain from risk to control to evidence, and that chain lives in a handful of documents. This guide lists them, clause by clause, and tells you what each one must actually contain.

What does ISO 27001 mean by "documents"?

The standard talks about "documented information", not about a fixed number of files. Some of it you maintain — policies, procedures, plans that guide work. Some of it you retain — records that prove work happened, like audit reports and review minutes. An auditor tests both halves. A policy nobody follows is a finding. A control everyone follows but nobody recorded is also a finding, because the auditor cannot verify it.

One more distinction matters before you open a blank document. Clauses 4 to 10 are mandatory for every certified organisation. You cannot skip a clause and explain it away. Annex A is different: it is a catalogue of 93 controls you choose from, based on your risks. The document that records those choices is the Statement of Applicability, and we come back to it below because it causes more audit findings than any other single file.

The current edition is ISO/IEC 27001:2022, published in October 2022. The transition from the 2013 edition closed on 31 October 2025, so a new certification today is assessed against the 2022 edition. If a toolkit or template you bought still cites the 2013 clause numbers or the old 114-control list, set it aside. It will send you down the wrong checklist.

The core set: seven documents every auditor asks for first

Start here. If these seven are solid, the rest of the audit is a conversation. If any one is missing, expect a nonconformity.

1. The scope of the ISMS (clause 4.3)

The scope states exactly what the certificate covers: which locations, teams, systems, services and interfaces sit inside the system, and what sits outside it. A SaaS company might scope "the cloud-hosted product platform and the engineering and support teams in Bengaluru", and leave a separate consulting arm outside. Vague scopes fail. "The whole company" fails too, when the auditor finds a team nobody assessed. Write the boundaries so a stranger could draw them, and record any exclusion with its reason.

2. The information security policy (clause 5.2)

This is a short, top-management-approved statement of direction: what security means for your business, and the framework for setting security objectives. Two pages beat twenty. The auditor checks three things: top management approved it, staff can find it, and it is available to interested parties where appropriate. A policy signed by nobody, or one that promises controls you do not run, hurts more than a plain one that matches reality.

3. The risk assessment process (clause 6.1.2)

This document defines how you assess risk, repeatably: the method, the scales for likelihood and impact, and the criteria for accepting a risk. Repeatability is the point. If two people running the same method on the same system reach wildly different answers, the method is broken. Keep the scales simple — three or five levels each — and define each level in plain words, not numbers alone.

4. The risk treatment process (clause 6.1.3)

Once risks are scored, this document says how you choose a treatment: avoid it, transfer it, mitigate it with a control, or accept it. It also requires you to check your chosen controls against Annex A, so nothing gets missed by accident. The treatment decision for each risk needs a named risk owner and that owner's acceptance of whatever risk remains after treatment. An unsigned treatment plan is a draft, not a decision.

5. The Statement of Applicability (clause 6.1.3 d)

The SoA lists every one of the 93 Annex A controls, states whether each applies to you, gives the reason, and records whether it is implemented. It is the document auditors open earliest and read hardest, so it gets its own section below.

6. The risk treatment plan (clause 6.1.3 e–f)

The plan turns treatment decisions into dated work: what will be done, who owns it, and by when. It also records that risk owners approved the plan and accepted the residual risks. A risk register full of high risks with no plan and no dates reads as a list of worries, not a system.

7. Information security objectives (clause 6.2)

Objectives must be measurable, monitored, and tied to the policy. "Improve security" is not an objective. "Close all critical vulnerabilities within 14 days of release, measured monthly" is. Two or three honest objectives beat a page of slogans, because the auditor will ask for the monitoring results at the next review.

The records that prove the system actually runs

Documents say what you intend. Records say what happened. Clauses 7 to 10 require you to retain evidence across the whole cycle:

• Competence evidence (clause 7.2) — training records and role assignments showing people can do the security work assigned to them.
• Risk assessment results (clause 8.2) and risk treatment results (clause 8.3) — the outputs of each assessment cycle, kept so trends can be compared.
• Monitoring and measurement results (clause 9.1) — the numbers behind your objectives, reviewed on a schedule you set.
• Internal audit programme and results (clause 9.2) — your own audits, run before the certification body arrives, with findings tracked to closure.
• Management review results (clause 9.3) — minutes showing top management reviewed the system, its performance, and its resourcing.
• Nonconformity and corrective action evidence (clause 10.2) — what went wrong, what you changed, and proof the change worked.

Notice the pattern. Every record answers a question the auditor will ask anyway: who did it, when, with what result, and what changed next. If a file cannot answer those four questions, it is decoration.

What is a Statement of Applicability, really?

Think of the SoA as the blueprint of a house you are building from the standard's plan. The plan shows 93 rooms. Your blueprint marks each one: built, in progress, or deliberately left out — and for every room left out, it says why. No basement in a flood plain? The blueprint says so. No swimming pool because the plot has no space? The blueprint says so. An auditor does not mind a house without a pool. An auditor minds a blueprint that pretends the pool exists, or one that never mentions it at all.

Annex A holds those 93 controls in four themes:

Three SoA mistakes show up again and again. First, controls marked "applicable" with no implementation evidence behind them — the auditor samples one and finds nothing. Second, controls marked "not applicable" with a one-word reason like "N/A", which explains nothing. Third, an SoA copied from another company, whose exclusions describe a business you do not run. Write each justification in one honest sentence tied to your own risks, and keep the SoA live: when you adopt a new tool or drop a service, update the affected rows the same week.

Which control-layer documents do auditors sample most?

Beyond the core set, Annex A controls each carry their own documented information — but only for the controls you include. You do not write 93 procedures. You write the ones your SoA commits to. In practice, auditors sample these first:

Topic-specific policies under A.5.1, which sit beneath the main policy and cover subjects like access control, supplier relationships, and incident management. The asset inventory under A.5.9, because an auditor cannot test protection of assets nobody listed. Access control rules under A.5.15, and the supplier and cloud-service controls under A.5.19 and A.5.23, which matter the moment a vendor touches your data. Incident response under A.5.24 and A.5.26, tested by asking what happened the last time something went wrong — and whether the record matches the procedure. On the technical side, backup under A.8.13, logging under A.8.15 and A.8.16, vulnerability management under A.8.8, change management under A.8.32, and secure coding under A.8.28 for product teams.

A cloud-only team sometimes marks the whole physical theme not applicable. Be careful. A.7 covers your office too: entry controls, clear desks, equipment disposal. "We are on the cloud" explains your servers, not your laptops, your office door, or the hard drive in the drawer. Mark individual physical controls out with reasons; do not strike the theme in one stroke.

What does a small IT company actually need to write, and in what order?

Write in this order, because each document feeds the next. First the scope, so everyone knows what is inside the system. Then the policy, so the direction is signed. Then the risk assessment process and the assessment itself, so controls follow risks instead of fashion. Then the SoA, which turns the assessment into control choices. Then the treatment plan, which turns choices into dated work. Then the procedures for the controls you included, shortest first. Then the records start accumulating on their own: audits, reviews, incidents, corrections.

Give every document an owner, a version, and a review date. A folder of undated files is the most common small-company failure I see, and the easiest to fix: one naming rule, one owner per file, one annual review on the calendar. A bought toolkit can help as a starting draft, but treat it as a draft. An auditor can tell within minutes whether the documents describe your company or somebody else's, and a template that names systems you do not own is worse than a short document you wrote yourself.

Five mistakes that turn a good system into audit findings

• A policy copied from the internet that promises controls you do not run.
• An SoA with no reasons for exclusions, or reasons copied from another company.
• A risk register with high risks, no owners, and no dates.
• Documents with no version, no owner, and no review date — nobody knows which copy is current.
• An internal audit skipped or rushed, so the certification auditor finds what your own audit should have caught.

How long does it take, and what does it cost?

For a small IT company, building this document set properly usually takes a few weeks of steady work alongside normal business, not a weekend. The realistic path runs through gap assessment, risk assessment, writing, internal audit, and management review, then the certification body's Stage 1 document review followed by the Stage 2 audit of the working system. Our earlier guide to the ISO 27001 process, from scope to risk assessment, walks through those stages in order.

On cost, keep the two parts separate. ComplyKart's ISO 27001 consultancy starts at ₹14,999 for companies up to 25 employees and ₹29,999 for 26 to 100 employees. That covers the consultancy: building the documents, the risk work, and audit preparation. Certification-body audit fees sit outside it, charged at actuals, and they vary with scope, sites, and headcount. Our ISO 27001 cost guide for IT companies and startups explains what drives that gap honestly, without inventing a fee band. Before you sign with any certification body, check how to verify an ISO certificate is genuine — the same care applies to choosing the body as to choosing the documents.

If the document list still looks long, start with the scope and the risk assessment this week. Those two force every hard decision — what is inside, what threatens it — and the rest of the set largely writes itself from their answers. And if you would rather have the set built with you than built alone, the ISO 27001 certification service page carries the current consultancy prices, and the compliance fee calculator can help you line up the year's filing costs beside it.

FAQs

How many documents does ISO 27001 require?

There is no fixed count. ISO/IEC 27001:2022 requires specific documented information in clauses 4 to 10 — scope, policy, risk processes, the Statement of Applicability, the treatment plan, objectives, and the records listed above — plus whatever your included Annex A controls need. Most small IT companies land between 15 and 30 live documents, not 93.

Is the Statement of Applicability a policy?

No. It is a control-by-control record: all 93 Annex A controls, each marked applicable or not, with a reason and an implementation status. Policies say what you do. The SoA says which controls you chose and why.

Can I exclude Annex A controls?

Yes, with a justified reason in the SoA tied to your risks. You cannot exclude clauses 4 to 10. An exclusion that reads "not applicable" with no reason will draw a finding; one that explains the business reality behind it will not.

Do I need a separate document for every Annex A control?

No. Group related controls into one procedure where it makes sense — one access-control document can cover several A.5 and A.8 controls. What matters is that every included control has documented guidance and evidence, not that every control has its own file.

What happens if a document is missing at Stage 1?

Stage 1 is the document review, so a missing core document usually becomes a finding to close before Stage 2 proceeds. That is the cheaper place to find it: fixing a document before Stage 2 costs days, while a failed Stage 2 costs a re-audit.