CISO Assistant Data Backups

While the CISO Assistant service is backed up at a platfrom level you can also carry out data backups as well as Vaultwarden if you use this to manage secure passwords and secrets to access CISO Assistant.

Local Vaultwarden Operational Backup Script

To implement a zero-downtime, safe live snapshot of your core credential store (vaultwarden.db) along with its associated configuration data and attachments, deploy this automated backup script on your host system.12

Step 1: Create the Backup Execution Script

Create a new shell script file within your system binary directory:12

sudo nano /usr/local/bin/backup-vault.sh

Paste the following production-ready automation script into the editor:12

#!/bin/bash

# Vaultwarden Zero-Downtime Backup & Encryption Script

TIMESTAMP=$(date +%Y%m%d-%H%M%S)

BACKUP_DIR="/opt/vciso-infra/vaultwarden-data/backups"

TARGET_FILE="$BACKUP_DIR/vault_backup_$TIMESTAMP.sqlite3"

# 1. Capture a safe, atomic live snapshot of the active SQLite file

sqlite3 /opt/vciso-infra/vaultwarden-data/data/vaultwarden.db ".backup '$TARGET_FILE'"

# 2. Package configuration parameters, metadata, and attachment structures

tar -czf "$BACKUP_DIR/vault_assets_$TIMESTAMP.tar.gz" -C /opt/vciso-infra/vaultwarden-data/data attachments config.json

# 3. Encrypt the backup artifacts using your team's public armor identity key

gpg --encrypt --recipient security@youragency.eu "$TARGET_FILE"

gpg --encrypt --recipient security@youragency.eu "$BACKUP_DIR/vault_assets_$TIMESTAMP.tar.gz"

# 4. Enforce a clean runtime state by removing unencrypted raw binaries

rm "$TARGET_FILE"

rm "$BACKUP_DIR/vault_assets_$TIMESTAMP.tar.gz"

# 5. Prune old archives beyond a 14-day tracking history window to save space

find "$BACKUP_DIR" -type f -mtime +14 -delete

Save the file and exit the editor (Ctrl+O, Enter, Ctrl+X).

Step 2: Configure Script Permissions & Cron Schedule

Make the backup file executable and schedule it to run automatically every night at 2:00 AM using the system crontab:12

# Set strict file permissions

sudo chmod +x /usr/local/bin/backup-vault.sh

# Append the execution window to the system crontab

echo "0 2 * * * root /usr/local/bin/backup-vault.sh" | sudo tee -a /etc/crontab

Application Instance Configuration & SQLite Backups

If you are also leveraging a standalone backend layout running on local file-based storage, you can use the native clone_instance Django management command to safeguard the core compliance repository and evidence revisions.3

[CISO Assistant Instance] ──► clone_instance ──► [Encapsulated Destination]

 (Active DB + Media Attachments)                   (Consistent Snapshot Copy)

Routine Maintenance & Backup Automations

To prevent potential file corruption or lock contentions during a running transaction, stop the application stack cleanly before initiating file duplication:3

# Terminate the application service daemon

systemctl stop ciso-assistant  

# Execute the cloning mechanism to establish a consistent snapshot copy

python manage.py clone_instance \

 --dest-db /backup/db.sqlite3 \

 --dest-attachments /backup/attachments  

# Restart the application service daemon

systemctl start ciso-assistant 

Automated Daily Backup Script (Cron Alignment)

To integrate full application snapshots into an automated pipeline without interactive prompts, embed the --force option directly inside a daily cron instruction:3

0 2 * * * cd /app/backend && python manage.py clone_instance \

 --dest-db /backups/daily/ciso-$(date +\%Y\%m\%d).sqlite3 \

 --dest-attachments /backups/daily/attachments-$(date +\%Y\%m\%d) \

 --force

CISO Assistant Recovery & Disaster Recovery GuideThis guide details the step-by-step process for restoring your CISO Assistant instance from previously captured full backups or SQLite database clones.12

1. At a Glance: Restoration Methods

Depending on your architecture and how your backups were generated, select the corresponding restoration path:

• Method A: CLICA Streaming Restore (Recommended): Best for restoring full backups (backup.json.gz + manifest tracking) across network perimeters safely without loading enormous archives into host memory.12

• Method B: Raw SQLite Stack Restoration: Best for standalone deployments utilizing the file-based clone_instance engine.12

2. Method A: CLICA Full Streaming Restore

The restore-full command executes an idempotent, memory-efficient restoration sequence that reads your local manifest and uploads your data in streaming batches.12

Step 1: Verify Your Directory Contents

Ensure your target recovery source directory contains all mandatory database records and tracking artifacts:12

• backup.json.gz: The core compressed metadata archive.12

• backup-manifest.jsonl: The append-only manifest file tracking your file hashes.12

• attachments/evidence-revisions/: Your physical documentation uploads.12

Step 2: Execute the Recovery Command

Run the streaming execution script from your terminal environment:12

uv run clica.py restore-full --src-dir ./db --verify-hashes

Note: If the upload is interrupted due to a transient network error, simply execute the same command again to safely resume progress without duplicating files.Restoring a full backup will replace all active records in your target instance. Ensure you have captured a precautionary snapshot of your target environment before running this command.12

Step 3: Regenerate Identity Tokens

Because the core database has been completely overwritten, your previous API access session keys are no longer valid. You must log in via the primary web dashboard interface and immediately regenerate your Personal Access Token.12

3. Method B: Raw SQLite Stack Restoration

If your operational workflow relies on basic SQLite clones generated via Django management utilities, use this local stack replacement sequence:12

Step 1: Halt the Active Stack

Stop the application daemon completely to prevent write collisions or database locking:12

systemctl stop ciso-assistant

Step 2: Copy the Target Database and Attachments

Manually replace your active runtime components with your verified snapshot archives:12

# Overwrite the production SQLite file

cp /backups/daily/ciso-20260708.sqlite3 /backup/ciso-assistant.sqlite3

# Sync your physical attachments repository back into media space

cp -r /backups/daily/attachments-20260708/* /backup/attachments/

Step 3: Align Environment Variables

Verify your environment settings match your restore location paths:12

export SQLITE_FILE=/backup/ciso-assistant.sqlite3

export LOCAL_STORAGE_DIRECTORY=/backup/attachments

Step 4: Revive the Stack

Restart the application service to point live traffic at your recovered database:12

systemctl start ciso-assistant

4. Post-Recovery Validation

Once your instance is fully online, execute these quality assurance checks:12

1. Run Status Checks: Execute python manage.py status to check that file sizes and object counts align with your pre-disaster metrics.1

2. Verify the X-Rays Dashboard: Open the /x-rays frontend route to verify that the validation engine scans your perimeters correctly and that no newly imported data records trigger unexpected integrity warnings.2

Disaster Recovery Mock Testing Schedule

This schedule outlines a structured approach for conducting a mock disaster recovery (DR) restoration exercise for CISO Assistant. The objective is to validate your replication scripts, verify backup data integrity, and ensure the engineering squads can achieve a graceful recovery within our targeted recovery time objectives (RTO).

1. Exercise Parameters & Assumptions

Before launching the mock exercise, the technical teams must align on the testing boundaries to prevent unintended disruption to active compliance tracking:

• Production Environment Safeguards: Testing must be conducted on an isolated staging instance or a dedicated recovery perimeter. The live platform will remain online under cold standby monitoring during the exercise window.

• Data Volume Readiness: Storage account volumes and history lengths will not be reduced before the test, allowing teams to measure realistic database extraction and hash verification performance.

• Dependencies: The standalone n8n orchestration engine and Kafka message dispatcher will be put into a paused queue state to prevent data collisions while the database is being overwritten.

2. High-Level Mock Testing Timeline

  T-2 Weeks                  T-1 Week                  T-24 Hours                T-0 (Test Window)

┌──────────────┐          ┌──────────────┐          ┌──────────────┐          ┌───────────────────────┐

│ Runbook      │─────────►│ Pre-Test     │─────────►│ Go/No-Go     │─────────►│ 4-Hour Testing        │

│ Finalized    │          │ Vol Checks   │          │ Briefing     │          │ Execution Window      │

└──────────────┘          └──────────────┘          └──────────────┘          └───────────────────────┘

• T-2 Weeks: Finalize the recovery runbook variants and distribute roles across the DevOps and Security squads.

• T-1 Week: Perform volume and sync lag recovery script checks in the test repository.

• T-24 Hours: Convene the Senior Leadership Team (SLT) for the formal Go/No-Go briefing based on environment stability.

• T-0 (Test Day): Open a 4-hour technical bridge call to execute the restoration, tracking progress against an active 1.5-hour downtime threshold.

3. Step-by-Step Scenario Execution Runbook

Step 1: Initialize Environment and Pre-Test Checks

• Action: Validate network perimeters and confirm that the target recovery database file size matches the production metadata catalog.

• Command: Ensure the recovery path contains the core compressed files and an append-only transaction manifest before starting:

• ls -lh /backups/daily/

• 
  

Step 2: Stop Traffic and Isolate Services

• Action: Pause incoming telemetry streams from asset scanners and halt the active application service daemon to guarantee transactional consistency.

• Command:

• systemctl stop ciso-assistant

• 
  

Step 3: Stream Database and Metadata Restoration

• Action: Execute an idempotent, streaming upload using the command-line architecture to recover all core perimeters, domains, and processing objects.

• Command:

• uv run clica.py restore-full --src-dir /backups/daily/db_snapshot/ --verify-hashes

• 
  

Step 4: Synchronize Revisions and Applied Controls

• Action: Re-establish the physical asset and evidence attachments repository while linking the technical vulnerability fields back to their respective compliance objects.

• Command:

• cp -r /backups/daily/attachments_snapshot/* /backup/attachments/

• 
  

Step 5: Revive the Stack and Regenerate Security Keys

• Action: Point live traffic paths at the newly recovered SQLite database location, bring the system daemon back online, and immediately cycle all Personal Access Tokens (PAT).

• Command:

• systemctl start ciso-assistant

• 
  

4. What-If Scenario Matrix (Incident Playbook)

ID

Incident Scenario

Impact / Likelihood

Mitigation / Response Strategy

Status

1

Hash Mismatch on Evidence

Local file hashes diverge from manifest entries during verification.

Med / Low

The streaming protocol will flag and report corrupted items. Execute standalone asset synchronization scripts to re-pull missing historical revisions.

Monitored

2

Token Synchronization Failure

Automated webhooks fail to authenticate after database overwrite.

High / Low

Access the system administrator backdoor portal manually. Re-issue service account keys and update the n8n environment configuration parameters.

Accepted

3

Replication Sync Lag

Data volume limits extend processing times beyond the 1.5-hour window.

High / Med

If replication bounds drop below acceptable SLAs, abort the process and restore the environment to the cold standby snapshot.

Accepted

5. Post-Exercise Validation Requirements

To conclude the exercise and transition back to normal operations, the auditing squad must review the system using the platform's automated quality checks:

• Object Count Verification: Run internal state audits to guarantee that the total number of domains, perimeters, and asset objects matches pre-test statistics.

• X-Rays Data Quality Scan: Access the +/x-rays frontend route to verify that the validation engine parses the recovered perimeters correctly. Ensure no data fragmentation has caused unexpected Ownership Gaps or Evidence Inconsistencies.

Post-Incident Report Template & Lessons Learned Framework

This template provides a standardized structure for summarizing performance metrics, recovery timelines, and procedural insights following the mock disaster recovery (DR) exercise.1

1. Document Control

This section tracks the lifecycle, iteration state, and formal approval chain of the post-incident assessment.1

Date

Version

Status

Reviewers

Jul 09, 2026

v1.0

Draft

Information Security Team / DevOps Lead

2. Management Summary

A high-level overview of the simulated disaster recovery operation, captured for leadership visibility.1

• Exercise Scope: Idempotent full streaming recovery and asset synchronization using the Model Context Protocol (MCP) and command-line interfaces.2

• Target Windows:

  • Recovery Time Objective (RTO) Target: 1.5 hours.

  • Actual Execution Duration: 1h 12m.

• Data Integrity Verification Rate: 100% of cryptographic file hashes validated successfully against the reference manifest.2

• Raised Action Items: 2 post-incident improvements identified.1

3. Incident Summary & Execution Timeline

Incident Description

A structured, non-disruptive dry-run execution conducted within an isolated staging environment to validate production backup continuity, verify data integrity, and measure realistic replication speed.2

Major Activities and Timeline

The technical sequence executed across the engineering bridge call during the test window:1

Date / Time

Component

Activity

Jul 09, 2026, 2:00 PM

Service Daemon

Halted the active application service container to isolate the environment and guarantee a static file state.2

Jul 09, 2026, 2:15 PM

Database Core

Initiated restore-full streaming via the command line layer. Compressed metadata block backup.json.gz read sequentially.2

Jul 09, 2026, 2:45 PM

Verification

Automated integrity handler executed --verify-hashes routine. Validated local SHA256 signatures against backup-manifest.jsonl.2

Jul 09, 2026, 3:00 PM

Media Store

Synchronized physical attachments and evidence revisions into the local directory structure.2

Jul 09, 2026, 3:12 PM

Security Keys

Revived application services and executed administrative session resets.2

4. Process Lessons & Performance Assessment

An analysis of technical performance and gaps observed during the recovery window.13

• What Handled Well: The streaming framework successfully bypassed high-memory ZIP packaging steps, preserving system resources and enabling continuous status tracking during file ingestion.2

• Observed Bottlenecks: The initial database configuration required manual session overrides to re-establish secure API paths following data restoration.2

• Data Quality State: Running an inspection through the X-Rays Dashboard confirmed that all restored perimeters, domains, and assets mapped accurately without introducing structural information gaps or unassigned ownership records.

5. Corrective Actions Summary

The following tracking entries have been raised to institutionalize lessons learned from the exercise:1

• Action PI01 — Personal Access Token Automation: Script the post-restoration generation of Personal Access Tokens (PAT) for service accounts to minimize manual API downtime.2

  • Target Deadline: 14 Days.

  • Owner: DevOps Engineering.

• Action PI02 — Manifest Protection Policy: Codify automated directory permissions ensuring the append-only backup manifest file remains secure and unalterable across all replication nodes.2

  • Target Deadline: 30 Days.

  • Owner: Cloud Infrastructure Team.