There is one distinction that decides whether a business passes a security audit or fails it.
Administrative controls, meaning training, policies, and signed documents, run on the honor system. Technical controls, meaning device management, conditional access, and remote wipe, are enforceable and verifiable.
We come back to this line often, because it is the clearest way to explain why so many businesses get caught off guard. Most companies we onboard have plenty of administrative controls. A password policy, an acceptable use policy, a signed agreement promising staff will delete company files after each project. On paper it looks like a security program. Then a client sends a security questionnaire, or an auditor asks a simple question, and the gap shows up in seconds. Nobody can prove any of it is actually happening.
Administrative Controls Run on the Honor System
A signed document is a promise. Training is a good intention. A written policy states what should happen. None of them make anything happen, and none of them prove anything after the fact.
We have watched this play out in a Microsoft SSPA compliance audit, where a business was confident that contractors signing annual agreements and completing yearly training would be enough. In a real audit, it counted for almost nothing. The auditor was not asking whether staff promised to be secure. They were asking for proof that they were.
Technical Controls Enforce. Measurement Proves.
Enforceable, verifiable security has three parts working together, and the last one is where most businesses fall short.
The policy is the rule. Sensitive files stay encrypted. Only trusted devices connect. Access is removed the day someone leaves.
The control is what enforces the rule automatically, so it does not depend on anyone remembering. Conditional access checks the device and the identity before it allows a login. Encryption is applied by default. Offboarding runs as a process, not a favour someone does when they find the time.
The measurement is the proof. It is the log that shows the control did its job, the report that shows which sign-ins were blocked, the access review that shows who can reach what today. This is the part that turns enforceable into verifiable. Without it, you are trusting that everything is fine. With it, you can show it.
Most businesses have the policy and are missing the enforcement and the proof. That is not a paperwork problem. It is the difference between security you believe you have and security you can demonstrate.
Why This Is Landing on Your Desk Now
We see this hit hardest during vendor security screenings. A larger client, an insurer, or a partner sends a questionnaire, and the questions are no longer “do you have a policy?” They are “show us.” Show us your access logs. Show us that MFA is enforced, not just available. Show us how you remove access when staff leave. A signed document answers none of those. The proof does.
The pressure is coming from your customers now, not only regulators. Security requirements cascade down the supply chain. The company above you was asked to prove enforcement, so now they are asking you. We have seen the same demand reach businesses whose existing tools could not enforce or prove device compliance, leaving them to add Microsoft Intune before they could pass. Businesses that can produce the evidence pass and keep the contract. Businesses that cannot end up scrambling, and sometimes lose the deal while they catch up.
What Actually Closes the Gap
When we set this up for a client, we do not start by writing more policies. Most already have enough on paper. We start by making the controls real inside Microsoft 365, then making sure those controls produce evidence. Conditional access enforces the device and identity rules. Endpoint management keeps the settings in place so they do not quietly drift over time. Offboarding runs as a defined process. All of it generates the logs and reports that answer a security questionnaire without a fire drill.
Here is the honest part. This is ongoing, not a one-time project. Controls drift. Staff change. A setting that was correct in January is not guaranteed to be correct in June unless something is watching. There is no such thing as a one-time purchase in IT, and this is the clearest example of it. The value was never the signed binder. It is being able to prove, on any given day, that what your policy says is what your systems actually do.
What This Means for You
If someone asked you today to prove your security policies are enforced, could you? Not describe them. Prove them, with logs and reports. If the answer is “probably not,” you are in good company, and it is a solvable problem. It starts with separating the administrative controls you have promised from the technical controls you can actually enforce and verify.
This type of Microsoft 365 Security Management work is what we do for all our clients here at TUCU. We can help you too. We can also help you meet your IT Compliance requirements or pass any Vendor Security Screening a client throws at you.
Contact us to book a free discovery call, and we will help you find the gaps between what your policies say and what your systems actually enforce, and manage it all for you.
FAQ
What is the difference between an IT policy and a control?
A policy is the rule that states what should happen, such as “only approved devices can access company data.” A control is the system that enforces that rule automatically, such as conditional access checking the device before it allows a login. The policy sets the intent. The control makes it real without depending on anyone remembering. You need both, because a policy with no control behind it is just a document.
What is the difference between administrative and technical controls?
Administrative controls are training, policies, and signed documents. They run on the honor system, because they rely on people doing what they promised and they prove nothing after the fact. Technical controls are device management, conditional access, and remote wipe. They enforce the rule automatically and produce evidence you can show in an audit. Security assessments increasingly accept only technical controls, because they are the ones that are both enforceable and verifiable.
How do I prove my IT security policies are enforced?
You prove enforcement with evidence, not with the policy document itself. That means access logs showing who reached what, reports showing which sign-ins were blocked, records confirming MFA is enforced rather than just available, and access reviews showing current permissions. In Microsoft 365, conditional access, endpoint management, and a defined offboarding process all generate this evidence automatically. If you cannot produce these records on request, the policy is likely not being enforced.
Why do vendor security screenings ask for evidence instead of policy documents?
Because a policy document only states intent, and larger buyers have learned that intent and reality often do not match. Security screenings now ask you to show that controls are actually running, with logs, reports, and enforced settings. These requirements cascade down the supply chain, so the company above you was asked to prove enforcement, and now they are asking you. Businesses that can produce the evidence pass and keep the contract.
Is having IT policies enough to pass a security audit?
No. Auditors and security screenings look for proof that controls enforce your policies, not just that the policies exist. A password policy means little if nothing prevents password reuse, and a device policy means little if any personal laptop can sign in. Passing depends on demonstrating enforcement through logs, reports, and access reviews.
What does it mean to enforce a policy in Microsoft 365?
Enforcement means a technical control applies the policy automatically so it does not rely on staff behaviour. Conditional access enforces device and identity rules before granting access, endpoint management keeps security settings from drifting over time, and offboarding runs as a process that revokes access the day someone leaves. Each of these also produces the logs and reports that prove the policy is working.
