Skip to main content

Compliance

Regulators and auditors require evidence that backups are restorable. Manual restore drills run infrequently and produce inconsistent evidence. Kymaros automates restore testing on a schedule and produces a RestoreReport resource for each run, providing machine-generated, timestamped evidence that recovery procedures were exercised.

This guide maps Kymaros capabilities to specific compliance controls and explains how to produce evidence for auditors.

SOC 2 — CC7.5​

Control: Recovery procedures are tested to ensure they meet defined recovery time objectives and enable resumption of data processing.

How Kymaros satisfies it:

  • RestoreTest resources define a recurring schedule, ensuring tests run at a documented frequency.
  • Each test records the measured RTO in kymaros_rto_seconds and in the RestoreReport status.
  • Health checks validate that the restored application is functionally operational (pods ready, HTTP endpoints responding, database queries succeeding), not just that files were copied.

Evidence to collect for auditors:

  1. Export all RestoreReport resources for the audit period: 
    kubectl get restorereports -n kymaros-system -o yaml > restorereports-q1-2026.yaml
  2. Show the RestoreTest schedule field to demonstrate the test cadence.
  3. Export Prometheus data for kymaros_score and kymaros_rto_seconds over the audit period as a graph or CSV.

ISO 27001 — Control 8.13: Information backup​

Control: Backup copies of information, software, and system images shall be tested regularly in accordance with backup policy.

How Kymaros satisfies it:

  • The backupSource field in RestoreTest explicitly links each test to a named backup, making the scope of what is being tested auditable.
  • RestoreReport records the backup name, test timestamp, score, and which checks passed or failed.
  • The backup age metric (kymaros_backup_age_seconds) demonstrates that the tested backup was recent.

Evidence to collect for auditors:

  1. The RestoreTest manifest, which documents the backup scope, schedule, and acceptance criteria (health checks).
  2. A series of RestoreReport resources showing consistent pass/fail history.
  3. The AlertManager rule RestoreTestNotRun as evidence that test execution gaps are detected and alerted.

DORA — Articles 11 and 12: ICT resilience testing​

Applicability: Digital Operational Resilience Act, applicable to EU financial entities and their ICT third-party providers.

Articles:

  • Article 11: ICT Business Continuity Policy — requires testing of ICT continuity capabilities.
  • Article 12: ICT Response and Recovery plans — requires periodic testing of recovery plans to ensure effectiveness.

How Kymaros satisfies it:

  • Automated nightly restore tests constitute continuous resilience testing of ICT backup and recovery capabilities, satisfying the "periodic testing" requirement.
  • RestoreReport provides a tamper-evident record (stored as a Kubernetes resource with creation timestamps managed by the API server) of when tests were run and their outcomes.
  • RTO measurement supports the Article 12 requirement to verify recovery time objectives are met in practice.

Evidence to collect for auditors:

  1. The full history of RestoreReport resources for the ICT systems in scope.
  2. A summary showing the percentage of tests that met RTO targets over the assessment period.
  3. Incident records (if any) from AlertManager showing that test failures triggered notification workflows.

DORA's technical standards (RTS) require documentation of test methodology. Include the HealthCheckPolicy or inline check configuration as documentation of what "successful restoration" means for each system.

HIPAA — Contingency Plan (§ 164.308(a)(7))​

Control: Required implementation specifications under the Contingency Plan standard include: Data Backup Plan, Disaster Recovery Plan, and Testing and Revision Procedures.

How Kymaros satisfies it:

  • Testing and Revision: Automated restore tests fulfill the requirement to periodically test contingency plans.
  • Data Backup Plan: RestoreTest resources document which backups cover which systems and what constitutes a successful restore.

Evidence to collect for auditors:

  1. RestoreTest manifests for all systems containing ePHI (electronic Protected Health Information).
  2. RestoreReport history demonstrating tests were conducted at the frequency defined in the contingency plan.
  3. Notification configuration showing that test failures are routed to appropriate personnel.

Note: HIPAA does not specify a minimum test frequency. Document your chosen frequency in your contingency plan and demonstrate that Kymaros enforces it via the schedule field.

PCI-DSS — Requirement 12.3.4: Hardware and software technologies reviewed​

Applicability: PCI-DSS v4.0, Requirement 12.3.4 applies to organizations storing, processing, or transmitting cardholder data.

Control: Hardware and software technologies are reviewed at least once every 12 months to confirm they continue to receive security fixes and support, and protect against known vulnerabilities.

Adjacent control — Requirement 9.4.5 and 12.10.1: Backup and recovery procedures must be tested.

How Kymaros satisfies it:

  • Restore tests provide documented evidence that backup media is functional and that cardholder data environments can be recovered.
  • Health checks that include resourceExists (for Secrets containing encryption keys or credentials) provide evidence that cryptographic material is included in backups.

Evidence to collect for auditors:

  1. RestoreReport history for environments containing cardholder data.
  2. Health check configurations that explicitly verify critical resources (Secrets, ConfigMaps containing references to encryption key identifiers).

Compliance dashboard (Team tier)​

The Kymaros dashboard includes a Compliance page available on the Team tier and above. The page is gated by the compliancePage feature flag.

The Compliance page aggregates test results across all RestoreTest resources and maps them to the frameworks above. It provides:

  • Pass rate by test over the selected time period (default: 90 days).
  • Per-framework control status (satisfied / at risk / not tested).
  • A summary table suitable for sharing with auditors.

To access the Compliance page:

  1. Open the Kymaros dashboard.
  2. Navigate to the Compliance tab in the left sidebar.
  3. Select the time period using the period selector (30, 60, or 90 days).

The period is passed to the API as a numeric value (number of days). The API endpoint is GET /api/compliance?period=90.

Exporting data for auditors​

Export all RestoreReports as YAML​

kubectl get restorereports -n kymaros-system \
  --sort-by=.metadata.creationTimestamp \
  -o yaml > kymaros-evidence-$(date +%Y%m%d).yaml

Export RestoreReports for a date range​

kubectl get restorereports -n kymaros-system -o json \
  | jq '[.items[] | select(.metadata.creationTimestamp >= "2026-01-01T00:00:00Z" and .metadata.creationTimestamp < "2026-04-01T00:00:00Z")]' \
  > kymaros-q1-2026.json

Export Prometheus metrics as CSV​

If you use Prometheus with the HTTP API:

curl -G 'http://prometheus:9090/api/v1/query_range' \
  --data-urlencode 'query=kymaros_score' \
  --data-urlencode 'start=2026-01-01T00:00:00Z' \
  --data-urlencode 'end=2026-04-01T00:00:00Z' \
  --data-urlencode 'step=86400' \
  | jq -r '.data.result[] | [.metric.test, (.values[] | join(","))] | @csv' \
  > kymaros-scores-q1-2026.csv

PDF reports (Enterprise tier)​

Enterprise deployments include PDF report generation. The PDF report for a RestoreTest includes:

  • Test metadata (name, schedule, backup source).
  • Full health check configuration.
  • Run history with timestamps, scores, and RTO measurements.
  • Pass/fail breakdown per check.
  • A signed attestation page with the operator version and report generation timestamp.

PDF reports are generated via the API:

GET /api/restore-tests/{name}/report.pdf?period=90

The report is suitable for direct submission to auditors as evidence documentation without further transformation.

To access PDF report generation, verify your license tier includes the Enterprise features. Contact your account team to enable the pdfReports feature flag.