Cloud Security for Financial Services: What Matters

Cloud security for financial services is the set of controls a bank, insurer or fintech uses to protect customer money and data on a public cloud platform, and to prove to auditors and regulators that those controls work. The provider secures the data centres and the platform underneath. The firm secures everything it configures on top: identity, network exposure, encryption keys, logging and recovery. In practice the failures that reach the news are rarely a breach of the provider's own data centres. They are a permission that was too broad, a storage bucket left public or a credential that never expired.

Those are engineering problems with known fixes. What follows is an engineering view, not legal advice; the rules that apply to you depend on your licence and your jurisdiction.

The shared responsibility model: who secures what

Every major provider publishes a shared responsibility model. AWS puts it most compactly: the provider is responsible for security of the cloud, the customer for security in the cloud. The line moves with the service you choose. On a virtual machine you patch the operating system. On a managed database the provider patches the engine, but you still decide who can connect to it.

Layer	The provider	You
Data centres, hardware, virtualisation	Secures and operates	Review the provider's audit reports
Managed service internals (database engines, queues)	Patches and operates	Choose secure settings
Operating systems and runtimes on virtual machines and containers	Supplies base images	Patch and harden
Identity and permissions	Supplies the tools	Decide who can do what
Network exposure	Supplies the tools	Decide what is reachable, and from where
Data, encryption choices and keys	Supplies encryption and key services	Classify data and control the keys
Logging, backup and recovery	Supplies the services	Switch them on, set retention, test restores

Two consequences follow. First, the provider's certifications do not transfer to you: their audit reports cover their side of the line, and your auditor will ask about yours. Second, the more managed the service, the less you have to secure yourself, which is a sound reason for a small team to prefer managed services.

Identity and least privilege

In the cloud, identity is the perimeter. Anyone holding the right credential can reach your data from anywhere, so this is where I would spend the first week.

• One identity source. Staff sign in through single sign-on with phishing-resistant multi-factor authentication.
• No long-lived keys. People and pipelines use short-lived credentials issued through roles or workload identity federation.
• Least privilege, enforced. Each workload gets its own role with only the permissions it uses. Wildcards are removed, and unused permissions are trimmed on a schedule.
• Separate accounts per environment. Production, staging and development live in separate accounts, subscriptions or projects, so a mistake in one cannot reach another.
• Privileged access is temporary. Administrative rights are requested, approved, time-limited and logged. The root or owner account is locked away for emergencies.
• Organisation-wide guardrails. AWS service control policies, Azure Policy and Google Cloud organisation policies can forbid dangerous actions and configurations, such as disabling audit logs or making storage public, whatever an individual account's own permissions say.

This is the practical core of zero trust: every request is authenticated and authorised on its own merits, and being inside the network grants nothing.

Encryption and key management

Encryption at rest is now the default on much of the major platforms, and a setting you must switch on for the rest. Encryption in transit means TLS on every connection, internal ones included. Both are the minimum. The decisions that need thought are about keys.

• Use customer-managed keys in the provider's key management service for sensitive data stores, so that reading the data requires permission on the key as well as on the storage.
• Separate the people who administer keys from the people and workloads that use them.
• Rotate keys automatically, and log every use of a key.
• Protect key deletion. Destroying a key destroys the data it protects, which is why providers enforce a waiting period that you should not shorten.
• For the most sensitive fields, such as account numbers or identity documents, add application-level encryption or tokenisation, so that a database administrator or a leaked backup reveals nothing useful.

Secrets deserve the same care. Database passwords, API tokens and certificates belong in a secrets manager with rotation, never in files committed to a repository.

Network segmentation

Identity comes first, but the network still limits how far an attacker can move. Databases, caches and internal services sit in private subnets with no public addresses. Only load balancers and gateways face the internet, behind a web application firewall. Firewall rules name specific sources and ports, and a rule that opens an administrative port to the whole internet should fail a pipeline check before it is ever deployed.

A compromised workload that can call any address on the internet can send data anywhere, so restrict egress to the destinations a service actually needs.

Segmentation also shrinks audits. If card data is handled in one small, isolated set of accounts, or better still handed to a payment processor so that your systems only see tokens, most of your estate falls outside PCI DSS scope.

Logging and audit evidence

You need to answer two questions on demand: what happened, and can you prove your controls were operating? Both depend on logs you can trust.

• Switch on control-plane audit logs in every account and region: AWS CloudTrail, the Azure Activity Log, Google Cloud Audit Logs.
• Send them to a dedicated log archive account, on write-once storage, that workload administrators cannot alter or delete from.
• Add data access logs for the stores that hold customer data, plus network flow logs.
• Set retention on purpose. PCI DSS, for example, expects at least twelve months of audit log history with the most recent three months immediately available. Your regulator may expect longer.
• Alert on the events that matter: a new administrator, a policy change, logging being switched off, a sign-in from an unexpected place.

Data residency

Choosing a region decides where your primary data sits. It does not decide where everything else sits. Check each of the following before you tell a regulator or a customer that data stays in one country:

• Backups, replicas and disaster recovery copies in a second region.
• Logs and metrics shipped to a monitoring or error-tracking service hosted elsewhere.
• Support and engineering staff, yours or a supplier's, who view data from another country.
• Analytics exports and AI services that process data outside the home region.

Residency rules vary widely between countries and between types of data, so take the legal position from counsel and then make it enforceable in engineering: region restrictions set as organisation policy, not as a convention people are trusted to remember.

Third-party and concentration risk

Regulators increasingly treat the large cloud providers as a shared dependency of the whole financial system. The EU's Digital Operational Resilience Act, for example, creates direct oversight for technology providers designated as critical, and expects firms to keep a register of their technology suppliers and workable exit plans. The vendor side of that question is covered in fintech development outsourcing.

The instinctive response is multi-cloud. I would be careful. Running the same system actively on two providers doubles what your team must know and secure, and for a small or mid-sized firm that often lowers security overall. A more proportionate approach:

• Use multiple availability zones always, and multiple regions for critical services.
• Keep the architecture portable where that is cheap: containers, standard databases and infrastructure as code.
• Write an exit plan that names what would move, in what order and roughly how long it would take.
• Map your suppliers' dependencies. If your identity provider, your monitoring tool and your payment gateway all run on the same cloud as you, that is one risk, not four.

If you are still choosing a platform, the differences that matter are covered in AWS vs Azure vs Google Cloud.

Resilience and tested recovery

Availability is a security property in finance. Customers who cannot reach their money are harmed whether the cause is an attacker or a failed deployment. Start by agreeing, for each critical service, how long it may be down and how much recent data you could afford to lose. Those two numbers, the recovery time and recovery point objectives, drive the design.

• Backups are stored in a separate account and made immutable for a set period, so that ransomware or a compromised administrator cannot delete them.
• Restores are tested on a schedule, into a clean environment, and timed. An untested backup is a hope.
• The whole environment can be rebuilt from code, not from memory.
• Failover is rehearsed, including the awkward parts: DNS, secrets, third-party allowlists and who is authorised to make the call.

Keep the records of each test. Regulators increasingly ask for them.

How PCI DSS, SOC 2 and ISO 27001 map onto engineering controls

None of these three is a financial regulation. They are standards that customers, partners and the card industry ask you to meet, and they overlap heavily.

Framework	What it is	What it asks of engineers
PCI DSS	A prescriptive card industry standard for anyone who stores, processes or transmits cardholder data	Specific technical requirements for the systems in scope; the smaller the scope, the smaller the job
SOC 2	An independent auditor's report against the AICPA trust services criteria, with security as the mandatory category	Evidence that the controls you describe actually operated across the review period
ISO 27001	A certifiable standard for an information security management system	A risk assessment, a chosen set of controls and proof that the management process runs

Underneath, the engineering is largely the same list: access control with multi-factor authentication, change management through reviewed pull requests, logging and monitoring, encryption, vulnerability management, incident response, backup and recovery, and supplier management. Build each control once, in code where you can, and map it to every framework that asks for it.

Passing an audit shows that controls exist and operate. It does not show that an attacker would fail. Independent penetration testing answers that second question, and PCI DSS requires it for a cardholder data environment. It finds less, and costs less to fix, when security was designed in from the start, which is the argument in security by design versus bolt-on.

The misconfigurations that actually cause incidents

The same short list appears again and again in published incident write-ups:

1. Public storage. A bucket, a disk snapshot or a database backup shared with everyone.
2. Over-broad roles. Wildcard permissions, or one role shared by many workloads.
3. Leaked long-lived keys. In source code, pipeline variables, chat messages or a laptop.
4. Privileged accounts without multi-factor authentication.
5. Open management ports and public databases.
6. A reachable metadata service. A server-side request forgery flaw lets an attacker ask a virtual machine for its own credentials. Enforcing the token-based version of the metadata service blocks the usual form of this attack.
7. Logging switched off, or stored where an intruder can delete it.
8. Production data in non-production environments that have weaker controls.

The 2019 Capital One breach is the best known public example in finance. As widely reported, it combined a misconfigured web application firewall, credentials obtained from the instance metadata service and a role with far more storage access than it needed.

Manual review does not catch these reliably. Prevention does: organisation-level guardrails, policy checks on infrastructure code in the pipeline, and continuous posture scanning that flags drift soon after it appears.

Cloud security for financial services: where to start

If you are facing all of this at once, I would take it in this order:

1. Fix identity: single sign-on, multi-factor authentication, no long-lived keys.
2. Separate environments into their own accounts and apply organisation guardrails.
3. Centralise audit logs in an account nobody on the workload side can alter.
4. Remove public exposure: storage, databases, management ports.
5. Move backups to a separate account and test a restore.
6. Put all infrastructure in code, with policy checks in the pipeline.
7. Then map what you have built to the frameworks you need.

Compliance comes last on that list on purpose. A firm with the first six in place already has most of the evidence any framework asks for. If you want help with the build, that is the work we do under cloud engineering and cybersecurity.

Frequently asked questions

Is the public cloud secure enough for financial services?

Yes, when it is configured well. The major providers run physical and platform security at a scale few individual firms could match. The risk sits in the firm's own configuration of identity, networks, keys and logging.

Who is responsible for cloud security, the provider or the financial firm?

Both, for different layers. The provider answers for the data centres, hardware and managed service internals. The firm answers for identity, configuration, data, keys, logging and recovery, and regulators hold the firm accountable for the service as a whole.

Does a compliant cloud provider make us PCI DSS or SOC 2 compliant?

No. The provider's attestations cover its own infrastructure. They let you inherit some controls, such as physical security, but your scope, your configuration and your processes are assessed separately.

Do financial services firms need multi-cloud for resilience?

Not usually as a first step. Multiple zones and regions on one provider, tested recovery and a written exit plan address most of the risk at far lower complexity. A credible exit strategy for critical services is a different thing from running on two clouds at once.