Identity and workplace security
For an organization with no security staff, the workplace tenant is where the leverage is. Almost everything an outsider would want — mail, files, the identity that unlocks everything else — is behind one set of settings, most of which were chosen once, during a migration, by someone who is no longer here.
The short version: highest value, lowest friction, start here
The work needs no code changes, no new products in most cases, and no change to how people do their jobs if it is designed properly. It produces findings a non-technical board can follow, and it closes the attack paths that are actually used against organizations this size: credential theft, mailbox rules, consent to a malicious application, and mail sent in your name.
It is also the work that most often has never been done. Tenants are stood up to make email function, not to make it defensible, and the settings that matter are not the ones that break visibly when they are wrong.
Tenant configuration review
The review runs across Microsoft 365 and Entra ID, or Google Workspace, from read access to the tenant. It produces a written statement of what is configured today — which is usually the first time anyone has had one — and then a gap list against a defensible target state.
Yes, and an inherited tenant nobody has read end to end is one of the most productive places to start, because the review produces the inventory the organization has never had. Where a managed provider holds the tenant, the review is explicitly not an assessment of that provider’s work; it is a statement of configuration, which you then own and can discuss with them.
Sharing, retention and external access
Who outside the organization can be invited, what they can reach once they are in, whether files shared with a link expire, whether mail forwarding to external addresses is possible, and how long deleted items and mailboxes of departed staff are retained. Retention is a security control and a privacy obligation at the same time, and the two pull in opposite directions often enough that the decision should be written down.
Application consent
Which third-party applications hold delegated permission into your tenant, who granted them, and whether an ordinary user can grant that permission without review. This is a quiet route in and it rarely appears on anyone’s list until it is used.
Conditional access and MFA, designed to survive real users
Not if it is staged. The design covers enrolment before enforcement, a defined path for shared mailboxes and service accounts, and a break-glass route that is proven to work before the policy is turned on. A policy that locks out the finance team on a Friday afternoon is rolled back on the Monday and not attempted again for two years, which is why the sequencing matters more than the policy text.
The design covers which conditions trigger which requirement — device state, location, application sensitivity, risk signal — and, just as importantly, what is deliberately left alone. It covers the authentication methods permitted and the ones to retire, including the weaker second factors that are worse than they look. It covers legacy authentication protocols, which bypass conditional access entirely and are still enabled in a surprising number of tenants. And it covers the break-glass accounts that must remain usable when the policy itself is the thing that is broken.
Why this matters to an underwriter, rather than only to an engineer, is covered separately in what an insurer is really asking when it asks about MFA.
Admin roles, standing privilege and the leaver problem
Two questions carry most of the finding value. How many accounts hold administrative roles, and how many of those need them all day, every day? And when somebody leaves, what actually happens, in what order, and who checks?
The deliverable is a privileged access model: which roles exist, who holds them, which are elevated only on request and for how long, which require a second approval, what is logged, and what raises an alert. Alongside it sits a joiner-mover-leaver process written as steps somebody can follow rather than as a policy statement — including the mover case, which is the one that quietly accumulates permission for years.
Email authentication: SPF, DKIM and DMARC, taken to enforcement
Three published standards work together. RFC 7208 defines the Sender Policy Framework, which states which hosts may send for a domain. RFC 6376 defines DomainKeys Identified Mail signatures, which let a domain take responsibility for a message cryptographically. RFC 9989 defines Domain-Based Message Authentication, Reporting, and Conformance, which tells receivers what to do when the first two fail and asks them to report back; it was published in May 2026 and supersedes the earlier DMARC specification, with aggregate and failure reporting split into RFC 9990 and RFC 9991.
The DMARC policy value takes one of three settings — none, quarantine or reject — and the entire point of the exercise is to arrive at reject without losing mail on the way. The staged path is: publish with monitoring only, read the aggregate reports until every legitimate sender is identified and aligned, move to quarantine on a portion of traffic, widen it, then reject.
Where enforcement usually breaks
Third-party senders and subdomains. The payroll platform, the ticketing system, the marketing tool, the transactional mail provider, the survey vendor somebody signed up for once — each sends as your domain and each needs its own alignment. Subdomains inherit or do not inherit the policy depending on how it is written, and a subdomain left unprotected is a usable forgery target. The longer walkthrough is in DMARC and email authentication.
Where impersonation has moved beyond mail — a voice or video call that appears to come from an executive — the controls are procedural rather than technical, and are covered in deepfake fraud controls.
What you receive
| Deliverable | What it is for |
|---|---|
| Tenant configuration review | What is set today, written down, with the gap against a defensible target |
| Conditional access design | Policies, sequencing and the enrolment plan that keeps people working |
| Privileged access model | Roles, elevation, approval, logging and the joiner-mover-leaver process |
| Email authentication plan | Sender inventory and the staged path from monitoring to reject |
| Remediation sequence | Ordered by risk and by disruption, so the rollout does not stall |
The work is design and review. This practice does not operate your identity platform, and the plan is written for your administrators or your managed provider to execute.
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
We inherited this tenant from an MSP and do not know what is configured — can you still help?
Yes, and an inherited tenant nobody has read end to end is one of the most productive places to start, because the review produces the inventory the organization has never had.
Bring whatever access you have. Where administrative access sits with a provider who is slow to grant it, the review can start from exported configuration and close the gaps later.
Will enforcing MFA lock people out?
Shared mailboxes, meeting-room accounts and the automation account that has run a nightly job since 2019 are where rollouts actually fail, and they are enumerated before anything is enforced.
Will DMARC enforcement break our marketing email?
Only if you enforce before your senders are covered. That is why the path runs from monitoring to quarantine to reject, with the report data read at each step to find the senders nobody remembered. Done in that order, enforcement is uneventful. Done as a single change, it is an incident.
Does our insurer care about this?
Cyber insurance applications ask about multi-factor authentication, privileged access and email controls, and those answers are underwriting information rather than a formality. An application answered optimistically is a problem at claim time rather than at renewal. What happens next, when something does go wrong, is covered by incident response readiness and ransomware readiness and resilience.
Start where the leverage is
Say which platform you run, roughly how many people are on it, and who administers it today. The reply says what a review would cover and what you would receive — see also cloud security configuration review and all security services.