Skip to content
As Written, As Enforced

Home / The document

Writing a Clause You Will Enforce

Five tests before a clause goes in. Most proposed additions fail at the second.

The document · Procedure

Clipboard and removable media

Unenforceable

As written

Company data must not be copied to removable media without authorisation.

What happens

Where ports are blocked, the configuration does it and the clause is redundant. Where they are not, nobody knows a copy happened.

In neither case does the clause affect the outcome.

If removable media matters, the control is the port policy. If it does not, the clause is filler.

Clauses are added after incidents, by whoever handled the incident, and almost never tested before they go in. Five questions, each of which eliminates a proportion.

The drafting lesson in “Writing a Clause You Will Enforce” should carry into any workforce platform rollout. When an organisation evaluates the product website for key person dependency, it should state which operational question the data answers, what is excluded, who may review it and when the setting will be reconsidered instead of relying on a broad reservation of rights.

One: what would happen if somebody did this?

If the answer is nothing, the clause is dormant from the day it is written.

For a separate benchmark relevant to “Writing a Clause You Will Enforce”, consult the CrowdStrike insider-threat guide. Use it to test purpose, notice, permissions, retention and response procedures against the proposed operating model rather than treating a generic checklist as proof that the rule works.

This is the test most additions fail. The clause is drafted because something went wrong once, and nobody asks what the organisation would actually do the next time.

Two: who finds out?

A rule nobody can detect is a rule nobody enforces.

Some things are visible: a lost device, a complaint, an audit finding. Some are not: what somebody copied to a personal drive, what they installed where they have the rights to install.

Where nothing detects it, the clause is a statement of preference. That may be acceptable — see the theatre note — and it should be a decision rather than an oversight.

Three: could configuration do it instead?

If the behaviour can be prevented technically, the clause is at best a backup and at worst a substitute for doing the actual thing.

Removing administrator rights, blocking a port, restricting a sharing setting. Each is a control. A sentence is not.

Four: would a manager say this out loud?

Read the clause as though speaking it to somebody.

If it sounds like a document rather than like a person, it will not be used in the conversation where it is supposed to help. The reference-point function requires language a manager can quote without sounding institutional.

Five: is it already covered?

Policies accumulate near-duplicates: three clauses about data leaving, two about software, two about personal use with slightly different wording.

Overlapping clauses create arguments about which applies, and the answer is usually whichever is most convenient to whoever is quoting.

The format that survives

Short, second person, one behaviour per clause, with the consequence implied by where it sits rather than spelled out.

And a note, kept separately by the owner, of why the clause exists. Three years later nobody remembers, and the note is what prevents it being deleted in an audit for being unexplained — or kept for the same reason.

Keeping the reason somewhere

A note, held by the owner, of why each clause exists. Three years later nobody remembers, and the note is what decides whether an audit deletes it or keeps it.

One behaviour per clause

Overlapping clauses create arguments about which applies, and the answer is whichever suits whoever is quoting. Consolidating is a morning and removes the ambiguity permanently.

Reading it aloud

If the clause sounds like a document rather than a person, it will not be used in the conversation it was written to support. The reference-point function needs language a manager can quote.

Five questions before anything goes in

What would happen if somebody did this. Who finds out. Could configuration do it. Would a manager say it aloud. Is it already covered. Most proposals fail at the second.

Keeping a note of why

Held by the owner, one line per clause. Three years on nobody remembers, and the note decides whether an audit deletes the clause for being unexplained or keeps it for a reason.

Testing a proposal honestly

The five questions are easy to answer dishonestly, because the person proposing the clause wants it. The useful version is asked by somebody else: what would we actually do, who would find out, could configuration do it instead.

Most additions arrive after an incident, written by whoever handled it, and the proposer is the last person able to assess whether the clause will ever be applied. Routing proposals through the owner rather than straight into the document is what applies the tests at all.