RichardHam.co.uk Blog

Author: admin

  • The M365 Security Baseline Most SMEs Skip

    The M365 Security Baseline Most SMEs Skip

    If your business runs on Microsoft 365 — and in the UK, that covers the vast majority of SMEs, law firms, and healthcare practices — there is a reasonable chance your tenant is less secure than you think.

    Not because Microsoft has failed. Not because your IT provider has been negligent. But because the default configuration of an M365 tenant is designed to get you up and running, not to protect a regulated business handling sensitive client data.

    Most organisations I work with assume that because Microsoft provides the platform, Microsoft secures it. That assumption is wrong, and it is the single most common gap I find when reviewing an SME’s security posture.

    The Shared Responsibility Model, Explained Simply

    Microsoft operates what is called a shared responsibility model. Microsoft secures the platform: the physical data centres, the hypervisor, the network infrastructure, the availability of the service. That part is genuinely well handled.

    What Microsoft does not do is secure your tenant. Your tenant is your configuration: who can log in, from where, with what level of verification. What happens to data when it leaves your mailbox. Who has access to your SharePoint sites. Whether a former contractor’s guest account is still active three years after they left.

    These are your decisions. Microsoft gives you the controls. It is up to you to turn them on and configure them correctly.

    The problem is that most SMEs never have this conversation. The tenant was set up when the business migrated to M365, the defaults were accepted, and no one with security expertise has reviewed the configuration since.

    The Seven Controls Most SMEs Skip

    When I conduct a baseline M365 security review, the same gaps appear with striking consistency. Here are the seven controls that are most commonly missing or misconfigured.

    1. MFA enforcement for all users. Multi-factor authentication is the single most effective control against credential-based attacks. It is also the one most likely to be partially deployed. I regularly find tenants where MFA is “enabled” but not “enforced” — a distinction that means users can still bypass it. Every account should have MFA enforced, without exception.

    2. Conditional access policies. MFA alone is not enough if it can be triggered from any device, on any network. Conditional access lets you require compliant devices, block legacy authentication, restrict access by location, and require step-up authentication for sensitive applications. Most SMEs I review have no conditional access policies configured at all.

    3. Mailbox auditing. M365 includes mailbox auditing as a standard feature, but it is not always enabled by default on older tenants. Without it, you have no record of who accessed a mailbox, what they did, and when. If a compromised account is used to exfiltrate email, you will not know. For law firms and healthcare organisations, this is a basic compliance requirement.

    4. DLP labels and policies. Data loss prevention lets you define sensitivity labels and apply policies that prevent data from leaving the organisation — for example, detecting when someone emails a document containing a National Insurance number or bank account detail to an external address. Most SMEs have no DLP policies. Those that do often run them in “test mode” that generates alerts but takes no action.

    5. Guest access controls. By default, M365 allows users to invite external guests to SharePoint sites, Teams channels, and shared folders. Without controls, a member of staff can share a folder containing sensitive client documents with an external address, and that access persists until someone manually revokes it. Guest access should be restricted by domain and subject to regular review.

    6. Retention policies. Without retention policies, everything stays in the tenant indefinitely — including data the business no longer needs, data it is not legally permitted to retain, and data that would be damaging in a breach or subject access request. Retention policies should reflect the organisation’s actual data retention schedule.

    7. Admin role hygiene. Global administrator grants full access to every service and every piece of data in the tenant. Most SMEs I review have between four and eight global administrators. The correct number is two or three, used exclusively for administration. Every additional global admin is an additional high-value target. Role-based access control should be used for everything else.

    Why This Matters: The Blast Radius of One Compromised Account

    The business risk here is not theoretical. A single compromised M365 account — obtained through phishing, credential stuffing, or a brute-force attack against an account without MFA — gives an attacker access to that user’s email, their OneDrive files, the SharePoint sites they can reach, the Teams channels they belong to, and every third-party application connected to the tenant.

    For a law firm, that could mean access to client matter files, privileged correspondence, and case strategy documents. For a healthcare practice, it could mean patient records and clinical communications. For any business, it could mean the ability to send convincing phishing emails from a trusted internal address to every contact in the organisation.

    The attacker does not need to breach your firewall. They do not need to exploit a vulnerability in your infrastructure. They need one set of credentials, and the default M365 configuration hands them the keys to everything.

    The Baseline Checklist

    If you want to assess where your organisation stands, here is a practical checklist. You can work through this with your IT team or your IT provider. Every item should be a yes or a concrete plan — not a “we think so” or “it should be on”.

    • [ ] MFA is enforced for every user account, without exceptions
    • [ ] Legacy authentication protocols are blocked via conditional access
    • [ ] Conditional access policies restrict access by device compliance and location
    • [ ] Mailbox auditing is enabled and logs are retained for at least 90 days
    • [ ] DLP policies are configured for sensitive data types and set to enforce, not just test
    • [ ] Guest access is restricted by domain and subject to regular access reviews
    • [ ] Retention policies are configured and aligned with the organisation’s data retention schedule
    • [ ] Global administrator roles are limited to two or three accounts, used only for administration
    • [ ] Role-based access control is used for all other administrative functions
    • [ ] A regular access review process is in place for both internal and external users

    If you can tick every box, your baseline is in good shape. If you cannot, you have a clear picture of where to start.

    Where to Start

    You do not need to fix everything at once. The highest-impact changes — MFA enforcement, blocking legacy authentication, and reducing global administrator count — can be implemented in a single afternoon and will meaningfully reduce your exposure.

    The rest can be prioritised based on your risk profile. A law firm handling privileged client data will prioritise DLP and mailbox auditing differently than a professional services firm with a smaller client base. The point is to make deliberate decisions about your configuration, not to accept the defaults and hope they are enough.

    If your organisation runs on M365 and you are not confident that your tenant is configured to a standard that would withstand scrutiny — from a regulator, a client, or an attacker — a structured security baseline review is the right first step. The Security & Compliance Strategy service covers M365 tenant configuration as part of the broader risk framework. Or get in touch for a 30-minute conversation about where your organisation stands.

  • What Multi-Agent Operations Actually Look Like in Practice

    What Multi-Agent Operations Actually Look Like in Practice

    Most organisations experimenting with AI agents are still operating them like a single chat window. Someone opens a prompt, asks the agent to do something, waits for the output, and moves on. That works for demos. It does not work when you are running agents against production systems or trying to get consistent results across a team.

    The gap is not technical. It is operational. The organisations getting genuine value from AI agents are not the ones with the most advanced models. They are the ones that figured out how to coordinate agents the way you would coordinate a team: clear roles, defined handoffs, checkpoint reviews, and someone accountable for the outcome.

    The Governance Gap Nobody Talks About

    The current wave of AI agent tooling is impressive. You can spin up an agent that writes code, another that reviews it, another that runs tests, and a fourth that deploys. The demos are compelling. The problem is that most organisations have not thought about what happens when these agents operate together at scale.

    Who coordinates them? What happens when two agents make conflicting changes? Where is the state stored, and who can inspect it? If an agent fails halfway through a task, what recovers? If an agent produces an incorrect output that another agent consumes, how do you trace the error back?

    These are the same questions you would ask about any multi-person production system. The difference is that agents do not have common sense, do not ask clarifying questions by default, and do not stop when something looks wrong unless you have built in the checks.

    The governance gap is this: most teams have moved from “can we run an agent?” to “we are running agents” without establishing the coordination layer in between.

    The Pattern That Actually Works

    After running autonomous coding agents in production for several months, the pattern that has proven reliable is a hybrid orchestration model. It has four parts.

    A coordinator role. One agent, or one human, owns the overall task. This role does not do the detailed work. It defines the objective, breaks it into independent subtasks, assigns each to a worker, and reviews the results. In practice, this is the role I occupy when running Hermes Agent, Claude Code, or Codex on a project. I set the direction, handle security decisions and state management, and delegate the pure coding work.

    Parallel worker agents. When subtasks are independent, they run simultaneously. Three agents working on three separate services at the same time complete in minutes what a single agent would handle sequentially in an hour. The key requirement is that the subtasks must be genuinely independent. If agent B depends on agent A’s output, running them in parallel creates conflicts, not speed.

    State machines for complex flows. When a task has sequential dependencies, a simple state machine prevents chaos. Each agent picks up the task at a defined state, does its work, writes output to a known location, and transitions the task forward. If an agent fails, the state does not advance. The next agent picks up the failed state and either retries or escalates.

    Checkpoint reviews. At defined points in the flow, a human reviews the output before the next stage begins. This is not a bottleneck. It is a safety mechanism. The review confirms that the output is sane, the state is correct, and the next stage has what it needs. In practice, these reviews take seconds when things are going well and save hours when they are not.

    A Concrete Example: Diagnosing Three Services at Once

    Suppose three independent services are exhibiting issues simultaneously. A traditional approach investigates them sequentially: diagnose service A, fix it, move to service B, fix it, move to service C.

    With a multi-agent setup, the coordinator defines the diagnostic task for each service and spins up three parallel subagents. Each agent gets the same instructions: examine the logs, identify the root cause, propose a fix, and write its findings to a shared state file. The agents do not communicate with each other. They do not need to. They are working on independent systems.

    When all three agents have completed their tasks, the coordinator reviews the findings, checks for conflicts (two agents proposing changes to a shared dependency, for example), and either approves the fixes or escalates for human review.

    A diagnostic process that would take a single engineer most of a day takes under thirty minutes. The quality is not lower — each agent focuses on a single problem without context-switching. The risk is not higher — the checkpoint review catches anything anomalous before it reaches production.

    This is not theoretical. It is a routine operational pattern that runs on free-tier models for the worker agents. The expensive model is the coordinator, and even that role can be handled by a human with a clear framework.

    The Cost Conversation

    There is a persistent misconception that running AI agents at scale requires expensive API subscriptions. In practice, the opposite is true. Worker agents doing diagnostics, code generation, and testing do not need frontier models. They need competent instruction-following, and that is available on free tiers or at very low cost.

    The coordinator role is where model quality matters. This is the agent making decisions about task decomposition, conflict resolution, and escalation. It needs to reason well. But there is only one coordinator, and it does relatively little token-heavy work compared to the workers.

    The cost structure in a well-designed multi-agent system is front-loaded into the coordination layer and minimal in the execution layer. You are paying for one good decision-maker and many cheap workers. The economics favour this model, which is one reason it works for cost-conscious organisations, not just well-funded ones.

    Failure recovery follows the same logic. When an agent fails on a free tier, the cost of retry is zero. When an agent fails on an expensive tier, every retry is a budget event. Putting cheap agents on high-volume work and the expensive agent on high-judgement work is not just an architectural decision. It is a cost optimisation.

    What Organisations Should Do Next

    If you are running or planning to run AI agents in production, the operational model matters more than model selection. Here is where to start.

    Define the coordinator role first. Decide whether a human or an agent owns task decomposition and review. Document what this role is responsible for and what decisions require escalation. This is your governance layer.

    Identify independent subtasks. Look at your current agent workflows and find the tasks that can run in parallel. Sequential workflows where tasks are independent are leaving time on the table.

    Build state into your workflows. Every agent should write its output to a known location in a known format. Every downstream agent should read from that location. If you cannot inspect workflow state at any point without replaying the entire execution, your state management is insufficient.

    Set checkpoint reviews at decision points. Not at every step — that defeats the purpose. At points where an incorrect output would propagate downstream and cause real damage. A review that takes five seconds and prevents a two-hour debugging session is time well spent.

    Use the right model for the right role. Do not pay frontier-model prices for tasks that a free-tier model handles competently. Reserve your budget for the coordination and review layers where reasoning quality directly affects outcomes.

    If your organisation is moving from AI experimentation to production agent operations, the coordination layer is where the value is — and where the risk lives. The AI & Automation Architecture service covers the design of multi-agent systems with proper governance, state management, and cost controls. Or get in touch for a conversation about what your agent operations should look like before they scale.

  • What Multi-Agent Operations Actually Look Like in Practice

    What Multi-Agent Operations Actually Look Like in Practice

    Most organisations experimenting with AI agents are still operating them like a single chat window. Someone opens a prompt, asks the agent to do something, waits for the output, and moves on. That works for demos. It does not work when you are running agents against production systems or trying to get consistent results across a team.

    The gap is not technical. It is operational. The organisations getting genuine value from AI agents are not the ones with the most advanced models. They are the ones that figured out how to coordinate agents the way you would coordinate a team: clear roles, defined handoffs, checkpoint reviews, and someone accountable for the outcome.

    The Governance Gap Nobody Talks About

    The current wave of AI agent tooling is impressive. You can spin up an agent that writes code, another that reviews it, another that runs tests, and a fourth that deploys. The demos are compelling. The problem is that most organisations have not thought about what happens when these agents operate together at scale.

    Who coordinates them? What happens when two agents make conflicting changes? Where is the state stored, and who can inspect it? If an agent fails halfway through a task, what recovers? If an agent produces an incorrect output that another agent consumes, how do you trace the error back?

    These are the same questions you would ask about any multi-person production system. The difference is that agents do not have common sense, do not ask clarifying questions by default, and do not stop when something looks wrong unless you have built in the checks.

    The governance gap is this: most teams have moved from “can we run an agent?” to “we are running agents” without establishing the coordination layer in between.

    The Pattern That Actually Works

    After running autonomous coding agents in production for several months, the pattern that has proven reliable is a hybrid orchestration model. It has four parts.

    A coordinator role. One agent, or one human, owns the overall task. This role does not do the detailed work. It defines the objective, breaks it into independent subtasks, assigns each to a worker, and reviews the results. In practice, this is the role I occupy when running Hermes Agent, Claude Code, or Codex on a project. I set the direction, handle security decisions and state management, and delegate the pure coding work.

    Parallel worker agents. When subtasks are independent, they run simultaneously. Three agents working on three separate services at the same time complete in minutes what a single agent would handle sequentially in an hour. The key requirement is that the subtasks must be genuinely independent. If agent B depends on agent A’s output, running them in parallel creates conflicts, not speed.

    State machines for complex flows. When a task has sequential dependencies, a simple state machine prevents chaos. Each agent picks up the task at a defined state, does its work, writes output to a known location, and transitions the task forward. If an agent fails, the state does not advance. The next agent picks up the failed state and either retries or escalates.

    Checkpoint reviews. At defined points in the flow, a human reviews the output before the next stage begins. This is not a bottleneck. It is a safety mechanism. The review confirms that the output is sane, the state is correct, and the next stage has what it needs. In practice, these reviews take seconds when things are going well and save hours when they are not.

    A Concrete Example: Diagnosing Three Services at Once

    Suppose three independent services are exhibiting issues simultaneously. A traditional approach investigates them sequentially: diagnose service A, fix it, move to service B, fix it, move to service C.

    With a multi-agent setup, the coordinator defines the diagnostic task for each service and spins up three parallel subagents. Each agent gets the same instructions: examine the logs, identify the root cause, propose a fix, and write its findings to a shared state file. The agents do not communicate with each other. They do not need to. They are working on independent systems.

    When all three agents have completed their tasks, the coordinator reviews the findings, checks for conflicts (two agents proposing changes to a shared dependency, for example), and either approves the fixes or escalates for human review.

    A diagnostic process that would take a single engineer most of a day takes under thirty minutes. The quality is not lower — each agent focuses on a single problem without context-switching. The risk is not higher — the checkpoint review catches anything anomalous before it reaches production.

    This is not theoretical. It is a routine operational pattern that runs on free-tier models for the worker agents. The expensive model is the coordinator, and even that role can be handled by a human with a clear framework.

    The Cost Conversation

    There is a persistent misconception that running AI agents at scale requires expensive API subscriptions. In practice, the opposite is true. Worker agents doing diagnostics, code generation, and testing do not need frontier models. They need competent instruction-following, and that is available on free tiers or at very low cost.

    The coordinator role is where model quality matters. This is the agent making decisions about task decomposition, conflict resolution, and escalation. It needs to reason well. But there is only one coordinator, and it does relatively little token-heavy work compared to the workers.

    The cost structure in a well-designed multi-agent system is front-loaded into the coordination layer and minimal in the execution layer. You are paying for one good decision-maker and many cheap workers. The economics favour this model, which is one reason it works for cost-conscious organisations, not just well-funded ones.

    Failure recovery follows the same logic. When an agent fails on a free tier, the cost of retry is zero. When an agent fails on an expensive tier, every retry is a budget event. Putting cheap agents on high-volume work and the expensive agent on high-judgement work is not just an architectural decision. It is a cost optimisation.

    What Organisations Should Do Next

    If you are running or planning to run AI agents in production, the operational model matters more than model selection. Here is where to start.

    Define the coordinator role first. Decide whether a human or an agent owns task decomposition and review. Document what this role is responsible for and what decisions require escalation. This is your governance layer.

    Identify independent subtasks. Look at your current agent workflows and find the tasks that can run in parallel. Sequential workflows where tasks are independent are leaving time on the table.

    Build state into your workflows. Every agent should write its output to a known location in a known format. Every downstream agent should read from that location. If you cannot inspect workflow state at any point without replaying the entire execution, your state management is insufficient.

    Set checkpoint reviews at decision points. Not at every step — that defeats the purpose. At points where an incorrect output would propagate downstream and cause real damage. A review that takes five seconds and prevents a two-hour debugging session is time well spent.

    Use the right model for the right role. Do not pay frontier-model prices for tasks that a free-tier model handles competently. Reserve your budget for the coordination and review layers where reasoning quality directly affects outcomes.

    If your organisation is moving from AI experimentation to production agent operations, the coordination layer is where the value is — and where the risk lives. The AI & Automation Architecture service covers the design of multi-agent systems with proper governance, state management, and cost controls. Or get in touch for a conversation about what your agent operations should look like before they scale.

  • What Multi-Agent Operations Actually Look Like in Practice

    What Multi-Agent Operations Actually Look Like in Practice

    Most organisations experimenting with AI agents are still operating them like a single chat window. Someone opens a prompt, asks the agent to do something, waits for the output, and moves on. That works for demos. It does not work when you are running agents against production systems or trying to get consistent results across a team.

    The gap is not technical. It is operational. The organisations getting genuine value from AI agents are not the ones with the most advanced models. They are the ones that figured out how to coordinate agents the way you would coordinate a team: clear roles, defined handoffs, checkpoint reviews, and someone accountable for the outcome.

    The Governance Gap Nobody Talks About

    The current wave of AI agent tooling is impressive. You can spin up an agent that writes code, another that reviews it, another that runs tests, and a fourth that deploys. The demos are compelling. The problem is that most organisations have not thought about what happens when these agents operate together at scale.

    Who coordinates them? What happens when two agents make conflicting changes? Where is the state stored, and who can inspect it? If an agent fails halfway through a task, what recovers? If an agent produces an incorrect output that another agent consumes, how do you trace the error back?

    These are the same questions you would ask about any multi-person production system. The difference is that agents do not have common sense, do not ask clarifying questions by default, and do not stop when something looks wrong unless you have built in the checks.

    The governance gap is this: most teams have moved from “can we run an agent?” to “we are running agents” without establishing the coordination layer in between.

    The Pattern That Actually Works

    After running autonomous coding agents in production for several months, the pattern that has proven reliable is a hybrid orchestration model. It has four parts.

    A coordinator role. One agent, or one human, owns the overall task. This role does not do the detailed work. It defines the objective, breaks it into independent subtasks, assigns each to a worker, and reviews the results. In practice, this is the role I occupy when running Hermes Agent, Claude Code, or Codex on a project. I set the direction, handle security decisions and state management, and delegate the pure coding work.

    Parallel worker agents. When subtasks are independent, they run simultaneously. Three agents working on three separate services at the same time complete in minutes what a single agent would handle sequentially in an hour. The key requirement is that the subtasks must be genuinely independent. If agent B depends on agent A’s output, running them in parallel creates conflicts, not speed.

    State machines for complex flows. When a task has sequential dependencies, a simple state machine prevents chaos. Each agent picks up the task at a defined state, does its work, writes output to a known location, and transitions the task forward. If an agent fails, the state does not advance. The next agent picks up the failed state and either retries or escalates.

    Checkpoint reviews. At defined points in the flow, a human reviews the output before the next stage begins. This is not a bottleneck. It is a safety mechanism. The review confirms that the output is sane, the state is correct, and the next stage has what it needs. In practice, these reviews take seconds when things are going well and save hours when they are not.

    A Concrete Example: Diagnosing Three Services at Once

    Suppose three independent services are exhibiting issues simultaneously. A traditional approach investigates them sequentially: diagnose service A, fix it, move to service B, fix it, move to service C.

    With a multi-agent setup, the coordinator defines the diagnostic task for each service and spins up three parallel subagents. Each agent gets the same instructions: examine the logs, identify the root cause, propose a fix, and write its findings to a shared state file. The agents do not communicate with each other. They do not need to. They are working on independent systems.

    When all three agents have completed their tasks, the coordinator reviews the findings, checks for conflicts (two agents proposing changes to a shared dependency, for example), and either approves the fixes or escalates for human review.

    A diagnostic process that would take a single engineer most of a day takes under thirty minutes. The quality is not lower — each agent focuses on a single problem without context-switching. The risk is not higher — the checkpoint review catches anything anomalous before it reaches production.

    This is not theoretical. It is a routine operational pattern that runs on free-tier models for the worker agents. The expensive model is the coordinator, and even that role can be handled by a human with a clear framework.

    The Cost Conversation

    There is a persistent misconception that running AI agents at scale requires expensive API subscriptions. In practice, the opposite is true. Worker agents doing diagnostics, code generation, and testing do not need frontier models. They need competent instruction-following, and that is available on free tiers or at very low cost.

    The coordinator role is where model quality matters. This is the agent making decisions about task decomposition, conflict resolution, and escalation. It needs to reason well. But there is only one coordinator, and it does relatively little token-heavy work compared to the workers.

    The cost structure in a well-designed multi-agent system is front-loaded into the coordination layer and minimal in the execution layer. You are paying for one good decision-maker and many cheap workers. The economics favour this model, which is one reason it works for cost-conscious organisations, not just well-funded ones.

    Failure recovery follows the same logic. When an agent fails on a free tier, the cost of retry is zero. When an agent fails on an expensive tier, every retry is a budget event. Putting cheap agents on high-volume work and the expensive agent on high-judgement work is not just an architectural decision. It is a cost optimisation.

    What Organisations Should Do Next

    If you are running or planning to run AI agents in production, the operational model matters more than model selection. Here is where to start.

    Define the coordinator role first. Decide whether a human or an agent owns task decomposition and review. Document what this role is responsible for and what decisions require escalation. This is your governance layer.

    Identify independent subtasks. Look at your current agent workflows and find the tasks that can run in parallel. Sequential workflows where tasks are independent are leaving time on the table.

    Build state into your workflows. Every agent should write its output to a known location in a known format. Every downstream agent should read from that location. If you cannot inspect workflow state at any point without replaying the entire execution, your state management is insufficient.

    Set checkpoint reviews at decision points. Not at every step — that defeats the purpose. At points where an incorrect output would propagate downstream and cause real damage. A review that takes five seconds and prevents a two-hour debugging session is time well spent.

    Use the right model for the right role. Do not pay frontier-model prices for tasks that a free-tier model handles competently. Reserve your budget for the coordination and review layers where reasoning quality directly affects outcomes.

    If your organisation is moving from AI experimentation to production agent operations, the coordination layer is where the value is — and where the risk lives. The AI & Automation Architecture service covers the design of multi-agent systems with proper governance, state management, and cost controls. Or get in touch for a conversation about what your agent operations should look like before they scale.

  • How Multi-Agent Operations Work in Practice

    How Multi-Agent Operations Work in Practice

    Most organisations still treat AI agents like a single chat window with extra buttons. That is fine for a demo. It is not fine when the work touches production systems.

    The difference is operational, not magical. The teams getting value from agents are the ones that add roles, checkpoints, and ownership.

    What works

    A reliable setup usually has four pieces:

    • a coordinator that defines the task and checks the output
    • worker agents that do independent chunks in parallel
    • state that lives somewhere everyone can inspect
    • review points before anything risky moves forward

    That is not glamorous, but it works.

    A simple example

    If three services are acting up at once, a good coordinator breaks the problem apart and sends each service to a separate worker. The workers do not need to talk to each other because the tasks are independent. The coordinator then compares the results and decides whether to approve the fix or escalate.

    That pattern saves time without turning the system into a black box.

    The cost question

    People often assume agent work must be expensive. In practice, the opposite is usually true. The cheap model can do the repetitive work. The better reasoning model is reserved for coordination and review.

    That split matters. It keeps the system affordable and keeps judgment where it belongs.

    What to do first

    1. Decide who owns the outcome.
    2. Identify which tasks can run in parallel.
    3. Make state visible.
    4. Add checkpoints where mistakes would hurt.

    That is enough to get started. The rest is tuning.

  • The Hidden IT Debt That Kills Deal Value

    The Hidden IT Debt That Kills Deal Value

    If you’re preparing for a transaction, the technology side of diligence is one of the few places where a couple of weeks of work can move the price by hundreds of thousands of pounds. Almost every founder I’ve worked with through a sale has discovered the same thing: the IT debt they thought was tolerable was visible to the buyer’s diligence team and got used as leverage.

    This post is the version I wish more founders saw twelve months before the process starts. It’s a list of the categories of technology debt that consistently show up in due diligence and consistently move price.

    Unsupported Software in Production

    This is the single most common finding. An old database version, an unsupported operating system on a key server, a desktop app that hasn’t been updated in years, a finance system on a release the vendor stopped patching three years ago.

    To the buyer this signals two things. First, an immediate cost they’ll have to absorb to bring you onto a supportable footing. Second, evidence that operational hygiene isn’t a strength — which raises questions about everything else.

    The fix is usually not exciting. Inventory what you have, identify everything outside support, and either upgrade, replace, or document a deliberate compensating control. The work isn’t hard; it’s that nobody’s been paid to do it. Twelve months out from a sale is the right time.

    Identity and Access Sprawl

    Diligence teams routinely pull a list of accounts with administrative privileges across your core systems. The list is almost always longer than expected, and it almost always includes:

    • People who left the business months or years ago
    • Service accounts with admin rights and no clear owner
    • Shared accounts where the password is in someone’s notes
    • Personal email addresses still tied to systems
    • Vendors and ex-vendors with access nobody has revoked

    A buyer reads that list and sees risk. Specifically, they see that an attacker who compromises any one of those accounts has admin reach across the estate.

    The corrective work is straightforward — a structured access review, removal of dormant accounts, mandatory MFA on what remains, separation of normal-user and admin identities — but it takes time to do properly. Done in a panic during diligence, it raises more questions than it answers.

    Single Points of Failure

    Every business has a few. The contractor who set up the original infrastructure and has the only credentials. The one engineer who knows how the data warehouse actually works. The single internet line at the head office. The cloud account that’s billed to a personal credit card. The third-party processor your operations cannot function without.

    Buyers don’t expect zero of these. They expect them to be documented, with mitigation in flight. What kills value isn’t the existence of dependencies — it’s the discovery that nobody has thought about them.

    The fix is partly technical (redundancy, secondary suppliers, properly owned cloud accounts) and partly documentation. Mostly it’s documentation. A diligence team is far less concerned about a single supplier dependency that you’ve identified, scoped, and have a plan for than they are about one they’ve found you didn’t know existed.

    Audit and Compliance Gaps

    If you process customer data — and almost every business does — your UK GDPR position will be reviewed. So will your security controls against any framework you’ve claimed: Cyber Essentials, ISO 27001, SOC 2. Buyers will check that your claims match reality.

    Common findings:

    • Records of processing that haven’t been updated in years
    • Data Protection Impact Assessments that don’t exist for systems where they should
    • A Cyber Essentials certificate from two years ago, with the controls now lapsed
    • Audit logs that aren’t actually being retained
    • A list of subprocessors that doesn’t match the systems in production

    Each of these is a moderate fix in isolation. Together they paint a picture of compliance theatre, and that picture is hard to repair under deal-team pressure. The right time to look at this is when you have months, not days.

    Patching and Vulnerability Backlog

    Most diligence engagements I’ve been part of include a vulnerability scan or, at minimum, a request for evidence that one has been done recently. The result almost always includes a tail of unpatched vulnerabilities that have been accumulating quietly.

    What raises the buyer’s concern isn’t the existence of vulnerabilities — every estate has them. It’s the absence of a process that systematically tracks, prioritises, and resolves them. If your IT manager or MSP can’t produce a patching SLA and evidence that it’s being met, the buyer will assume the worst.

    A defensible patching position takes a few months to establish. You need an inventory, a prioritisation method, an SLA your team can actually meet, and the evidence that proves it. None of this is technically complex. All of it takes time.

    Cloud Cost and Architecture Surprises

    If you’re running on AWS, Azure, or GCP, the buyer’s team will look at three things: what you’re spending, whether the architecture is appropriate to that spend, and whether you have any commercial commitments (Reserved Instances, Savings Plans, Enterprise Discount agreements) that affect the post-deal economics.

    Common findings:

    • Tens of thousands of pounds a month going to over-provisioned compute or unused storage
    • Architecture decisions made early that no longer fit the business
    • Multi-year commercial commitments that lock the new owner in to a specific spend pattern
    • A cloud bill split across multiple accounts and personal cards with no clear ownership

    This is one of the easier categories to address pre-deal — a competent cloud architect can produce a remediation plan in a couple of weeks. But it has to be done before the buyer’s team finds it, because once it’s in their report, the saving is theirs to negotiate, not yours.

    Vendor Contracts and Lock-In

    Buyers will read your major technology contracts. They look for auto-renewal clauses that have just triggered, change-of-control provisions that require vendor consent, multi-year commitments at above-market rates, and termination penalties that affect the integration plan.

    Surprises here are particularly painful because they affect the buyer’s post-completion options, not just the price. A discovered change-of-control clause requiring a key supplier’s consent can delay or even block the deal entirely.

    The fix is contract-by-contract: a structured review of your top vendor agreements, identification of the issues, and either renegotiation or clear documentation. This is unglamorous work that founders generally don’t want to spend money on. The pre-sale period is the moment when it pays for itself many times over.

    What Pre-Sale Cleanup Actually Looks Like

    The pattern across all of these is the same. Each finding, taken alone, is fixable in a few weeks. The problem is that there are usually six or seven of them, they all need somebody senior to triage and prioritise, and the actual remediation involves coordination with internal teams, MSPs, vendors, and lawyers.

    A useful pre-sale technology engagement is typically two to four months of part-time work, starting twelve to eighteen months out from the process. The output is:

    • A clear inventory of the technology and security position
    • A prioritised list of findings that would matter to a diligence team
    • A realistic remediation plan with effort and cost
    • Resolution of the highest-risk items before the data room opens
    • Documentation that turns the remaining items from surprises into footnotes

    What you’re buying with that engagement is a much better starting point for the diligence conversation. The buyer’s team will still find issues — they always do. The difference is that they’re issues you’ve already identified, scoped, and either fixed or explained. Which means the conversation in the negotiation room isn’t should we adjust the price, it’s we agree this is in flight.

    If you’re a founder twelve months out from a planned sale, or a fund-side advisor preparing a portfolio company for exit, this is the right time to look at the technology position. The cost of doing it now is small. The cost of having it found in someone else’s report is not.

    If you’re preparing a UK business for sale and want a clear read on the technology position before the data room opens, this is the kind of work I do. The full description is on the Technical Transformation & M&A service page, and the private-equity sector page covers the buy-side and portfolio engagements. Or just get in touch for a 30-minute conversation.

  • What I Consistently Find in UK Law Firm M365 Tenants

    What I Consistently Find in UK Law Firm M365 Tenants

    UK law firms run on Microsoft 365. The corporate departments use it for document management, email, file sharing; the matters move through Outlook and SharePoint; the partners’ calendars sit in Exchange. It’s the central nervous system of the firm, and the threat model around it is well understood by attackers — authentic-fraud, business-email-compromise, and targeted credential theft are routine.

    What surprises me is how consistent the audit findings are. Different firms, different sizes, different IT suppliers — and largely the same gaps. None of these are exotic. All of them are fixable. But until someone with a structured eye looks at the tenant, they tend to stay where they are.

    This is the list I’ve assembled over enough M365 audits in the legal space to call it a pattern. If you run a UK law firm or sit on the management committee of one, this is what your auditor or your fractional CISO is going to find when they look.

    1. Legacy Authentication Still Works

    This is the most common single finding and the most consequential. Legacy authentication protocols — Basic Auth on Exchange, IMAP, POP3, SMTP AUTH — don’t support modern multi-factor authentication. If they’re enabled, an attacker who phishes a username and password can sign in as that user, full stop, with no MFA challenge.

    In law firms it usually persists because of an old line-of-business application: a dictation tool, a billing add-in, a niche practice-management integration. Somebody enabled the protocol years ago to make it work, and nobody has been paid to come back and turn it off.

    The fix is a Conditional Access policy that blocks legacy authentication across the board, with explicit and documented exceptions for any application that genuinely still needs it. In most firms the exception list ends up being zero or one applications. Microsoft has been actively retiring these protocols for years, and there’s almost nothing legitimate left that requires them.

    2. Conditional Access Is Either Absent or Performative

    Most firms have MFA enabled. Far fewer have it enforced through Conditional Access policies that actually constrain where and how people can sign in.

    Common patterns:

    • MFA enforced for users but not for global administrators (because admins find it inconvenient)
    • No location-based restrictions, so an attacker in Russia or Vietnam can hit the sign-in page directly
    • No device compliance requirements, so any unmanaged device can authenticate
    • Mobile email access without app protection policies, so a lost or sold phone is an unmanaged data egress

    A defensible Conditional Access posture means: every user, every admin, every privileged account, with location and device controls appropriate to the role. It takes a structured deployment but it’s not technically complex, and the security delta is significant.

    3. Mail Flow Authentication Is Incomplete

    Almost every law firm I audit has SPF set up. Some have DKIM. Very few have DMARC at enforcement (p=reject or p=quarantine with a meaningful percentage).

    The gap matters because of how legal email is targeted. Authentic-fraud — where an attacker sends a fake invoice from a supplier address, or a fake completion-funds instruction from a counterparty — relies on being able to spoof the sending domain. Without DMARC at enforcement, your domain can be spoofed. With DMARC at enforcement, it can’t.

    DMARC is a journey, not a switch. You need to start at p=none, gather reports, identify legitimate senders that need configuring, fix them, and then move stepwise to p=quarantine and eventually p=reject. It typically takes six to ten weeks of attention, but the protection it produces — for clients, for counterparties, and for the firm’s reputation — is worth far more than the work.

    4. Admin Rights Are Vastly Over-Distributed

    The principle of least privilege says that admin rights should be the smallest possible set, granted to the smallest possible group, for the shortest possible time. The reality in most firms is the opposite. The IT manager is a global admin. So is their deputy. So are two engineers at the MSP. So is the partner who set up the original tenant. So is the consultant who came in to fix the email migration in 2019.

    When I audit, I routinely find five or six accounts with global admin privileges. Often more. Each of those accounts is a high-value target — phishing one of them gets the attacker the keys to the entire estate.

    The corrective work is straightforward but politically delicate. You need to:

    • Inventory every account with privileged roles
    • Remove anyone who doesn’t need the role on a daily basis
    • Move the rest to Privileged Identity Management (PIM) so they hold the role only when they need it
    • Separate normal-user accounts from admin accounts (so phishing the user account doesn’t compromise admin)
    • Require MFA and Conditional Access on the admin accounts at a higher bar than normal users

    This is one of the most impactful changes a firm can make. It takes weeks, not months. And it dramatically reduces the blast radius of any compromise.

    5. Audit Logging Is Often Misconfigured

    The unified audit log in M365 is invaluable when something has happened — a suspicious sign-in, a mass file download, a new mail forwarding rule on a partner’s account. But it has to be enabled, with retention long enough to be useful, and reviewed against alerts that catch the things you actually care about.

    In many tenants I find:

    • Unified audit logging never enabled, or enabled for only some workloads
    • Retention set to the licensing default of 90 days when an investigation might need to go back a year
    • No alerts configured for high-risk events (impossible-travel sign-ins, mass downloads, mailbox forwarding rules, OAuth grants to suspicious applications)

    For a firm of any size, the log is your evidence base when you need to demonstrate to clients, insurers, or the SRA that you’ve understood and responded to an incident. Without it, you have stories. With it, you have evidence.

    The configuration takes an afternoon. The alert tuning takes longer — but that’s where the value is.

    6. SharePoint Permissions Are a Mess

    This is the finding most law firms underestimate. SharePoint Online underpins the document store; in many firms it’s the de-facto matter file system, often with a document management overlay on top. Permissions in SharePoint are notoriously easy to set up incorrectly and notoriously hard to audit afterwards.

    Common findings:

    • Sites where “Everyone except external users” has read or edit access — meaning every employee can see every matter
    • Documents shared via “anyone with the link” with no expiry, where the link has been forwarded around
    • Guest access enabled on sites that should be internal-only
    • Inherited permissions broken in places that nobody documented
    • Former employees still appearing in permission groups long after their accounts were disabled

    The corrective work is unglamorous: a structured permissions review, retirement of broad-access shares, replacement of “anyone with the link” sharing with proper guest access, and access reviews scheduled into the calendar. It’s an ongoing discipline, not a one-off project. But the principle is non-negotiable for a law firm — confidentiality obligations don’t allow for a permissions model where anyone can see anything.

    What This Adds Up To

    None of these findings are exotic. None of them require expensive tooling beyond what’s already in your M365 licensing. What they require is somebody with a structured eye to look at the tenant, identify the gaps, and have the institutional weight to actually drive the corrective work to completion.

    That’s almost always the gap. The IT manager or the MSP knows about most of these issues — they live with the symptoms — but they don’t have the time, the seniority, or the air-cover to push through the work. A fractional CISO engagement gives you that. A structured audit gives you the prioritised list.

    If you run a UK firm, the question worth answering this quarter is: when did somebody actually look at the tenant? If the answer is more than a year ago or never, this is the work that pays back fastest.

    If you’d like a structured M365 audit for your firm, the work sits inside the Security & Compliance Strategy service, and the legal-sector page covers how I scope this for law firms specifically. Or just get in touch for a 30-minute conversation about where your tenant stands.

  • What a Cyber Essentials Plus Audit Actually Involves

    What a Cyber Essentials Plus Audit Actually Involves

    What a Cyber Essentials Plus Audit Actually Involves
    Published: April 8, 2026

    Cyber Essentials and Cyber Essentials Plus are often mentioned in the same breath, but they’re meaningfully different certifications. Cyber Essentials is self-assessed — you answer a questionnaire about your controls and a certification body reviews your answers. Cyber Essentials Plus involves an auditor actually testing whether your controls work.

    If you’re being asked to achieve CE Plus — by a public sector client, a large enterprise in your supply chain, or your cyber insurance provider — it helps to know what you’re walking into.

    The Five Technical Controls

    Both certifications are built around the same five technical control areas. Cyber Essentials Plus tests all five through active assessment:

    1. Firewalls — boundary firewalls and internet gateways are configured to block unauthorised access
    2. Secure configuration — devices and software are configured securely, unnecessary services removed
    3. User access control — user accounts are managed, access is limited to what’s needed, admin rights are controlled
    4. Malware protection — protection against malicious software on devices
    5. Patch management — operating systems and software are up to date and vulnerabilities are patched promptly

    The assessment tests these controls against your actual devices and environment. It’s not a paper exercise.

    What the Assessment Actually Looks Like

    The assessment is conducted remotely in the vast majority of cases, using a combination of automated scanning tools and manual verification. The auditor will need access to representative sample devices across your environment — typically a mix of Windows, macOS, and mobile if applicable — as well as access to your network boundary.

    External vulnerability scan — the assessor scans your internet-facing infrastructure for open ports, accessible services, and known vulnerabilities. Anything exposed that shouldn’t be is a finding.

    Internal device sampling — the assessor will check a sample of user devices. They’re looking at: is the OS up to date, are software patches current, is malware protection active and updated, are there unnecessary admin rights on user accounts, is the device configured securely (screensaver lock, auto-update, no unnecessary services).

    User account review — they’ll look at your Active Directory or Entra ID (Azure AD) to check for unused accounts, accounts with unnecessary admin privileges, and whether your admin accounts are separate from day-to-day user accounts.

    Browser configuration — browsers are specifically assessed. Extensions, default security settings, and whether browser-based malware protection is active.

    The whole process typically takes half a day to a day depending on the size of your environment.

    Where Businesses Fail

    Having supported a number of UK businesses through CE Plus, the failure points are consistent:

    Patching lag on end-user devices. The standard requires that high and critical vulnerabilities are patched within 14 days of a patch being released. Most businesses aren’t meeting this. Laptops that are rarely connected to the corporate network, personal devices used for work, and machines that haven’t been restarted in months are the typical culprits.

    Admin rights on standard user accounts. This is extremely common. Users who were given admin rights to install something three years ago and still have them. Sometimes it’s the entire organisation because “it was just easier”. CE Plus will fail on this.

    Unsupported software. An application that hasn’t received a security update in over a year, or is running on an end-of-life OS version, is a straight failure. This catches people out when they have legacy line-of-business software that the vendor no longer patches.

    Scope creep surprises. Businesses sometimes underestimate what’s in scope. If a personal mobile phone is used to access company email or data, it’s in scope. If a contractor’s laptop connects to your network, it may be in scope. Agreeing the scope boundary clearly before assessment avoids surprises.

    External exposure they didn’t know about. Open ports, misconfigured cloud services, old VPN endpoints — the external scan sometimes surfaces things the business genuinely didn’t know were there.

    How to Prepare

    If you’re planning to pursue CE Plus, give yourself at least six to eight weeks of preparation time — more if you know patching or access control is in a poor state.

    Start with a self-assessment against the Cyber Essentials requirements document. Work through each of the five controls honestly. Where you can’t answer yes confidently, that’s where you need to focus.

    Fix patching first. This is the most common failure point and the one that takes the longest to fix systematically. You need a repeatable process, not a one-off catch-up before the audit.

    Audit your admin rights. Pull a full list of accounts with local admin or domain admin privileges. Anything that isn’t explicitly needed and documented should be removed before the assessment.

    Check your software inventory. Identify anything running on an unsupported version. Either update it, replace it, or make a decision about scope exclusion (with appropriate compensating controls).

    Agree scope in writing before the assessment starts. Be explicit about what’s included: which devices, which network segments, which cloud services.

    Is It Worth It?

    Aside from the contractual requirements — and CE Plus is increasingly required for UK government supply chain and some financial services clients — the process is genuinely useful. Going through it forces a structured review of controls that most businesses have never done systematically.

    The businesses I’ve seen come through it well are the ones that treated preparation as an IT improvement project, not a box-ticking exercise. The ones that struggle are the ones that try to do the minimum to pass rather than fixing the underlying issues.

    If you need support preparing for Cyber Essentials Plus, I offer a structured readiness assessment that works through all five control areas and produces a prioritised remediation list before you engage a certification body. It sits inside the Security & Compliance Strategy service.

    Get in touch to discuss CE Plus preparation.

  • 2026 AI Threats for UK SMEs: What’s Actually Changed

    2026 AI Threats for UK SMEs: What’s Actually Changed

    2026 AI Threats for UK SMEs: What’s Actually Changed
    Published: April 1, 2026

    Every year brings a new round of threat reports telling SMEs that cyber risk is increasing. That’s been true for twenty years. What’s different in 2026 is that AI has genuinely changed the threat landscape — not just the scale of attacks, but the nature of them. The traditional advice still applies, but it’s no longer sufficient on its own.

    Here’s what I’m seeing, and what UK SMEs actually need to be thinking about.

    Phishing Has Crossed a Quality Threshold

    For years, phishing emails were easy to spot if you knew what to look for: odd phrasing, generic greetings, suspicious sender domains, poorly formatted logos. Staff training focused on these signals, and it worked reasonably well.

    AI-generated phishing has removed most of those signals. Emails are now grammatically perfect, contextually appropriate, and personalised using data scraped from LinkedIn, company websites, and previous data breaches. I’ve seen examples targeting UK SME directors that reference their specific clients, their recent hires, and their company structure — all publicly available, all assembled automatically at scale.

    The implication isn’t that training is useless. It’s that training needs to evolve. Spotting typos is no longer the point. The question to train staff on is: was I expecting this request? Does this ask me to do something — click, pay, approve, share credentials — and if so, have I verified it through a separate channel?

    Deepfake Audio and Video Are Becoming Operational

    This was theoretical eighteen months ago. It’s operational now. UK businesses have experienced losses from voice-cloned fraud — attackers using AI-generated audio of a senior person in the business to instruct a finance team member to make a payment.

    The attack is effective because it bypasses the email security controls most businesses have invested in. It’s a phone call. It sounds like the CFO. It says there’s an urgent payment that needs to go today.

    The defence is procedural, not technical: any payment instruction, regardless of how it arrives or who it appears to be from, above a threshold amount requires verification via a pre-agreed method. That policy needs to be written, communicated, and tested.

    Shadow AI Is Creating Data Exposure You Don’t Know About

    Your staff are using AI tools. If you haven’t explicitly told them which tools are approved and what data they can put into them, they’re making those decisions themselves — and the decisions aren’t always good ones.

    I’ve spoken to business owners who didn’t know their team had been pasting client contracts into ChatGPT to summarise them, or putting commercially sensitive proposals into AI writing tools, or using consumer AI assistants for analysis that contains personal data. None of it was malicious. None of it was authorised either.

    The fix isn’t to ban AI — that’s both impractical and counterproductive. The fix is a clear AI use policy: which tools are approved, what data categories can be used with each, and what’s prohibited. It doesn’t need to be long. It needs to exist.

    Automated Vulnerability Exploitation Has Accelerated

    AI tools have significantly reduced the time between a vulnerability being disclosed and active exploitation in the wild. The window between a patch being released and attackers using the underlying vulnerability against unpatched systems is now measured in hours in some cases, not weeks.

    For SMEs running on-premise infrastructure or self-managed cloud services, this puts a new premium on patching speed. Monthly patching cycles — which were never ideal — are now genuinely inadequate for critical vulnerabilities. Critical patches need a 24–72 hour response window as a minimum.

    If you’re running an MSP or internal IT team, this is worth an explicit conversation: what is your current patching SLA for critical CVEs, and can you demonstrate that it’s being met?

    Prompt Injection Is a Real Risk If You’re Using AI in Your Workflows

    This one is less widely understood but increasingly relevant for businesses that have started integrating AI into their operations — customer-facing chatbots, AI-assisted document processing, automated workflows.

    Prompt injection is an attack where malicious instructions are hidden in content that an AI system processes — a document, an email, a form submission — and those instructions cause the AI to behave in unintended ways. In a customer service chatbot, that might mean the AI leaks internal information or gives incorrect advice. In an AI-assisted finance workflow, the implications can be more serious.

    If you’re deploying AI in any operational context, your vendor or developer needs to demonstrate they’ve thought about this. It should be on your checklist when evaluating any AI-powered tool.

    What This Means in Practice

    None of this requires a large security budget. It requires clear thinking about where your exposure is and proportionate controls.

    For most UK SMEs in 2026, the immediate priorities are:

    1. Update your phishing awareness training to reflect AI-generated threats — not just “spot the typo”
    2. Implement a payment verification policy that can’t be bypassed by a convincing phone call
    3. Publish an AI use policy before something goes wrong
    4. Review your patching SLA for critical vulnerabilities with your IT team or MSP
    5. If you’re using AI in any operational workflow, get a basic security review of how it’s been deployed

    If you’re not sure where to start, a Discovery Audit will give you a prioritised picture of your current exposure across all of these areas. The AI-specific side of this — governance, threat modelling, and safe deployment — sits in the AI & Automation Architecture service.

    Book a call to discuss your security position.

  • Your M365 Tenant Has More Exposure Than You Think

    Your M365 Tenant Has More Exposure Than You Think

    Your M365 Tenant Has More Exposure Than You Think
    Published: March 24, 2026

    Most small and mid-sized businesses running Microsoft 365 believe they’re reasonably well protected. They’re paying for the licences, they’ve got MFA turned on (probably), and their IT provider or MSP set it all up. What more is there to do?

    Quite a lot, as it turns out. When I audit an M365 tenant — and I’ve audited more than I can count — I consistently find the same set of misconfigurations and over-permissions. Not because anyone did anything wrong, but because the defaults Microsoft ships aren’t designed for your security posture. They’re designed for onboarding speed.

    Here’s what I typically find.

    Legacy Authentication Is Still Enabled

    This is the single most common finding, and it’s the one that matters most. Legacy authentication protocols — Basic Auth, SMTP AUTH, IMAP, POP3 — don’t support modern multi-factor authentication. If they’re enabled, an attacker who gets hold of a username and password can authenticate without needing to pass MFA at all.

    Microsoft has been moving to block legacy auth for years, but many tenants still have it partially or fully enabled — often because someone needed it for an old application or printer, and nobody ever turned it off again.

    The fix is to create Conditional Access policies that block legacy authentication across the board, with explicit exceptions only where you have a genuine and documented business need.

    Too Many Global Admins

    Almost every tenant I audit has more Global Administrators than it should. In some cases I’ve seen five or six people with Global Admin — in a company of 40 people.

    Global Admin is the highest privilege level in a Microsoft 365 tenant. Anyone with it can create accounts, access all data, modify security settings, and disable MFA. It should be used sparingly, with dedicated admin accounts (not day-to-day user accounts), and protected with phishing-resistant MFA.

    The principle of least privilege applies here. Most people who are Global Admins don’t need to be. Exchange Administrator, User Administrator, and Security Reader roles cover 90% of what people actually need to do.

    MFA Is On, But Not Enforced Everywhere

    MFA adoption in SMEs has improved significantly. But “MFA is enabled” and “MFA is enforced” are different things.

    In many tenants, MFA is configured via the legacy Per-User MFA panel rather than Conditional Access. This approach has gaps — it doesn’t cover service accounts, doesn’t handle different risk levels, and gives users the option to skip registration. I’ve seen tenants where MFA is “enabled” for all users but 20% of them have never actually registered a method.

    Conditional Access gives you proper control: require MFA for all users, all apps, with no exceptions except explicit break-glass accounts. If you’re on Microsoft 365 Business Premium, you have the licences for it. Most businesses aren’t using them properly.

    External Sharing Is Wide Open

    SharePoint and OneDrive external sharing defaults are permissive. In a default or lightly configured tenant, users can share files externally with anyone, with no expiry, no notification to IT, and no audit trail in a place anyone looks at.

    I’ve found tenants where sensitive commercial documents — contracts, financials, client data — had been shared externally via “anyone with the link” and had been sitting that way for two or three years. Nobody knew.

    The fix is to review and restrict your SharePoint sharing settings at tenant level, enable sharing expiry for external links, and configure alerts for broad external sharing events.

    Email Security Is Incomplete

    SPF is usually configured — it’s been standard practice for long enough that most tenants have it. DKIM and DMARC are a different story.

    Without DKIM signing, emails from your domain can be spoofed with a reasonable success rate. Without a DMARC policy at enforcement (p=reject or p=quarantine), you have no mechanism to prevent or monitor spoofing of your domain. Most tenants I audit have DMARC either missing entirely, or set to p=none — monitoring only, no protection.

    For a business of any size, a properly configured email authentication stack (SPF + DKIM + DMARC at enforcement) is non-negotiable. It’s not complex to implement, and the protection it provides against phishing and impersonation is significant.

    Audit Logging Isn’t Turned On Properly

    M365 has a unified audit log that captures sign-in events, admin actions, file access, mail forwarding rules, and much more. It’s invaluable when you’re investigating an incident — or trying to demonstrate compliance.

    In many tenants it’s not enabled, or it’s enabled but the retention period is set to 90 days (the default for most licence types). If you need to investigate something that happened four months ago, that’s a problem.

    Check that unified audit logging is enabled, review your retention settings, and make sure you have alerts configured for high-risk events: impossible travel sign-ins, mass download events, new mail forwarding rules.

    What to Do With This

    None of this is exotic. These are all configurations within the Microsoft 365 Admin Center and the Security portal — no additional tooling required. But they take time to work through properly, and they require someone who knows what they’re looking at.

    If you want to know exactly where your tenant stands, I run a structured M365 security audit that covers all of the above and more, with a prioritised findings report. It typically takes half a day and gives you a clear picture of your exposure. It sits inside the broader Security & Compliance Strategy service.

    Get in touch to discuss an M365 audit for your business.

Powered by