A FTSE 250 asset manager moves £40bn of customer data to AWS over a weekend. By Monday, the S3 buckets are public, IAM roles inherit excessive permissions from the legacy AD groups, and the FCA's operational resilience reporting under PS21/3 is now a problem because nobody mapped the new important business services. This is not hypothetical — it is the recurring pattern our consultants see when UK financial services firms treat cloud migration as an infrastructure project rather than a security one.
Lift-and-shift is the worst offender. Teams replicate on-premise architecture into AWS, Azure, or GCP, drag their firewall rules across, and assume the perimeter still exists. It does not. The control plane is now an API, the identity provider is the new perimeter, and every misconfigured storage bucket is a potential Section 166 skilled person review waiting to happen.
With the FCA's operational resilience rules fully in force since 31 March 2025 (PS21/3 mapping, testing, and self-assessment), and the Bank of England's third-party risk management policy SS2/21 expecting firms to demonstrate cloud concentration risk controls, going live without locking down the basics is no longer a tolerable risk. Here are the nine controls our team insists firms implement before flipping the DNS.
Why cloud migration security is different now
The threat model has shifted. In a traditional data centre, an attacker needs network access. In cloud, they need a leaked access key, a compromised CI/CD pipeline token, or an over-permissioned service principal. The 2024 Verizon Data Breach Investigations Report identified credential abuse as the most common initial access vector in breaches involving cloud assets. Your cloud migration security checklist must reflect that reality.
For UK financial services, the regulatory layer adds weight. The FCA, PRA, and Bank of England joint discussion paper DP3/22 on critical third parties — now progressing through the Financial Services and Markets Act 2023 powers — means hyperscaler dependency is a board-level concern. The ICO continues to enforce UK GDPR Article 32 security of processing obligations, with cloud misconfiguration cited in several recent monetary penalty notices.
The 9 controls to lock down before go-live
1. Identity-first architecture
Federate every cloud account to a single identity provider — Entra ID, Okta, or Ping. Disable local IAM users for human access. Enforce conditional access with phishing-resistant MFA (FIDO2 or platform authenticators). Privileged actions go through just-in-time elevation, not standing admin rights.
2. Landing zone with guardrails, not greenfield chaos
Use AWS Control Tower, Azure Landing Zones, or GCP's secure foundations blueprint. Deploy preventative service control policies that block public S3 buckets, public storage accounts, and unencrypted disks at the organisation level — not the workload level. This is the single biggest defence against the lift-and-shift security risks our consultants find during cloud audits.
3. Encryption with customer-managed keys
Default platform encryption is not sufficient for FCA-regulated data. Use AWS KMS, Azure Key Vault, or GCP Cloud KMS with customer-managed keys. Rotate annually. Log every key usage to your SIEM. For especially sensitive workloads, evaluate Bring Your Own Key (BYOK) and confirm key escrow procedures with your DR plan.
4. Network segmentation that survives contact with developers
Hub-and-spoke topology. Private endpoints for all PaaS services. No public IPs on databases — ever. Egress through inspection points. If a developer needs to bypass it, the answer is no, then a conversation about why their workflow needs redesigning.
5. Logging that proves what happened
CloudTrail, Azure Activity Logs, and GCP Audit Logs enabled across every account, every region, immutable, with cross-account write to a dedicated security tenant. Retain for a minimum of seven years for financial services records under FCA SYSC 9. Feed to a SIEM with detection rules tuned for cloud-native attack patterns — not just legacy Windows event IDs.
6. Secrets management
No credentials in code. No credentials in environment variables in production. Use AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault. Scan every commit with tools like Gitleaks or TruffleHog in the CI pipeline. Rotate everything the migration touched.
7. Workload identity for service-to-service auth
IAM roles for EC2, managed identities for Azure resources, workload identity for GKE. Service accounts with static keys are a 2014 pattern — they have no place in a 2026 migration.
8. Backup and immutability against ransomware
Immutable backups in a separate account or tenant with no trust relationship back to production. Test restore procedures monthly. The 2023 attacks on financial sector cloud tenants demonstrated that attackers go for the backup plane first. AWS Backup Vault Lock and Azure Backup immutable vaults are mandatory, not optional.
9. Cloud adoption framework security alignment
Map your migration to the Microsoft Cloud Adoption Framework or AWS Cloud Adoption Framework security perspective. These are not marketing documents — they are the structured way to evidence to the FCA, PRA, or an external auditor that security was designed in, not bolted on after the breach.
The common mistakes we keep finding
Three patterns dominate every cloud audit our team runs.
First, IAM permission sprawl. Initial migration scripts use AdministratorAccess "temporarily." Eighteen months later, that role is still attached to a Lambda function nobody owns. Use IAM Access Analyzer and Azure AD access reviews quarterly.
Second, shared responsibility confusion. The hyperscaler secures the cloud. You secure what is in the cloud. We have seen boards genuinely believe AWS patches their EC2 instances. It does not. Document the shared responsibility model per service and per workload.
Third, no exit strategy. SS2/21 expects you to demonstrate you can recover services in the event of a critical third-party failure. If your migration plan does not include how you would move off the chosen provider, you are not compliant with the spirit of operational resilience.
How Pyralink helps
Pyralink Innovation Ltd, led by Founder and Managing Director Michael Adedeji (CISM, CISA, CC, MSc Data Science), runs cloud migration assurance for UK financial services firms before, during, and after go-