Resource
Your Security Blueprint: 7 IT Policies Every Business Should Have in Writing
Most businesses run on an unwritten assumption that everyone knows what they should and shouldn't do with company systems. That works fine until it doesn't. And when it doesn't, an unwritten assumption doesn't just look bad to an auditor. It can be the reason a cyber insurance claim gets denied.
Why everyone just knows isn't a policy.
Most small and mid-sized businesses operate on handshake logic: an informal, shared understanding of acceptable behavior that was never actually written down. It holds up fine during normal operation. It falls apart the moment something goes wrong, a phishing click, a lost laptop, a departing employee with lingering access, because there's nothing documented to point to.
This is where the real exposure sits. Most cyber insurance applications ask directly whether specific policies exist and are enforced: acceptable use, access control, incident response. A business answers yes because the practice generally happens, even though nothing is written down. If a claim is ever filed, the carrier can ask for the documented policy and the evidence it was followed. An unwritten policy that everyone just knew is not something a carrier can verify, and a policy that can't be verified is functionally the same as a policy that doesn't exist. That gap is exactly how a claim gets denied after the incident that was supposed to be covered.
Policies are what your security baseline looks like on paper.
A technical security baseline, MFA enforced, endpoints protected, access reviewed, is only half the picture. The written policy is what proves that baseline is a standard the business actually holds itself to, not just a set of settings that happen to be configured today. Our own Standards & Security Baseline is the technical floor every environment we manage runs on. These seven policies are how that floor gets written down in a form an insurer, an auditor, or a court can actually rely on.
The seven policies worth having in writing.
Acceptable Use Policy. Defines the line between business and personal use of company systems, and gives HR something enforceable to point to.
BYOD Policy. If personal devices touch company data, this defines the security minimums and the offboarding process before it becomes a gap nobody planned for.
Password and MFA Policy. Moves past assuming MFA is basically on toward a documented standard for where it's required and how credentials are managed.
Remote Access Policy. Defines how off-site work connects to company systems, closing the gap between having a VPN and the VPN actually being required and enforced.
Data Retention Policy. How long different types of data are kept and how it's disposed of, which matters as much for a subpoena as it does for a breach.
Incident Response Policy. Who does what, in what order, when something goes wrong, decided in advance instead of during the event.
Employee Training Policy. Makes security awareness a recurring, documented practice instead of a one-time onboarding checkbox.
Why an unenforced policy can be worse than no policy at all.
A written policy that doesn't match what's actually happening is not a neutral gap, it's a liability. This is exactly how a claim gets denied: the cyber insurance application asked whether a policy existed, someone answered yes because the practice generally happens, and the carrier later finds out during a claim investigation that the policy was never actually enforced, or never actually existed in the form that was represented on the application. At that point, the carrier isn't just declining to cover a gap. They're pointing to a specific answer on a signed application that wasn't true, and that's grounds to deny the claim entirely, not just the part connected to the missing control.
That outcome is worse than never having claimed the policy existed in the first place. It converts a security gap into a misrepresentation on an insurance contract. The value of these seven policies comes entirely from being real: written, enforced, and kept current against what the environment actually does, so that what's on file matches what was told to the carrier. That's the difference between a policy that protects the business and paperwork that quietly voids the coverage it was supposed to secure. See Governance, Risk & Compliance and our guide on what should be in a managed IT contract.
Common questions
Questions leadership usually asks first.
Continue reading
Related work and reading.
Standards & Security Baseline
The technical floor these policies put in writing.
Read more: Standards & Security BaselineGovernance, Risk & Compliance
Full policy development and lifecycle management, not a one-time document.
Read more: Governance, Risk & ComplianceCyber Insurance IT Requirements
The broader set of controls carriers expect evidence for, not just policies.
Read more: Cyber Insurance IT RequirementsNext step
Get a clearer view of your IT environment.
Find out what is working, where the risks are, and what needs attention next.