There is a question that should be on every CISO and CRO's desk in the Gulf right now: do you have a current, accurate, and honest baseline of the threats facing your business-critical applications?
Not a threat register that was last reviewed eighteen months ago. Not a penetration test result from a system that has since been significantly changed. A live, structured, continuously maintained picture of who wants to attack your most important systems, how they might do it, and what your current exposure actually is.
If you cannot answer that question with confidence, you are not alone — but you are exposed.
Why the Threat Landscape Has Shifted
Nothing makes the case for a current, honest threat baseline more powerfully than what happened on 1 March 2026.
In the immediate aftermath of the US and Israeli strikes on Iran, Iranian drone and missile attacks hit three AWS data centres across the UAE and Bahrain — two facilities in the UAE and one in Bahrain — causing fires, power outages, and structural damage that forced multiple availability zones offline simultaneously. The consequences for UAE banking were immediate and material. Abu Dhabi Commercial Bank, Emirates NBD, and First Abu Dhabi Bank all experienced service disruptions, alongside payments platforms and enterprise software systems across the region.
What made this particularly significant from a resilience and security architecture standpoint was not just that the attacks happened — it was that the standard redundancy model failed. AWS's multi-availability-zone architecture, which had always been designed to protect against power outages, natural disasters, and infrastructure failures, had never been stress-tested against a coordinated physical attack that damaged multiple zones within the same region simultaneously. Two out of three cloud availability zones in the UAE region went down together. The assumption that geographic distribution within a region provided adequate protection was exposed as insufficient.
The IRGC was explicit about its targeting logic. Following the strikes, Iranian state media published a list of designated targets that included the UAE and Bahrain infrastructure of AWS, Google, Microsoft, IBM, Oracle, and Nvidia — framing commercial data centres as legitimate military objectives due to their role in supporting US and allied military workloads. Whether that targeting rationale is accepted or not is largely beside the point for a CISO: the practical reality is that Gulf-based cloud infrastructure has now been attacked, banks have experienced outages as a direct result, and the threat model that most organisations were operating against did not include this scenario.
Geopolitical escalation does not just create physical and operational disruption. It creates a new and very specific category of threat — one that sits between traditional cyber attack and physical infrastructure risk — that most enterprise security frameworks were not built to address.
State-affiliated actors, opportunistic criminal groups, and hacktivists are all emboldened by regional instability. Research tracking ransomware activity showed over 800 claimed victim organisations in a single month in late 2025 alone. But the March 2026 data centre strikes represent something qualitatively different: a direct, deliberate attack on shared commercial infrastructure, with cascade consequences for every institution that depended on it.
The threat is not abstract. It is present, it is directional, and for too many Gulf organisations, the current threat model is already out of date.
The Problem with Reactive Security
For years, the dominant model in financial services cybersecurity was prevention-led: build stronger walls, tighten controls, and stop attackers from getting in. That model no longer reflects reality.
Digital footprints across the sector are expanding rapidly — driven by multi-cloud deployments, real-time payment APIs, mobile-first customer experiences, and deepening integration across partner ecosystems. Each connection is a potential entry point. Each new deployment potentially shifts the threat landscape. And traditional security approaches — static assessments, periodic scans, annual penetration tests — simply cannot keep pace with the speed at which these environments change.
The consequence is a growing gap between what organisations believe their exposure to be and what it actually is. That gap is where attacks happen.
Threat modelling closes that gap. It provides a structured, systematic approach to understanding what assets matter most, what threats are most plausible against those assets, and where controls are weakest relative to the risk they are supposed to manage. Critically, done well, it transforms security from a reactive checklist into a continuous, risk-informed discipline embedded throughout the organisation.
Starting with a Baseline: How to Begin
For organisations that have not yet established a formal threat modelling practice, or where existing frameworks have not been revisited since the regional risk environment changed, the starting point is a structured baseline assessment. This means:
Identifying your crown jewels. What are the applications, data stores, and systems that, if compromised, would cause material harm to the organisation? For a bank, this typically means core banking platforms, payment processing infrastructure, customer identity and authentication systems, and regulatory reporting environments. These are your priority scope.
Mapping your architecture and trust boundaries — including your cloud assumptions. Threat modelling requires an honest picture of how your systems are structured, how data flows between them, where external connections exist, and where trust assumptions have been made. Many organisations are surprised, during this exercise, to discover undocumented integrations, deprecated systems still receiving data, or third-party connections that were never formally risk-assessed. But the March 2026 events add a new and urgent dimension: the assumption that multi-availability-zone cloud architectures provide unconditional resilience must now be explicitly challenged. Senior cloud architects have been direct on this point since the UAE outages — data residency requirements meant that organisations attempting to failover to alternative regions during the crisis risked moving sensitive customer data outside national borders, potentially breaching regulatory obligations in the very moment they were trying to restore service. Your threat model must account for this tension.
Applying a structured framework. The STRIDE methodology — which analyses systems across the dimensions of Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege — remains one of the most widely used frameworks for application-level threat analysis. PASTA (Process for Attack Simulation and Threat Analysis) offers a more business-outcome-focused approach that resonates well at executive and Board level. OCTAVE provides a risk-centric methodology suited to organisations assessing enterprise-wide exposure. The right choice depends on your context, but the choice matters less than the commitment to structured, repeatable analysis.
Prioritising and remediating. A threat model without a clear output — a prioritised set of risks with identified mitigating controls — is an academic exercise. The value is in the decisions it drives: which vulnerabilities to address first, which architectural changes to make, which controls to strengthen, and where investment in additional capability is warranted.
The Role of Automation: Moving from Point-in-Time to Continuous
The most significant development in threat modelling practice over the past two to three years is the emergence of automation tooling that makes continuous, embedded threat modelling genuinely achievable — not just aspirational.
Historically, threat modelling was a specialist activity: expensive, time-consuming, and typically performed during major design reviews or after significant incidents. That model does not scale to the pace at which modern financial services environments change.
Automated threat modelling platforms — tools such as IriusRisk, ThreatModeler, and the growing category of LLM-augmented threat analysis tools — are changing this calculus materially. They allow security and development teams to integrate threat analysis into the design and build process, maintaining a living model of architectural risk rather than a series of point-in-time snapshots.
The capabilities these platforms bring include automated threat identification from architecture diagrams and data flow documentation, pre-built threat libraries mapped to financial services contexts, integration with existing frameworks including DORA, NIST 800-53, and regional regulatory requirements, and continuous updating as systems change. Critically, they lower the barrier for teams that do not have deep security expertise to participate meaningfully in threat analysis — which matters enormously for Gulf organisations where specialist security talent remains a competitive resource.
One important caveat: even the most sophisticated threat modelling tooling has traditionally focused on logical and cyber threats — the attack paths that traverse software, networks, and identity systems. The events of early 2026 have created pressure on the field to more formally integrate physical infrastructure threat scenarios, particularly for organisations whose critical applications run on shared cloud infrastructure in regions that have now demonstrably come under physical attack. Leading platforms are beginning to incorporate physical and hybrid threat vectors, but this remains an area where human judgement and scenario planning must complement automated analysis.
Emerging research into LLM-based threat modelling automation for banking systems — using techniques such as Chain of Thought prompting and fine-tuned models against domain-specific datasets — points to a near-term future where the analytical work of threat identification becomes substantially machine-assisted, with human judgement applied at the prioritisation and decision layer. This is not science fiction. It is being piloted now.
What Good Looks Like
For Gulf organisations — banks in particular — moving toward a mature threat modelling capability means building three things simultaneously:
A living asset inventory and architecture baseline. You cannot model threats against systems you have not accurately mapped. This foundational work, often underinvested, is the prerequisite for everything else.
A repeatable, tooled process. Threat modelling should not depend on the availability of a single specialist or the memory of a design decision made three years ago. Automation tools, combined with clear process ownership, allow organisations to scale the practice across their application portfolio.
Executive and Board visibility. Threat models produce risk outputs that are inherently strategic — they tell you, in business terms, where your most material exposures are. This information belongs at the top of the organisation, informing investment decisions and risk appetite conversations, not confined to a security team's internal documentation.
The Window Is Now
The Gulf's financial services sector is rebuilding. New infrastructure is being designed and deployed. Cloud migrations are accelerating. Payment systems are being modernised. Every one of these transformation programmes is an opportunity — and an obligation — to design security in from the outset rather than retrofit it afterward.
But "the window is now" carries a sharper meaning after March 2026 than it did before. The organisations whose threat models included physical attack on cloud infrastructure, whose continuity plans explicitly addressed multi-AZ failure scenarios, and whose security architecture had modelled dependency on shared hyperscaler infrastructure — those organisations recovered faster and made better decisions under pressure. The organisations that had not done that work discovered the gap at the worst possible moment.
Threat modelling is not a compliance task. It is the discipline that tells you whether the system you are building, or operating, is actually safe to run in the environment you are actually operating in — not the environment you assumed you were in. In the Gulf in 2026, those two things are no longer the same.
At VerityX, our Core practice works with banks and enterprises across the Gulf to build exactly this kind of embedded security capability — from threat modelling foundations through to governance, identity, and data resilience. The work is practical, it is executable, and it is designed to produce outcomes that last.
The question is not whether your organisation needs a current threat baseline. It does. The question is whether you will build it before or after something goes wrong.
Mark Rothwell Brooks is CEO of VerityX, a specialist transformation consultancy for banks, regulators, governments, and mission-critical enterprises. VerityX's Core practice drives execution across Data, Cyber, Identity, and Resilience — including threat modelling programmes for financial services organisations across the Gulf region.
