Policies

Your first information security policy set, without starting from scratch

The core policies every framework expects, mapped to ISO 27001 and SOC 2, and how editable templates get you there in days.

A usable information security policy set has five things: a short top-level policy that states management's commitment, a handful of topic-specific policies covering access control, acceptable use, incident response, vendor management and business continuity, a named owner for each one, a review date, and language your own staff can actually follow. If you are starting an ISO 27001 or SOC 2 project, you do not need forty pages on day one. You need the policies your auditor will check against a control, and they need to describe what your organisation actually does, not what it aspires to do.

What should an information security policy set include?

An information security policy set is not one document. It is a top-level policy plus a small number of topic-specific policies that between them cover every area an auditor will ask about. For a business of 5 to 200 people, the core set usually looks like this:

• Information security policy (top-level). States management's commitment, the scope of the program, and who is accountable for it.
• Access control policy. How accounts are provisioned, reviewed and removed, and the rule that access follows least privilege.
• Acceptable use policy. What staff can and cannot do with company devices, accounts and data.
• Data classification and handling policy. How information is labelled (public, internal, confidential, restricted) and handled at each level.
• Incident response policy. Who is notified, how an incident is triaged, and what gets documented.
• Vendor and third-party security policy. How new vendors are assessed and reviewed over time.
• Business continuity policy. What happens if a system or facility goes down.
• Change management policy. How changes to production systems are proposed, reviewed and approved.

None of these need to be long. Auditors are not grading prose. They are checking that a document exists, that it is approved by someone with authority, that it matches what actually happens day to day, and that it has a review date attached.

Which policies do ISO 27001 and SOC 2 actually require?

ISO 27001:2022 does not list "an incident response policy" as a named requirement. Instead, Annex A sets out 93 controls across four themes: organizational, people, physical and technological. Each policy document you write is really a way of demonstrating one or more of those controls are addressed. SOC 2 works similarly, through the AICPA's Trust Services Criteria rather than a numbered annex. The table below maps the core policy documents to both.

Policy document	ISO 27001:2022 Annex A	SOC 2 Trust Services Criteria	Typical owner
Information security policy (top-level)	A.5.1	CC1.1, CC1.2	Leadership
Access control policy	A.5.15, A.5.18	CC6.1, CC6.2, CC6.3	IT / security lead
Acceptable use policy	A.5.10	CC1.1, CC1.4	HR / IT
Data classification policy	A.5.12, A.5.13	CC6.1	Security lead
Incident response policy	A.5.24 to A.5.28	CC7.3, CC7.4	Security lead
Vendor security policy	A.5.19 to A.5.22	CC9.2	Procurement / security
Business continuity policy	A.5.29, A.5.30	A1.2 (availability)	Operations
Change management policy	A.8.32	CC8.1	Engineering lead

Treat this as a starting map, not a legal opinion. Your auditor has the final say on whether a given document satisfies a given control for your specific Statement of Applicability or audit scope.

How long should an information security policy be?

There is no required length in either framework. A workable top-level information security policy runs one to three pages. Each topic-specific policy, such as access control or incident response, usually fits on one or two pages once you strip out boilerplate. A complete first policy set for a company of 5 to 200 people is commonly 15 to 30 pages in total. Long is not the same as thorough. A 60-page policy manual nobody has read is worse evidence than a 20-page set your team can actually describe in an interview with the auditor.

Free template, consultant, or a compliance platform: what changes?

A free information security policy template, such as the ones published by the NIST Computer Security Resource Center or industry bodies like SANS, costs nothing and gives you a reasonable starting structure. What it will not do is map itself to your specific framework's controls, track which sections you have actually customised, or hold the evidence that proves you follow the policy day to day. That gap is usually filled either by a compliance consultant, who drafts a tailored set for a fee, or by hours of unpaid internal time spent reading the standard and cross-referencing it yourself.

CertAssist sits between those two options. It gives you editable policy templates already mapped to the framework you are certifying against, alongside the evidence checklist for each control, for a flat US$225 a month at the current launch price (normally US$375 a month, see pricing). It does not replace legal review of your policies, and it does not remove the need for an independent auditor to examine the finished program. What it removes is the blank page.

Who should approve an information security policy, and how often should it be reviewed?

ISO 27001 expects the top-level information security policy to be approved by top management, meaning someone with genuine authority over the business, not just the person who happens to run IT. SOC 2 does not name a specific title, but auditors want to see the policy endorsed by someone senior enough that it carries weight, commonly a CEO, CTO or a named security owner.

Both frameworks expect a documented review at least once a year. In practice you should also review a policy after any major change: a new system, a security incident, a change in headcount or organisational structure, or an update to the standard itself, as happened with the move from ISO 27001:2013 to the 2022 revision. Put the annual review on a calendar with a named owner. "We will get to it" is the single most common finding auditors report in this area.

A simple process for writing your first policy set

1. Confirm your framework and scope. Know which controls or criteria you must cover before you write a word. See our guide to ISO 27001 for small business if you are just starting out.
2. Start from a template mapped to that framework, not a generic Word document you found through a search engine.
3. Assign one owner per policy. Shared ownership is how policies go stale.
4. Tailor the language to match reality. If the policy says MFA is mandatory everywhere and it is not yet, either turn it on first or say so honestly with a target date.
5. Get sign-off from someone with real authority, and record the approval date.
6. Link each policy to its evidence, such as screenshots, configuration exports or system logs, in one place your auditor can review.
7. Diarise the annual review before you move on to the next task.

This is the same structure CertAssist's editable templates follow for teams working through SOC 2 compliance software or an ISO 27001 program, so the policy set and the evidence behind it live in the same place your auditor reviews.

Frequently asked questions

← Back to the blog