Ceph controls for ISO 27001 backup and cryptography

Start with the data whose loss would stop the business soonest, then work outward. Rank each system by the recovery time and recovery point your policy sets for it, and restore the top tier first so the test proves the recovery path you would rely on in a real incident. A typical first set includes one RBD volume that backs a production database, one CephFS subtree with user-shared files, and a sample of RGW buckets holding application data. Include at least one object in a bucket with Object Lock retention, because that path uses different permissions and can fail differently. Record the scope of each test in writing before it starts, so the results can be compared with the same scope in later rounds.

The frequency should come from your backup policy, which A.8.13 requires you to define and follow, not from a default chosen by the storage team. Set separate intervals for full restores of critical systems, partial restores of individual objects or volumes, and restores from any off-cluster or immutable copy. Tie each interval to a trigger as well, such as a Ceph major upgrade, a change to replication or CRUSH rules, a change to KMS integration, or a site change. Expect the frequency to recur, since every test consumes staff time and temporary capacity. Ask your assessor which intervals they expect to see evidence for, and confirm that the policy text and the test calendar agree.

Restore into a separate pool, RGW zone, or cluster that has no client mounts, no replication link to production, and no shared credentials with production. For RBD, export a snapshot or backup image into a restore pool and attach it to a test host only. For RGW, restore into a bucket owned by a test user, or into a separate zone. Block the test environment from reaching production monitors and from writing to production buckets, and confirm this with a network check before the run. If encryption keys are involved, the test should prove that the restore target can fetch keys from the external KMS under its own identity, so the test covers the key path as well as the data path.

Compare a cryptographic digest of the restored data with a digest recorded at backup time, and keep both values in the test record. For files and RGW objects, store a SHA-256 checksum alongside the object or in a manifest, then recompute it after restore. For RBD images, compare checksums of exported extents or of a filesystem inside the image, and record the snapshot ID used for the source. Also compare object counts, total bytes, and metadata such as ownership, ACLs and Object Lock retention dates. A matching size alone does not prove integrity. Ask your team to confirm which hash algorithm your policy names, because the audit evidence should show the same algorithm from backup through restore.

Separate the people who run the restore from the people who accept the result. The operator who performs the restore should not be the only person who signs the outcome. A typical sign-off includes the system owner who confirms the restored data is usable, a security or compliance representative who confirms the integrity method was followed, and a manager who accepts any exceptions. Keep the backup administrator role distinct from the approver where the platform supports it, and record names, roles and dates in the test record. If you use an external partner for testing, the sign-off remains with your organization, because the internal policy owner decides whether the test met the requirement.

A useful record lets an auditor follow one test from scope to result without asking the team questions. Include the test identifier, date, the source and target identifiers, the snapshot or backup point used, the restore method and command or procedure version, and the integrity method with its digest values. Record start and end timestamps for each step, the elapsed time against the recovery time objective, the achieved recovery point, and any errors or retries. Note failures in full, including the symptom, the cause if known, and the decision taken. Store records in a system with access control and retention, and keep a link to the change or ticket that started the test.

Treat a failed restore as a finding with an owner and a closure date, not as a footnote. Log the failure in the same record as the test, classify its impact on the recovery objectives, and open a corrective action in your issue tracker. Typical causes include expired or unavailable keys in the external KMS, missing replication after a CRUSH or pool change, snapshot retention shorter than the backup policy, and incomplete manifests. Verify each fix by repeating the failed step, then attach that second result to the original finding. Assessors look for this loop, so a log that shows only passing tests can raise questions about whether failures are reported.

Your own team can run restore tests if it has access to an isolated target, the backup tooling, the KMS path and a reviewed procedure. The main gaps are usually time, independence and documentation. Staff who maintain the cluster may be too close to the production configuration to test it objectively, and routine tests can be deferred during incidents. A partner can plan the test program, write the procedures and record templates, run an initial set of tests and train your staff to repeat them. Define the scope, deliverables and timeline in writing before work starts, so the handover to your team is clear. Ask any provider to show how their test records map to your policy.

The cost follows the written scope, and four factors move it most: cluster size, the number of backup targets and replication or recovery sites, the KMS integration, and how wide the restore tests and evidence process need to be. A single-site cluster with one backup target and a basic key workflow is a much smaller job than a multi-site design with separate recovery accounts, Object Lock retention and an external KMS wired into every encryption path. Ask the vendor to price each factor separately so you can see which choice changes the total.

The one-time work covers mapping the controls to your environment, designing backup targets and retention, configuring encryption at rest and msgr2 secure mode, integrating the key management service, running the first restore tests and assembling the initial evidence pack. The recurring work covers repeating restore tests on your chosen schedule, reviewing key access and rotation, keeping the evidence current after Ceph upgrades, and updating the records when the cluster changes. Confirm with the vendor whether the restore test cadence and evidence refresh are included in the fixed scope or sit under a separate retainer.

No duration has been fixed for this work, so the timeline depends on the written scope and on how quickly your team can provide access, approvals and existing policies. The critical path usually runs through the backup policy, the agreed recovery objectives, the KMS decision and the first documented restore test, because each depends on a decision from your side. Ask for a timeline in the quote that lists each milestone, the inputs you must supply, and the point at which the evidence pack is handed over.

Three roles carry most of the load. An ISMS owner decides the backup policy, the cryptography rules and which evidence the audit scope requires. A storage administrator provides cluster access, owns the Ceph configuration and runs or observes the restore tests. A security reviewer checks key custody, access to backup accounts and the encryption choices against your risk assessment. Expect each role to be involved at defined points rather than full time, and confirm the named people and their hours before the scope is signed.

Yes, if your team already runs Ceph in production, has a working external KMS and can carry out restore tests with documented results. The gaps usually appear in the evidence process: mapping each control to a configuration, keeping dated records of restore tests and tracking key lifecycle events in a form an auditor can sample. Assess your skills against the control list before deciding. A partner is most useful when you need the design and evidence structure delivered quickly or when the internal team lacks time to run the tests.

ISO does not certify organizations. Accredited certification bodies issue ISO/IEC 27001 certificates after auditing the management system, and they operate to ISO/IEC 17021-1 with ISO/IEC 27006-1 applied to all clients by 31 March 2026. A certification cycle lasts three years, with at least one audit, either surveillance or recertification, in every calendar year. DeployOpen prepares systems, controls and evidence for that assessment but does not issue audit reports, attestations or certificates. Confirm the certification body you intend to use and its accreditation status before you plan the evidence timeline.

Ask for the scope stated as controls, systems and environments: which Ceph clusters, which backup targets, which KMS and which key types are in scope. Request a deliverables list covering the control mapping, configuration records, restore test reports and the evidence pack index. Ask which items are one-time and which recur, what the retainer covers if you choose one, what your team must provide and by when, how changes to scope are priced, and what happens if an audit finding requires rework. Confirm the cluster version with the vendor, since supported Ceph releases change the configuration steps.

Confirm the release your cluster runs and whether it is in the actively maintained set. The Ceph releases page lists Tentacle (20.2.x) and Squid (19.2.x) as actively maintained, with estimated end-of-life dates of June 1, 2027 and October 31, 2026 respectively. Those dates affect the evidence plan because a control design built on a release nearing end of life may need an upgrade before the next audit cycle. Ask the vendor to show how the upgrade work and its evidence would be scoped and priced.