Write down a requirement nothing actually enforces and you have created evidence that will be read aloud to you after the breach.
Policy exists to state what the company requires, in language one person can follow and another can check. Almost every failure we see happens at one of three points, and the drafting is never among them. The requirements cannot be enforced, nobody has read them, or nobody has touched them in four years.
- EnforceableOr it is a statement, not a policy
- ReadableWritten for the people bound by it
- OwnedA named owner per document
- GovernanceThe function added in CIS Controls v8.1
Eight things separating a real policy set from a folder full of files.
It states obligations rather than preferences
A document built on the word should is a list of preferences. Where something is genuinely required, say so and be ready to enforce it. Where it is advice, move it into a standard or a guideline where it belongs. Blending the two gives you a document nobody can be held to and nothing anybody can be measured against.
Every requirement is enforceable by something
Three options exist for any requirement: a technical control makes it true, a process catches when it is not, or a named person accepts that it is unenforced and signs that acceptance. A requirement with none of the three is an intention, and intentions get produced after incidents, in litigation, and during regulatory inquiries as proof the company knew exactly what it should have been doing and was not doing it.
It is written for the people bound by it
An acceptable use policy is read by the entire company and should sound like it. An encryption standard is read by three engineers and can be as technical as it needs to be. Writing everything in one voice produces documents nobody outside IT will read and documents that lack the precision engineers actually require.
Every document carries a name and a date on its front page
These documents rot without making a sound. Systems get replaced, obligations shift, people leave, and the file carries on describing a company that stopped existing years ago. Putting an owner and a review date on the cover is deeply unexciting, and it is the only thing that stops a policy set becoming a historical record.
The structure separates policy from standard from procedure
A policy says what is required and should almost never change. A standard says how that is achieved and moves when the technology moves. A procedure says which buttons to press and changes constantly. Merge all three into one file and the entire document needs re-approval every time an operational detail shifts, which is precisely why it stops being updated.
Anything touching people is reviewed by the right functions
Acceptable use, monitoring, discipline, and supervision of communications each carry employment and privacy consequences that differ from one state to the next. Even Microsoft builds its own message review capability around privacy by design, pseudonymizing usernames by default, gating access by role, and requiring an administrator to opt each investigator in. Nothing in this area should be drafted by engineers alone. Counsel and HR belong in the room.
Exceptions are a process, not an absence
Exceptions happen in every organization, and denying it only means they happen quietly and off the record. A written exception process with an approver, a reason, and an expiry date turns something unavoidable into something governed, and leaves you with a live list of where your own requirements are currently not met.
It supports the obligations you actually have
Policy is frequently the artifact an auditor, a regulator, or an enterprise customer asks for first. HIPAA expects documented policies from covered entities, SOC 2 auditors sample against them, and the FTC Safeguards Rule requires covered financial institutions to maintain a written information security program. Where the policy set maps to those obligations, the request is answered in one exchange. Where it does not, the same request produces weeks of mapping work under time pressure.
Every policy is a promise, and a promise you cannot keep leaves you worse off than silence.
It sounds backwards, and it is the most important thing to understand before commissioning any of this work.
- Commit in writing to patching every system inside thirty days, then miss it routinely, and you have manufactured a documented standard you visibly fail. That page turns up in the incident review, in the coverage dispute with your carrier, and in discovery. Having written it leaves you in a worse position than never having addressed the subject.
- The same applies to monitoring nobody performs, review cycles nobody runs, and an encryption requirement applied to roughly half the systems. Each one records that the company understood the obligation and failed it anyway, which is a materially worse place to stand than never having written it.
- The answer is not to write less policy. It is to write requirements the company will genuinely meet, enforce technically whatever can be enforced, detect the rest, and record openly where something is still an ambition along with the date it becomes an obligation.
- The result is shorter and considerably less impressive to look at, and it will hold up. We would far rather hand over eight documents a company actually complies with than twenty describing the company somebody once hoped it would grow into.
Four things that make a policy set hold up, as opposed to look good.
We only write requirements you will meet
Every requirement gets three questions: what makes this true, what would catch it being false, and who is signing to say it is unenforced. Anything failing all three either gains a control, gains a detection, gains a dated exception with an approver, or comes out of the document. That single test cuts most drafts down considerably and improves every one of them.
We separate policy from standard from procedure
The policy carries the requirement and should sit still for years. The standard carries the method and moves with the technology. The procedure carries the steps and changes constantly. Keeping the three apart means an operational tweak never triggers a policy re-approval, which is the only reason any set stays current.
We write each document for whoever actually reads it
Acceptable use gets read by everyone, so it stays short, plain, and clear about what happens if you ignore it. An encryption standard gets read by engineers and can be as dense as it needs to be. A set written throughout in the voice of an auditor is complied with by exactly the department that produced it, which leaves out most of the company.
We build the exception process before it is needed
Exceptions will happen. With no process they happen quietly, invisibly, and forever. With one, each carries an approver, a reason, and a date it dies, which gives you a live register of where your own requirements go unmet and a standing obligation to revisit each entry rather than forget it existed.
Six US situations where the policy set becomes the priority.
A regulated business whose examiner or auditor asks for policy first
Policy is usually the first thing anyone asks to see, and it gets read closely rather than skimmed. The FTC Safeguards Rule obliges covered financial institutions to maintain a written information security program, HIPAA expects documented policies from covered entities, and examiners in both worlds hold the paperwork up against what is actually happening. Where the set genuinely maps to your obligations, the request closes in one exchange. Where it came out of a generic template, every gap between the writing and the reality shows up in that same reading.
A business responding to customer security questionnaires
Nearly every enterprise questionnaire asks the same three things: do these named policies exist, when were they last reviewed, and who owns them. Each takes one sentence when the set is governed properly, and produces a distinctly uncomfortable pause when the review dates are from three years ago.
An organization pursuing SOC 2 or another attestation
SOC 2 is earned by showing controls operating over a period, not by producing documents, which makes an ambitious policy set actively harmful. The auditor samples against whatever your policy committed to, so every stretch in the writing becomes an exception in the report. What works is a set the company genuinely complies with, backed by evidence it ran, rather than a comprehensive one describing an aspiration.
An operator introducing monitoring of any kind
Anything about monitoring carries employment and privacy consequences that a technical author will not anticipate, and in the United States those consequences change from state to state. Microsoft designs its own message review capability around privacy by default, with usernames pseudonymized, access gated by role, and each investigator opted in individually by an administrator. Counsel and HR need to be drafting this alongside you, not reviewing it afterwards.
An organization with a policy set nobody has updated in years
This is the engagement we see most. The documents are perfectly competent, they describe systems replaced two procurement cycles ago, and the review dates expired before anybody currently employed arrived. Refreshing usually beats rewriting, because staff adopt a set they half-recognize far more readily than one that appears from nowhere.
A group standardizing policy across several entities
The structure that works is a group-level policy set with entity-level standards beneath it, because the requirement can be shared while the method varies by state, by system, and by size. Forcing one identical set across companies with genuinely different obligations produces documents that fit none of them properly.
How US organizations handle security policy.
| Feature | Enforceable and maintained | A comprehensive set, unmaintained | No formal policy |
|---|---|---|---|
Requirements stated clearly | Yes | Yes | No |
Requirements actually enforced | Yes | Partly | Not applicable |
Written for the intended reader | Yes | For an auditor | Not applicable |
Named owner per document | Yes | Rarely | No |
Review dates observed | Yes | No | Not applicable |
Policy, standard, and procedure separated | Yes | Conflated | Not applicable |
Exception process exists | Yes | No | No |
Legal and HR involved where needed | Yes | Sometimes | No |
Maps to actual obligations | Yes | Partly | No |
Position if quoted after an incident | Defensible | Damaging | Weak |
Twelve documents, and what each one is actually for.
Document
Information security policy
- What it establishes
- The top-level commitment, who owns what, and how every other document relates to it
Document
Acceptable use
- What it establishes
- What staff may and may not do, written for the whole company rather than for the IT department
Document
Access control
- What it establishes
- How access gets granted, reviewed, and taken away, and what counts as privileged
Document
Asset management
- What it establishes
- What qualifies as an asset, whose name is against it, and how it stays tracked
Document
Data classification and handling
- What it establishes
- The classification levels, and what each demands at rest, in transit, and at disposal
Document
Data retention and disposal
- What it establishes
- What is kept, for how long, and what gets deleted, which cuts attack surface as well as storage cost
Document
Change management
- What it establishes
- Which changes need sign-off, from whom, and what qualifies as an emergency
Document
Incident response
- What it establishes
- Declaration, authority, escalation, and notification obligations
Document
Business continuity and recovery
- What it establishes
- Objectives, responsibilities, and the testing commitment
Document
Vendor and third-party security
- What it establishes
- What is required of vendors and how it is assured
Document
Remote and mobile working
- What it establishes
- What is allowed, on which devices, and subject to which conditions
Document
Monitoring and privacy
- What it establishes
- What gets monitored, by whom, behind which safeguards, and under whose oversight
Five steps, and the enforceability test happens during drafting.
- 1
Establish the obligations and the current position
First, what you are genuinely obliged to meet, whether that comes from a regulator, a contract, an attestation, or a large customer: HIPAA, SOC 2, the FTC Safeguards Rule, one of the state privacy statutes, CMMC, or an enterprise agreement. Then what policy actually exists right now, what it commits you to, whose name is on it, and when anybody last opened it. Refreshing beats replacing in most cases, because familiarity does more for adoption than novelty.
- 2
Agree the structure and the document set
We agree which documents you actually need, how policy, standard, and procedure will be kept apart, and what each covers. A bigger set is not a better one. The right set is the smallest that satisfies your obligations while leaving nothing an assessor or a customer will ask about unanswered.
- 3
Draft, testing each requirement for enforceability
Each requirement is put to the same three questions: what enforces it technically, what would detect a breach, or who is accepting that it is unenforced and until what date. Anything failing all three comes out or gets downgraded. We apply this while drafting rather than at review, because it should shape what gets written rather than what gets cut.
- 4
Review with the functions that need to see it
Counsel and HR review anything touching acceptable use, monitoring, privacy, or discipline, which matters more in the United States because employment and privacy law varies state by state. Business functions review anything that changes how they work. Engineers review the standards. A set drafted by IT, reviewed by IT, and approved by IT binds precisely one department.
- 5
Publish, govern, and set the review cycle
Every document leaves with an owner and a review date on it, a defined route for approving changes, a written exception process with approvers and expiry dates, communication to the people it binds, and recorded acceptance wherever that matters. Then the first review goes in the calendar rather than remaining an intention.
What organizations ask about security policy.
Fifteen questions worth asking about the policies already sitting in your drive.
Is it real
- Pick three requirements. Are they enforced?Technically, or by detection.
- Is there a requirement you knowingly fail?That is the risk.
- Does it say should where it means must?Preferences are not policy.
- Does it reference systems you still run?Policies outlive platforms.
- When was each document last reviewed?Check the front page.
Is it read
- Can a non-technical employee understand it?Acceptable use especially.
- How do new hires receive it?And is acceptance recorded.
- How is a change communicated?Silent updates are not changes.
- Is it findable?Including when systems are down.
- Is it the right length?Length correlates with non-readership.
Is it governed
- Does each document have a named owner?A role, and a person.
- Who approves a change?And at what level.
- Is there an exception process?With approver, reason, and expiry.
- Are current exceptions recorded?They exist whether or not they are.
- Does it map to your obligations?That is what an auditor asks.
The pages around this one.
Pick three requirements from your policy set and ask what enforces each.
If the answer for any of them is nothing, that requirement is a documented commitment with no mechanism behind it. Finding those before somebody else does is the entire point of reviewing a policy set.
Related Services
Explore more solutions that work great with this service
Incident Response Plan Development
Incident response plan development for US organizations: decision
Learn moreIT Compliance
HIPAA, SOC 2, NIST, CMMC, CCPA readiness
Learn moreTenant Security Baseline
Documented controls mapped to CIS
Learn moreMicrosoft Purview
Data governance and compliance solutions
Learn moreMicrosoft 365 Security Audit
Independent Microsoft 365 tenant security audit for US organizations
Learn more