Ceph for financial services

Ceph for financial services: where self-hosted storage fits a regulated firm

A bank, insurer or payment firm that needs storage it controls, with resilience, backup and audit obligations, can use Ceph to provide object, block and file storage in infrastructure the firm runs. The fit is strongest when the firm wants those three storage types on one platform and needs to show regulators where data sits, how it is copied and how it is recovered. Ceph does not make a firm compliant on its own. It is a storage layer whose design, operation and evidence still have to be planned against the rules that apply to that firm.

Ceph's source is licensed under LGPL-2.1 or LGPL-3, and the project offers no paid edition of its own. The software cost is therefore zero, and the money goes to the people and services around the build: architecture, hardware, implementation, security testing, documentation, and support or retainers after go-live. Ask any partner to price these as separate line items, and ask which of them recur each year. Hardware, licensing for surrounding tools and staff time for operations will all sit outside the Ceph licence fee, which is why the quote should follow a written scope rather than a platform comparison alone.

The choice of release is a compliance-relevant decision, not only a technical one. The maintained releases are Tentacle (20.2.x, first released November 18, 2025) and Squid (19.2.x, first released September 26, 2024). The Ceph releases page lists estimated end-of-life dates for each, so a firm that deploys Squid must plan its upgrade to a later release before that date. Record the chosen release, its end-of-life date and the upgrade window in the register of ICT arrangements and in the change records your auditors will request. Confirm the current status of both releases on the Ceph releases page before you commit to a version.

Which financial services requirements shape the Ceph build

This table maps the financial services requirements most likely to affect a Ceph design to the evidence an assessor or supervisor will expect and to the storage, backup, segregation or audit decisions each one drives. Read each row as a question to answer before cluster design starts, not as a certification claim, because none of these regimes issues a Ceph certificate.

Requirement	What it asks for	What it means for the Ceph build
DORA Article 28(3): register of information	A register covering all contractual arrangements for ICT services, including services supplied by storage and hosting providers.	Record every Ceph-related contract, support agreement and hosting arrangement, plus the sites and components each one covers, so the register can be kept current as the cluster changes.
DORA Article 28(8): exit strategies	Documented, tested exit strategies and transition plans for ICT services that support critical or important functions.	Keep data in standard S3, NFS or block formats where possible and document how data would move to another platform, then test that move on a non-production copy.
DORA Article 30(2): contract terms on location and data return	Contracts must state where services are provided and data processed, give advance notice of changes, and cover data return on insolvency or termination.	Name the data centers and sites that hold Ceph data and metadata in the contract, and agree how and in what format data is returned to the institution if a provider exits.
DORA Chapters II and IV: ICT risk management and resilience testing	A documented ICT risk framework and regular testing of digital operational resilience, scaled to the entity's risk profile.	Test failure domain loss, OSD and monitor failures, and restores from backup as part of the resilience program, and keep the results with the change records.
PCI DSS v4.0.1: scope and encryption	Defines which systems store, process or transmit cardholder data. Encryption and access requirements apply inside that scope, and the entity's assessor decides how they are met.	Keep card data on a dedicated pool or cluster where practical to limit scope. Confirm with your QSA how Ceph encryption at rest, key custody and encryption in transit are evidenced, because disk encryption alone may not satisfy every requirement.
PCI DSS v4.0.1: validation documents	Assessment is documented on the official Report on Compliance or Self-Assessment Questionnaire, with an Attestation of Compliance.	DeployOpen prepares configuration evidence for the assessor. The assessor issues the ROC or SAQ and the AOC, and a certificate from a vendor does not count as validation.
SEC ICFR: IT general control areas (Release 33-8810)	Example IT general control areas for SOX 404 include program changes, computer operations and access to programs and data.	Use change tickets for Ceph upgrades and configuration changes, restrict who can run cephadm and access the dashboard, and retain logs of administrative actions as evidence of computer operations.
FTC Safeguards Rule: multi-factor authentication (16 CFR 314.4(c)(5))	Multi-factor authentication for any individual accessing any information system, unless the Qualified Individual approves an equivalent control in writing.	Require MFA for administrative access to the Ceph dashboard and S3 management accounts where supported, and record any approved equivalent control in writing. Confirm the supported SSO options for your Ceph version before design.
Swift Customer Security Controls Framework (CSCF)	Independent assessment of controls for Swift users, with annual attestation in the KYC-SA application. The framework has 32 controls, 26 mandatory and 6 advisory.	Where Ceph hosts Swift-connected environments, map the storage hosts, administrative access and logging to the relevant controls and have an independent assessor review them. Swift does not certify the platform itself.

How the design differs for banks, insurers and payment firms

Illustrative example: a deposit-taking bank runs a core ledger, customer account records, payment message archives and reporting marts. Its storage design usually starts from the systems that must recover fastest and the data that must never be altered. Core ledger databases and their transaction logs are typically placed on block storage (RBD) in a cluster with tight change control, while archived payment messages and statements suit object storage (RGW) with object lock or versioning planned at the bucket level. Analytics extracts and regulatory reports can share a general-purpose pool, provided access is separated by tenant or account.

Core ledger volumes: Keep database volumes on a dedicated pool with its own replication rule, so capacity pressure from reporting does not affect ledger latency.
Message and statement archives: Store long-retention records in RGW buckets with a retention policy that your records team has approved in writing.
Reporting and analytics: Place extracts on a separate pool or cluster, because these copies often fall outside the controls applied to the ledger.
Backup targets: Keep a second copy at a physically separate site, with the failure domains in your CRUSH map matching the site model you have documented.
Cardholder or payment card data: Usually out of scope for a bank's core storage, but card-related services should be isolated so that any PCI DSS scope stays bounded.

Confirm with your risk and records teams which data classes must be segregated under your DORA register and exit plans, and ask your assessor where storage falls within your cardholder data environment.

Ceph settings and integrations that matter for financial data

Most of the controls a bank, insurer or payment firm will test on Ceph are set during design and integration, not after go-live. The cards below cover the placement, media, access, immutability and encryption choices that connect storage to resilience, segregation and audit evidence. Confirm each setting against the release you plan to run before it goes into a design.

CRUSH failure domains across racks and sites

CRUSH rules decide where replicas or erasure-coded chunks land, so they set what a single rack, room or site failure can take with it. For financial data, define the failure domain explicitly for each pool and tie it to the recovery objectives your resilience testing uses. Ask the team to show the rule output for a simulated loss of one rack and one site before accepting the design.

Enterprise SSDs for metadata and WAL/DB

On HDD-based OSDs, the write-ahead log and RocksDB metadata sit on shared SSDs, and those devices become a shared failure point for several drives at once. The Ceph hardware recommendations advise enterprise-class SSDs for this role. Confirm the device model, power-loss protection and the number of OSDs each SSD serves, since losing one can take several OSDs down together.

RGW multisite and immutability planning

RGW multisite replicates object data between zones for recovery, but replication alone does not stop a deleted or ransomware-encrypted object from spreading. Immutable retention for records must be designed and tested separately, and the Object Lock style behavior you need has to be confirmed for your chosen release. Ask for a written test showing that a locked object cannot be deleted by an administrator or by replication.

RGW authentication with Keystone or LDAP and MFA

Access to object buckets should follow the same identity controls as the rest of the estate. RGW supports Keystone and LDAP authentication and multi-factor authentication, which lets you map bucket access to named groups and remove shared keys. Confirm how MFA is enforced for each access path, and document who approves any exception in writing, since access reviews will ask for that record.

Dashboard SSO through SAML 2.0 or OAuth2

The Ceph Dashboard supports single sign-on through SAML 2.0, and through OAuth2 when cephadm runs the Management Gateway and OAuth2 Proxy services. Using SSO keeps administrator sign-in on the bank's identity provider, so leavers lose dashboard access with their directory account. Confirm which path your release supports, and test that disabling a user in the directory blocks dashboard sessions.

msgr2 secure mode for transit encryption

Messenger v2 runs on port 3300, and its secure mode encrypts all traffic after authentication with AES-GCM and adds integrity checks. Enabling it covers traffic between daemons and clients on the cluster network, which supports encryption-in-transit requirements in your control set. Verify the mode on every client path, including older clients, and record the test results as evidence for the encryption control owner.

How a financial services Ceph rollout runs

The sequence moves a Ceph storage platform from scope and regulatory mapping through test build, hardening, recovery proof and evidence collection to a handover your operations team can run. Each step closes with an output that a risk, audit or architecture owner can check.

Confirm scope and register of information entry
Define which business services, applications and data classes will use the Ceph cluster, and which of them support critical or important functions. Record the Ceph deployment, the people or firms providing support, the hosting locations and the data flows as entries in your register of information for ICT contractual arrangements, aligned with DORA Article 28(3). Your legal and third-party risk teams confirm the contract terms, including where services are provided and data processed, against DORA Article 30(2). The step closes when the scope statement and the register entries are approved by the owners who sign off third-party risk.
Complete risk and exit assessment
Assess the concentration, dependency and substitutability risk of running Ceph for each in-scope service, and document how the storage would be moved or restored if the platform or the support provider became unavailable. DORA Article 28(8) expects documented, tested exit strategies and transition plans for ICT services that support critical or important functions, so this step produces the exit plan that later testing will exercise. The step closes when risk owners accept the residual risk in writing and the exit plan names the data formats, copies and procedures needed to leave the platform.
Design architecture and failure domains
Map the CRUSH hierarchy to your real failure boundaries, such as racks, rooms, power feeds and sites, and choose replication or erasure coding for each pool according to the recovery objectives agreed with the business. Decide where monitors, managers and object gateways run, how public and cluster networks are separated, and how traffic is encrypted. The design should show which failure combinations the cluster survives and which require a restore from backup. The step closes with an architecture document and a failure-domain diagram reviewed by the infrastructure and security architects.
Benchmark hardware before purchase
Test candidate drives, controllers, SSDs for WAL and DB or metadata, and network cards on a representative set of hosts before committing to a bill of materials. Ceph's hardware guidance calls for a dedicated drive per OSD, shared SSDs for WAL and DB on HDD-based OSDs, enterprise-class SSDs for metadata, and bonded network links across two switches, and it advises sizing memory for peak use and benchmarking because no two clusters are alike. Record throughput, latency under recovery load and memory use at peak. The step closes with a benchmark report that the purchase decision references.
Build the cluster with cephadm in test
Bootstrap a test cluster with cephadm, add hosts and services, and apply the failure-domain and pool layout from the architecture document. Run the same configuration management and change process that production will use, so that the build can be repeated and reviewed. Verify that the cluster reaches a healthy state and that the placement, service and pool definitions are stored as version-controlled specifications. The step closes when a second build from the same specifications reproduces the test cluster without manual edits.
Harden security and integrate identity
Configure client authentication, encryption in transit with the messenger v2 secure mode, dashboard access and host access for cephadm. For the Object Gateway, connect the authentication sources your identity standards require, such as LDAP or Keystone, and enable multi-factor authentication where your access policy requires it. Where the Dashboard is used for administration, decide between SAML 2.0 and OAuth2 single sign-on and test the administrator login path with logging enabled. The step closes with a hardening checklist signed by the security team, showing each control, its configuration and the test that proved it.
Test backup, immutability and multisite recovery
Run restore tests from your backup tooling, verify that protected or immutable copies cannot be altered or deleted by ordinary administrators, and rehearse a site-level recovery using the multisite design. Record recovery time and recovery point results against the objectives agreed in the architecture step, and repeat the tests after any change to pools, sites or backup software. Segregation between production and backup administration should be checked during this testing. The step closes when the restore results, including failures and the fixes applied, are filed with the risk owners.
Collect audit evidence and hand over
Gather the evidence that auditors and supervisors are likely to request: configuration baselines, access reviews, change records, test results, the register entries and the exit plan, mapped to the controls your assessment scope requires. Hand the cluster to the operations team with runbooks for health warnings, drive replacement, monitoring and logging, and agree a patch and upgrade plan that tracks the supported Ceph releases. DeployOpen prepares this evidence for your assessors, but independent auditors and certification bodies issue any audit report or attestation. The step closes when the operations team runs a supervised change and the evidence index is accepted by compliance.

Does PCI DSS disk encryption apply to a Ceph cluster?

PCI DSS applies to a Ceph cluster whenever the cluster stores, processes or transmits cardholder data or sensitive authentication data, and also when it could affect the security of the cardholder data environment. The standard covers merchants, processors, acquirers, issuers and service providers, so a firm that holds card data on Ceph block, file or object storage should treat that cluster as in scope. Scope is not decided by the product. It follows the data flows: which volumes hold card numbers, which backup buckets receive copies, and which administrative paths can reach the OSD hosts, monitors and the RGW endpoints. Ceph nodes that share a network segment, identity system or hypervisor with the cardholder environment may also fall in scope, so map those dependencies before you size the controls.

PCI DSS v4.x offers two ways to meet a requirement. The defined approach follows the stated controls as written, while the customized approach, available to entities with robust security and risk management, meets the stated objective in a different way. PCI SSC guidance on compensating controls and the customized approach explains the difference. For encryption at rest on a Ceph cluster, the choice affects the evidence you must produce, such as key management records and proof that encrypted OSDs or encrypted RGW objects stay encrypted through recovery and replacement. The firm decides which approach to use for each requirement, and the Qualified Security Assessor reviews that decision as part of the Report on Compliance. Confirm the approach with your QSA before the build, not after the evidence is collected.

Ceph does not make a cluster compliant on its own. Encryption options, cephx authentication and msgr2 secure mode address parts of the picture, but each requirement needs your own configuration, key custody, logging and documented procedures, and the assessor decides whether the evidence is sufficient. Ask your QSA which requirements they expect you to evidence for storage, and which the payment brand's program treats as in scope for your entity type. Then have DeployOpen or your own team map each control to a specific Ceph setting, file or log source so the assessment is traceable.

Compliance evidence a Ceph build should produce

Auditors reviewing a Ceph storage estate under DORA, PCI DSS, SOX IT general controls and Swift CSCF ask for the same core records in different forms. Producing them during the build, rather than reconstructing them before an assessment, is what makes the evidence credible. DeployOpen prepares this evidence, while independent auditors and the PCI SSC templates govern validation.

Configuration baselines

Record the approved cluster configuration at handover: cephadm service specifications, CRUSH map and failure domains, network layout, enabled RGW features and dashboard settings. Store these as version-controlled files with a named owner and an approval date. Auditors compare live state against this baseline, so check that drift detection runs and that deviations are logged.

Access review records

Keep dated reviews of who holds cephx keys, dashboard accounts, RGW users and cephadm host access, with each grant tied to an approver. For SOX IT general controls, the access to programs and data is the area most often tested. Confirm that multi-factor authentication for dashboard and gateway access is enforced, and that exceptions are approved in writing.

Backup and restore test records

Retain dated restore tests for RBD images, CephFS data and RGW buckets, including the time taken, the data verified and the person who signed off. A backup job that completes is not evidence of recovery. Ask the team which restores were tested against a copy of production data and which were only exercised in a lab.

Change logs for upgrades

Each Ceph upgrade needs a change record covering the target release, the pre-upgrade health check, the rollback decision point, the test results and the approver. Tie the record to the release notes used for planning. Auditors reviewing program change controls will ask whether production changes followed the same path as test changes.

Exit and transition plans

DORA Article 28(8) expects documented, tested exit strategies for ICT services supporting critical or important functions. For a self-hosted Ceph estate, this means a written plan for moving data to another storage platform, the data formats involved and a rehearsal record. Confirm how data return would work on termination of any service provider's contract, as Article 30(2) requires.

Validation ownership and limits

DeployOpen prepares systems, controls and evidence, but does not issue audit reports, attestations or certifications. For PCI DSS, validation is a Report on Compliance by a Qualified Security Assessor or a Self-Assessment Questionnaire, each with an Attestation of Compliance. Ask your assessor early which evidence formats they accept before the build is designed.

What financial firms ask before a Ceph implementation

What does a Ceph implementation cost and what drives the price?

The cost is set by the written scope, not by a list price, and DeployOpen does not publish one. The main components are design work, hardware and network purchases, deployment and integration, hardening, backup and recovery testing, documentation and evidence for your assessors, and any ongoing support. Hardware is usually the largest one-time cost and it depends on capacity, the media mix and whether you need separate SSDs for metadata and WAL and DB. Recurring costs include support retainers, upgrades and staff time for operations. Ask for a quote that splits one-time and recurring items and states which environment, sites and gateways are covered. Ceph's own hardware guidance says to benchmark before buying because no two clusters are alike, so ask for that step to be in the scope.

How long does a Ceph build take for a financial firm?

Duration depends on how many sites you run, how much hardware must be sourced, how many services you enable (block, file and S3-compatible object storage), and how long your change, risk and security approvals take. Multisite recovery, encryption design and evidence collection add time because each needs sign-off from your own owners. Procurement lead time for servers, drives and switches is often the longest single item, so confirm it early. DeployOpen works to a fixed scope agreed in writing before work starts, so the timeline should be a deliverable in that document. Ask for milestones tied to test results, not only to installation dates.

What must our firm provide before a Ceph project starts?

Plan to supply four things: people, hardware and facilities, network, and policy decisions. On the people side, name an engineer who can approve changes, a storage owner, a security contact and a business owner for each service the cluster will support. For hardware, confirm rack space, power, cooling and whether drives, servers and switches are bought by you or by the partner. Network design needs two switches for bonded links and enough bandwidth between sites. Policy owners must decide retention periods, backup frequency, encryption key custody, access roles and recovery targets, because the build cannot finish without them. Write these inputs into the scope so delays have a named owner.

Can an internal team run a Ceph implementation without a partner?

An internal team can build Ceph, since the project is open source and cephadm manages clusters as containers, but the question is whether you have the skills and time to do it safely and repeatably. The work spans hardware selection, CRUSH failure domain design, placement groups, networking, authentication, encryption in transit, backup testing and upgrades. Most firms underestimate the operations side: health warnings, full OSDs, drive replacement and scrub errors all need trained staff on call. A useful test is whether your team can rebuild the cluster from documentation and run a recovery exercise without the original builders. Some firms build internally and buy a partner only for design review, hardening or a support retainer.

How does PCI DSS scope apply to Ceph storage?

Scope follows the data and systems, not the product. If the storage holds, processes or transmits cardholder data or sensitive authentication data, or could affect the security of the cardholder data environment, it falls within the assessed environment. Reducing scope usually means keeping card data out of the cluster, segmenting networks, and limiting access to the storage admin plane. Disk encryption requirements are met through a combination of controls you choose and document, so confirm with your Qualified Security Assessor how they will test your design. Your assessor, not DeployOpen, decides the final scope, and a Report on Compliance or Self-Assessment Questionnaire with its Attestation of Compliance is the form of validation.

How do we keep Ceph upgrades inside supported releases?

Start by checking the Ceph releases page, which lists the actively maintained releases, their latest point versions and estimated end-of-life dates. Plan upgrades before a release reaches end of life, and treat each major move as a project with a rehearsal in a non-production cluster. cephadm handles the container-based upgrade process, but it does not remove the need for pre-upgrade health checks, backups, a rollback decision and a change record that your change board can approve. Build a yearly review into your operations calendar and budget for the testing time. Ask any partner to include upgrade runbooks, a test plan and a supported-release register in the deliverables.

What does DORA require for a Ceph storage contract?

DORA requires financial entities to keep a register of information on all contractual arrangements for ICT services and, for services supporting critical or important functions, to document and test exit strategies. Contracts with ICT providers must state where services are provided and data processed, and they must cover data return on termination or insolvency. For a self-hosted Ceph build, your own contract with DeployOpen and any hosting provider both fall under these rules. Ask for the contract to name locations, data return terms and exit assistance, and keep the register entry current. Confirm the exact obligations with your competent authority or legal team.

What to ask an implementation partner before signing

Start with the written scope. Ask the partner to list every deliverable, the cluster components they will build (for example the Ceph monitors, OSDs, the Object Gateway and any CephFS or RBD services), the environments covered, and what the client must provide, such as hardware, network design sign-off, DNS and identity integration. Confirm that the scope names what is excluded, because gaps between scope items are where financial services projects usually stall. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and quotes follow from that written scope. No price list is published, so ask for a quote that itemizes each deliverable and states which items are one-time and which recur.

Next, ask how the partner handles the contract terms that DORA Article 30(2) requires for ICT services. Your contract must state where services are provided and where data is processed, require advance notice of changes, and cover data return on termination or provider insolvency. Ask who will document the storage locations and failure domains in the register of information that DORA Article 28(3) requires, and who keeps the exit strategy and transition plan that Article 28(8) asks you to test. Ask whether the partner can show a documented exit path for the Ceph data, such as how an RGW bucket or RBD image would be copied out to another platform. Check these answers against your own legal and third-party risk teams, since the regulation applies to your contracts, not the partner's template.

Ask whether restores are tested at the secondary site, not only backups. Request the test plan, the frequency, the evidence produced (restore logs, checksums, time to service) and who signs off the result. Ask how the partner documents PCI DSS scope decisions if any Ceph cluster stores, processes or transmits cardholder data or could affect that environment. The answer should name the scope boundary, the network segmentation, the encryption approach and the evidence kept for the Qualified Security Assessor or self-assessment. Finally, ask who supports upgrades after handover, what the support window is for each Ceph release, and whether support is a separate retainer. Confirm this in writing, because the Squid and Tentacle release lines have published end-of-life dates that will force upgrades on your schedule.

How DeployOpen works on this

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Ceph storage for financial firms. We scope the work in writing first, then build and verify it against the controls your auditors and supervisors will test, and hand over the evidence and runbooks your team needs to operate it.

How we scope

Written, fixed-scope agreement covering the Ceph services, sites and data classes in your environment
Mapping of backup, segregation, encryption and audit requirements to specific cluster and gateway configuration
Confirmation of which contractual, residency and exit-strategy records your ICT third-party register needs

How we build

cephadm deployment across your data centers or cloud accounts, with failure domains and network bonding designed upfront
Encryption, client authentication and RGW access controls configured and verified against your documented policies
Recovery and failover tests run for multisite designs, with results recorded for your resilience testing program

How we hand over

Architecture, configuration and runbook documentation written for your operations and security teams
Evidence packs of configuration, test results and access settings prepared for your auditors and assessors
Knowledge transfer sessions so your engineers can run upgrades, restores and capacity changes independently

How we support

Optional retainer for ongoing support, scheduled upgrades within your planned release path, and patching
Periodic restore testing and configuration review as your retention, residency or compliance obligations change
Continuous security testing of the storage interfaces available through the same retainer, scoped in writing

Ceph for financial services