Every business that adopts a policy discovers the same thing six months later: nobody reads page four. The document exists, it went out by email, two people opened it, and the rules inside are now doing about as much work as the folder they sit in.
A policy tells people what to do. A control makes sure it happens whether anyone remembers it or not. Most security advice aimed at small businesses blurs the two, which is how a company comes to believe it has handled a risk when what it has is a paragraph about the risk.
What each one is
A policy is a written rule people agree to follow. It works through attention and goodwill: someone has to remember it and apply it in the moment that calls for it. That makes a policy cheap to write and quick to change. It also leaves the outcome with whoever is at the keyboard on a busy afternoon.
A control is a technical measure that enforces the rule automatically. A tenant setting that refuses a weak password. A rule that stops a spreadsheet of customer records from being attached to an outbound email. A filter that will not let an unapproved application connect to your company data. A control has no opinion about whether anyone read the policy.
Security frameworks have their own vocabulary for this, calling the written and trained parts administrative controls and the enforced parts technical controls. The plain version holds up fine for deciding what to do on Monday, so this guide says policy and control.
The gap between them
Policy without control is compliance theater. It looks convincing in an audit binder and does nothing on a Tuesday afternoon. Say your policy forbids client data in unapproved AI tools, and your Microsoft 365 tenant has no data loss prevention configured. The first time someone forwards a customer export to their personal account to drop into a chat box at home, the policy’s only remaining function is telling you whose fault it was. You still get the phone call from the client.
Control without policy fails differently. It breeds workarounds, because staff route around restrictions nobody explained to them. Block external file sharing with no explanation and the 40MB file goes out through somebody’s personal Gmail on a Sunday. The work still got done. It got done somewhere you have no visibility into, which is a worse position than the one you started in.
The two halves cover each other’s weakness. The policy tells people what the business expects and why, so the control lands as a boundary with a reason behind it. The control makes sure the expectation survives the week nobody has time to think about it. When people ask which one they need, they are usually looking at a pair where one half is missing.
Three examples you already know
| The rule | The policy | The control |
|---|---|---|
| Passwords should be hard to break | A written password standard staff agree to follow | Tenant settings that enforce length and screen for breached passwords, plus MFA |
| AI tools should not receive client data | An AI acceptable use policy naming approved tools and forbidden data | DLP rules on client records and app controls that block unsanctioned tools |
| Nobody should be able to send email as your domain | There is no useful policy here | SPF, DKIM, and DMARC records published on your domain |
Passwords. The policy is the standard you write down: how long, how they get stored, what happens when one is suspected of leaking. Current NIST guidance has moved away from the symbols-and-quarterly-resets school, so the written standard in most businesses is due a rewrite anyway. The control is what your tenant does with that standard: minimum length enforced at the point of change, known-breached passwords refused, and multi-factor authentication so a password on its own is never enough to get in. That last piece needs attention of its own right now, because Microsoft is retiring SMS and voice MFA, and any account still relying on phone codes has a control that is about to stop working.
AI use. The policy is the part that handles judgment. An AI acceptable use policy names which tools are approved, which tier of each one, and which categories of information may never go into them. No control can make those calls for you, because they depend on your clients and your contracts. The control is what catches the decisions nobody makes consciously. Data loss prevention rules that recognize client records and stop them leaving by email or file share, and app controls that keep an unsanctioned tool from connecting to your Microsoft 365 data in the first place. Catching a paste into a browser window takes endpoint-level DLP, which sits above the Business plans. Be honest with yourself about the limit here: neither one reaches a personal phone unless the work apps on that phone are managed, and even then the browser sitting next to them is not. That is exactly why the policy has to be something staff are willing to follow when nothing is watching.
Email spoofing. This row is the useful contrast, because there is no policy worth writing. Nothing your staff do or avoid doing prevents an outsider from forging your domain in the From field of an email to your customers. SPF, DKIM, and DMARC are three records in your DNS, and they either exist and are correct or they do not. That makes it a pure control with no human dependency, and one of the few security jobs that stays done, needing attention only when you add a new sending service or when the DMARC reports show something new sending as you. It is worth knowing which of your risks look like this one, because those are the ones where writing a policy is a way of feeling busy.
Which do you need first
Policy first, in almost every case. A policy costs an afternoon and no money, and it defines what correct means. Every control you configure later gets configured against some definition of correct, and if you have not written one down, the definition ends up being whatever the person doing the configuration assumed. Starting with the document also surfaces the disagreements while they are still cheap, which is often the real value of the exercise.
Then add controls for the rules where a single mistake would hurt most. Rank them by consequence and not by how interesting the technology is. For most small businesses the top of that list is identity, meaning MFA and sign-in rules, followed by whatever protects client data on its way out of the building.
The reassuring part is that this second step is usually a configuration job. If you pay for Microsoft 365 Business Premium, you are already licensed for almost every control named above, and Business Standard can enforce multi-factor authentication too. Microsoft Secure Score in your admin center is a decent first read on how many of them are actually turned on, and the number surprises most owners the first time they look. If your business is working toward SOC 2 or operating under HIPAA, the same order still applies, with the difference that an auditor will eventually ask you to show both halves for every rule that matters.
The pattern worth taking away: for every written rule you rely on, ask what would happen if the person involved forgot it entirely. If the answer is nothing good, that rule needs a control behind it, and the rest can stay a matter of trust.
Closing the distance between what your policies say and what your systems enforce is the substance of a security program, and it usually starts as a short list of settings in a tenant you already own. Get in touch and we will tell you which of your rules are currently enforced and which are running on goodwill.