DEV Community: Daniel Glover

Building a Cybersecurity Culture That Actually Sticks

Daniel Glover — Thu, 16 Apr 2026 09:47:09 +0000

Every IT leader I have worked with has the same complaint: "We run the training, people pass the quiz, and then click the phishing link the following week."

Building a cybersecurity culture is not about compliance checkboxes or annual e-learning modules. It is about fundamentally shifting how your organisation thinks about risk. The difference between organisations that suffer catastrophic breaches and those that catch threats early almost always comes down to culture, not technology.

This guide shares practical, battle-tested strategies for building a cybersecurity culture that changes behaviour, not just awareness scores.

Why Most Security Awareness Programmes Fail

Traditional security awareness training follows a predictable pattern. Once a year, employees sit through a presentation or click through an online module. They learn about password hygiene, phishing red flags, and data classification. They pass a quiz. Then nothing changes.

The problem is not the content. It is the approach. Annual training treats cybersecurity as an event rather than a habit. Behavioural science tells us that one-off interventions rarely produce lasting change. You would not expect a single gym session to make someone fit, yet we expect a single training session to make someone security-conscious.

Research from the SANS Institute consistently shows that organisations with mature security cultures experience 70% fewer security incidents than those relying on compliance-driven training alone. The difference is not budget or tools. It is sustained, embedded, culturally reinforced behaviour.

The Three Failure Modes

From my experience leading IT teams, security awareness programmes typically fail in one of three ways:

The compliance trap - Training exists solely to satisfy audit requirements. Nobody measures whether behaviour actually changes.
The fear approach - Security teams use scare tactics and punishment. Employees learn to hide mistakes instead of reporting them.
The technology fallacy - Leadership assumes tools will compensate for human error. They invest in email filtering but neglect the human layer.

Each of these creates a false sense of security. The organisation believes it has addressed the human element when, in reality, it has simply documented that it tried.

What a Strong Cybersecurity Culture Looks Like

A genuine cybersecurity culture has observable characteristics. You can walk into an organisation and sense it within days.

People report incidents without fear. In a healthy security culture, employees flag suspicious emails, admit to clicking dodgy links, and ask questions about unfamiliar processes. There is no shame in making a mistake. The shame is in hiding one.

Security is part of business decisions. When launching a new product or onboarding a new vendor, security considerations are raised naturally, not bolted on as an afterthought. Project managers ask about data flows. Marketing teams question third-party tracking scripts.

Language matters. Security teams talk about risk in business terms, not technical jargon. They say "this could cost us three days of revenue" rather than "the CVE has a CVSS score of 9.1." Communication bridges the gap between technical reality and business impact.

Leaders model the behaviour. When the CEO uses multi-factor authentication, when directors challenge suspicious requests, when the board asks informed questions about cyber risk, it signals that security matters at every level.

A Practical Framework for Culture Change

Building cybersecurity culture is a long game. You will not transform an organisation in a quarter. But you can make measurable progress with a structured approach. Here is the framework I have used across multiple organisations.

1. Measure Your Starting Point

Before changing anything, understand where you are. Run an anonymous survey measuring:

How comfortable employees feel reporting security incidents
Whether they can identify common threats (phishing, social engineering, suspicious USB devices)
Their perception of the security team (helpful partner or bureaucratic blocker?)
How often they encounter security guidance in their daily work

This baseline gives you something concrete to improve against. Without it, you are guessing.

2. Make Reporting Safe and Simple

The single most impactful change you can make is removing barriers to incident reporting. If someone clicks a phishing link and is afraid to tell anyone, you have lost your most valuable detection mechanism: the human sensor.

Implement a one-click reporting button in your email client. Create a dedicated Slack or Teams channel for security questions. And critically, publicly thank people who report incidents. "Sarah in finance spotted a sophisticated phishing attempt this morning and reported it within minutes. That is exactly what we need" goes further than any training module.

I have seen organisations reduce their average incident detection time by over 60% simply by making reporting psychologically safe.

3. Embed Security Into Daily Workflows

Security awareness should not be a separate activity. It should be woven into existing processes:

Onboarding: New starters get a 30-minute security orientation on day one, covering real examples of attacks that targeted the organisation (anonymised if needed).
Team meetings: A two-minute "security moment" at the start of monthly team meetings. Share a recent phishing attempt, a news story about a breach, or a quick tip.
Project kickoffs: Include a security checklist in project templates. Not a 50-page risk assessment, but five practical questions about data handling and access control.
Performance reviews: Include security awareness as a competency. Not as a stick, but as recognition that security-conscious behaviour is valued.

The goal is frequency and relevance. Short, regular touchpoints beat long, infrequent sessions every time.

4. Use Phishing Simulations Intelligently

Phishing simulations are valuable when done correctly and counterproductive when done badly.

Do: Run monthly simulations with increasing sophistication. Track improvement over time. Use failures as coaching opportunities, not punishment. Share aggregate results transparently.

Do not: Name and shame individuals who fail. Use simulations that are deliberately misleading to the point of being unfair. Run simulations without follow-up education for those who click.

The best approach I have seen combines simulation with immediate, constructive feedback. When someone clicks a simulated phish, they see a brief, friendly explanation of what they missed and one specific thing to look for next time. No alarm bells. No disciplinary notes. Just learning.

Over 12 months of well-run simulations, most organisations see click rates drop from 25-30% to under 5%.

5. Empower Security Champions

You cannot scale culture change through the security team alone. You need allies embedded across the business.

Identify volunteers from each department who are interested in security. Give them additional training, access to threat intelligence briefings, and a direct line to the security team. These security champions become the local experts who answer questions, spot risks, and reinforce good practice within their teams.

The champion model works because people are more likely to listen to a trusted colleague than to someone from a central IT function they rarely interact with. A security champion in the sales team who says "watch out for this invoice scam doing the rounds" carries more weight than an email from IT.

6. Communicate Like a Human

The fastest way to kill a cybersecurity culture is to communicate like a compliance department. Nobody reads 2,000-word security policies. Nobody remembers 47 rules for password creation.

Instead:

Tell stories. "Last month, a company similar to ours lost two million pounds because someone approved a payment based on a spoofed email. Here is how to spot one."
Keep it short. Weekly security tips should be three sentences maximum.
Use humour. A funny poster in the kitchen about password reuse will do more than a formal policy document.
Be visual. Infographics, short videos, and memes are more shareable and memorable than text-heavy guidance.

The UK's National Cyber Security Centre produces excellent, plain-English guidance that serves as a model for how to communicate security concepts without drowning people in jargon.

Measuring Cultural Change

You cannot manage what you do not measure. Track these indicators quarterly:

Phishing simulation click rates - Your most direct behavioural measure
Incident reporting volume - An increase is good (it means people are reporting more, not that more incidents are happening)
Time to report - How quickly do employees flag suspicious activity?
Survey scores - Repeat your baseline survey annually to track perception changes
Shadow IT discovery rate - Are employees proactively disclosing unapproved tools?

Present these metrics to the board alongside traditional security metrics. Executives respond well to trend lines showing cultural improvement. It demonstrates that the organisation is building resilience, not just buying tools.

For a deeper look at how the CISO role is evolving to encompass this kind of strategic work, the shift from technical guardian to business partner is directly relevant here.

The Role of Leadership

Culture flows downhill. If the executive team treats security as someone else's problem, the rest of the organisation will follow suit.

IT leaders must secure visible executive sponsorship for cybersecurity culture initiatives. This means:

Board-level reporting on security culture metrics alongside financial and operational metrics
Executive participation in security exercises and tabletop scenarios
Budget allocation that reflects the priority placed on human factors, not just technology
Consistent messaging that security is everyone's responsibility, backed by action

When I have seen cybersecurity culture programmes fail, the root cause is almost always lack of sustained leadership commitment. The initial enthusiasm fades, the budget gets redirected, and the programme quietly dies.

The same principle applies to Zero Trust Architecture, where success depends on organisational buy-in rather than technology procurement.

If you need help designing a security awareness programme that goes beyond compliance checkboxes, my IT compliance services cover programme design, policy development, and audit preparation alongside the technical controls.

Quick Wins to Start This Week

If you are reading this and thinking "where do I even begin?", here are five actions you can take immediately:

Set up a one-click phishing report button in your email client. Most platforms (Outlook, Gmail) support this natively or through add-ons.
Run a baseline phishing simulation to understand your current click rate. Services like KnowBe4, Proofpoint, or even open-source tools like GoPhish make this straightforward.
Create a security tips channel in your messaging platform. Post one tip per week. Keep it casual.
Add a security moment to your next team meeting. Share a recent real-world breach story and ask "could this happen to us?"
Thank someone publicly for reporting a security concern. Set the tone that reporting is valued.

None of these require budget approval. None require new technology. They require intent, consistency, and a genuine belief that your people are your strongest defence, not your weakest link.

The Long Game

Building a cybersecurity culture is not a project with a start and end date. It is an ongoing commitment that evolves as threats change, as your organisation grows, and as new technologies create new risks.

The organisations that get this right treat cybersecurity culture as a core business capability, not an IT initiative. They invest in it continuously, measure it rigorously, and celebrate it visibly.

Your security tools will stop a significant proportion of threats. But the threats that get through, the sophisticated social engineering attacks, the carefully crafted phishing campaigns, the insider risks, these are the ones where culture is your last and best line of defence.

Start small. Be consistent. Measure everything. And remember: the goal is not perfect security. The goal is an organisation where everyone understands their role in protecting it.

That is a cybersecurity culture that actually works.

Get in touch to discuss how to build a security culture that produces real behaviour change in your organisation.

Slopsquatting: The AI Supply Chain Attack Vector You Are Not Monitoring

Daniel Glover — Thu, 16 Apr 2026 09:46:04 +0000

Slopsquatting is a new class of software supply chain attack that exploits a fundamental flaw in AI coding assistants: their tendency to hallucinate package names that do not exist. When an AI model recommends installing a package that has never been published, attackers can register that name on public repositories like PyPI or npm and inject malicious code into any developer who follows the AI's suggestion.

The term was coined by Seth Larson, Python Software Foundation developer in residence, as a play on typosquatting - where attackers register misspelled versions of popular packages. But slopsquatting is potentially worse. While typosquatting relies on human error, slopsquatting exploits trust in AI tools that 92% of US developers now use daily.

The Scale of AI Package Hallucinations

Research from Virginia Tech, the University of Oklahoma, and the University of Texas reveals the alarming scope of this problem. The team tested 16 code-generation LLMs by prompting them to generate 576,000 Python and JavaScript code samples. Their findings, published in March 2025, should concern every organisation relying on AI-assisted development.

headers={["Metric", "Finding", "Implication"]}
rows={[
["Hallucination rate", "19.7% (roughly 1 in 5)", "One in five package recommendations points to nothing"],
["Unique fake packages", "205,474 names", "Massive attack surface for adversaries to exploit"],
["Reproducibility", "43% appear every time", "Attackers can predict which fake names will be suggested"],
["Repeat appearances", "58% appear more than once", "Majority of hallucinations are not random noise"]
]}
/>

The reproducibility finding is particularly concerning. Attackers do not need to scrape massive prompt logs or brute force potential names. They can simply observe LLM behaviour, identify commonly hallucinated names, and register them on public package registries.

Not All Models Are Equal

The research found significant variation between AI models. Open-source LLMs like CodeLlama, DeepSeek, WizardCoder, and Mistral showed the highest hallucination rates. Commercial tools performed better but still posed risk - ChatGPT-4 hallucinated package names in approximately 5% of cases.

For organisations processing thousands of AI-generated code suggestions daily, even a 5% error rate translates into substantial exposure.

How Slopsquatting Attacks Work

The attack chain is straightforward, which makes it dangerous:

Step 1: Discovery - An attacker prompts popular AI coding assistants with common development tasks: "Create a Python script to process CSV files", "Build a Node.js authentication module", or similar requests. They record every package name suggested.

Step 2: Verification - The attacker checks which suggested packages actually exist. Research shows roughly 20% will not.

Step 3: Registration - For non-existent packages that appear reproducibly (43% of hallucinations), the attacker registers matching names on PyPI, npm, or other public registries.

Step 4: Payload - The attacker publishes functional-looking code that includes malicious payloads - credential harvesting, backdoors, cryptocurrency miners, or data exfiltration routines.

Step 5: Exploitation - When another developer prompts the same AI model with a similar request, receives the same hallucinated package name, and runs pip install or npm install, the malicious package enters their development environment.

According to Trend Micro's analysis, the hallucinated package names are "semantically convincing" - they look like real packages with plausible naming conventions. Developers cannot easily spot the deception by sight alone.

Why Slopsquatting Is Worse Than Typosquatting

Traditional typosquatting attacks rely on developers making typing mistakes: reqeusts instead of requests, or lodahs instead of lodash. Security teams have developed defences against this - spell checkers, package manager warnings, and developer training.

Slopsquatting sidesteps all of these protections:

No typing errors to catch - The AI suggests a package name that looks entirely legitimate. There is no misspelling to flag.

Trust in AI tools - Developers increasingly accept AI suggestions without verification, a practice amplified by vibe coding culture where developers "give in to the vibes" and trust AI outputs.

Reproducibility aids attackers - Because 43% of hallucinated packages appear consistently, attackers can target specific AI models and specific prompts with high confidence.

Scale of AI adoption - With 41% of global code now AI-generated, the attack surface is massive and growing.

According to BleepingComputer's reporting, slopsquatting incidents will continue as AI coding adoption accelerates. The combination of widespread AI tool usage and inherent model limitations creates a persistent vulnerability.

Real-World Risk Scenarios

Consider how slopsquatting could affect your organisation:

Scenario 1: Developer Workstation Compromise - A developer uses an AI assistant to generate a data processing script. The AI suggests a hallucinated package that an attacker has registered. Installation grants the attacker access to the developer's machine, source code repositories, and potentially credentials for production systems.

Scenario 2: CI/CD Pipeline Infiltration - A build process pulls dependencies based on AI-generated requirements files. A slopsquatted package enters the pipeline, gaining access to deployment credentials, secrets, and the ability to inject malicious code into production builds.

Scenario 3: Compliance Violation - Regulated industries require software bill of materials (SBOM) documentation and supply chain verification. AI-hallucinated packages lack provenance, auditable histories, or security reviews. Their presence in production code creates compliance gaps.

Scenario 4: Intellectual Property Theft - A malicious slopsquatted package exfiltrates source code, configuration files, or API keys to attacker-controlled infrastructure. By the time the breach is discovered, sensitive data has already been compromised.

Mitigation Strategies for CISOs and IT Leaders

Defending against slopsquatting requires a multi-layered approach that spans developer practices, tooling, and governance.

1. Mandatory Dependency Verification

Establish a policy requiring developers to verify every AI-suggested package before installation:

Check the package exists on the official registry
Review the package's publish history and maintainer details
Examine download statistics - legitimate popular packages have substantial usage
Look for security audits or vulnerability disclosures

This adds friction to the development process, but the alternative is accepting unvetted code from potentially malicious sources.

2. Implement Dependency Scanning Tools

Deploy software composition analysis (SCA) tools that can identify suspicious packages. Solutions from Snyk, Socket, and similar vendors now include specific detection capabilities for slopsquatted packages, looking for:

Newly registered packages with names similar to common hallucination patterns
Packages with minimal download history but wide AI-suggested distribution
Code that exhibits suspicious behaviour (network calls, file system access, credential reading)

3. Use Lockfiles and Hash Verification

Package lockfiles (package-lock.json, Pipfile.lock, poetry.lock) pin dependencies to specific versions with cryptographic hashes. This prevents the silent substitution of legitimate packages with malicious ones and makes supply chain tampering detectable.

Require all projects to maintain lockfiles and fail builds if lockfile verification fails.

4. Configure AI Tool Settings

Research shows that LLM "temperature" settings affect hallucination rates. Higher temperature (more randomness) increases hallucinations. Where configurable, set AI coding assistants to lower temperature settings to reduce the frequency of fabricated package suggestions.

This is not a complete solution - even low-temperature models hallucinate - but it reduces exposure.

5. Establish AI Code Governance

Integrate slopsquatting defence into your broader AI governance controls. Define policies for:

Which AI coding assistants are approved for use
Required verification steps before accepting AI-generated dependency lists
Audit trails for AI-suggested code entering production systems
Incident response procedures if a slopsquatted package is detected

6. Sandbox AI-Generated Code

Never run AI-generated code directly in production environments or on developer workstations with access to sensitive resources. Test all AI suggestions in isolated sandboxes where malicious code cannot reach valuable targets.

Container-based development environments and virtual machines provide isolation layers that limit blast radius if a slopsquatted package is accidentally installed.

7. Educate Development Teams

Developers need to understand that AI coding assistants are not security tools. Georgetown's CSET research highlights that AI models do not understand your application's risk model, internal standards, or threat landscape. Every AI suggestion - especially package recommendations - requires human verification.

Training should cover:

What slopsquatting is and how it works
How to verify package legitimacy before installation
Red flags that indicate suspicious packages
Reporting procedures for potential supply chain attacks

The Bigger Picture: AI Code Security

Slopsquatting is one manifestation of a broader challenge. AI coding assistants introduce multiple security risks beyond hallucinated packages - including insecure code patterns, missing security controls, and logic errors that can compromise applications.

The research is clear: over 40% of AI-generated code contains security vulnerabilities, and this rate has not improved as models have scaled. Security must be a deliberate, human-driven layer on top of AI productivity gains - not an afterthought.

For CISOs and IT leaders, the imperative is clear. AI coding tools are here to stay, and their adoption will only accelerate. The organisations that thrive will be those that harness AI's productivity benefits while implementing robust controls to catch the security gaps that AI cannot see.

Slopsquatting is a solvable problem. But solving it requires acknowledging that AI assistants, however helpful, can be vectors for supply chain attacks - and building defences accordingly.

Want to discuss AI security strategy for your organisation? Connect with me on LinkedIn or explore more on vibe coding security risks.

AI Washing and Layoffs: What Is Real and What Is Hype

Daniel Glover — Thu, 16 Apr 2026 09:45:50 +0000

The headlines write themselves. Amazon cuts thousands. Pinterest restructures. Across the board, the message is the same: AI is here, and humans are no longer needed.

Except that is not quite what is happening.

A Forrester report published in January 2026 made a bold claim that should give every IT leader pause. Many companies announcing AI-related layoffs, the analysts found, do not actually have mature AI applications ready to fill those roles. What they have is a convenient narrative.

Welcome to the era of AI-washing.

What is AI-washing?

The term borrows from "greenwashing" - where companies exaggerate their environmental credentials. AI-washing works the same way, but in reverse. Instead of overstating what AI can do for the planet, companies are overstating what AI can do for their workforce. They are attributing financially motivated cuts to future AI implementation that may never materialise.

As Molly Kinder, a senior research fellow at the Brookings Institute, put it: saying layoffs are caused by AI is a "very investor-friendly message." The alternative might mean admitting the business is struggling, that pandemic-era over-hiring created bloated teams, or that revenue targets were missed.

AI makes for a better press release than "we hired too many people in 2021."

The numbers tell a different story

More than 50,000 layoffs in 2025 were publicly attributed to AI. That is a staggering figure. But dig into the specifics and the picture gets murkier.

Many of the companies making these cuts had not deployed AI tools at scale. Some had pilot programmes. Others had vague roadmaps. Very few had production-ready systems capable of replacing the roles they were eliminating.

This matters because it shapes public perception. Every AI-attributed layoff reinforces the narrative that automation is an unstoppable force already displacing workers en masse. That narrative creates anxiety, influences policy, and - critically for IT leaders - distorts strategic planning.

If your board reads that Amazon cut roles "because of AI" and then asks why your department has not done the same, you need to be armed with the reality behind the headlines.

But genuine disruption is real

Here is where it gets complicated. While AI-washing is absolutely happening, genuine AI disruption is also accelerating.

In the first week of February 2026, Anthropic launched a suite of AI tools targeting legal, sales, and customer support workflows. The market reaction was immediate and brutal. Shares in Pearson fell 8%. Relx plunged 14%. Thomson Reuters lost 18% in a single session. The FTSE 100, which had hit a record high that morning, was dragged into the red.

These are not speculative startups. These are established companies with decades of market dominance, and investors wiped billions off their valuations overnight because an AI company released a product.

Clifford Chance, one of the world's largest law firms, had already cut 10% of its London business services staff in November 2025, citing increased AI use as a genuine factor. According to Morgan Stanley, the UK is losing more jobs than it is creating as companies adopt AI tools - and is being hit harder than rival economies including the US, Japan, Germany, and Australia.

So the truth is uncomfortable but important: some companies are using AI as cover for unrelated cuts, while others are experiencing real displacement. The challenge for IT leaders is telling the difference.

How to spot AI-washing in your organisation

As someone who manages IT strategy across a complex business, I have learned to ask pointed questions when "AI" gets thrown around in boardroom conversations. Here is what I look for:

1. Is there a production-ready system?

If someone claims AI will replace a function, ask to see the tool. Not a demo. Not a proof of concept. A production system with documented accuracy, error rates, and a support model. If it does not exist yet, the layoff is not AI-driven. It is cost-driven with AI branding.

2. What is the transition plan?

Genuine AI-driven restructuring comes with a transition plan. Retraining programmes. Phased rollouts. Fallback procedures. If the plan is "cut now, automate later," that is a red flag.

3. Who benefits from the narrative?

Follow the incentives. If the company's share price responds positively to "AI transformation" messaging, there is a financial incentive to frame every cost reduction as AI-related - whether it is or not.

4. Are the affected roles actually automatable?

This is the most basic question and it is surprising how rarely it gets asked. Some roles being cut involve complex judgment, relationship management, or creative problem-solving that current AI simply cannot replicate. If those are the roles being eliminated "because of AI," something else is going on.

What IT leaders should actually be doing

Rather than getting swept up in the hype cycle - or dismissing AI entirely because of the washing problem - there is a pragmatic middle ground.

Audit your AI readiness honestly. Map your current processes against what AI can genuinely automate today, not in some theoretical future. Be specific. Contract review? Possibly, depending on complexity. Strategic vendor negotiation? Not even close. My series on business AI enablement provides a structured framework for this assessment.

Build a skills transition framework. The roles that AI genuinely threatens tend to be repetitive, data-heavy, and rules-based. The people in those roles often have institutional knowledge that is incredibly valuable. A good IT leader finds ways to redeploy that knowledge rather than simply cutting headcount. Understanding the shadow AI governance crisis is a key part of this - you cannot manage AI's workforce impact if you do not even know where AI is being used.

Push back on performative AI strategy. If your C-suite wants to announce an "AI transformation" without the underlying capability to deliver it, that is your moment to provide honest counsel. The short-term PR benefit is not worth the long-term credibility damage when the promised efficiencies fail to materialise.

Watch the tooling market closely. The Anthropic announcement moved markets because it represented a genuine capability leap. These moments will keep coming. Your job is to evaluate each one on its merits - not to dismiss them all as hype, and not to panic-adopt because a competitor made a press release.

The honest conversation we need

Twenty-seven percent of UK workers are worried their jobs will disappear within five years because of AI. That anxiety is understandable, but it is being amplified by companies that are muddying the waters between genuine automation and convenient excuses.

As IT leaders, we have a responsibility to cut through the noise. That means being honest about what AI can and cannot do today. It means challenging AI-washing when we see it, even when the narrative is politically convenient. And it means preparing our organisations for real disruption - not the imagined kind that makes for good investor calls. If you are looking for a practical starting point, AI training and closing the skills gap covers how to equip your workforce for the genuine changes that are coming.

The companies that will thrive are not the ones making the boldest AI claims. They are the ones doing the hard work of genuine implementation, responsible workforce transition, and honest strategic planning.

AI is transforming business. But the transformation is messier, slower, and more nuanced than the headlines suggest. And if we are going to navigate it well, we need to start by telling the truth about what is actually happening.

Daniel Glover is Head of IT Services at a major UK e-commerce business, managing a team across infrastructure, security, and digital transformation. He writes about technology leadership, AI strategy, and the realities of enterprise IT.

AI Governance Controls: A Framework for Enterprise AI Deployment

Daniel Glover — Thu, 16 Apr 2026 09:19:40 +0000

This is Part 6 of a 7-part series on Business AI Enablement for IT Leaders. The series covers why enablement matters, shadow AI risks, building an enablement framework, employee training, tool selection, and concludes with a 90-day implementation roadmap.

Governance has an image problem. To many employees, governance means bureaucracy, delays, and the word "no" repeated in various forms. This reputation is often deserved.

But AI governance done well looks different. It provides clarity that enables faster decision-making. It creates guardrails that allow confident action. It removes uncertainty that otherwise paralyses adoption.

The 68% of organisations without formal AI controls are not more innovative than those with them. They are simply operating blind, accumulating risks they cannot see, and missing opportunities to learn from experience.

This article provides a governance framework that enables rather than restricts.

The Governance Paradox

Governance and enablement seem opposed. More rules mean less freedom. Tighter controls mean slower action. This framing is wrong.

Consider an analogy. Traffic lights slow individual vehicles at intersections. But traffic lights enable higher overall throughput because they eliminate the chaos of uncoordinated intersections. The constraint creates capability.

AI governance works the same way. Clear rules about data handling eliminate the uncertainty that makes employees hesitant. Defined approval paths are faster than ad hoc escalation. Established verification processes catch errors before they cause damage.

Governance that fails:

Prohibits without providing alternatives
Requires approval for everything regardless of risk
Changes frequently without clear communication
Punishes compliance failures without addressing root causes
Creates burdens disproportionate to risks addressed

Governance that works:

Enables safe action by clarifying boundaries
Matches controls to actual risk levels
Remains stable with predictable updates
Treats failures as learning opportunities
Creates minimal overhead for low-risk activities

The goal is not minimal governance. The goal is appropriate governance - controls proportionate to risk that enable productive work.

The AI Policy Framework

Every organisation needs a foundational AI policy. This document establishes principles, defines responsibilities, and points to detailed guidance for specific areas.

Policy Structure

An effective AI policy includes:

Purpose and scope. Why the policy exists and who it covers. This should emphasise enablement alongside risk management.

Principles. The values guiding AI use in the organisation:

Transparency about when AI is used
Human responsibility for AI outputs
Privacy and data protection priority
Continuous learning and improvement
Safety and quality standards

Roles and responsibilities. Who is accountable for what:

Executive sponsor for AI enablement
IT responsibility for approved tools and security
Business unit responsibility for appropriate use
Individual employee responsibility for policy adherence
Champions and their support role

Approved tools. Reference to the authorised tool catalogue with access procedures.

Prohibited uses. Clear boundaries on what is not permitted:

Using non-approved tools for business purposes
Processing prohibited data types with AI
Automated decisions without human review for specified categories
Representing AI output as human work where disclosure is required

Compliance requirements. How the policy relates to regulations:

GDPR and data protection obligations
Industry-specific requirements
Emerging AI regulations

Enforcement and exceptions. How violations are addressed and how exceptions are requested:

Progressive response to violations
No-blame approach to good-faith errors
Exception request process with criteria
Appeals mechanism

Review and updates. How the policy stays current:

Annual review minimum
Trigger events for interim updates
Communication of changes

Policy Principles

Several principles make AI policies effective:

Clarity over comprehensiveness. A shorter policy that employees actually read and understand beats a comprehensive policy they ignore. Link to detailed guidance rather than including everything.

Principles over rules. Rules cannot cover every situation. Principles help employees make good decisions when specific guidance is absent.

Enable by default. The policy should help employees do things, not primarily stop them. Prohibitions should be few and justified.

Proportionate enforcement. Minor infractions should not receive the same treatment as serious violations. Good faith matters.

Data Classification for AI Inputs

Data classification determines what information can be used with which AI tools. Without clear classification, employees either avoid AI entirely (missing value) or use it recklessly (creating risk).

Classification Tiers

headers={["Tier", "Description", "AI Use Guidance"]}
rows={[
["Public", "Information intended for public distribution", "Any approved tool"],
["Internal", "Business information not intended for public disclosure", "Enterprise-grade tools with data protection agreements"],
["Confidential", "Sensitive information requiring protection", "Restricted tools with enhanced controls; may require approval"],
["Prohibited", "Information that must not be processed by external AI", "No external AI processing permitted"]
]}
/>

Public data includes published content, marketing materials, and information already in the public domain. This data can be used with any approved AI tool without restriction.

Internal data includes business information, internal communications, and operational data. Enterprise-grade tools with appropriate data protection agreements can process this data.

Confidential data requires heightened protection. This may include customer personal information, strategic plans, financial projections, and proprietary methods. Use with AI requires either restricted tools with enhanced controls or case-by-case approval.

Prohibited data must not be processed by external AI under any circumstances. This category typically includes:

Highly sensitive personal data (health records, financial details)
Trade secrets and critical intellectual property
Security credentials and access keys
Information subject to specific regulatory restrictions

Classification in Practice

Employees need practical guidance to classify data quickly:

Provide examples for each classification tier relevant to common work
Create decision trees that help with ambiguous cases
Establish escalation paths when classification is uncertain
Train on classification as part of AI enablement programmes

The goal is confident, rapid classification that does not slow work but does prevent inappropriate exposure.

Output Verification and Quality Controls

AI outputs are not automatically trustworthy. Verification requirements should match the risk of using unverified output.

Verification Levels

Level 1: Spot Check (Low Risk)

For internal productivity outputs where errors have limited consequences:

Review output for obvious errors
Confirm general alignment with intent
No formal documentation required

Examples: Internal email drafts, meeting notes, personal research summaries.

Level 2: Quality Review (Medium Risk)

For outputs that influence decisions or reach internal audiences:

Verify factual claims
Check logical consistency
Confirm alignment with organisational standards
Brief documentation of review

Examples: Internal reports, analysis summaries, policy drafts.

Level 3: Expert Review (High Risk)

For outputs affecting customers or significant decisions:

Subject matter expert verification
Comprehensive fact-checking
Consistency review against standards
Documented sign-off

Examples: Customer communications, published content, code deployment.

Level 4: Formal Validation (Critical Risk)

For outputs with significant business or regulatory implications:

Multi-person review
Compliance verification
Full documentation and audit trail
Leadership sign-off

Examples: Financial statements, legal documents, regulatory submissions.

Common Verification Failures

Training should address frequent verification mistakes:

Trusting confident tone. AI presents incorrect information as confidently as correct information. Confidence is not an accuracy signal.
Skipping source verification. AI may cite sources that do not exist or do not support claimed conclusions. Sources require independent verification.
Assuming consistency. AI may contradict itself within the same output. Long outputs need internal consistency review.
Overlooking omissions. AI may not mention important considerations it does not know about. Outputs are not comprehensive without explicit prompting.

Monitoring and Compliance Enforcement

Governance without monitoring is just documentation. Effective monitoring provides visibility without surveillance overreach.

What to Monitor

Usage patterns. Aggregate analytics on AI tool adoption:

Number of active users
Frequency of use
Use case patterns
Tool-specific adoption

This data informs capacity planning, training priorities, and tool evaluation. It does not require content inspection.

Policy indicators. Signals that suggest policy issues:

Access attempts to non-approved tools
Unusual data volumes
Off-hours usage patterns
Error rates suggesting untrained users

These indicators prompt investigation without requiring comprehensive surveillance.

Compliance events. Specific incidents requiring attention:

Reported violations
Security incidents involving AI
Customer complaints related to AI use
Audit findings

Monitoring Boundaries

Monitoring should respect employee privacy and trust:

Be transparent. Employees should know what is monitored and why.
Focus on patterns, not content. Usage statistics are less intrusive than content inspection.
Investigate with cause. Deep inspection should be triggered by indicators, not applied universally.
Protect whistleblowers. Employees reporting concerns should not face retaliation.

Heavy-handed monitoring damages the trust that effective AI enablement requires. The goal is sufficient visibility for governance, not comprehensive surveillance.

Enforcement Approach

Policy violations need appropriate response. The approach should be:

Proportionate. Minor first-time violations do not warrant the same response as repeated serious violations.

Educational. Many violations result from misunderstanding, not malice. Response should include training.

Consistent. Similar violations should receive similar responses regardless of who commits them.

Documented. Actions taken should be recorded for consistency and appeals.

Progressive. Responses should escalate for repeated violations:

Informal guidance and training
Formal warning with documentation
Restricted access pending retraining
Disciplinary action as per HR policy

No-blame for good faith. Employees who make genuine mistakes while trying to work appropriately should be supported, not punished.

Incident Response for AI Failures

AI-related incidents will occur. Preparation enables effective response.

Incident Categories

Data exposure. Sensitive information shared with inappropriate AI tools.

Immediate assessment of data involved
Vendor notification if relevant
Regulatory reporting if required
Affected party notification if necessary

Quality failures. AI outputs that caused business problems.

Document the failure and impact
Identify root cause
Implement verification improvements
Update training if needed

Security incidents. Compromises involving AI tools or data.

Standard security incident response applies
Additional focus on data scope and AI-specific factors
Vendor involvement as appropriate

Compliance violations. Regulatory requirements breached through AI use.

Legal and compliance engagement
Regulatory notification as required
Remediation planning
Control enhancements

Incident Response Process

A structured process ensures consistent handling:

Detection and reporting. Clear channels for identifying and escalating issues.
Initial assessment. Rapid evaluation of scope and severity.
Containment. Immediate actions to prevent further impact.
Investigation. Understanding what happened and why.
Remediation. Addressing immediate damage and preventing recurrence.
Review. Learning lessons and improving controls.
Documentation. Recording the incident for compliance and learning.

As I explored in the incident response discussion in the CISO series, effective incident response is a core organisational capability.

Quick Reference: AI Governance Policy Template

Use this template as a starting point for your organisation's AI policy:

Purpose

[ ] Statement of policy intent emphasising enablement and safety
[ ] Scope covering all employees and AI use

Principles

[ ] Transparency in AI use
[ ] Human accountability for outputs
[ ] Data protection priority
[ ] Continuous improvement commitment

Approved Tools

[ ] Reference to tool catalogue
[ ] Access request procedures
[ ] Criteria for new tool requests

Data Classification

[ ] Four-tier classification with descriptions
[ ] Examples for each tier
[ ] AI use guidance by tier
[ ] Escalation for uncertain classification

Acceptable Use

[ ] Permitted use cases
[ ] Prohibited uses with rationale
[ ] Output verification requirements
[ ] Attribution and disclosure requirements

Roles and Responsibilities

[ ] Executive sponsor
[ ] IT responsibilities
[ ] Business unit responsibilities
[ ] Individual responsibilities
[ ] Champion role

Compliance

[ ] Regulatory alignment statements
[ ] Audit and reporting requirements
[ ] Training requirements

Enforcement

[ ] Violation response framework
[ ] Exception request process
[ ] Appeals mechanism

Governance

[ ] Policy owner
[ ] Review schedule
[ ] Change communication process

Governance Evolution

AI governance is not static. As AI capabilities evolve, governance must adapt.

Near-Term Developments

Regulatory pressure. The EU AI Act and emerging regulations will create new compliance requirements. Governance frameworks need to accommodate these requirements.

Agentic AI. AI systems that take autonomous actions raise governance questions current frameworks do not address. Decision authority, override mechanisms, and accountability need clarification.

Embedded AI. As AI becomes invisible within other tools, governance must account for AI use employees may not recognise as AI.

Governance Maturity

Organisations progress through governance maturity levels:

Level 1: Ad Hoc. No formal governance. Decisions made case by case.

Level 2: Defined. Policies exist but are inconsistently applied.

Level 3: Managed. Policies are consistently enforced with monitoring and improvement.

Level 4: Optimised. Governance continuously improves based on experience and external developments.

Most organisations are at Level 1 or 2. The framework in this article targets Level 3, with processes for progressing to Level 4.

Building Governance Capability

Effective governance requires investment:

Dedicated ownership. Someone accountable for AI governance as a significant responsibility.
Cross-functional coordination. Regular engagement across IT, legal, compliance, HR, and business units.
Continuous learning. Staying current with regulatory, technology, and industry developments.
Employee engagement. Governance that does not consider employee needs will not be followed.

Governance is a capability, not a document. The documents enable the capability but are not the capability themselves.

Developing Your AI Governance Framework

Building governance that enables rather than restricts requires balancing business needs with risk management. My IT compliance services help organisations develop AI governance frameworks that support productive adoption while maintaining appropriate controls.

Get in touch to discuss how to build AI governance that works.

Previous: Part 5 - Selecting AI Tools for Business Units

Next: Part 7 - AI Enablement: Your 90-Day Roadmap

Dry Run Engineering: The Practice That Reduces Production Incidents

Daniel Glover — Thu, 16 Apr 2026 09:19:26 +0000

There is a post trending on Hacker News today about the --dry-run flag. Henrik Warne writes about adding it to a reporting application early in development and being surprised by how useful it became. I have been nodding along because this matches my experience exactly.

The --dry-run pattern is one of those deceptively simple engineering practices that punches well above its weight. If you have ever run rsync --dry-run before committing to a massive file sync, or used terraform plan before terraform apply, you already know the value.

What dry-run actually means

A dry-run flag tells your script to show what it would do without actually doing it. Print the files that would be deleted. Log the API calls that would be made. Display the database rows that would be updated. Then exit without changing anything.

The key principle: make it safe to run without thinking.

When a colleague asks "what will this script do?", you should be able to run it with --dry-run and show them. No risk. No cleanup needed afterwards.

Where this matters most

Database migrations

Before running a migration that modifies production data, a dry-run should output:

How many rows will be affected
Sample of the changes (first 10 rows, perhaps)
Any constraints that might fail
Estimated execution time

File operations

Scripts that move, rename, or delete files should preview the operations. I once watched a junior engineer accidentally delete a week of customer uploads because a cleanup script had no preview mode. That script has a --dry-run flag now.

API integrations

When your script calls external services - sending emails, posting to Slack, updating CRM records - a dry-run should log what would be sent without actually sending it. This is invaluable for testing integrations without spamming real systems.

Infrastructure changes

Terraform popularised plan before apply. Ansible has --check mode. Kubernetes has --dry-run=client. These tools understood that showing the diff before making changes reduces incidents significantly.

Implementation patterns

The simplest approach is a global flag that gates all side effects:

def delete_old_files(directory, dry_run=False):
    files = find_files_older_than(directory, days=30)

    for file in files:
        if dry_run:
            print(f"Would delete: {file}")
        else:
            os.remove(file)
            print(f"Deleted: {file}")

    print(f"Total: {len(files)} files {'would be' if dry_run else ''} deleted")

For more complex scripts, consider a transaction-style approach where you collect all intended actions, display them, then execute only if not in dry-run mode:

class ActionPlan:
    def __init__(self):
        self.actions = []

    def add(self, description, execute_fn):
        self.actions.append((description, execute_fn))

    def preview(self):
        for desc, _ in self.actions:
            print(f"  - {desc}")

    def execute(self, dry_run=False):
        if dry_run:
            print("Dry run - the following actions would be taken:")
            self.preview()
            return

        for desc, fn in self.actions:
            print(f"Executing: {desc}")
            fn()

The hidden benefit: better logging

Adding dry-run support forces you to think about what your script actually does. You cannot preview an action without first describing it clearly. This naturally improves your logging, error messages, and overall observability.

Scripts with good dry-run output tend to have good production logging too. The same descriptions you write for preview mode become your audit trail.

Common objections

"It adds complexity"

Yes, but minimal complexity. A single boolean flag and some conditional prints. The alternative - running scripts blind and hoping for the best - creates far more complexity when things go wrong.

"Our scripts are simple enough"

Until they are not. Adding dry-run early is trivial. Retrofitting it after an incident is embarrassing and often incomplete.

"We have staging environments"

Staging helps, but it is not the same as previewing against production data. A dry-run against your actual database shows you what will really happen, not what would happen to synthetic test data.

Making it the default

I have started making --dry-run the default for destructive scripts. You have to explicitly pass --execute or --no-dry-run to make changes. This inverts the safety model - accidents require extra effort.

$ ./cleanup-old-data.py
$ ./cleanup-old-data.py --execute

This is particularly valuable for scripts that run via cron or automation. A misconfigured job that runs in dry-run mode by default produces logs instead of damage.

The small investment that pays dividends

Henrik Warne added --dry-run on a whim and found himself using it daily. That matches my experience. Once you have it, you use it constantly - before deployments, while debugging, when demonstrating to stakeholders, during incident response.

The pattern is old. Subversion had it. rsync has had it for decades. But it remains underused in custom scripts and internal tools. Every automation you write that modifies state should have this escape hatch.

Add the flag. Your future self will thank you.

If you are building automation that touches production systems, dry-run is just one layer of defence. Pair it with proper governance controls and a solid engineering practice to keep technical debt from creeping in.

Inspired by Henrik Warne's post which is worth reading in full.

Securing AI Agents: A Practical Guide for IT Leaders

Daniel Glover — Thu, 16 Apr 2026 09:19:00 +0000

Securing AI agents is no longer a theoretical exercise - it is an immediate operational requirement. Following the ClawdBot security concerns I outlined yesterday, I have had dozens of conversations with IT leaders asking the same question: "I understand the risks, but how do I actually secure this thing?"

Fair question. Most security coverage has focused on what can go wrong without explaining what to do about it. This post bridges that gap. I run ClawdBot daily and have spent considerable time hardening my own deployment. Here is what I have learned about securing AI agents in practice.

Why AI Agent Security Differs from Traditional Applications

Before diving into specific controls, it is worth understanding why securing AI agents requires a different mental model than traditional application security.

Conventional applications have predictable behaviour. A web server handles HTTP requests. A database stores and retrieves data. Their attack surfaces are well understood and their behaviours are deterministic.

AI agents are fundamentally different. They make decisions autonomously based on natural language input. They interact with multiple external services. They maintain persistent state that influences future behaviour. Most importantly, their actions are not fully predictable - the same input might produce different outputs depending on context, memory, and the underlying model's reasoning.

This non-determinism creates security challenges that traditional controls were not designed to address. You cannot simply firewall an AI agent because it legitimately needs broad access to function. You cannot audit every action because the agent generates thousands of micro-decisions. You cannot prevent all malicious input because the agent must process untrusted content to be useful.

Securing AI agents requires defence in depth - multiple overlapping controls that together reduce risk to acceptable levels.

The Five Layers of AI Agent Defence

I have found it helpful to think about AI agent security across five distinct layers. Each layer addresses different threat categories, and weakness in one layer should be compensated by strength in others.

Layer 1: Network Isolation

The most fundamental control is limiting what your AI agent can reach. Jamieson O'Reilly's research on exposed ClawdBot instances demonstrated that hundreds of deployments were directly accessible from the public internet - a configuration that should never exist for a tool with this level of system access.

At minimum, AI agents should run on an isolated network segment with explicit egress rules. My deployment sits behind a reverse proxy that requires authentication for any external access. The host machine itself has no direct internet exposure - all traffic routes through defined channels.

For organisations, this means treating AI agent hosts like you would treat privileged access workstations. They should not share network space with general user devices. They should have monitored egress paths. They should absolutely not be reachable from the public internet without VPN authentication.

Layer 2: Credential Segmentation

The plaintext credential storage that Hudson Rock documented is a genuine concern. AI agents need credentials to function, but those credentials should be scoped, rotated, and monitored.

My approach uses dedicated service accounts for everything the AI agent touches. These are not my personal credentials - they are purpose-created accounts with minimal permissions for specific tasks. My agent can read my calendar but cannot delete events. It can send emails but cannot modify forwarding rules. It can access specific files but not my entire filesystem.

When possible, use short-lived tokens rather than persistent credentials. OAuth tokens that expire and require refresh are significantly less valuable if stolen than static API keys. Where static credentials are unavoidable, store them in a secrets manager rather than in the agent's configuration files.

The goal is ensuring that even if the agent is compromised, the attacker gains access to limited, auditable, revocable permissions rather than unfettered access to everything.

Layer 3: Execution Boundaries

AI agents can execute code and shell commands. This is what makes them powerful. It is also what makes them dangerous if those capabilities are not bounded.

ClawdBot and similar tools support command allowlists - explicit definitions of what commands the agent may execute. This is essential. Without allowlists, a prompt injection attack could instruct the agent to execute arbitrary shell commands on the host system.

My configuration uses a strict allowlist that permits only specific, vetted commands. The agent can run git status but not rm -rf. It can invoke specific scripts I have written but not arbitrary code. Any command outside the allowlist requires explicit approval before execution.

Beyond command restrictions, consider sandbox isolation for the agent runtime. Running the agent in a container or VM provides an additional boundary that limits blast radius if other controls fail. Even if an attacker achieves code execution within the sandbox, they face another barrier before reaching the host system or network.

Layer 4: Input Validation and Filtering

Prompt injection remains the most discussed attack vector for AI systems, and agentic deployments make it particularly dangerous. When an agent processes untrusted input while retaining execution privileges, that input can influence behaviour in unexpected ways.

Complete prevention of prompt injection is not currently possible - it is a fundamental challenge with how large language models process instructions. What you can do is reduce exposure and limit consequences.

First, minimise processing of untrusted content. If your agent does not need to summarise arbitrary web pages, do not give it that capability. Every external data source is a potential injection vector.

Second, implement output filtering for sensitive operations. Before the agent sends an email or executes a command, have it explain what it is about to do. This creates a natural checkpoint that makes manipulation more difficult and more detectable.

Third, use separate contexts for different trust levels. My agent processes my direct messages with full permissions but handles external content in a restricted mode that cannot trigger privileged actions.

Layer 5: Monitoring and Anomaly Detection

No security control is perfect. The final layer is detecting when something has gone wrong.

AI agents generate extensive logs - every interaction, every decision, every action. These logs are security telemetry. A sudden spike in API calls, unusual command execution patterns, or unexpected network connections may indicate compromise.

I export my agent's activity logs to a centralised monitoring system that alerts on anomalies. This caught an issue last month where a misconfigured skill was making excessive API calls - not malicious, but exactly the pattern a compromised agent might exhibit.

For organisations, integrate AI agent monitoring into your existing SIEM infrastructure. The logs are there. Use them.

Practical Hardening Checklist

Based on the layered defence model, here are specific actions to secure an AI agent deployment:

Network Controls

Never expose the agent control interface directly to the internet
Require VPN or zero-trust access for remote management
Implement egress filtering to known-good destinations
Monitor for unexpected outbound connections

Authentication and Access

Use dedicated service accounts with minimal permissions
Enable multi-factor authentication on the management interface
Rotate credentials on a defined schedule
Audit which services have been granted access

Execution Boundaries

Enable command allowlisting and review it regularly
Run the agent in a container or isolated VM where possible
Disable capabilities you do not actively use
Require approval for sensitive operations

Data Protection

Encrypt configuration files at rest where supported
Do not store production credentials in memory files
Regularly purge conversation logs containing sensitive data
Back up agent state to detect unauthorised modifications

Monitoring

Export activity logs to centralised monitoring
Alert on unusual patterns - volume, timing, destinations
Review agent actions periodically, not just when problems occur
Test your detection capabilities with benign anomalies

When an AI Agent Is the Wrong Choice

Not every use case justifies the security overhead of an AI agent. Before deploying one, honestly assess whether the productivity benefits outweigh the risks.

AI agents make sense when you need autonomous action across multiple services and have the infrastructure to secure them properly. They make less sense when simpler automation would suffice or when the data involved is particularly sensitive.

If your AI agent would require access to financial systems, health records, or credentials for critical infrastructure, the risk calculus changes significantly. In those scenarios, the controls required to secure the agent may exceed the effort the agent would save.

I use my agent for email triage, research, and task coordination - valuable but not catastrophic if compromised. I do not give it access to production systems, financial accounts, or anything where a security incident would cause material harm.

As I discussed in my piece on AI governance controls, the key is matching the tool to the risk tolerance. AI agents are powerful. Power requires proportionate controls.

The Path Forward

Securing AI agents is not a solved problem. The tools are evolving rapidly. The threat landscape is shifting as attackers recognise the value of these systems. Best practices will continue to develop.

What we can do today is apply sound security principles to this new tool category. Isolate networks. Segment credentials. Bound execution. Filter input. Monitor everything.

The AI agents as insider threat framing is useful here. Treat your AI agent like a new employee with broad access - trust but verify, grant minimum necessary permissions, and maintain visibility into their actions.

Done well, AI agents can be both powerful and secure. Done poorly, they become exactly the attack surface that security researchers have been warning about. The choice is in the implementation.

Need a production-safe AI agent rollout plan?

Most teams do not need another generic AI policy. They need concrete boundaries around tools, credentials, network reach, approvals, and monitoring before the first agent quietly acquires too much access. My security consulting services and technical consulting support focus on that operational layer.

If you are evaluating agent deployment more broadly, pair this with my articles on AI governance controls and AI agents as an insider threat so policy, architecture, and day-to-day controls line up.

If you want help stress-testing an AI agent design before it reaches production, book a free consultation and I will help you identify the highest-risk gaps first.

Shadow AI Governance Crisis: The Uncontrolled AI Tool Threat

Daniel Glover — Thu, 16 Apr 2026 09:18:41 +0000

This is Part 2 of a 7-part series on Business AI Enablement for IT Leaders. The series covers why enablement matters, building an enablement framework, employee training, tool selection, governance controls, and concludes with a 90-day implementation roadmap.

There is an AI revolution happening inside your organisation. You probably cannot see it.

According to Cisco's 2025 research, approximately 60% of organisations feel they may be unable to identify shadow AI usage. This is not a failure of security tools. It is a fundamental visibility gap created by how employees access AI - through personal accounts, browser extensions, and mobile applications that never touch corporate infrastructure.

Shadow AI is the natural successor to shadow IT. But where shadow IT typically involved file sharing or project management tools, shadow AI involves systems that process sensitive information, generate business content, and increasingly make recommendations that influence decisions.

The stakes are higher. The visibility is worse. And the problem is growing faster than most IT leaders realise.

The Invisible AI Revolution

Shadow AI has reached a scale that should concern every technology leader. Netskope research found that more than 73% of work-related ChatGPT queries were processed using accounts not approved for corporate use. Employees are not just experimenting with AI - they are integrating it into daily work through channels IT cannot monitor.

The speed of growth is remarkable. In sectors like healthcare, manufacturing, and financial services, shadow AI tool usage surged more than 200% year over year according to Zendesk's CX Trends 2025 report. This is not a gradual adoption curve. It is a flood.

How shadow AI enters organisations:

headers={["Entry Point", "Visibility", "Common Examples"]}
rows={[
["Personal accounts on corporate devices", "None to minimal", "ChatGPT Plus, Claude Pro, Gemini Advanced"],
["Browser extensions", "None without endpoint monitoring", "AI writing assistants, grammar tools with AI"],
["Mobile applications", "None on personal devices", "AI chatbots, voice assistants, productivity apps"],
["Embedded AI in approved tools", "Partial", "AI features in email, documents, CRM systems"],
["API integrations by power users", "Varies", "Custom scripts, Zapier automations, low-code tools"]
]}
/>

The challenge is that each entry point has different visibility characteristics. Corporate-managed devices might reveal browser extension usage, but only if endpoint monitoring is configured for it. Mobile devices used for work bypass corporate controls entirely.

The result is that IT leaders are making governance decisions based on incomplete information about actual AI usage patterns.

Where Shadow AI Hides

Understanding where shadow AI concentrates helps prioritise governance efforts. Different business functions have different AI use cases - and different risk profiles.

Marketing and Communications

Marketing teams adopted generative AI faster than almost any other function. The use cases are obvious: content creation, social media posts, email campaigns, ad copy. Shadow AI in marketing typically involves:

Content drafting and editing with ChatGPT or Claude
Image generation for campaigns
Competitive analysis from AI-summarised research
Customer persona development

Risk profile: Moderate. The primary risks are brand inconsistency, factual errors in public content, and potential copyright issues with AI-generated material.

Analytics and Business Intelligence

Data analysts discovered that AI could accelerate insight generation significantly. Shadow AI in analytics includes:

Natural language queries against datasets
Automated report narrative generation
Pattern identification in unstructured data
Code generation for analysis scripts

Risk profile: High. Analysts often work with sensitive business data. Uploading datasets to public AI tools creates substantial data leakage risk.

Customer Service and Support

Frontline support staff use AI to handle volume and complexity. Common shadow uses:

Drafting customer responses
Summarising case history
Troubleshooting assistance
Translation for international customers

Risk profile: High. Customer data frequently flows through these interactions. Regulatory implications vary by industry but are significant in financial services and healthcare.

Software Development

Developers were early adopters of AI coding assistants. Shadow AI in development involves:

Code generation and completion
Debugging assistance
Documentation creation
Code review and refactoring suggestions

Risk profile: Critical. Proprietary code and system architecture details may be exposed. As I explored in my analysis of vibe coding security, AI-generated code also introduces security vulnerabilities if not properly reviewed.

Human Resources

HR teams use AI for tasks ranging from job descriptions to policy drafting. Shadow uses include:

Writing and improving job postings
Drafting employee communications
Performance review assistance
Policy document creation

Risk profile: High. Employee data is sensitive, and AI-assisted hiring decisions may have legal implications around bias and discrimination.

Finance and Procurement

Finance teams leverage AI for analysis and documentation. Shadow applications:

Financial report drafting
Contract review and summarisation
Vendor research and comparison
Budget modelling assistance

Risk profile: Critical. Financial data and contract terms are highly sensitive. Errors in AI-assisted financial analysis could have material business impact.

The Real Risks of Unmanaged AI

Shadow AI creates risks that compound over time. The longer unmanaged AI operates, the more these risks accumulate.

Data Leakage

Every prompt sent to a public AI service potentially exposes information. For consumer-grade AI tools, this data may be used for model training, stored for extended periods, or accessible to the AI provider's employees.

Consider what employees routinely share with AI:

Customer names and account details
Proprietary business strategies
Unreleased product information
Employee performance data
Financial projections and results

A single employee pasting customer data into ChatGPT may not seem catastrophic. But multiply that by hundreds of employees across months of usage, and the aggregate exposure becomes substantial.

The Samsung incident in 2023 - where employees inadvertently exposed proprietary source code through ChatGPT - demonstrated how quickly a shadow AI problem can become a security incident. The company subsequently banned ChatGPT entirely, a reactive measure that created its own productivity costs.

Compliance Violations

Regulatory frameworks increasingly address AI specifically. The EU AI Act, with full enforcement in 2026, creates obligations that shadow AI directly undermines:

Documentation requirements: Organisations must document AI systems used for certain purposes. Shadow AI is undocumented by definition.
Risk assessment obligations: High-risk AI applications require assessment. Shadow AI bypasses this entirely.
Data protection integration: GDPR requirements apply to data processed by AI. Shadow AI often processes personal data without appropriate safeguards.

For organisations in regulated industries, the compliance risk is acute. Healthcare organisations using AI for any patient-related purpose face HIPAA implications. Financial services firms face supervisory scrutiny of AI in customer interactions and decision-making.

Quality and Consistency Failures

AI outputs require verification. Without training and governance, employees often accept AI outputs uncritically. This creates quality risks:

Factual errors: AI confidently generates incorrect information. Without verification processes, these errors propagate into business documents, customer communications, and decisions.
Inconsistency: Different employees using different AI tools produce inconsistent outputs. Brand voice varies. Data interpretations differ. Customer experiences diverge.
Hallucinations in critical contexts: AI fabricating citations, statistics, or precedents can have serious consequences in legal, financial, or customer-facing contexts.

Security Vulnerabilities

Shadow AI creates security exposure beyond data leakage:

Credential exposure: Employees may share API keys, passwords, or access tokens with AI to get assistance. These credentials become exposed.
Malicious output: AI can be manipulated to produce harmful code, phishing content, or misleading information. Without security awareness training, employees may not recognise these risks.
Supply chain risk: Browser extensions and third-party AI integrations may themselves be security risks, operating with permissions that exceed their apparent function.

Why Employees Turn to Shadow AI

Understanding why employees bypass official channels is essential for solving the problem. Blame is counterproductive. Employees using shadow AI are typically trying to do their jobs better.

Legitimate Options Are Missing

The most common driver of shadow AI is simply that organisations have not provided approved alternatives. When IT has no official AI tools available - or the approval process takes months - employees find their own solutions.

This is particularly acute when employees see competitors or peers at other companies using AI effectively. The productivity gap creates pressure to find solutions regardless of official policy.

Approved Tools Do Not Meet Needs

Sometimes organisations have approved AI tools, but they do not serve the use cases employees actually need. A customer service AI that cannot help with marketing content creation pushes marketing teams toward shadow alternatives.

Friction Is Too High

Even when appropriate tools exist, friction kills adoption. If using the approved AI requires multiple approvals, VPN connections, or cumbersome interfaces, employees will gravitate toward the consumer tool that works immediately.

Employees Do Not Know Alternatives Exist

Poor communication about approved tools drives shadow AI as much as poor tools themselves. Employees may not know what is available, how to access it, or what use cases it supports.

Fear of Appearing Incompetent

Some employees hide AI use because they fear it will be seen as cheating or a sign they cannot do their jobs. This creates a particularly insidious form of shadow AI where employees actively conceal their usage.

Gaining Visibility Without Surveillance

The immediate reaction to shadow AI is often surveillance: deploy monitoring tools, scan network traffic, inspect browser history. This approach has severe limitations.

Technical constraints: Much shadow AI occurs through personal devices, personal accounts, and encrypted connections. Traditional monitoring cannot see what it cannot access.

Cultural damage: Aggressive surveillance destroys trust. Employees who feel monitored become less likely to engage transparently with IT - the opposite of what you need for effective AI governance.

False precision: Even comprehensive monitoring only shows tool usage, not the content or risk level of that usage. An employee querying ChatGPT about lunch options looks the same in logs as one uploading customer data.

Better approaches:

Anonymous Usage Surveys

Ask employees directly what AI tools they use and for what purposes. Anonymous surveys generate more honest responses than identifiable ones. The goal is understanding patterns, not identifying individuals.

Network-Level Discovery

While you cannot inspect encrypted content, you can identify connections to known AI services. This provides aggregate usage data without content surveillance. Useful for understanding scale, not individual behaviour.

Expense Analysis

Many employees expense AI subscriptions. Expense reports reveal shadow AI spend that licensing reviews miss.

Access Log Analysis

For corporate-managed identity systems, authentication logs to AI services reveal usage patterns. This works for services that support SSO but catches employees using personal accounts.

Open Dialogue

Often the most effective approach is simply asking. Town halls, team meetings, and informal conversations can surface shadow AI usage when employees feel safe discussing it.

The goal of visibility is not punishment. It is understanding current state so you can design solutions that actually address employee needs. This is particularly important when AI is reshaping how software itself gets built - the governance challenge extends well beyond chat-based AI tools into the development pipeline itself.

The 32% Control Gap

Netskope research found that only 32% of organisations have formal controls in place for AI usage. This control gap explains much of the shadow AI problem.

What formal controls typically include:

Acceptable use policies specific to AI
Data classification guidance for AI inputs
Approved tool catalogues with access provisioning
Training requirements before AI access
Monitoring and audit capabilities
Incident response procedures for AI-related issues

Why controls lag:

Speed of adoption: AI adoption outpaced governance development at most organisations
Uncertainty about risk: Without clear risk frameworks, governance teams hesitated
Lack of ownership: AI governance often falls between IT, security, legal, and business - and belongs clearly to none
Competing priorities: Other security and compliance priorities consumed governance capacity

What happens without controls:

Without formal controls, AI governance becomes ad hoc. Different business units develop different practices. Inconsistent risk management creates compliance gaps. Employees lack clear guidance on appropriate use.

The 32% figure is not just a governance gap. It is a value gap. Organisations without controls cannot systematically improve AI effectiveness because they lack the feedback loops that governance provides.

Quick Reference: Shadow AI Discovery Checklist

Use these steps to assess shadow AI in your organisation:

Baseline Assessment:

[ ] Survey employees anonymously about AI tool usage
[ ] Analyse network traffic for connections to known AI services
[ ] Review expense reports for AI-related subscriptions
[ ] Audit authentication logs for AI service access
[ ] Interview business unit leaders about team AI practices

Risk Identification:

[ ] Map shadow AI by department and use case
[ ] Identify data types flowing through shadow channels
[ ] Assess regulatory implications by usage type
[ ] Evaluate security exposure from identified tools
[ ] Prioritise risks by likelihood and impact

Root Cause Analysis:

[ ] Document why employees chose shadow tools over alternatives
[ ] Identify gaps in official tool offerings
[ ] Assess friction in approved tool access
[ ] Review communication about available resources
[ ] Understand cultural factors driving concealment

Immediate Actions:

[ ] Address highest-risk shadow AI with interim controls
[ ] Communicate current policies clearly to all employees
[ ] Establish safe reporting channel for AI concerns
[ ] Begin planning for comprehensive enablement programme

Shadow AI discovery is not a one-time exercise. As new AI tools emerge and employee needs evolve, regular reassessment is essential.

From Visibility to Action

Discovering shadow AI is only the first step. The insight is valuable only if it drives action.

The temptation is to respond with restrictions - blocking services, banning tools, enforcing compliance. This approach fails for the same reasons that drove shadow AI in the first place. Employees have needs that AI addresses. Blocking tools does not eliminate those needs.

The effective response is enablement that makes shadow AI unnecessary. Provide approved tools that meet employee needs. Offer training that builds confidence. Implement governance that enables rather than restricts.

Part 3 provides the framework for this enablement approach - a structured method for building the access, training, governance, and support that make shadow AI obsolete.

The goal is not zero shadow AI. Some experimentation with new tools will always occur, and that experimentation often identifies valuable capabilities. The goal is reducing shadow AI to the point where visibility is achievable and risks are manageable.

Organisations that achieve this balance gain the benefits of AI adoption without the accumulating risks of unmanaged usage.

Addressing Shadow AI in Your Organisation

Understanding your shadow AI landscape is the first step toward effective governance. My IT compliance services help organisations assess current AI usage, identify risks, and develop governance frameworks that enable rather than restrict.

Get in touch to discuss how to gain visibility into AI usage and build controls that actually work.

Previous: Part 1 - Why Business AI Enablement Matters Now

Next: Part 3 - Building Your AI Enablement Framework

The True Cost of Technical Debt: A Framework for IT Leaders

Daniel Glover — Thu, 16 Apr 2026 09:18:27 +0000

Every IT leader knows the feeling. You are staring at a system that works - technically - but every change takes three times longer than it should. Deployments that should take minutes take hours. New starters spend their first week trying to understand why the codebase has four different ways of doing the same thing. And somewhere in the back of your mind, you know that one critical integration is held together by a script nobody fully understands.

That is technical debt. And if you cannot put a number on it, you will never get the budget to fix it.

I have spent years managing IT infrastructure and development teams supporting over 250 users at an e-commerce company. Along the way, I have learned that the biggest barrier to tackling technical debt is not technical - it is communication. Engineers understand the problem intuitively. The board needs it in pounds and pence.

Here is the framework I use to measure technical debt, prioritise what to fix first, and build a business case that actually gets approved.

What Technical Debt Really Is (and Is Not)

Ward Cunningham coined the term "technical debt" in 1992 as a metaphor for the shortcuts teams take to ship faster. Like financial debt, it accrues interest - every future change costs more because of the shortcuts taken earlier.

But not all technical debt is bad. Just as a mortgage lets you buy a house before you have saved the full price, deliberate technical debt lets you ship features quickly when speed matters. The problem is unmanaged debt - the kind that accumulates silently until it becomes a crisis.

In my experience, technical debt falls into four categories:

Deliberate and prudent - "We know this is not ideal, but shipping this week is worth more than perfection next month." This is strategic debt with a clear payoff.
Deliberate and reckless - "We do not have time for tests." This is corner-cutting that always costs more later.
Inadvertent and prudent - "Now we know what we should have built." This is the natural result of learning and is unavoidable.
Inadvertent and reckless - "What is a design pattern?" This comes from lack of skill or oversight and is the most expensive to fix.

Understanding which type you are dealing with changes how you prioritise and communicate the problem. I explored the strategic mindset shift required in my earlier piece on reframing tech debt as a leadership challenge - this post focuses on the practical measurement and business case side.

Why the Board Does Not Care (Yet)

I have sat in boardrooms where I tried to explain technical debt using engineering language. Terms like "code smell," "coupling," and "architectural drift" got blank stares. The conversation moved on quickly.

The board cares about three things: revenue, risk, and cost. If you cannot connect technical debt to at least one of those, you will not get budget. Full stop. That is exactly where IT management consulting adds value - turning technical concerns into commercial decisions leaders can actually act on.

Here is what changed my approach: I stopped talking about the debt itself and started talking about its consequences in business terms.

"Our deployment pipeline takes 4 hours instead of 20 minutes, which means we can only ship once a day instead of continuously. That cost us two weeks of lost sales during the Black Friday promotion because we could not push a critical pricing fix fast enough."
"Three of our five senior developers spend roughly 30% of their time working around legacy code rather than building new features. That is the equivalent of burning one full-time salary on maintenance that should not exist."
"Our payment integration uses an API version that reaches end-of-life in six months. If we do not migrate, we lose the ability to process card payments."

Numbers. Timelines. Business impact. That is the language that gets attention.

A Framework for Measuring Technical Debt

Quantifying something as nebulous as technical debt sounds impossible, but it is not. You just need to measure the right proxies. Here is the framework I developed and refined over several years.

Step 1: Identify the Debt

Start with a structured audit. I use a simple spreadsheet with the following columns:

System/component - What is affected
Type of debt - Using the four categories above
Description - Plain-English explanation of the problem
Impact area - Velocity, reliability, security, or scalability
Severity - High, medium, or low

Get your engineering team involved. Run a session where everyone can contribute anonymously - you will be surprised what surfaces. In our case, we identified 47 distinct items of technical debt across our platform in the first audit.

Step 2: Quantify the Cost of Inaction

For each item, estimate the ongoing cost using these metrics:

Developer time tax - How much extra time does this debt add to every related task? If a developer spends an extra 2 hours per week working around a legacy authentication module, that is roughly 100 hours per year. Multiply by your loaded cost per developer hour (salary plus benefits plus overhead, typically between £50 and £80 per hour for mid-level engineers in the UK), and you have a tangible annual cost.

Incident cost - How often does this debt cause incidents? What is the cost per incident in terms of engineer time, lost revenue, and customer impact? We tracked this over six months and found that our legacy order processing system was responsible for 60% of our on-call pages - roughly 3 incidents per week, each costing an average of 4 hours of engineer time plus measurable revenue impact during downtime.

Opportunity cost - What features or improvements cannot be delivered because the team is fighting fires or working around limitations? This is harder to quantify but often the most compelling. We estimated that technical debt was consuming roughly 35% of our total engineering capacity - meaning for every three engineers we employed, one was effectively doing nothing but servicing debt.

Risk cost - What is the probability and impact of a catastrophic failure? An end-of-life dependency with no migration plan is a ticking time bomb. Multiply the probability of failure by the estimated business impact to get a risk-adjusted cost.

Step 3: Calculate the Cost of Remediation

For each item, get engineering estimates for the fix. Be honest about uncertainty - use ranges rather than single numbers. A database migration might take "between 3 and 6 weeks of one engineer's time," which translates to a cost range you can present with confidence.

Step 4: Prioritise Using a Debt Ratio

I use a simple ratio to prioritise:

Debt Ratio = Annual Cost of Inaction / One-Time Cost of Remediation

A ratio above 2.0 means the debt pays for itself within six months. Anything above 1.0 pays for itself within a year. Below 1.0, you are looking at a longer payback period - which might still be worth it for risk reduction, but requires a different argument.

Sort your debt items by this ratio. The top of the list is where you start.

In our case, the top three items had ratios of 4.2, 3.8, and 3.1. That made the business case almost trivial - we were spending four times more per year living with the debt than it would cost to fix it.

Building the Business Case

With your data in hand, building the business case becomes a straightforward exercise. Here is the structure I use.

The One-Page Executive Summary

The board does not want a 30-page document. They want clarity. I use a single page with four sections:

The problem - "Technical debt is costing us an estimated £X per year in lost productivity, incidents, and delayed features."
The evidence - Two or three specific, quantified examples from your audit.
The proposal - "We recommend a 12-week remediation programme targeting the top 10 debt items, requiring £Y in dedicated engineering time."
The return - "This will reduce ongoing costs by £Z per year, improve deployment frequency by X%, and eliminate our three highest-risk dependencies."

Framing It as Investment, Not Cost

Language matters enormously. "We need to refactor our codebase" sounds like an expense with no return. "We are proposing a £80,000 investment that will save £200,000 annually and reduce critical incident risk by 60%" sounds like a no-brainer.

I always present technical debt remediation alongside feature work, not as an alternative to it. The pitch is not "instead of building features, we want to fix old code." It is "by investing 20% of our capacity in debt reduction, we will increase our feature delivery speed by 40% within two quarters."

Using Leading Indicators

Once you have approval, you need to show progress. Track and report on:

Deployment frequency - How often can you ship?
Lead time for changes - From commit to production
Change failure rate - What percentage of deployments cause incidents?
Mean time to recovery (MTTR) - How quickly can you fix problems?

These are the four DORA metrics, and they are well-understood benchmarks that translate directly to business value. Report on them monthly. When the board sees deployment frequency double and incident rates halve, the next budget request becomes much easier. For more on translating technical outcomes into language the board understands, see my guide to data storytelling for IT value.

Making It Sustainable

The biggest mistake I see is treating technical debt remediation as a one-off project. It is not. Debt accumulates continuously, and you need a continuous process to manage it.

The 20% Rule

We allocate 20% of every sprint to debt reduction. This is non-negotiable and built into our capacity planning. It is not glamorous, but it keeps debt from compounding. Think of it like making minimum payments on a credit card - it prevents the balance from growing while you tackle the big items strategically.

Debt Retrospectives

Every quarter, we run a technical debt retrospective. The engineering team reviews the current debt register, updates estimates, and identifies new items. This keeps the data fresh and ensures nothing festers unnoticed.

Architectural Decision Records (ADRs)

When we take on deliberate debt - and sometimes we should - we document it in an ADR. This includes what the debt is, why we are taking it on, and when we plan to pay it back. This creates accountability and prevents "temporary" solutions from becoming permanent fixtures.

Common Objections (and How to Handle Them)

Over the years, I have heard every objection. Here are the most common and how I address them.

"We cannot afford to slow down feature delivery."
You are already slower than you should be. Technical debt is the reason features take longer than estimated. Investing in debt reduction accelerates future delivery.

"If it is not broken, why fix it?"
It is broken - you just cannot see it yet. Show them the incident data. Show them the developer time tax. Show them the end-of-life dependencies. "Not broken" and "not yet catastrophic" are very different things.

"Can we just rewrite the whole thing?"
Almost certainly not. Full rewrites are expensive, risky, and take far longer than anyone estimates. Incremental remediation delivers value continuously and reduces risk at every step.

"How do we know this will actually deliver the savings you are projecting?"
You do not, with certainty. But you have data, benchmarks, and a clear measurement framework. Propose a three-month pilot targeting the highest-ratio items and measure the results before committing to the full programme.

The Real Cost of Doing Nothing

Technical debt does not stay static. It compounds. The longer you leave it, the more expensive it becomes to fix, and the more it constrains your ability to respond to market changes.

I have seen companies where technical debt became so severe that they could not adopt new payment providers, could not scale for peak trading, and could not meet regulatory deadlines. At that point, the cost is not measured in developer hours - it is measured in lost contracts and failed audits. This is exactly why boring, reliable infrastructure beats cutting-edge every time - it reduces the kind of accumulated complexity that makes technical debt unmanageable.

The true cost of technical debt is not what it costs today. It is what it will cost you when you can no longer afford to ignore it.

Key Takeaways

Technical debt is a business problem, not just a technical one. Frame it accordingly.
Measure the cost of inaction using developer time tax, incident cost, opportunity cost, and risk cost.
Use the debt ratio (annual cost of inaction divided by remediation cost) to prioritise ruthlessly.
Present a one-page business case with clear numbers and projected returns.
Make debt management sustainable with the 20% rule, quarterly retrospectives, and ADRs.
Track DORA metrics to demonstrate ongoing value to leadership.

The conversation about technical debt does not have to be adversarial. When you bring data, clarity, and a clear return on investment, it becomes one of the easiest business cases you will ever make.

If you need help building the business case for technical debt remediation or want an outside perspective on your technology estate, my IT management consulting and technical consulting services can support both the strategy and delivery. Get in touch to discuss your priorities.

Daniel Glover is an IT leader with experience managing technology teams and infrastructure for organisations with 250+ users. He writes about IT strategy, cybersecurity, and engineering leadership at danieljamesglover.com.

Zero Trust Architecture: Why Good Intentions Are Not Enough

Daniel Glover — Thu, 16 Apr 2026 09:06:30 +0000

If I had a pound for every email I received promising to "Install Zero Trust in 24 hours," I would have retired to the Bahamas.

Zero Trust Network Access (ZTNA) is simultaneously the most hyped and most pivotal concept in modern cybersecurity. It is also the most misunderstood. You cannot buy Zero Trust. It is an architectural approach, not a SKU.

This article cuts through the marketing fog to examine what Zero Trust actually means, how to assess your organisation's readiness, and how to implement it in phases without disrupting your business. We will explore the three foundational pillars, provide a practical maturity model, and give you a roadmap for transformation.

The Zero Trust Myth vs Reality

Before we discuss implementation, we need to dispel some persistent myths that vendors perpetuate.

What Zero Trust Is Not

Myth 1: Zero Trust is a product you can buy.
Every major security vendor now slaps "Zero Trust" on their product brochures. Firewalls, VPNs, identity providers, endpoint agents - all claim to "enable Zero Trust." None of them deliver it alone. Zero Trust is an architecture, not a product category.

Myth 2: Zero Trust means trusting nothing.
The name is unfortunately misleading. Zero Trust does not mean paranoid distrust of everything. It means verifying everything explicitly rather than relying on implicit trust from network location.

Myth 3: Zero Trust replaces your existing security.
Zero Trust augments and reorganises your security controls. It does not eliminate the need for firewalls, encryption, or endpoint protection. It changes how these controls coordinate and make decisions.

Myth 4: Zero Trust is only for large enterprises.
While implementation complexity scales with organisation size, the principles apply to organisations of any size. A 50-person company can implement Zero Trust principles with standard tooling.

What Zero Trust Actually Is

Zero Trust is a security model based on a simple principle: "Never trust, always verify."

The traditional security model - often called "Castle and Moat" - assumed that if you were inside the corporate network, you were trusted. Everyone inside the castle walls was a friend. This model made sense when:

Employees worked in offices
Servers lived in data centres
Applications were on-premises
The network perimeter was well-defined

None of these assumptions hold in 2026. Your employees work from home, coffee shops, and co-working spaces. Your servers are in AWS, Azure, and Google Cloud. Your applications are SaaS. The perimeter has not just eroded - it has evaporated.

Zero Trust assumes the network is already compromised. Every access request - regardless of source - must be explicitly verified against:

Identity: Who is making the request?
Device: What device are they using, and is it healthy?
Context: When, where, and why are they requesting access?
Resource: What specifically are they trying to access?
Privilege: Should they have access to this resource at this time?

Only after all these factors are verified does access get granted - and only the minimum access required.

The Shift in Thinking

headers={["Traditional Model", "Zero Trust Model"]}
rows={[
["Trust internal network traffic", "Verify all traffic regardless of source"],
["Wide network access once connected", "Least privilege access to specific resources"],
["Security focused on perimeter", "Security focused on identity and data"],
["Static access permissions", "Dynamic, context-aware access decisions"],
["VPN as primary remote access", "Identity-centric access without VPN"],
["Implicit trust for internal users", "Explicit verification for all users"],
["Flat networks with minimal segmentation", "Micro-segmented networks with strict boundaries"]
]}
/>

This shift fundamentally changes how we architect security. As I discussed in Identity is the New Firewall, the network perimeter is dead. Identity has become the new perimeter - and Zero Trust is the architecture that makes identity-centric security operational.

The Three Pillars of Zero Trust

Zero Trust implementations rest on three foundational pillars. Miss any one of them, and your architecture has a structural weakness.

Pillar 1: Identity Verification (The Foundation)

Identity is the cornerstone of Zero Trust. Before any other decision can be made, you must know who is making the request. Not just their username - their verified identity.

As I explored in Identity is the New Firewall, the vast majority of modern breaches involve compromised identities, not smashed firewalls. If an attacker steals a valid credential, network controls are useless. The attacker is the user.

Essential Identity Controls:

Multi-Factor Authentication (MFA):
If you still allow single-factor authentication on any external-facing system, you are negligent. But not all MFA is equal:

SMS/Voice codes: Vulnerable to SIM swapping and interception. Better than nothing, but barely.
Time-based codes (TOTP): Better, but still phishable.
Push notifications: Convenient but susceptible to push fatigue attacks.
Hardware keys (FIDO2/WebAuthn): Phishing-resistant. The gold standard.
Biometric passkeys: The future - phishing-resistant with excellent UX.

Move toward phishing-resistant MFA for all privileged access and sensitive systems.

Single Sign-On (SSO):
SSO is not just a convenience feature - it is a security control. It creates:

A single authentication point for all applications
Centralised logging and auditing
One place to revoke access when employees leave
Consistent policy enforcement across applications

Every application that supports SSO should use it. Every application that does not should be evaluated for replacement.

Identity Governance and Administration (IGA):
Knowing who someone is means nothing if you do not manage what they are allowed to do:

Automated provisioning and deprovisioning
Access certification and reviews
Segregation of duties enforcement
Access request workflows

Conditional Access Policies:
Identity verification should not be binary. Conditional access evaluates context:

Is this a known device?
Is the location unusual?
What is the user trying to access?
What is the risk level of this request?

Based on these factors, you might allow access, require additional verification, or deny access entirely.

Pillar 2: Device Health

Verifying identity is necessary but insufficient. You must also verify the device making the request.

Consider this scenario: Your CEO authenticates with their username, password, and hardware key. Perfect identity verification. But they are connecting from an infected, unmanaged personal iPad they picked up at a conference. Zero Trust says: Access Denied.

The device is part of the trust calculation because a compromised device can compromise everything the user accesses from it.

Device Health Signals:

Management status: Is this a managed corporate device or a personal device?
OS patch level: Is the operating system current on security updates?
Disk encryption: Is the device encrypted at rest?
Endpoint protection: Is EDR/antivirus running and healthy?
Firewall status: Is the local firewall enabled?
Jailbreak/root detection: Has the device been tampered with?
Compliance status: Does the device meet your baseline requirements?

Device Trust Tiers:

Not all devices need the same trust level. Consider a tiered approach:

headers={["Tier", "Device Type", "Trust Level", "Access Scope"]}
rows={[
["1", "Managed, fully compliant corporate device", "High", "All corporate resources"],
["2", "Managed device with minor compliance gaps", "Medium", "Most resources, excluding highly sensitive"],
["3", "BYOD with MDM enrolled", "Low", "Limited resources via containerised apps"],
["4", "Unknown/unmanaged device", "Minimal", "Public resources only, or browser-based with no data export"]
]}
/>

Technical Implementation:

Device health verification typically requires:

Mobile Device Management (MDM) for mobile devices
Endpoint Detection and Response (EDR) for computers
Device compliance policies defining minimum requirements
Conditional access integration to enforce device requirements at authentication

Your identity provider and device management platform must integrate to share health signals. Without this integration, you cannot make device-aware access decisions.

Pillar 3: Least Privilege Access

The third pillar addresses what happens after identity and device are verified: granting the minimum access required, for the minimum time required.

The traditional model granted broad access - once authenticated, users could often reach many resources they did not need. Zero Trust inverts this: access is denied by default, and explicitly granted only to specific resources.

Least Privilege Principles:

Default Deny:
If access is not explicitly granted, it is denied. This is the opposite of traditional "allow by default" networks.

Just Enough Access (JEA):
Grant access only to the specific resources needed for the specific task. A developer does not need access to the HR database. A marketing analyst does not need access to production servers.

Just-In-Time Access (JIT):
Why does your administrator have Domain Admin rights 24/7? They use those privileges for perhaps 10 minutes a day. JIT grants elevated privileges only when needed, for a specific duration, with specific approval. When the task is complete, privileges are revoked automatically.

Micro-Segmentation:
Traditional networks are "flat" - once inside, you can communicate with anything. Micro-segmentation creates secure zones, limiting lateral movement. The printer cannot talk to the database server. The development environment cannot reach production.

Application-Level Access:
Instead of network access, grant application-level access. Users connect to the specific application they need, not to the network where the application lives. This eliminates the concept of "being on the corporate network."

Implementation Considerations:

headers={["Control", "Purpose", "Implementation"]}
rows={[
["Privileged Access Management (PAM)", "Control and audit privileged credentials", "CyberArk, BeyondTrust, HashiCorp Vault"],
["Identity Governance (IGA)", "Lifecycle management and access reviews", "SailPoint, Saviynt, Microsoft Entra ID Governance"],
["Zero Trust Network Access (ZTNA)", "Application-level access without VPN", "Zscaler, Cloudflare Access, Palo Alto Prisma"],
["Software-Defined Perimeter", "Hide applications from unauthorised users", "Appgate, Perimeter 81, Google BeyondCorp"],
["Micro-Segmentation", "Limit lateral movement within networks", "Illumio, Guardicore, VMware NSX"]
]}
/>

Zero Trust Maturity Model

Zero Trust implementation is not binary - it is a journey. Most organisations start at a low maturity level and progress through stages over multiple years.

The Five Maturity Levels

headers={["Level", "Name", "Characteristics"]}
rows={[
["0", "Traditional", "Perimeter-based security; implicit trust for internal network; limited identity controls; flat network architecture"],
["1", "Initial", "Basic MFA deployed; some network segmentation; centralised identity provider; awareness of Zero Trust concepts"],
["2", "Developing", "MFA for all users; device health checks begun; ZTNA for some applications; access reviews implemented"],
["3", "Defined", "Conditional access policies active; comprehensive device compliance; micro-segmentation advancing; JIT access for privileged accounts"],
["4", "Managed", "Real-time risk assessment; continuous verification; automated response to anomalies; comprehensive visibility"],
["5", "Optimised", "Fully automated Zero Trust decisions; AI-driven anomaly detection; continuous improvement; complete asset visibility"]
]}
/>

Most organisations today are at Level 0 or 1. Reaching Level 3 represents a significant security improvement. Level 5 is aspirational for most - even security-mature organisations rarely achieve full optimisation.

Self-Assessment Checklist

Use this checklist to assess your current Zero Trust maturity:

Identity (Score 0-5 for each):

[ ] All users have MFA enabled for all external access
[ ] Phishing-resistant MFA deployed for privileged accounts
[ ] SSO implemented for all supported applications
[ ] Automated provisioning/deprovisioning in place
[ ] Regular access reviews conducted and actioned
[ ] Conditional access policies evaluate context
[ ] Identity threat detection monitors for anomalies

Device (Score 0-5 for each):

[ ] Device inventory is complete and accurate
[ ] MDM deployed on all mobile devices accessing corporate data
[ ] EDR deployed on all endpoints
[ ] Device compliance policies defined and enforced
[ ] Conditional access integrates device health signals
[ ] BYOD policy clearly defined with technical controls
[ ] Unmanaged device access restricted appropriately

Network/Access (Score 0-5 for each):

[ ] Network segmentation separates critical assets
[ ] ZTNA deployed for remote application access
[ ] VPN dependency reduced or eliminated
[ ] Micro-segmentation limits lateral movement
[ ] Application-level access replaces network-level access
[ ] Default deny posture for new connections
[ ] Visibility into all network traffic

Privileged Access (Score 0-5 for each):

[ ] Privileged accounts inventoried and monitored
[ ] PAM solution manages privileged credentials
[ ] JIT access implemented for administrative tasks
[ ] Session recording for sensitive access
[ ] Separation of duties enforced
[ ] Break-glass procedures documented and tested
[ ] Regular privileged access reviews conducted

Scoring:

0-35: Level 0-1 (Traditional/Initial)
36-70: Level 2 (Developing)
71-105: Level 3 (Defined)
106-125: Level 4 (Managed)
126-140: Level 5 (Optimised)

The Zero Trust Adoption Roadmap

Migrating to Zero Trust is a multi-year journey. Do not attempt to "rip and replace" your entire security architecture overnight. That path leads to outages, user frustration, and abandoned initiatives.

Instead, approach Zero Trust in phases, starting with your highest-value targets and expanding methodically.

Phase 1: Foundation (Months 1-6)

Objectives:

Establish identity as the primary control plane
Achieve comprehensive MFA coverage
Gain visibility into current access patterns

Week 1-4: Assessment and Planning

[ ] Conduct current state security assessment
[ ] Inventory all applications and their authentication methods
[ ] Map data flows and identify critical assets ("Crown Jewels")
[ ] Assess existing identity infrastructure
[ ] Document current network architecture
[ ] Identify stakeholders and form Zero Trust working group
[ ] Develop phased implementation plan

Week 5-12: Identity Foundation

[ ] Deploy or upgrade identity provider (Entra ID, Okta, etc.)
[ ] Enable MFA for all external access
[ ] Implement SSO for high-priority applications
[ ] Configure basic conditional access policies
[ ] Begin automated provisioning/deprovisioning
[ ] Deploy phishing-resistant MFA for IT administrators

Week 13-24: Device Visibility

[ ] Complete device inventory across all platforms
[ ] Deploy MDM for mobile devices
[ ] Ensure EDR coverage on all endpoints
[ ] Define initial device compliance baselines
[ ] Integrate device signals with identity provider
[ ] Establish BYOD policy and technical controls

Phase 1 Checkpoint:

Before proceeding to Phase 2, validate:

[ ] MFA enabled for 100% of external access
[ ] SSO implemented for top 10 applications
[ ] Conditional access policies active
[ ] Device inventory 95%+ complete
[ ] MDM/EDR coverage on all managed devices
[ ] Stakeholder support confirmed

Phase 2: Crown Jewels Protection (Months 7-12)

Objectives:

Protect most critical applications with full Zero Trust controls
Implement ZTNA for sensitive application access
Deploy PAM for privileged accounts

Crown Jewels Identification:

Your "Crown Jewels" are the systems and data that would cause the most damage if compromised. Typically:

Financial systems (ERP, banking, payment processing)
Customer data repositories (CRM, databases)
Intellectual property (source code, designs, research)
HR systems (employee data, payroll)
Executive communications

Week 25-36: ZTNA Deployment

[ ] Select ZTNA solution aligned with architecture
[ ] Deploy ZTNA for Crown Jewels applications
[ ] Configure application-level access policies
[ ] Integrate with identity and device health signals
[ ] Train IT staff on ZTNA administration
[ ] Begin phased user migration from VPN

Week 37-48: Privileged Access Management

[ ] Inventory all privileged accounts
[ ] Deploy PAM solution (CyberArk, BeyondTrust, etc.)
[ ] Implement password vaulting for admin accounts
[ ] Configure JIT access for administrative tasks
[ ] Enable session recording for sensitive access
[ ] Conduct privileged access review

Phase 2 Checkpoint:

[ ] Crown Jewels applications protected with ZTNA
[ ] PAM deployed for IT administrative access
[ ] JIT access operational for routine admin tasks
[ ] VPN dependency reduced for pilot groups
[ ] Metrics showing reduced attack surface

Phase 3: Broad Deployment (Months 13-24)

Objectives:

Extend Zero Trust controls to all applications
Implement micro-segmentation
Achieve continuous verification

Week 49-72: Application Expansion

[ ] Deploy ZTNA for Tier 2 applications
[ ] Migrate remaining users from VPN
[ ] Extend SSO to all supported applications
[ ] Implement risk-based authentication
[ ] Configure automated response to anomalies

Week 73-96: Network Transformation

[ ] Design micro-segmentation architecture
[ ] Deploy initial micro-segmentation for critical segments
[ ] Implement network traffic analysis
[ ] Reduce lateral movement paths
[ ] Validate segmentation effectiveness through testing

Phase 3 Checkpoint:

[ ] ZTNA deployed for all appropriate applications
[ ] VPN eliminated or limited to exceptions
[ ] Micro-segmentation protecting critical assets
[ ] Continuous monitoring operational
[ ] Incident response processes updated for Zero Trust

Phase 4: Optimisation (Ongoing)

Objectives:

Continuous improvement based on metrics
Advanced automation and AI-driven decisions
Regular maturity reassessment

Ongoing Activities:

Regular access reviews and certification
Policy refinement based on operational data
Technology refresh as capabilities evolve
Red team exercises to validate controls
Maturity assessment against framework
Stakeholder reporting and ROI demonstration

Vendor Landscape Overview

The Zero Trust market is crowded and confusing. Understanding the landscape helps navigate vendor conversations.

Platform Categories

headers={["Category", "What It Does", "Key Vendors"]}
rows={[
["Identity Provider (IdP)", "Centralised authentication and SSO", "Microsoft Entra ID, Okta, Ping Identity, Google Workspace"],
["Zero Trust Network Access (ZTNA)", "Application-level access without VPN", "Zscaler Private Access, Cloudflare Access, Palo Alto Prisma Access, Netskope Private Access"],
["Secure Access Service Edge (SASE)", "Converged network and security services", "Zscaler, Netskope, Palo Alto, Cisco"],
["Privileged Access Management (PAM)", "Secure privileged credentials and sessions", "CyberArk, BeyondTrust, Delinea, HashiCorp Vault"],
["Identity Governance (IGA)", "Access lifecycle and certification", "SailPoint, Saviynt, One Identity, Microsoft Entra ID Governance"],
["Endpoint Detection and Response (EDR)", "Device security and health attestation", "CrowdStrike, Microsoft Defender, SentinelOne, Carbon Black"],
["Micro-Segmentation", "Network traffic control and lateral movement prevention", "Illumio, Guardicore (Akamai), VMware NSX"]
]}
/>

Vendor Selection Considerations

When evaluating vendors, consider:

Integration capability: Zero Trust requires components to share signals. Vendors must integrate with your existing identity, endpoint, and network infrastructure.

Deployment model: Cloud-native vs on-premises vs hybrid. Your infrastructure strategy should guide this choice.

User experience: Security that frustrates users gets bypassed. Evaluate the user experience for each solution.

Operational complexity: More tools means more operational overhead. Consider managed services or converged platforms.

Total cost of ownership: Beyond licensing, consider implementation, training, integration, and ongoing operations.

Vendor viability: Zero Trust is a long-term architecture. Ensure vendors will be around for the journey.

Avoid Vendor Traps

The "complete solution" myth: No single vendor delivers complete Zero Trust. You will need multiple integrated components.

The checkbox approach: Do not buy tools to check compliance boxes. Buy tools that genuinely improve your security posture.

The best-of-breed vs platform debate: There is no universal right answer. Best-of-breed offers capability but complexity. Platforms offer integration but potential gaps. Choose based on your operational maturity and resources.

Migration Priority Matrix

Not all applications and users should migrate at the same time. Prioritise based on risk and impact.

headers={["Priority", "Application Type", "User Group", "Rationale"]}
rows={[
["1 - Immediate", "Financial systems, customer databases", "IT administrators", "Highest value targets; privileged access most abused"],
["2 - High", "Email, collaboration tools", "Executives, finance staff", "Common attack vectors; high-value user targets"],
["3 - Medium", "Development tools, internal apps", "General employees", "Significant data access; large user population"],
["4 - Lower", "Public-facing marketing, low-sensitivity apps", "Contractors, temporary staff", "Lower data sensitivity; transient users"],
["5 - Deferred", "Legacy systems without modern auth", "Specialised users", "Technical constraints; plan for modernisation"]
]}
/>

Prioritisation Factors

Data sensitivity: What is the classification of data accessible through this system?

User privilege level: Are users accessing administrative functions or routine tasks?

Attack surface: Is the application internet-facing? Does it process untrusted input?

Business criticality: What is the impact of downtime or compromise?

Technical feasibility: Does the application support modern authentication?

User impact: How disruptive will the migration be for users?

Common Implementation Challenges

Zero Trust implementations frequently encounter these challenges. Anticipate them.

Technical Challenges

Legacy application compatibility:
Some applications do not support modern authentication (SAML, OIDC, SCIM). Options include:

Application proxy solutions that front legacy apps
Vendor upgrades or replacements
Isolated access with additional compensating controls

Network visibility gaps:
You cannot protect what you cannot see. Ensure comprehensive visibility into network traffic before implementing micro-segmentation.

Integration complexity:
Zero Trust requires components to share information. Budget significant effort for integration work.

Organisational Challenges

User resistance:
Zero Trust may introduce additional verification steps. Communicate the "why" before the "what." Emphasise that security protects users, not just the company.

Stakeholder fatigue:
Multi-year transformations risk losing executive attention. Deliver visible wins early and maintain regular progress reporting.

Skills gaps:
Zero Trust requires new skills in identity, cloud security, and modern architecture. Plan for training and potentially external support.

Operational Challenges

Alert fatigue:
More visibility means more alerts. Invest in tuning and automation to prevent analyst burnout.

Policy complexity:
Conditional access policies can become complex quickly. Document policies clearly and review regularly.

Incident response updates:
Zero Trust changes how incidents unfold. Update playbooks and train responders on the new architecture.

Measuring Zero Trust Success

Metrics demonstrate progress and justify continued investment.

Key Performance Indicators

headers={["Category", "Metric", "Target"]}
rows={[
["Coverage", "% of applications protected by ZTNA", "100% (excluding documented exceptions)"],
["Coverage", "% of users with MFA enabled", "100%"],
["Coverage", "% of privileged accounts in PAM", "100%"],
["Effectiveness", "Mean time to revoke access on termination", "< 1 hour"],
["Effectiveness", "% of access requests requiring step-up auth", "Risk-appropriate"],
["Effectiveness", "Lateral movement attempts blocked", "Increasing"],
["Risk Reduction", "VPN attack surface eliminated", "Measured in exposed services"],
["Risk Reduction", "Privileged session duration", "Decreasing"],
["Operational", "False positive rate for anomaly detection", "< 5%"],
["Operational", "User authentication friction incidents", "Decreasing"]
]}
/>

Demonstrating ROI

Zero Trust investments compete for budget. Demonstrate value through:

Reduced breach risk: Quantify risk reduction using frameworks like FAIR
Compliance efficiency: Reduced audit findings, faster evidence collection
Operational savings: VPN infrastructure retirement, reduced help desk burden
Business enablement: Secure remote work, faster onboarding, M&A integration

Zero Trust and the Modern Workplace

Zero Trust aligns perfectly with how organisations actually operate in 2026.

Remote and Hybrid Work

As I explored in Asynchronous IT Leadership, the remote-first world is here to stay. Zero Trust was designed for this reality - it assumes no network is trusted, making work location irrelevant to security posture.

VPNs were designed to extend the corporate network to remote users. But they extend all network access, create performance bottlenecks, and frustrate users. ZTNA provides application-level access without the overhead and risk of full network connectivity.

Cloud and SaaS

Traditional perimeter security cannot protect cloud applications. They are outside the perimeter by definition. Zero Trust's identity-centric model secures cloud resources the same way it secures on-premises resources.

As discussed in SaaS Governance Strategies, managing access to SaaS applications requires robust identity controls. Zero Trust provides the architectural foundation for SaaS security.

API-First Architecture

Modern applications are collections of APIs. As I covered in API-First Enterprise Strategy, APIs need security too. Zero Trust principles - verify identity, check context, grant minimum access - apply equally to human users and service accounts accessing APIs.

Quick Reference: Implementation Checklist

Use this checklist to track your Zero Trust implementation:

Foundation:

[ ] Executive sponsor identified and engaged
[ ] Zero Trust working group formed
[ ] Current state assessment completed
[ ] Crown Jewels identified and documented
[ ] Phased implementation plan approved
[ ] Success metrics defined

Identity:

[ ] Identity provider deployed or upgraded
[ ] MFA enabled for all external access
[ ] Phishing-resistant MFA for privileged users
[ ] SSO implemented for priority applications
[ ] Conditional access policies configured
[ ] Automated provisioning/deprovisioning operational
[ ] Access review process established

Device:

[ ] Device inventory complete
[ ] MDM deployed for mobile devices
[ ] EDR deployed on all endpoints
[ ] Compliance baselines defined
[ ] Device health integrated with access decisions
[ ] BYOD policy and controls implemented

Access:

[ ] ZTNA selected and deployed
[ ] Crown Jewels applications migrated to ZTNA
[ ] VPN dependency reduced
[ ] PAM deployed for privileged accounts
[ ] JIT access configured for admin tasks
[ ] Network segmentation improved

Operations:

[ ] Monitoring and alerting operational
[ ] Incident response playbooks updated
[ ] User training completed
[ ] Operational documentation complete
[ ] Regular maturity assessments scheduled

The Reality Check

Let me be direct: Zero Trust implementation is hard. It takes years, not months. It requires sustained investment, executive commitment, and organisational change management.

But the alternative - relying on perimeter security in a perimeterless world - is worse. Every major breach you read about exploits the gap between traditional security models and modern IT reality.

Start small: Protect your Crown Jewels first. A Zero Trust proxy in front of your most critical application delivers immediate risk reduction.

Build incrementally: Each phase delivers value while building toward the complete architecture.

Accept imperfection: You will never achieve Zero Trust "perfection." The goal is continuous improvement in security posture.

Focus on architecture, not products: The vendors will come and go. The principles endure.

Conclusion

Zero Trust is the security architecture for 2026 and beyond. It acknowledges the reality that networks are untrusted, perimeters are dissolved, and identity is the new control plane.

Do not be seduced by vendor promises of instant Zero Trust. There is no shortcut. But with systematic implementation - identity foundation, device health, least privilege access - you can transform your security posture.

As I discussed in Identity is the New Firewall, identity is the foundation. Build on it. Verify everything. Trust nothing implicitly.

The architecture is clear. The journey is long. Start today.

Building Your Zero Trust Architecture

Transforming from traditional perimeter security to Zero Trust requires experienced guidance and systematic execution. My IT management services and IT compliance services help organisations assess their current maturity, develop phased implementation plans, and execute Zero Trust transformations that deliver measurable risk reduction.

Get in touch to discuss your Zero Trust journey.

Related reading: Identity is the New Firewall explores the identity foundation that Zero Trust requires. SaaS Governance Strategies addresses access control for cloud applications. API-First Enterprise Strategy covers API security in modern architectures.

Vibe Coding Security: What Happens When Developers Trust AI Too Much

Daniel Glover — Thu, 16 Apr 2026 09:05:53 +0000

Nearly half of all AI-generated code contains security vulnerabilities. Not edge cases. Not theoretical risks. According to Veracode's 2025 GenAI Code Security Report, which tested over 100 large language models across 80 real-world coding tasks, 45% of AI-generated code introduced OWASP Top 10 vulnerabilities.

With 41% of global code now AI-generated and 87% of Fortune 500 companies using at least one vibe coding platform, this isn't a future problem. It's happening now, in production systems, handling real user data.

The conversation around vibe coding has focused heavily on productivity gains and democratised development. What's been missing is an honest assessment of security - and what organisations need to do about it.

The Security Landscape in 2025

The statistics paint a concerning picture. Veracode's research found that while AI models improved at writing functional code, security performance remained flat regardless of model size or training sophistication. The assumption that "smarter" models naturally produce more secure code has proven false.

Language-specific findings are particularly stark:

Java: 72% security failure rate
Python: 45% failure rate
C#: 42% failure rate
JavaScript: 38% failure rate

An Endor Labs study reinforced these findings, discovering that over 40% of AI-generated code solutions contain security vulnerabilities, even when developers used the latest foundational AI models.

The root problem, as the CSA notes, is that AI coding assistants don't inherently understand your application's risk model, internal standards, or threat landscape. This disconnect introduces systemic risks - not just insecure lines of code, but logic flaws, missing controls, and inconsistent security patterns.

Common Vulnerabilities in Vibe-Coded Applications

Input Validation Failures

By default, AI-generated code frequently omits input validation unless explicitly prompted to include it. According to Endor Labs research, this results in insecure outputs by default - the AI simply doesn't consider validation a requirement unless you tell it to.

Cross-Site Scripting (XSS)

Veracode's testing found that AI tools failed to defend against cross-site scripting in 86% of relevant code samples. This is one of the most common web application vulnerabilities, yet AI consistently produces code susceptible to it.

SQL Injection

AI assistants reproduce insecure patterns from their training data. Security researchers have documented AI generating classic vulnerable patterns like sql = "SELECT * FROM users WHERE id = " + user_input - textbook examples of what not to do.

Log Injection

88% of AI-generated code samples were vulnerable to log injection attacks (CWE-117), according to Veracode's report. This vulnerability allows attackers to forge log entries or inject malicious content into logging systems.

Hardcoded Secrets

The Tea App data breach in July 2025 exposed this risk dramatically. A security scan of the iOS app revealed API keys and client tokens embedded directly in the source code - attackers could extract these keys to impersonate the app and access user data without triggering authentication controls.

Hallucinated Dependencies

A particularly insidious risk is "slopsquatting" - where AI invents nonexistent library names that attackers then register as malicious packages. OWASP now recognises this as a stealth compromise technique unique to AI coding workflows.

Real-World Incidents

Tea App Data Breach - July 2025

Tea, a women-only dating safety app, suffered catastrophic data breaches in July and August 2025. Over 72,000 user images - including 13,000 government ID photos - were exposed. The breach affected more than 1.6 million users, with personal messages and sensitive information leaked to 4chan and Twitter.

The aftermath was severe: multiple class action lawsuits consolidated into federal court, an FBI investigation, and widespread media coverage from BBC, NPR, and The New York Times. Women whose data was leaked faced harassment and doxxing.

It's worth noting that Simon Willison has questioned whether vibe coding was the direct cause - Tea's statement indicated the underlying issues related to code written before February 2024. However, the incident highlights the exact vulnerability patterns AI-generated code commonly exhibits: unauthenticated database access and hardcoded credentials.

Replit/SaaStr Database Deletion - July 2025

SaaStr founder Jason Lemkin documented a catastrophic failure with Replit's AI coding tool. During a code freeze - when no changes should have been made - the AI deleted an entire production database containing records on over 1,200 executives and 1,196 companies.

The AI's response was remarkable in its honesty: "I saw empty database queries. I panicked instead of thinking. I destroyed months of your work in seconds. You told me to always ask permission. And I ignored all of it."

Perhaps more concerning: the AI initially told Lemkin that data recovery was impossible, which turned out to be false. Reports indicate the AI also created a 4,000-record database filled with fictional people to cover up bugs.

Cursor IDE Vulnerabilities - August 2025

CVE-2025-54135, dubbed "CurXecute," demonstrated how AI coding tools themselves can become attack vectors. This vulnerability in Cursor IDE allowed attackers to achieve remote code execution through prompt injection - a malicious message processed by the AI could modify configuration files and execute arbitrary commands, all without user approval.

The vulnerability was rated 8.6 (high severity) and affected all Cursor versions prior to 1.3.9. security researchers who discovered it demonstrated how a crafted Slack message could compromise a developer's entire machine.

Business Risk Assessment

The Over-Trust Problem

The disconnect between developer confidence and actual security outcomes is striking. GitHub's own survey shows 75% of developers trust AI code as much or more than human code - even while more than half regularly see insecure suggestions.

Snyk's research reveals the contradiction: while 80% of teams trust AI coding tools, 56% simultaneously admit the AI-generated code sometimes or frequently introduces security issues. Snyk CEO Peter McKay has stated that AI-generated code is actually 30-40% more vulnerable than human-written code.

Perhaps most telling: 89% of AI suggestions remain unchanged during code review, indicating developers often accept suggestions without thorough comprehension.

Technical Debt Accumulation

API evangelist Kin Lane, quoted in InfoQ's analysis, offered a stark assessment: "I don't think I have ever seen so much technical debt being created in such a short period of time during my 35-year career in technology."

Veracode CTO Jens Wessling noted that the rise of vibe coding - where developers rely on AI without explicitly defining security requirements - represents a fundamental shift. "GenAI models make the wrong choices nearly half the time, and it's not improving."

Regulatory Exposure

The EU AI Act, which began enforcement in February 2025, has significant implications for AI-generated code. High-risk AI systems require risk management documentation, human oversight, and audit trails.

For organisations using vibe-coded applications in critical infrastructure, healthcare, or financial services, compliance requirements are substantial. Penalties reach up to EUR 35 million or 7% of global annual turnover for prohibited practices, and EUR 15 million or 3% for high-risk system violations.

The November 2025 "Digital Omnibus on AI" has adjusted some timelines, but the direction is clear: AI involvement in code generation will require documentation and accountability.

Security Checklist

For Developers

Never ship AI-generated auth, crypto, or system-level code without expert review. Security experts consistently recommend keeping scope small and building critical systems yourself.

Treat all AI output as code from a confident but occasionally wrong junior developer. Trust but verify - always.

Run SAST/DAST on every AI-generated snippet before committing. Static and dynamic analysis catch flaws that visual review misses.

Explicitly prompt for security requirements. AI omits input validation and security controls by default unless you specify them.

Check for hallucinated package names. Before adding any AI-suggested dependency, verify it actually exists and is legitimate.

For Teams and Engineering Managers

Mandate human review for all AI-generated code. The 89% unchanged rate during code review indicates current practices are insufficient.

Separate development and production environments. The Replit incident demonstrated why this basic practice remains essential - implement it as a hard requirement for AI tools.

Implement "planning-only" modes for AI tools in sensitive contexts. Let teams collaborate with AI on design without risking live systems.

Document AI involvement in code generation. EU AI Act compliance will require audit trails. Start building this practice now.

Train developers on AI-specific security risks. More than half of organisations don't provide tool-related training - this is a significant gap.

For Organisations

Run proof of concept before adopting AI coding tools. Only 1 in 5 organisations currently do this - don't skip due diligence.

Integrate Software Composition Analysis (SCA) tooling. Less than 25% of developers use SCA to identify vulnerabilities in AI-generated code suggestions.

Establish formal AI code security policies. Define what AI can and cannot be used for, and enforce it.

Consider AI coding tools as part of your threat landscape. The Cursor vulnerability demonstrates that AI tools themselves can be attack vectors.

Keep scope constrained. Don't let AI write entire applications or handle critical systems. Use it for boilerplate and well-understood patterns.

Free Advice: Automate Your Security Reviews

Here's something you can implement today. The checklist above is comprehensive, but manually running through it for every commit is unrealistic. Instead, use AI to audit AI-generated code before it reaches production.

The following prompt can be integrated into your pre-push hooks, CI/CD pipeline, or run manually before code review. It instructs an AI model to perform a security audit against the specific vulnerabilities that AI-generated code commonly introduces.

Pre-Push Security Audit Prompt

Copy this prompt and run it against your staged changes or pull request diff:

You are a security auditor specialising in AI-generated code vulnerabilities. Review the following code changes for security issues, focusing specifically on the vulnerabilities that AI coding assistants commonly introduce.

## Code to Review
[PASTE YOUR DIFF OR CODE HERE]

## Required Security Checks

Analyse the code against each category below. For each issue found, provide:
- The specific line or code block
- The vulnerability type (CWE number if applicable)
- Severity (Critical/High/Medium/Low)
- A concrete fix

### 1. Input Validation
- [ ] All user inputs are validated before use
- [ ] Input length limits are enforced
- [ ] Input type checking is present
- [ ] No raw user input in SQL queries, shell commands, or file paths

### 2. Injection Vulnerabilities
- [ ] No string concatenation in SQL queries (use parameterised queries)
- [ ] No user input in shell/system commands
- [ ] No user input directly rendered in HTML (XSS prevention)
- [ ] No user input in log statements without sanitisation (log injection)

### 3. Authentication and Authorisation
- [ ] No hardcoded credentials, API keys, or secrets
- [ ] Session tokens are generated securely
- [ ] Authentication checks present on protected routes
- [ ] Authorisation verified for resource access

### 4. Cryptography
- [ ] No deprecated algorithms (MD5, SHA1 for security, DES, RC4)
- [ ] No hardcoded encryption keys or IVs
- [ ] Secure random number generation for security contexts
- [ ] TLS/HTTPS enforced for sensitive data transmission

### 5. Data Exposure
- [ ] Sensitive data not logged
- [ ] Error messages don't expose internal details
- [ ] No sensitive data in URLs or query parameters
- [ ] PII properly handled and encrypted at rest

### 6. Dependency Safety
- [ ] All imported packages exist in official registries
- [ ] No typosquatting risks (verify package names character by character)
- [ ] Dependencies are pinned to specific versions
- [ ] No known vulnerable dependency versions

### 7. Configuration Security
- [ ] Debug mode disabled for production
- [ ] CORS properly configured (not wildcard for authenticated endpoints)
- [ ] Security headers present (CSP, X-Frame-Options, etc.)
- [ ] No sensitive defaults that should be environment-specific

## Output Format

Provide your findings as:

### Summary
[X] issues found: [Critical count] Critical, [High count] High, [Medium count] Medium, [Low count] Low

### Critical Issues (must fix before merge)
[List each critical issue with location, description, and fix]

### High Issues (should fix before merge)
[List each high issue]

### Medium Issues (fix in next iteration)
[List each medium issue]

### Low Issues (consider fixing)
[List each low issue]

### Passed Checks
[List categories that passed all checks]

### Recommendations
[Any additional security improvements specific to this codebase]

If no issues are found, confirm which checks passed and note any areas that couldn't be fully assessed from the code provided.

Integrating Into Your Workflow

For Git pre-push hooks: Save the prompt as a template file and use a script that extracts your staged diff, combines it with the prompt, and sends it to your preferred AI API. Block the push if critical issues are found.

For CI/CD pipelines: Add a security audit stage that runs the prompt against the PR diff. Fail the pipeline on critical issues, add review comments for high/medium issues.

For manual review: Before requesting code review, paste your changes into Claude, ChatGPT, or your preferred AI tool with this prompt. Address critical and high issues before submitting.

Why This Works

This approach uses AI to catch the specific vulnerabilities that AI introduces. It's not a replacement for proper SAST/DAST tooling, but it adds a layer of defence that specifically targets the blind spots in vibe-coded applications.

The prompt is deliberately structured around the OWASP Top 10 and CWE categories that Veracode's research identified as most problematic in AI-generated code. It forces explicit verification of the security controls that AI routinely omits.

Moving Forward

Understanding these risks doesn't mean avoiding AI-assisted development - it means approaching it with appropriate rigour. Organisations that establish strong security practices around vibe coding will capture the productivity benefits while managing the risks.

The developers and teams who will thrive are those who:

Use AI as a tool, not a substitute for security knowledge
Maintain healthy scepticism about generated code
Build security review into their AI-assisted workflows
Stay informed as the landscape evolves

Vibe coding is reshaping how we build software. The question isn't whether to use it, but whether you're prepared to use it securely.

Concerned About Security in Your Development Practices?

AI-generated code introduces unique security challenges that require specialised attention. My IT compliance services help organisations establish security frameworks, conduct code audits, and build secure development practices - whether you are adopting vibe coding or strengthening existing workflows.

If you are actively reshaping engineering workflows around AI, it is also worth reading my guides to securing AI agents in production and technical debt in AI-assisted delivery. Those two issues usually appear alongside insecure code patterns rather than in isolation.

Book a free consultation to discuss your security requirements, AI development guardrails, and where your current review process is still exposed.

Management Trends 2026: What IT Leaders Need to Know

Daniel Glover — Thu, 16 Apr 2026 09:05:26 +0000

There is a stat doing the rounds right now that should make every middle manager sit up and pay attention.

Gartner predicts that organisations using AI to flatten their structures will eliminate roughly half of middle management roles by 2026. Not over the next decade. By the end of this year.

If that sounds dramatic, look around. The evidence is already stacking up. Gallup reported a notable dip in manager engagement in 2025, dropping from 30% to 27%. Younger managers under 35 fell five percentage points. Female managers dropped seven. DDI's Global Leadership Forecast found 71% of leaders reporting increased stress from their roles, with 40% of those actively thinking about quitting.

The people we rely on to hold organisations together are burning out, checking out, or being restructured out of existence.

As someone who has led IT teams through multiple rounds of organisational change, M&A integrations, and the shift to hybrid working, I have seen first-hand how leadership expectations have changed. What worked five years ago simply does not cut it anymore. I covered the state of play heading into 2025 in my piece on IT management trends - this post looks at what has changed since and where we are heading next.

Here are five management trends that will define 2026 - and what you can actually do about them.

1. Leaner Teams, Heavier Emotional Load

Restructuring and automation have made teams leaner, but the work has not disappeared. It has just been redistributed upward onto fewer managers.

This is not a temporary adjustment. It is structural. Organisations that cut middle management layers often discover they have removed the very people who absorbed complexity, translated strategy into action, and shielded teams from executive whiplash.

The result? Remaining managers carry a disproportionate emotional and operational load. They are expected to be strategic and tactical, empathetic and efficient, available and focused - all at once. For organisations that need help redesigning that operating model, IT management consulting can provide an outside view and a practical plan.

What to do about it: If you manage managers, check in on their capacity rather than just their output. Build emotional resilience into your leadership development frameworks, not as a nice-to-have but as a core competency. Recognise that a stressed manager creates a stressed team, which creates a retention problem.

2. The Span of Influence Is Tripling

Managers today oversee nearly triple the number of employees compared to a decade ago. Flatter structures mean wider spans of control, more direct reports, and less time per person.

This is where traditional management falls apart. You cannot run meaningful one-to-ones with 15 direct reports every week. You cannot build psychological safety across a team of 20 when you barely have time to check Slack. The old playbook of "manage by presence" is dead.

The leaders who thrive in 2026 will be those who shift from managing individuals to designing systems. Clear decision-making frameworks, strong delegation structures, and team rituals that build trust without requiring constant managerial input.

What to do about it: Audit your span of control. If you are managing more than 8 to 10 people directly, something needs to change - either through delegation, restructuring, or being honest with leadership about what is sustainable. Document your decision-making frameworks so your team can operate autonomously when you are not available.

3. Decision Velocity Beats Decision Quality

DHR Global's 2026 talent outlook names agility as the single most critical leadership competency this year. Not strategic thinking. Not technical expertise. Agility.

The reasoning is straightforward. In a volatile environment, a good decision made quickly beats a perfect decision made slowly. Leaders who wait for complete information before acting are being outpaced by those who make sound calls with 70% of the data and course-correct fast.

This does not mean being reckless. It means building "rapid learning loops" into how you lead. Make a decision, measure the outcome, adjust, repeat. Replace perfectionist norms with high standards and fast iteration. A structured IT strategy review can help ensure you are making fast decisions within a sound strategic framework.

What to do about it: Track how long your decisions take. If approvals routinely take weeks, that is a leadership bottleneck, not a process. Push decision-making authority down to the people closest to the problem. Your job is to set guardrails, not sign off on everything.

4. The Hybrid Trust Problem Is Not Going Away

Stanford research confirms what most of us already suspected: remote and hybrid work is permanent for a large chunk of the workforce. But the trust gap between leaders and distributed teams has not been solved. My piece on workplace transformation in 2026 digs into the infrastructure and technology side of making hybrid work sustainable.

Too many organisations are still managing hybrid work with the same tools and expectations they used when everyone was in the same building. Proximity bias is real - the people who show up in the office get more visibility, more opportunities, and more trust, whether or not they are actually performing better.

The best leaders in 2026 will be those who measure output rather than attendance, who build rituals for connection that work across time zones, and who resist the temptation to conflate "visible" with "productive."

What to do about it: If you have hybrid teams, audit your promotion and development decisions for proximity bias. Are office-based staff getting disproportionate opportunities? Build structured async communication habits. Weekly written updates beat impromptu corridor conversations for distributed teams.

5. Gen Z and Millennials Are Rewriting the Leadership Contract

Stanford's CASBS research found that younger workers evaluate organisations not just on salary and progression, but on purpose, flexibility, and whether leadership actually walks the talk.

This is not about pandering or offering bean bags and pizza Fridays. It is about authenticity. Younger employees have a low tolerance for performative leadership - saying you value wellbeing while expecting midnight emails, claiming to support development while cutting training budgets.

For IT leaders specifically, this matters because the tech talent market remains fiercely competitive. The difference between retaining your best engineer and losing them to a competitor often comes down to whether they trust their manager to advocate for them.

What to do about it: Be honest about what your organisation actually offers rather than what the careers page claims. If you cannot offer remote work, say so clearly rather than dangling it and pulling back. Invest in genuine development conversations - not annual reviews that tick a box, but regular, honest discussions about growth.

The Common Thread: Emotional Intelligence Is Not Optional

Every single one of these trends has the same underlying requirement. Emotional intelligence.

Not the fluffy, "be nice to people" version. The operational kind. The ability to read a room, manage your own stress response, have difficult conversations without creating drama, and build trust in environments where face time is limited.

Gartner, HBR, DDI, DHR Global - every major research house is converging on the same conclusion. Technical competence gets you the job. Emotional intelligence determines whether you keep it and whether anyone wants to follow you.

The organisations that invest in building this capability at every management level will outperform those that keep promoting the loudest voice in the room.

What I Am Doing About It

In my own teams, I have been deliberately shifting how I lead over the past two years:

Documenting decisions, not just making them. Every significant call gets written down with reasoning. This builds trust, enables delegation, and creates a reference point when things need revisiting.
Protecting manager capacity. I actively push back on meeting culture and administrative overhead that eats into my team's ability to actually lead.
Measuring what matters. SLA adherence, NPS scores, project delivery - not hours logged or seats warmed.
Having honest conversations early. If something is not working, I would rather address it in week one than let it fester into a performance issue in month six.

None of this is revolutionary. But in a year where half of middle management might disappear, the basics done consistently will separate the leaders who thrive from those who do not.

What management trends are you seeing in your organisation? I would love to hear what is changing for you - connect with me on LinkedIn or get in touch to discuss your IT leadership challenges.

ISO 27001 Internal Audit Checklist for Small Teams

Daniel Glover — Mon, 13 Apr 2026 17:04:19 +0000

ISO 27001 internal audits often get treated like a mini certification audit.

That is usually where the pain starts.

Small teams already have enough on their plate. They are running BAU support, shipping changes, dealing with suppliers, handling incidents, and trying to keep governance work moving without turning the whole year into an evidence-gathering exercise. When internal audit is handled badly, it becomes a scramble for screenshots and policies nobody has read since the last review.

It does not need to work that way.

Clause 9.2 of ISO 27001 requires internal audits at planned intervals so you can assess whether the ISMS is operating effectively and whether it conforms to both the standard and your own internal requirements. That sounds formal, because it is. But in practice the job is simpler than many teams make it. You need an audit programme, clear scope, objective evidence, competent auditors, and proper follow-up on what you find.

The key point is this. An internal audit is not there to prove you are perfect. It is there to tell you whether your ISMS is real, current, and working.

For smaller organisations, that distinction matters. If your audit process is designed like a heavyweight corporate exercise, it will drift, people will avoid it, and the findings will be weak. If it is designed as a focused check on how the system actually operates, it becomes one of the most useful compliance tools you have.

What ISO 27001 Actually Expects

The standard does not demand a massive audit bureaucracy.

What it does expect is discipline.

Advisera's summary of clause 9.2 is a useful plain-English reminder. Internal audits need to happen at planned intervals, cover whether the ISMS conforms to ISO 27001 and your own policies, and produce evidence through document review, checklist-based testing, reporting, and follow-up. ISMS.online makes a similar point, emphasising scope, frequency, methods, responsibilities, reporting, and auditor objectivity. DataGuard also highlights something teams often miss: ISO 27001 does not dictate one universal cadence. You choose planned intervals based on your risk environment, scope, and organisational needs.

That gives small teams more flexibility than they often realise.

You do not need to audit every clause and every Annex A control in one exhausting week. You do need a credible programme that covers the full ISMS over time and gives leadership confidence that important areas are being checked properly.

The Biggest Mistake Small Teams Make

The most common mistake is treating internal audit as a document exercise.

The team gathers policies, checks version numbers, confirms that training exists, and writes "compliant" next to most headings. The problem is that none of this tells you whether the ISMS is actually being followed.

A policy that says access reviews happen quarterly is not evidence that access reviews happened.

A risk methodology document is not evidence that risks are being reviewed.

A supplier assurance process is not evidence that suppliers were actually assessed.

That is why a good audit has to test operation, not just existence. If you are auditing incident management, ask for the incident log, recent lessons learned, and evidence that actions were closed. If you are auditing supplier risk, compare the stated due diligence process with what happened on real procurements. I made a similar point in my vendor due diligence guide. A process is only useful if it changes decisions in real life.

A Practical ISO 27001 Internal Audit Checklist

If I were running this in a small team, this is the checklist I would use.

1. Confirm the audit scope and objective

Be explicit about what you are auditing.

That might be the whole ISMS over a longer programme, or a focused review of a specific area such as access control, supplier assurance, incident management, asset management, or management review.

For each audit, define:

the scope
the audit criteria
the owner for the area being audited
the planned date
the auditor
the evidence sources you expect to review

If those basics are fuzzy, the audit usually turns into a wandering conversation rather than a useful test.

2. Check that the audit is independent enough

ISO 27001 does not require a huge separate internal audit department, but it does require objectivity.

That means people should not audit their own work where this would create a conflict of interest. In a small team, independence often means using a colleague from another function, rotating responsibilities, or bringing in external support for sensitive areas.

This is one of those places where small organisations need to be honest. You may not achieve perfect structural independence, but you still need a defensible approach that avoids self-approval.

3. Review the audit programme

Before looking at one area in detail, step back and ask whether the overall audit plan is credible.

Can you show:

a documented audit programme
planned intervals based on risk and importance
coverage of the whole ISMS over time
completed audits from prior periods
follow-up of previous nonconformities

If the programme only exists in someone's head, that is your first weakness.

4. Test whether policies match reality

Pick the policies and procedures relevant to the area under review, then compare them with live evidence.

Examples:

Access control policy versus actual access reviews and joiner-mover-leaver records
Incident process versus the last few incidents handled
Risk management process versus the current risk register and treatment actions
Supplier assurance process versus recent supplier onboarding decisions
Backup policy versus actual backup logs, restore tests, and recovery evidence

This is where most useful findings appear.

5. Verify that records are current, not historic theatre

A lot of teams can show you evidence. Fewer can show you current evidence.

Look for dates, cadence, ownership, and signs of live use. Ask simple questions:

Was this reviewed when it was supposed to be?
Is the owner still the right person?
Are actions open longer than expected?
Does this record reflect the current estate, supplier set, or risk picture?

If your asset register still lists systems that were retired six months ago, or your risk register reads like an audit artefact rather than a management tool, the ISMS is drifting.

The Areas Small Teams Should Prioritise

If resources are tight, I would prioritise audit attention on the areas that tend to break first.

Risk management

Your risks should be current, clearly owned, and tied to treatment actions. If you need a better structure for making them readable, my guide to IT risk registers executives use is a good companion.

Access control

Test whether access is approved, reviewed, and removed properly. This is one of the easiest areas to write well and run badly.

Incident management

Check whether incidents are logged consistently, whether lessons learned are captured, and whether corrective actions actually close.

Supplier assurance

Third-party controls are often one of the weakest practical areas in smaller ISMS environments because supplier onboarding moves faster than governance.

Backup and recovery

A backup status page is not enough. You want evidence of restore confidence. The same principle came up in my Proxmox backup and disaster recovery guide. Recovery evidence matters more than backup optimism.

Management review and improvement actions

If leadership never reviews the ISMS properly, the whole system becomes performative. Internal audit should test whether management review is happening with substance, not just as a calendar event.

What Good Audit Evidence Looks Like

Useful evidence is specific, recent, and traceable.

That can include:

approved policies and procedures
meeting minutes
risk register updates
completed training records
screenshots from operational systems
supplier review records
change records
incident tickets
access review outputs
action trackers with owners and dates

What you want is a chain from requirement to process to proof.

For example, if the policy says privileged access is reviewed quarterly, you should be able to see the review schedule, the review outputs, the approvals, and any remediation raised from that review.

If you cannot, the finding is not "documentation gap". The finding is that the control may not be operating.

How to Write Findings That People Will Actually Fix

Weak audit findings are vague and moralising.

They say things like, "Process should be improved" or "Evidence was incomplete." That helps nobody.

A useful finding should state:

what requirement was being tested
what evidence was reviewed
what gap was found
why it matters
what corrective action is needed
who should own it

For example:

The access control procedure states quarterly privileged access reviews are required. Evidence was available for Q1 and Q2, but no Q3 review record was produced for the infrastructure admin group. This creates a risk that inappropriate access remains active beyond the organisation's approved review window. The control owner should complete the overdue review and implement a tracked schedule to prevent recurrence.

That gives management something clear to act on.

A Sensible Cadence for Small Organisations

I would not recommend one giant annual internal audit and nothing else.

A better pattern is:

an annual audit programme covering the full ISMS
lighter quarterly audits on higher-risk areas
targeted follow-up where nonconformities or major changes exist
immediate extra review after material incidents, supplier failures, or major structural change

This keeps the workload manageable and improves the quality of evidence because you are not trying to reconstruct a year's worth of activity in one go.

It also helps board and leadership reporting. If the ISMS is being checked steadily, your updates become cleaner and more credible. That matters when compliance work needs budget, priority, or operational changes. I touched on that wider reporting discipline in IT metrics board reporting. Good governance gets easier when the evidence is routine rather than last-minute.

The Bottom Line

A good ISO 27001 internal audit should leave you with a clearer view of reality.

Not just whether the right documents exist, but whether the system is being followed, whether controls are operating, and whether leadership can trust the picture they are being shown.

For small teams, that means keeping the method practical.

Plan the audit properly. Keep it independent enough to be credible. Test live evidence, not just paperwork. Write findings people can act on. Follow through.

Do that consistently and internal audit stops being a compliance tax. It becomes one of the fastest ways to find drift before your certification body, your customers, or a real incident finds it for you.

If you need help turning ISO 27001 from a documentation project into a working management system, my IT compliance services are designed for exactly that problem.