What an information security policy is for
The information security policy is the first document an auditor reads and the one every other security policy hangs from. It says that you run a security program, what it covers, who is accountable for it, and how your other policies fit together. Most SOC 2 programs start here, often with a search for an information security policy template.
A template is a fine start, but it describes a company, not necessarily yours. This guide gives you an outline instead: the seven sections a good policy needs, what to write in each, and short example wording. Every example is a sketch to rewrite in your own words.
In SOC 2 terms, this policy typically supports criteria about management's commitment to integrity and ethical values (CC1.1), the information used to run internal control (CC2.1) and putting controls in place through policies (CC5.3). Treat that mapping as indicative: your auditor decides how each criterion is evidenced.
What belongs in it, and what goes in the topic policies
Decide first what to leave out. The information security policy sets direction. The topic policies (access control, incident response, change management and so on) set the detailed rules. Put the detail here too and you get two documents saying the same thing slightly differently, which an auditor will notice.
| Put it in the information security policy | Put it in a topic policy or procedure |
|---|---|
| That a security program exists, and its goals | Password length, MFA rules, access review steps |
| Who is accountable for security, and leadership's role | Incident severity levels and the on-call process |
| Which policies make up the program | Patch timeframes for each vulnerability severity |
| How policies are approved, reviewed and communicated | Backup frequency and retention periods |
| How exceptions are requested and approved | Firewall rule standards, encryption algorithms |
| That breaches have consequences | Tool-specific settings and step-by-step instructions |
For the full set of topic policies a SOC 2 program usually needs, and what each one covers, see which SOC 2 policies you need. This article covers only the top-level one.
An infosec policy outline, section by section
These seven sections are a common policy structure. Aim for two to four pages; if yours runs much longer, topic-policy detail has probably crept in.
1. Purpose
One short paragraph on why the policy exists: what you protect (usually the confidentiality, integrity and availability of your and your customers' information), and that this policy establishes the program the other policies belong to.
Example wording to adapt: "This policy explains how [Company] keeps the information entrusted to us safe from loss, misuse and unauthorized access. It sets up our information security program and is the parent of every other security policy."
2. Scope
Say who and what the policy applies to: people (employees, contractors, interns), systems (work devices, cloud services, internal tools) and information in any form. Be clear about the edges, such as contractors on their own laptops.
Example wording to adapt: "This policy applies to everyone who works for or on behalf of [Company], and to any device, account or service used to handle [Company] or customer information."
3. Roles & Responsibilities
Name roles, not people, so the policy survives a reorganization. A small company usually needs leadership, a security lead, policy owners, managers and everyone in scope, each with one or two concrete duties. If you keep a separate roles document, summarize and point to it.
Example wording to adapt: "The CTO is accountable for the security program, reports on it to the leadership team each quarter, and approves changes to security policies."
4. Policy Statements
This is the heart of the policy: a numbered list of commitments, each one specific enough that someone could check whether you meet it. Eight to twelve statements is plenty. Good candidates:
- The program consists of this policy, the supporting policies and the recurring activities that put them into practice.
- Policies are published where everyone in scope can read them, and people acknowledge the ones that apply to them.
- Security risks are assessed and treated under the risk management policy.
- Information is handled according to its classification.
- Control failures are recorded, owned and fixed.
- Suspected incidents are reported straight away to a named contact.
Example wording to adapt: "Every security policy has a named owner, is approved by the leadership team, and is reviewed at least once every 12 months or sooner after a significant change."
Use "must" for what you always do and "should" only for genuine recommendations. "Appropriate controls are maintained" can't be tested, so nobody can prove it.
5. Exceptions
Explain how someone asks to depart from a security policy: in writing, with the business reason and any compensating control, approved by a named role, recorded, and given an end date. Exceptions with no expiry tend to become permanent.
Example wording to adapt: "Requests for an exception go to the security lead with the reason, the risk and how it will be reduced. Approved exceptions are logged and expire after six months unless renewed."
6. Enforcement
State that breaches can lead to disciplinary action in line with your HR process and the law. Keep it proportionate: you want people to report their own mistakes.
Example wording to adapt: "Breaking this policy may lead to disciplinary action. Honest mistakes reported promptly are treated as a chance to improve our controls."
7. Related Documents
List the topic policies and key procedures this policy relies on, using their real titles, and update the list when you add or retire a policy.
Finish with an effective date and, separately, keep a record of each approved version (more on that below).
Management commitment and roles
Auditors look for evidence that leadership owns security, not just the policy's author. The policy is where that commitment is written down, but it only counts if it shows up elsewhere too:
- Leadership approves it. The approver should be someone with authority over the whole company, such as the CEO or a leadership team, not only the security lead who drafted it.
- Leadership hears about it. If the policy says the security lead reports to leadership each quarter, keep the agendas or notes of those meetings.
- Leadership resources it. A security lead with no time allocated is a commitment on paper only.
In a small startup the CTO may be security lead, policy owner and approver at once. That is common. Where you can, add an approver who is not the author: independent approval is easier to defend.
Keep it short and true to what you do
Every statement in the policy is a promise your auditor may test. Before approving it, read each line and ask two questions: do we actually do this, and could we show evidence that we did? If the answer is no, either change the statement or start doing the thing before your audit period begins.
Short policies are easier to follow, review and read before acknowledging. Leave out threat background, company history and anything that reads like marketing.
Approve it, review it, get it acknowledged
Three recurring steps make the policy hold up in an audit:
- Approval. Record who approved which version and when. Keep the approved text itself, not just a note that something was approved. Policy version control and approvals covers how to do this so an auditor can trace each approval to exact text.
- Annual review. Review the policy at least once a year, which is the common expectation, and sooner after a big change such as a new product line or a reorganization. A review that changes nothing still counts if you record it.
- Employee acknowledgement. Everyone in scope should read and acknowledge this policy when they join and again when it changes in a way that affects what they must do. Record who acknowledged which version. See policy acknowledgement tracking for how to run this without spreadsheets.
Common mistakes with information security policies
- Copying a template you don't follow. The template promises monthly reviews, a security committee or a tool you don't have. Each one is a potential exception in your report.
- Restating the topic policies. When the information security policy says access is reviewed quarterly and the access control policy says twice a year, you have a contradiction to explain.
- Naming people instead of roles. Someone leaves, and the policy is out of date the same day.
- Untestable language. "Reasonable", "appropriate" and "as needed" give an auditor nothing to check and give your team nothing to do.
- Approving once and forgetting. A policy last approved two years ago tells an auditor the program isn't being run.
Important: the policy is part of what your auditor tests against. A promise in it that you can't evidence can turn into an exception in your SOC 2 report, even if the control it describes was never required.
Doing this in Confluence
Compliance in a Box provisions the Information Security Policy as a managed Confluence page under Policies in your compliance space, along with the rest of the SOC 2 policy set. Security is always in scope, so this policy is always created. The page starts from a template with the same seven sections described above, plus an effective date. Your company name, security contact and effective date from the company profile are filled in once, when the page is created.
The page opens with a note that it was generated from a template and is a starting point, not legal advice, to review and tailor before approval. You can delete the note once you've done that. If you already have an information security policy elsewhere in Confluence, you can import its text instead.
From there the app tracks the steps above:
- Owner and approvers. The admin who generated the pages starts as owner and approver of every policy. Change that under Settings, Owners & approvers: one owner and one to ten approvers. Only the owner and Compliance Admins can edit the page (page restrictions need Confluence Standard or above).
- Approval. The policy starts as Draft. When the text is ready, the owner selects Submit for approval and describes what changed. Every approver must approve, and each approval is tied to that exact page version, so an edit made after submitting cancels the submission. Self-approvals are labeled, and the Compliance Admins' Dashboard lists policies approved without an independent approver.
- Acknowledgement. The Information Security Policy requires acknowledgement. When it is first approved, everyone in its audience (all employees by default) is asked to acknowledge it within 30 days, and new joiners are picked up by the daily check. Later versions trigger a new round only when approved as a Material change.
- Review dates. The default review cadence is 12 months from the latest approval. The policy is flagged Review due 30 days before the date and Overdue after it, and the owner can use Mark as reviewed when nothing needs to change.
The policy is mapped to CC1.1, CC2.1 and CC5.3 in the generated controls matrix, and the yearly Annual Policy Review activity lists every policy with its approval date on its evidence page. The details are in Policies and approvals, Policy acknowledgements and the SOC 2 content reference.
FAQ
What should I include in an information security policy?
Purpose, scope, roles and responsibilities, a short list of testable policy statements, an exception process, enforcement, and a list of related policies. Keep detailed rules for specific areas in their own topic policies.
Who should approve the information security policy?
Someone with authority over the whole company, such as the CEO or the leadership team. Ideally at least one approver is not the person who wrote it. Your auditor will want to see who approved which version and when.
Can I use a free information security policy template?
Yes, as a starting point. Rewrite every statement to match what your company actually does, remove anything you don't do, and have it approved before relying on it.