This blog captures the key themes from the launch event of Technically Speaking, Audacia's new podcast - held as part of Leeds Digital Mini Festival.
Technology and security leaders from financial services, government and software came together to explore the 'Human Problem' in cybersecurity. Chaired by Philip White, Managing Director at Audacia, with panelists Rob Devany (Leeds Building Society), Nayza Fioritta Neves Ferro (Lhasa), Jennifer Anderson (National Wealth Fund) and Richard Brown (Audacia). The views here reflect the collective discussion rather than any single individual or organisation.
Cybersecurity has topped the CIO priority list for four consecutive years. Budgets have grown, frameworks have matured and security tooling has never been more advanced. However, the data tells a consistent story: between 68% and 95% of data breaches involve a human element, and 66% of CISOs say their greatest vulnerability is still people – whether that's through a compromised credential, a phishing click or a misconfigured system.
Start with Risk Appetite
The starting point for any security programme should be a conversation at board level about what level of risk the organisation is willing to accept.
Different organisations will have different risk appetites; a government body managing critical infrastructure funding has a very different threat profile to a fintech operating under competitive delivery pressure. The important thing is that everyone understands and agrees with the defined appetite.
A common failure of communication is what practitioners call the "watermelon" problem: green on the outside, red on the inside. An organisation declares a robust risk stance at board level, but day-to-day behaviour doesn’t align. The danger is that this misalignment falls hardest on whoever is accountable for security - when something goes wrong, the declared appetite and the actual practice are suddenly at odds.
Coordinating risk posture and everyday actions means going beyond a headline position and working through what the agreed appetite looks like in practice: how data is shared, how suppliers are granted access and what employees can and can't do on company devices. These operational details are what gives the policy meaning.
Internal Threats, External Threats and the Supply Chain Problem
Practitioners tend to think about their threat landscape in two buckets: internal threats and external threats. Both require active management, and the discipline of RAG-rating each area against a clear framework helps boards understand the current position without drowning in technical detail.
Supply chain sits uncomfortably across both; a third-party supplier with access to internal systems is an internal risk managed through an external relationship. Organisations need effective security controls in place with suppliers, even when delivery timelines create pressure to cut corners. One approach is to issue suppliers with managed virtual environments rather than allowing them to connect from their own hardware.
For software development teams, the harder problem is open source. It is practically impossible to formally vet every dependency in a modern codebase, and yet open source is foundational to how software gets built. One counter-intuitive shift is in how teams handle dependency updates. For years, applying updates immediately was considered good practice but that assumption no longer holds. Threat actors have learned to inject malicious code into open-source packages and push them as updates, meaning a developer who patches on day one may be the first to pull compromised code into their codebase. Tools like Dependabot now support cool-down windows, giving security vendors time to identify and flag suspicious packages before they reach production.
There is also a simpler lever that gets less attention: reducing the number of dependencies in the first place. Every library added to a codebase is a maintenance commitment and a potential attack surface. In an era when AI can generate functional code quickly, the case for pulling in an external package to handle something straightforward is weaker than it used to be. If the function is stable and well-understood, writing and owning it directly can be the more defensible choice. The JavaScript ecosystem has long illustrated what the opposite looks like - deep dependency trees where a single unmaintained package can cause widespread disruption.
The broader principle is visibility. Knowing exactly what your software estate contains - through practices like maintaining a software bill of materials (SBOM) - means that when a vulnerability is disclosed, organisations can pinpoint their exposure immediately rather than working backwards through layers of dependencies.
The Human Attack Surface
The most technically sophisticated attack campaigns get significant attention. But the more common scenario is simpler: someone has a distracted afternoon, a link looks plausible and they click it. The breach that follows may not be detected for weeks.
Eliminating human error is impossible, therefore the appropriate response to this is to build enough redundancy into the system that a single mistake doesn't become a significant incident. Two practical approaches are worth prioritising:
Security Operations Centres (SOCs)
24/7 monitoring of an organisation's estate means that suspicious behaviour is caught by the security team before the affected individual realises something has gone wrong. Outsourcing the SOC function is a practical option for organisations that can't sustain it internally.
Self-service incident response
Giving employees a quick, easy way to flag their own mistakes - for example, a one-click option to revoke all active sessions if they suspect they've been compromised - reduces the window of exposure. A culture should be established to reassure employees that if they do make a mistake, reporting it quickly is the right move, and the organisation has the tools to contain the damage.
Why Security Training Usually Fails
Annual compliance-driven security training has become a standard fixture in most organisations. Its impact on actual incident rates is harder to demonstrate. A useful exercise is to consider whether the number of security incidents would change if the training programme were removed entirely. For many organisations, the impact would be negligible.
What seems to work better involves several shifts:
- Frequency over volume: Bite-size monthly content has more lasting effect than an annual session.
- Personas over policies: Training built around realistic, role-specific scenarios has a greater impact than generic guidance.
- Peer storytelling: When someone in the team shares a near-miss in their own words the message can carry more weight than top-down instruction. This can look like making real, anonymised examples a regular part of team meetings.
- Culture over compliance: Physical security is a useful illustration: when teams stop thinking of locking up the office as a "security task" and start thinking of it as helping their colleagues, behaviour changes in a way that no policy document achieves.
The framing shift should be that security isn't something the IT team does to protect the organisation from its own employees. It's embedded culturally as something everyone contributes to.
AI Is Changing the Threat Landscape
AI is shifting the cybersecurity problem in two directions at once.
On the threat side, social engineering attacks are becoming harder to detect. Phishing emails that once had obvious tells such as poor grammar, generic greetings and implausible pretexts, now pass convincingly as legitimate communications. At the same time, the volume is increasing and the targeting is more precise. Overall, the human attack surface is being exploited more efficiently.
On the development side, the volume of AI-generated code entering production is creating a new category of risk. Frontier technology companies are now shipping thousands of code changes per week written entirely by AI. Most organisations won't move at that pace, but it’s clear that AI is becoming a standard part of the development workflow, and the security implications of that haven't been fully worked through.
The practical answer is to make sure the foundations that make safe, fast change possible are already in place. In a human sense this means equipping teams with the right skills; developers need to understand how to use AI tooling effectively, including what to verify and what still requires human judgement. In terms of technology: automated testing, CI/CD pipelines, static analysis and code review processes, are the guardrails that determine whether AI-generated code is an accelerant or a liability. Teams without these foundations will simply move faster in the wrong direction.
However, the same AI capabilities making attacks harder to detect are also being applied defensively. Security teams are using AI to identify anomalies, accelerate threat detection and work through vulnerability data at scale.
The Pace-of-Change Paradox
One of the more counter-intuitive tensions in modern security practice is whether the risk of changing too slowly is now greater than the risk of changing too fast.
For example, delaying the adoption of a new tool - an AI assistant, a cloud service, a development platform - because of security due diligence processes can push teams towards workarounds. Those workarounds sit outside the visibility and control of the security function. The organisation ends up less secure than if it had moved faster and managed the risk through proper channels.
Rather than rushing due diligence, the constructive response is better-leveraged diligence. Many organisations will start research on a new tool from scratch. However, most tools under consideration have already been adopted by comparable organisations. Finding out what they encountered, and what they did about it through peer networks and industry benchmarks is a faster route to a defensible decision than starting anew. The same principle extends beyond tool adoption. The earlier advice to delay dependency updates rather than apply them on day one is an example not of moving too slowly but of better-leveraged diligence in practice.
Three Priorities for Security Leaders
For anyone newly put in charge of cybersecurity in their organisation, three recommendations stand out above the rest:
Focus on people first
Tools and budgets matter, but the most common point of failure is human. Getting people genuinely engaged, not just compliant, tends to deliver more lasting results than technical controls alone.
Know your framework
For those newer to the security function, the National Cyber Security Centre (NCSC) publishes practical, accessible guidance calibrated to organisation size and sector. Starting there, rather than trying to synthesise a position from scratch, is a more reliable foundation.
Build a sounding board
The risk landscape, once you start looking at it seriously, is genuinely overwhelming. Having trusted peers to pressure-test thinking, and to pull focus back to what's within control, is as important as technical knowledge.
Introducing Technically Speaking
Technically Speaking is a new podcast from Audacia, hosted by Technical Director Richard Brown. Each episode is a conversation with a senior technology leader working through the questions shaping modern technology in practice.
In Episode #1, host Richard Brown is joined by Amy De-Balsi, an independent programme manager working in a highly regulated public sector environment, and Adam Brookes, Head of Consulting at Audacia, to explore why AI initiatives so often stall between proof of concept and production, and what it actually takes to close that gap.
Listen now on your preferred platform
If there are topics you'd like to see covered, we'd welcome your input at [email protected]
