Navigating Regulatory Incident Response in Finance

Technology teams in the financial sector have always wrestled with changing regulations governing IT resilience and Incident response. These regulations are designed to safeguard client outcomes when using financial products and to minimise risk arising from technical incidents. Interpreting the regulations and understanding what a company needs to implement to meet requirements is a minefield that many Incident Responders and Risk Managers have had to traverse. In today’s financial landscape, regulatory expectations around operational resilience are no longer just a compliance checkbox—they’re a strategic imperative. As regulators sharpen their focus on incident response, firms must evolve from reactive firefighting to proactive resilience. Having led global incident response frameworks across multiple jurisdictions, I’ve seen firsthand how regulation can either be a burden or a blueprint for excellence.Historically, the Monetary Authority of Singapore (MAS) Technology Risk Management standards and guidelines were the most stringent of Incident response frameworks. With explicit downtime reporting regulations, covering rolling annual cumulative downtime, as well as individual incidents, it was always in the back of any financial sector Incident teams mind and defined many of the metrics by which IT resilience was governed. These metrics often determined IT remuneration and fed directly into Board-level reporting, elevating incident response to a strategic priority. Now, other regulatory authorities are introducing more stringent requirements for firms to demonstrate the resiliency of their IT systems and ability to manage incidents in order to deliver the best client outcomes reliably and consistently.

An Evolving Approach

In the UK, historically, the need to report incidents is moving from subjective (under Principle 11), with firms responsible for deciding what was reportable, to a more proactive approach. The Financial Conduct Authority requires firms to identify important business services, identify acceptable impact tolerance levels and test their response to incidents affecting the technology that delivers these business services, ensuring an ability to stay within the acceptable risk threshold. While conceptually straightforward, this demands a deep understanding of business services, their relative importance, and a clear mapping to the technical assets that support them. Importantly, this is not just a technology exercise. Without engagement from a wide range of stakeholders, it's impossible to accurately categorise services in terms of criticality. Typically, this mapping is a project in itself involving a cross-spectrum of stakeholders from across technology and business functions. The FCA’s CP24-28 consultation proposes formalising IT operational risk reporting frameworks. Firms will be required to report operational incidents—including outages, cyber-attacks, and service disruptions—when thresholds are breached. Structured updates and final reports will become mandatory. Additionally, firms must establish internal and external communication plans and conduct root cause analysis. Akin to MAS and Japan’s Financial Services Agency (JFSA) frameworks, this will include initial reporting, interim updates, and a final report within 30 working days of resolution.There is also an increased focus on supply chain, particularly on third-party arrangements (suppliers critical to a firm’s services), and the exposure to their incidents. For companies operating in Europe, this mapping is also required for DORA (Digital Operational Resilience Act). DORA takes the FCA regulations and amplifies the requirements, with firms required to, as a minimum:

• Set up and maintain resilient ICT systems and tools that minimise the impact of ICT risk.
• Identify, classify and document critical or important functions and assets
• Continuously monitor all sources of ICT risks in order to establish protection and prevention measures
• Establish prompt detection of anomalous activities
• Put in place dedicated and comprehensive business continuity policies and disaster and recovery plans, including yearly testing of the plans, covering all supporting functions
• Establish mechanisms to learn and evolve both from external events as well as the entity’s own ICT incidents

The reporting requirements alone make having an efficient incident management process a must. Once companies have identified critical services, in the event of an incident, they quickly need to understand whether it meets reporting thresholds. Significant incidents then need to be reported with as accurate information as is available, as soon as possible, even if the incident is still ongoing. A capable incident team will need to simultaneously be managing the incident, the recovery and the reporting/communication. Information such as how many clients / financial counterparts / transactions affected is often not easily available, increasing complexity. Reputational impact is not always easy to determine objectively, so having an operational risk matrix/framework in place prior to the incident occurring is a must for quick evaluation of impact. This is in addition to traditional Incident Management metrics such as downtime, duration, severity, data impact or financial impact. A mature incident management team will be used to communication and reporting, at least internally. But reporting to regulators is a more onerous and detailed exercise, and some more nascent or immature Incident management processes may struggle with this requirement; if incidents are frequent, without a solid process in place, this will become burdensome. This marks a shift from subjective reporting to a rules-based, threshold-driven model. Firms must now build internal mechanisms to assess impact in real time and engage regulators with precision.Building incident response frameworks often began with interpreting regulatory requirements and translating them into operational language the wider firm could understand—particularly around identifying which services were truly critical under the criteria determined in regulation. Success depended not only on accurate analysis and process design but also on having a team with the right skill sets to execute swiftly and confidently. A recurring challenge was over-reliance on senior staff for decision-making during major incidents. Despite having detailed runbooks, junior team members were often hesitant to determine reportability or manage concurrent workstreams without escalation, resulting in reliance on a few key individuals.. To mitigate this, we focused on preparing the team to operate under pressure—without fear of regulatory scrutiny—reducing key-person dependency and improving overall resilience.Standard tabletop exercises frequently fell short of mimicking the stress and complexity of real incidents. While useful for validating expected responses, they rarely tested the team’s ability to navigate ambiguity or make rapid decisions in dynamic scenarios. Prescriptive drills, such as toggling systems or sending dummy communications, may satisfy audit requirements but offer limited practical value. Any exercise with true value gives experiences that enrich a future response rather than ticking an auditory box. It's often the unexpected that challenges incident managers and responders. Challenging people to think outside of the linear path is what really develops incident responders into people who can make quick and clear decisions irrespective of changing or challenging scenarios. To try and make drills as lifelike as possible, we used Uptime Labs to simulate bespoke, high-impact scenarios tailored to our critical services. These immersive exercises gave responders the confidence and capability to manage real incidents effectively.Drills were conducted regularly by our Incident Responders, with outcomes documented to track progress and identify areas for improvement. This built trust in the team’s ability to manage incidents end-to-end—from detection and containment through to recovery, communication, and root cause analysis. The team became well-practised, audit-ready, and capable of meeting regulatory Incident management and reporting expectations.

Regulation as a Catalyst

Regulation is evolving from prescriptive to performance-based. It’s no longer enough to say you’re resilient—you must demonstrate it. As reporting requirements increase, more incidents will be reportable as the rules tighten. Teams will need to be more organised, better drilled and have more visibility over impact more quickly. The firms that thrive will be those that treat regulatory frameworks not as constraints, but as catalysts for operational excellence.