Skip the reading? Connect your stack and get a readiness score today. Plans from $79 a month, prices published.
A company pursuing SOC 2 or ISO 27001 typically needs 12 to 20 written policies, not the 40-document library most template packs sell. The non-negotiable core is an information security policy, access control, acceptable use, incident response, change management, risk management, vendor management, business continuity, data classification and retention, secure development if you write software, and HR security covering onboarding and offboarding. Everything past that is either a topic-specific policy your risk assessment justified, or padding that will age into fiction.
What policies does a company actually need?
Start from the frameworks rather than a vendor's document count. ISO 27001 is explicit: Clause 5.2 requires a single top-level information security policy approved by management, and Annex A control 5.1 asks for topic-specific policies underneath it, defined and reviewed. SOC 2 is deliberately less prescriptive. The Trust Services Criteria describe outcomes, not a policy list, so an auditor infers the policies you need from the controls you claim. That difference confuses first-time buyers, who go looking for the official SOC 2 policy list and find that none exists.
What both frameworks converge on in practice is the set below. These are the documents that come up in nearly every audit of a company under 200 people.
| Policy | What it has to say | Why it exists |
|---|---|---|
| Information security policy | Your overall security commitment, scope, and who owns it | ISO 27001 Clause 5.2 requires it by name; SOC 2 auditors open with it |
| Access control | How accounts are granted, reviewed, and revoked; MFA and least privilege | The most heavily sampled control area in both frameworks |
| Acceptable use | What staff may do with company systems, data, and devices | The document employees actually have to acknowledge |
| Incident response | How you detect, triage, escalate, and communicate a security incident | Required in substance by SOC 2, ISO 27001, HIPAA and GDPR alike |
| Change management | How code and infrastructure changes get reviewed, tested, and released | Auditors trace real pull requests and deploys against it |
| Risk management | How you identify, score, treat, and re-review risks | ISO 27001 Clauses 6.1.2 and 6.1.3 require the process to be documented |
| Vendor and third-party management | How you assess vendors before signing and on a schedule | SOC 2 CC9.2 and ISO 27001 A.5.19 to A.5.22 |
| Business continuity and disaster recovery | Recovery objectives, backup approach, and who declares an incident | Tested recovery is the evidence, not the document |
| Data classification and retention | What data you hold, how it is labeled, and how long you keep it | The hinge document for GDPR and HIPAA scope questions |
| Secure development | Code review, dependency management, and testing before release | Needed if you ship software; skip it honestly if you do not |
| HR security | Background checks, onboarding, training, and offboarding steps | Offboarding is where auditors find the most exceptions |
| Encryption and key management | What is encrypted at rest and in transit, and who holds the keys | Often folded into the security policy at small scale |
How many policies should a small company have?
Twelve to twenty is the realistic range for a company of 5 to 200 people carrying one or two frameworks. Fewer than about ten and you are almost certainly missing a topic an auditor will ask about. More than about twenty-five and you have bought a template library you will not maintain, which is worse than having fewer documents, because a policy that says something untrue about your company is a finding while a missing policy is just a gap.
The number is not the goal. Coverage is. One well-written access control policy that genuinely describes how your identity provider is configured beats four separate documents on passwords, MFA, provisioning, and reviews that contradict each other.
Which policies do auditors ask for first?
Access control, change management, and incident response, in roughly that order. Those three are where the technical evidence is richest, so an auditor can compare what the policy claims against what your systems actually did. If your access control policy says accounts are reviewed quarterly, they will ask for the last four reviews. If your change management policy says every change is peer reviewed, they will pull a sample of merges and check for approvals.
This is the practical reason to write policies after looking at your systems rather than before. A change management policy is only as strong as the release process behind it, and if yours is still someone connecting to a server by hand, fixing the zero-downtime deployment pipeline will do more for the control than any wording will.
What makes a policy fail an audit?
Three things, and none of them is writing quality. First, the policy describes a process the company does not follow, which surfaces the moment the auditor interviews an engineer. Second, nobody can show who approved it or when, so there is no accountable owner. Third, there is no record that staff read it, which means the policy cannot be said to control anyone's behavior.
That third one catches more teams than the other two combined. Auditors sample employees and ask for their acknowledgment of the current version, and a signature collected at hire against a document that has been revised twice since does not answer the question. Per-version policy attestation is what closes it.
Do company policies need to be reviewed every year?
Annual review is the widely accepted cadence and the one auditors expect to see, though neither SOC 2 nor ISO 27001 states a fixed interval. ISO 27001 A.5.1 requires policies to be reviewed at planned intervals and when significant changes occur, which means an annual cycle plus a trigger-based review after anything material: a new product line, an acquisition, a serious incident, or a change in the systems the policy describes. Set the date when you approve the document, assign it to a named person, and put it on the compliance calendar, or it will not happen.
Who should approve company policies?
A named individual with the authority to commit the company, recorded with the approval date. For the top-level information security policy, ISO 27001 Clause 5.2 puts that at top management, which for a 40-person company usually means the CEO or CTO rather than a committee. Topic-specific policies can be approved by the function that owns them, so the head of engineering approves secure development and the head of people approves HR security. What matters to an auditor is that the approver is a person, not a mailbox, and that the date is on record.
Can you use policy templates?
Yes, as a starting point, and almost everyone does. The failure mode is treating the template as the finished document. A generic access control policy will describe password rotation rules and a VPN you do not run, and that gap is exactly what an auditor finds. The workable approach is to start from a draft that already references your real stack, then edit it against how your team genuinely operates and have the owner approve it. That is the reason policy management software that drafts from your connected systems tends to produce fewer findings than a template pack: the first version is at least describing the right company.
What about GDPR, HIPAA and PCI DSS?
They add documents rather than replacing the core set. GDPR expects a privacy policy, a data retention schedule, and, for most organizations processing at any scale, a record of processing activities under Article 30. HIPAA adds sanction, workforce clearance, and contingency planning requirements under the Security Rule's administrative safeguards at 164.308. PCI DSS adds cardholder data handling rules and, if you take payments, a scope definition that is worth more effort than the policy itself. In every case the sensible move is to extend an existing policy rather than start a parallel library, because one approved access control policy can satisfy the equivalent requirement in all of them at once.
Where to start this week
Write or fix the information security policy, access control, and incident response first. Those three carry the most audit weight and the most real-world risk. Get a named approver and a date on each one, publish them where staff can actually find them, and collect acknowledgments against the specific version. Then work down the table above, and map each policy to the controls it satisfies so a second framework does not become a second writing project. If you want the whole set generated against your real systems and tracked from draft through attestation, that is what policy management software is for, and our page on SOC 2 compliance software covers how the same documents feed the rest of the audit.
RUN IT, NOT JUST READ IT
Turn this into tracked rows with owners
Everything in this guide becomes obligations, controls, and evidence with owners and due dates inside Complies, with a live readiness score on top. Plans from $79 a month, prices published.