Backup & Recovery —
what is protected,
and how it is restored.

What this policy covers

This Backup and Recovery Policy defines the standards, procedures, and obligations governing the protection and recovery of data processed by the VIGIL platform operated by Anshin Risk and Resilience Consulting Private Limited (ARRC Global). It applies to:

• All data stored in production systems supporting the VIGIL platform — databases, file storage, configuration, and application state
• All client data held within the platform — uploaded intelligence, assessment outputs, user accounts, and associated records
• All infrastructure configuration required to restore the platform to a functional state
• All personnel with responsibilities in the backup or recovery process

This policy is referenced by the Incident Response Plan — when recovery from backup is required during an incident, this policy governs the procedure. The two documents are designed to work together.

The commitments that define what "good" looks like

Recovery objectives define the maximum acceptable data loss (RPO) and the maximum acceptable time to restore service (RTO) following a failure requiring recovery from backup. These are not aspirational targets — they are the standards against which backup architecture and recovery procedures are designed and tested.

The complete scope of backup coverage

The following data categories and system components are included in VIGIL's backup programme. Everything necessary to restore the platform to a fully functional, data-complete state is covered.

Databases

• Primary application database (PostgreSQL). Full database backup daily. Continuous transaction log shipping enabling point-in-time recovery to any point within the current backup window.
• All client data within the database. Client account records, user data, assessment data, risk registers, and all associated platform records are covered by the primary database backup. Client data is backed up as part of the platform-wide backup — there is no separate client-by-client backup schedule.

File Storage

• Client-uploaded documents and intelligence files. All files uploaded by clients to the platform are backed up daily alongside the database backup.
• Assessment outputs and generated reports. Structured output files generated by the platform are covered by the daily backup.
• Application and configuration files. Platform application code is version-controlled in a source code repository (providing its own version history). Deployed application state and runtime configuration are backed up daily.

Infrastructure Configuration

• Server configuration. Infrastructure configuration is version-controlled and stored separately from the primary platform infrastructure, enabling rebuild of the server environment from a known-good state.
• Security configuration. Access control lists, firewall rules, TLS certificates, and security-relevant configuration are covered by infrastructure backup.

What Is Not Backed Up

• Ephemeral session data. Active session tokens and in-memory session state are not backed up — they are by design short-lived and not required for recovery.
• Temporary processing files. Intermediate files created during assessment processing that are not persisted to the database or file storage are not individually backed up — they are reconstructable from the source data.

Frequency, timing, and how long backups are kept

Backup jobs are automated and scheduled. Job completion — success or failure — is logged and monitored. A failed backup job triggers an alert to the operations team within 30 minutes of the scheduled completion time. Failed backup jobs are investigated and resolved before the next scheduled backup window; if resolution is not possible within that window, the Founding Principal is notified.

Protecting backups against the same threats as production data

A backup that is not secured is not a backup — it is a second copy of the attack surface. VIGIL's backup security applies controls equivalent to or exceeding those on production data.

• Encryption at rest. All backup files are encrypted using AES-256 before being written to backup storage. Encryption keys are managed separately from the backup data and rotated on a defined schedule.
• Encryption in transit. Backup data is transmitted to backup storage over encrypted channels using TLS 1.3. No backup data traverses the network in plaintext.
• Access restriction. Access to backup storage is restricted to the minimum personnel and systems required for backup operations. Backup storage credentials are separate from production credentials and are rotated independently.
• Geographic separation. Weekly and monthly backups are stored in a geographically separate location within the EU, ensuring that a single physical failure cannot simultaneously destroy both production data and backups.
• Immutable backup storage. Backup storage is configured with write-once protections for the retention period — backup files cannot be modified or deleted before their retention period expires except by an authorised explicit deletion operation. This protects against ransomware attacks that attempt to encrypt or destroy backups alongside production data.
• Integrity verification. Each backup is hash-verified at creation. Integrity hashes are stored separately and verified at each backup test and before any recovery operation. A backup with a failed integrity check is treated as corrupt and not used for recovery — the previous verified backup is used instead.
• No backup data in development. Backup data is never used in development or staging environments. Test data in non-production environments is synthetically generated or anonymised.

Verification that backups actually work

An untested backup is an assumption. VIGIL's backup testing programme verifies that recovery is possible — not just that backup jobs complete — on a documented, regular cadence.

• Quarterly restoration test. At least once per quarter, a full restoration from the most recent daily backup is performed in an isolated non-production environment. The test verifies: (a) backup integrity hash passes; (b) restoration completes within the RTO of 4 hours; (c) restored data is consistent and complete; (d) the restored platform reaches an operational state.
• Point-in-time recovery test. At least annually, a point-in-time recovery test is performed using transaction log backups, verifying recovery to a specific historical point within the 7-day log retention window.
• Post-incident test. Following any incident that triggers a recovery from backup, a fresh restoration test is conducted from the post-incident backup set before the next quarterly test falls due, to confirm backup integrity was not affected by the incident.
• Test documentation. Every backup test is documented with: the date and time of the test, the backup set used (type and creation date), the tester's identity, the outcome (pass/fail), the time taken for restoration, and any issues identified. Test records are retained for 2 years.
• Failed test response. A failed backup test — whether due to corrupt backup, incomplete restoration, integrity hash failure, or RTO breach — is treated as a high-priority operational issue. The root cause is identified and resolved before the next scheduled production backup window. The Founding Principal is notified of any test failure on the day of occurrence.

From decision to restored service — step by step

Recovery from backup is initiated when a failure, incident, or data integrity issue cannot be resolved through other means. The decision to initiate recovery requires authorisation from the Founding Principal or designated Incident Lead.

Specific provisions for enterprise client data

• Client data is covered by the platform-wide backup. There is no separate per-client backup schedule. Client data is protected as part of the overall platform backup — the same frequency, encryption, retention, and testing standards apply to all client data without distinction.
• Recovery point applies to all clients equally. In a platform-wide recovery scenario, all clients are restored to the same recovery point. ARRC Global cannot restore one client's data to a different point in time than another's within a single platform recovery operation.
• Client notification of data loss. Where a recovery operation results in data loss, affected clients are notified of: the recovery point used; the period of data affected; the categories of data within that period; and any actions clients can take to reconstruct or resubmit data that was lost.
• Client data export before recovery. Where time permits before initiating recovery, an export of current client data state is attempted and preserved — even if the current state is partially corrupted — to maximise the data available for potential reconciliation after restoration.
• Client-requested recovery. Clients may not directly initiate or specify recovery operations. Recovery is an operational decision made by ARRC Global in response to a failure or incident. Clients who believe their data has been corrupted or lost should contact ARRC Global immediately at contact@arrcglobal.com.

How backups are securely removed at end of retention

• Automated deletion at retention expiry. Backup files are automatically deleted when their retention period expires. Deletion is confirmed by the backup management system and logged.
• Client data deletion from backups. When a client subscription terminates and client data is deleted from production systems, client data within the backup sets is not deleted immediately — it persists within the existing backup until each backup file reaches its natural retention expiry and is deleted in the scheduled rotation. The maximum period client data persists in backups after subscription termination is 60 days (the retention period of the weekly backup), plus the time remaining on any active backup at the point of termination. This is explicitly disclosed in the Data Processing Agreement.
• Secure deletion standard. Backup deletion overwrites the storage medium using a secure deletion method appropriate to the storage type — consistent with the deletion standards defined in the Data Retention Policy.
• Deletion logging. All backup deletions — whether automated at retention expiry or manual on instruction — are logged with the backup ID, deletion date, and deletion method. Deletion logs are retained for 3 years.

Accountability for backup and recovery

• Founding Principal. Policy owner. Authorises all production recovery operations. Notified of all backup job failures and failed backup tests on the day of occurrence. Reviews this policy annually.
• Development and operations team. Responsible for: implementation and maintenance of backup automation; monitoring and responding to backup job alerts; conducting quarterly backup tests; maintaining backup documentation; and executing recovery procedures under the direction of the authorised Incident Lead.
• Incident Lead (during incidents). Authorises recovery operations where delegated by the Founding Principal during an active incident. Coordinates recovery actions with the operations team. Responsible for client and principal notification at each recovery milestone.

Policy maintenance and document access

This policy is reviewed annually and updated following any recovery operation, failed backup test, or material change to the platform's data architecture or backup infrastructure. Recovery objectives (RPO and RTO) are reviewed following each recovery event to confirm they remain appropriate and achievable.

Enterprise clients and procurement teams requiring the full Backup and Recovery Policy document — including backup architecture diagrams, test records summary, and recovery runbooks — may request it below.