Security questionnaires, insurance renewals and client due-diligence reviews all ask essentially the same thing: can you demonstrate control over identity, data, devices and recovery? This engagement answers that question with evidence rather than assertion — and gives you a plan for the parts where the answer is currently no.

Scope

What gets reviewed

Identity and access

MFA and conditional access coverage, legacy authentication exposure, guest and external access, administrative role assignment.

Data and email

Sharing configuration, retention and deletion policy, mail flow rules and forwarding, and where sensitive data currently sits.

Devices

Enrolment and compliance coverage, update posture, and the population of devices reaching the environment from outside management.

Recoverability

Backup coverage against the workloads that matter, retention alignment with policy, and whether restores have been exercised.

Visibility

Logging, retention of audit data, and whether an incident could be reconstructed after the fact.

Deliverables

What you receive

  • A written assessment report, structured by risk rather than by product
  • A prioritised risk register with severity and effort against each item
  • A remediation plan sequenced by dependency, suitable for internal execution
  • A working session to walk through the findings with your team or leadership
Questions

Before you ask

How long does it take?

Scope, duration and price are agreed in writing before the engagement starts. The variable is the size and complexity of the tenant, which is established in the initial scoping conversation.

What access do you need?

Read-level access sufficient to review configuration. The specific roles are agreed up front, granted for the duration of the engagement, and revoked at the end.

Will this disrupt anything?

The assessment is a review, not a change. No configuration is modified without a separate, explicit agreement.

Can our existing IT provider stay involved?

Yes, and it usually works better when they do. The deliverable is written so it can be executed by whoever already runs the environment.