Securing ISMS Data: Backup Strategy for Self-Hosted Compliance Systems

No backup, no certification

If you run your ISMS self-hosted, you have full control over your data. That is the central advantage over a SaaS solution. But with that control comes a responsibility that the provider handles for you with cloud solutions: data backup.

This sounds obvious, and yet it happens regularly: a server fails, a hard drive dies, an update goes wrong, or a ransomware attack encrypts the system. And then it turns out that the last backup is three months old, was never tested, or resided on the same server.

With a regular application server, that is annoying. With your ISMS system, it is potentially existential. Your ISMS contains the risk register, the control status, audit reports, incident documentation, and all the evidence you need for your certification. If this data is gone, you do not simply start over — you lose the documented proof of your entire security work. In the worst case, your ISO 27001 certification is at risk because you can no longer produce the required records.

This article walks you through building a solid backup strategy for your self-hosted ISMS, step by step.

What you need to back up

An ISMS system typically consists of three components, all of which must be backed up:

1. The database

The database is the heart of your ISMS. This is where all structured data resides: risks, controls, audit entries, user accounts, permissions, and configurations. Most self-hosted solutions use PostgreSQL or MySQL/MariaDB.

Why a filesystem backup of the database is not enough: If you simply copy the data directory of PostgreSQL or MySQL while the database is running, you may get an inconsistent state — open transactions, half-written blocks, missing WAL entries (Write-Ahead Log). Such a backup may be unusable in an emergency. That is why you need a logical backup via the database tools.

2. The filesystem

In addition to the database, ISMS systems store files on the filesystem:

• Uploads: Uploaded documents such as policy PDFs, audit reports, training records, certificates.
• Configuration files: Application configuration, database connection, SMTP settings, license keys.
• Media: Screenshots, diagrams, network maps.

These files must be backed up separately since they are not in the database.

3. The application configuration

This includes:

• Web server configuration: Nginx or Apache virtual host configuration, SSL certificates.
• Environment variables: .env files or systemd configurations with database passwords and API keys.
• Cron jobs: Automated tasks such as the backup scripts themselves, report generation, or cache cleanup.
• SSL certificates: If you use your own certificates (not Let's Encrypt, which auto-renews).

Database backup with pg_dump

For PostgreSQL, pg_dump is the standard tool for logical backups. It produces a SQL file or a compressed archive containing the complete database contents.

Basic backup

pg_dump -h localhost -U isms_user -d isms_db -Fc -f /backup/isms_db_$(date +%Y%m%d_%H%M%S).dump

Parameters explained:

• -h localhost: Connect to the local database server.
• -U isms_user: Database user with read permissions on all relevant tables.
• -d isms_db: Name of the ISMS database.
• -Fc: Custom format. Compressed, supports selective restore and parallel restore. Significantly better than -Fp (plain SQL).
• -f /backup/...: Output file with timestamp in the filename.

For MySQL/MariaDB

mysqldump -h localhost -u isms_user -p --single-transaction --routines --triggers isms_db | gzip > /backup/isms_db_$(date +%Y%m%d_%H%M%S).sql.gz

Important: --single-transaction ensures the backup is consistent without locking the database. This only works with InnoDB tables (the default in MariaDB and modern MySQL).

Filesystem backup

For files on the filesystem, rsync or tar works well:

tar czf /backup/isms_files_$(date +%Y%m%d_%H%M%S).tar.gz \
  /var/www/isms/uploads/ \
  /var/www/isms/.env \
  /var/www/isms/config/ \
  /etc/nginx/sites-available/isms.conf

Adjust the paths to your installation. The specific directories depend on the ISMS software used. For ISMS Lite, the relevant paths are listed in the installation documentation.

Encrypting backups with AES-256

ISMS backups contain your risk register, incident reports, and audit results. An unencrypted backup on a network share, an external hard drive, or even cloud storage is a security incident that just has not been discovered yet.

Why AES-256?

AES-256 (Advanced Encryption Standard with 256-bit key) is the current standard for symmetric encryption. It is recommended by the BSI, recognized in all relevant compliance frameworks, and is considered quantum-computer-resistant by current standards. For backup encryption, there is no reason to use anything else.

Encryption with OpenSSL

openssl enc -aes-256-cbc -salt -pbkdf2 -iter 100000 \
  -in /backup/isms_db_20260315_020000.dump \
  -out /backup/isms_db_20260315_020000.dump.enc \
  -pass file:/etc/isms-backup/encryption.key

Parameters explained:

• -aes-256-cbc: AES-256 in CBC mode.
• -salt: Adds a random salt to prevent rainbow table attacks.
• -pbkdf2 -iter 100000: Key derivation with 100,000 iterations, slows down brute force.
• -pass file:...: Reads the password from a file instead of the command line (more secure because it does not appear in the process list).

Encryption with GPG (alternative)

GPG offers the advantage of asymmetric encryption. You encrypt with the public key and only need the private key for decryption:

gpg --encrypt --recipient backup@your-company.com \
  --output /backup/isms_db_20260315_020000.dump.gpg \
  /backup/isms_db_20260315_020000.dump

The advantage: the private key does not need to reside on the backup server. It can be stored separately and is only needed for the restore. This reduces the risk that an attacker who compromises the backup server can also decrypt the backups.

Key management

The password or key for backup encryption is the single most important key in your entire backup concept. If you lose it, all encrypted backups are worthless. If an attacker finds it, they can read all backups.

Recommended storage:

• Primary: On the backup server in a file with restrictive permissions (chmod 600, root only).
• Secondary: In a password manager or a physical safe, accessible to at least two authorized persons.
• Not: In the git repository, in an email, on a sticky note, or in the application's .env file.

Offsite copy: The second line of defense

The 3-2-1 principle of data backup states: 3 copies, on 2 different media types, 1 of which is offsite. For ISMS backups, the offsite copy is particularly important because a ransomware attack that hits your ISMS server will probably encrypt local backups as well.

Option 1: Copy encrypted backup to a second location

rsync -avz --progress /backup/isms_db_20260315_020000.dump.enc \
  backup-user@offsite-server:/backup/isms/

The offsite server should:

• Be at a different physical location (not in the same building).
• Have its own credentials (not the same as the production server).
• Not accept incoming SSH connections from the production server (only the backup server connects to the offsite server, not the other way around).

Option 2: S3-compatible object storage

Many hosting providers offer S3-compatible object storage, including European providers like Hetzner, Contabo, or IONOS. This lets you push encrypted backups to the cloud without giving up data sovereignty — because the backups are already client-side encrypted:

aws s3 cp /backup/isms_db_20260315_020000.dump.enc \
  s3://isms-backup/2026/03/15/ \
  --endpoint-url https://s3.eu-central-1.example.com

Since the backup is encrypted before upload, the storage provider cannot read the data. You use the cloud only as a storage medium, not as a data processor.

Option 3: Immutable backups

For maximum protection against ransomware, immutable backups are ideal. S3 Object Lock or WORM storage (Write Once Read Many) prevents once-written backups from being modified or deleted — not even by an attacker with admin rights.

Testing restores: A backup you have never tested does not exist

You will read this statement in every backup article, and yet "restore never tested" is the most common backup mistake. With ISMS data, this is particularly dangerous because you may not notice the data loss until months later — namely during the next audit or management review.

Why restore tests fail

The most common reasons a restore does not work:

• Missing dependencies: The database version on the restore system does not match the backup version.
• Wrong permissions: The database user who owns the tables does not exist on the restore system.
• Corrupt backups: The backup was interrupted during writing or the storage medium has errors.
• Missing encryption keys: The key for decryption is no longer available.
• Incomplete backups: Database was backed up, but uploads are missing, or vice versa.

Restore procedure for PostgreSQL

# 1. Decrypt backup
openssl enc -d -aes-256-cbc -pbkdf2 -iter 100000 \
  -in /backup/isms_db_20260315_020000.dump.enc \
  -out /tmp/isms_restore.dump \
  -pass file:/etc/isms-backup/encryption.key

# 2. Create database (or empty existing one)
createdb -h localhost -U postgres isms_restore_test

# 3. Restore backup
pg_restore -h localhost -U postgres -d isms_restore_test \
  --no-owner --role=isms_user /tmp/isms_restore.dump

# 4. Verify: Count records in critical tables
psql -h localhost -U isms_user -d isms_restore_test \
  -c "SELECT 'risks' AS table_name, COUNT(*) FROM risks
      UNION ALL SELECT 'controls', COUNT(*) FROM controls
      UNION ALL SELECT 'incidents', COUNT(*) FROM incidents
      UNION ALL SELECT 'audits', COUNT(*) FROM audits;"

# 5. Clean up
dropdb -h localhost -U postgres isms_restore_test
rm /tmp/isms_restore.dump

Restore test plan

Recommendation: Perform the restore test quarterly. Document the result as evidence for internal audits and management reviews. In ISMS Lite, you can create the restore test as a recurring task with assigned responsibility and deadline, so it is not forgotten.

Retention periods for audit data

Not every backup needs to be kept forever. But for ISMS data, special requirements apply because auditors can review historical data.

ISO 27001 and retention

ISO 27001 requires in Clause 7.5 (Documented Information) that records be retained that provide evidence of conformity and the effectiveness of the ISMS. The standard does not specify a minimum duration, but in practice the following benchmarks apply:

NIS2 and retention

NIS2 does not define explicit retention periods, but the NIS2 reporting deadlines and documentation obligations suggest that incident reports and risk assessments should be retained at least for the period during which regulatory inquiries are possible. In practice, we recommend at least 5 years for all security-related records.

Retention strategy for backups

Not every backup needs to be retained for years. A proven strategy:

• Daily backups: Retained for 30 days.
• Weekly backups: Retained for 12 weeks (Sunday backup is kept).
• Monthly backups: Retained for 12 months (backup from the 1st of the month).
• Annual backups: Retained for 5 years (backup from January 1st).

This scheme ensures that you can access daily snapshots in the short term and that historical data for audits is available long-term, without letting storage requirements explode.

Automation via cron

Manual backup is not backup. It gets forgotten, postponed, executed incorrectly. Automation is not optional — it is mandatory.

Complete backup script

#!/bin/bash
# ISMS Backup Script
# Backs up database and filesystem, encrypts and transfers offsite

set -euo pipefail

# Configuration
BACKUP_DIR="/backup/isms"
OFFSITE_HOST="backup@offsite.example.com"
OFFSITE_DIR="/backup/isms"
DB_NAME="isms_db"
DB_USER="isms_user"
ENCRYPTION_KEY="/etc/isms-backup/encryption.key"
ISMS_DIR="/var/www/isms"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
LOG_FILE="/var/log/isms-backup.log"
RETENTION_DAYS=30

# Logging
exec >> "$LOG_FILE" 2>&1
echo "=== Backup started: $(date) ==="

# 1. Database backup
echo "Starting database backup..."
pg_dump -h localhost -U "$DB_USER" -d "$DB_NAME" -Fc \
  -f "$BACKUP_DIR/db_${TIMESTAMP}.dump"
echo "Database backup complete."

# 2. Filesystem backup
echo "Starting filesystem backup..."
tar czf "$BACKUP_DIR/files_${TIMESTAMP}.tar.gz" \
  "$ISMS_DIR/uploads/" \
  "$ISMS_DIR/.env" \
  "$ISMS_DIR/config/" \
  2>/dev/null || true
echo "Filesystem backup complete."

# 3. Combine
echo "Creating full archive..."
tar cf "$BACKUP_DIR/isms_full_${TIMESTAMP}.tar" \
  -C "$BACKUP_DIR" \
  "db_${TIMESTAMP}.dump" \
  "files_${TIMESTAMP}.tar.gz"
echo "Full archive created."

# 4. Encrypt
echo "Encrypting backup..."
openssl enc -aes-256-cbc -salt -pbkdf2 -iter 100000 \
  -in "$BACKUP_DIR/isms_full_${TIMESTAMP}.tar" \
  -out "$BACKUP_DIR/isms_full_${TIMESTAMP}.tar.enc" \
  -pass file:"$ENCRYPTION_KEY"
echo "Encryption complete."

# 5. Clean up temporary files
rm -f "$BACKUP_DIR/db_${TIMESTAMP}.dump"
rm -f "$BACKUP_DIR/files_${TIMESTAMP}.tar.gz"
rm -f "$BACKUP_DIR/isms_full_${TIMESTAMP}.tar"

# 6. Offsite transfer
echo "Transferring backup offsite..."
rsync -az "$BACKUP_DIR/isms_full_${TIMESTAMP}.tar.enc" \
  "$OFFSITE_HOST:$OFFSITE_DIR/"
echo "Offsite transfer complete."

# 7. Delete old backups (local retention)
echo "Cleaning up old backups..."
find "$BACKUP_DIR" -name "isms_full_*.tar.enc" -mtime +$RETENTION_DAYS -delete
echo "Cleanup complete."

# 8. Create checksum
sha256sum "$BACKUP_DIR/isms_full_${TIMESTAMP}.tar.enc" \
  >> "$BACKUP_DIR/checksums.sha256"

echo "=== Backup complete: $(date) ==="
echo "File: isms_full_${TIMESTAMP}.tar.enc"
echo "Size: $(du -h "$BACKUP_DIR/isms_full_${TIMESTAMP}.tar.enc" | cut -f1)"

Setting up the cron job

# Daily backup at 02:00
echo "0 2 * * * root /opt/scripts/isms-backup.sh" > /etc/cron.d/isms-backup
chmod 644 /etc/cron.d/isms-backup

Monitoring the backup job

A backup script that fails silently is worse than no script at all. Monitor the backup job:

Option 1: Email notification on failure

Add at the end of the script:

if [ $? -ne 0 ]; then
  echo "ISMS backup failed on $(date)" | \
    mail -s "ALERT: ISMS Backup Failed" admin@your-company.com
fi

Option 2: Healthcheck ping

Use a service like Healthchecks.io or your own endpoint:

# At the end of a successful backup
curl -fsS -m 10 --retry 5 https://hc-ping.com/your-uuid > /dev/null

If the ping is missing, you get a notification.

Option 3: Logging and monitoring integration

Write backup results to your central logging system (syslog, Graylog, ELK) and create an alert when the daily backup entry is missing.

Checklist: ISMS backup strategy

Common mistakes with ISMS backups

Mistake 1: Backup and production system on the same server. That is not a backup — it is a copy on the same disk. In the event of a hardware failure or ransomware attack, both are gone. At minimum, the offsite copy must be physically separated.

Mistake 2: Unencrypted backups on cloud storage. You invest in the security of your ISMS, but the backup of your risk register sits unencrypted in an S3 bucket? That is a contradiction the auditor will notice at the latest.

Mistake 3: Restore never tested. By far the most common mistake. Investing 30 minutes quarterly in a restore test can save you weeks of rebuilding work. Schedule the test as a fixed appointment — just like the internal audit.

Mistake 4: Only backing up the database, not the files. Many backup scripts only back up the database. But if the uploads (policy PDFs, audit reports, certificates) are missing, the restore is incomplete. An ISMS without the uploaded documents is like a filing cabinet without files.

Mistake 5: Losing the encryption key. The key is on the backup server and nowhere else. The server dies. The backups exist but nobody can decrypt them. Store the key in at least two independent locations, and ensure that at least two people have access.

Special case: Backup during certification

If you are preparing for ISO 27001 certification or are in an ongoing certification cycle, additional recommendations apply:

Before the audit: Create a complete backup and a separate snapshot. If something goes wrong during the audit (unlikely but possible), you have a defined state.

During the certification cycle: Ensure that the backup strategy itself is documented in the ISMS. The auditor will ask about it. The data backup policy should explicitly cover ISMS data.

After changes: When you make major changes to the ISMS (new risk assessment, SoA update, policy change), create an additional backup before the change. If something goes wrong, you can revert to the previous state.

The backup strategy in the bigger picture

Your ISMS backup strategy does not exist in isolation. It should be part of your general backup strategy and embedded in the overarching disaster recovery plan. The RPO and RTO for your ISMS system should be explicitly defined:

• RPO (Recovery Point Objective): How many hours of ISMS data can you afford to lose at most? With daily backups at 02:00, you lose nearly 24 hours in the worst case. Is that acceptable? For most companies, yes, because ISMS data does not change by the minute.

• RTO (Recovery Time Objective): How quickly must the ISMS be available again after an outage? Half a day? A full day? In most cases, the ISMS is not business-critical in the sense of "production is down," but during an active security incident, you need access to your incident response procedure.

Tip: Keep the most important procedures (incident response, escalation paths, contact details) available offline as well — for example, as a printed IT emergency handbook. Then a brief ISMS outage is not a showstopper in an emergency.

Conclusion

A self-hosted ISMS gives you full control over your most sensitive security data. This control also obligates you to handle data backup yourself. Database backup, filesystem backup, encryption, offsite copy, automated execution, and regular restore tests — none of these steps is optional. Start today if you have not already. The first backup is the most important one.

Further reading

• Your Company's Crown Jewels: Why ISMS Data Needs Special Protection
• Data Backup According to BSI: The 3-2-1-1-0 Principle in Practice
• Backup Strategy and Restore Tests: Because Backups Alone Are Not Enough
• Creating a Disaster Recovery Plan: From Emergency Back to Normal Operations
• Self-Hosted vs. Cloud: Data Sovereignty for Compliance Software