If you manage Microsoft 365 security, you might well have noticed the Standard Preset Security Policy as a baseline protection for Exchange Online, Office and Teams protections. It’s a sensible choice — Microsoft maintains it, it’s kept up to date with best-practice settings, and it covers anti-spam, anti-malware, and anti-phishing policies as well as Safe Links and Safe Attachments policies if you have Defender for Office licences. All in one neat package.
So why would you ever want to duplicate it?
The Problem with Presets: They’re All-or-Nothing
The Standard Preset Security Policy is powerful, but it has a fundamental constraint — you can’t modify all of the settings. The majority of settings are locked. Microsoft controls them. If you need to adjust a single value (say, bump the bulk email threshold or tweak the phishing confidence level for a specific group of users), you cannot do it within the preset itself.
Your only options are:
- Apply the preset to everyone and live with every setting as-is
- Build a completely custom policy from scratch, manually re-entering dozens of settings
- Apply no protection at all while you figure it out
None of these are good options.
The Real-World Scenario: Exceptions Are Inevitable
In practice, every organisation has edge cases. Marketing needs bulk email to flow more freely. The executive team needs stricter anti-phishing protections than the standard settings provide. A shared services department receives legitimate mail that keeps getting quarantined. A newly acquired subsidiary needs to be onboarded gradually, not hit with full enforcement on day one.
The moment you have one group of users who needs different treatment, you need a policy you can actually edit. And that means a custom policy — built from the preset’s settings as a starting point.
Why Not Just Build a Custom Policy from Scratch?
You could. But the Standard (and also the Strict) Preset Security Policy contains dozens of individual settings across five different policy types. Looking them up, transcribing them correctly, and keeping them in sync as Microsoft updates the preset is error-prone and time-consuming.
More importantly, if you build from scratch, you’re making a guess about what “standard” should look like. Microsoft’s preset is the answer to that question — it’s the product of ongoing threat intelligence, customer telemetry, and security research. Starting from their baseline and making targeted modifications is a far stronger security posture than assembling your own from memory or documentation.
What Duplicating The Policy Gives You
When you duplicate the Preset Security Policies, you get:
- A working copy of every setting across all five policy types — anti-spam, anti-malware, anti-phishing, Safe Links, and Safe Attachments
- Full editability — every setting can be changed without affecting the original preset or other users
- A point in time snapshot — your policies do not change when Microsoft update the presets, and this can be a good idea though often you will need to check back for changes and apply them to your custom duplicate policies.
You can then scope your duplicate policy to specific users, groups, or domains, adjust only the settings that need to differ, and enable it when you’re ready. You cannot raise the priority of your policy above the Microsoft ones, and as only one policy of every type will apply to a given user, you need to make sure that the preset policy now does not apply to that subset of users.
But if you need a custom anti-spam policy and so you remove users from the scope of preset policies, all the other preset policies (anti-malware, Safe Lists etc) do not apply to this user population either – so when you make a custom version of one policy you need to do all five – and this adds to the time it takes to do the work.
A Concrete Example
Imagine your legal team needs stricter bulk email protection. The Standard (and Strict if you are using it) preset doesn’t allow you to change that setting the way you need it. Rather than rebuilding everything from scratch, you:
- Duplicate all the Standard preset policies (all five of them)
- Enable and scope the duplicates to the Legal group
- Change the one setting in the one policy that needs to differ
- Enable the policies
- Ensure that the Legal group are exempt from the preset policies
Every other setting remains at the Microsoft-recommended standard. You’ve made a surgical change without compromising protection for anyone else or diverging unnecessarily from best practice.
The Operational Argument: Audit and Change Management
There’s also a governance angle. When auditors or your security team review your policies, a custom policy with documented modifications is far easier to explain than either “we use the preset” (which offers no visibility into what changed or why) or a fully bespoke policy where every setting needs justification.
A duplicate of the standard baseline, with only deliberate deviations, tells a clear story: here is our baseline, and here is exactly what we changed and why.
Policy Duplication Script
So to do this duplication I have written the ‘Duplicate-StandardPresetSecurityPolicy.ps1’ script (on GitHub). This will ask you the name of the policy that it will create, the recipient or domain that you want to apply the policies to and if you want to duplicate them all or just specific ones. Once you have duplicated them all once and can customise the rules for who the policy applies to, you do not need to duplicate them all again for another single policy with a different setting and application group.
Here is an example of using this script to duplicate all the Standard preset policies:
.\Duplicate-StandardPresetSecurityPolicy.ps1 -PolicyName "Contoso UK Staff" -RecipientGroup uk@contoso.com -PolicyTypes All
And once you have duplicated all five, here is an example of adding an additional anti-spam policy, duplicated from the Standard Preset, that you can change to update a setting such as the Bulk Email Threshold example discussed above:
.\Duplicate-StandardPresetSecurityPolicy.ps1 -PolicyName "Contoso UK BCL 5 Test Policy" -RecipientGroup uk-bcl5-test@dcadvisory.com -PolicyTypes AntiSpam
Set-HostedContentFilterPolicy "DCA MX To EOP BCL 5 Test Policy" -BulkThreshold 5
Conclusion
The Standard Preset Security Policy is an excellent foundation. But real-world environments are not uniform, and security requirements are never truly one-size-fits-all. Duplicating the preset gives you the best of both worlds: Microsoft’s continuously maintained best-practice settings as your starting point, with the flexibility to adapt them to your organisation’s actual needs — without touching the preset itself, and without starting from a blank page.
The goal isn’t to deviate from Microsoft’s recommendations. The goal is to apply them intelligently.
Leave a Reply