Writing Your First IT Security Policy: A Founder Is Guide

You need an IT security policy. Maybe it is for SOC 2. Maybe an enterprise customer asked for it. Maybe you just realized that your company has no written rules about how to handle sensitive data, and that makes you nervous. Writing policies that match how you actually operate, rather than a template nobody follows, is part of what a fractional CISO does.

Good news: your first security policy does not need to be 100 pages. It needs to be clear, enforceable, and honest about how your company actually operates.

The policies you actually need

Start with these seven. They cover the requirements for SOC 2 and most enterprise security questionnaires:

1. Information Security Policy (2-3 pages). The umbrella document. It defines: who is responsible for security (usually the CTO or a designated security officer), the scope of the policy (all employees, contractors, and systems), and the high-level principles your company follows (least privilege, defense in depth, security by design).

2. Access Control Policy (2-3 pages). How access to systems and data is managed. Cover: how access is granted (manager approval), how access is reviewed (quarterly), how access is revoked (same-day on termination), authentication requirements (MFA required for all systems), and the principle of least privilege (no more access than needed for the role).

3. Data Classification and Handling Policy (2-3 pages). Define data categories: Public (marketing materials, blog posts), Internal (company financials, internal docs), Confidential (customer data, source code), and Restricted (credentials, encryption keys). For each category, define how data should be stored, transmitted, and disposed of.

4. Acceptable Use Policy (2-3 pages). What employees can and cannot do with company devices and accounts. Cover: permitted personal use (reasonable personal use is fine), prohibited activities (do not install unauthorized software, do not use company email for personal purposes), password requirements (use the company password manager, unique passwords for every service), and reporting obligations (report suspected security incidents immediately).

5. Incident Response Policy (3-4 pages). What happens when a security incident occurs. Define: what constitutes a security incident, who to contact (incident response team or designated contact), the response process (identify, contain, eradicate, recover), communication procedures (internal and external), and post-incident review requirements.

6. Change Management Policy (2-3 pages). How changes to production systems are managed. Cover: all changes require code review and approval, changes are deployed through the CI/CD pipeline (no manual deployments), significant changes require testing in a staging environment, and emergency change procedures for urgent fixes.

7. Vendor Management Policy (2-3 pages). How you evaluate and manage third-party tools and services. Cover: vendor evaluation criteria (security posture, SOC 2 status, data handling practices), approval process for new vendors, periodic review of existing vendors, and requirements for data processing agreements.

How to write them

Start with templates. Compliance platforms like Vanta and Drata provide policy templates that you can customize. Alternatively, use free templates from SANS (sans.org/information-security-policy) as a starting point.

Customize for reality. If your policy says "all employees complete security training quarterly" but you have never run security training, the policy is aspirational, not real. Write policies that describe your current practices and add a section for planned improvements. An honest policy that describes what you actually do is better than a perfect policy that nobody follows.

Keep them short. A 3-page policy that people read is better than a 30-page policy that nobody reads. Save the detailed procedures for runbooks and operational documentation. Policies define the "what" and "why." Procedures define the "how."

Getting buy-in

Policies without buy-in are shelf-ware. Have every employee read and acknowledge the policies (electronically is fine). Walk through the key points in a team meeting. Make the policies accessible (a shared Google Drive folder or a Notion page, not a PDF buried in an email).

Review and update policies annually. Requirements change. Tools change. Processes change. Outdated policies create a false sense of security.

Policy, Standard, Procedure: Getting the Layers Right

Most first-time policy sets fail because everything gets crammed into one layer. A policy states intent and obligation: access is granted on the principle of least privilege and approved by a manager. A standard states the specific, testable rule: MFA is required on all systems and passwords are a minimum of 14 characters. A procedure states how somebody does it: here is how you provision a new engineer in Okta, step by step.

Keeping these separate changes how often you have to go back to your executive team for reapproval. Policies rarely change. Standards change when your tooling changes. Procedures change constantly and should live in your engineering wiki. If you write "engineers are provisioned through Okta using the runbook in Notion" into an approved policy, you have to reapprove it the day you migrate identity providers.

What an Auditor Actually Tests

Auditors do not grade your prose. For every policy in scope they test four narrow things, and knowing them changes what you spend effort on.

Approval. Who approved it, when, and whether they had the authority. Board minutes, a signed cover page, or a document system with an approval record all work. A policy approved by the person who wrote it with no oversight is weak.

Review cadence. Your own policy almost certainly says it is reviewed annually. The auditor will check the last review date against that commitment. A policy last reviewed 16 months ago is an exception against your own stated rule, not against any external standard.

Distribution and acknowledgement. They pull a sample of employees, usually including a recent joiner and a leaver, and ask for acknowledgement records. Timing is what catches people: if your policy says new hires acknowledge within 30 days and somebody signed on day 60, that is an exception even though they signed.

Consistency with practice. The auditor reads your policy, tests the environment, and compares. Everything else on this list is paperwork. This is where policies actively hurt companies.

Do Not Promise What Your Operations Cannot Deliver

Here is the failure mode that costs startups the most, and it comes straight out of templates. A template says critical vulnerabilities are remediated within 24 hours and high severity within 7 days. It sounds responsible, so it stays in. Nobody notices that your actual practice is to look at scanner output on Tuesdays.

Twelve months later the auditor takes your scanner data, filters to critical findings, and measures time to closure against the number in your own policy. You now have exceptions on a control that would have passed comfortably if the policy had said 30 days for critical and 90 for high, which is what you actually do and which is a defensible position for a company your size. The policy created the finding. Nothing in SOC 2 or ISO 27001 dictated 24 hours; you did.

The same trap sits in half a dozen template clauses: quarterly awareness training when you run it annually, penetration testing twice a year when you budget for one, log retention of 12 months when your plan retains 30 days, access reviews monthly when you can barely sustain quarterly. Read every number in a template and ask whether you can produce evidence of it every single time for the whole audit period. If not, change the number before approval, not after the finding.

Writing down a weaker commitment you honor is a stronger position than a strong commitment you miss. Auditors report against what you said. Buyers occasionally push back on a specific number, and that is a negotiation you can have with a straight face.

The Exception Process Nobody Builds Until They Need It

Real companies break their own policies. An engineer needs standing production access for a migration. A legacy service cannot support MFA. Without a documented exception process, each of these becomes either an undocumented violation or a reason to water down the policy for everyone.

Build one page. An exception record names the rule, the system, the reason, the compensating control, the approver, and the expiry date. Expiry is the part that matters, because an exception with no end date is a policy change made quietly by one person. A company with six documented, time-bounded, approved exceptions reads as mature. One with zero exceptions and an environment full of them reads as unaware.

Signs an Auditor Is Reading a Template

Reviewers develop a fast instinct for unedited templates, and once they suspect one they test harder everywhere else. The tells are consistent: references to a Chief Information Security Officer when nobody has been designated, badge access and server room clauses when you are fully remote, procedures written for Windows Active Directory when the company runs on Macs and Google Workspace, a bracketed placeholder somebody missed, or a dozen policies all approved on the same date by the same person.

Templates are a fine starting point and you should use one. The work is the two hours per policy spent deleting what does not apply and rewriting what does. That is the entire value of having the policy.

Which Policies to Add, and What Triggers Them

The seven above cover the ground for a first SOC 2 and most questionnaires. The rest should be added when something specific triggers them, rather than all at once.

A business continuity and disaster recovery policy becomes necessary the moment you sign an availability commitment, and it needs a tested restore behind it. A risk management policy is mandatory for ISO 27001. A secure development policy matters once a buyer asks how you handle code review and dependency vulnerabilities. A cryptography and key management policy shows up when you handle regulated data or answer PCI questions. A data retention and disposal policy becomes urgent under PIPEDA and Quebec's Law 25. A remote work and device policy is worth having as soon as people use personal machines for work.

The newest addition is an acceptable use policy for AI tools, now a live question in security questionnaires. It needs to say which tools are approved, what data may never be pasted into them, whether customer data may reach a model provider, and who approves new ones. Companies without one are not avoiding the risk, they are just not managing it.

When Policy and Practice Have Already Diverged

If you are mid-audit and have found a gap between what your policy says and what you do, the instinct is to quietly update the policy. Do not backdate anything. Auditors check document histories, and a backdated approval puts your management assertions in question rather than a single control.

The clean move is to record the gap as a finding you identified yourself, write a corrective action with an owner and a date, update the policy with a real approval date, and hand all of it over. Self-identified findings with remediation in flight are read as evidence your program works.

When You Should Skip Hiring Anyone

Most startups can write their first policy set themselves, and we will say that before quoting anybody. Under about 25 people, on one cloud provider and one identity provider, with no regulated data, a technical lead with a good template, two focused afternoons, and the discipline to delete every clause that does not describe reality will produce a policy set that passes a first SOC 2. Paying several thousand dollars for documents about a company someone has to interview you to understand is not obviously better.

Outside help earns its cost in narrower situations. When the policy has to satisfy a specific rule set, HIPAA or PCI DSS or a federal supply chain requirement, and getting the wording wrong is expensive. When you have grown past the point where one person knows how everything works. When an auditor has already issued findings and you need somebody who reads audit language for a living. Or when the real problem is that nobody owns security decisions, which is a fractional CISO problem rather than a document problem.

If you want a place to keep approval and acknowledgement records without paying for a compliance platform yet, the free traztech Workspace holds policies against the controls they satisfy. If a buyer has already handed you a requirement, tell us what they asked for and we will tell you which parts you should do yourself.