Backup Policy

This policy mandates backup and restore requirements for Tanqory Inc. to protect availability, integrity, and confidentiality of data across all systems and confidentiality tiers. It binds employees, contractors, and counterparties, and should be read with BCP/DR, Data Classification, Access Control, and Incident Response to ensure legal and industry compliance.

1) Scope, Purpose, and Roles

Scope covers customer data, transactions, system configs, applications, files/media, code, documentation, and logs across Production/Staging/Development and with external providers. Purpose: prevent loss, minimize downtime, meet defined RPO/RTO, and comply with legal/contractual duties. Security owns policy/monitoring; Infrastructure/IT executes backups/restores; system/data owners set classification and RPO/RTO; Compliance checks adherence; all parties follow approved runbooks.

2) Backup Principles and Strategy

Use 3‑2‑1‑1‑0: at least 3 copies, 2 media types, 1 offsite, 1 immutable/air‑gapped, and zero errors after test. Combine full/incremental/snapshot by data type. Automate via orchestrated jobs with monitoring/alerts on failure. Critical data uses near‑real‑time replication/streaming logs. Cross‑region backups for disaster resilience and immutable copies for ransomware risk. Track all steps in ticketing/work management for auditability.

3) RPO/RTO and System Tiers

RPO/RTO by data class: Restricted (1h/1h), Confidential (4h/4h), Internal (24h/8h), Public (7d/24h). Critical DB/payment: replication + hourly snapshots; customer files: 4h incremental; configs: version control + daily backup; security logs: streaming near‑real‑time. Contract/legal obligations use stricter values captured in agreements/appendices.

4) Backup Schedule and Retention

Baseline: continuous replication; hourly snapshots (kept 24h); daily full (30 days); weekly full (90 days); monthly full (1 year); annual archive (7 years). Include cross‑region and immutable/offsite copies. Retention may adjust for tax/finance and data protection limits (e.g., personal log limits). Primary DB keeps WAL/redo logs ≥7 days for PITR. Changes require Security/Compliance approval and runbook updates.

5) Storage, Security, and Encryption

Encrypt backups at rest (e.g., AES‑256) and in transit (TLS 1.2/1.3). Store on diverse media (block/object, offsite) with Need‑to‑Know and RBAC/ABAC. Use immutable/air‑gapped storage for critical sets. Backup vault access requires MFA and audit logging; validate integrity (hash) before usability. Offsite storage must be region/AZ separated with clear contractual/legal controls.

6) Testing and Recovery

Restore testing cadence: monthly for critical, quarterly for general, and at least annual tabletop + technical restores. Include PITR, RPO/RTO verification, data integrity, and dependency checks. Log test results, errors, restore times, and action items with owners/deadlines. If RPO/RTO not met, adjust backup/DR design to meet targets.

7) Monitoring, Alerts, and Incident Handling

Monitor jobs/storage/integrity; alert on failures/space/hashes. Backup incidents (repeated failures, missing immutable copy, hash mismatch) feed into Incident Response within SLA and SIEM for trends. If personal data is involved, follow Data Breach Policy and legal notice rules. Post‑incident reviews drive runbook/schedule updates. Flow: failure alert → diagnose (system/space/rights/network) → fix/rerun → hash verify → ticket + SIEM → escalate to Incident Response if SLA/PII impact → post‑incident review.

8) Change Control and Governance

Architecture/schedule changes go through Change Management, approved by Security/Infra/Compliance, recorded in tickets, and reflected in runbooks/DR Plan. Security sets policy and audits practice; Infra/IT executes; Data Owners set classification/retention; Compliance verifies legal/contract alignment.

9) External Providers and Transfers

Backup processors/hosts require risk assessment and contracts covering security, encryption, deletion at term, and lawful cross‑border transfer (SCC/Addendum). Must support Privacy Policy/DPA rights (delete/export) with proof of deletion on request. Provider changes require stakeholder notice and successful restore testing before cutover.

10) Business Continuity and BCP/DR Integration

Backup plans tie to BCP/DR, naming critical systems, owners, first‑wave recovery steps, and required resources. DR drills include backup restore tests at least annually and must evidence target RPO/RTO. Where SLA/Order Form sets stricter RPO/RTO, use those values. Status/incident communications follow the Incident/BCP Communication Plan via durable medium (email/dashboard).

11) Review and Improvement

Review at least annually or upon major system/cloud/storage/legal/standard changes. Use test/audit/incident findings to improve schedules, encryption, retention, and testing. Material changes are versioned/dated and announced to stakeholders via email/dashboard. English controls; conflicting contract terms prevail.

Appendix A: Mapping to Standards (Examples)

• ISO/IEC 27001:2022 Annex A: A.5, A.6, A.7, A.8, A.9, A.12, A.18 — covered across Sections 1–11.
• SOC 2 TSC: CC6, CC7, CC8 — covered in Sections 2–9.
• PCI DSS: Req.7/8, Req.12 — covered in Sections 2–7/10.
• GDPR/UK GDPR/PDPA: data minimization and integrity/confidentiality (Art.5/32) — covered in Sections 1/2/5/6/9.
• Add mappings for HIPAA, FedRAMP, FIPS 140‑2/3 as needed (crypto/access/logging specifics).

Appendix B: Strengthened Parameters (Illustrative)

• At rest: AES‑256 (FIPS‑validated if required). In transit: TLS 1.2/1.3, min 2048‑bit keys.
• Key/token rotation: Vault/Secrets every 60–90 days; API keys/service tokens max 90 days or stricter per contract/risk.
• Timeout/lockout: idle 15–30 minutes for critical systems; lockout after ~5 failed attempts (or stricter if mandated).
• If customer/law requires stricter values, apply those and record in contract/Order Form with audit evidence.

Glossary

• RTO (Recovery Time Objective): Max acceptable time to restore service after an incident.
• RPO (Recovery Point Objective): Latest acceptable data point to lose.
• Immutable Backup: Backup that cannot be altered/deleted during retention, reducing ransomware risk.
• Air‑gapped: Backup copy isolated from the primary network to prevent spread of attacks.
• PITR (Point‑in‑Time Recovery): DB recovery to a specific time.
• 3‑2‑1‑1‑0 Rule: 3 copies, 2 media, 1 offsite, 1 immutable/air‑gapped, 0 errors after tests.
• BCP/DR: Business Continuity/Disaster Recovery.
• WAL/Redo Logs: DB transaction logs for PITR.
• SIEM: Security Information and Event Management.
• Retention: Period backups are kept before deletion/anonymization.

---

Document Details