Somewhere out there is a 60-page IT policy binder, downloaded from a template site, signed by employees who never read it, sitting in a drawer answering no questions. That’s what “policy framework” usually produces at small-business scale — and it’s worse than nothing, because it creates the feeling of governance without any of the behavior. The working alternative: five short policies, each answering questions that actually come up, each brief enough to read in five minutes. Here they are, with what each one must say.

Why write anything down at all

Three reasons, all practical. Consistency: without a written rule, every situation gets decided fresh by whoever’s nearest, and the decisions drift. Protection: when you have to act — a termination involving misuse, an incident involving an employee’s account — the written policy is what makes the action defensible. Obligation: insurers, regulators, and increasingly your own clients’ vendor questionnaires ask for specific policies by name; “we sort of have an understanding” doesn’t check the box.

The rule that governs all five: a policy only counts if it describes what actually happens. A policy that bans what everyone does daily is a liability with a signature line. Write what’s true, or change what’s true first.

Policy 1: Acceptable use — the one everyone signs

What company technology and accounts may be used for, in plain language: reasonable personal use is fine (say so — pretending otherwise just makes the policy fiction), what’s prohibited, the expectation that company data stays in company systems, and a clear statement that company systems belong to the company. This is the policy every employee signs at hire — the one an onboarding checklist makes automatic. One page.

Policy 2: Access and accounts

Who gets access to what, and the lifecycle: access granted by role, minimum necessary · MFA required, with the short exception process named · passwords via the company password manager, never shared · admin rights separated from daily accounts · and access removed same-day at departure, per the offboarding checklist the policy points to. This is the policy auditors and insurers read first, because it’s the one whose failures cause claims.

Policy 3: Data handling

Where the sensitive stuff lives and how it moves — which is trivially short if you’ve done the three-bucket classification first, because this policy is just those rules with a signature block: what counts as Restricted, the named systems it lives in, how to send it when a client asks (portal or secure link, never a plain attachment), and no company data in personal accounts. Add the retention line — what we keep and for how long — and you’ve covered what most vendor questionnaires ask.

Policy 4: Remote work and devices

The questions hybrid work generates weekly: company access from managed devices, with MFA, over approved paths · what’s allowed from personal devices (be honest and specific — email in the sanctioned app, yes; downloading the client database, no) · encryption on anything portable · and the lost-device rule: report immediately, no blame attached — because the policy’s real job is making the report happen fast, and fear is what slows it.

Policy 5: Incident reporting — the shortest and most important

One paragraph everyone can recite: if you clicked something, lost something, or saw something weird — tell [name/number] immediately; you will never be punished for reporting fast. The no-blame sentence isn’t decoration; it’s the entire mechanism. The incidents that get expensive are the ones nobody mentioned for three days, and a culture where fast reporting is praised outperforms most technology it accompanies. This policy connects to your incident response and communication plans — but the employee-facing version is that one paragraph.

Making them real

Format each policy the same way: a plain-English rule, the why in one sentence, and who to ask. Version and date them. Introduce them in one meeting, not a memo — the meeting is where “reasonable personal use” and “no-blame reporting” get said out loud, which is what makes them believed. Revisit annually in the same pass as your IT plan: what changed, what’s no longer true, what new question came up this year that deserves a sentence. Five pages, reviewed yearly, describing reality — that’s a policy framework that actually governs. The binder was never the point.