Writing SOC 2 Policies That Aren't Just Box-Checking

The Policy Graveyard

Every company that's ever done a compliance exercise has one: a folder (usually called "Policies" or "Compliance" or "GRC") that contains 20-30 Word documents written by a consultant three years ago, approved once, and never read since.

The problem isn't just that this is a bad experience. It's that it creates real audit risk. Auditors don't just check that policies exist. They verify that policies are communicated to staff, acknowledged, and actually followed. A policy that nobody has read is a control that doesn't exist.

Orion's founder Priya had three policies before they started: an acceptable use policy, a privacy policy for their website, and an information security policy that was a modified template from the internet.

None of them had been communicated to the 12-person team. None had been approved by anyone. Two had never been updated since the company was founded.

Here's how they fixed it.

The Minimum Policy Set for SOC 2

These are the policies auditors almost always request. Some are standalone documents; some can be combined.

| Policy | Covers | Priority | |---|---|---| | Information Security Policy | Overall security objectives and governance | Critical | | Access Control Policy | Who can access what, and how | Critical | | Incident Response Plan | How to identify, report, and respond to incidents | Critical | | Change Management Policy | How code and infrastructure changes are controlled | Critical | | Vendor Risk Management Policy | How third-party vendors are assessed | High | | Acceptable Use Policy | How company systems and data may be used | High | | Business Continuity / DR Plan | How you recover from disruptions | High | | Data Classification Policy | How data is categorized and protected | Medium | | Vulnerability Management Policy | How vulnerabilities are identified and remediated | Medium | | Encryption Policy | When and how data is encrypted | Medium |

What Makes a Policy Audit-Ready

Every policy needs five things to satisfy an auditor:

1. A Version Number and Date

Version 2.1 | Approved: November 15, 2024

This proves the policy was deliberate and controlled. Undated, unversioned documents suggest an ad hoc process.

2. An Owner

Owner: Rishabh Arora, Head of Engineering | Reviewer: Priya Singh, CEO

Someone is responsible for this policy. If the policy is wrong or outdated, there's a named person accountable for fixing it.

3. An Approval Record

The policy should be approved — formally, by someone with authority. For a small company, this typically means the CEO or CTO signs off. For a larger company, it might be the board or a security committee.

How to do this simply: Create a shared Google Doc. When the policy is final, the approver adds a dated comment: "Approved by [Name], [Date]" or creates a PDF with a digital signature. For extra credibility, keep a version log at the bottom of the document.

4. A Review Cycle

Annual review by: November 2025

Policies should be reviewed at least annually. The auditor will check whether your review cycle has been followed.

5. Evidence of Communication

The hardest part. The policy exists. The owner knows about it. Does the team?

How to Communicate Policies Without Losing the Team

Here's the tension: security policies need to be communicated. But nobody wants to read a 15-page information security policy. Here's what Orion did that actually worked:

Policy acknowledgment via HR onboarding: Every new hire at Orion signs an acknowledgment that they've read the information security policy, acceptable use policy, and code of conduct as part of their first-week onboarding checklist. This is tracked in their HRIS (in Orion's case, a simple Airtable form).

Annual refresh: Every October, Orion sent a Slack message linking to the current policy folder with a request to re-acknowledge. They used a simple Google Form. Completion was tracked in a spreadsheet. Incomplete responses were followed up by the people ops lead.

Evidence this creates: An annual acknowledgment record showing name, employee email, and date of acknowledgment. When the auditor asks "show me evidence that employees were made aware of the information security policy," Orion could provide a clean spreadsheet showing 12/12 employees acknowledged.

Writing Policies People Will Actually Read

I'll share a simple structural approach that makes policies useful rather than just compliance decoration:

Start with the purpose in plain English. Not "This policy establishes the organisational framework for the governance of information security in alignment with relevant regulatory requirements and industry best practices." Just: "This policy describes how we protect access to our systems and customer data."

State the scope clearly. Who does this apply to? All employees? Contractors? Specific teams? Be explicit.

Use numbered rules, not paragraphs. "1.1 All production systems must require MFA." is clearer and more actionable than a paragraph explaining the importance of multi-factor authentication.

Include examples. "Confidential information includes: customer data, financial records, source code, employee salary information, and any data marked CONFIDENTIAL."

Tell people what to do if they're unsure. "If you're unsure whether an activity is permitted under this policy, contact security@orionhq.com before proceeding."

The Policy Review Process

Every year (at minimum), policies should be reviewed and re-approved. This is where many companies fail — they write the policy once, put it in a folder, and forget about it.

Orion's annual policy review process:

1. One week before the review date, the policy owner reviews the document against current practices
2. Any updates are made and the version number is incremented
3. The updated document is sent to the approver for review and sign-off
4. The approval date is updated in the document header
5. The updated policy is re-communicated to all staff
6. The annual acknowledgment process runs

This takes about 2 hours per policy, per year. Budget time for it.

What Comes Next

With policies in place, we're going to get into one of the more technically complex controls: change management. CC8 and CC9 are where the engineering team starts to feel the compliance burden most acutely — but done right, they actually improve your engineering practices.