RichardHam.co.uk Blog

Tag: audit

  • Why AI Workflows Need Audit Trails

    Why AI Workflows Need Audit Trails

    The conversation around AI has shifted. It is no longer just about drafting text or summarising meetings. More and more often, these systems are taking actions on live business processes.

    That is where the risk changes shape.

    A clever prompt can produce a good-looking result. It cannot tell you what happened after the fact if the output was wrong.

    The gap

    When a person makes a decision in a process, there is usually some trace of it. An email, a ticket, a sign-off, a log entry. With an AI system, that trace is often thin or missing.

    If the system updates the wrong record or sends the wrong message, the team is left with a result and very little explanation.

    What breaks without logs

    • You cannot reconstruct the sequence of events.
    • You cannot show who approved what.
    • You cannot improve the workflow with confidence.

    That is not just a debugging problem. It is an accountability problem.

    What a useful audit trail looks like

    At minimum, every execution should capture:

    • the input it received
    • the steps it took
    • the action it actually executed
    • the output it produced
    • the timestamp and identity of the run

    That is enough to answer the questions that matter later.

    The practical bit

    The tooling is already there. Structured logs, append-only storage, and reviewable traces are all enough to get started. The main thing is to design for visibility before the workflow is under pressure.

    If the system is allowed to act, it should also be required to explain itself.

  • The M365 Audit You Can Run Before Calling a Consultant

    The M365 Audit You Can Run Before Calling a Consultant

    Last month I published a post about the M365 security baseline most SMEs skip — the default tenant configuration that leaves businesses exposed because no one with security expertise has reviewed it since the initial migration.

    That post explained what to check. This one gives you the tool to check it.

    I built an open-source M365 Audit Toolkit and put it on GitHub. It is a set of read-only PowerShell modules that connect to your tenant using your credentials, interrogate the configuration, and produce a structured report of what is misconfigured, missing, or ranging beyond what you would reasonably accept. It does not change anything. It does not write data. It reads, evaluates, and reports.

    And it is designed so that you can run it yourself — before you pick up the phone to a consultant.

    Why a Self-Service Audit

    Most UK SMEs operate in a state of confident uncertainty about their M365 tenant. The IT provider set it up. It works. Email flows. SharePoint files sync. Teams calls connect. Everything appears fine.

    But “fine” is not a security posture. It is an absence of visible failure.

    The problem is that the gaps in an M365 tenant are invisible until they are not. A compromised account exposes every SharePoint site the user can reach. A forgotten guest account with access to a shared folder persists indefinitely. A mailbox that has never been audited leaves no trail when something goes wrong. These gaps do not generate alerts. They do not appear in the admin console with a red warning icon. They sit quietly until a breach unmasks them, a subject access request forces you to find every piece of personal data in the tenant, or a client’s due diligence questionnaire asks questions you cannot answer.

    I built the toolkit because the cost of a structured audit should not be a barrier to knowing where you stand. You should not need to engage a consultant just to find out whether your conditional access policies are configured, your admin roles are clean, or your retention policies align with your data retention schedule.

    Run the audit first. Understand your gaps. Then decide whether you need help closing them.

    What the Toolkit Covers

    The M365 Audit Toolkit is modular. You can run the full audit or pick the modules relevant to your situation currently and build from there. At present it covers five areas.

    Security Baseline Assessment. Checks MFA enforcement across all users, verifies that legacy authentication protocols is blocked, reviews conditional access policy configuration, mailbox auditing status, and DLP label deployment. This maps directly to the seven controls most SMEs skip.

    Admin Role Hygiene. Identifies every global administrator in the tenant, flags accounts that should not hold that role, checks for service principal permissions that grant equivalent access, and reports on role-based access control adoption for other administrative functions. If your tenant has four, six, or eight global admins, this module will tell you exactly who they are and what they can do.

    Guest Access Audit. Enumerates every external guest account in the tenant, what they can access, when they were last active, and whether access reviews are configured. This is the module that finds the former contractor who still has access to your shared folders three years after their engagement ended — which is more common than you would think.

    SharePoint and OneDrive Governance. Reviews site-level sharing settings, detects externally shared content, checks for orphaned sites, and reports on storage allocation and versioning configuration. If you have ever wondered how much of your organisation’s data is sitting in personal OneDrive accounts that the business does not back up and cannot access, this module provides the answer.

    AI Readiness Evaluation. Assesses your tenant’s readiness to adopt Copilot and other AI services safely — reviewing sensitivity label coverage, data loss prevention configuration, and access controls that would govern what an AI service can surface to users. This is increasingly relevant as Microsoft bundles Copilot into enterprise and business tiers.

    How to Run It

    The toolkit uses interactive MFA authentication, meaning it connects as you and inherits your permissions. It does not require app registrations, client secrets, or service accounts. If you have global reader access to the tenant, you can run the audit.

    The general workflow:

    1. Clone the repository from GitHub and review the modules.
    2. Connect to your tenant using interactive browser-based MFA authentication.
    3. Select the modules relevant to your assessment — security baseline, guest access, governance, AI readiness, or all of them.
    4. Review the output as a structured summary showing what passed, what failed, and what needs attention.

    The entire process can be completed in under an hour for a typical SME tenant. The output is a point-in-time snapshot — it does not persist data, and it does not leave artefacts in your tenant beyond the sign-in logs generated by your own authentication.

    When to Call a Consultant

    Running the audit yourself is the right first step. But there are situations where the findings will tell you that it is time to bring in expertise.

    • The report is long and you do not know where to start. If every module returns significant findings, the remediation effort is material and benefits from prioritisation and sequencing — which is exactly what a structured engagement provides.
    • You lack the permissions or authority to make changes. If the audit reveals that conditional access policies need to be reconfigured but your IT provider controls the tenant, the value of the report is in telling you exactly what to ask for and why.
    • You are preparing for client due diligence, a cyber insurance application, or a regulatory review. The audit output gives you a factual baseline, but remediation may need to be documented, evidenced, and in some cases certified.
    • You are adopting Copilot or other AI services. The AI readiness module will tell you where your gaps are, but closing them — sensitivity labels, access controls, DLP policies — is a project that benefits from experience doing it.

    The point is not to avoid consultants. The point is to arrive at that conversation informed, with a clear picture of what needs to be done rather than starting from a blank page.

    The Checklist Before You Pick Up the Phone

    If you want to understand your M365 tenant before committing to an engagement, here is the minimum viable assessment:

    • [ ] Run the security baseline module and resolve any critical MFA or conditional access findings
    • [ ] Run the admin role module and reduce global administrators to two or three accounts
    • [ ] Run the guest access module and revoke access for accounts no longer needed
    • [ ] Review the SharePoint governance report for externally shared sites and orphaned content
    • [ ] Review the AI readiness output if Copilot adoption is on your roadmap

    If you can work through that list and resolve the findings, your tenant is in materially better shape. If you cannot, you now have a specific, evidenced brief for what needs to happen next.

    The M365 Audit Toolkit is available now on GitHub. It is free, read-only, and built for exactly this use case.

    If you run it and the findings warrant a conversation, the Security & Compliance Strategy service covers M365 tenant configuration as part of a broader engagement. Or get in touch with your report — I can tell you within a 30-minute call whether the gaps are ones you can close yourself or whether it is time to bring in support.

  • Why Agentic AI Needs Audit Trails, Not Just Clever Prompts

    Why AI Workflows Need Audit Trails

    The conversation around AI has shifted. It is no longer just about drafting text or summarising meetings. More and more often, these systems are taking actions on live business processes.

    That is where the risk changes shape.

    A clever prompt can produce a good-looking result. It cannot tell you what happened after the fact if the output was wrong.

    The gap

    When a person makes a decision in a process, there is usually some trace of it. An email, a ticket, a sign-off, a log entry. With an AI system, that trace is often thin or missing.

    If the system updates the wrong record or sends the wrong message, the team is left with a result and very little explanation.

    What breaks without logs

    – You cannot reconstruct the sequence of events.
    – You cannot show who approved what.
    – You cannot improve the workflow with confidence.

    That is not just a debugging problem. It is an accountability problem.

    What a useful audit trail looks like

    At minimum, every execution should capture:

    – the input it received
    – the steps it took
    – the action it actually executed
    – the output it produced
    – the timestamp and identity of the run

    That is enough to answer the questions that matter later.

    The practical bit

    The tooling is already there. Structured logs, append-only storage, and reviewable traces are all enough to get started. The main thing is to design for visibility before the workflow is under pressure.

    If the system is allowed to act, it should also be required to explain itself.

  • Why Agentic AI Needs Audit Trails, Not Just Clever Prompts

    Why Agentic AI Needs Audit Trails, Not Just Clever Prompts

    The conversation around AI in business has shifted. For the past two years, most organisations have experimented with generative AI as a productivity tool — drafting documents, summarising meetings, answering questions. The model receives input, produces output, and a human reviews the result.

    That is no longer the whole picture.

    Across the organisations I work with, AI is moving from answering questions to taking actions. Agents execute n8n workflows that move data between systems. They trigger Hermes agents that read, write, and decide. They call APIs, update records, send messages, and make operational decisions — sometimes with human approval, sometimes without.

    This is agentic AI: systems that do not just respond, but act. It creates a governance problem that clever prompts alone cannot solve.

    The Governance Gap

    When a human makes a decision in a business process, there is usually a trace. An email sent, a form submitted, a system log entry, a manager’s sign-off. When something goes wrong, you can reconstruct the sequence of events. You can ask: what were they asked to do, what did they do, and why?

    When an AI agent executes an action, that trace often does not exist. The agent receives a prompt, processes it through one or more model calls, and performs an action. If the action is wrong — if it updates the wrong record, sends a message to the wrong person, or executes a workflow it should not have — the organisation is left with a result and no explanation.

    This is not a theoretical risk. In my own infrastructure, I have built agentic workflows that interact with live systems. The difference between a safe deployment and an unsafe one is not the quality of the prompt. It is whether the system logs enough information to reconstruct what happened after the fact.

    What Happens Without Audit Trails

    Without audit trails, three things break down.

    You cannot reconstruct events. If an agent produces an incorrect output or takes an unintended action, you need to know what input it received, which model or tool it called, what intermediate decisions it made, and what action it executed. Without this, debugging is guesswork. You are trying to diagnose a problem without access to the patient’s notes.

    You cannot establish accountability. When an automated system causes harm — a data breach, a financial error, a compliance failure — someone needs to be able to explain what happened. Under UK GDPR, the accountability principle requires organisations to demonstrate compliance, not just claim it. If your AI agent processes personal data and you cannot show what it did with that data, you are not compliant. It does not matter how good the system is in theory.

    You cannot improve the system. Agentic AI systems iterate. You adjust prompts, change tool configurations, add guardrails. Without structured logs of what each execution actually did, you are optimising in the dark.

    What a Practical Audit Trail Looks Like

    An audit trail for an agentic AI system does not need to be complex. It needs to be consistent and complete. At minimum, each agent execution should capture:

    • Input received. What was the agent asked to do? This includes the user’s request, any system context, and the prompt that was constructed.
    • Decision chain. What steps did the agent take? Which tools did it call? What intermediate outputs did it produce? For multi-step agents, this is the sequence of reasoning that led to the final action.
    • Action taken. What did the agent actually do? Which API was called, which record was updated, which message was sent.
    • Output produced. What was the final result returned to the user or passed to the next step in the workflow.
    • Timestamp and identity. When did this happen, and which agent or workflow executed it?

    This is not excessive. It is the same information you would expect from any business system that takes actions on data. The fact that the system is powered by a language model does not change the requirement — it increases it, because the system’s behaviour is less deterministic and harder to predict.

    The Regulatory Dimension

    For UK organisations, this is not optional. UK GDPR Article 5(2) establishes the accountability principle: you must be able to demonstrate that you comply with data protection principles. If an AI agent processes personal data — and most business agents do — you need to show what data it accessed, what it did with that data, and on what basis.

    Article 30 requires records of processing activities. An agent that processes client records, employee data, or customer information is conducting processing activity. If you cannot produce a log of that activity, you do not have the records the regulation requires.

    For financial services firms, the FCA’s operational resilience framework adds another layer. Important business services must withstand disruption and recover. If your AI agents are part of an important business service — processing transactions, managing client communications, monitoring risk — you need to understand how they behave, what they depend on, and what happens when they fail. Audit trails are the evidence base for your resilience assessment.

    How to Implement Audit Trails in Agent Workflows

    The good news is that the tooling exists. You do not need to build this from scratch.

    Structured logging at every node. In n8n workflows, each node can be configured to log its input and output. For agentic workflows, you should log at minimum the trigger, each decision point, and the final action. Use a consistent schema — timestamp, node name, input summary, output summary, and execution status — so that logs are searchable and comparable.

    Observability platforms. Tools like Langfuse are designed for exactly this purpose. They capture the full execution trace of an agent: prompt, model response, tool calls, and final output. When connected to your workflow engine, they give you a queryable record of every agent execution without building custom logging infrastructure.

    Immutable storage. Audit logs must be tamper-evident. If the log can be modified after the fact, it is not an audit trail — it is a diary. Store logs in append-only storage with access controls that prevent modification. This can be as simple as writing to a write-once bucket or using a logging service that enforces retention policies.

    Structured output from agents. Design your agents to return structured output, not just free text. A JSON response that includes the action taken, the target system, and the rationale is far more useful for auditing than a paragraph of prose. This also makes it easier to validate agent behaviour programmatically — you can check that the action taken is within the set of permitted actions before it executes.

    Regular review. Audit trails are only useful if someone looks at them. Build a review cadence — weekly for high-risk agents, monthly for lower-risk ones — where you sample executions and check for anomalies.

    The Bottom Line

    The organisations that will get the most value from agentic AI are not the ones with the most sophisticated prompts. They are the ones that can trust their agents to act safely, verify what those agents did, and improve them over time.

    Audit trails are the foundation of that trust. They are how you move from hoping your agents behave to knowing they do. They are how you satisfy regulators, reassure boards, and sleep at night.

    If you are deploying agentic AI in your organisation — or planning to — audit infrastructure is not a phase-two consideration. It is a prerequisite.

    If you are building agentic AI systems and need help establishing the governance, architecture, and audit infrastructure to support them, the AI & Automation Architecture service covers exactly this. For a broader conversation about where your organisation stands, get in touch.

  • Why Agentic AI Needs Audit Trails, Not Just Clever Prompts

    Why Agentic AI Needs Audit Trails, Not Just Clever Prompts

    The conversation around AI in business has shifted. For the past two years, most organisations have experimented with generative AI as a productivity tool — drafting documents, summarising meetings, answering questions. The model receives input, produces output, and a human reviews the result.

    That is no longer the whole picture.

    Across the organisations I work with, AI is moving from answering questions to taking actions. Agents execute n8n workflows that move data between systems. They trigger Hermes agents that read, write, and decide. They call APIs, update records, send messages, and make operational decisions — sometimes with human approval, sometimes without.

    This is agentic AI: systems that do not just respond, but act. It creates a governance problem that clever prompts alone cannot solve.

    The Governance Gap

    When a human makes a decision in a business process, there is usually a trace. An email sent, a form submitted, a system log entry, a manager’s sign-off. When something goes wrong, you can reconstruct the sequence of events. You can ask: what were they asked to do, what did they do, and why?

    When an AI agent executes an action, that trace often does not exist. The agent receives a prompt, processes it through one or more model calls, and performs an action. If the action is wrong — if it updates the wrong record, sends a message to the wrong person, or executes a workflow it should not have — the organisation is left with a result and no explanation.

    This is not a theoretical risk. In my own infrastructure, I have built agentic workflows that interact with live systems. The difference between a safe deployment and an unsafe one is not the quality of the prompt. It is whether the system logs enough information to reconstruct what happened after the fact.

    What Happens Without Audit Trails

    Without audit trails, three things break down.

    You cannot reconstruct events. If an agent produces an incorrect output or takes an unintended action, you need to know what input it received, which model or tool it called, what intermediate decisions it made, and what action it executed. Without this, debugging is guesswork. You are trying to diagnose a problem without access to the patient’s notes.

    You cannot establish accountability. When an automated system causes harm — a data breach, a financial error, a compliance failure — someone needs to be able to explain what happened. Under UK GDPR, the accountability principle requires organisations to demonstrate compliance, not just claim it. If your AI agent processes personal data and you cannot show what it did with that data, you are not compliant. It does not matter how good the system is in theory.

    You cannot improve the system. Agentic AI systems iterate. You adjust prompts, change tool configurations, add guardrails. Without structured logs of what each execution actually did, you are optimising in the dark.

    What a Practical Audit Trail Looks Like

    An audit trail for an agentic AI system does not need to be complex. It needs to be consistent and complete. At minimum, each agent execution should capture:

    • Input received. What was the agent asked to do? This includes the user’s request, any system context, and the prompt that was constructed.
    • Decision chain. What steps did the agent take? Which tools did it call? What intermediate outputs did it produce? For multi-step agents, this is the sequence of reasoning that led to the final action.
    • Action taken. What did the agent actually do? Which API was called, which record was updated, which message was sent.
    • Output produced. What was the final result returned to the user or passed to the next step in the workflow.
    • Timestamp and identity. When did this happen, and which agent or workflow executed it?

    This is not excessive. It is the same information you would expect from any business system that takes actions on data. The fact that the system is powered by a language model does not change the requirement — it increases it, because the system’s behaviour is less deterministic and harder to predict.

    The Regulatory Dimension

    For UK organisations, this is not optional. UK GDPR Article 5(2) establishes the accountability principle: you must be able to demonstrate that you comply with data protection principles. If an AI agent processes personal data — and most business agents do — you need to show what data it accessed, what it did with that data, and on what basis.

    Article 30 requires records of processing activities. An agent that processes client records, employee data, or customer information is conducting processing activity. If you cannot produce a log of that activity, you do not have the records the regulation requires.

    For financial services firms, the FCA’s operational resilience framework adds another layer. Important business services must withstand disruption and recover. If your AI agents are part of an important business service — processing transactions, managing client communications, monitoring risk — you need to understand how they behave, what they depend on, and what happens when they fail. Audit trails are the evidence base for your resilience assessment.

    How to Implement Audit Trails in Agent Workflows

    The good news is that the tooling exists. You do not need to build this from scratch.

    Structured logging at every node. In n8n workflows, each node can be configured to log its input and output. For agentic workflows, you should log at minimum the trigger, each decision point, and the final action. Use a consistent schema — timestamp, node name, input summary, output summary, and execution status — so that logs are searchable and comparable.

    Observability platforms. Tools like Langfuse are designed for exactly this purpose. They capture the full execution trace of an agent: prompt, model response, tool calls, and final output. When connected to your workflow engine, they give you a queryable record of every agent execution without building custom logging infrastructure.

    Immutable storage. Audit logs must be tamper-evident. If the log can be modified after the fact, it is not an audit trail — it is a diary. Store logs in append-only storage with access controls that prevent modification. This can be as simple as writing to a write-once bucket or using a logging service that enforces retention policies.

    Structured output from agents. Design your agents to return structured output, not just free text. A JSON response that includes the action taken, the target system, and the rationale is far more useful for auditing than a paragraph of prose. This also makes it easier to validate agent behaviour programmatically — you can check that the action taken is within the set of permitted actions before it executes.

    Regular review. Audit trails are only useful if someone looks at them. Build a review cadence — weekly for high-risk agents, monthly for lower-risk ones — where you sample executions and check for anomalies.

    The Bottom Line

    The organisations that will get the most value from agentic AI are not the ones with the most sophisticated prompts. They are the ones that can trust their agents to act safely, verify what those agents did, and improve them over time.

    Audit trails are the foundation of that trust. They are how you move from hoping your agents behave to knowing they do. They are how you satisfy regulators, reassure boards, and sleep at night.

    If you are deploying agentic AI in your organisation — or planning to — audit infrastructure is not a phase-two consideration. It is a prerequisite.

    If you are building agentic AI systems and need help establishing the governance, architecture, and audit infrastructure to support them, the AI & Automation Architecture service covers exactly this. For a broader conversation about where your organisation stands, get in touch.

  • Why AI Workflows Need Audit Trails

    Why AI Workflows Need Audit Trails

    The conversation around AI has shifted. It is no longer just about drafting text or summarising meetings. More and more often, these systems are taking actions on live business processes.

    That is where the risk changes shape.

    A clever prompt can produce a good-looking result. It cannot tell you what happened after the fact if the output was wrong.

    The gap

    When a person makes a decision in a process, there is usually some trace of it. An email, a ticket, a sign-off, a log entry. With an AI system, that trace is often thin or missing.

    If the system updates the wrong record or sends the wrong message, the team is left with a result and very little explanation.

    What breaks without logs

    • You cannot reconstruct the sequence of events.
    • You cannot show who approved what.
    • You cannot improve the workflow with confidence.

    That is not just a debugging problem. It is an accountability problem.

    What a useful audit trail looks like

    At minimum, every execution should capture:

    • the input it received
    • the steps it took
    • the action it actually executed
    • the output it produced
    • the timestamp and identity of the run

    That is enough to answer the questions that matter later.

    The practical bit

    The tooling is already there. Structured logs, append-only storage, and reviewable traces are all enough to get started. The main thing is to design for visibility before the workflow is under pressure.

    If the system is allowed to act, it should also be required to explain itself.

  • 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.

  • 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.

  • M365 Copilot GA: Auditing in the AI Era

    t

    When Microsoft 365 Copilot arrived, the immediate question from clients was not “Can it help?” It was “Is it safe to turn on?”

    My answer was simple: not without a proper permissions review.

    AI does not remove tenant risk. It makes existing risk easier to surface.

    What I kept finding

    Across multiple audits, the same issues kept coming back:

    • over-permissive app consents
    • mailbox forwarding rules that nobody had reviewed in months
    • Intune drift that had crept in quietly

    None of that was exotic. It was just the usual gap between default settings and an actual security posture.

    Why the audit mattered

    The useful part of the process was not the reporting template. It was the discipline.

    I needed a way to check the tenant, explain the findings clearly, and keep the evidence somewhere traceable. That made the audit easier to repeat and a lot harder to hand-wave away.

    The lesson

    If Copilot is going to sit on top of the tenant, the tenant needs to be in decent shape first.

    That means permissions, logging, and a clear view of who can do what. Otherwise the tool just gives people faster access to a system they do not actually understand.

Powered by