Microsoft 365 security hardening
Close the access and sharing gaps putting company data at risk.
Configure, test and document the agreed Microsoft 365 security controls, including the application permissions selected for review and correction.
- What you get
- Approved Microsoft 365 security controls configured and tested, with policy, change and exception records.
- How it starts
- A free scope call. The price is fixed in writing before anyone is given access.
- When it is done
- The selected controls reach their approved enforcement state; agreed tests pass and remaining exceptions have owners.
Illustrative sample · constructed example
Enforce a control only after its pilot explains the effect.
Hardening pilot · access and sharing
Selected check
Does the control block a legitimate pilot task?
Hardening pilot · access and sharing
Pause enforcement. Results apply to the named sample checks below.
| Test case | Expected behavior | Sample review |
|---|---|---|
| Required business task | An intended pilot user can still do their job. | Task blocked |
| Unwanted access | The agreed control prevents the selected exposure. | Pilot investigation |
| Recovery | Keep the rollback reference and emergency-access checks. | Separate checks required |
| Next group | Review impact and exceptions before expanding scope. | Approval required |
A corrected pilot supports the next decision. It does not prove every user or control is ready.
- Evidence
- Constructed observation: a required pilot task no longer works.
- Decision
- Pause enforcement
- Next action
- Investigate the dependency and agree a correction or bounded exception.
Illustrative sample. Only controls in the agreed standard are included; wider security work is scoped separately.
Open the complete illustrative document to inspect its fields and print a copy.
Open the sample documentWhy now
The work starts here.
An insurance review, an audit finding, a departing employee, or a security question turned up controls that need fixing.
Scope at a glance
- One Microsoft 365 tenant
- Controls supported by existing licensing
- Client approves change windows
If nobody acts
What waiting costs
A Conditional Access policy left in report-only records what it would have done, without doing it. A control that reads as deployed on a summary can sit in that state until somebody opens the policy.
Consent granted to an application stays until an administrator revokes it. Where the grant is an application permission, the app signs in as itself rather than as a person, so it sits outside the sign-in rules written for users.
An enterprise application nobody uses keeps its consent and its credentials until somebody deletes the entry. A trial signed up for once leaves behind something that can still sign in to your tenant.
An exclusion added to unblock one project keeps applying to the group it was written against. That includes anyone added to the group later, until someone reviews the policy set and asks why it is there.
With no record of what was changed and when, a problem appearing after a change window gets investigated as a new fault. The change behind it is the last place anyone looks.
Check your own environment
Sounds like you?
- An insurer, auditor or client sent a questionnaire and you cannot answer it from records
- You pay for Business Premium or E5 but nobody can say which of it is switched on
- Somebody left and you are not certain their access was fully removed
- There is no list of who has administrator rights, or why
Save yourself the call
Not for you if
- The controls are already switched on and you have evidence you could hand to an auditor
- The questions are only about MFA and access rules, which is a narrower piece of work
- A provider already owns security policy and reviews it on a schedule
The work
What is different when we hand over
The current access, sharing and application-consent controls are inventoried and the agreed target state is approved.
Conditional Access and related security policies are staged, tested and moved to the approved enforcement state.
Risky application consents, unused enterprise applications and stale access are removed or bounded within the agreed list.
Exceptions are documented with an owner, a reason and a review date.
Acceptance
Checks before handover
Done when the approved controls are enforced, the agreed access and application tests pass, and every remaining exception has an owner.
Agreed policies are deployed and in their approved enforcement state
Risky application consents and unused enterprise apps are revoked or bounded, within the agreed list
Named tests pass
Exceptions have an owner and a documented reason
The client receives the policy register, test results, change record, and operating instructions
A fair question
We pay for Business Premium. Is the security not included?
The tools are included. Almost none of them are switched on by default, and a license is not evidence. What an insurer or auditor asks for is which controls are actually enforced, who is excluded from them, and who signed off on those exclusions. This turns the licensing you already own into that answer.
Price and calendar
Scope, price and project calendar
Engagement price
Price fixed after a short scope call.
The price is agreed in writing before any work starts and before anyone is given access. The call itself costs nothing. What moves the number:
What determines the scope
- Administrator and privileged-role population
- Number of existing Conditional Access policies to work through
- Volume of stale, departed-user and guest accounts to clean up
- Applications authenticating through Microsoft 365
- Number of agreed change windows
Scope & responsibilities
What is and is not included
The exclusions, what we need from you, how change is staged and reversed, and what is handed over at the end.
Exclusions
- Emergency incident response or same-day employee termination
- Full Intune enrollment or endpoint repair
- Rebuilding permissions site by site across SharePoint
- Full Purview classification or DLP program
- SOC monitoring
- Help desk and end-user support
- Licensing and hardware
- Controls unavailable under the client’s licensing
What we need from you
- Distribute user communications
- Own help-desk and end-user support throughout
- Approve change windows and provide administrative access
- Nominate owners for any exception that stays open
Change and rollback method
- The existing policy and application-access state is captured before changes begin.
- Policies are tested in report-only or with a pilot group before broad enforcement.
- The previous policy state remains the rollback point for each agreed window.
What your sign-in and sharing rules look like afterwards
- A System guide: the configuration as delivered, the checks that were run and the unresolved list
- Policy and application-access inventory, before and after
- Test results for the agreed controls
- Exception register with owners and review dates
- Change record and operating instructions
Access, acceptance and support arrangements
How you know the work is good
Judge it by what you can inspect.
The method is written down, the sample records open and the demo can be broken on purpose. Read it the way your technical owner would.
- 01How a project runs
A first conversation, free. An agreed scope with a named technical lead in the proposal. The price fixed in writing before we are given access. Checks before handover.
How we work- 02What is checked
Release checks, access test matrices and ownership maps. Constructed inspection records on the service pages show the standard before you buy.
See sample deliverables- 03What you keep
A System guide: what was agreed, what changed, what was tested and what remains open. With it, the scripts and check results behind the work.
Next step
Start with a free scope call.
Tell us what needs to change, what must keep working and the deadline. The call is free, and the price is fixed in writing before anyone is given access.
Price the security hardeningOr write to [email protected]