Which ISO 27001 policies you need and who writes them
ISO/IEC 27001:2022 requires two layers of policy. Clause 5.2 asks top management to set a top-level information security policy, and Annex A control A.5.1 asks for that policy plus topic-specific policies beneath it. The organization owns these documents: its top management approves them, and no implementation partner or certification body can substitute for that decision. If a customer or contract asks for ISO 27001, the first practical question is which topic-specific policies your scope and systems actually need, and who signs off on them. The set differs by scope, risk and systems. A SaaS company running cloud infrastructure will usually need policies on access control, cryptography, secure development, supplier relationships and incident response, while a company with a small office network may need fewer, shorter ones. Use your Statement of Applicability and risk treatment decisions to decide which topics need a written policy, and confirm with your certification body how it expects those topics to be covered before drafting begins. An implementation partner can draft the documents, map them to the Annex A controls and organize the evidence of approval, communication and acknowledgment, but the approvals and the risk decisions behind them remain yours. For each policy, record who approved it, when it was published, how staff and relevant external parties were told about it, and how their acknowledgment is captured. Set review intervals and triggers for an early review after significant changes, such as a new hosting provider or a merger. An independent certification body will sample these records during the audit and check that the policies are being followed in practice, not just filed.
Which topic-specific policies A.5.1 expects
A.5.1 does not give a fixed list of policies. The topic-specific policies an organization writes follow from its risk assessment and Statement of Applicability, and each one records a decision that management has made. The six areas below are common starting points, and each names the Annex A controls it supports.
Access control policy
This policy records who may use which systems and data, how access is requested, approved, reviewed and removed, and how privileged accounts are handled. It is the written basis for the access controls in Annex A theme 5 and theme 8, including A.5.15 (access control), A.5.18 (access rights) and A.8.2 (privileged access rights). Check that the policy matches what your identity system actually enforces, and that access reviews produce dated records.
Acceptable use policy
This policy sets out what personnel may and may not do with company devices, accounts and information, including remote work and use of personal devices. It supports A.5.10 (acceptable use of information and other associated assets) and A.5.14 (information transfer). Its acknowledgment by each person is part of the evidence an assessor will ask to see, so confirm that new joiners sign it before they receive access.
Cryptography and key management policy
This policy records which cryptographic methods and key lengths are approved, where encryption is required, and who owns key generation, storage, rotation and destruction. It underpins A.8.24 (use of cryptography) and supports A.8.10 (information deletion) where encrypted data must be destroyed. Ask whether keys are held in a dedicated service with logged access, and whether the policy names an owner for each key class.
Information security incident management policy
This policy defines what counts as a security event or incident, how it is reported, who triages it, when management and affected parties are informed, and how lessons are recorded. It supports A.5.24 (planning and preparing for incident management), A.5.26 (response to incidents) and A.6.8 (reporting information security events). Confirm that the reporting route works outside business hours and that the policy names who may declare an incident.
Supplier security policy
This policy sets the security requirements that suppliers must meet, how they are assessed before and during the relationship, and how their access and data are ended at exit. It supports A.5.19 (information security in supplier relationships), A.5.20 (addressing security within supplier agreements) and A.5.21 (managing security in the ICT supply chain). Check that the supplier register and the contract templates reflect the requirements the policy sets.
Backup and continuity policy
This policy records backup frequency, retention, protection of backup copies, restore testing and the recovery targets the business has agreed. It supports A.8.13 (information backup), A.8.14 (redundancy of information processing facilities) and A.5.30 (ICT readiness for business continuity). Ask for restore test records, since an assessor will look for proof that backups can be restored, not only that they run.
How a policy moves from draft to approved and acknowledged
This sequence turns a drafted policy into an approved, published and acknowledged document, with a dated record at each phase that an assessor can trace from requirement to evidence. The outputs build on each other, so a gap at one phase shows up in the evidence of the next.
Draft policies against the risk assessment
The policy owner, usually the security lead, writes the information security policy and each topic-specific policy from the risk assessment and treatment results, the scope of the ISMS and the legal and contractual obligations the organization has identified. Each draft should name the risks it addresses and the controls it supports, so a reviewer can trace why each statement exists. The step is done when the draft has a version number, an author and a list of reviewers, such as legal, HR, IT operations and affected business owners.
Obtain management approval with a recorded date
Top management reviews the drafts and approves the information security policy, and approves each topic-specific policy at the level the organization has set in its governance. Approval should be recorded in a document control entry or meeting minutes that show the approver, the date and the approved version. The output is an approved version with a unique identifier, and a rejected draft goes back to the owner with the reasons written down.
Publish in a controlled location
The approved version moves to a single controlled repository, such as a document management system or wiki with access control and version history, and superseded copies are withdrawn or clearly marked. Only the owner can publish changes, and every change keeps the previous version available for audit. The output is a published policy with a document control record that lists its location, effective date, owner and review date.
Communicate to personnel and relevant parties
The organization tells personnel, contractors and, where relevant, interested parties such as key suppliers that the policy exists, what it requires of them and where to find it. Communication may include onboarding material, a short briefing, a notice from management or a message through the usual internal channels, and it should target the audiences each policy affects. The output is a distribution record that lists the channel used, the date and the audience, so the organization can show who was informed.
Record acknowledgment from relevant personnel
Relevant personnel confirm they have read and understood the policies that apply to their role, through an electronic acknowledgment in the HR or learning system, a signed form, or another method the organization defines. Acknowledgment should be recorded against the policy version, so a later change triggers a new acknowledgment. Missing acknowledgments are followed up and escalated under the organization's own process. The output is an acknowledgment log that shows names, roles, policy versions and dates.
Schedule review and feed changes back
The owner sets a review interval for each policy and reviews it earlier when a significant change occurs, such as a new system, a material incident, a change in legal obligations or a restructuring. Each review either confirms the current version or starts a new draft that returns to approval, publication and acknowledgment. The organization should confirm its own review intervals with its auditor, since the requirement asks for planned intervals without fixing them. The output is a review log that links each revision to its reason.
Setting review intervals and triggers for policies
A.5.1 requires the information security policy and topic-specific policies to be reviewed at planned intervals and after significant changes, so the review cadence is a commitment you must be able to show an auditor. Pick an interval your team will actually keep. A reasonable starting point is an annual review of the top-level policy under clause 5.2 and of each topic-specific policy, with a shorter cycle for policies tied to fast-moving areas such as cloud access or supplier management. A calendar entry, a named policy owner and a recorded decision for each policy matter more than a long interval that lapses. The standard does not set a fixed period, so confirm the interval you choose with your certification body before you put it into the policy framework.
Triggers are the events that force an unscheduled review regardless of the calendar. Write them down in the policy review procedure so they are not argued case by case. Typical triggers include adding a new cloud provider or changing how an existing one is used, an acquisition or divestment that changes the organization's systems or legal entities, a significant security incident or near miss, a material change in applicable regulation or contractual obligations, and a change in the risk assessment results that affects a policy's assumptions. Illustrative example: if a team moves customer data to a new hosting region, the data handling and supplier policies are reviewed before the change goes live, not at the next annual cycle.
Every review should leave a record that shows what was checked, who approved the outcome and whether any change was made. Keep the version history, the approver's name and date, a short note on what changed or why nothing did, and the link to the trigger that prompted an out-of-cycle review. These records are what an assessor samples when testing A.5.1, so an unchanged policy with a documented review is better evidence than a policy with a recent date and no trail. Ask your certification body which review records and sampling they expect during the first audit.
What an assessor asks to see for policies
An assessor tests whether the policy set is real, approved, reachable and kept current, not whether a policy document exists. The cards below cover the records that prove each of those points, and they apply to every policy in scope because assessors sample and a gap in one policy record is enough to raise a finding.
Approved policy versions
Each policy needs a version number, an owner, and a record showing that top management approved that exact version. Assessors check that the approved text matches the version in circulation, so a draft edited after sign-off with no new approval is a common finding. Ask for the approval date, the approver's role, and the version history for the information security policy under clause 5.2 and every topic-specific policy under A.5.1.
Publication location and access
Assessors ask where the current policies live and whether every relevant person can reach them. A shared drive or intranet page with access logs, plus a note of which audiences receive each policy, shows that publication is controlled. Check that superseded versions are archived and not left in circulation, because an outdated copy in a team folder can undermine the whole set.
Acknowledgment records by person
Communication under A.5.1 and the expectation in A.5.4 that personnel apply the policies both require proof at the individual level. Keep a record for each employee, contractor and relevant third party that names the policy, the version, and the date of acknowledgment. Assessors sample individuals, so a team-level sign-off or a missing contractor record will be tested directly.
Review history and triggers
A.5.1 requires review at planned intervals and after significant changes, so the record must show both. Keep a review log with the date, the reviewer, what changed or was confirmed, and the trigger, such as a scheduled review, a new cloud provider, or a material incident. Ask whether a review that found no changes was still recorded and approved, because an unchanged policy still needs evidence of review.
Links from policies to the Statement of Applicability
The Statement of Applicability records which Annex A controls apply and why, and each policy should map to the controls it supports. Assessors trace a control in the SoA back to a policy, then to the procedures and records that operate it. Maintain this map as a working document with control IDs such as A.5.1, A.5.36 and A.5.37, and confirm that each link still points to a current policy version.
How NIST CSF 2.0 GV.PO subcategories point to the same ISO 27001 requirements
This table sets the two NIST CSF 2.0 policy subcategories against the ISO 27001 clause and Annex A controls that the NIST Reference Tool lists as informative references for them. Read each row as a pointer to where the same policy expectation appears in ISO 27001, not as proof that one framework satisfies the other. Confirm every mapping with your assessor before relying on it in a customer answer or audit file.
| CSF subcategory | What it asks | ISO 27001 references |
|---|---|---|
| GV.PO-01 | Policy for cybersecurity risk management is established, communicated and enforced, based on organizational context and priorities | Clause 5.2; A.5.1, A.5.37, A.6.1, A.6.2, A.6.4, A.6.5, A.6.7, A.6.8 |
| GV.PO-02 | Cybersecurity policies are reviewed, updated, communicated and enforced to reflect changes in requirements, threats and technology | Clause 5.2; A.5.1, A.5.31, A.5.32, A.5.34 |
| Shared focus: top-level policy | Management sets the overarching security policy that the rest of the ISMS depends on | Clause 5.2 and A.5.1 both anchor this; check that your top-level policy is approved and dated |
| Shared focus: review cycle | Policies change when context, threats or requirements change, not only on a calendar | A.5.1 review at planned intervals and after significant changes; GV.PO-02 links review to changing conditions |
| Shared focus: enforcement | Staff and processes must follow the policies in practice | A.5.4 and A.5.36 test whether policies are applied; GV.PO-01 expects enforcement |
| Gap to check: legal and regulatory policy inputs | Policies reflect legal, regulatory and contractual obligations | Confirm which A.5.31 and A.5.32 policy records cover your specific obligations with your assessor |
Questions buyers ask about ISO 27001 policies
How many policies does ISO 27001 require?
ISO 27001 requires one top-level information security policy under clause 5.2, plus whatever topic-specific policies your organization needs to support its Annex A controls. The standard does not publish a fixed count. Topic-specific policies are driven by your scope and risk assessment: access control, acceptable use, supplier security, incident management, and cryptography are common examples. Clause 5.2 and A.5.1 together set the expectation that each policy is approved, communicated, acknowledged and reviewed. Ask your auditor which topic-specific policies they expect to see, because an organization with a small scope can often run with fewer documents than a large one.
Can a small team write its own ISO 27001 policies?
Yes. Nothing in ISO 27001 requires an outside author, and a small team with a clear scope can draft its own policies. The work is mainly deciding what the organization actually does, then writing that down in short, accurate documents. Teams usually find that the policy is easier to write once the risk assessment and Statement of Applicability exist, because each policy should trace back to identified risks and selected controls. Expect the effort to come from internal reviews and sign-off rather than from the writing itself. An outside partner can speed this up, but the organization still owns the content.
Do ISO 27001 policies need to be signed by the board?
ISO 27001 requires top management to approve the information security policy, not a board resolution specifically. Who counts as top management depends on your governance structure, so confirm the approver with your certification body and record the approval clearly, with a date and version. Many organizations have the chief executive or a board committee approve the top-level policy and the management team approve topic-specific policies. The approval should show that leaders have reviewed and accepted the policy, and that approval should be repeated when the policy changes or at its planned review.
Does a policy template satisfy the ISO 27001 requirement?
A template gives you structure, but it does not satisfy the requirement on its own. Auditors look for policies that match your organization, scope, technology and risks. A template left with generic wording or references to systems you do not run is a common finding. Use a template as a starting point, then edit each statement against what your people and systems actually do. Check that every policy has an owner, an approval record, an acknowledgment process and a review date. The test is whether staff can follow the policy and whether the operating evidence matches what it says.
How long does drafting ISO 27001 policies take?
The duration depends on the scope and how many people must review the documents. The main drivers are the number of topic-specific policies you need, how many systems and sites are in scope, whether current practices are already written down, and how many approvers and reviewers are involved. Organizations with informal practices usually spend extra time documenting what already happens before they can write policy text. Ask any partner or consultant to give you a written timeline tied to a defined list of policies, reviewers and approval steps, and to state which assumptions the timeline depends on.
Can a partner write our policies, and what must we still do ourselves?
A partner can draft policies, map them to Annex A controls and prepare the supporting procedures, and DeployOpen can take on this kind of work within a written scope. The organization still owns the decisions. Leaders must approve the policies, staff must receive and acknowledge them, and the business must confirm that the described practices are real. Owners must run the controls and keep the records afterward. A partner also cannot issue the certificate. Only an accredited certification body can do that. Before you sign, ask who will interview your teams, who signs off each document, and what evidence the organization must keep after the engagement ends.
How do policies relate to the certification audit?
Policies are one of the first things a certification auditor reviews, because they show what management intends and whether the Statement of Applicability is backed by documentation. The auditor will check that the top-level policy meets clause 5.2, that topic-specific policies exist where your controls require them, and that staff can show they know and follow the rules. Auditors also test whether policies are reviewed on schedule and after significant changes. Keep approval records, version history and acknowledgment evidence ready. Certification is issued by an accredited certification body, not by the partner who helped prepare the documents.
How DeployOpen prepares policy evidence for ISO 27001
DeployOpen prepares the policy set, its approval and communication records, and the review schedule that ISO 27001 assessors check under A.5.1. The organization owns and approves every policy, and an independent certification body decides whether the evidence meets the standard.
How we scope
- Agree in writing which policies the ISMS needs, including the top-level policy and each topic-specific policy in scope.
- Confirm which systems, sites and teams the policies apply to, so every policy has a named owner and audience.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Draft policies that match the organization's actual tooling, roles and procedures rather than generic templates.
- Map each topic-specific policy to the Annex A controls it supports, so the link to A.5.1 and A.5.4 is traceable.
- Set up document control with version history, approval records and a review interval for each policy.
How we hand over
- Deliver policy documents with approval, publication and acknowledgment records ready for the assessor to sample.
- Document the review schedule and the triggers for out-of-cycle review after significant changes.
- Train the named policy owners to run approvals, collect acknowledgments and answer assessor questions.
How we support
- Ongoing support, policy updates and upgrades are available as a retainer after handover.
- Support can cover revisions when the scope, systems or regulatory requirements change.
- Confirm with your certification body which evidence format and sampling approach it will use before the audit.
