AI adoption has outrun AI governance, almost everywhere, almost all at once. If you are the person accountable for cyber security in your organisation, this is not a future risk to plan for. It is a present one you are already carrying, and industry research shows just how big the AI governance problem is for many organisations.

IBM’s 2026 Cost of a Data Breach Report, found that shadow AI – unauthorised AI tools running inside the business without oversight, featured in 43% of AI-related breaches, more than double the 20% recorded a year earlier. This combined with the discovery from AvePoint’s State of AI 2026 Report, that 89.5% of organisations suffered a generative AI breach in the past year, up from 75.1% in 2025, and Okta’s Global CISO Insights 2026, survey highlighting that 81% of CISO’s are worried their AI systems weren’t properly governed shows the scale and potential impact of the AI governance issue many businesses are facing.

In this blog article Cyberfort AI security experts explore why AI adoption is causing AI security governance problems. They also provide practical advice on where organisations need to focus in the future so they can keep pace with the ever-changing AI security governance landscape.

What actually needs attention

The temptation, faced with the research numbers highlighted above, is to focus on the technology – which model, which vendor, which tool to ban or approve. From our experience at Cyberfort that is the wrong focus, and it is why so many organisations are losing ground even as they spend more on AI tools, systems and processes.

The real focus must be governance. Knowing what AI tools are running, what they can access, and who is accountable for it. With Okta’s research also showing that fewer than half of CISOs can confidently say they know where their organisation’s AI agents are, what they can touch, or what they are authorised to do, organisations cannot secure what they cannot see. Unfortunately, right now most organisations cannot see most of their own AI estate.

This matters more for your business, because the attack surface AI creates isn’t abstract. It’s your customer data flowing into a generative tool nobody approved. It’s an AI agent with standing access to a system it was never meant to touch. It’s a well-meaning team member pasting commercially sensitive information into a chatbot to save an afternoon’s work. Each of these is a governance failure before it is a technical one, and each is now common enough to be the rule rather than the exception.

So where should you start? AI governance needs to be focused and concentrated on three areas, visibility into what AI is actually in use across the business; a risk assessment that treats AI systems as the distinct asset class they are, not a subset of general IT risk; and governance that assigns clear ownership.

Why AI Governance is playing catch up

At Cyberfort we have reviewed AI governance across several organisations in the past 3 months. From our customer reviews three clear patterns are emerging as to why AI governance is having to play catch up with tools being deployed.

1. AI adoption inside organisations has moved faster than any previous technology shift, and it has moved largely outside formal procurement.

Nobody files a request to use a generative AI assistant the way they once filed one for a new finance system. It simply arrives, embedded in a browser, a productivity suite, or an employee’s own initiative. That means your existing governance processes, built for sanctioned software rolled out through IT, were never designed to catch it.

2. AI agents are a qualitatively different risk from AI tools.

A chatbot that drafts an email is a data exposure risk. An agent with access credentials, able to take autonomous action across systems, is an operational risk, and the distinction matters because the controls that limit the first do almost nothing to limit the second. The Cloud Security Alliance’s recent research found 65% of organisations experienced an AI agent security incident in the past year. These are not hypothetical scenarios; they are the current state of what is happening in organisations today.

3. Confidence and control have decoupled.

AvePoint’s report found that even as breach rates climbed, organisations’ confidence in their ability to prevent unauthorised AI access also rose. More than 80% described themselves as “very” or “extremely” confident. That gap between how safe leadership believes the organisation to be and how exposed it is, is itself a risk indicator. It suggests many governance programmes are measuring the wrong things or not measuring at all.

The pattern across all three areas is the same. AI has become infrastructure before it became a governed asset. Every day that gap persists, a business’s exposure compounds, because each new AI deployment inherits the ungoverned conditions of the ones before it.

A practical approach to solving the AI governance problem in your business

Closing the AI governance gap is not a one-off project. It is an ongoing discipline, and it has to be built into how your organisation already manages risk, not bolted on as a separate AI workstream that competes for attention and budget.

Start with a proper risk assessment of the AI systems already in use, not the ones you’ve sanctioned. This means identifying shadow AI as deliberately as you would hunt for unmanaged devices on your network, because the two problems are structurally identical. Unknown assets with access to data you are accountable for protecting.

From there, IT and Security teams should build mitigation strategies tailored to specific business domains rather than generic AI policy. A professional services firm’s exposure through client confidentiality is not the same as a manufacturer’s exposure through operational technology, and a governance framework that treats them identically will under-protect one and over-constrain the other.

Then embed best practice around your highest-value data assets. Specifically, the information that would do the most damage if it ended up inside a model you don’t control. Organisations with high levels of shadow AI see breach costs averaging $670,000 higher than those with minimal unauthorised AI deployment (IBM Cost of a Data Breach 2026 report). Protecting your crown-jewel data from ungoverned AI access is not a compliance exercise; it is a direct cost-avoidance measure with a figure attached.

Finally, align all of this with your existing risk engineering approach rather than creating a parallel structure. AI governance that sits apart from your established risk framework will always be the first thing deprioritised when budgets tighten. AI governance that is simply an extension of how you already assess, mitigate, and monitor risk becomes permanent, because it is accountable to the same processes everything else is.

This is precisely where ongoing, specialist support earns its place. AI threats, tooling, and regulatory expectations are moving fast enough that a single assessment, however thorough, is out of date within months. What organisations need instead is continuous consultancy – threat modelling that updates as your AI estate changes, governance that evolves with new tools and new regulation, and technical guidance that turns a risk assessment into an operating discipline rather than a document that sits unopened after the first review.

Why AI Governance needs a specialist security partner, not an internal workaround

AI security governance is a genuinely difficult problem, and it is not one most internal security teams are resourced to solve alone, through no fault of their own. AI threat modelling, agent governance, and secure-AI best practice are specialist disciplines that didn’t exist in most security functions’ remit three years ago. Expecting a team already stretched across conventional threat landscapes to also become AI governance experts overnight is not a resourcing plan – it is a hope.

A specialist partner closes that gap directly. The right AI Security Support & Advisement engagement gives ongoing consultancy and technical guidance to integrate secure AI usage, threat modelling, and governance into your actual internal workflows. Not a generic framework handed over and left with you, but risk assessment of your businesses AI systems specifically, mitigation strategies built for your business domain, and best practices that safeguard your highest-value data assets. Done properly, this aligns with your existing risk engineering approach rather than duplicating it. This results in AI governance strengthening confidence in deploying AI safely across the organisation instead of becoming another initiative competing for attention.

The organisations that will come out ahead over the next year are not the ones that ban AI, and not the ones that adopt it fastest. They are the ones that govern it with the same rigour they apply to every other part of their risk estate continuously, not as a one-off exercise, and with specialist support that keeps pace with how quickly this landscape is moving.

The industry research highlighted at the start of this article are not a warning about some other organisation. Shadow AI nearly doubling its presence in breaches year on year, nine in ten organisations already breached through generative AI, and fewer than half of CISOs confident they know their own AI estate, these are the current conditions your organisation is operating under right now, whether or not that risk has been formally assessed.

The next practical step is straightforward.

Undertake an assessment with a specialist MSSP of what AI is actually running in your business, where it has access, and how exposed your highest-value data is as a result. From there, ongoing specialist advisement turns that one-off clarity into a standing capability, one that evolves as fast as the threats do, rather than falling behind them again within the quarter.

If your organisation needs practical advice on AI security governance and is unsure of where to start, email us at [email protected] to speak to one of our experts.

For more information about Cyberfort AI services click here

In our previous DORA blog article, we covered classifying and reporting an incident once it happens. This blog article looks at the requirement built to reduce how often an incident occurs, proving, before an attacker does, that a critical service can withstand one.

Most financial services firms already run a testing programme. Vulnerability scans happen on a schedule. Penetration tests get commissioned, findings get logged, and a report gets filed somewhere a board member could locate it if asked. On paper, that looks like compliance. Under DORA, it is not.

A distinction worth making immediately, because it shapes everything that follows: DORA requires basic resilience testing of critical and important functions from every in-scope firm. Threat-led penetration testing (TLPT) is a separate, additional obligation that applies only to a targeted set of larger and more systemically important entities, identified by their competent authority.

NOTE: If you are a smaller regulated firm reading this, the testing obligations below still apply to you; the TLPT-specific sections further down may not, unless your authority has told you otherwise.

DORA’s testing regime is built on a different question to the one most testing programmes answer. It does not ask whether you tested something. It asks whether your testing demonstrates that a critical or important function can withstand a realistic attack, and for the firms in scope for the highest tier, whether an independent, authorised attacker has actually tried to break it under conditions that mimic a genuine adversary.

This is a materially higher standard than an annual scan and a penetration test tucked into a compliance folder.

Testing already happens, and happens well

So let’s start with what is working, because it is most of the picture. Financial Services firms have run vulnerability management and penetration testing for years, often to a higher standard than many other regulated sectors. Annual and quarterly scanning cadences are common. External penetration testing against internet-facing infrastructure is standard practice, and many firms already run it more frequently than any regulation requires. Security teams in this sector are not short of testing experience, testing tooling, or testing discipline.

That maturity is real, and it matters. It means the foundation DORA is building on, a technically capable, well-resourced security testing function, is already in place across most of the sector. The gap is not in the testing itself. It is in what the testing is aimed at, how it is structured, and what happens with the result.

DORA tests the business service, not the system

Most existing penetration testing programmes are scoped around infrastructure. An external perimeter, a set of applications, a network segment. That scoping makes sense operationally, but it answers a narrower question than DORA is asking. DORA’s testing framework is explicitly structured around critical and important business functions, the actual services the entity delivers, and the ICT systems that support them end to end, including the third parties involved in delivering them.

This distinction is not superficial. A penetration test that confirms a payment gateway’s external interface is well defended tells you very little about whether the payment service as a whole would survive a coordinated attack that also touches a cloud provider’s authentication layer, an outsourced settlement process, and an internal system nobody thought to scope in. Scenario-based testing – tabletop exercises and live simulations that follow a business service through a plausible failure chain, rather than testing a system in isolation, is a specific DORA requirement precisely because infrastructure-scoped testing misses this.

Then there is TLPT which sits in a different category altogether. TLPT is not a bigger penetration test. It is a live, red-team-style exercise conducted against live production systems, built around real threat intelligence about the actors most likely to target the entity, and run under a formal methodology (in the EU, TIBER-EU) that requires coordination with the entity’s competent authority throughout. For firms in scope, this is required at least every three years, and it requires a level of internal governance, legal preparation and stakeholder buy-in that most organisations have never had to build, because nothing in their existing testing programme has ever demanded it.

The honest complication for most security leaders reading this is your current programme is probably testing the right systems well. It may not be testing the right services at all, and if TLPT applies to you, it is very unlikely to already be structured for it.

So what does this actually mean?

If you run a strong vulnerability and penetration testing function already, the natural instinct is to treat DORA testing as a scope extension, test a few more things, a little more often. That instinct will leave gaps in three specific places which we highlight below:

Remediation evidence – DORA does not just want a list of findings. It wants demonstrable closure. Evidence that every finding was actually resolved, by whom, and by when, tracked with the same discipline as the testing itself. A penetration test report with an unclosed high-severity finding from eighteen months ago is not a testing gap under DORA. It is a governance gap, and it is one of the first things a supervisor will ask to see.

Co-ordination – If threat-led penetration testing applies to your organisation, it cannot be run the way a standard penetration test is commissioned – scoped internally, executed, and reported. TLPT requires engagement with your competent authority before testing begins, a threat intelligence provider to build the scenario, a specialist testing provider accredited to run it, and internal stakeholders – legal, operations, the board, briefed on what a live attack against production systems actually means in practice. None of that exists in a standard testing budget or timeline, and building it under time pressure, close to a deadline, is where firms lose control of the process.

Business service framing – If your testing programme cannot currently produce a mapped inventory of critical and important functions with the ICT systems and third parties that support each one, you cannot yet scope scenario-based testing correctly. Because you do not yet know what a realistic failure chain for that service looks like. This is a dependency most firms do not realise their testing programme has until they try to build a test plan against it.

Where should the focused priorities be

From our experience at Cyberfort when we surface the gaps above, we recommend a four step sequence, so testing is built outward from the business, not inward from the infrastructure you already know how to test.

1. Map before you test

Build or confirm the inventory of critical and important business functions and the ICT systems, including third parties, that support each one. This is the input every other testing decision depends on. Without it, scenario-based testing is guesswork about what to include.

2. Rebuild the testing calendar around services, not systems

Layer scenario-based testing – tabletop first, live exercises second, onto the critical functions identified above, alongside your existing vulnerability assessment and penetration testing cadence. The two should run as one coordinated programme, not two separate compliance activities.

3. Establish remediation tracking with evidence of closure

Every finding, from every test type, needs an owner, a deadline and a closure record that can be produced on request. If this does not already exist as a formal process, it is one of the fastest fixes available and one of the first things scrutinised.

4. TLPT – start the governance work now

Identify your competent authority contact, understand the coordination process end to end, and brief your board and legal function on what authorising a live attack against production systems actually involves. This groundwork takes longer than the test itself.

How do you know if your resilience testing is effective

Testing generates a lot of activity. From our experience at Cyberfort we believe the following measures tell you whether the activity you are undertaking is reducing risk, not just producing reports.

Finding closure rate within agreed remediation deadlines – This is the single clearest signal of whether testing changes anything. A programme that generates findings faster than it closes them is not building resilience, it is building a backlog. Aim for the large majority of findings – vulnerability, penetration test and scenario-based alike, closed within the deadline originally agreed for each severity level.

Time to close critical and high-severity findings specifically – Averages hide the risk that matters most. A programme can look healthy overall while a critical finding on a payment system sits open for months. Track this separately, and aim for critical findings closed in days, not the weeks or months that a blended average might allow.

Proportion of critical and important functions covered by scenario-based testing in the last cycle – This tells you whether your testing programme has actually been reframed around business services, or whether it is still infrastructure-scoped with a new label. Full coverage of the mapped critical function inventory is the target; a partial programme signals scoping work still to do.

Recurrence rate of previously closed findings – A finding that reappears after being marked closed means the fix did not address the underlying cause. This matters more than raw finding volume, because it tells you whether remediation is real or cosmetic. Aim for this to be close to zero, any meaningful recurrence rate is worth investigating on its own.

TLPT and rehearsal governance readiness, if in scope – This is less a number and more a status check. Is your competent authority relationship established, is your threat intelligence input current, and has your board actually been briefed on what the exercise involves. Readiness here should be continuous, not built in the months before the test is due. A programme that starts governance work only when the three-year deadline approaches is already behind.

DORA itself does not prescribe numeric thresholds for any of the measures above; there is no rule stating a specific closure percentage or a specific number of days. The benchmarks here are directional good-practice targets, reflecting what a mature testing programme should be capable of, not figures lifted from a named regulatory standard or study. Set your own thresholds against your risk appetite and the criticality of the function in question and expect a critical payment or settlement service to warrant a tighter target than a lower-tier internal system.

Where you may need further support

Two areas consistently sit beyond what an internal team can build alone, whatever its testing maturity.

The first is threat-led penetration testing itself. Working with an accredited testing provider brings you the outcome that matters. A scenario built on threat intelligence current enough to be credible, and a testing process that has already navigated the competent authority coordination process, rather than one your team is assembling for the first time under deadline pressure, with the governance risk that carries.

The second is business function mapping done to the standard that scenario-based testing needs. The outcome here is a genuine, evidenced understanding of which ICT systems and third parties sit behind a specific critical service, and how a failure would propagate through it, not a list of applications with a criticality label attached. Getting this right is what determines whether everything that follows in the testing programme tests the right thing at all, and it is a different discipline to running the test itself.

A useful first move costs nothing but honesty. Take your current testing calendar and, service by service, ask whether it was built around what the business actually delivers or around the systems your team happens to own. For most firms, that single exercise will surface the gap faster than any external assessment could.

The sequence from there matters. Mapping before testing, testing before remediation evidence, remediation evidence before TLPT governance. Each step makes the next one meaningful, and skipping ahead tends to produce activity without proof. Building that sequence properly, before a supervisor or a real incident forces the pace, is the difference between a testing programme that demonstrates resilience and one that only demonstrates effort.

Next in the DORA series

Testing a service properly tends to expose dependencies that sit outside your own environment entirely – a cloud provider, a sub-processor, a supplier nobody had mapped. That’s where we go in our next blog article – DORA and ICT Third-Party Risk 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.

In this blog article Cyberfort security experts look at what happens when a financial services firms incident management framework is tested for real with an actual incident. They also look at key actions to take when the regulatory clock starts ticking whether your process is ready or not.

Detecting an incident and reporting it on time are two different capabilities. DORA expects both and many financial services firms have invested far more heavily in one than the other.

DORA’s incident management requirements are not, at heart, a reporting exercise. They are a test of whether your organisation can recognise a genuine problem quickly enough, and describe it accurately enough, for a regulator’s clock to be met without guesswork.

That distinction matters because most financial services firms already have monitoring tools, a security operations function and an incident process of some kind. What DORA exposes is whether that process was ever designed to answer regulatory questions under time pressure; severity, impact, cross-border relevance, rather than just internal ones like ‘is this resolved yet’.

So, the practical question for a senior security leader when it comes to Incident Management and DORA is not ‘do we have incident management’. It is ‘can we classify an incident correctly within the first hour, and can we prove with a documented root-cause record that we did, for every major incident, not just the ones that made the board pack’.

Most regulated financial services firms are not starting from a blank canvas when it comes to incident management. Security information and event management platforms, endpoint detection tooling and around-the-clock monitoring are standard across the sector and have been for some time. Anomalous activity detection – the first of DORA’s obligations, is broadly in place, even if it varies in maturity from one firm to the next.

This is the comfortable part of the picture, and it is often where board-level confidence about DORA incident readiness comes from. If asked ‘can we detect an incident’, most CISOs would say yes, and reasonably so.

The comfort stops there, because detecting something and classifying it in DORA’s terms are not the same skill, and the sector’s investment has overwhelmingly gone into the former.

The regulatory clock is more specific than most incident plans assume

It is worth being precise about what that clock actually requires, because the specificity is the point. Once an incident is classified as major, DORA’s technical standards set out a three-stage reporting path: an initial notification within four hours of classification, and no later than twenty-four hours from when the incident was first detected; an intermediate report within seventy-two hours of that initial notification; and a final report within one month. There is no grace period built into any of those windows for a classification process that is still deliberating.

That is the detail an internal incident plan has to be built around, not the general principle that reporting should happen ‘without undue delay’. A four-hour clock that starts at classification, not at detection, makes the speed and consistency of your classification step the single biggest determinant of whether you report on time at all.

Classification and cross-border relevance are where the process breaks

DORA does not simply ask you to notice an incident. It asks you to classify it by severity, impact, and critically, and if it has cross-border relevance, using a standardised methodology that the European Central Bank and national competent authorities expect to see applied consistently, not improvised on the day.

This is where the Incident Management gap actually sits in many financial services firms when it comes to DORA compliance. Classification decisions are frequently made informally, by whoever is on the incident bridge at the time, using judgement rather than a documented methodology. That might produce a reasonable outcome, but it does not produce a defensible one, and it rarely produces a consistent one across incidents six months apart or across different response teams.

Cross-border relevance is a particular blind spot. Many financial services firms operate across more than one jurisdiction. Yet few have a documented, tested method for deciding when an incident in one entity’s systems has implications that another competent authority needs to know about. That decision, made badly or made late, is exactly the kind of gap DORA was written to close.

The four-hour reporting requirement compounds this. That clock does not wait for your classification process to catch up. It starts at the point of classification, and the twenty-four-hour detection ceiling applies regardless. An informal or slow classification step does not buy you time; it simply means you report late, working from judgement, not a stopwatch.

So what does this mean for financial services organisations?

If your organisation can detect incidents well but has never pressure-tested how quickly and consistently it can classify one against DORA’s specific criteria, you have a gap that will not show up until a real incident forces it into the open.

The practical answer is not more detection tooling. It is a documented, rehearsed classification methodology that turns judgement calls into a repeatable process, backed by a root-cause and remediation record that exists for every major incident as a matter of course, not assembled retrospectively when a regulator asks for it.

So where should financial services firms start with building this capability? At Cyberfort we believe there are four key steps organisations should undertake when it comes to building out the reporting capabilities to become DORA compliant. Each step should be built as a sequence, not a single project. Every step depends on the one before it and skipping ahead tends to produce a document that looks complete but has not actually been tested.

1. Document a standardised classification methodology

Define, in writing, exactly how severity, impact and cross-border relevance are assessed and by whom. Not as a judgement call for whoever is on the bridge, but as a repeatable method that produces the same classification for the same facts, every time it is applied.

2. Rehearse it against realistic scenarios agreed deadlines

A methodology that has only ever been read, not used, will not survive contact with a real incident. Run it through tabletop exercises that specifically test the ‘is this major’ and ‘is this cross-border’ decisions, not just the technical response.

3. Build the root-cause and remediation record into the incident process itself

Do not treat root-cause analysis as a follow-up task completed after the pressure is off. Make it a mandatory close-out step for every major incident, owned by a named individual, so the record exists whether or not a regulator ever asks to see it.

4. Establish the reporting and information-sharing pathway before you need it

Know, in advance, exactly who reports to which competent authority, in what format, and how anonymised data feeds into the EU-wide information-sharing frameworks. This should be a pre-agreed pathway, not something worked out during the incident itself.

How do you know if your Incident Response process is working?

When working with Financial Services firms we often find the below measures and management approaches to incident management and reporting tell you whether the 4-step process outlined above is actually working, not just documented.

Time from detection to classification. This matters because DORA’s four-hour reporting clock only starts once you classify an incident as major, so a slow classification step erodes the time you have to report well. Aim to bring this down to well under an hour for anything touching a critical or important function, not days, and ideally not much more than the time it takes to convene the right people.

Consistency of classification outcomes. If two similar incidents, assessed months apart, produce different severity or cross-border judgements, your methodology is not standardised. It is a matter of who happened to be on the call. Track this by periodically re-testing past incident facts against the current methodology and checking the outcome matches. Aim for full consistency; any drift is a sign the documented method has stopped being the one actually used.

Root-cause analysis completion rate. This is the clearest proof that remediation is a genuine discipline rather than a box-ticking exercise once the pressure is off. Aim for a completed, reviewed root-cause record for every major incident, with none left open beyond the timeframe your own process sets for closing them out.

Reporting timeliness against the regulatory window. This is the most visible metric to a regulator and the hardest to fix retrospectively. Aim for full adherence to the four-hour, seventy-two-hour and one-month deadlines for every major incident and treat any near-miss on timing as a signal to fix the classification step upstream, not the reporting step itself.

Tabletop exercise frequency and findings closure. A methodology that is never rehearsed is a document, not a capability. Aim to run realistic incident classification exercises at least annually, with every material finding from each exercise closed out before the next one runs, otherwise you are simply re-discovering the same gap on a yearly cycle.

These figures are directional good-practice targets, not numeric thresholds DORA itself prescribes. Your own risk appetite, the criticality of the functions involved and the jurisdictions you operate in should all shape exactly where you set the bar. The point is to set it explicitly and measure against it, rather than to hit a specific number for its own sake.

Where you’ll likely need further support

Two areas tend to need outside input when it comes to DORA expectations around incident management and reporting, even in organisations with strong internal security teams.

The first is cross-border classification logic. Working out when an incident in one jurisdiction needs to be flagged to another competent authority is a legal and regulatory judgement as much as a technical one. Getting outside support here means arriving at a workable internal standard your team can apply consistently in the moment; built on expertise that has seen how different national authorities actually interpret the requirement in practice, rather than relying on a legal opinion sought for the first time in the middle of a live incident.

The second is independent rehearsal. An incident classification exercise designed and run by the same team that will use it in a real incident tends to test what that team already believes, rather than what a regulator or an external reviewer would actually probe. Bringing in an outside facilitator, unattached to the existing process, means the gap in your methodology is found before a real incident does with a specific, evidenced list of what to fix, rather than a rehearsal that quietly confirms the plan already in place.

Final thoughts

Detection was never the hard part of DORA’s incident requirements and treating it as though it is, is the most common reason organisations misjudge their own readiness. The hard part is classification, consistency and the discipline to produce a defensible record every time, not just when it is convenient. Start there, test it before a real incident does, and the reporting deadline stops being the thing you are afraid of.

Next in the DORA series

Having a documented classification process is one thing. Proving under scrutiny that a critical service can actually withstand a real attack is another. That’s the subject of our next article DORA and Digital Operational Resilience Testing.

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 >