What policies do you actually need to get ISO 27001 certified?

Short answer: It's a common misconception that ISO 27001:2022 hands you a fixed set of policies to write. In fact, it names only one: the Information Security Policy. That's the only policy the standard makes compulsory. In practice, though, most businesses end up with 15 to 25 ISO 27001-related policies.

Here's why. Alongside its main requirements, the standard includes a menu of 93 optional security measures called "controls," listed in a section called Annex A. Which ones you use depends entirely on your business, and you work that out in three steps:

1. Conduct a risk assessment to identify what could realistically go wrong in your organisation.
2. Go through Annex A to find the controls that address those risks.
3. Record the controls from Annex A that apply to you in a document called the Statement of Applicability, or SoA.

Once a control is on that list (the "SoA"), it's no longer optional for you — and if it depends on staff following certain rules, those rules need to be written down. That written document is a policy. You can then group related controls together, giving you policies like an Access Control Policy or a Backup Policy. (More detail on this later.)

So if a consultant or website has sold you a master list of 30 template policies, it's worth knowing the standard doesn't dictate a number. Writing policies you don't need leaves you reviewing and updating unnecessary paperwork. Skipping one you do need leaves a gap an auditor will find, putting your certification at risk.

Here's how to work out exactly which policies you need:

‍

The Mandatory ISO 27001 Policy:

The Information Security Policy is the only policy the standard requires outright. Clause 5.2 of ISO 27001:2022 requires a top-level Information Security Policy, signed off by leadership, that:

• Is appropriate to the purpose of the organisation;
• Includes information security objectives;
• Includes a commitment to satisfy applicable requirements of the ISO 27001 standard;
• Includes a commitment to continual improvement of your Information Security Management System ("ISMS")

Every other policy you’ll need to achieve – or maintain – certification is decided by your own business through a chain that works like this:

1. Your risk assessment — or a legal, regulatory, or contractual obligation — flags something you need to address;
2. You mark the Annex A control that deals with it as applicable in your Statement of Applicability (SoA);
3. Some controls are satisfied by a system doing its job e.g. endpoint protection on every laptop is proven by a dashboard, not by paperwork. Others depend on people following rules, and those rules have to be written into policies.

This is the single most misunderstood part of ISO 27001, and it's why "which policies do I need to get ISO 27001 certified” doesn't have a universal answer.

The Annex A-Linked Policies You'll Almost Always Need:

Annex A’s 93 controls are split into four groups: organisational, people, physical, and technological. Below is each group, with the policies most businesses require to address these controls.

Organisational Controls:

• Access control policy: Sets out who can get into which systems and data, and how that access is granted, reviewed, and removed. Usually this is the first thing an auditor digs into – and they’ll want to test it by checking leavers lost their access and that any access reviews happened on schedule. ‍
• Incident management policy Defines what counts as a security incident, who gets told, and what happens next. Auditors pay close attention to this one, but having the policy alone won’t satisfy them – they’ll want to see evidence that the policy is actually being followed (logged incidents, response records, etc.).
• Supplier/third-party security policy: Covers how you vet suppliers who touch your data and what security you require of them. The 2022 revision of the ISO 27001 standard put more weight on this given the increasing threat. Verizon’s 2025 Data Breach Investigation Report found third-party involvement in 30% of data breaches, double the previous year.
• Information classification and handling policy: Defines your sensitivity levels/classification labels (e.g. public, internal, sensitive, confidential) and how information at each level must be stored, shared, and disposed of. It underpins many of the     other policies, because you can’t apply the right level of protection to something until you know how sensitive it is.
• Acceptable use policy: The rules for how staff use company systems, devices, email,  and internet access. Auditors will want to see that your staff actually know and agree to this.  
• Data retention and disposal policy: States how long you keep each type of data and how you securely destroy it. Narrow compared to the policies above, but auditors will look for actual retention periods rather than a general commitment to not keeping things forever.

People Controls:

• Security awareness & training policy: Sets out what security training staff receive, when they receive it, and how often it’s refreshed. People remain the largest attack surface, so auditors want to see that this training isn’t a one-off at induction. Together with the policy, they’ll also want to see training completion records per person.
• Screening policy: Covers what background checks you run before someone is given access to sensitive systems or data. Auditors look for evidence the checks were actually carried out as described in the policy.
• Remote working policy: Sets the security expectations for staff working outside the office – home networks, personal devices, working in public (e.g. at cafes). It’s relevant only if you have remote or hybrid staff, and straightforward to de-scope in the Statement of Applicability if you don’t.  

Physical Controls:

• Physical and environmental security policy: Governs who can get into your premises, offices, and any equipment areas, and how that’s controlled. Auditors will look at evidence this policy is in place via visitor logs, entry records, and details of who holds keys or door codes.
• Equipment and asset handling policy: Covers how devices are issued, tracked and returned, and what happens if/when one is lost or stolen. Worth taking seriously because lost and stolen devices are among the most common incidents a small business will actually face.
• Clear desk and clear screen policy: The day-to-day discipline of locking screens when away from a desk and not leaving sensitive papers out. Narrow in scope, and a candidate for de-scoping if you’re fully remote, though a clear desk may still apply dependent on the nature of your work and the information.  

Technological Controls:

• Backup policy: States what gets backed up, how often, where it’s stored, and how you verify a restore works. The most consequential control here because ransomware or hardware failure with no working backup is an existential problem for the business, not only a compliance gap. Auditors increasingly want evidence of a tested restore, not just backups running.
• Password / authentication policy: Covers how users prove who they are: password requirements, MFA, how credentials are issued and reset. It pairs with your access control policy rather than duplicating it. Access control governs who’s allowed into a system, the password / authentication policy governs how they prove it’s them.
• Malware protection policy: Sets out what anti-malware protection you run, on which devices, and who’s responsible for confirming it’s working.  
• Network security policy: Covers how your networks are segmented, protected and monitored, including remote access. It often overlaps with what your cloud provider already handles, so it’s worth establishing where their responsibility ends and yours begins before you draft this policy.
• Change management policy: Governs how changes to systems are approved, tested, and released without introducing new security holes.
• Business continuity / disaster recover policy: The plan for keeping the business running after a major disruption, not just keeping the data safe. It’s broader than your backup policy, and auditors will look for evidence you’ve tested it rather than only written it.  
• Cryptographic controls / encryption policy: States what data you encrypt at rest and in transit, and how encryption keys are managed. For small SaaS and services businesses much of this is handled by cloud platforms by default, but you still need to document your position rather than assume it.

Common Mistakes When Scoping & Writing ISO 27001 Policies:

• Adopting policy templates without adapting them to your business: Starting from a template – whether downloaded from a website or provided by a consultant – is normal and sensible, particularly for non-experts. The mistake is leaving them as-is with generic placeholder text instead of specifics about your systems, roles and processes. A policy that’s clearly still in     template form typically gets flagged as a nonconformity, which you’ll then have to fix before (or shortly after) you can get certified.
• Not  being able to explain why you have a policy: Every policy should trace back to a specific risk you identified, and the control from Annex A that addresses it. If an auditor asks “why does this policy exist?” and you can’t answer, that’s typically logged as a nonconformity – usually minor if it’s an isolated case, but potentially major if it happens repeatedly since that suggests the underlying risk assessment wasn’t done properly.
• Treating  policy creation as a one-off project: ISO 27001 clause 7.5 requires documented information to be controlled: version-controlled, reviewed on a schedule, and re-approved when your ISMS scope changes. A policy that was written just to pass the original certification audit then forgotten is one of the most common problems auditors find when they conduct the     surveillance audits.

Keeping ISO 27001 Policies Audit-Ready Once They’re Written

Once you’ve worked out which policies you need – the Information Security Policy, plus any policies covering the Annex A controls relevant to your organisation’s risks – the job isn’t finished. Each policy needs a named owner, a review date, records of what changed between versions, and proof that you communicate these policies – and any updates to them – to the relevant people in your organisation.

Dayspring Software is built to help businesses meet these document control requirements of the ISO 27001 standard. It helps you answer the questions auditors ask about your policies: who owns this policy? When was it last reviewed? When will it next be reviewed? What changed between versions? Do your staff know about it? Read more about how Dayspring Software supports businesses with achieving or maintaining their ISO27001 certification here.

FAQs:

Do I need to implement all 93 Annex A controls to get ISO 27001 certified? No. But, you do need to go through all 93 and decide whether each one is relevant to your business. You can find the 93 controls in your copy of the ISO 27001 standard, which is available to purchase online via the official ISO website, but may also be supplied to you by your auditor and/or consultant. You only need to implement — and write policies for — the relevant controls. The ones that aren't relevant to your business, you can leave out ("de-scope"), as long as you document your reason for excluding them in your Statement of Applicability.

Do I need a separate policy for every applicable Annex A control? No. Related controls are typically grouped into a single policy: a handful of access-control related controls sit under the access control policy, for example. This is how 93 controls collapse into 15 to 25 documents. Auditors check that every applicable control is addressed somewhere, not that each control has its own dedicated policy.

What’s the difference between a policy and a procedure in ISO 27001? A policy states the rule and who owns it (e.g. “all access is granted on a least-privilege basis, reviewed quarterly”). A procedure is a step-by-step of how it’s carried out (e.g. “to onboard new staff member, do X, then Y”).

Can I manage both policies and procedures inside Dayspring Software’s platform? Yes, absolutely. You can upload any documents of your choosing to Dayspring and the platform will ensure they’re version-controlled, reviewed on a schedule, and acknowledged by staff.

Is the Information Security Policy the only mandatory policy in ISO 27001? Yes, the Information Security Policy is the only policy the ISO 27001 standard requires from every single business, no matter what. But, that doesn't mean it's the only policy you'll need to get certified. Once you've gone through Annex A and identified which controls apply to your business, the policies for those controls become just as mandatory for you as the Information Security Policy — you can't pass certification without them. So, it's less "only one policy is required" and more "only one policy is required for everyone — the rest depend on your business."

What happens if we don’t have a policy an auditor thinks we should have? The auditor logs it as a "non-conformity" — their term for "you're missing something the standard requires." If it's a small, isolated gap, that's usually minor: you get a set amount of time to fix it, and certification isn't held up. If it's a bigger gap — or a sign that risks weren't properly assessed in the first place — that's major, and it can block certification until it's sorted. Either way, this is why when working out which policies you need for ISO 27001, you should start with a thorough risk assessment, then go through Annex A to see which controls apply to you — and from there, which policies you need.

How often do ISO 27001 policies need to be reviewed? There's no fixed number of months or years set by the standard. What it does require is that your policies stay up to date — so if something changes, the policy should be updated to match. In practice, most businesses review each policy once a year as a baseline ahead of their internal audit, plus an extra review any time something relevant changes, like bringing on a new supplier or changing a system that the policy covers.

Can small businesses use a simplified ISO 27001 policy set?
Yes. ISO 27001 isn't one-size-fits-all and is focused on continual improvement: the number of policies you need scales with the size and risk of your business. A small business with fewer systems, staff, and risks can end up with a much shorter, simpler policy set than a large company, as long as each excluded control is justified in the Statement of Applicability.