When the UK's Financial Conduct Authority embarked on its cloud transformation journey, the stakes couldn't have been higher. This wasn't a typical enterprise migration. Every system handled data that, if compromised, could shake confidence in the UK's financial markets. Every architectural decision had to withstand scrutiny from internal auditors, external regulators, and ultimately, Parliament itself.

I spent years leading the cloud architecture function within the FCA's Cloud Centre of Excellence, designing secure cloud-native solutions for some of the UK's most critical regulatory programmes, including MiFID II and PSD2. The experience taught me lessons that every organisation—especially SMEs—can apply when navigating the complex intersection of cloud transformation and regulatory compliance

The Regulatory Compliance Challenge

Most organisations approach cloud transformation with a technology-first mindset. They focus on lift-and-shift migrations, cost optimisation, and developer productivity. Compliance, if considered at all, becomes an afterthought—a box-ticking exercise handled by a separate team weeks before go-live.

This approach fails spectacularly in regulated industries. At the FCA, we learned that regulatory compliance isn't a phase of cloud transformation. It's the foundation upon which everything else is built. When you're designing systems that must comply with GDPR, maintain operational resilience under regulatory scrutiny, and demonstrate security controls that meet government standards, compliance must be embedded from day one

The challenge is particularly acute for SMEs. Large enterprises have dedicated compliance teams, legal advisors, and budgets that can absorb the cost of regulatory missteps. SMEs lack these luxuries. A single compliance failure—a data breach, a failed audit, a regulatory fine—can be existential.

The Security-First Approach

At the FCA, we developed an approach that inverted the traditional cloud transformation model. Instead of building first and securing later, we designed security and compliance controls before migrating a single workload. This "security-first" methodology became the blueprint for how we delivered cloud transformation in one of the UK's most regulated environments.

The approach rested on three foundational principles.

First, assume breach. We designed every system assuming that perimeter defences would eventually fail. This meant implementing defence-in-depth strategies: encryption at rest and in transit, least-privilege access controls, network segmentation, and continuous monitoring. When we architected solutions for MiFID II transaction reporting, we built systems where even a compromised account couldn't access sensitive data without triggering multiple alerts and automated containment responses.

Second, embed compliance into the SDLC. We integrated security and compliance checks directly into the software development lifecycle. Infrastructure-as-code templates were scanned for misconfigurations before deployment. Automated security testing ran on every code commit. Compliance requirements were translated into technical controls that developers could implement without needing to interpret regulatory text. This shift-left approach meant that by the time a system reached production, it had already passed dozens of automated compliance checks.

Third, maintain continuous evidence Regulators don't just want to know that you're compliant today. They want evidence that you've been compliant continuously. We implemented comprehensive logging, monitoring, and reporting capabilities that generated audit trails automatically. Every configuration change, every access request, every security event was logged, analysed, and retained according to regulatory requirements. When auditors arrived, we could demonstrate compliance with data, not assurances.

Real-World Application: MiFID II and PSD2

The Markets in Financial Instruments Directive II (MiFID II) and the second Payment Services Directive (PSD2) presented particularly complex compliance challenges. Both regulations imposed strict requirements on data handling, transaction reporting, and operational resilience. Both required systems that could scale to handle millions of transactions whilst maintaining security and auditability.

For MiFID II, we designed a cloud-native transaction reporting system that ingested, validated, and reported trading data from financial institutions across the UK. The system had to process massive volumes of data, detect anomalies in real-time, and maintain an immutable audit trail—all whilst complying with GDPR data protection requirements.

We achieved this by architecting the system with compliance embedded at every layer. Data was encrypted using AWS Key Management Service with keys managed according to government security standards. Access controls were implemented using attribute-based access control (ABAC) policies that enforced least-privilege principles automatically. The entire infrastructure was defined as code, version-controlled, and deployed through automated pipelines that included security scanning at every stage.

The result was a system that not only met regulatory requirements but exceeded them. We achieved zero security incidents throughout the programme's lifecycle. Audit findings were minimal. And perhaps most importantly, we demonstrated that cloud platforms could meet the stringent security and compliance requirements of a financial regulator—a proof point that has since enabled broader cloud adoption across UK government.

Practical Steps for SMEs

Based on my experience at the FCA and subsequent work with major UK banks, here are the practical steps SMEs should take when embarking on cloud transformation in regulated contexts.

Start with a secure landing zone. Before migrating any workloads, establish a secure foundation. This means implementing identity and access management controls, network segmentation, logging and monitoring, and encryption by default. AWS Control Tower and Azure Landing Zones provide frameworks that embed these controls from day one.

Map regulatory requirements to technical controls. Don't rely on legal teams to interpret regulations. Work with compliance experts who can translate regulatory requirements into specific technical controls. For example, GDPR's data minimisation principle translates to specific architectural patterns: data classification, automated retention policies, and privacy-by-design approaches

Automate compliance checks. . Use tools like AWS Security Hub, Azure Security Center, and open-source solutions like Checkov and tfsec to scan infrastructure code for compliance violations before deployment. Integrate these tools into your CI/CD pipelines so that non-compliant configurations are blocked automatically

Implement comprehensive logging. Enable CloudTrail, VPC Flow Logs, and application-level logging from day one. Centralise logs in a SIEM solution like Azure Sentinel or AWS Security Hub. Define retention policies that meet regulatory requirements. This investment pays dividends during audits and incident response.

Design for operational resilience. Implement multi-region architectures, automated backups, and disaster recovery capabilities. Test your recovery procedures regularly. Document your important business services and impact tolerances. This preparation isn't just good practice—it's increasingly a regulatory requirement.

Engage with auditors early. . Don't wait until go-live to involve auditors and compliance teams. Engage them during the design phase. Walk them through your architecture, your controls, and your evidence collection mechanisms. Their feedback will save you costly rework later

The Path Forward

Cloud transformation in regulated industries doesn't have to be a compliance minefield. With the right approach—one that embeds security and compliance from the start—it becomes an opportunity to build systems that are not only compliant but more secure, more resilient, and more auditable than their on-premises predecessors.

The FCA's cloud transformation demonstrated that even the most regulated organisations can leverage cloud platforms safely and effectively. The key is inverting the traditional approach: instead of building first and securing later, we must design security and compliance into the foundation of every cloud system we build.

For SMEs, this approach isn't just about meeting regulatory requirements. It's about building trust with clients, protecting your business from existential risks, and creating a competitive advantage in markets where security and compliance are increasingly the price of entry.

The question isn't whether your organisation can afford to adopt a security-first approach to cloud transformation. It's whether you can afford not to.

About the Author

Abdul Khader Abdul Hanif is the founder of Zazo Tech, a UK-based consultancy specialising in security-first digital transformation. He previously served as Lead Product Architect at the UK's Financial Conduct Authority, where he led cloud architecture for regulatory programmes including MiFID II and PSD2. He holds SC Clearance, AWS Professional and Azure Expert certifications, and has been featured in an AWS case study for security implementation excellence.