mazyar/tm_back
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
f68b6d7787ef5f9f23b205fc6d8b828d3d95fe8a
tm_back/docs/security/policies/backup-and-recovery-policy.md
T
Mazyar 06e663b691 Add security and compliance documentation for ISO/IEC 27001 
- Introduced a comprehensive suite of security documents to support ISO/IEC 27001 certification, including the ISMS Foundation, Risk Assessment Matrix, Gap Analysis Report, Statement of Applicability, and ISO27001 Roadmap.
- Updated the README to include links to the new security documentation, enhancing the project's compliance framework and providing clear guidance on security policies and procedures.

This addition strengthens the overall security posture of the Tender Management System and aligns with industry standards for information security management.
2026-06-11 01:53:24 +03:30

5.4 KiB
Raw Blame History

Backup & Recovery Policy

Field Value
Document ID POL-004
Version 1.0
Status Draft — Pending approval
Owner DevOps Lead
Maintained By DevOps Lead
Effective Date Pending approval
Review Cycle Annual
ISO 27001 Reference A.8.13 — Information backup

Related: Information Security Policy | Incident Response Plan

1. Purpose

This policy defines backup requirements, retention periods, and recovery objectives for Tender Management System data to ensure business continuity and data protection.

2. Scope

Covers backup and recovery for:

Asset ID Backup Method
MongoDB (tm database) A-001 Automated snapshots / mongodump
MinIO object storage A-003 Bucket replication or periodic sync
Redis A-002 RDB snapshots (cache — lower priority)
Application configuration A-010 Version-controlled templates; secrets in vault
Application logs A-011 Log aggregator retention

3. Recovery Objectives

Metric Definition Target
RTO (Recovery Time Objective) Maximum acceptable downtime 4 hours (production API)
RPO (Recovery Point Objective) Maximum acceptable data loss 1 hour (MongoDB); 24 hours (MinIO documents)

RTO/RPO are reviewed annually and after major architecture changes.

4. Backup Requirements

4.1 MongoDB

Parameter Requirement
Frequency Continuous oplog / hourly snapshots (production)
Retention Daily: 30 days; Weekly: 12 weeks; Monthly: 12 months
Storage Separate region/account from production
Encryption Encrypted at rest (AES-256 or provider equivalent)
Access DevOps Lead + break-glass only

Collections in scope: companies, customers, users, tenders, notices, feedback, notifications, and all domain collections.

4.2 MinIO

Parameter Requirement
Frequency Daily incremental; weekly full sync
Retention 30 days rolling
Scope files and documents buckets (company docs, tender JSON, translations)
Encryption Server-side encryption enabled
Versioning Bucket versioning enabled where supported

4.3 Redis

Parameter Requirement
Frequency Daily RDB snapshot
Retention 7 days
Note Redis holds ephemeral cache/session data; rebuild acceptable within RTO

4.4 Configuration & Secrets

  • Infrastructure-as-code and config templates in Git
  • Production secrets in secret manager (not backed up in plaintext)
  • Secret manager backup per provider documentation

5. Backup Security

  1. Backups classified C3 Confidential — same protection as source data
  2. Backup storage not publicly accessible
  3. Backup access logged and restricted to authorized DevOps personnel
  4. Backup encryption keys managed separately from backup data
  5. No backup data transferred to unauthorized regions (GDPR data residency compliance)

6. Recovery Procedures

6.1 MongoDB Full Restore

  1. Identify target recovery point (timestamp before incident)
  2. Provision clean MongoDB instance or restore to staging first
  3. Restore from snapshot / mongodump
  4. Verify document counts and sample integrity checks
  5. Update application connection string
  6. Run application smoke tests (auth, tender list, company profile)
  7. Monitor for 24 hours post-restore

6.2 MinIO Restore

  1. Identify affected buckets/prefixes
  2. Restore from backup or cross-region replica
  3. Verify file accessibility via file store service
  4. Re-run worker jobs for any missing derived data (translations)

6.3 Partial Restore (Single Collection / Document)

  • Use point-in-time recovery or selective mongorestore
  • Requires IC approval for production partial restores
  • Audit log entry required

7. Backup Testing

Test Frequency Success Criteria
MongoDB restore to staging Monthly Data integrity verified; app connects successfully
MinIO file restore (sample) Quarterly Random files readable and checksum-valid
Full DR simulation Annual RTO/RPO met in tabletop or live test
Backup job monitoring Daily All scheduled backups complete without error

Test results documented with date, tester, outcome, and remediation items.

8. Responsibilities

Role Responsibility
DevOps Lead Implement and monitor backups; conduct restore tests
ISO Verify policy compliance; include backup status in management review
Engineering Lead Validate application behavior post-restore
IC (during incident) Authorize production restore; communicate status

9. Failure Handling

If a scheduled backup fails:

  1. Automated alert to DevOps on-call
  2. Investigate and re-run within 4 hours
  3. If unrecoverable, escalate to P2 incident if production data at risk
  4. Document failure and resolution in backup log

10. Document Control

Version Date Author Changes
1.0 2026-06-11 Engineering Initial policy

Approval

Role Name Signature Date
DevOps Lead Pending
ISO Pending
Reference in New Issue View Git Blame Copy Permalink