Security by standard beats security by memory.
Every Microsoft 365 tenant we set up or take over in the UAE gets the same written hardening standard applied on day one: enforced MFA, legacy authentication blocked, mail authentication configured, sharing defaults made sane, and monitoring that somebody actually reads. Then the tenant stays measured against that standard, so drift gets caught instead of discovered.
- 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 control areas, written down, applied the same way every time.
Identity: MFA enforced, legacy authentication blocked
Multi-factor authentication enforced for every account, not enabled and hoped for. Legacy authentication protocols blocked, because they are the paths that cannot enforce a second factor and they are the first thing an attacker tries. A Conditional Access starter set that covers the common cases as a coherent whole rather than a pile of individual policies. And tested break-glass accounts, documented, excluded deliberately, and monitored, so an emergency lockout does not become a second incident.
Mail: SPF, DKIM and DMARC, plus anti-forwarding
The three email authentication records configured properly so your domain is hard to spoof and your legitimate mail lands where it should. External auto-forwarding blocked or explicitly controlled, because a quiet forwarding rule is the mechanism behind most invoice fraud in this region. Microsoft's preset protection policies applied for phishing, spam and malware, so filtering reflects Microsoft's current recommendation rather than whatever was chosen years ago.
Sharing: sane defaults and guest hygiene
SharePoint and OneDrive sharing defaults set so that sharing still works but the accidental cases stop: no anonymous links that live forever, external sharing scoped to what the business actually needs, and site owners who know what their sites expose. Guest access gets a lifecycle: an owner for every guest, and a review cadence, because guests accumulate in every tenant and nobody removes them without a prompt.
Endpoints: enrollment and a compliance gate that gates
Devices enrolled into management, a compliance policy that defines what a healthy device looks like, and, critically, compliance connected to access. A device reported as non-compliant that can still read the mailbox is information, not protection. The baseline requires the gate to actually gate, staged carefully so nobody gets locked out of work on cutover day.
Monitoring: alerts that matter and a score that trends
A small set of alerts chosen because each one means something and somebody will act on it: new forwarding rules, unusual sign-in patterns, new admin role assignments, mass file activity. Not two hundred alerts nobody reads. Secure Score tracked as a trend against the baseline position, so the question is never whether the tenant is fine but whether it moved, and in which direction.
Data: retention decisions made and recorded
The baseline does not pretend to be a records management programme. What it requires is that retention decisions exist and are written down: what the tenant keeps, for how long, and who decided. Most tenants have never made these decisions at all, which means the answer to what do we keep is whatever the defaults happen to do. A recorded decision beats an accidental one even when the two look the same.
What each baseline area gives you when somebody official asks.
| Baseline area | ISO 27001 expectation it supports | UAE PDPL expectation it supports | Insurance questionnaire line it answers | |
|---|---|---|---|---|
| Identity and MFA | Access control and authentication requirements | Appropriate technical measures protecting personal data access | Is MFA enforced for all users and administrators | |
| Conditional Access and break-glass | Documented access rules and privileged access management | Controlled access to systems holding personal data | How is remote and privileged access controlled | |
| Mail authentication and anti-forwarding | Protection against malware and information transfer controls | Measures against unauthorised disclosure in transit | Are SPF, DKIM and DMARC in place; is forwarding restricted | |
| Sharing defaults and guest hygiene | Information classification and external party access controls | Limits on disclosure of personal data to third parties | How is external file sharing governed and reviewed | |
| Endpoint enrollment and compliance | Endpoint and mobile device security requirements | Protection of personal data on devices that can reach it | Are company devices managed and encrypted | |
| Monitoring and alerting | Logging, monitoring and event response requirements | Ability to detect and respond to personal data incidents | How would you detect a compromised account | |
| Retention decisions recorded | Documented control decisions an auditor can read | Personal data kept no longer than the stated purpose requires | Do you have a data retention policy |
Four reasons a standard beats a smart engineer's memory.
You can read the standard before you buy anything
The baseline is a document, and we share it with prospective clients on request before any engagement. You can hand it to your own IT person, another provider, or an auditor and ask whether it is sensible. A provider whose hardening standard is secret does not have one, they have habits. Ours survives being read.
It is applied against evidence, not assumptions
On an existing tenant, the baseline starts from our Microsoft 365 security audit, so every change is a response to a verified finding rather than a blanket reconfiguration. On a new tenant it is applied clean from day one. Either way, the end state is measured, not asserted: we re-check the tenant against the standard and show you the result.
It is honest about licences
The baseline is written so tenants on the Business Premium licence family can meet all of it, because that is what most UAE SMBs actually run. We do not answer every gap with an upgrade to the top tier. Where a control genuinely needs a higher licence, the baseline says so explicitly and treats it as an upgrade decision for you to make with the trade-offs in front of you.
It catches drift, which is where security actually dies
Tenants do not usually get breached because they were never configured. They get breached because a control that existed in 2023 was quietly weakened in 2024: an exclusion added for a project, a policy disabled during troubleshooting and never re-enabled. Scheduled re-checks compare the tenant against the written standard, so weakening is a finding with a date, not a surprise during an incident.
What is deliberately not in the baseline.
A standard that promises everything is a standard nobody actually meets. The baseline is deliberately scoped to what every tenant should have regardless of size or licence, and it is honest about where it stops.
- E5-only capabilities are an upgrade path, not the standard. Advanced threat hunting, longer investigation tooling and the top licence tier's features are genuinely valuable for some organisations, and recommending them to everyone would be selling, not engineering. The baseline is written so a Business Premium tenant can meet all of it. Where your risk profile justifies the E5 family, we say so separately and explain why.
- Per-company additions sit on top, not inside. A DIFC firm, a healthcare provider and a trading company each need controls beyond the baseline, and those are scoped per organisation as an extension. The baseline is the floor every tenant gets, not the ceiling any tenant should stop at.
- It is not a certification and we do not pretend it is. Applying the baseline does not make you ISO 27001 certified or PDPL compliant by itself. It gives you the tenant-level technical controls those frameworks expect, documented in a form an auditor can read, which makes the real certification work meaningfully shorter.
- It does not replace backup, incident response or user training. Those are their own disciplines with their own pages. The baseline assumes they exist or flags that they do not.
Four situations where a written standard earns its keep.
A tenant taken over from a previous partner
You inherit configuration decisions nobody can explain: admin accounts of unknown purpose, Conditional Access exclusions with no recorded reason, sharing settings that might be deliberate or might be 2019. The baseline gives the takeover a defined end state. Instead of poking at settings indefinitely, we audit the tenant, apply the standard in stages, and hand you a document that says what the tenant is now configured to and why.
After an incident
A compromised mailbox, a fraudulent payment attempt, a scare that got everyone's attention. The immediate response handles the incident; the baseline answers the question that follows it, which is how do we make sure this cannot simply happen again. Post-incident is also when staging discipline matters most, because the temptation is to lock everything down at once and break half the company doing it.
Before a cyber-insurance renewal
Insurance questionnaires have become genuinely technical: MFA enforcement, legacy authentication, mail authentication, device management, detection capability. Answering no, or answering yes inaccurately, both cost you. Applying the baseline before renewal means the answers are yes, they are true, and there is a document behind each one if the insurer or their assessor asks for substance.
Before an audit or certification push
Organisations heading into ISO 27001, a regulator visit, or a large customer's vendor assessment need their Microsoft 365 tenant to stop being the weak exhibit. The baseline delivers the tenant-level technical controls those reviews expect, already documented in the shape reviewers ask for: what the control is, why it is set that way, who owns exceptions and when they expire.
What a tenant on the baseline has that a default tenant 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 |
Hardening that locks users out is hardening that gets rolled back.
Report-only first, enforce second
Conditional Access policies go in report-only mode before they go live. That shows exactly who would have been blocked and why, using real sign-in data from your own users, before anyone is actually blocked. Enforcement happens after the report is clean or the affected cases are understood.
- Real impact data before enforcement, not guesses
- The one salesperson with the odd travel pattern gets found in the report, not at the airport
- Enforcement dates agreed with you, not sprung on you
Staged rollout, riskiest users last
Controls land on a pilot group first, usually IT and volunteers, then expand in rings. Executives and anyone whose lockout would hurt go in a late ring, after the process is proven boring. By the time enforcement reaches the whole company, it is a non-event.
- Pilot ring proves the control before it spreads
- Helpdesk is briefed before each ring, so the first call is expected
- Any ring can pause without unwinding the others
An exceptions register, with expiry dates
Some things legitimately cannot meet the baseline yet: an old application that only speaks legacy authentication, a device that cannot enroll. Those become recorded exceptions with an owner, a reason, a compensating control and an expiry date. Not silent permanent exclusions that outlive the reason they were created.
- Every exception has a named owner and a written reason
- 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 documented way back, tested where it matters. Break-glass accounts exist and have been used in a drill before the day they are needed. If a control misfires, it comes off in minutes, gets fixed, and goes back on, rather than becoming a story about why security is off.
- Break-glass access tested before enforcement, not during an outage
- Each change is reversible independently
- Misfires produce a fix, not a permanent rollback
Five steps from current state to a tenant on the standard.
- 1
Audit the current state
Every existing tenant starts with our Microsoft 365 security audit: what is actually configured, what evidence the tenant retains, and where the gaps against the baseline are. This is what makes the rest of the work surgical rather than blanket. A brand-new tenant skips this step and gets the baseline applied clean.
- 2
Plan the gap closure with you
Each gap becomes a planned change with an owner, an impact assessment and a rollout ring. Anything that could affect how people work, authentication changes above all, gets flagged, discussed and scheduled with you. Legitimate blockers become entries in the exceptions register with a compensating control and an expiry date, not silent omissions.
- 3
Apply in stages, identity first
Identity controls go first because they stop the most attacks: MFA enforcement, legacy authentication blocked, the Conditional Access starter set in report-only, break-glass accounts created and tested. Then mail authentication and anti-forwarding, then sharing defaults and guest hygiene, then endpoint enrollment and the compliance gate, then monitoring. Report-only before enforce, pilot ring before company-wide, every stage reversible.
- 4
Document what the tenant is now
The output is not a folder of screenshots. It is the baseline document marked up for your tenant: each control, its state, the date it was applied, every exception with its owner and expiry, and the retention decisions that were made and by whom. This is the artifact you hand to an auditor, an insurer or a future provider, and it is what the next re-check measures against.
- 5
Re-measure on a schedule
The tenant is re-checked against the standard on an agreed cadence, and after significant changes such as a migration or a provider handover. Each re-check reports the same way: still compliant, drifted here, exception expired there. Secure Score is tracked as a trend line alongside, so improvement and regression are both visible as numbers with dates rather than impressions.
What organisations ask about the tenant security baseline.
The pages around this one.
Microsoft 365 Security Audit
The examination that comes first on any existing tenant: what is actually configured, what evidence it retains, and where the gaps against this baseline are.
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.
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 365 Security Audit
Tenant review, and how far back your evidence really goes
Microsoft Security Dubai
Entra, Defender, Purview, Sentinel, and what you already own
Microsoft Entra
Identity and access management solutions
Entra Conditional Access
The control that decides who reaches your data
Entra ID P1 vs P2
What P2 genuinely adds, and what quietly moved
Microsoft Intune
Device management and endpoint security
M365 Administration
Expert Microsoft 365 tenant management
M365 Reporting & Auditing
Tenant reporting, audit logs, and usage analytics