Security by standard beats security by memory.
Whether we build a tenant from scratch or inherit one, the same written standard goes on in the first week. Multifactor enforced rather than merely available, the old authentication protocols shut off, mail authentication records set up properly, sharing defaults pulled back to something sensible, and a short list of alerts that a person genuinely reads. After that the tenant is measured against the standard on a schedule, which is how a weakened control becomes a dated finding instead of a discovery during an incident.
- WrittenA documented standard, not one engineer's habits
- Day oneApplied at setup or takeover, not someday
- Six areasIdentity, mail, sharing, endpoints, monitoring, data
- Re-checkedScheduled reviews against the same standard
Six areas, written down, and applied identically on every tenant.
Identity: MFA enforced, legacy authentication blocked
Multifactor required on every account, rather than switched on and left to optimism. The older authentication protocols closed off, because those are the routes where a second factor cannot be demanded, which is exactly why they are the first thing anybody tries. A starter set of Conditional Access policies designed as one coherent thing instead of a heap of rules added one at a time. And a tested pair of emergency accounts, written down, deliberately excluded and watched, so that being locked out during a crisis does not turn into a second crisis.
Mail: SPF, DKIM and DMARC, plus anti-forwarding
All three mail authentication records set up correctly, so that spoofing your domain is difficult and the mail you actually send arrives in an inbox rather than a junk folder. Automatic forwarding to outside addresses blocked or brought under explicit control, because a quiet forwarding rule is the machinery behind most invoice fraud and business email compromise. The preset protection policies applied for phishing, spam and malware, so that filtering reflects what Microsoft recommends today rather than what somebody selected in 2019.
Sharing: sane defaults and guest hygiene
Sharing settings in SharePoint and OneDrive adjusted so that people can still share and the accidents stop happening. No anonymous links living forever, external sharing narrowed to what the business genuinely does, and site owners who understand what their own sites are exposing. Guests get a lifecycle of their own, with a named owner each and a review that comes round regularly, because guest accounts pile up in every tenant and nobody has ever removed one without being asked to.
Endpoints: enrollment and a compliance gate that gates
Devices brought under management, a compliance policy stating what a healthy machine looks like, and, above all, that compliance wired into access. A device flagged as non-compliant which can still open the mailbox is a fact on a dashboard, not a control. The standard insists the gate actually gates, and it goes in carefully enough that nobody is locked out of their job on the day it switches on.
Monitoring: alerts that matter and a score that trends
A short list of alerts, each one there because it means something and somebody will do something about it. New forwarding rules, sign-in patterns that look wrong, new administrative role assignments, files moving in bulk. Not two hundred alerts that everyone has learned to ignore. Secure Score is followed as a line rather than a number, so the question is never whether the tenant is fine, it is whether it moved and which way.
Data: retention decisions made and recorded
This is not a records management program and does not claim to be. What it insists on is that decisions about retention exist somewhere in writing: what is kept, for how long, and whose call it was. Most tenants have never made those decisions at all, which means the honest answer to what do you keep is whatever the defaults happen to do. A decision somebody recorded beats an accident, even where the two produce the same outcome.
What each area is worth on the day somebody official starts asking questions.
Baseline area
Identity and MFA
- SOC 2 expectation it supports
- Logical access control and authentication requirements
- HIPAA and state privacy expectation it supports
- Appropriate technical safeguards on access to protected and personal data
- Insurance questionnaire line it answers
- Is MFA enforced for all users and administrators
Baseline area
Conditional Access and break-glass
- SOC 2 expectation it supports
- Documented access rules and privileged access management
- HIPAA and state privacy expectation it supports
- Controlled access to systems holding regulated data
- Insurance questionnaire line it answers
- How is remote and privileged access controlled
Baseline area
Mail authentication and anti-forwarding
- SOC 2 expectation it supports
- Protection against unauthorized information transfer
- HIPAA and state privacy expectation it supports
- Safeguards against unauthorized disclosure in transit
- Insurance questionnaire line it answers
- Are all three mail authentication records live, and is forwarding held down
Baseline area
Sharing defaults and guest hygiene
- SOC 2 expectation it supports
- External party access controls and review evidence
- HIPAA and state privacy expectation it supports
- Limits on disclosure of regulated data to third parties
- Insurance questionnaire line it answers
- How is external file sharing governed and reviewed
Baseline area
Endpoint enrollment and compliance
- SOC 2 expectation it supports
- Endpoint and mobile device security requirements
- HIPAA and state privacy expectation it supports
- Protection of regulated data on devices that can reach it
- Insurance questionnaire line it answers
- Are company devices managed and encrypted
Baseline area
Monitoring and alerting
- SOC 2 expectation it supports
- Logging, monitoring and incident response requirements
- HIPAA and state privacy expectation it supports
- Ability to detect and respond to data incidents
- Insurance questionnaire line it answers
- How would you detect a compromised account
Baseline area
Retention decisions recorded
- SOC 2 expectation it supports
- Documented control decisions an auditor can read
- HIPAA and state privacy expectation it supports
- Data kept no longer than the stated purpose requires
- Insurance questionnaire line it answers
- Do you have a data retention policy
Four reasons a written standard beats even a very good engineer recollection.
You can read the standard before you buy anything
It is a document, and we hand it to prospective clients who ask for it before anything is signed. Give it to your own IT person, to a competing provider or to an auditor and ask whether it holds up. A provider who will not show you their hardening standard does not have one, they have habits. This one survives being read closely.
It is applied against evidence, not assumptions
On a tenant that already exists, this begins with an audit of what is genuinely configured, so every change answers a verified finding rather than reconfiguring things wholesale. On a new tenant it goes on clean from the first day. In both cases the finishing state is measured rather than claimed: the tenant is checked back against the standard and you see the result.
It is honest about licenses
It is written so that a tenant on the Business Premium family can satisfy every part of it, because that is what most American small and mid-sized companies actually hold. Not every gap here gets answered with a proposal to move up a tier. Where a control genuinely does require a higher license, that is stated outright and treated as a decision for you to take with the trade-offs visible.
It catches drift, which is where security actually dies
Tenants rarely get breached for never having been configured. They get breached because something that was solid two years ago was quietly loosened last year. An exclusion added for a project that finished. A policy switched off during troubleshooting and never switched back. Scheduled re-checks measure the tenant against the written standard, so that loosening becomes a finding with a date attached rather than a surprise in the middle of an incident.
What is deliberately not in the baseline.
A standard promising everything is one nobody ever satisfies. This is deliberately drawn around what every tenant ought to have whatever its size or license, and it is straightforward about where it ends.
- Anything requiring the top license tier is an upgrade conversation, not part of the standard. Advanced hunting, longer investigation windows and the rest are genuinely worth having for some companies, and recommending them to everybody would be selling rather than engineering. The standard is written so a Business Premium tenant can satisfy every line of it. Where your risk actually justifies the E5 family, we raise that separately and explain the reasoning.
- Anything specific to your company sits on top rather than being folded in. A medical practice under HIPAA, a defense contractor working toward CMMC, and a consulting firm each need controls this does not cover, and those are scoped individually as an extension. Treat this as the floor every tenant stands on, not a ceiling anyone should stop at.
- It is not a certification and nobody here will pretend otherwise. Applying it does not make you SOC 2 attested or HIPAA compliant on its own. What it gives you is the technical controls at the tenant level that those frameworks expect, written up in a form an auditor can read, which makes the real audit work considerably shorter than it would otherwise be.
- It is not a substitute for backup, for incident response or for training people. Each of those is a discipline in its own right with its own page here. This either assumes they are in place or tells you plainly that they are not.
Four situations where a written standard earns its keep.
A tenant taken over from a previous partner
What you inherit is a set of decisions nobody can account for. Administrator accounts whose purpose is a mystery, Conditional Access exclusions with no reason recorded anywhere, sharing settings that are either deliberate or simply left over from years ago. This gives the handover a defined destination. Rather than prodding at settings indefinitely, the tenant gets audited, the standard goes on in stages, and you finish holding a document that states what the tenant is configured to and why.
After an incident
A mailbox taken over, a payment nearly sent to the wrong account, a scare that finally got everybody paying attention. The immediate response deals with the incident itself. This answers the question that arrives straight afterward, namely how you stop the same thing happening again next quarter. It is also the moment when staging discipline matters most, because the instinct is to lock everything down that same afternoon and break half the company in the process.
Before a cyber-insurance renewal
Cyber insurance questionnaires have become properly technical. Is multifactor enforced, is legacy authentication closed, is mail authentication configured, are devices managed, can you detect anything. Answering no costs you money, and answering yes when it is not quite true can cost you a claim, because a misstated application is grounds to dispute one. Getting this on before renewal means the answers are yes, the answers are accurate, and there is a document behind each one when the insurer or their assessor asks for substance.
Before a SOC 2, HIPAA, or customer audit push
Companies walking into a SOC 2 examination, a HIPAA security risk analysis, or a vendor assessment from a customer large enough to insist on one, need the Microsoft 365 tenant to stop being the embarrassing exhibit. This produces the tenant-level controls those reviews expect, already written up in the shape reviewers want them: what the control is, why it is set that way, who owns each exception and when it runs out.
What a tenant on this standard has that a tenant left on defaults does not.
| Feature | On the GR baseline | Configured from memory | Tenant defaults |
|---|---|---|---|
MFA enforced for every account | Usually most accounts | Depends on tenant age | |
Legacy authentication blocked | Sometimes | Often still open | |
Conditional Access designed as a set | Accumulated policies | ||
Break-glass accounts documented and tested | Exist, untested | ||
SPF, DKIM and DMARC all configured | SPF only is common | Partial | |
External auto-forwarding controlled | Sometimes | ||
Sharing defaults reviewed and set | Permissive | ||
Guest accounts owned and reviewed | |||
Device compliance gates access | Reported only | ||
Alerts somebody actually reads | Alert fatigue | Few configured | |
Exceptions written down with expiry | No exceptions concept | ||
Drift caught by scheduled re-checks | |||
A document that says what "configured" means |
Any hardening that locks people out of their work gets reversed within a fortnight.
Report-only first, enforce second
Every Conditional Access policy runs in report-only before it runs for real. That tells you exactly who would have been stopped and for what reason, using genuine sign-in data from your own staff, while nobody is actually being stopped. Enforcement follows once the report comes back clean or the affected cases are understood and handled.
- Real impact data before enforcement, not guesses
- The one salesperson with the unusual travel habits turns up in the report rather than stranded at a gate
- Enforcement dates agreed with you, not sprung on you
Staged rollout, riskiest users last
Each control goes to a pilot group first, normally the IT team and whoever volunteers, then spreads outward in rings. Executives, and anybody whose lockout would genuinely hurt, sit in one of the last rings, by which point the process has proven itself thoroughly dull. Reaching the whole company is a non-event.
- Pilot ring proves the control before it spreads
- The help desk is briefed ahead of every ring, so the first call surprises nobody
- Any ring can pause without unwinding the others
An exceptions register, with expiry dates
Some things genuinely cannot meet the standard yet. An old application that speaks nothing but legacy authentication, a device that will not enroll. Each becomes a recorded exception carrying an owner, a stated reason, something compensating for it, and a date it expires. Not a silent permanent carve-out that outlives whatever created it by five years.
- Each exception carries a name against it and a reason in writing
- Every exception expires and must be renewed deliberately
- The register is reviewed at every scheduled re-check
Rollback planned before anything is enforced
Every enforcement step has a route back, written down and rehearsed where it counts. The emergency accounts exist and somebody has actually signed in with them during a drill, well before the day that matters. When a control misfires it comes off within minutes, gets corrected and goes back on, instead of turning into the story of why security stayed switched off.
- Emergency access proven before enforcement rather than in the middle of an outage
- Each change is reversible independently
- Misfires produce a fix, not a permanent rollback
Five steps from wherever the tenant is today to a tenant on the standard.
- 1
Audit the current state
Any tenant that already exists begins with an audit. What is genuinely configured, what evidence it holds onto, and where it falls short of the standard. That is what lets everything afterward be precise rather than sweeping. A brand new tenant skips this entirely and gets the standard applied to a clean slate.
- 2
Plan the gap closure with you
Every gap turns into a planned change with somebody owning it, an assessment of what it will affect and a ring it belongs to. Anything capable of changing how people work, and authentication changes most of all, gets raised, discussed and scheduled with you rather than done quietly. Genuine blockers go into the exceptions register with something compensating and a date they expire, not left as silent omissions.
- 3
Apply in stages, identity first
Identity goes in first because it stops the most attacks. Multifactor enforced, legacy authentication closed, the Conditional Access starter set running in report-only, and the emergency accounts created and actually tested. Then mail authentication and the forwarding controls, then sharing defaults and tidying up guests, then device enrollment and the compliance gate, then the monitoring. Report-only before enforcement, a pilot ring before the whole company, and every stage able to be undone.
- 4
Document what the tenant is now
What you receive is not a folder of screenshots. It is the standard itself, marked up against your tenant: every control, its current state, the date it went on, each exception with an owner and an expiry, and the retention decisions along with who made them. That is the thing you hand to an auditor, to an insurer or to whoever supports you next, and it is what the following re-check measures against.
- 5
Re-measure on a schedule
The tenant gets measured against the standard on a rhythm you agree to, and again after anything significant such as a migration or a change of provider. Every re-check reports identically: still holding here, drifted there, this exception has expired. Secure Score runs alongside as a trend, so both improvement and slippage show up as numbers with dates on them rather than as somebody impression.
What organizations ask about the tenant security baseline.
The pages around this one.
Microsoft 365 Tenant Setup
A new tenant built to this baseline from day one, so hardening is the starting position rather than a retrofit project two years later.
Tenant Takeover
Inheriting a tenant from a previous partner, and how the baseline turns an unknown configuration into a documented one with a defined end state.
Cybersecurity Audit & Compliance
The wider security examination that comes first on any existing environment: what is actually configured, and where the gaps are.
Ask to read the baseline. Then decide.
We will send you the standard, tell you which parts your tenant likely already meets, and scope what closing the rest would involve. If your current setup turns out to be closer than you feared, we will say so, because a tenant measured against a written standard is the outcome we are selling either way.
Related Services
Explore more solutions that work great with this service
Microsoft Entra
Identity and access management solutions
Learn moreMicrosoft Intune
Device management and endpoint security
Learn moreMicrosoft Defender
Advanced endpoint and email threat protection
Learn moreM365 Tenant Management
Your tenant run properly, end to end
Learn moreM365 Administration
Expert Microsoft 365 tenant management
Learn more