A policy nobody follows is just decorative

Every organisation has policies.

Usually in SharePoint.
Usually in a folder called Policies.
Sometimes in Policies - New.
And occasionally in something like Policies - Final - Approved - Use This One, which contains three versions of the same document.

This is normal. Not ideal, but normal. The problem isn’t a lack of policy. Most places have plenty. The problem is that policy and reality don’t always line up.

A document says access is reviewed.
Access isn’t reviewed.

A policy says changes are recorded.
Changes happen in Teams.

Devices are supposed to be managed.
Unmanaged ones still appear on the network like they pay rent.

At that point, the policy isn’t doing anything.

It’s just there.

“We have a policy”

There’s a habit of treating policy existence as risk management.

“We have an access policy.”
“We have a change process.”
“We have an incident plan.”

That’s fine. But having a document isn’t the same as having control but a policy nobody follows doesn’t reduce any risk.

And when something goes wrong, nobody asks if the policy exists. They ask if it works.

Can you show access was reviewed?
Can you show changes were approved?
Can you show devices are known and managed?

If the answer is “we should be doing that”, then the policy isn’t doing much.

Why policies drift away from reality

It usually comes down to a few things.

They’re written in a way nobody actually reads.
They sit outside the tools people use every day.
Nobody really owns them.
They slow things down without adding anything useful.
Leadership doesn’t push for them to be followed.

None of that is unusual. But it does mean the policy becomes optional.

What a policy needs to do

It doesn’t need to be long.

It just needs to be clear:

• what risk are we managing
• what are people expected to do
• who is responsible
• where this shows up in day-to-day work
• how we know it’s working

If it can’t answer those, it’s probably not ready.

Where policy should show up

You should see policy in how things actually happen.

• access requests
• onboarding and offboarding
• change records
• incident handling
• device builds
• approvals

If none of that changes after a policy is written, then nothing really changed.

The document might be new. The behaviour isn’t.

Making it usable

Most people don’t need to read a full policy library.

They need to know what applies to them, and what to do.

That usually means:

• a short, plain version of the policy
• clear steps for common situations
• rules built into the tools people already use

If access needs approval, make it part of the request.
If changes need tracking, make it part of the workflow.

Can you tell what I’m working on at the moment?