An FCA-supervised firm migrated its core ledger to AWS last quarter. The cloud team enabled KMS, rotated the keys, and ticked the encryption box on the compliance tracker. Six weeks later, an internal audit flagged the entire setup as non-compliant: the key material was AWS-generated, AWS-held, and AWS-managed. The firm had no demonstrable control over the cryptographic boundary protecting customer financial data.
This is the BYOK gap. Bring Your Own Key sounds like a configuration switch — it is not. It is a control architecture, and most UK financial services firms get it wrong in ways that surface only during FCA supervisory reviews or ISO 27001 surveillance audits.
The FCA's operational resilience rules (PS21/3, fully in force since March 2025) demand firms evidence control over data confidentiality across third-party service providers. Cloud key management sits at the centre of that evidence. Below are the five BYOK mistakes our consultants find repeatedly when auditing UK financial services environments — and how to fix them before your next audit.
What BYOK Actually Means (And What It Does Not)
BYOK lets you generate key material outside the cloud provider's environment — typically on an on-premises HSM — and import it into the provider's KMS (AWS KMS, Azure Key Vault, Google Cloud KMS). The cloud provider then uses your key to encrypt data at rest and in transit within its services.
BYOK is not Hold Your Own Key (HYOK), and it is not external key management. With standard BYOK, the cloud provider still operates the cryptographic operations on your behalf. The key sits inside the provider's HSM during use. If your control requirement is "the cloud provider can never access plaintext," BYOK alone does not deliver that — you need External Key Store (AWS XKS), Azure Key Vault Managed HSM with double encryption, or equivalent.
Knowing which model you actually need is the first audit question. Most firms cannot answer it.
Why Cloud Encryption Key Management Matters Now
Three pressures converge in 2026. First, the FCA's operational resilience regime requires firms to identify important business services and prove they can withstand disruption — including cryptographic key compromise. Second, the Cyber Security and Resilience Bill currently progressing through Parliament will expand managed service provider obligations, and key management is squarely in scope. Third, ISO 27001:2022 Annex A 8.24 (Use of cryptography) demands a documented key management policy covering the full key lifecycle.
For UK firms with EU customers or EU-based group entities, DORA (in force since January 2025 for EU financial entities) layers additional ICT third-party risk requirements. Your EU subsidiary's key management posture is now your group problem.
The Five BYOK Mistakes We See Repeatedly
1. No documented key lifecycle policy
Firms enable BYOK without a policy defining generation, distribution, storage, rotation, archival, and destruction. ISO 27001 auditors will ask for this document. "AWS handles it" is not an answer. Write the policy. Map every stage to a control owner. Reference NIST SP 800-57 Part 1 Rev. 5 for lifecycle guidance.
2. Rotation theatre
Annual rotation toggled on in the console, with no cryptographic justification, no impact analysis on long-lived ciphertexts, and no testing of decryption fallback. Worse: rotation that breaks downstream services because the dependency map was never drawn. Define rotation frequency by data classification and threat model. Test it in non-production. Document the rollback.
3. IAM permissions wider than the key boundary
The encryption key is hardened. The IAM role that can call kms:Decrypt is attached to every Lambda in the account. Effective security equals the weakest principal with decrypt rights. Run an access analyser. Apply key policies, not just IAM policies. Separate encrypt and decrypt principals where data flow allows.
4. No segregation between key custodian and data owner
The same cloud engineer who deploys workloads also administers the KMS. That fails separation of duties under ISO 27001 A.5.3 and will be flagged in any FCA SYSC review. Key administration belongs with a security or cryptography function. Data access belongs with the application team. Enforce via key policy conditions and SCPs.
5. Encryption in transit assumed, not verified
Data encryption at rest in transit is treated as a single line item. Teams configure TLS termination at the load balancer and assume internal traffic is protected. It is not — east-west traffic inside the VPC often runs plaintext. Audit every hop. Enforce TLS 1.3 minimum. Use service mesh mTLS for inter-service traffic. Document the trust boundaries.
KMS Best Practices: A Practical Checklist for Audit Readiness
- Document the key hierarchy. Customer Master Keys, Data Encryption Keys, envelope encryption flow. One diagram. Update it when architecture changes.
- Enable CloudTrail / Azure Monitor / Cloud Audit Logs for every KMS operation. Ship to immutable storage. Retain per your records policy — for FCA-regulated activity, six years minimum.
- Implement dual control for key deletion. No single administrator should be able to schedule key deletion. Use approval workflows.
- Test key recovery quarterly. Loss of key material equals loss of data. Prove the recovery path works before you need it.
- Map keys to data classifications. Confidential customer data, internal, public — separate keys, separate policies, separate audit trails.
How Pyralink Helps
Pyralink Innovation Ltd is a UK cybersecurity firm led by Michael Adedeji (CISM, CISA, CC, MSc Data Science). Our consultants have built and audited cloud key management architectures across AWS, Azure, and Google Cloud for financial services and regulated firms.
CloudAuditX, our multi-cloud auditing platform, scans your KMS configuration, IAM exposure to cryptographic operations, rotation status, and logging posture — producing the evidence pack your auditor will ask for. A free trial is available.
For firms needing ongoing oversight, our fractional vCISO service (from £497/month) gives you a named senior advisor to own the key management policy, present to your audit committee, and remediate findings. Pyralink holds £5M professional indemnity insurance.