The policy set for a company that has none. About 20 policies in plain markdown, mapped to CIS Controls v8, written so an employee can actually read them.
Most policy templates are compliance artifacts. Long, written in a voice no human uses, and nobody opens them after the day they get approved. A policy nobody reads isn't a control. It's a document.
These are written to be read.
Your 40-page acceptable use policy is not a control. It's a document. Every policy in here is under two pages, second person, with a reason for every rule.
Notes on a Cocktail Napkin in Sharpie Beat Nothing, and a two-page policy people follow beats a forty-page one they don't. The bathroom door version of this argument is in PRINCIPLES.md.
- Companies with no formal policies who need to start somewhere
- IT and security leaders who inherited a policy set from 2016 that mentions fax machines
- vCISOs and consultants standing up a program from zero
- Anybody prepping for a first SOC 2, a customer security review, or a cyber insurance application
Companies with mature policy sets who just need gaps filled. Cherry-pick instead.
Anybody in a heavily regulated sector expecting these to satisfy a specific regulator. They won't without real work.
Three documents, three jobs. Most companies smash them into one and then wonder why nobody reads any of it.
| Answers | Names tools? | Changes when | Approved by | |
|---|---|---|---|---|
| Policy | What we do | Never | The business changes | Leadership, legal |
| Procedure | How we implement it | Sometimes, by category | The approach changes | Function owner |
| Guide | Step by step | Always | The tool changes | Whoever owns the tool |
"You must use multi-factor authentication on every account that supports it" is true whether you run Entra, Okta, or Duo. It stays true when you rip all three out next year. That is a policy.
The second a product name lands in a policy, the policy has an expiration date. You switch vendors and legal has to re-approve a document that did not actually change. Do that twice and people stop believing policies mean anything.
Split them and each one moves at its own speed. Swap password managers and you rewrite one guide. The policy does not move. Legal never hears about it.
Full write-up: POLICY-PROCEDURE-GUIDE.md.
Foundation. Information Security, Acceptable Use, Data Classification, Access Control, Password and MFA
Operations. Endpoint and Device, Change Management, Logging and Monitoring, Backup and Recovery, Vulnerability and Patch Management
People. Security Awareness, Remote Work, Email and Phishing, Physical Security
When Things Go Wrong. Incident Response, Business Continuity and DR
Governance. Vendor Management, AI Acceptable Use, Exception and Risk Acceptance, Policy Governance
Plus a CIS v8 mapping, a 12-month rollout plan, and the style guide these follow.
Read style-guide.md before you write a word. It's the shortest file in here and it's why these read differently from every other policy set on GitHub.
Under Two Pages. Doesn't fit? It's two policies, or it's a procedure. Procedures live somewhere else.
Second Person. "You must turn on MFA." Not "Employees shall ensure that multi-factor authentication is enabled." People follow instructions aimed at them. They skim instructions aimed at a category.
Say Why. One sentence of reason per rule. That's not padding, that's the enforcement mechanism. People follow rules they understand and route around rules they don't.
Nothing You Can't Check. A rule nobody enforces teaches people that rules are optional. That lesson carries over to the ones that matter.
Name a Person, Not a Department. Departments don't review policies. People do.
The Security Awareness policy in here is built around a thing that actually works: teach people to secure their own stuff first.
Password manager on their phone. MFA on their bank. Freeze their credit. They'll do it, because it's their money and their family. Then doing it at work stops being a rule and becomes a habit they already have.
If you're on Bitwarden Enterprise, every employee already has a free Families plan sitting there. Them plus five people, all premium features, no extra cost. Most companies pay for it and never mention it. Turn it on and send one email.
Worth saying up front because it shapes half this policy set.
Somebody downloads the customer list the week before they quit. The reflex is to buy DLP. But that's a manager who didn't know their person was leaving, an offboarding process that starts too late, and probably a reason they're walking.
Policies here try to name the right owner for the actual problem. A lot of what lands on the security team isn't a security problem, and writing a technical rule for it just moves the failure somewhere quieter.
Worth knowing before you write the Acceptable Use policy, because it's easy to write one that makes things worse.
People running unapproved tools are usually blocked from doing their job, or they know a better tool exists, or they don't know what they already have, or somebody out-marketed you. Consumer "privacy" VPNs are the classic. Real security uses exist. Almost none of them apply to somebody on Facebook at a hotel.
Write a policy that punishes shadow IT and you don't get less of it. You get better-hidden shadow IT, and you lose the person who was going to tell you about the next one.
The Acceptable Use policy here says what's off limits and why, and points people at how to ask for something instead. That second half is the part that works.
Don't Publish All Twenty at Once. They'll get approved, filed, and ignored. rollout-plan.md has the sequence, roughly:
- Months 1-2. Information Security, Acceptable Use, Password and MFA. The foundation and the two everybody touches daily.
- Months 3-5. Data Classification, Access Control, Endpoint. The ones that shape how work happens.
- Months 6-8. Incident Response, Backup, Vendor Management. The ones that matter when something breaks.
- Months 9-12. Everything else, plus a review of the first batch.
Each one gets an announcement, a short plain explanation of what changed for people, and a name to ask. Skip that and you didn't roll it out, you filed it.
It's in here because in 2026 a policy set without one isn't finished, and because if you don't publish one people will use AI anyway with zero guidance.
For the full version, with the intake workflow, tiering, agent controls, and board oversight, see ai-governance-kit.
policies/ 20 policies. What we do. No vendors, no tools.
procedures/ 10 procedures. How we implement it.
guides/ 8 guides. Step by step, all tool.
mappings/cis-v8.md every policy mapped to CIS Controls v8
rollout-plan.md 12 months, because 20 at once means none get read
style-guide.md the writing rules. Read this first.
POLICY-PROCEDURE-GUIDE.md the three-document split
Everything ships as a structured draft. Policies carry the skeleton and the writing rules. Procedures and guides are stubs on purpose, because they depend on your stack.
Not legal advice, not regulatory guidance, not a compliance program. Adopting these doesn't make you compliant with anything.
They're drafts. They need your company name, your actual systems, your real approval process, and a look from whoever owns legal risk. A policy describing a process you don't follow is worse than no policy, because now you've documented not doing it.
Nothing here comes from a client engagement.
Want: sector variants, policies I missed, and rewrites that say the same thing in fewer words. That last one especially.
Nothing client-identifiable. See CONTRIBUTING.md.
CC BY 4.0. Use it, change it, use it commercially. Just say where you got it.
© 2026 Harrison Ward
Cyber risk and technology exec. Built and ran a firm-wide security program as CTO of a 175-person, five-office firm, including a full rewrite of policies, processes, and controls. Most recently SVP in Kroll's Cyber Risk practice.
github.com/HarrisonWard · LinkedIn
Published under these principles. Security Shouldn't Be Paywalled.