The Digital Operational Resilience Act came into full effect in January 2025 and its implications for UK based firms with EU operations are still being worked through. Many organisations have completed their gap assessments but are now facing the harder challenge of sustainable compliance rather than point in time readiness. The firms that will stay ahead are those treating DORA not as a one off project but as a permanent change to how they manage third party risk and ICT incident reporting on an ongoing basis.

Ask any cyber security leader to name their most significant control gaps and identity will appear in the first three. Yet IAM programmes consistently receive less investment than perimeter security, endpoint protection, and SIEM, despite the fact that the majority of serious breaches involve compromised credentials or excessive access privileges. The problem is rarely technical. It is organisational. IAM sits across HR, IT, and security simultaneously, meaning ownership is diffuse and sustained remediation requires exactly the kind of cross functional governance that most organisations find difficult to maintain.

The majority of cyber transformation programmes that fail to deliver do not fail because of technical complexity. They fail because the business analysis and requirements work at the front end was not done with sufficient rigour. Consultants are brought in to implement solutions before the current state has been properly understood, stakeholders have not aligned on what success looks like, and scope expands to fill the available budget. The fix is methodical and unglamorous: thorough discovery, an honest gap analysis, and a scope agreed in writing before any technology decisions are made.

January 2025 arrived and DORA became enforceable. For many firms, the months before the deadline were spent producing documentation rather than embedding genuine operational change. What we are seeing now is the gap between firms that treated this as a compliance exercise and those that used it as an opportunity to address real weaknesses in their ICT risk management. The regulator's early focus appears to be on the quality of incident reporting and the robustness of third party oversight arrangements, both areas where documentation alone will not be enough.

The NIS2 Directive extended the scope of the original NIS regulations significantly, bringing a far wider range of sectors and organisations within its reach. For UK firms with EU operations or clients, the obligations are real and the penalties for non compliance are material. The most common gap we encounter is not a lack of security controls but a lack of documented evidence that those controls exist and are working. NIS2 is an audit framework as much as a security one, and organisations that have not invested in their evidence management are going to find the first inspections uncomfortable.

Year after year, post incident reviews point to the same root cause: an account with more access than it needed, inadequately monitored, used by an attacker who had more time inside the environment than anyone realised. Privileged access management is not a new discipline. The technology exists. The frameworks are well documented. What is missing in most organisations is not knowledge but governance, specifically the ongoing commitment to review, revoke, and challenge access entitlements as a regular business process rather than a project that runs once and is then forgotten.

With both DORA and NIS2 now finalised and their respective implementation deadlines set for January 2025 and October 2024, organisations across financial services and critical infrastructure have a defined window to get their houses in order. Two years sounds generous. In our experience it is not. Genuine compliance requires changes to governance structures, third party contracts, incident response processes, and in many cases the way IT risk is reported to the Board. Organisations that start treating this as a documentation exercise in month twenty three will not be ready.

The exploitation of the MOVEit file transfer vulnerability in mid 2023 affected hundreds of organisations globally, many of which had no direct relationship with MOVEit and had no idea the software was running anywhere in their supply chain. This is the defining challenge of modern cyber risk management. Your security perimeter is only as strong as your least secure supplier, and in most organisations the visibility into what third parties are running, and how they are protecting it, remains dangerously limited. Third party cyber risk is not a procurement issue. It belongs in the security programme.

The 2022 revision of ISO 27001 introduced meaningful changes to Annex A, reducing the number of controls while adding new ones focused on areas such as threat intelligence, cloud security, and data masking. For organisations already certified to the 2013 version, transition to the new standard is mandatory by October 2025. The changes are not cosmetic. Several of the new controls require genuine capability that many certified organisations do not yet have. Starting the transition work now rather than in the final six months is the difference between a managed process and a scramble.

March 2022 marked the deadline for UK financial services firms to have identified their important business services, set impact tolerances, and begun mapping the people, processes, technology, and third parties that support them. Many firms met the deadline on paper. Fewer met it in substance. The FCA's expectation is that by March 2025 firms will be able to demonstrate they can remain within their impact tolerances during severe but plausible disruption scenarios. The gap between having a documented framework and having a tested, operational one is significant, and three years passes faster than organisations expect.

Financial services firms represent an attractive target for ransomware groups for reasons that go beyond the obvious. The combination of sensitive customer data, regulatory pressure to restore services quickly, and the reputational consequences of prolonged downtime creates conditions where paying a ransom can seem like the path of least resistance. It rarely is. The organisations that recover fastest from ransomware attacks are not those that pay most quickly. They are those that invested in offline backups, tested their recovery procedures, and had a credible incident response process before the attack happened rather than after.

Zero trust has become one of the most overused terms in cyber security, applied to products and marketing materials with enough frequency that its meaning has become genuinely diluted. The core principle, that no user or device should be trusted by default regardless of where they sit on the network, is sound and increasingly important in a world where the perimeter has effectively dissolved. The problem is that most organisations approaching zero trust are buying a product rather than redesigning an architecture. Identity is the control plane of a zero trust model. Without a mature IAM foundation underneath it, zero trust becomes an expensive way to add complexity without meaningfully improving security.

When the UK entered lockdown in March 2020, organisations that had spent years building perimeter security controls watched that perimeter dissolve in a matter of days. Staff were connecting from home networks, on personal devices, through VPN infrastructure that had never been designed to support the entire organisation simultaneously. For many firms, access controls that had worked adequately in an office environment became an immediate liability. The organisations that coped best were not necessarily those with the most sophisticated security tools. They were those whose identity and access management foundations were solid enough to extend to a distributed workforce without collapsing under the pressure.

The early months of the pandemic produced a surge in phishing activity that was unlike anything most security teams had encountered at scale. Attackers moved faster than defenders, exploiting uncertainty around government guidance, HMRC communications, and health information to craft convincing lures that bypassed both technical controls and human judgement. The limitations of once a year awareness training became impossible to ignore. Security behaviours are not built through annual eLearning modules. They are built through regular, relevant, scenario based exposure that keeps pace with the actual threat landscape rather than the one that existed when the training was last updated.

By mid 2020 it was clear that the assumption of a short interruption to normal working had been wishful thinking. Security programmes that depended on on site access for discovery work, stakeholder workshops, and technical assessments had to adapt or pause. What we learned through that period has changed how we approach programme delivery permanently. Discovery work conducted through structured remote workshops, with the right preparation, produces outputs that are comparable in quality to on site engagement. What does not translate well is the informal knowledge transfer that happens in corridors and over coffee. Building deliberate substitutes for those moments is now a standard part of how we plan engagements.

The General Data Protection Regulation came into force on 25 May 2018 after two years of implementation time that most organisations used less effectively than they should have. The final weeks before the deadline revealed a pattern we have seen repeated with every major regulatory change since: a rush to produce privacy notices and consent mechanisms without the underlying data mapping and governance processes to support them. GDPR compliance is not a legal exercise dressed up as a technology project. It is a data governance programme that requires organisations to understand what personal data they hold, where it sits, who has access to it, and what justifies that access. Firms that started with the documentation rather than the data are already behind.

The Information Commissioner's Office moved quickly to establish that the new enforcement regime was not ceremonial. The early cases pointed to a consistent theme: organisations that had failed to implement appropriate technical measures to protect personal data, and had then failed to detect or report breaches within the 72 hour window the regulation requires. Both failures were preventable. The detection problem is primarily an investment issue. Organisations without adequate logging and monitoring capability cannot know what they cannot see. The reporting problem is primarily a process issue. Without a documented and tested incident response procedure, 72 hours disappears in internal escalation and uncertainty about whether a reportable event has actually occurred.

For most of the past decade, cyber security in financial services has been housed primarily within IT functions, resourced as a technology cost, and reported to the Board through a CTO or CIO who had multiple competing priorities. That model is no longer adequate and regulators are increasingly explicit about it. The FCA and PRA have both signalled clearly that they expect cyber risk to be managed at Board level, with accountability structures that treat a serious security incident with the same urgency as a regulatory breach or a major operational failure. Shifting that accountability requires more than a new reporting line. It requires Boards and ExCo members who understand enough about cyber risk to ask the right questions and to know when the answers they are receiving are insufficient.