Security Policy Writing

You write policies people can follow and auditors can test. A good policy says what must happen, who is responsible and how you would prove it, in language a new employee understands on first read. The worst policy is a downloaded template that promises controls the company does not run: an auditor will test those promises and record every gap as a failure.

When to use

• "A customer wants our security policies."
• "We're starting SOC 2 / ISO 27001; we need the policy set."
• "Write us an acceptable use policy for new starters."
• "Our policies are three years old; update them."
• After an incident or a new system, when a policy no longer matches reality.

What you need

• Facts about the company: size, locations, remote or office, systems used, types of data held (customer personal data, payment data, health data), customers' contractual demands, target framework if any.
• Existing documents: old policies, handbook, onboarding checklists, contracts with security clauses. Read them from a connected Google Drive or Notion, or files the owner provides.
• Answers from the owner to the interview in references/policy-set.md (ask with clarify, a few questions at a time).
• Who approves policies (the owner or management) and who owns each one day to day.

Method

1. Interview before writing. Use the question list in references/policy-set.md. For each control area find out what actually happens today. Where practice and intention differ, write what happens today and record the improvement as a dated plan, not as current policy.
2. Choose the set. For a small company, one top-level information security policy plus roughly 8 to 12 topic policies is enough; references/policy-set.md lists the recommended set and what each must cover. Merge small topics rather than producing 30 documents nobody reads.
3. Use one structure for every policy:
   • header: title, owner, approver, version, effective date, next review date, framework mapping
   • purpose (two or three sentences)
   • scope (people, systems, data, locations)
   • roles and responsibilities
   • policy statements (numbered, so evidence and exceptions can refer to them)
   • exceptions (how to request one, who approves, how long it lasts)
   • enforcement
   • related documents (procedures, standards)
   • version history
4. Write the statements so they can be tested:
   • "must" for requirements, "should" for recommendations; avoid "may" for anything that matters
   • each "must" names who does what, how often, and what record proves it ("The IT owner reviews admin access every quarter and records the review in the access review log")
   • numbers instead of adjectives: "within 5 working days", not "promptly"
   • no control the company does not run today; future controls go in a dated plan
   • keep policy (what and why) separate from procedure (step-by-step how); link to procedures instead of embedding them
   • plain English, short sentences, no legal flourishes
5. Map to the framework if one is in play: SOC 2 Trust Services Criteria references (CC1 to CC9 and any additional categories), ISO/IEC 27001:2022 clauses and Annex A control numbers, or GDPR articles. Put the mapping in each policy header and keep a mapping table across the set. Cite the framework version.
6. Check consistency across the set: the same numbers everywhere (review frequency, leaver removal time, password rules, data retention periods), the same role names, no contradictions.
7. Get legal review where policies have legal effect: employee monitoring, data retention periods required by local law, disciplinary consequences, privacy notices. Say this explicitly to the owner; you do not decide these.
8. Approval and rollout: the approver signs and dates each policy (ISO 27001 requires top management to establish the information security policy); staff acknowledge the policies that apply to them; publish them where staff can find them; record acknowledgements as audit evidence.
9. Schedule the annual review with cronjob, plus a trigger to revisit after incidents, major system changes or new regulations.

Turning weak statements into testable ones

Weak	Testable
"Access is granted on a need-to-know basis."	"Access to production systems must be approved by the engineering lead before it is granted, and the approval is recorded in the access ticket."
"Leavers' access is removed promptly."	"IT removes all access within 1 working day of a leaver's last day and records completion on the leaver checklist."
"Systems are patched regularly."	"Critical security updates must be applied to internet-facing systems within 14 days of release; exceptions are recorded with a review date."
"Data is backed up."	"Production databases are backed up daily; a restore is tested every quarter and the result is recorded."
"Staff receive security training."	"Every employee and contractor completes security awareness training within 30 days of joining and every 12 months; HR keeps completion records."
The numbers in the right-hand column are examples. Use the numbers the company actually meets, or will commit to.

Revise before the annual review when

• a security incident showed the policy was wrong, unclear or not followed
• a new system, supplier or type of data arrives (for example the company starts taking card payments)
• the company enters a new country or market with different legal duties
• a customer contract commits the company to something stricter
• the framework or regulation it maps to publishes a new version Record each revision in the version history with what changed and who approved it.

For very small companies

Under about ten people, one combined "Information Security Handbook" with a section per topic is often better than separate policies, as long as each section keeps its own owner, statements and review date, so it can still be mapped to a framework.

Output

• One markdown or document file per policy, using the structure above, saved to the owner's drive or workspace.
• A policy register: policy, owner, approver, version, effective date, next review, framework mapping, status.
• A list of "plan" items: improvements the owner chose to make, with owners and dates, kept out of the policy text until done.
• A show_card with the register.

Checks before you finish

• Every "must" is something the company does today, or is clearly marked as a dated plan item outside the policy.
• Numbers and role names are consistent across all policies.
• Each policy has an owner, an approver and a review date.
• Framework mappings name the framework version.
• Items needing legal review are listed and sent to the owner.
• No legal flourishes, and no vague adjectives where a number belongs.

Pitfalls

• Copying a big-company template. It promises a security team, a change board and quarterly audits that do not exist. Every unfulfilled promise becomes an audit exception.
• Policy as procedure. Step-by-step instructions in a policy go stale fast. Keep them in linked procedures.
• Aspirational wording. "We are committed to world-class security" proves nothing and cannot be tested.
• No owner. A policy without a named owner is never reviewed.
• Forgetting acknowledgement. Unread policies do not protect anyone and do not count as evidence.
• Sign-off. The owner or management approves every policy. Legal counsel reviews anything touching employment law, monitoring, privacy notices or statutory retention.

Recommended set and interview questions: references/policy-set.md. Credits: references/CREDITS.md.