Security, Compliance and Resilience for Financial Workloads

Executive summary

A payment system is three things at once: a target, because attackers and fraudsters want the funds and the data behind them; a trust boundary, because insiders and compromised suppliers can misuse legitimate access; and an audited record, because supervisors and auditors judge whether every amount was authorized and explainable. Moving to public cloud removes none of these pressures. It redraws who holds which control, and the controls that matter most for money movement stay with the customer.

Security, compliance and resilience for financial workloads should therefore be engineered in and proven continuously, rather than assembled for the audit:

• Start from assets and adversaries, and confirm the shared-responsibility line for each service rather than assuming it.
• Govern workforce, privileged, break-glass and workload identities deliberately, and enforce segregation of duties in systems rather than in procedure documents.
• Protect data in layers, with keys held in validated hardware security modules (HSMs) under customer control and tokenization to shrink what is worth stealing.
• Write controls as policy as code, scan configuration continuously, and map one control set to every applicable framework.
• Set recovery objectives per component, prove them with drills that complete a real run, and design incident notification before it is needed.

An operating model based on the three lines model, a small set of early-warning metrics and a staged maturity path turn these practices into a program. The closing section sets out what to achieve in the first 90 days.

Three pressures at once

A system that moves money differs from most workloads because three pressures land on it together. External attackers and fraud pursue the money; insiders and suppliers pursue the access that reaches it; and auditors and supervisors judge whether each movement of funds was authorized, accurate and explainable.

Money-movement systems are a target, a trust boundary and an audited record at once, and the cloud shifts many of their controls to the customer.

Public cloud does not remove these pressures; it redraws who holds which control. Under the shared-responsibility model the provider secures the platform, but identity, data classification, key control, secure configuration and audit evidence sit with the customer. Two expectations have hardened alongside cloud adoption. Evidence should be produced continuously rather than gathered before a review, and resilience is judged across a whole service from end to end, including the third parties it depends on, rather than system by system. The sections that follow address each pressure in turn.

Threat model and shared responsibility

Good security starts from what is worth protecting and who would go after it, and then establishes precisely which of the resulting controls the organization, rather than its cloud provider, must operate.

What must be protected, and from whom

Both lists are specific to money movement. The most valuable asset is often not data at all but the ability to release funds, and the most damaging attacks rarely look like intrusions: a changed bank account, an approval granted by the wrong person, or a quiet edit to an amount. Suppliers, dependencies and the software supply chain widen the attack surface beyond the organization's own code. Threats are described here only to the level needed to justify controls; each control in the sections that follow maps back to one or more of these assets and adversaries, and a control that maps to neither is a candidate for removal.

Shared responsibility across the cloud stack

Shared responsibility is the most misread idea in cloud security. The provider secures the facilities, the hardware and the managed services themselves, and offers attestations such as independent audit reports. Everything the customer builds or configures remains the customer's responsibility, and the dividing line moves with the service model: more is inherited from a managed database than from raw virtual machines. Whatever the service model, the customer keeps responsibility for its data, its identities and access management, and the configuration of what it deploys.

For a money-movement system the customer-side column holds exactly the controls that matter most: who may read bank data, how strongly people authenticate, where data lives, how services are configured, who controls the keys, and whether the audit trail proves that controls operated. Distributed denial-of-service (DDoS) absorption at the network edge is largely provider-supplied, but segmentation, private endpoints and egress rules are not. The split is illustrative; teams should confirm it for each service against the provider's documentation and contract, because assuming the provider covers something it does not is a common root cause of audit findings and incidents.

Zero trust for financial workloads

Zero trust replaces the old assumption that anything inside the network perimeter is safe. NIST Special Publication 800-207, Zero Trust Architecture, describes it as granting no implicit trust to assets or user accounts based on their network location or ownership, and sets out seven tenets, among them securing all communication regardless of location, granting access to each resource per session, deciding access by dynamic policy, and monitoring the security posture of every asset. Industry guidance often condenses the idea into three principles: verify explicitly, use least-privilege access and assume breach.

For financial workloads this is not abstract. A foothold on one host must not grant access to the ledger, so every call between components is authenticated and authorized. Standing administrator rights become a standing liability, so privilege is minimized and time-bound. The through-line is that identity, not location, becomes the control plane, which makes the identity system both the strongest control and the highest-value target and justifies the attention the next section gives it. NIST Special Publication 800-53 Revision 5 provides a detailed control catalog on which these principles can draw.

Identity, access and duties

If identity is the control plane, then the governance of identities is the core of the security program. Four kinds of identity need deliberate treatment, and segregation of duties must be enforced by systems rather than by procedure.

Four identities to govern deliberately

Phishing resistance is the property that matters for workforce identity. Authenticators based on public-key cryptography and bound to the legitimate site, such as FIDO2 security keys, passkeys and smart cards, resist the credential phishing, one-time-code relay and push-fatigue attacks that defeat weaker methods. Privileged access is the sharpest risk, which is why no one should carry standing production power: grants expire automatically, and every session leaves a record.

Break-glass access exists so that emergencies do not become a back door; it is rehearsed, so it works when needed, and alarmed, so it is never used quietly. Workload identity extends the same discipline to services, using short-lived identities issued by the cloud platform or by an open standard such as SPIFFE in place of static secrets that are copied, shared and rarely rotated. Together these make identity something the organization can both enforce and prove.

Roles and access across a pay cycle

Segregation of duties turns from a policy statement into an enforced control when it is expressed as a role-to-access matrix and applied by the systems themselves. The table below shows an illustrative separation for a payroll or disbursement run, from the operators who prepare it to the platform and site reliability engineering (SRE) staff who keep it running.

The pattern is that the people who create an amount, approve it and release it are always different, and that platform and SRE staff can keep the platform running without being able to read bank data or move money. The decisive point is where the rule lives. Segregation of duties is enforced in the workflow engine and in identity policy, not left to a procedure document, so no single identity can quietly hold two roles whose separation the matrix requires, and every attempt to do so is blocked and logged.

Least privilege you can prove

Least privilege is easy to assert and hard to prove. Access is a control only when its operation can be demonstrated on demand, so the checklist below is framed around evidence.

The test of a real access attestation is that removals are actioned, not merely reviewed. Shared administrator accounts are eliminated because an action no one can be tied to is an action no one can be held to. When every access change and approval is written to the tamper-evident audit trail, the control can be evidenced to an auditor without a manual scramble.

Protecting data and keys

Protecting financial data is a layered problem, and encryption is only as strong as the control over the keys behind it.

Data protection in depth

Classification comes first because every later layer depends on knowing what the data is. Encryption in transit uses mutual Transport Layer Security (mTLS) between services, so both ends prove their identity, and strong transport security, TLS 1.2 or later and preferably TLS 1.3, to every bank and partner endpoint. Encryption at rest is applied to every store and backed by a key management service and hardware security modules (HSMs), but generic encryption mainly protects against lost disks; the layers above it, key control and minimized exposure, are what protect against a compromised account. Each layer narrows what an attacker or an error can reach.

Keys under your control

Keys live in a managed key service backed by HSMs, never in application code, images or configuration files. The ledger, the audit trail and bank data use customer-managed keys, which the organization can rotate, disable or revoke under its own policy, and every use of a key is logged for review. Critically, key administration is separated from data administration, so the person who can manage a key cannot read the data it protects. Revocation and rotation are rehearsed so a suspected compromise has a known, practiced response. NIST Special Publication 800-57 provides widely used guidance on key management, including how long each type of key should remain in use.

HSM assurance is usually expressed through FIPS 140-3, the standard against which cryptographic modules are validated in the United States and Canada. It defines four increasing security levels, and it has replaced FIPS 140-2 for new validations. Cloud key services and dedicated cloud HSMs commonly use modules validated at Level 3, but a level applies to a specific module and certificate, so teams should check the published validation certificate rather than rely on product descriptions.

Shrinking the data worth stealing

The second half of data protection reduces how much sensitive data exists to be stolen in the first place.

• Tokenize card data so that most systems handle tokens rather than card numbers. This can reduce the scope of a PCI DSS assessment, although the tokenization system itself, and anything that can detokenize, stays in scope.
• Tokenize or encrypt bank account numbers too. They fall outside PCI DSS but are just as valuable to fraudsters, and in the United States the Nacha Operating Rules require larger ACH originators and third-party processors to render stored account numbers unreadable.
• Encrypt sensitive fields and mask them by default in screens, exports and logs.
• Hold data only in permitted regions, enforced by placement policies rather than convention.
• Keep immutable backups that ransomware and insiders cannot alter or delete.
• Write logs and traces that never carry secrets or personal data, so telemetry does not become a second copy of the data it describes.

Compliance and continuous evidence

Financial workloads typically answer to several frameworks at once. They overlap more than they conflict, and the efficient response is one control set, operated continuously, with evidence produced as a by-product of normal work. This section is a guide, not legal advice: which regimes apply, and in what form, must be confirmed with counsel and compliance.

Frameworks and the evidence they expect

The Payment Card Industry Data Security Standard (PCI DSS) governs payment card account data. Compliance is validated through a self-assessment questionnaire (SAQ) or a report on compliance (ROC) prepared by a qualified assessor, each with an attestation of compliance, and supported by quarterly external scans by an approved scanning vendor (ASV) and penetration tests that include verifying segmentation. ISO/IEC 27001 certifies an information security management system (ISMS) through an accredited certification body, with the scope and the Statement of Applicability defining what is covered. The NIST Cybersecurity Framework (CSF) 2.0 organizes a program around six functions: Govern, Identify, Protect, Detect, Respond and Recover.

The General Data Protection Regulation (GDPR) governs personal data, with Article 32 setting the security-of-processing requirements. The Sarbanes-Oxley Act (SOX) drives IT general controls (ITGCs) over access, change and operations for systems that support financial reporting, usually assessed against the COSO Internal Control, Integrated Framework. The EU Digital Operational Resilience Act (DORA, not to be confused with the DevOps Research and Assessment program of the same initials) requires financial entities to manage ICT risk, report major ICT-related incidents, test their digital operational resilience, and manage ICT third-party risk through a register of information and exit strategies. Sector supervisors add their own outsourcing and resilience expectations.

From audit season to continuous evidence

Audits fail, or exhaust teams, when evidence is reconstructed after the fact. The alternative makes evidence a by-product of normal operation.

Policy as code changes the timing of compliance: a non-compliant change is blocked before it reaches production instead of being found months later. Continuous scanning catches the drift that policy as code cannot prevent, such as a setting changed by hand during an incident. Automatic evidence means the audit trail builds itself from normal work. Named ownership matters because an unowned control is, in practice, an uncontrolled one. Mapping one control set to several frameworks, using a published mapping such as the Cloud Security Alliance Cloud Controls Matrix as a starting point, means one implementation answers several regimes, and an auditor's question becomes a query against records the system already holds.

Third-party and dependency risk

A cloud money-movement system depends on many third parties, and their risk is the organization's risk.

Four practices keep this dependency web under control:

• A register of critical providers records the services each one supports, so dependencies are known before they fail.
• Concentration and fourth-party risk are assessed, because several services may rest on one provider the organization never chose directly.
• Exit plans, including plans for a stressed exit when a provider fails abruptly, are written and tested. DORA makes this explicit for ICT services that support critical or important functions.
• Each relationship has a named owner accountable for the controls that govern it, the contract and the ongoing monitoring of the provider.

Whether a specific regime applies, and what it requires of the register and the exit plans, must be confirmed with counsel.

Resilience and incident response

Resilience is the ability to keep moving money correctly through disruption, and to recover quickly and verifiably when disruption wins. It is engineered per component, proven by exercise and completed by a practiced incident response.

Recovery objectives by component

One target for a whole system either over-engineers the edges or under-protects the core, so objectives are set per component. The recovery point objective (RPO) is the maximum tolerable data loss, and the recovery time objective (RTO) is how quickly service must return.

The ledger and audit trail lead. Their recovery point should be near zero, achieved by synchronous replication across availability zones within a region and an active-passive posture across regions, because concurrent writes to one ledger from two regions invite conflicts a ledger cannot tolerate unless the database guarantees strongly consistent writes across regions. Payments in flight must be neither lost nor duplicated, so idempotent replay and reconciliation carry them across a failover. Everything derived from the ledger can recover more slowly because it can be rebuilt. The objectives shown are illustrative starting points, to be set from business need and proven by restore testing rather than assumed.

Proving resilience, not assuming it

A recovery plan that has never been run is a hypothesis. Resilience is a claim until it is exercised end to end, including the providers in scope.

A drill proves little unless it completes real work: for a payroll workload, that means finishing a pay cycle on the recovered system, not merely booting the database. Operational resilience regimes ask firms to identify their critical services, set a tolerance for disruption to each and test against it, although the vocabulary differs. UK operational resilience rules speak of important business services and impact tolerances, the maximum tolerable disruption to each service, while DORA works through critical or important functions. The specific obligations belong with counsel.

Threat-led penetration testing (TLPT) emulates the tactics of real attackers against live production systems. DORA, for example, requires it at least every three years for the financial entities that supervisors designate. Whatever the test, every finding is tracked to closure with an owner and a date, so testing drives change rather than paperwork.

Incident response and notification

Incident response for money movement follows a practiced structure, and its order matters: stop the harm to money and data first, investigate the cause later.

Severity is set by impact on money and data rather than by technical symptoms, and the same detection stack feeds fraud and anti-money-laundering monitoring, so a security signal and a fraud signal can be correlated. Containment comes before root cause, but evidence is preserved and a timeline kept from the first minute, because forensics and notification both depend on them.

Notification deserves design in advance, because many regimes impose duties to notify regulators and affected people within short, specific deadlines. Under GDPR, for example, a personal data breach must be notified to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it. DORA requires financial entities to report major ICT-related incidents to their competent authority through an initial notification, an intermediate report and a final report. Contracts with customers and banks add their own obligations. The exact duties must be confirmed with counsel, and the people, templates and approvals needed to meet them should be in place before an incident starts. NIST Special Publication 800-61 Revision 3 frames incident response as part of overall cybersecurity risk management under CSF 2.0.

Operating model, metrics and maturity

Controls need owners, measures and a path to improve. This section sets out who does what, the pitfalls that recur, what to measure, and a staged path to provable security.

Three lines for cloud security

The three lines model, which the Institute of Internal Auditors publishes as the Three Lines Model (an update of the earlier three lines of defense), gives security clear ownership so that nothing falls between building and assuring.

The first line owns and operates controls, with security champions raising the baseline from inside each team. The second line sets policy and provides the expertise, monitoring and challenge that keep the first line honest, without running the controls itself. Internal audit, the third line, provides independent assurance by testing evidence rather than accepting assertions. Continuous evidence, described earlier, feeds all three lines from the same source of truth rather than from three separate spreadsheets, which is what makes the model efficient as well as sound.

Pitfalls and early-warning metrics

Some pitfalls recur because each is the easy path under delivery pressure, and several pass audits that read documents rather than behavior.

A small set of counted metrics gives early warning, so that trends rather than anecdotes drive attention.

A staged path to provable security

Maturity gives teams a shared description of where they stand and what comes next. It is assessed per service and per team rather than for the whole organization at once.

The stages are cumulative. The enforced stage turns the standards of the defined stage into defaults that cannot be bypassed quietly; the evidenced stage turns enforcement into continuous proof; and the resilient stage proves that the whole arrangement survives disruption. Critical workloads, such as the ledger and the payment cycle, move first, and no stage is skipped, because each produces the data and habits the next depends on.

Where to start

The first 90 days should produce evidence rather than a plan on a shelf. They start with identity, because it is the fastest high-value improvement, and end with a recovery drill that proves the result.

1. Map one service (days 1 to 30). Map the assets, adversaries and shared-responsibility line for one real service.
2. Lock down privileged identity (days 1 to 30). Enforce single sign-on and phishing-resistant MFA for everyone with privileged access.
3. Take control of keys (days 31 to 60). Move keys into a managed key service with customer-managed keys and key-use logging.
4. Start continuous compliance (days 31 to 60). Express the top controls as policy as code, with continuous configuration scanning.
5. Prove recovery (days 61 to 90). Run a disaster-recovery drill that includes a real run on the recovered system, and baseline the security metrics.

Throughout, treat the frameworks named in this paper as prompts to confirm obligations with counsel and compliance, not as legal advice. Security and resilience are engineered in and proven continuously, not assembled for the audit.

Glossary

Shared responsibility model

The division of security and compliance duties between a cloud provider, which secures the platform, and the customer, which secures what it builds and configures on it.

Zero trust

A security model that grants no implicit trust based on network location or asset ownership and authenticates and authorizes every access request.

Phishing-resistant MFA

Multi-factor authentication, such as FIDO2 security keys, passkeys or smart cards, that cannot be relayed or replayed through a fake site.

Just-in-time access

Privileged access granted on request, for a limited time and with approval, instead of held permanently.

Break-glass access

A controlled, alarmed emergency path to restore access when normal mechanisms fail.

Workload identity

A short-lived, verifiable identity issued to a service or process so that it can authenticate without static secrets.

Segregation of duties

Separating the steps of a sensitive process, such as creating, approving and releasing a payment, so that no one person can complete it alone.

Hardware security module (HSM)

A tamper-resistant device that generates, stores and uses cryptographic keys without exposing them.

Customer-managed key

An encryption key held in a cloud key service but controlled by the customer, which decides its policy, rotation and revocation.

FIPS 140-3

The standard against which cryptographic modules are validated in the United States and Canada, with four increasing security levels.

Tokenization

Replacing sensitive data, such as a card or account number, with a token that maps back to it only within a protected service.

Policy as code

Control requirements written as machine-readable rules and enforced automatically in pipelines and platforms.

SOC 1 and SOC 2

AICPA attestation reports on a service organization's controls: SOC 1 for controls relevant to customers' financial reporting, SOC 2 for controls against the trust services criteria.

Recovery point objective (RPO)

The maximum amount of data loss, measured in time, that a component can tolerate.

Recovery time objective (RTO)

The maximum time within which a component must be restored after a disruption.

Impact tolerance

In UK operational resilience rules, the maximum tolerable level of disruption to an important business service.

Threat-led penetration testing (TLPT)

Testing that emulates the tactics of real attackers against live production systems, based on threat intelligence.

Three Lines Model

The IIA model distinguishing roles that own and manage risk, roles that provide expertise, monitoring and challenge, and internal audit, which provides independent assurance.

Register of information

Under DORA, the record a financial entity keeps of all its contractual arrangements for ICT services.