Field note
Defender Office 365 Baseline
Most email security debates drag on because people talk about settings in the abstract. The better question is simpler: which users need more protection, what will it interrupt, and who will own the fallout when something legitimate gets caught.
The Standard vs Strict discussion gets treated like a maturity test far too often. This baseline comparison is a scoping decision, not a ranking.
Microsoft gives you preset security policies in Defender for Office 365 so you do not have to hand-build every anti-phishing, Safe Links and Safe Attachments choice from scratch. That is useful. Where teams get into trouble is assuming there must be one answer for the whole tenant. In real life, risk is uneven. Finance, leadership, admins, procurement and anyone exposed to supplier payments usually need a tighter posture than the rest of the business.
That means most tenants should start with a simple rule:
- put normal users on
Standard - put high-risk users on
Strict - keep exceptions rare, named and reviewed
That is less glamorous than a giant custom policy stack, but it is easier to explain and much easier to keep tidy six months later.
What Standard is good at
Standard is where most SMEs should begin because it gives you a strong baseline without immediately forcing a culture war with the helpdesk.
If you are cleaning up a tenant that has grown unevenly, Standard is often the fastest way to stop obvious gaps:
| Where Standard helps | Why it works |
|---|---|
| General user population | Sensible protection without the highest level of friction |
| Early-stage cleanup | Lets you stabilise detection and reporting before tightening more |
| Teams with poor exception hygiene | Avoids a flood of allow requests on day one |
| Mixed operational maturity | Gives you a baseline that support staff can actually live with |
That last point matters. A control no one understands will get bypassed the moment it blocks a sales quote, supplier invoice or client introduction.
Where Strict earns its keep
Strict is not there to make the dashboard look serious. It is there for the people most likely to be impersonated, socially engineered or targeted because they can approve money, change access or unblock other people.
I usually care about these groups first:
- Finance and payroll.
- Directors and executive assistants.
- Global admins and other privileged roles.
- Procurement and supplier-facing staff.
- Shared high-visibility mailboxes that attract external contact.
If one of those users gets a convincing fraudulent invoice, bogus MFA prompt or malicious document share, the business impact is not theoretical. That is where tighter phishing and link controls tend to justify themselves quickly.
The mistake people make
The most common mistake is rolling out Strict broadly before anyone has cleaned up the noisy basics:
- missing user reporting
- unclear quarantine handling
- old allow entries
- broken sender authentication on legitimate partner mail
- no agreed path for false positives
On paper, Strict looks like the "safer" answer. In practice, if the surrounding process is weak, users and support staff start fighting the tool rather than learning from it. Once that happens, pressure builds for blanket exceptions, and those exceptions usually stay around much longer than the original problem.
That is why I prefer a staggered rollout. Standard for broad coverage. Strict for the people who genuinely carry more business risk. Then review the data and expand if it is earning its place.
A deployment model that stays sane
This is the version that tends to survive contact with normal business operations:
| User group | Suggested preset | Notes |
|---|---|---|
| Most staff | Standard | Good baseline while keeping support overhead reasonable |
| Finance, payroll, directors | Strict | Higher impersonation and payment fraud exposure |
| Admin accounts | Strict | High-impact identities deserve tighter filtering |
| Shared mailboxes | Case by case | Depends on workflow, automation and message volume |
| VIPs with noisy external comms | Strict plus careful review | Often worth it, but watch false positive patterns |
The point is not to build five policy families. The point is to make a small number of deliberate choices and document why they exist.
What to check before calling it done
A preset policy rollout is not finished because the toggle is on. I would want quick answers to these:
- Are the preset policies actually assigned to the right users?
- Are Safe Links and Safe Attachments in scope where expected?
- Are impersonation protections covering the people and domains that matter?
- Is the Report Message or Report Phishing workflow live and reaching the right review queue?
- Can someone explain how quarantine release works?
- Are there old allow entries with no named owner?
- Are external forwarding controls aligned with the email risk posture?
- Is there a monthly review point for exceptions and false positives?
If the answer to half of those is "probably", the policy is not operational yet.
What success looks like
Success is not "everyone is on Strict".
Success is more boring than that:
- suspicious mail gets filtered consistently
- high-risk users are protected more aggressively
- legitimate mail problems get resolved without panic
- exceptions stay small and reviewable
- user reports help the system instead of disappearing into a black hole
That is a decent outcome. It is also the kind of setup a small internal team can keep running without needing to redesign it every quarter.
References
Related notes
05 Mar 2026 · 4 min
Defender Office 365 Operations
Related: defender for office 365, security operations, phishing.
22 Jan 2026 · 5 min
Phishing Still Pays: A Microsoft 365 Action Plan for UK SMEs
Related: phishing, defender for office 365, uk cyber security.
30 Apr 2026 · 3 min
Cyber Breaches Survey Lessons for M365
Related: uk cyber security, microsoft 365, phishing.
Need help mapping this to your own tenant, controls, or assessment timeline?