9 Cloud Practices for Financial Institutions

Financial services cloud adoption has a specific flavor: the regulators are watching, the auditors are perpetual, the data is attractive to attackers, and the tolerance for downtime is low. None of these make the cloud impossible — community banks and credit unions run core systems in the cloud every day now — but they make some patterns mandatory and some patterns disqualifying.

Here are nine practices we apply when we work with financial institutions.

1. Scope Reduction Before PCI Compliance

The single biggest lever for making PCI DSS survivable is scope reduction. Every system that handles, stores, or transmits cardholder data is in-scope for PCI and inherits all 300+ controls. Every system outside that boundary is much simpler to manage.

How to reduce scope:

• Tokenize. Let a PCI-certified processor handle the actual PANs. Your system stores tokens. Your system is not in PCI scope.
• Use hosted payment pages. The payment form is on the processor's domain, not yours. Your site redirects to it and receives a token back. PCI SAQ A applies instead of SAQ D.
• Segregate networks. The PCI segment is walled off from everything else with dedicated firewalls, dedicated IAM, dedicated logging. Nothing outside the segment can reach it directly.

Budget impact: A well-scoped PCI environment costs 5 to 10 times less to run and audit than a broadly-scoped one. This is the highest-ROI decision in financial cloud.

2. SOX Change Management in IaC

SOX Section 404 cares about the integrity of financial reporting systems. That includes the systems that feed the general ledger, the systems that report to regulators, and the infrastructure those systems run on.

The IaC pattern that satisfies SOX:

• Every production change is a pull request.
• Every PR has at least one non-author approval.
• PRs are linked to change tickets in your ITSM.
• The pipeline that applies the change is audited end-to-end, from commit to apply.
• Drift detection runs continuously. Drift is investigated and either reverted or explained.

The PR history and the pipeline logs are your SOX evidence. Auditors love it because it's deterministic. Much better than Word documents describing what somebody did six months ago.

3. Multi-Region by Default for Core Systems

For a core banking platform, a loan origination system, or a trading application, single-region is not acceptable. The business impact of a regional outage during business hours is too high to absorb.

Common patterns:

• Active-passive across two regions of the same cloud, with synchronous replication for the primary database. RTO minutes, RPO near-zero.
• Pilot light in a second region for non-critical systems. RTO hours, RPO minutes.
• Cold standby in a different cloud or on-prem for regulatory "backup of last resort" scenarios.

Budget realistically. The second region is not free, but neither is an outage during month-end close.

4. Comprehensive Immutable Audit Logs

Financial auditors care about who did what, when, to which systems, and what the outcome was. "Comprehensive" here means more than API logs — it includes database-level audit, file system access where relevant, and application-level audit for any system that touches the GL.

What to log:

• All administrative access (console, SSH, RDP)
• All privileged operations
• All database queries against sensitive tables
• All configuration changes
• All authentication events

Where to store it: Immutable object storage with at least 7-year retention (longer for specific data types). SIEM for active monitoring. Never in the same account or subscription as the thing being audited.

5. Data Residency by Regulation

US, EU, UK, Canada, and Australia all have their own rules for where financial data can live. Multi-jurisdictional banks have to handle all of them at once.

Concrete controls:

• Per-region deployments of the same application for jurisdiction-specific data
• Cloud provider regions chosen to match regulatory requirements (FedRAMP for US federal, IL4/IL5 for defense-adjacent, UK sovereign regions)
• Data tagging with jurisdiction metadata enforced by policy
• Backup destinations in the same jurisdiction as the source

Data leaking from one jurisdiction to another is a regulatory event, not a technical convenience. Treat it accordingly.

6. Segregation of Duties at the IAM Level

SOX and SOC 1 Type II both care about who can do what. A developer should not be able to both write code and deploy it to production. An administrator should not be able to both make a change and approve the change.

IAM patterns that work:

• Distinct roles for "developer" and "deployer." Developers write code, a separate CI/CD identity deploys.
• Break-glass accounts for emergencies. Separate credential, alerted on use, automatic ticket created.
• Just-in-time elevated access via Azure PIM, AWS Identity Center, or SSO integrations. Admin access is granted for a time window with justification, not permanently.
• Quarterly access reviews automated from IAM data. Managers attest or revoke.

7. Vendor Risk Management Is Regulatory

If you're a bank, your regulators (OCC, FDIC, state banking departments) care about who you use. "Critical third parties" have to be inventoried, assessed, monitored, and documented. The cloud provider is one of them. So is every SaaS vendor you use.

What we document for each critical vendor:

• SOC 1 / SOC 2 reports, reviewed annually
• Contractual data protection terms
• Exit plan with realistic timeline and cost
• Financial health review (for smaller vendors)
• Concentration risk analysis if multiple critical services depend on the same vendor

Regulators will ask for this. Having it ready saves weeks during examinations.

8. Encryption Keys in HSM-Backed KMS

Default cloud encryption is not sufficient for core banking data. Customer-managed keys backed by a FIPS 140-2 Level 3 HSM are the pattern we implement. The key material never leaves the HSM.

Specific services: Azure Key Vault Premium with Managed HSM, AWS CloudHSM or KMS with custom key stores, Google Cloud HSM. All three support the required certifications.

Key rotation: Automated, annually at minimum for regulated data, quarterly for PCI cardholder environments.

9. Tabletop Exercises With the Business, Not Just IT

The best technical DR plan is irrelevant if the business continuity team can't execute around it. Financial institutions have specific communication requirements during an incident — regulators may need to be notified, press releases may need to be coordinated, customer communications may need to be reviewed by compliance.

Run tabletops with the whole cast: IT, business continuity, compliance, legal, executive, and PR. Scenarios that force cross-team coordination expose the gaps that purely technical drills don't catch.

What We'd Actually Do

For a community bank or credit union starting a cloud migration:

1. Scope the PCI environment ruthlessly before moving anything. Tokenize. Redirect to hosted payment pages.
2. IaC from day one with the PR review pattern described above. No manual production changes.
3. Centralize audit logging to an SIEM in a separate cloud account.
4. Multi-region for core systems, single-region for back-office.
5. Customer-managed HSM-backed keys for anything touching member PII or core data.
6. Quarterly DR drills and annual cross-team tabletops.

Three Takeaways

1. PCI scope reduction is worth more than any other control you can implement. Tokenize aggressively.
2. SOX is satisfied by good IaC with reviewed changes. The pipeline is the evidence.
3. Financial services tabletops should include the business, not just IT. Regulatory notifications are the thing technical teams forget.