ISO 27001 policy templates save time only when you know which documents the standard actually requires. The standard names a short list of documented information, from the scope of the ISMS to the results of management reviews, and it asks for an information security policy plus topic-specific policies where the organization needs them. It does not set a number of policies, and a toolkit with dozens of them can leave a team maintaining documents that describe controls it does not run. This article lists what ISO/IEC 27001:2022 requires you to document, the policies Annex A expects, and how to choose and customize templates so each document matches what the organization does.
ISO 27001 Policy Templates Start With What the Standard Requires
Mandatory Documented Information by Clause
ISO/IEC 27001:2022 uses the term documented information. Some of it has to be written down, such as policies and methods, and some has to be retained as evidence, such as audit results. The table lists the items the clauses name.
| Clause | Documented information | Typical form |
|---|---|---|
| 4.3 | Scope of the ISMS | ISMS scope statement |
| 5.2 | Information security policy | Information security policy |
| 6.1.2 | Information security risk assessment process | Risk assessment methodology |
| 6.1.3 | Information security risk treatment process | Risk treatment methodology |
| 6.1.3(d) | Statement of Applicability | SoA |
| 6.2 | Information security objectives | Objectives register with owners and dates |
| 7.2 | Evidence of competence | Training records and qualifications |
| 7.5.1 | Documents the organization decides are necessary for the ISMS | Document register |
| 8.1 | Evidence that processes ran as planned | Operational records |
| 8.2 | Results of risk assessments | Risk register or report |
| 8.3 | Results of risk treatment | Risk treatment plan |
| 9.1 | Evidence of monitoring and measurement results | Metrics reports |
| 9.2 | Internal audit program and results | Audit plan and reports |
| 9.3 | Results of management reviews | Management review minutes |
| 10.2 | Nonconformities, actions taken, and corrective action results | Corrective action log |
Only one row in this table is a policy in the usual sense: the information security policy in clause 5.2. The rest are scope statements, methods, plans, and records, so a template for most of them is a form, not a rule. The statement of applicability is the document that decides how many further policies the organization needs, and the clauses 4 to 10 requirements explain where each item comes from.
How Much Documentation Is Enough
Clause 7.5.1 lets the organization decide how much documented information it needs beyond the items the standard names. The standard notes that the extent can differ between organizations because of their size and type of activities, the complexity of their processes, and the competence of their people. A small software company and a multinational therefore do not need the same document set, and a toolkit built for the larger one will over-document the smaller one. The test is whether a document gives people the information they need to do the work and gives an auditor confidence that the process ran as planned.
The Information Security Policy Comes First
Clause 5.2 asks top management to establish an information security policy that is appropriate to the purpose of the organization. The policy includes the information security objectives or a framework for setting them, a commitment to satisfy applicable requirements, and a commitment to continual improvement of the ISMS. It must be available as documented information, communicated within the organization, and available to interested parties as appropriate. A template can supply the structure, but the commitments and the objectives have to come from the organization’s leadership, because an auditor will ask top management about them.
The Policies Annex A Expects
Control A.5.1 and Topic-Specific Policies
Control A.5.1 asks the organization to define an information security policy and topic-specific policies, have management approve them, publish them, communicate them, and review them at planned intervals and after significant changes. Relevant personnel and interested parties also have to acknowledge them. The control does not say how many policies there should be. That number is the organization’s decision, and the statement of applicability is where the decision is recorded, because a policy is needed only where an included control calls for a written rule.
Common Topic-Specific Policies and the Controls Behind Them
The table lists topics that organizations commonly cover and the control each one supports. It is a menu, not a required list.
| Policy topic | Related control | Question the policy answers |
|---|---|---|
| Access control | A.5.15 | Who may access what, and who approves it? |
| Acceptable use of assets | A.5.10 | What may staff do with company information and devices? |
| Information transfer | A.5.14 | How is information shared inside and outside the organization? |
| Supplier security | A.5.19 | What security does the organization require from suppliers? |
| Incident management | A.5.24 | Who declares an incident, and what happens next? |
| Business continuity and ICT readiness | A.5.30 | Which ICT services must recover, and how fast? |
| Remote working | A.6.7 | What rules apply when staff work outside the office? |
| Clear desk and clear screen | A.7.7 | How is information protected at desks and on screens? |
| Backup | A.8.13 | What is backed up, how often, and how is restore tested? |
| Cryptography | A.8.24 | Which encryption is required, and how are keys managed? |
| Secure development | A.8.25 | Which rules apply to building and changing software? |
| Change management | A.8.32 | How are changes approved, tested, and recorded? |
A topic belongs on the organization’s list only when the statement of applicability includes the related control and a written rule is needed. Several topics can share one document: a small organization may cover acceptable use, remote working, and clear desk in a single acceptable use policy. Fewer documents mean fewer things to keep current, and an auditor will read each one against how the organization actually works.
How to Decide Which Templates You Need
Policy, Procedure, and Record Are Different Documents
Most of the confusion about templates comes from treating three different documents as one.
| Document | What it does | Example |
|---|---|---|
| Policy | States the rule and who owns it | Access control policy |
| Procedure | Describes how the rule is carried out | User access request and removal procedure |
| Record | Shows that the rule was followed | Access review log and approved request tickets |
A policy template gives you the first row. The evidence an auditor tests comes from the third, and no template can produce it, because a record exists only when the work has been done.
A Decision Rule Based on the Statement of Applicability
The statement of applicability is the filter that keeps the document set small. The information security risk assessment feeds it, and it tells you which controls are in scope. Work through the same five steps for each control:
- Check the status. If the control is included, ask whether a written rule is needed. If it is excluded, no template is needed, and an organization that excluded the controls for premises it does not operate has no use for a physical security policy.
- Look for an existing document. A contract clause, an employee handbook section, or a runbook may already state the rule.
- Choose a template only for the gap. Pick the template for that topic, and no more.
- Combine small topics. Topics with the same owner and review cycle can share one document.
- Register the document. Add it to the document register under clause 7.5.1, with an owner, a version, and a review date.
The result is a document set sized to the organization. It is usually shorter than a toolkit’s contents list, and every document in it has an owner who knows what it says.
An Illustrative Document Set for a Small Software Company
Take a software company with a remote workforce, a cloud-hosted product, and no office premises in scope. After the statement of applicability is complete, its document set might consist of the clause 5.2 information security policy, one acceptable use policy that also covers remote working and clear desk and clear screen, an access control policy, a supplier security policy, an incident response procedure, and a short technology standard that covers backup and cryptography. Change management and secure development can share one document because the same engineering lead owns both. Alongside these, the organization keeps the required records: the risk register, the risk treatment plan, the audit reports, and the management review minutes. The example is illustrative and not a recommendation for any specific organization, because the right set comes from that organization’s own risk assessment and statement of applicability.
What Templates Do Not Do
Where Copied Policies Fail Audits
An auditor reads each policy against how the organization actually works, so a template that was pasted in without changes tends to fail in the same few ways:
- Promises the organization does not keep. A statement such as “multi-factor authentication is required for all systems” is a finding if one system does not use it.
- Placeholders left in. Generic role names, company names, or bracketed text show that nobody owned the document.
- Old control numbering. Templates written for the 2013 version cite controls that were merged or renumbered, and the transition to 2022 ended on October 31, 2025.
- No owner or review date. A policy without them cannot show that management approves it and reviews it at planned intervals.
- No communication. Control A.5.1 expects personnel to acknowledge policies, so a policy that sits in a folder does not meet it.
How to Customize a Template in Seven Steps
A template becomes a usable policy when each step below has been done:
- Confirm the control. Cite the related control from the statement of applicability, using its 2022 reference.
- Name real roles. Replace generic roles with the job titles that exist in the organization.
- Remove what you cannot meet. Delete every statement the organization does not do today, or move it to a plan with an owner and a date.
- Add the specifics. Name the systems, the frequencies, and the thresholds.
- Link the evidence. Point the policy to its procedure and to the record that shows it operating.
- Approve, publish, and collect acknowledgment. Keep the approval and the acknowledgments as records.
- Set the review. Record the version and the next review date.
The records from steps 5 and 6 are what an auditor asks for first, and the guide to evidence mapping for the Stage 2 audit shows how to organize them.
How to Keep Policies Current
Approved policies still need maintenance. Control A.5.1 expects review at planned intervals and when significant changes occur, so each policy should carry a review date and an owner. Events that call for an earlier review include a new risk, a security incident, an audit finding, a change in systems or suppliers, and a new legal or contractual requirement. Keep each approved version and the date it was published, since an auditor may ask what was in force at the time of an event. A short change log at the top of each document is enough, and the document register from clause 7.5.1 can show every owner and review date in one place.
Check Your Readiness Before You Write a Policy
Templates tell you what to write. They do not tell you which documents you need or where the real gaps are, and a readiness check does. It is a better first step than downloading a toolkit, because it shows what already operates and what exists only on paper.
Elevate’s ISO 27001 readiness self-assessment covers all 123 requirements of ISO 27001:2022: the 30 management system clauses and the 93 Annex A controls. Each requirement is rated from 1 to 5, the workbook shows a score for each section, and it maps the evidence an assessor typically requests to the clauses where it applies. The Summary tab ranks the gaps, so the policies that are actually missing stand out. Download the ISO 27001 readiness self-assessment and bring the results to a no-cost 30-minute readiness review with Elevate’s team.
The workbook is a working aid. Only a formal gap assessment or a certification audit by an accredited certification body produces an official result. The guide to the ISO 27001 readiness assessment steps explains how a formal assessment runs, and Elevate’s ISO 27001 service covers the path to certification.
Conclusion
ISO 27001 policy templates help when they fill a gap the statement of applicability has identified. The standard requires a short list of documented information, one information security policy, and the topic-specific policies that the organization’s own controls call for. Everything else in a toolkit is optional, and every optional document is one more thing to keep current and defend.
Teams that want help sizing the document set can Book a Readiness Call with Elevate’s ISO 27001 specialists. Elevate prepares organizations for audits performed by accredited certification bodies and does not issue certifications.
Key Takeaways
A small, accurate document set is easier to defend than a large one copied from a toolkit.
- The standard requires a short list. The table in this article lists 15 items of documented information, and only one of them, the clause 5.2 information security policy, is a policy in the usual sense.
- Annex A expects topic-specific policies where needed. The statement of applicability decides which ones the organization writes.
- Policy, procedure, and record are different documents. A template gives you the policy, and an auditor tests the records.
- Customize before you publish. Remove what you do not do, name real roles, link the evidence, and collect acknowledgment.
- Check readiness first. Score the requirements before you write a document, so you write only the ones that are missing.
Frequently Asked Questions
What policies does ISO 27001 require?
ISO/IEC 27001:2022 requires one policy by name: the information security policy in clause 5.2. Control A.5.1 also expects topic-specific policies where the organization needs them, but it does not list them or set a number. The statement of applicability determines which topic-specific policies apply.
How many policies do you need for ISO 27001?
There is no fixed number. The count depends on the controls the statement of applicability includes and on whether a written rule is needed for each one. Related topics can be combined into one document, which reduces what has to be reviewed and kept current.
Can you use an ISO 27001 policy template as it is?
No. A template is a starting structure, and an auditor reads each policy against how the organization actually works. Remove the statements you do not meet, name real roles, add the specific systems and frequencies, and link each policy to its procedure and records before approval.
Are policy templates enough to pass an ISO 27001 audit?
No. Policies are only part of the documented information, and an auditor also tests the records that show the controls operating, such as access reviews, audit reports, and management review minutes. A template can give you the policy, but the records come from doing the work.
What is the difference between a policy, a procedure, and a record?
A policy states a rule and who owns it. A procedure describes how the rule is carried out. A record shows that the rule was followed, for example a review log or an approved request. Templates usually cover the first two, and records come from doing the work.