It is no secret that AI powered attacks are increasing in volume, speed and sophistication. Gartner’s September 2026 AI Security survey identified that 41% of businesses have reported at least one social engineering incident involving a deepfake on an employee audio call in the past 12 months, and 36% reported the same for a video call. Add into this that Verizon’s 2026 Data Breach Investigations Report, showed 62% of all breaches now involve a human element – someone clicking, trusting, transferring, or simply believing what they were shown or told, means there is a gap between employee knowledge of AI powered cyber attacks and what is actually happening from an attack perspective.

So what does this mean? The attack surface has moved forward in terms of speed and complexity. Cyber-attacks are no longer aimed primarily at your organisations firewall, endpoints, or perimeter. Attackers are focusing their efforts at your people, and they are using artificial intelligence to do it with a level of fluency, speed and personalisation that traditional security awareness training was never built to counter. If your organisation’s answer to this shift in attacker behaviour is still a once-a-year
e-learning module and a simulated phishing email with an obvious spelling mistake, you do not have an awareness programme. You have a compliance artefact, and your board should know the difference.

What senior leaders must prioritise right now

Cyber security budgets are finite, and board attention is scarcer still, so prioritisation is not a small point, it is the discipline that determines whether your security spend actually reduces risk. For organisations with a client-facing, trust-dependent business model the priority must shift from pure technical control to human resilience, and it has to shift now.

That means three things rising to the top of the agenda. First, deepfake recognition, specifically, the ability of staff who handle payments, approvals, or sensitive instructions to recognise and challenge a synthetic voice or video, even when it sounds exactly like their chief executive. Second, recognising that AI-driven phishing – email, SMS and collaboration-platform messages are no longer generic and clumsy, but individually crafted using scraped data about your organisation, your clients and your internal relationships. Third, taking the time to understand behavioural social engineering – the multi-channel, multi-step campaigns that combine a believable pretext with urgency and authority, exploiting workplace norms rather than technical vulnerabilities.

This is not a call to abandon technical controls, email filtering, endpoint detection and identity controls remain essential. It is a call to recognise that technical controls alone cannot stop an attack that is designed, from the outset, to be convincing to a human being. Your focus must widen to include the one layer of your defence that AI has made dramatically harder to trust. Your own judgement, and your people’s.

The situation organisations are actually facing

Look honestly at what has changed in the past year, and the picture is painful. The barrier to entry for convincing impersonation has collapsed. Cloning an executive’s voice from a handful of public clips, or generating a passable video likeness, no longer requires specialist skill or significant cost, it requires motivation and a few minutes with freely available tools. This isn’t just hearsay or scaremongering. The FBI’s Internet Crime Complaint Centre logged its first standalone AI-fraud category in 2025, recording 22,364 complaints and $893.3 million in adjusted losses. A figure that is itself likely an undercount, since many incidents are never reported or never recognised as AI-enabled in the first place.

At the same time, the economics of social engineering have shifted sharply in the attacker’s favour. AI-generated phishing content is cheaper, faster and more targeted to produce than ever before, which means your organisation is not facing occasional, crude attempts. It is facing a sustained, scaling campaign that specifically studies how your business operates before it strikes. Attackers now research your supplier relationships, approval chains, and internal language, then build a pretext that fits precisely inside your normal way of working. That is why so many of these incidents succeed not because an employee was careless, but because the deception was engineered to look exactly like a legitimate, everyday request.

The organisations most exposed are not necessarily the ones with the weakest technology. They are the ones whose culture rewards speed and responsiveness over verification. A client-focused ethos, ironically, can become a vulnerability if staff are never given explicit permission, and practical tools, to pause and challenge an instruction that feels slightly wrong. A finance team trained to be helpful and fast is precisely the team a well-crafted deepfake call is designed to exploit. This is not a failure of character. It is a failure of preparation, and it sits squarely with leadership to correct it.

What a practical, proportionate response looks like

The answer is not a bigger slideshow or more generic security email training. It is a bespoke, continuously evolving training programme built around the specific threat vectors your organisation actually faces, delivered to employees and key stakeholders in a form they will retain under pressure. Because the moment that matters is not during the training session, it is during the call, the email, or the video request itself.

From our experience at Cyberfort, having delivered this type of training to several organisations in recent weeks, we have seen how AI security training requires a genuinely practical programme that does four things which generic, off-the-shelf awareness training does not. It teaches deepfake recognition as a specific, rehearsed skill – what synthetic audio and video actually look and sound like, what verification step to take when something feels urgent or unusual, and crucially, that staff have explicit organisational permission to slow down and check, even when the voice on the line sounds exactly like the finance director for example.

A good AI cyber training programme should build fluency in AI-driven phishing patterns, not spotting typos, but recognising the signs of content that is individually tailored, contextually accurate and emotionally engineered to bypass scepticism. It trains behavioural social engineering awareness across every channel your business uses, not just email, because today’s campaigns move fluidly between email, SMS, collaboration platforms and phone calls within a single attempt. And it should align every one of these elements with your organisation’s own risk-aware culture and client-facing ethos, so the training reinforces how your people already think about trust, rather than fighting against it.

This has to be measured, not assumed. A credible programme includes simulated AI-threat scenarios – realistic, evolving tests rather than static exercises, and clear reporting pathways so that staff who spot something suspicious know exactly where to raise it and feel confident doing so without blame. The organisations seeing the strongest improvement in resilience are the ones treating this as an ongoing capability-building exercise, refreshed as attacker techniques evolve, not a once-a-year box to tick before the next audit.

Why AI security training needs specialist MSSP support

For any organisation considering building this capability in-house it is highly likely that your internal IT or security team almost certainly does not have the specialist expertise, attacker-informed intelligence, or the capacity to design and continuously update AI-threat awareness training to the standard your organisation demands.

This is not a criticism of any IT or Security team. It reflects how fast the threat landscape has moved and how specialised effective countermeasures have become. Deepfake detection, AI-phishing pattern recognition and behavioural social engineering defence are now disciplines in their own right, informed by live threat intelligence that a managed security partner sees across many organisations, not just yours.

A specialist managed security services provider brings three things an internal team struggles to replicate alone when it comes to AI security training:

1. Current, cross-industry visibility into how AI-enabled attacks are evolving right now, rather than how they looked when the training was last written.

2. The capability to design a bespoke programme that reflects your organisation’s specific risk profile, client relationships and operating culture, rather than a generic template.

3. The ongoing commitment to refresh and test that training as the threat landscape shifts, which a one-off internal project is rarely resourced to sustain.

The organisations that treat security awareness as a strategic capability, built and maintained in partnership with a specialist that lives in this threat landscape every day, are the ones that will still be trusted by their clients and their boards when a well-crafted deepfake call eventually reaches their teams. The organisations that treat it as a compliance exercise will find out the hard way that a tick-box training module was never going to stop an attacker who had already done their homework.

The next step is not complicated. It is a conversation about where your people are most exposed. It should cover what your current training actually covers against the threats of 2026 rather than 2022, and what a bespoke programme aligned to your culture and your risk profile would look like in practice. That conversation is worth having before the incident, not after it.

Final thoughts

AI has made deception cheap, fast and personal. Deepfake incidents, AI-written phishing and multi-channel social engineering are now a routine part of the threat landscape your people face every day, not an edge case. A bespoke, continuously refreshed awareness programme, built with a specialist partner who tracks these threats across many organisations, not just yours – is now a board-level resilience decision, not a line item in a training budget.

To find out more about Cyberfort AI security services contact us at [email protected] and one of our experts will be in touch.

Find out more about our AI Security Services Here >

Download the AI Security Readiness Guide >

DORA has been live for over a year, the question for most boards has shifted from “are we ready?” to “can we prove it?” This is the second article in our DORA series, looking at what DORA actually requires, pillar by pillar, and where financial services firms most often find the gap between activity and evidence. In this blog article Cyberfort security experts look at the ICT Risk Management pillar in detail, identifying where many financial services firms have knowledge gaps and provide practical advice on key focus areas to ensure compliance.

Introduction

Most financial services firms believe they have ICT risk under control. They have a security operations centre, a patching cadence, an incident response plan and a long list of technical controls. What many do not have is a documented, board-owned ICT risk management framework that would satisfy a DORA supervisor asking a simple question – ‘show me how the board decided how much ICT risk this organisation is willing to carry, and how you know whether you are within that limit today’.

Under DORA, ICT risk management is not a technology function that reports upwards occasionally, it is a governance obligation that the board owns directly, with the same rigour as credit risk or liquidity risk. If your framework cannot answer that question clearly and with evidence, you have found your starting point, and it is worth understanding exactly why so many otherwise well-run security functions land in the same position.

Operations without governance maturity

Across financial services, the operational side of ICT risk is usually in reasonable shape. Firms run vulnerability management programmes, maintain asset inventories, operate detection and response capability, and can produce evidence of controls when asked. Security teams are not the weak link here.

The weak link is what sits above the operational layer. DORA’s ICT risk management pillar (set out primarily in Articles 5 to 16 of the regulation) asks for something most firms have never had to formalise in this way. A documented risk appetite and tolerance framework, integrated into the wider enterprise risk management system, reviewed annually, and independently validated. Not just referenced in a policy pack but actively used to make and defend decisions.

Why ‘we manage risk well’ is not the same as ‘we can evidence governance’

This is where the ‘so what?’ question usually surfaces. If the operational controls are working, why does the governance layer matter so much?

Because DORA does not ask supervisors, or boards, to take competence on trust. It asks for a defensible chain of evidence:

A stated risk appetite
A classification method applied consistently
Named owners against every material risk
Deadlines that are tracked rather than aspirational
Reporting lines that reach the board risk committee in a form the committee can actually act on.

Most firms have fragments of this. Few have it end to end.

From our experience at Cyberfort we know the practical consequence shows up in three recurring patterns.

First, risk appetite exists informally, as a shared understanding among the security leadership team, rather than as a document the board has approved and can be tested against.

Second, ownership of ICT risks is diffused across IT, security and business units, so when an audit or supervisory review asks who owns a specific residual risk, the answer takes too long to arrive or arrives inconsistently depending on who is asked.

Third, independent validation, someone outside the team that built the framework, checking that it actually works, is thin or non-existent, which means the first real test of the framework is a live incident or a supervisory request, rather than a planned review.

None of this means the underlying security work is bad. It means the governance structure has not caught up with the operational maturity sitting underneath it. DORA is the first regulation to test that gap directly, at board level, with consequences attached.

A practical sequence, not a rewrite

The fix is not a wholesale replacement of what already exists. It is a sequence of four moves that turn existing operational capability into something the board can own and a supervisor can test.

If your organisation is unsure of where to start with the risk management pillar of DORA, the key starting point is with a board-approved risk appetite and tolerance statement. This is the single most valuable document you may not yet have in a defensible form. It should state, in terms the board can genuinely debate and sign off on how much ICT disruption, data loss or service degradation the organisation is prepared to tolerate before it becomes unacceptable, and where those thresholds differ by system criticality. Without this, every subsequent step in the framework has nothing to be measured against.

The second step is to formalise the identification, classification and assessment cycle. Most firms already do this informally and continuously through their security operations. The task is to make the cycle explicit, scheduled and consistently applied, so that every material ICT risk is scored against the same criteria and lands in the same register, rather than being assessed differently depending on which team found it.

Third, assign named owners and real deadlines to every risk mitigation action, and track them the same way you would track a regulatory finding. A mitigation with no owner and no date is not a plan, it is an intention, and intentions are exactly what supervisors’ probe first.

The final step is to build the reporting mechanism that carries all of this to the board risk committee on a fixed cadence, and commission an annual independent review of the framework itself. Not the individual controls, but whether the framework as a whole still reflects how the organisation actually operates. This is the step most often skipped, usually because it requires bringing in a perspective from outside the team that built the framework in the first place.

Taken in that order, this sequence does not require a new team or a new toolset. It requires the board to take formal ownership of decisions that, in most firms today, are still being made informally by security leadership on the board’s behalf.

The KPI’s that matter, and why

It should be noted that DORA itself does not prescribe numeric thresholds for any of the measures below. There is no rule stating a specific closure percentage or a specific number of days. The figures given are directional good-practice targets, reflecting what a mature framework should be capable of, not figures lifted from a named regulatory standard. Set your own thresholds against your risk appetite and the criticality of the function in question.

With that caveat in place, a framework is only as strong as the metrics that prove it is working. Under DORA, the board risk committee needs indicators that speak to governance performance, not just technical performance. From our DORA consultancy work we recommend all financial services organisations track these five KPIs, included in the board reporting pack on a monthly basis.

1. Time to detect and classify a material ICT risk

This matters because DORA’s incident reporting timelines only work if a risk is recognised and classified quickly enough to trigger them. A framework that takes days to classify something that happened in minutes cannot support the reporting obligations built on top of it. Good practice is a classification cycle measured in hours for anything touching a critical or important function, not days, and the board should know what your current cycle is, rather than assuming it is fast.

2. Mitigation closure rate against agreed deadlines

This is the clearest signal of whether ownership and deadlines are real or aspirational. A framework with named owners but a low closure rate tells the board that accountability exists on paper but not in practice. Firms with mature frameworks typically track this above nine in ten mitigations closed on or before their agreed deadline, with any slippage escalated automatically rather than quietly rolled over.

3. Risk register coverage against the critical function inventory

DORA expects risk assessment to extend to every ICT system supporting a critical or important function, not just the systems that are easiest to assess. This metric tells the board whether the register is comprehensive or has blind spots. The benchmark to aim for is full coverage including every system in the critical function inventory represented in the risk register with a current assessment date, and any gap treated as a finding in its own right.

4. Outstanding findings from independent validation

This is the metric that proves the framework has actually been tested by someone other than the people who built it. A high or ageing number of open findings suggests the framework looks sound on paper but has not been stress-tested. Good practice is a validation cycle that closes the substantial majority of findings within the same reporting year they were raised, with any finding still open after two review cycles escalated directly to the board.

5. Reporting cadence adherence to the board risk committee

This is the simplest metric and the easiest to let slip. It measures whether ICT risk reporting to the board is happening on the schedule the framework promises, in the form the committee agreed to receive it. The benchmark is straightforward. One hundred per cent adherence to the agreed cadence, because a framework that reports late or inconsistently cannot claim to give the board real-time oversight of risk.

A firm running lower-criticality systems may reasonably set a longer classification window than a firm running payment infrastructure; what matters to a supervisor is that the threshold was a considered board decision, not a default nobody examined.

Where you are likely to need further support

Two areas consistently take longer than firms expect, and both are worth planning for early rather than discovering under deadline pressure.

The first is drafting a genuine risk appetite statement. This sounds straightforward until a board actually sits down to agree numerical or descriptive thresholds for ICT disruption. The conversation is likely to surface disagreements about risk tolerance that have never been made explicit before, and it takes skilled facilitation to turn that into a document the board will actually stand behind. Done well, the outcome is a statement the board genuinely understands and owns, not one it has merely signed.

The second is independent validation. It has to be genuinely independent, not the same team marking its own homework with a different report template, and it has to be done by people who understand both the regulatory expectation and the operational reality well enough to give the board a credible answer, rather than a checklist exercise. Done well, the outcome is a validation the board can rely on when a supervisor asks how it knows the framework works, backed by evidence rather than assurance alone.

If either of those is where your own programme is stalling, this is where bringing in outside perspective tends to move things fastest; because both tasks benefit from someone who has run the exercise before and can shortcut the false starts.

If you take one thing into your next board risk committee meeting, make it this. Ask to see the current ICT risk appetite statement, in writing, with the board’s sign-off date attached. If it does not exist in that form, that is your starting point, and everything else in this article follows from getting that one document right.

Next in the DORA series

A board-approved risk appetite is where governance starts, but it means little if the organisation cannot detect, classify and report an incident against it fast enough to meet the regulator’s clock. That is where we turn next, in Blog 3: DORA and ICT Incident Management.

If you are unsure of where to start, need support to ensure your organisation is compliant with DORA, or for more information about Cyberfort DORA compliance services contact us at [email protected] and speak to one of our compliance experts.

If your organisation has treated Cyber Essentials as a box-ticking exercise, it is time to reconsider the value of this certification standard. Insurers are already pricing cyber cover against it, some cover is being attached to it for free, and claims outcomes are diverging sharply between those who hold it and those who do not. In this blog article Cyberfort security experts look at why more insurers are mandating Cyber Essentials and Cyber Essentials Plus and where organisations should start with obtaining this certification.

Why are insurers demanding Cyber Essentials?

If your organisation does not hold Cyber Essentials, you are negotiating your cyber insurance from a position of weakness, and you may not even know it. Insurers are no longer treating the certification as a peripheral nice-to-have. They are using it as a baseline signal of risk, attaching real cover to it, and drawing a harder line at the point of claim between organisations that can demonstrate basic control and those that cannot.

This is not a future risk to plan for. It is already happening, and it is happening quietly, in premium calculations and underwriting criteria that most boards never see until a renewal comes in higher than expected, or a claim is challenged. The organisations that treat cyber essentials certification as a compliance formality, rather than as a live input into how their insurer prices and pays out on risk, are the ones who will be caught out first.

This matters more now than it did even two years ago, because the UK government has itself moved decisively. NCSC and the Department for Science, Innovation and Technology (DSIT) have both restated, throughout the past 12 months that Cyber Essentials is central to the UK’s approach to raising baseline cyber resilience across the economy, and the insurance market has followed that signal.

Insurers are already pricing on Cyber Essentials

Cyber insurance underwriting has always relied on some proxy for an applicant’s control maturity, because insurers cannot audit every policyholder’s network before every renewal. For years that proxy was a lengthy self-assessment questionnaire, inconsistently completed and inconsistently trusted. Cyber Essentials gives underwriters something better, an externally verified, government-backed certification against a fixed technical standard, refreshed annually, covering the five controls that NCSC’s own data shows would have prevented the overwhelming majority of the cyber incidents it investigates.

That is precisely the kind of signal an underwriter wants. Independently assessed, standardised, and easy to verify. Several insurers operating in the UK market now explicitly reference Cyber Essentials in their underwriting criteria for small and medium-sized businesses, and a number offer a preferential rate or a more straightforward application route to certified applicants.

For a CFO or CEO reading a renewal quote, this means a decision made in the IT function – to pursue certification or let it lapse, now shows up as a line on the insurance budget. That is a governance point as much as a technical one. Control decisions taken below board level are already having a financial consequence at board level, whether or not anyone has connected the two.

Certification comes with quantifiable cover attached

The clearest evidence that insurers treat Cyber Essentials as a genuine risk signal, rather than a marketing checkbox, is that some of them are prepared to give away cover on the strength of it. NCSC’s own guidance confirms that organisations with a turnover under £20 million that achieve Cyber Essentials certification receive free cyber liability insurance cover of up to £25,000, automatically included as part of the certification process through NCSC’s delivery partner.

That is not a discount voucher or a marketing gesture. It is underwritten cover, provided because the insurer assessing the risk has concluded that an organisation meeting the Cyber Essentials standard is a materially better risk than one that has not been assessed at all. Insurers do not give away liability cover on organisations they consider high-risk; they price those organisations out or decline them. The fact that this cover is bundled automatically into certification tells you what the insurance market actually believes about the standard’s protective value, more clearly than any marketing statement from NCSC itself could.

For smaller and mid-sized businesses, this is close to a straightforward financial argument. The certification, which typically costs a fraction of a single cyber insurance premium, can bring with it cover that would otherwise need to be purchased separately. For larger organisations above that turnover threshold, the free cover does not apply directly, but the signal to their own insurers, that basic control hygiene is independently verified, still feeds into how their much larger cyber programmes are priced.

Certification changes what happens at the point of claim

The most consequential evidence sits in claims data, not in premiums. NCSC has published figures, drawn from its delivery partner’s own insurance claims experience, showing that organisations holding Cyber Essentials made 92% fewer claims than organisations without the certification. That is a large enough gap that it cannot be dismissed as noise, and it is precisely the kind of statistic that changes underwriting behaviour, because it demonstrates the certification’s protective effect in the real-world outcome insurers care about most, whether they end up paying out.

Beyond the headline number, certification also matters procedurally at the point of a claim being assessed. Insurers increasingly ask, as part of claims handling, whether basic controls were in place at the time of an incident, the same categories of control that Cyber Essentials tests. An organisation that can point to a current certification has a documented, independently verified answer to that question. An organisation that cannot is relying on its own account of its own security posture, offered after the fact, at precisely the moment an insurer has the least reason to take that account at face value. That difference can affect not just the speed of a claim, but its outcome.

The wider context – government is not treating this as optional

None of this is happening in isolation. The UK government has been explicit that Cyber Essentials sits at the centre of its strategy for raising baseline resilience across the economy, and it has backed that position with its own procurement rules. Certain categories of government contract have required Cyber Essentials for a number of years, and the government’s own Cyber Governance Code of Practice, along with its wider Cyber Resilience agenda through 2025 and 2026, continues to push board-level accountability for exactly the control areas the certification tests.

Put simply, the same standard that insurers are using to price risk is the standard government is using to gate contracts and expects boards to own. For a business operating in regulated sectors, supplying the public sector, or answering to increasingly cyber-literate customers and investors, Cyber Essentials is converging into a single reference point that touches procurement eligibility, insurance economics, and governance expectation at the same time. Treating it as three separate, unconnected compliance tasks, one for sales, one for finance, one for the board pack, is where most of the wasted effort and missed opportunity in this space actually sits.

What this means for the board

For senior leaders, the implication is not simply to renew the certificate and move on. It is that Cyber Essentials should be reviewed as a financial and risk instrument, not purely a technical one, and that review needs to happen where finance, risk and the insurance renewal cycle actually meet, which for most organisations is a boardroom conversation, not an IT one.

Three questions are worth putting directly to your executive team and your broker at the next renewal:

1. Does your current cyber insurance policy reference Cyber Essentials, or a comparable control standard, in its pricing or its claims conditions, and have you actually asked your insurer that question rather than assumed the answer?

2. If you hold certification, are you using it actively in renewal negotiations, or letting it sit as a badge on a website while the insurer prices you as an unknown quantity?

3. If you do not hold it, what is the quantifiable cost of that gap, in premium, in cover you cannot access, and in the leverage you do not have at the point of a claim?

None of these are IT questions. They are financial governance questions with a technical control standard sitting underneath them. Answering them properly requires the same kind of scrutiny a board would apply to any other instrument that affects the cost and reliability of risk transfer. Cyber Essentials has become one of those instruments, whether or not it was designed to be.

Final thoughts

The organisations that will be best positioned as this trend continues are not the ones with the most sophisticated cyber programmes. They are the ones who have understood that Cyber Essentials, cyber insurance pricing, and claims outcomes are now linked in ways that show up directly on the balance sheet, and who have made sure their certification status, their insurance conversation, and their board’s oversight of both are pointed in the same direction.

The alternative is to keep treating certification as a compliance exercise handled once a year by someone in IT, disconnected from the insurance renewal handled once a year by someone in finance, disconnected again from the risk conversation the board has once a year without reference to either. That disconnection is not a neutral choice. It is a cost, and increasingly, it is a cost insurers are pricing you for whether you have noticed it or not.

For more information about Cyberfort Cyber Essentials services contact us at [email protected].

Click here to find out more about our Cyber Essentials Fast Track Service >

Click here to download the Datasheet >

It’s over a year since DORA’s application date, this article opens our DORA insight series. It sets out the five capabilities every financial services firm needs to demonstrate under DORA. Over the forthcoming weeks Cyberfort security and compliance experts will explore each pillar in depth giving their insights, thoughts and recommendations for security professionals who are responsible for implementing and managing this regulatory standard in their organisation.

Most financial services firms are not starting their DORA journey from a position of weakness. They already have security teams, incident response processes, supplier oversight, testing programmes and governance forums. What DORA has done is expose the gap between having these capabilities and being able to demonstrate that they work consistently, under pressure, and with board-level accountability.

That distinction matters because DORA is not a technology regulation. It is an operational resilience regulation.

Regulators are not asking whether an organisation owns the right tools. They are asking whether it can prove it understands its ICT risks, responds effectively to disruption, manages third-party dependencies, tests resilience in a meaningful way, and contributes to the wider resilience of the financial services ecosystem.

Organisations that approach DORA as a compliance exercise will almost certainly produce an
unnecessary large quantity of documentation. Organisations that get the greatest value from it will use it as an opportunity to build lasting operational resilience capabilities.

Across all the conversations with financial services firms at Cyberfort over the past year, one consistent theme emerges. Success under DORA is not determined by individual controls or isolated projects. It is determined by five interconnected organisational capabilities.

Capability 1: ICT Risk Management

Everything starts with governance. Most firms can demonstrate strong operational security controls; vulnerability management, monitoring, asset inventories, incident response plans. What is often harder to demonstrate is how ICT risk is effectively governed, owned and managed at board level.

DORA places direct responsibility on senior leadership for the management of ICT risk. That means organisations need more than technical capability. They need a documented framework that explains:

How ICT risks are identified and assessed
How risk appetite is defined and approved
Who owns material risks
How mitigation activities are tracked
How the board receives and acts upon risk information

The key question is not “do we manage ICT risks?” It is “can we demonstrate how the organisation makes risk decisions, and prove those decisions align with documented and accepted business risk tolerances?” Without that foundation, every other DORA capability becomes significantly harder to sustain.

Capability 2: Incident Detection, Classification and Reporting

Most firms are relatively good at detecting incidents. The challenge is what happens next.

DORA’s requirements go beyond identifying suspicious activity or responding to technical events. Organisations must be able to classify incidents consistently, assess their severity accurately, determine cross-border and regulatory significance, and report major incidents against a genuinely tight clock – an initial notification within hours of classification, followed by further reports within days and weeks.

This is where many organisations discover that their existing incident processes were designed to support operational response rather than regulatory decision-making. An incident bridge call might successfully coordinate technical remediation, but can it determine severity using documented criteria, assess cross-border relevance, demonstrate why a classification decision was made, and produce an auditable record of root cause and remediation?

The difference between detection and classification is often where the greatest DORA related gap exists. Building a repeatable and defensible incident classification process is one of the most valuable investments financial services firms can make.

Capability 3: Operational Resilience Testing

Testing is not new. What DORA changes is the purpose of testing.

Traditional security testing often focuses on systems, applications or infrastructure. DORA shifts attention towards the resilience of critical and important business services. The key question becomes – can this service continue to operate during a realistic disruptive event?

Answering that requires more than vulnerability scans and penetration tests. Organisations must understand which systems support critical functions, which third parties those functions depend upon, how failures could propagate across services, and whether resilience assumptions have actually been validated under realistic scenarios.

For a sub-set of larger, designated organisations, this also means Threat-Led Penetration Testing. For every organisation in scope of DORA, it means moving beyond testing technology in isolation and towards testing business resilience as a whole. In many ways, testing is where assumptions become evidence.

Capability 4: Third-Party Risk Management

Few financial services organisations operate independently. Critical functions increasingly rely on cloud providers, managed service providers, software vendors and complex supply chains, and DORA recognises that operational resilience cannot exist if third-party dependencies remain poorly understood.

Most firms already have supplier management processes. The challenge is gaining visibility into critical supplier dependencies, concentration risk, fourth-party exposure, contractual obligations and exit readiness.

A supplier register can tell you who your providers are. A resilience-focused third-party risk programme tells you what happens if one of them fails. That distinction is becoming increasingly important as regulators place greater emphasis on systemic risk and concentration within the financial services technology ecosystem.

Capability 5: Information and Intelligence Sharing

The final capability is often the most misunderstood. Many organisations view threat intelligence as something they consume. DORA encourages organisations to view intelligence sharing as something they actively participate in – contributing to, and benefiting from, sector-wide resilience initiatives.

The rationale is straightforward. No individual financial services firm has complete visibility of the threat landscape. Attackers routinely target multiple organisations using similar techniques, dependencies and infrastructure. Sharing intelligence helps firms identify threats faster, improve detection capabilities and strengthen resilience across the sector.

The most mature organisations establish formal processes for consuming threat intelligence, feeding it into detection and testing activities, sharing appropriate indicators and insights, and maintaining audit trails of participation. The result is not simply compliance. It is a stronger collective defence capability.

Why these capabilities matter together

It is tempting to treat DORA’s pillars as separate workstreams. In reality, they are closely connected. A risk management framework informs incident classification. Incident data helps shape resilience testing. Testing identifies third-party dependencies. Third-party risks influence governance decisions. Threat intelligence improves every stage of the process.

The organisations making the greatest progress are not building five separate programmes. They are building one operational resilience capability that integrates and embeds governance, response, testing, supplier oversight and intelligence sharing into a single operating model.

Final thoughts

The most important question for financial services leaders one year into DORA is not whether they are compliant today. It is whether their organisation could confidently demonstrate resilience tomorrow.

The firms that succeed will be those that move beyond documentation and focus on capability: governance that can withstand scrutiny, incident processes that work under pressure, testing that reflects real-world threats, supplier oversight that reveals hidden dependencies, and intelligence sharing that strengthens both the organisation and the wider sector.

DORA provides the framework. The challenge, and the opportunity, is turning that framework into resilience that can be demonstrated, measured and relied upon when it matters most.

In this DORA series

Over the next five articles, we go deeper into each of these capabilities in turn:

ICT Risk Management: building board-owned governance and risk oversight.
Incident Management and Reporting: creating consistent and defensible incident classification.
Digital Operational Resilience Testing: proving resilience through realistic testing.
ICT Third-Party Risk Management: managing concentration risk and supplier dependency.
Information and Intelligence Sharing: strengthening resilience through collaboration and shared insight.

For more information about Cyberfort’s DORA compliance and operational resilience services, contact us at [email protected] and one of our experts will be in touch.

Written by Fahad Naeem – Cyber Security Consultant (Cyberfort)

The core philosophy of modern cyber security has flipped. Never trust, always verify. Perimeter defences like traditional firewalls and VPNs are no longer enough; they leave blind spots inside your network once an attacker gets past the gate. This is where Zero Trust Architecture comes in.

What is Zero Trust Architecture?

Zero Trust Architecture is a relatively modern cyber security framework that shifts the traditional approach around securing the boundary to operating on the principle of never trusting and always verifying. There is an assumption that the threat exists both inside and outside the network. Automatic trust is removed from every user, device, application, and there is an enforcement of identity verification, device health checks, and least-privilege access controls for every user, application, or system attempting to connect to resources.

The benefit of this approach is that it reduces the possible attack surface of a threat actor as it limits their access points and minimises the risk of lateral movement by attackers, limiting the damage of any potential breaches.

Legacy Problems

Zero Trust is easy to conceptualise in a modern cloud environment; however, the challenge arises when applying to legacy systems that are deeply embedded in an organisations operation. The previous framework focused on perimeter-based security e.g. firewalls and virtual private networks, which do provide security benefits, but provides a fundamentally limited view inside the network.

Because legacy systems were built before modern Zero Trust standards existed, they present multiple security vulnerabilities. This is compounded by the fact that these systems often run outdated operating systems, creating additional attack vectors to be exploited. They also create integration hurdles, including incompatibility with single sign-on standards like SAML or OIDC, and a lack of support for endpoint detection and response (EDR) agents, which hinders device health verification.

These issues have led to significant impacts in the real world:

British Library ransomware attack – due to lack of network segmentation attackers were able to exfiltrate 600 gigabytes of data.

Target data breach – an attacker was able to compromise third party vendor credentials and because of lack of network segmentation attackers were able to steal 40 million credit card records.

Micro segmentation

One approach that can help legacy systems is micro segmentation; this allows organisations to isolate and secure legacy without having to rewrite code. By creating smaller tightly controlled network zones with least privilege access enforcement, lateral movement is limited.

A particularly difficult challenge to contend with for legacy systems is the lack of a hypervisor, which sits between physical hardware and the operating system. It is used to manage traffic, processing (CPU), memory (RAM) and storage between the virtual computers and allows them to run independently and even on different operating systems. Security tools use three methods to handle this scenario:

1. Operating system approach (internal enforcement)

with administrative access to the server’s operating system, an agent can be installed directly. The agent acts as local security that can push micro segmentation policies and routing data securely to its intended location.

2. Network port approach (external hardware enforcement)

if the server is a closed application, then you can use physical network switches in your server room. The switch becomes the security boundary and manages the data ingress.

3. Proxy/Gateway approach (identity-based delivery)

in this approach the server is hidden from the rest of the network, and the proxy or gateway sits in front of the server with the server configured only to accept traffic from the proxy. The proxy can then authenticate identities and pass device health checks.

Depending on your specific situation a combination can gain the desired segmentation.

Real world examples include:

BUPA’s Cromwell Hospital – they utilised agentless micro segmentation to identify unmanaged devices, group them and apply identity-ware policies at the edge of the network. Resulting in all medical machinery being ring fenced minimising lateral movement risks.
U.S. Federal Government Agency – The agency deployed a rigorous Software-Defined Perimeter (SDP) and Micro-Segmentation model; this reduced their attack surface by 85% and stopped 100% of red team’s penetration tests.

So where should you start with micro segmentation? Based on our experience at Cyberfort we collaborate with our customers on embedding a 4-step approach:

1. Inventory and risk-assess before you segment

First identify your legacy system, what they connect to, what data they handle and why they cannot be patched or replaced in the normal way, then document the risk assessment formally rather than leaving it as IT group knowledge, so the decision to compensate with segmentation (rather than remediate directly) is deliberate and auditable.

2. Choose the enforcement method the system will actually support

Check what access you genuinely have – administrative rights to install an agent, physical control of the network hardware, or the ability to front the server with a proxy, before committing to an approach. Forcing the wrong method onto a system that can’t support it (for example, trying to install an agent on a closed appliance) wastes effort and can leave gaps that look closed but aren’t. Also make sure you consider the risk of over-segmentation which can lead to operational inefficiencies and if user experience is ignored it can lead to workaround which can open the risk back up.

3. Build the zones around least privilege, not convenience

Define each segment as narrowly as the system’s function allows, and grant access only to the specific users, services and ports that genuinely need it. A segmentation zone that is still broad enough to let lateral movement happen defeats the purpose, the tighter the boundary, the smaller the blast radius if the legacy system is compromised.

4. Monitor the boundary continuously, not just at set-up

Segmentation only works if you can see when something crosses it. Feed the traffic at each zone boundary into your monitoring so unusual connections, a legacy system suddenly reaching out to somewhere it never has before, are flagged and investigated in real time, rather than discovered after the fact.

Migration Strategies

When considering your organisation and its need a practical method to move off legacy systems can be to wrap and migrate; wrapping is securing your current system so the immediate risk is minimised allowing you to continue with your functions and then migrating to more modern systems in the longer term.

Below is a high-level approach of how this can be implemented:

The first step is always to review and prioritise your system to ensure that you are focusing on what matters most to your organisation. Ask questions like:

How critical is this system to operations? It is important to have impartial scoring as business areas will always consider themselves the most important. ISO22301 has a section around business impact assessment that can help determine the impact to the business if a system is lost and therefore determine an order of criticality.
Does it handle or store sensitive data? This can be either personally sensitive data or sensitive company data.
Can it be easily replaced or modernised in the short term?

Once this has been completed you know where to focus your efforts to maximise benefits. First, limit network access to validated users only. Next, implement segmentation so systems are isolated from one another, effectively limiting the blast radius of a potential attack. This also increases the life span of your solution reducing organisational waste.

Over the long term you can develop a migration strategy e.g. how to move your system off the legacy approach and to follow a zero-trust model, either on-premises or a cloud service providers environment. This might require refactoring or replacing systems, by building them yourself or by purchasing software as a service (SaaS).

Finally, once you have migrated and validation has been completed, decommission old hardware and systems following best practices to ensure safe disposal of your businesses data.

Key takeaways

It’s not about if an attacker can breach your boundary protection it’s when.

Consider your system and what approach works best for your organisation.

Immediate migration is likely to be pricey and might not be the best approach in the short term.

For further reading check out Zero Trust | Zero trust architecture design principles | National Cyber Security Centre.

If you would like to find out more about Cyberfort Zero Trust Architecture services contact us at [email protected] and one of our experts will be in touch.

Why “We Have IT Handling That” is no longer enough to keep organisations secure, resilient and compliant

There is a question that surfaces in board meetings, insurance renewals, due diligence processes, and post-incident reviews more than any other. It is uncomfortable precisely because it sounds simple.

“Who owns cyber security in this organisation?”

In a surprising number of small and medium-sized businesses, the honest answer is – nobody does. Not formally or accountably. There is an IT Director who handles the infrastructure. There is a Head of Compliance who manages the frameworks. There is a senior leader, often the CEO or CFO who steps in when the topic comes up in a board meeting and does their best to project confidence. But there is no single person with the expertise, the mandate, and the accountability to own the organisation’s security posture end to end.

This is not a failure of intent. It is a structural gap that has opened up as the threat landscape has grown faster than the talent market and the budget cycles of most organisations. It is a gap that carries consequences if not addressed. Consequences that are becoming harder to absorb as regulatory expectations increase, insurers tighten their criteria, and customers start asking questions their suppliers cannot answer.

This article sets out what the cyber security leadership gap looks like in practice, why it tends to stay hidden, and how businesses can begin to address it.

What the leadership gap actually looks like

The cyber leadership gap rarely presents as an obvious absence. Most organisations that have it believe, genuinely, that they have it covered. The IT function is capable. The policies exist. The awareness training has been done. There is a firewall, antivirus and endpoint detection.

What is missing is not technology. It is strategic ownership.

A CISO, does something that no amount of tooling can replicate. They translate between the technical reality of the organisation’s security posture and the business language that the board, insurers, regulators, and customers need to hear. They maintain a live risk register that reflects what is actually happening in the environment, not what the policies say should be happening. They prioritise remediation not by what is technically interesting, but by what the business cannot afford to lose. They make sure that when the responsibility question is asked, in an audit, due diligence call, or a board meeting, that there is a coherent, evidenced answer.

Without that leadership, organisations accumulate risk in the gaps. Not dramatic, headline-grabbing risk in most cases. The quieter kind. Policies that exist on paper but have never been enforced. Security controls that were implemented two years ago and have not been reviewed since. Vendors who were assessed at onboarding and never since. A risk register that was created for a certification exercise and now sits in a shared drive, unreviewed.

None of these individually represents a crisis. Together, they represent an organisation that does not know its own exposure and will only find out what it is at a moment of its attackers’ choosing rather than its own.

Why the gap stays hidden

The cyber leadership gap tends to stay hidden because the people who know it exists are also the people who are asked to paper over it. The IT Director who gets asked to present the “cyber update” to the board. The Head of Compliance who adds a security section to the risk register without the technical depth to make it meaningful. The COO who fields the insurer’s questionnaire by calling the IT team and hoping the answers are correct.

From our experience at Cyberfort the most common reasons the security leadership gap stays hidden and the potential impact this is having are:

No baseline

Without a formal security programme and a consistent measurement framework, most organisations do not have an accurate picture of their current posture. They know roughly what controls they have in place. They do not know whether those controls are working, if they are configured correctly, or they cover the attack surfaces that actually matter.

No ownership

When something goes wrong, a phishing campaign, a data subject access request that uncovers a gap, an insurer query that cannot be answered cleanly, it is not immediately clear whose problem it is. The IT team escalates. The compliance team flags it. Leadership is briefed. But nobody has the authority and the expertise to make the decision and own the consequences.

No continuity

Security decisions made in one year are rarely revisited in the next unless something forces them onto the agenda. A control that was fit for purpose when the organisation had fifty staff may be entirely inadequate at two hundred. A supplier relationship that looked low-risk before a business’s data environment expanded may now represent significant exposure. Without ongoing strategic oversight, the security programme drifts.

When the gap becomes visible

The cyber leadership gap tends to become visible in one of several different circumstances which are highlighted and discussed below. The situations described below are the most common ones we see at Cyberfort where cyber security leadership is needed on a fractional basis.

A board accountability question

An investor, a non-executive director, or a regulator asks who is accountable for cyber security and wants a specific name. “The IT team” is not an answer. “We are reviewing our governance arrangements” is not reassuring. The absence of a named, qualified owner is itself a red flag.

An insurance renewal

Cyber insurance questionnaires have become substantially more demanding over the past three years. Insurers now ask detailed questions about governance, patch management processes, privileged access controls, and incident response capability. Organisations without a security leader who cannot answer those questions and evidence the answers, face premium increases, exclusions, or declined renewals.

An enterprise customer questionnaire

Larger customers, particularly in financial services, professional services, and public sector supply chains, increasingly require their suppliers to demonstrate security maturity before onboarding. Security questionnaires that would once have been handled by the IT team now require board-level sign-off on governance arrangements that, in many cases, do not exist.

A merger or acquisition

Security due diligence has become a standard part of the M&A process. A target organisation with no security programme, no risk register, and no governance framework represents a discount to valuation and a material integration risk. Acquirers who find this out during diligence are rarely forgiving.

A post-incident review

After a security incident, a phishing compromise, ransomware attempt, or a data breach, the question that follows is always – what was the governance arrangement that allowed this to happen? The absence of a security leader means the answer is, at best, complicated.

A new regulatory obligation

GDPR, NIS2, DORA, the ICO’s guidance on accountability, each of these creates specific governance obligations that cannot be met by an IT team alone. They require documented processes, named accountabilities, and evidence of ongoing oversight.

A new executive with a risk mandate

A new CEO, CFO, or COO who comes from a more security-mature environment and discovers the governance gap on arrival. These individuals tend to move quickly, because they understand the exposure they have just inherited.

What good Security Leadership provides

It is worth being clear about what a senior security leader actually does, because the gap is sometimes described in terms of credentials “we don’t have a CISO” rather than a leader .

A CISO, or an equivalent senior security leader , provides four things that cannot be replicated by tooling, frameworks, or occasional consultancy.

Strategic context

The ability to understand the business’s risk appetite, its commercial priorities, and its threat profile, and to translate those into a security programme that protects what actually matters rather than what a framework says should be protected.

Governance

The policies, processes, and oversight mechanisms that ensure the organisation’s security programme operates consistently, is reviewed regularly, and is aligned to current risk rather than historical assumption.

Board communication

The ability to present security risk in language that a board can act on, not as a list of technical vulnerabilities, but as a business risk with financial, operational, and reputational dimensions, prioritised and costed.

Accountability

A named, qualified individual who owns the outcome. When something goes well, that accountability creates credibility. When something goes wrong, it creates the capacity to respond effectively rather than scrambling to identify who is responsible.

The Economics of the Problem

A senior CISO for a UK mid-market business now commands a salary of £120,000+. Add employer’s National Insurance, pension contributions, recruitment costs, and the management overhead of a direct report, and the all-in cost of a full-time hire comfortably exceeds £150,000 per year.

For organisations in the £20m to £100m revenue range, the market where the governance gap is most common and most acute, that is a significant financial commitment. Many organisations in this revenue range do not need a full-time CISO. They need the output of one: strategic oversight, governance, board reporting, and the ability to field the questions that arise from insurers, regulators, and customers with confidence.

The fractional model has emerged as a direct response to this economics problem. Rather than committing to a full-time hire that the organisation may not fully utilise, organisations can access senior security expertise on an ongoing, structured basis, maintaining the continuity, the accountability, and the strategic oversight that the gap creates, at a fraction of the cost.

Understanding the business value of a vCISO

The value of a fractional security leadership model lies not just in the expertise it provides, but in the structure it imposes. An effective engagement creates the governance mechanisms that allow an organisation to operate with appropriate security maturity, rather than simply providing advice on demand.

A well-structured vCISO engagement with a specialist MSSP typically progresses through the following stages.

Step 1 — Onboarding and Current State Assessment

The engagement begins with a structured review of the organisation’s current security posture – existing controls, policies, governance arrangements, risk register, and any historical audit or assessment findings. The objective is to establish an honest baseline, not a polished picture, but an accurate one.

Step 2 — Governance Framework and Risk Register

With a baseline established, the engagement moves to building or rebuilding the governance structures that the organisation needs. This includes a live risk register that reflects the actual environment, a suite of policies that are enforced rather than archived, and the governance mechanisms that ensure ongoing oversight.

Step 3 — Security Roadmap

The governance framework is paired with a prioritised roadmap, the specific actions, in order, that will move the organisation from its current posture to its target posture. This is not a theoretical framework. It is a practical plan with named owners, clear priorities, and measurable outcomes.

Step 4 — Ongoing Leadership, Board Reporting, and Governance Oversight

The ongoing engagement provides the continuity that makes the model work. Regular leadership sessions, monthly or quarterly board reporting, active oversight of the risk register and roadmap, and the capacity to respond to the external triggers, the insurance renewal, customer questionnaire, or regulatory enquiry as they arise.

The Question to Ask

The cyber leadership gap is not a technology problem. It is not solved by deploying another tool or achieving another certification. It is solved by answering one question clearly ’Who is responsible for security in this organisation, and what does that responsibility actually mean?’

If that question does not have a clean answer, or if the answer is a name followed by a long explanation of everything else that person is also responsible for, it may be worth understanding what a structured approach to closing that gap would look like. It is also probably time to engage with a specialist MSSP who has the skills, knowledge and expertise to fill your businesses security leadership gap before it’s too late.

For more information about Cyberfort’s vCISO service and how it can help your organisation build its security strategy and achieve its objectives, email us at [email protected] and one of our experts will be in touch.

To find out more about the Virtual CISO starter service click here >

Download Data Sheet >

With many industry reports highlighting that 60%+ of the security breaches that occurred in the past year involved a vulnerability for which a patch already existed, (not a zero-day or sophisticated nation-state exploit attack) and it taking organisations over 200 days on average to identify where a security breach has occurred, now is the time for organisations to start thinking about and taking vulnerability management more seriously.

The statistics above are not unrelated, they describe a single, coherent threat that many businesses are not taking action on. Most UK organisations are carrying vulnerability risk they cannot see, prioritise or close. The root cause is almost never a lack of security tools. It is a lack of structure around how those tools are used, what they tell you, and what happens next.

In this blog article we explore why Vulnerability Management needs to be a business priority. We also cover why all organisations should be putting this capability in place if they want to stay resilient and secure against attack both today and in the future.

The difference between Scanning and Managing

Most businesses run some form of vulnerability scanning. They have a tool, sometimes built into a broader security platform, sometimes a standalone product, that periodically checks their estate and produces a list of findings. They know the tool exists. Someone on the team looks at it. Occasionally, patches are applied.

That is scanning. It is not vulnerability management.

This distinction matters because scanning answers one question – what vulnerabilities exist?

Vulnerability management answers a harder set of questions.

Which of those vulnerabilities represent the most significant risk to this particular organisation, given how its systems are configured, what data they hold, how they connect to the outside world, and what an attacker would actually need to do to exploit them? And crucially, who is responsible for fixing them, by when, and how do we know they have been fixed?

The gap between those two sets of questions is where most breaches happen. Not because organisations don’t know about vulnerabilities in their IT estates. But because they lack the structure to turn a list of findings into a governed, prioritised programme of remediation with clear accountability and measurable progress.

Why the problem is Structural, not Technical

It is tempting to treat vulnerability management as primarily a technical problem. Buy a better scanner. Add more coverage. Increase scan frequency. Each of these things has value, but none of them addresses the structural issues that cause vulnerability programmes to stall.

The first structural problem is volume without context. Modern IT estates, particularly those that have grown through cloud adoption, remote working infrastructure, or acquisitions, generate vulnerability findings at a scale that cannot be addressed manually. An uncontextualised scan of a medium-sized business might return thousands of findings across hundreds of systems. Without a clear methodology for translating that volume into a prioritised, actionable list, most organisations default to inaction. They close the highest-severity findings where they can and leave everything else in a growing backlog that nobody owns and nothing resolves.

The second structural problem is the absence of a baseline. Many organisations cannot confidently answer the question “what did our vulnerability posture look like six months ago, and has it improved”. Without a baseline, there is no way to demonstrate progress to a board, satisfy an insurer’s question about remediation, or identify whether a recent infrastructure change has materially increased exposure. Scanning without a baseline is collecting data. Vulnerability management is building a record.

The third structural problem is ownership ambiguity. In most organisations without a dedicated security operations function, vulnerability remediation falls between teams. IT operations owns patching. Development owns application code. Cloud teams own infrastructure configuration. Security owns the findings, but has no direct authority to make remediation changes. Without a clear governance model that defines who receives findings, who is accountable for remediation, and what escalation looks like when remediation stalls, vulnerability management programmes fragment into a series of disconnected conversations with no reliable closure mechanism.

The Compounding Effect of a Growing Estate

These structural problems are manageable when an organisation’s IT estate is stable and well-understood. They become significantly harder when that estate is changing, through cloud adoption, which introduces new infrastructure at a pace that outstrips manual inventory; acquisitions, which bring inherited systems with unknown security history; rapid growth, which adds users, devices, and services faster than governance frameworks can absorb; or through the shift to hybrid and remote working, which has permanently extended the boundary of what counts as the IT estate.

The practical consequence is that many organisations are managing vulnerability risk against an incomplete picture of their own attack surface. They are scanning what they know about and making decisions about remediation priority based on a partial view that may be missing the very systems an attacker would find most attractive.

This is not a failure of security awareness. It is a structural consequence of how organisations grow, and it requires a structural response.

What Good Vulnerability Management Actually Looks Like

Understanding what good looks like is the starting point for identifying the gap between current practice and where an organisation needs to be.

Good vulnerability management begins with an accurate, maintained inventory of the assets in scope, not a theoretical list, but a continuously reconciled picture of what is actually present in the environment. This sounds basic, but it is frequently the hardest part. Shadow IT, legacy systems, cloud-native infrastructure, and contractor-managed devices all contribute to inventory drift.

From a reliable inventory, good vulnerability management applies contextual prioritisation, not just CVSS scores, but asset criticality, exploitability in the wild, network exposure, and the specific sensitivity of the data or functions hosted on affected systems. A high-severity vulnerability on an internet-facing authentication system is categorically different from the same vulnerability on an internal development server with no external connectivity, and treatment should reflect that difference.

Good vulnerability management produces governance-ready output. Executive reporting that communicates risk in business language, not technical jargon; tracking that shows remediation progress over time; and audit-ready documentation that satisfies the questions insurers, regulators, and enterprise customers are increasingly likely to ask.

Critically, good vulnerability management closes the loop. It tracks findings through to remediation, validates that patches have been applied correctly, and maintains a continuous record of the organisation’s risk posture over time, not a point-in-time snapshot that is out of date the moment it is produced.

The situations where this becomes urgent

For most organisations, vulnerability management improvement is a steady-state priority, important, but not urgent in any given week. There are situations, however, where it becomes genuinely pressing.

An upcoming cyber insurance renewal is one of the most common. Insurers are asking increasingly detailed questions about scanning frequency, remediation timelines, and the governance processes that surround vulnerability management. Organisations that cannot answer those questions credibly or that can only answer them based on informal practices rather than documented processes are finding that coverage becomes harder to obtain, premiums increase, or specific exclusions are applied to incidents that might have been prevented by better vulnerability controls.

A compliance audit or certification assessment is another area that often becomes urgent in relation to vulnerability management. ISO 27001, SOC 2, PCI DSS, Cyber Essentials Plus, and DORA all have requirements that touch vulnerability management directly or indirectly. Organisations that treat vulnerability management as a background activity often find, when they engage in a formal audit process, that their existing practices do not meet the evidentiary standard required for certification or compliance.

The third area when vulnerability management becomes a priority is when there has been a significant change to the IT estate, a cloud migration, an acquisition, a major infrastructure refresh, will routinely reveal vulnerability posture issues that were hidden by the previous environment’s stability. The act of changing creates new exposure, and the process of integrating new systems into existing governance frameworks is rarely instantaneous.

A new security leader taking stock of inherited practices will frequently find vulnerability management is an area where there is significant distance between what people believe is happening and what is actually happening in practice. Establishing a reliable baseline is often the first practical step toward building a credible programme.

And increasingly, enterprise customers and regulated sector procurement processes are requiring suppliers to demonstrate a managed approach to vulnerability risk as a condition of doing business. The question is no longer just “do you scan?” but “can you show us your remediation process and your progress over time?”

Why Existing Approaches Often Fall Short

The most common objection to investing in structured vulnerability management is “we already have tools that do this.” And often that is technically true. The gap is almost never in the tooling; it is in what surrounds the tooling.

Without a defined baseline, you cannot measure improvement. Without a prioritisation framework, high-volume scan output becomes overwhelming rather than actionable. Without tracked remediation, you cannot demonstrate to an auditor, an insurer, or a board that findings are being addressed. Without regular executive reporting, the information stays in the technical team and never reaches the people who carry the governance accountability.

At Cyberfort we have recognised where vulnerability scanning and management falls short. To help businesses our experts have created a Managed Vulnerability Health Check, which is designed to close those gaps. It is not a scanning tool, it is a structured programme that wraps around your existing environment and provides the process, the prioritisation, reporting, and the continuous tracking that turns scan output into genuine risk reduction. In the next section of this article we summarise this approach and identify what the key outcomes are for IT, security and business leaders.

The Four Steps of a Structured Approach to Vulnerability Management

Establishing or improving a vulnerability management programme is not a single project with a defined end date. It is a continuous cycle, but it has a beginning, and that beginning follows a logical sequence outlined below.

The cycle then repeats, with each iteration building on the baseline established in the previous one, so the organisation accumulates an increasingly accurate and well-evidenced picture of how its vulnerability posture changes over time.

Step 1 is scoping and onboarding

Establishing what is in scope, what scanning coverage is required, and how findings will flow into the governance process. This is where inventory gaps are identified and the basis for a reliable baseline is established.

Step 2 is the baseline scan and risk prioritisation

Running an initial comprehensive scan of the in-scope estate, applying contextual prioritisation, and producing the first structured view of the organisation’s vulnerability posture. This is the baseline against which all future progress will be measured.

Step 3 is reporting and communication

Translating technical findings into executive-ready output. This includes a risk prioritisation dashboard, a remediation action plan with clear ownership, and an executive summary that communicates the headline risk picture without requiring technical expertise to interpret it.

Step 4 is ongoing health reviews and remediation tracking

Maintaining the programme over time, running regular scans, tracking remediation progress, validating closures, and providing the continuous record that satisfies governance, audit, and insurance requirements.

Final Thoughts

Vulnerability management is an area where it is genuinely difficult to assess the quality of your own programme from the inside. Teams that have been operating the same way for several years naturally normalise their existing practices, and it takes an external perspective to identify where the gaps are between current practice and what good actually looks like.

The most useful diagnostic question is a simple one – can you confidently name your top ten most critical open vulnerabilities right now, the ones that, if exploited, would cause the most significant harm to your organisation? Can you say when each was identified, who is responsible for fixing it, what the current remediation status is, and when it is expected to be closed?

If the answer is yes, and you can evidence it, your programme is in good shape. If the answer involves any uncertainty about the list itself, ownership, remediation status, or how you would demonstrate progress to an external party, then the gap between your current practice and what you need is worth understanding properly.

That understanding is the right place to start and will enable your organisation to truly understand where vulnerabilities exist, when they should be priortised for remediation and how to close the security gaps that exist in your organisation today and in the future. For more information about Cyberfort Vulnerability Management services email us at [email protected] and one of our experts will be in touch.

To find out more about the Managed Vulnerability Healthcheck service click here >

Download Data Sheet >

The gap between how fast organisations move and how often they test their security is quickly becoming one of the most significant risk factors for UK businesses.

Think about the rate of change in a typical organisation over the course of a year. New applications go live. Cloud environments are extended. Third-party integrations are added. Infrastructure is migrated. Teams expand and bring new devices and access requirements with them. Each of these changes alters the attack surface, sometimes in small ways, sometimes materially.

Now consider when penetration testing happens. For most organisations, the honest answer is ‘when it has to’ or ‘when we are required to, so we can meet a compliance standard’. Annual cycles, driven by compliance obligations or insurance requirements, have become the default rhythm. A test happens, a report is produced, remediation actions are (ideally) completed, and then the clock starts again until the same point arrives next year.

The problem with this model is not the testing itself. Penetration testing, done well, remains one of the most valuable tools available for understanding real-world exposure. The problem is the assumption that a point-in-time test, carried out once a year against an estate that changes continuously, provides meaningful ongoing assurance. It does not.

This article explores why the traditional penetration testing model has structural limitations that many organisations have not yet reckoned with, and what a more responsive approach looks like in practice.

The numbers behind the gap

Before examining the issues, it is worth understanding the value of penetration testing and why at Cyberfort we believe there needs to be a new approach taken by businesses.

According to Verizon’s 2026 Data Breach Investigations Report, vulnerability exploitation has overtaken stolen credentials as the single most common way attackers get in, now accounting for 31% of confirmed breaches, up from 20% the year before. It should also be noted that only 26% of known exploited vulnerabilities were actually remediated in 2025, down from 38% the year before. The implication is clear, the majority of successful attacks are not the result of sophisticated zero-day exploits or nation-state-level techniques. They are the result of known gaps that were either not found, prioritised, or fixed in time.

Take these findings alongside the UK government’s Cyber Security Breaches Survey 2025, which found just 12% of UK businesses carried out penetration testing in the past 12 months there is clearly a gap to close with penetration testing for businesses. Given the rate at which most organisations change their IT environments, that means the vast majority of businesses are operating with an attack surface that has not been assessed at all in the past year, let alone re-assessed against what has changed since.

Taken together, these points tell the same story. Organisations are accepting more risk than they realise, not because they are careless, but because the testing model they rely on was designed for a slower, more static environment.

Why the traditional Penetration Testing model has structural limitations

It is important to be clear, traditional, comprehensive penetration testing programmes have genuine value. For large, complex environments, particularly where regulatory requirements mandate deep, formal assessment, a structured, multi-week Pen Testing engagement conducted by a qualified team remains the right approach.

But the traditional model has characteristics that make it a poor fit for certain situations due to the following reasons:

It takes time to scope and mobilise

Large-scale engagements require detailed scoping, legal sign-off on rules of engagement, scheduling across internal and external teams, and sometimes months of lead time. By the time the test begins, the environment has already moved on from when the conversation started.

It is expensive

A comprehensive penetration test can run to tens of thousands of pounds. That investment is justified for broad programmes, but it makes frequent testing economically difficult for most organisations.

It is disruptive

Wide-scope testing against live environments requires careful coordination to avoid operational impact. That friction increases the internal resistance to testing more frequently.

It produces a point-in-time result

Once the report is delivered, it reflects the state of the environment at the time of testing. Three months later, after a major deployment or a cloud expansion, the findings may no longer represent current exposure.

None of these are criticisms of the traditional Pen Testing model for what it is designed to do. They are observations about the gap it leaves and the situations where a different approach is more appropriate.

The situations where testing most often falls behind and why a Rapid Pen Testing approach could be the answer

Understanding where the gap is widest helps identify where a more responsive Pen Testing approach matters most. Examples of when a Rapid Pen test approach could be the answer include:

A new application approaching go-live

Development cycles move quickly, and security testing is often scheduled too late or compressed under deadline pressure. Applications go live with untested components, and the window for remediation before real users, and real attackers arrive is extremely short.

A customer, insurer, or regulator requesting evidence of testing

This is increasingly common. Procurement processes, particularly in financial services, professional services, and the public sector, now routinely ask for evidence of recent penetration testing. “We tested last year” is an increasingly unsatisfying answer when the question is asked in the context of a contract award or an insurance renewal.

A compliance deadline

ISO 27001, PCI DSS, SOC 2, and DORA all include penetration testing requirements. The timing of compliance cycles rarely aligns neatly with annual testing programmes, which means organisations often find themselves needing a test quickly to meet an audit or certification window.

Retesting after remediation

When findings from a previous test are remediated, there is a natural question, ‘did it actually work?’ Without a targeted retest, the answer is “we think so”, which is not the same as “we know so.”

M&A due diligence

Acquiring or merging with another organisation means inheriting its attack surface. Security posture is an increasingly significant factor in due diligence, but the timelines involved in M&A rarely accommodate a lengthy traditional testing programme.

Post-incident review

When an incident occurs, whether a breach, a near-miss, or a significant compromise of a partner or supplier, boards and leadership teams understandably want broader assurance. Was this an isolated event, or is there wider exposure?

What these situations share is a need for structured, credible security testing that can be scoped, mobilised, and delivered without the weight of a full-scale programme.

What Rapid Pen Testing actually looks like

Speed and rigour are not opposites in penetration testing. A well-designed, tightly scoped engagement can deliver genuine technical depth and actionable findings within a condensed timeframe, provided the scope is defined precisely and the methodology is structured from the outset.

The key discipline is scope definition. A rapid engagement is not a broad sweep across an entire estate. It is a focused, expert assessment of a defined target a specific application, an external perimeter, a cloud environment, a set of internal systems. Precisely because the scope is bounded, the testing can go deep within it. So, what does this look like in reality?

Step 1: Scoping and Rules of Engagement

Before any testing begins, the target environment, objectives, and boundaries are defined clearly. This includes confirming authorisation, agreeing on testing windows where required, and establishing how findings will be communicated. A tight scoping conversation is what enables speed later, ambiguity at this stage is what creates delays.

Step 2: CREST-Aligned Testing

Testing is conducted by qualified practitioners following a structured methodology. For external infrastructure and applications, this typically covers reconnaissance, enumeration, exploitation attempts, and privilege escalation testing. For internal assessments, it includes lateral movement and persistence testing within the defined scope. CREST accreditation provides a standard of assurance that is recognised by regulators, insurers, and procurement teams.

Step 3: Findings Analysis and Risk Prioritisation

Not all findings are equal. The analysis phase translates technical findings into a risk-prioritised view, distinguishing between critical issues that need immediate attention, significant risks that should be addressed in the near term, and lower-priority observations that inform future improvement. This prioritisation is what makes a report actionable rather than overwhelming.

Step 4: Executive and Technical Reporting

Two audiences receive the output, the technical team, who need the detail to understand and remediate findings; and the board or leadership team, who need a clear picture of exposure and the actions required. Both reports are produced as standard. Where an optional retest is required to validate remediation, this can be scoped and scheduled as a follow-on step.

What you should look to achieve from a Rapid Pen Test engagement

At the end of the engagement, the organisation should have a validated picture of its security posture within the tested scope, a prioritised remediation plan, documented evidence of testing that can be used in compliance, insurance, and customer contexts, and clear guidance on what to fix first and why.

That last point matters more than it might appear. One of the most common challenges organisations face after a pen test is knowing where to start. A long list of findings with no clear prioritisation creates paralysis rather than action. A Rapid Pen Test Sprint is designed specifically to avoid that outcome, findings are prioritised by risk, context is provided, and the remediation path is clear from the moment the report lands.

Why can’t we just undertake a vulnerability scan instead?

Automated vulnerability scanning is a useful tool. It identifies known vulnerabilities at scale and provides a baseline view of patch status and configuration. But it has a fundamental limitation, it cannot simulate what an attacker actually does.

Penetration testing is adversarial by design. A qualified tester does not just identify that a vulnerability exists, they attempt to exploit it, chain it with other weaknesses, and assess whether it can be used to gain meaningful access or impact. That context is what separates a theoretical risk from a demonstrated one.

The practical implication is that scanning and testing answer different questions. Scanning answers ‘what known vulnerabilities exist in this environment?’ Testing answers ‘what can an attacker actually do with them?’ Both questions matter, but they are not interchangeable. Organisations that rely solely on automated scanning for security assurance in between penetration tests are answering a smaller question than they may realise.

Final Thoughts

Security testing is, at its core, an act of honesty. It is an organisation choosing to understand its actual exposure rather than its assumed exposure. The gap between those two things is where incidents happen.

The organisations that manage this well are not necessarily those with the largest security budgets. They are the ones that test frequently enough to keep pace with how their environment changes, scope their testing precisely enough to go deep where it matters, and use findings as an active input into risk decisions rather than a compliance artefact to be filed away.

If your last penetration test was more than twelve months ago, or if something significant has changed in your environment since the last one, it is worth understanding what your current exposure actually looks like. The cost of finding out is significantly lower than the cost of finding out the hard way.

This is why at Cyberfort we believe Rapid Pen Testing services fill the gap that most organisations are finding in their quest to become secure and resilient to attack. Penetration Testing should no longer be a once-a-year exercise to meet a compliance standard; it should be something undertaken every time there is a significant change in the IT environment. With the pace of change happening in today’s digital world, those organisations who take the time to test, learn and remediate incrementally and rapidly will be more future ready than those who don’t.

For more information about Cyberfort Rapid Pen Testing services download the datasheet below or contact us at [email protected] and one of our experts will be in touch.

To find out more about the Rapid Pen Testing service click here >

Download Data Sheet >

Procurement teams are quietly turning Cyber Essentials from a routine formality into a condition of doing business. If your Cyber Essentials or Cyber Essentials Plus certification isn’t in place before the next tender lands, you won’t lose on price or capability. You’ll potentially lose before you’re even in the room.

In this article Cyberfort security experts look at why more organisations are now mandating Cyber Essentials and Cyber Essentials Plus as a key requirement for their suppliers. They also cover what it means for businesses bidding for work where this certification is a critical requirement in the procurement process.

Your next lost deal won’t be logged as a lost deal in a traditional way

It will look like a procurement email. A supplier questionnaire returned with a box unticked. A tender portal that quietly closes your submission before anyone reads your pricing. No negotiation, no feedback call, no chance to explain your roadmap. You are removed from consideration on a technicality that was entirely within your control to fix and didn’t.

This is the reality facing UK businesses right now. Cyber Essentials and Cyber Essentials Plus have moved from a ‘nice-to-have’ compliance badge to a pass/fail gate embedded directly into procurement workflows, supplier onboarding portals, and prime contractor due diligence. Procurement teams are quietly turning Cyber Essentials from a routine formality into a condition of doing business.

What’s actually shaping your business priorities

Every board and leadership team we speak to is wrestling with the same set of pressures, protecting revenue in a tighter market, defending margin against rising costs, and proving to enterprise customers and public sector buyers that their supply chain is trustworthy. None of those pressures show up on a spreadsheet labelled ‘cyber security’. They show up as lost tenders, stalled renewals, and contracts that quietly go to a competitor who ticked a box you didn’t know existed.

The market reality is government frameworks have required Cyber Essentials for certain contracts for years, and that requirement is increasingly flowing down through prime contractors into their supply chains. Insurers are asking for it before they’ll quote competitively. Enterprise customers are including it into supplier onboarding as a pass/fail gate, not a nice-to-have. If your business provides products or services into government, defence, financial services, or any enterprise customer with its own compliance obligations, Cyber Essentials and Cyber Essentials Plus are no longer a security decision sitting in IT’s budget. They are a revenue decision sitting in yours.

Your customer’s customer matters here too. When your buyer signs off a contract with you, they are often answering to their own board, regulator, or insurer about the risk you represent to them. Cyber Essentials is one of the quickest, most recognisable ways for them to answer that question without a lengthy audit. If you can’t give them that answer quickly, they will find a supplier who can.

Why it’s time to reframe how you think about certification

The critical success factor most businesses miss with Cyber Essentials and Cyber Essentials Plus is timing, not intent. Almost every organisation we talk to agrees Cyber Essentials matters. Very few have mapped it against their actual sales calendar and what the impact would be if they don’t have the certification in time or let the existing certification lapse after 12 months.

Certification bodies have assessment windows that need to be factored into time to prepare. Cyber Essentials Plus requires technical verification, not just a self-assessment questionnaire, and that takes real preparation – patching, configuration checks, device readiness. If you start the process the week a tender lands, you have already lost the tender. The certification simply won’t be in place before the deadline that requires it.

A lost tender is not a line item, it’s a compounding cost. It’s the contract value you didn’t win, the renewal option you never got the chance to negotiate, and the reference customer you don’t get to point to in your next pitch. Compare that against the cost of certification itself, which is modest, predictable, and entirely within your control. The organisations that treat Cyber Essentials as a line item to budget for later are the ones who discover, too late, that ‘later’ has a closing date attached to it. Usually after the date a tender document lands on their desk. Wait too long to act, and you’ll find the window you were waiting for has already closed.

Additionally, the assumption that Cyber Essentials and Cyber Essentials Plus only applies to certain heavily regulated sectors is starting to be out of date. Many organisations outside of the traditional heavily regulated sectors are now mandating Cyber Essentials or Cyber Essentials Plus in their procurement processes.

This is mainly in response to the high-profile supply chain attacks witnessed across several sectors over the past year. Businesses now expect their suppliers to prove they have security in place and have a achieved a minimum baseline standard. Supply chain risk doesn’t respect industry boundaries. If any part of your customer base sits inside a regulated or security-conscious supply chain and increasingly, most do, the requirement flows downstream to you whether or not your own sector demands it directly.

What certification actually changes for your business

This isn’t about security features. It’s about what certification does to your commercial position.
Cyber Essentials and Cyber Essentials Plus remove a qualification gap before it costs you a deal, not after, when the deal is already gone and you’re trying to work out why the phone stopped ringing.

Practically, this means your business appears on more shortlists, not fewer. Your sales team stops losing time on tenders that were disqualified before the first call. Your renewal conversations become easier, because the compliance question is already answered rather than raised as a last-minute objection by your customer’s own procurement or legal team. And your business becomes the supplier that makes a buyer’s own governance conversation easier, which is a genuine competitive advantage when two suppliers are otherwise evenly matched on price and delivery.

A single missed tender because of a compliance gap in your certification is a one-off cost. A pattern of missed tenders because certification was never prioritised is a structural gap in how much revenue your business can actually access. That’s the number your board should care about, not the cost of certification, but the addressable revenue currently closed off without it.

The businesses that treat certification as a growth enabler, not an IT task, are the ones still winning the deals everyone else quietly loses.

Why this matters beyond your own experience

At Cyberfort we’ve worked with organisations across regulated and security-conscious sectors who assumed their existing security posture was ‘good enough’ to satisfy a customer’s procurement check, only to find that assumption tested and found short at the worst possible moment – mid-tender, with a deadline measured in days rather than weeks.

The pattern is consistent, the businesses that treat Cyber Essentials certification as a proactive commercial safeguard keep their pipeline clean of avoidable losses. The businesses that treat it as a reactive box to fill in when asked, lose deals they never even knew they were being evaluated for.

So where do you actually start?

In the previous sections of this article, we have highlighted the potential impact of not having a baseline security certification like Cyber Essentials and Cyber Essentials Plus. But identifying the problem is only one part of the equation. Businesses need to fix this certification gap before it’s too late. So where should you start?

Begin with an honest audit of where certification already sits in your pipeline, not where you assume it does. Pull your live tenders and your top renewal-risk accounts and ask a blunt question of each one: does this buyer’s procurement process reference Cyber Essentials or Cyber Essentials Plus, explicitly or as a supply chain flow-down from their own customer? Don’t rely on memory or on what came up last time, procurement requirements shift quietly, often without a formal announcement, and the gap is rarely visible until a bid team hits it mid-process.

Next, separate Cyber Essentials from Cyber Essentials Plus in that audit, because they answer different questions for different buyers. Cyber Essentials is a self-assessed baseline – fast to achieve, and increasingly the minimum entry price for public sector and supply chain work. Cyber Essentials Plus adds independent, hands-on technical verification, the level that risk-conscious enterprise buyers and regulated sectors are starting to expect as standard, not as a differentiator. If you don’t know which one your pipeline actually needs, that uncertainty is itself the gap.

With that audit completed, map your certification timeline against your actual bid deadlines, not against a generic “get round to it” schedule. Certification takes real time to prepare for and complete, and that time compresses fastest in the exact quarters when tender volume peaks. If a renewal or a new tender is sitting three months out and you haven’t started, you’re not planning ahead, you’re already behind, whether or not that’s visible yet in your pipeline reporting.

From there, treat certification as a standing commercial control, not a one-off project. Build it into contract renewal reviews, into new business qualification criteria, and into the standard information your sales team gathers before a bid goes to proposal stage. The organisations that get caught out aren’t usually the ones who never considered certification, they’re the ones who treated it as a single completed task rather than a continuously maintained position. Certifications lapse. Buyer requirements change. A gap that didn’t exist in last year’s renewal cycle can exist in this year’s.

Final Thoughts

Finally, put a number on it. If you want that figure for your own business, the actual revenue currently sitting behind a compliance gap you may not know you have, that’s a conversation worth having before your next tender deadline, not after it closes without you. Cyberfort can help you run that audit properly, identifying where certification already gates your pipeline, where it’s about to, and what needs to happen, by when, to make sure the next deal you lose isn’t lost to a gap you had every opportunity to close first.

The businesses that treat this as a live commercial risk, reviewed on a schedule rather than remembered when a customer asks, are the ones who never find out the hard way what “eventually” was worth.

If your business is considering Cyber Essentials or Cyber Essentials Plus and isn’t sure where to start, needs help with the certification process or requires more knowledge about this certification standard talk to a Cyberfort expert. Contact us at [email protected] for more information.

To find out more about the Cyber Essentials service click here >

Download Data Sheet >

There is a pattern playing out inside businesses right now that security teams are only just beginning to grapple with. A business deploys Microsoft Copilot, ChatGPT, Claude or Gemini. The IT team follows the vendor’s setup guide, enables the licence, and rolls it out to users. Within weeks, executives are summarising emails, generating first drafts, and asking questions of their data in natural language. Productivity improves. The board is pleased.

What nobody has checked is what data these AI tools can actually reach.

Because these AI tools don’t create new access, they inherit existing permissions. If a user already had access to a shared drive containing board minutes, financial forecasts, HR records, or sensitive client data, these AI tools can now potentially surface all of it in response to a simple typed question. In many Microsoft 365 environments, permissions have accumulated over years: old shared folders never cleaned up, overly broad access granted to entire departments, files that were never meant to be widely visible sitting in locations that technically anyone with a company login can reach.

The AI tool hasn’t introduced a new vulnerability in the conventional sense. It has simply made the existing one dramatically easier to exploit.

Why This Is Happening Now

The pace of AI adoption inside organisations has outstripped the pace of governance. That isn’t a criticism, it is an observation about how enterprise technology typically evolves. When email was introduced, most organisations didn’t have an email security policy until something went wrong. When staff started using smartphones for work, mobile device management came later. When cloud storage arrived, data classification lagged behind.

AI is following a similar adoption curve, but faster and with higher stakes.

The difference this time is that AI tools don’t just store or transmit data, they actively reason over it, synthesise it, and present it in response to unstructured natural language queries. The implications of overpermissioning are therefore qualitatively different. A misconfigured shared folder in a pre-AI environment might go unnoticed indefinitely. The same misconfiguration in a Copilot-enabled environment for example, can be surfaced to anyone in the organisation within seconds.

Shadow AI adds a further dimension to this problem. While IT departments are managing official deployments, staff are independently signing up for ChatGPT, Claude, Gemini, and a growing range of AI-powered productivity tools. They are pasting customer data, internal documents, and commercially sensitive material into these tools without any visibility from the organisation’s security function. In many cases they don’t know they are doing anything wrong, the tools are freely available, the interface is intuitive, and nobody told them not to.

According to research by ISACA, only 31% of organisations have some form of formal governance in place when it comes to AI. That means the majority of organisations are operating in a space where the rules haven’t been written, the risks haven’t been assessed, and the exposure hasn’t been mapped.

The Three Gaps at the Heart of the Problem

Understanding where the risk actually sits requires looking at three distinct but connected areas.

The data permissions gap. Before any AI tool can be safely deployed, the organisation needs to understand what its users can access and whether that access is appropriate. In most Microsoft 365 environments, this picture has never been properly mapped. Data has accumulated over years, access has been granted ad hoc, and the cumulative effect is a permissions landscape that nobody has a complete view of. AI tools surface this gap in a way that makes it impossible to ignore.

The governance gap. Most organisations don’t have policies that specifically address AI tool usage, data classification in the context of AI, or acceptable use boundaries for generative models. Without these policies, staff have no framework for deciding what is and isn’t appropriate and security teams have no baseline against which to measure behaviour or investigate incidents.

The visibility gap. Shadow AI is, by definition, invisible to the tools organisations use to monitor data flows. Conventional endpoint, network, and SIEM controls are designed to detect known threat patterns. They are not designed to identify when a member of staff pastes a client contract into a public AI tool. This isn’t a gap that can be closed with existing controls, it requires a different approach to monitoring and awareness.

The Questions Boards Are Starting to Ask

As AI governance has moved up the regulatory agenda, with the EU AI Act, FCA guidance on AI in financial services, and ICO attention on AI and personal data, boards and audit committees are beginning to ask questions that security and IT teams are struggling to answer.

What AI tools are currently operating within the business? What data can those tools access? Do we have a policy that governs AI usage? Have we assessed our exposure under relevant regulatory frameworks? How would we know if sensitive data had been processed by an unapproved AI tool?

For many organisations, the honest answer to most of these questions is currently “we don’t know.”

That isn’t a comfortable position to be in. It is, however, a fixable one, and the organisations that address it proactively will be in a fundamentally stronger position than those that wait for a regulatory inquiry or a data incident to force the issue.

When This Becomes Particularly Urgent

There are specific moments when the need for clarity around AI security becomes especially acute. Organisations that are actively rolling out Copilot or another enterprise AI tool are in the highest-risk window, the period between deployment and a proper security review is when exposure is greatest. The same is true when staff are using AI tools without explicit IT approval, when an insurance renewal or regulatory audit is approaching, when a board sign-off on AI investment is required, or when a new CIO, CISO, or CTO joins and needs to understand the existing landscape.

In each of these situations, operating without a clear view of AI security posture isn’t just a technical risk, it is a governance and accountability risk that sits at board level.

What a Structured Review Looks Like

So where should you start when looking at solving these problems with AI adoption in your business? At Cyberfort we encourage all businesses to undertake an AI Security Readiness review before any AI tool is fully deployed. From our experience understanding AI security exposure requires a methodical approach across four areas:

Step 1 — Scoping and Discovery. Establish the boundaries of the assessment: which AI tools are in scope, which parts of the estate will be reviewed, and which stakeholders need to be involved. This step also captures the organisation’s current understanding of its own AI usage, which is often the first point at which shadow AI usage becomes visible.

Step 2 — AI Usage and Exposure Review. Map the AI tools currently operating within the organisation, both sanctioned and unsanctioned. Assess data access permissions, identify overpermissioning in Microsoft 365 or other AI-adjacent environments, and establish a baseline picture of where sensitive data could be reached by AI tools.

Step 3 — Security and Governance Assessment. Evaluate the organisation’s current policies, controls, and monitoring capabilities against the specific requirements of an AI-enabled environment. Identify gaps in policy, monitoring, data classification, and incident response that are specific to AI risk.

Step 4 — Findings, Scorecard, and Roadmap. Produce a clear, executive-readable risk scorecard and a prioritised remediation roadmap. This gives the organisation both the board-level view and the technical detail needed to act.

What Good Looks Like

Organisations that have done this work properly typically come out of it with three things they didn’t have before.

First, a clear and accurate picture of what their AI tools can actually access, which is almost always different from what they assumed. Second, a governance framework that gives staff clarity on what is and isn’t acceptable, reducing the shadow AI risk significantly. Third, a documented security posture around AI that can be presented to insurers, regulators, boards, and enterprise customers when the question arises.

None of this requires stopping AI adoption. The goal isn’t to slow the business down, it is to make sure the speed of adoption doesn’t create a risk profile that leadership hasn’t had the opportunity to consider.

Final Thoughts

The rapid adoption of AI tools represents a shift that is structurally different from the changes that conventional security controls are designed to address. It reshapes how people work and make decisions, rather than simply introducing new technology. It draws on publicly available and organisational data as its raw material. And it has become cheap, easy, and scalable in a very short period of time.

The organisations that understand this are moving from passive awareness to active preparation: mapping their exposure, testing their people, and embedding the procedural controls that make impersonation significantly harder to execute successfully.

If this is an area where your organisation does not yet have a clear and confident answer, it is worth understanding what a structured review would tell you. The gap, once understood, is almost always more addressable than it first appears.

To start that conversation email us at [email protected] or visit cyberfortgroup.com.

To find out more about AI Security Readiness Review service click here >

Download Data Sheet >