Financial sector cyber incidents more than doubled between 2024 and 2025, rising from 864 recorded cases to 1,858, according to recent research, accounting for roughly 18 to 19 percent of all cyberattacks worldwide that year.
The regulator's response has been a wave of updated and tightened frameworks:
- PCI DSS 4.0.1 with all requirements now mandatory as of March 2025
- DORA is fully enforced across EU financial entities
- SEC’s cybersecurity disclosure rules require public companies to report material incidents within four business days.
The pressure is no longer theoretical, and it is no longer aimed only at security outcomes. Regulators are increasingly examining the architecture that produces those outcomes and are seeing where it can be improved.
That shift matters because it changes what “compliant” actually means in a cloud environment. Passing an annual audit has never been the same thing as being secure, but for a long time, the gap between the two was manageable.
As regulatory frameworks have grown more technically specific, particularly around how cloud infrastructure must be configured, monitored, and controlled, that gap has become harder to paper over.
Banks that designed their cloud environments without compliance requirements baked in are now discovering that fixing the gap is not a configuration tweak. It involves rearchitecting access controls, rebuilding logging infrastructure, restructuring network segmentation, and in some cases re-platforming services entirely.
Banking cloud security and compliance are not two workstreams that run in parallel and eventually meet. They are the same set of decisions, made at the architecture level, and the cost difference between making those decisions at the start versus making them under regulatory pressure is substantial.
This article covers what that actually looks like in practice.
Key Threats to Banking Cloud Security
While every industry faces cloud security risks, banks operate under a specific set of pressures: higher regulatory scrutiny, richer data targets, and a threat landscape that is deliberately focused on financial infrastructure. Understanding the most common attack vectors is not just a technical concern; it shapes the architectural decisions that follow.
Ransomware Attacks
Financial institutions are among the most targeted sectors for ransomware, in part because the cost of operational disruption is so high that paying a ransom can seem faster than recovering. Ransomware typically enters through phishing emails or unpatched vulnerabilities in cloud infrastructure. Once inside, it can encrypt critical files, disrupt core banking operations, or exfiltrate customer data and threaten to release it publicly unless a payment is made. The damage extends well beyond any ransom itself: incident response costs, regulatory notifications, reputational damage, and potential fines for data exposure all follow.
How to defend against it:
- Implement strict email filtering and phishing simulation training so that malicious emails are blocked automatically, and staff can recognize the ones that aren’t.
- Distribute critical workloads across multiple environments so that a compromise in one area does not bring down the entire operation.
- Maintain isolated, regularly tested backups of critical data in a separate environment from production, ensuring recovery is possible without paying.
- Establish and rehearse incident response procedures specifically for ransomware scenarios, including regulatory notification timelines.
Software Supply Chain Attacks
Cloud platforms make it easy to incorporate third-party services, libraries, and APIs, but each external dependency is a potential entry point. A vulnerability in a vendor’s code, or a compromise of the vendor itself, can propagate directly into your environment. Banks are also exposed to attacks directed at their cloud providers: as a client of a compromised provider, the attack is not aimed at you directly, but you bear the consequences.
The SolarWinds attack in 2020 demonstrated at scale how deeply supply chain compromises can reach into organisations that never considered themselves the primary target.
How to defend against it:
- Apply Zero Trust principles to all third-party services: continuous verification of identities and permissions, least-privilege access, and timeout periods for all connections.
- Conduct structured vendor security assessments before onboarding new dependencies and on a regular basis thereafter, covering access controls, compliance posture, and incident history.
- Monitor third-party integrations for anomalous behaviour rather than assuming that vetted vendors remain safe indefinitely.
- Establish contractual requirements for security standards with all software vendors and cloud service providers, including the right to audit.
Insider Threats
Not every security failure originates from an external attacker. Employees, contractors, and business partners with legitimate access to cloud systems can introduce risk through malicious intent, careless credential management, or successful social engineering.
A staff member who reuses passwords across personal and work accounts, or who shares access credentials informally to solve a short-term problem, can create an opening that is indistinguishable from a legitimate login until the damage has already been done. In cloud environments, where access can be provisioned quickly and privileges tend to accumulate over time, unreviewed access rights are a consistent vulnerability.
How to defend against it:
• Define and enforce role-based access control (RBAC) with clearly scoped permissions for every user role, and audit those permissions regularly.
• Automate user deprovisioning to ensure that access is revoked promptly when employees leave or change roles.
• Require multi-factor authentication for all privileged access, and enforce session timeouts for sensitive systems.
• Run regular security awareness training, with particular focus on social engineering tactics and credential hygiene.
Credential Stuffing and Account Takeover
Credential stuffing involves attackers using automated tools to test large volumes of stolen username and password combinations against banking systems. The success rate per attempt is low, but the scale at which these attacks operate makes even a small percentage of successful logins significant.
The risk is compounded by the fact that many users reuse credentials across multiple services, meaning a breach somewhere entirely unrelated can become a banking security problem years later. A single successful account takeover in a banking context can expose not just one customer’s data but transaction histories, linked accounts, and identity documentation.
How to defend against it:
• Enforce multi-factor authentication across all customer-facing and internal systems.
• Implement continuous monitoring for anomalous login patterns, including multiple failed attempts, logins from unusual locations, and rapid sequential access attempts.
• Rate-limit authentication endpoints and deploy bot detection to interrupt automated credential testing before it reaches meaningful scale.
• Maintain visibility into known credential breach databases to proactively identify when employee or customer credentials have been exposed elsewhere.
API Exploits
Open banking regulations have accelerated open API and PSD3 adoption across financial services, creating rich integration surfaces between banks, fintechs, and third-party providers.
That same openness makes APIs a consistent target. Vulnerable API endpoints can expose customer data, allow unauthorised transactions, or provide a pathway into internal systems if authentication is insufficiently rigorous. Common weaknesses include broken object-level authorisation, where an attacker can access another user’s data by modifying an ID in a request, and insufficient rate limiting, which allows attackers to enumerate data or brute-force authentication at scale.
How to defend against it:
• Conduct regular API penetration testing, specifically targeting authentication bypasses, authorisation flaws, and injection vulnerabilities.
• Enforce strict input validation and output encoding on all API endpoints to prevent injection-based attacks.
• Implement rate limiting and anomaly detection on API traffic to identify and interrupt unusual request patterns before they become breaches.
• Maintain a complete and current inventory of all exposed API endpoints, including deprecated ones, since legacy endpoints are frequently overlooked in security reviews.
Softjourn’s work with financial institutions across fintech and banking covers the full range of these threat scenarios, from PCI DSS-compliant cloud architecture to secure API design and access control frameworks. The sections below address the architectural and compliance decisions that defend against all five.
Softjourn’s work with financial institutions across fintech and banking covers the full range of these threat scenarios, from PCI DSS-compliant cloud architecture to secure API design and access control frameworks. The sections below address the architectural and compliance decisions that defend against all five.
What Regulatory Frameworks Actually Demand in a Cloud Context
There is a tendency, particularly among teams preparing for their first cloud-based audit, to approach regulatory frameworks as lists of boxes to check. Read that way, PCI DSS becomes a set of encryption requirements, DORA becomes a business continuity document, and GDPR becomes a consent management problem. That reading is not wrong, exactly, but it misses the architectural dimension of what these frameworks are actually asking for.
PCI DSS 4.0.1
With all requirements now mandatory as of March 31, 2025, PCI DSS 4.0.1 represents the most technically specific version of the standard to date. In a cloud context, it requires banks and payment processors to define and maintain a clear cardholder data environment, which is considerably more complex in a shared cloud infrastructure than it was in a physical data center.
Requirement 1 mandates network security controls that segment cardholder data from everything else, meaning environment isolation is not optional. Requirements 7 and 8 govern access control and identity management in ways that map directly to how IAM roles and policies must be configured in AWS, Azure, or GCP.
In practical terms, PCI DSS 4.0.1 shapes decisions about how environments are structured, how services communicate, who can access what and under what conditions, and how every meaningful event is recorded and stored.
DORA (Digital Operational Resilience Act)
Fully enforced across EU financial entities since January 2025, DORA goes further than most frameworks in specifying how institutions must manage technology risk, including risk introduced by third-party cloud providers.
It requires documented ICT risk management frameworks, regular resilience testing, and specific contractual arrangements with cloud service providers covering audit rights, data portability, and exit strategies.
For banks running on AWS, Azure, or GCP, DORA effectively means that concentration risk is a compliance issue, not just an operational one. An institution that has moved its critical workloads to a single provider without a documented resilience and exit plan is not DORA-compliant, regardless of how well-configured that environment is.
SOX (Sarbanes-Oxley Act)
SOX requirements in a cloud environment concentrate primarily on financial data integrity and access control. Section 404, which governs internal controls over financial reporting, requires that any system touching financial data be covered by documented controls, regular testing, and clear audit trails.
In cloud terms, this translates to questions about who provisioned which resources, who changed which configurations, and when. Infrastructure-as-code practices, combined with robust change management logging, are among the most reliable ways to produce the kind of audit evidence SOX reviewers look for.
GDPR
For banks operating in or serving customers in Europe, GDPR adds a layer of requirements around data classification, data residency, and the right to erasure that interact in complicated ways with cloud storage architecture.
Data residency requirements mean that where data physically lives inside a cloud provider’s infrastructure matters, not just how it is protected. The right to erasure requires that personally identifiable information can be located and deleted reliably, which has direct consequences for how databases are structured and how backup and archival systems are designed.
The common thread across all four frameworks is that they are not asking for security as an outcome to be demonstrated after the fact. They are asking for controls, structures, and documentation that must be built into the environment from the beginning to function as required.
Key Threats to Banking Cloud Security
While every industry faces cloud security risks, banks operate under a specific set of pressures: higher regulatory scrutiny, richer data targets, and a threat landscape that is deliberately focused on financial infrastructure. Understanding the most common attack vectors is not just a technical concern; it shapes the architectural decisions that follow.
Compliant on Paper vs. Compliant in Practice
Passing a compliance audit and maintaining a genuinely secure cloud environment are related, but they are not the same thing.
The distinction matters more in cloud environments than it did in traditional on-premise infrastructure, for a reason that is easy to overlook: cloud environments are not static.
A point-in-time audit captures a snapshot of that environment on a specific day. What happens between audits is where most real-world security failures occur.
The Misconfiguration Problem
Cloud misconfiguration is one of the most consistent sources of security exposure in financial services, and it is rarely the result of negligence.
More often, it happens because cloud environments move faster than the policies governing them.
A developer spins up a storage bucket with overly permissive access settings to solve an immediate problem. An IAM role gets broad permissions during a testing phase and none of these is a dramatic failure. They accumulate quietly, and they are invisible to an auditor who reviews documentation rather than live configuration state.
The gap between documented security policy and actual environment configuration is sometimes called policy drift, and it is endemic in organizations that treat compliance as a periodic review process rather than a continuous operational discipline.
The Audit Evidence Problem
Most compliance frameworks require evidence, not just assertion. PCI DSS requires log retention and tamper-resistance. SOX requires documented change management and access control testing. DORA requires ICT risk assessments and resilience test results. Producing that evidence for an audit is manageable if the systems generating it were designed to do so from the start.
Producing it after the fact, by reconstructing logs, manually documenting controls, or retroactively mapping architecture decisions to framework requirements, is time-consuming, error-prone, and often incomplete.
Banks that build code audit evidence collection into their infrastructure, through automated logging pipelines, immutable audit trails, and policy-as-code tooling, spend significantly less time preparing for audits and produce more reliable evidence when they do. Banks that treat audit preparation as a separate project, standing up in the weeks before a review, tend to find gaps they cannot fully close in time.
What Regulators Are Actually Looking For
It is worth being direct about what has changed in how regulators approach cloud environments. The FFIEC Cybersecurity Assessment Tool was retired in August 2025, with regulators explicitly encouraging institutions to adopt frameworks like NIST CSF 2.0 that treat cybersecurity as a continuous risk management discipline rather than a scored assessment.
DORA’s resilience testing requirements are operationally focused, asking institutions to demonstrate that their controls actually work under pressure, not just that the controls exist on paper. PCI DSS 4.0.1 introduced customized implementation options that give institutions more flexibility, but also more responsibility to demonstrate that their chosen controls meet the intent of the requirement.
The direction of travel across regulatory frameworks is consistent: away from point-in-time checkboxes and toward continuous, demonstrable control effectiveness. An architecture that was designed for periodic audit readiness is increasingly out of step with what regulators expect to see.
Ukrainian Processing Center (UPC), a key player in Ukraine’s financial sector supporting card transactions and ATM services across 15 European countries, partnered with Softjourn to migrate its Open Banking and E-Commerce platforms from on-premise infrastructure to AWS while maintaining full PCI DSS compliance throughout the transition.
Softjourn proposed a phased, serverless migration strategy built entirely on infrastructure-as-code using Terraform. Using only native AWS serverless services was a deliberate compliance decision required to meet the stringent audit requirements of the PCI DSS assessment.
The result was a scalable, cost-efficient cloud environment with improved performance and a compliance posture built into the architecture rather than applied after the fact.
When Compliance Is the Migration Goal, Not the Afterthought
The UPC migration illustrates what happens when compliance requirements shape architectural decisions from the start.
The Bullet case study illustrates something slightly different but equally instructive: what happens when achieving regulatory approval is the explicit business objective driving the migration, not a condition to be satisfied along the way.
Bullet, an Irish accounting software provider serving SMEs, enterprises, and financial institutions, needed to meet Central Bank of Ireland regulatory requirements to operate and expand in the Irish market. CBI licensing is not a minor compliance checkbox.
It requires demonstrable high availability, robust disaster recovery, secure data management, and the kind of infrastructure documentation that regulators can audit with confidence.
Bullet’s legacy monolithic architecture could not satisfy those requirements, and the path to CBI licensing ran directly through a full infrastructure overhaul.
Softjourn led a migration from the legacy monolith to a scalable, AWS-based architecture designed specifically around the CBI’s technical requirements.
The new infrastructure incorporated zero-downtime deployment, multi-zone availability so that if one availability zone failed the system would remain operational in another, automated database snapshots stored on S3, and CloudWatch-based observability across all system components.
Every architectural decision was evaluated against what the CBI would need to see in an audit, not against what was fastest or cheapest to build.
The outcome was significant beyond the technical results. Bullet became one of the few CBI-licensed AWS resellers in Ireland, a competitive position that opened new market opportunities with banks and larger financial institutions that required that level of regulatory credibility from their software partners.
That framing applies well beyond this single migration. When compliance is treated as a trust problem rather than a paperwork problem, the architectural decisions that follow tend to be more durable and more defensible under scrutiny.
Policy as Code
One of the most practical approaches to continuous compliance in cloud environments is treating security and compliance policies the same way development teams treat application code: version-controlled, automatically tested, and enforced through tooling rather than manual review.
Tools like AWS Config, Azure Policy, and Open Policy Agent allow organizations to define what a compliant configuration looks like and automatically flag or remediate deviations as they occur, rather than discovering them during a quarterly review.
When a storage bucket is provisioned with public access enabled, a policy-as-code rule can catch it immediately, before it reaches production and before it becomes an audit finding.
Automated Monitoring and Alerting
Continuous compliance also requires visibility into what the environment is actually doing at any given moment, not just what it is configured to do. Automated monitoring using AI and ML covers configuration state, but behavioral monitoring covers runtime activity: unusual access patterns, unexpected data transfers, authentication anomalies, and service-to-service communication that falls outside defined parameters.
For financial institutions, this level of monitoring serves dual purposes. It is a security control that can detect and respond to threats in near real time, and it is also the source of the audit evidence that regulators increasingly expect to see. An institution that can produce detailed, timestamped records of access activity, configuration changes, and anomaly detections across its cloud environment is in a fundamentally stronger position during a regulatory review than one that reconstructs that picture from scattered logs ahead of an audit deadline.
The Organizational Side of Continuous Compliance
Technology alone does not produce continuous compliance. The organizational model has to support it.
Compliance cannot be owned exclusively by a legal or risk team that reviews documentation periodically while engineering teams build and deploy independently. Equally, it cannot be delegated entirely to security engineers who lack the context to understand what the business actually needs to operate.
The institutions that manage this well tend to build shared ownership into their development and operations workflows, embedding compliance checks into CI/CD pipelines, making security review part of the standard deployment process, and ensuring that the teams building cloud infrastructure understand what the regulatory requirements actually ask of them.
This is less about adding compliance staff and more about making compliance requirements legible to the people making day-to-day architectural decisions.
The Cost of Retrofitting
The case for building compliance into cloud architecture from the start is ultimately a financial one, and it is not particularly close. Retrofitting compliance onto a live banking cloud environment is expensive in ways that are easy to underestimate when the decision to defer is made.
The most visible costs are the direct ones:
- the engineering time required to rearchitect access controls,
- Rebuild logging infrastructure,
- Restructure network segmentation
- Re-platform services that were deployed without compliance requirements in scope.
In a production environment, none of that work happens without risk management overhead, testing cycles, and careful sequencing to avoid disrupting live operations. Work that would have taken days during initial build can take months when done around a system that cannot go offline.
What Non-Compliance Actually Costs
The penalty landscape for financial institutions makes the engineering cost of retrofitting look modest by comparison.
According to PwC's Global Compliance Survey 2025, regulation is adding unprecedented complexity and cost to companies. Some have adapted by becoming "compliance pioneers," evolving their processes, technology, and talent models to mitigate risk and surface new insights. Others have lost momentum, with management attention pulled away from strategic goals. The survey gathered feedback from 1,802 executives across 63 territories and a broad industry mix, and points to where compliance teams will need to step up next:
- 71% of executives expect to undertake digital transformation initiatives over the next three years that will require the support of Compliance.
- 41% say they need Compliance support tied to new business models.
- 54% of respondents work at companies with annual revenues over $1 billion, signaling that this shift is happening at scale.
- Financial services (29%) and industrial products and services (20%) lead the industry mix, followed by TMT (14%), consumer markets (14%), and health industries (10%)
Transaction monitoring violations accounted for more than $3.3 billion of that total, a 100% increase from the prior year. These were not penalties for exotic or one-off failures. They were, in many cases, the result of compliance controls that had not kept pace with the scale and complexity of institutions’ technology environments.
TD Bank’s $3.09 billion fine in 2024 for systemic AML compliance failures stands as one of the largest in US regulatory history, and it came with a four-year independent monitorship that effectively put the bank’s compliance program under external supervision for the better part of a decade.
Santander UK was fined £107.7 million by the FCA in 2023 for prolonged weaknesses in its KYC and AML controls, with regulators noting that the bank had failed to address issues despite prior warnings.
None of these cases involved a single dramatic failure. What they share is a pattern of controls that were not designed to keep up with the operational environment they were supposed to govern.
Building It Right the First Time
Cloud migration decisions in banking are rarely made by a single team, and the security and compliance requirements that shape those decisions are rarely owned by a single person.
That distributed ownership is part of what makes it so easy for compliance to slip into a later phase: everyone assumes someone else is accounting for it in their workstream, and by the time the gaps surface, the environment is already live.
The institutions that avoid that pattern share a common approach.
They treat the regulatory frameworks governing their cloud environments not as external constraints to be satisfied after the fact, but as inputs to architectural decision-making from the start. PCI DSS shapes how environments are segmented and how access is controlled.
Contact Softjourn to get started on building a banking cloud architecture that is secure, audit-ready, and designed to stay that way.
