Encrypting ISMS Data: At Rest, In Transit, and In Backups

Why ISMS data is especially worth protecting

Not all data in a company is equally sensitive. Customer master data, project plans, and marketing material require protection, but their loss is typically manageable. ISMS data is in a category of its own. It systematically documents where a company is vulnerable.

A risk register lists which threats the company has identified and how likely and severe they are assessed to be. The risk assessment contains evaluations of which systems are insufficiently protected. The Statement of Applicability documents which security controls are not implemented and why. Audit reports list non-conformities and weaknesses. Action plans show which gaps remain open and when they are scheduled to be closed.

For an attacker, this is a treasure. Instead of searching for vulnerabilities themselves, they find a ready-made documentation of the attack surface. Where are the systems unpatched? Which controls are missing? Which risks has the company consciously accepted because the likelihood was deemed low? If this data falls into the wrong hands, the attacker has a detailed attack plan.

That is precisely why it is not enough to treat ISMS data like other business data. It needs encryption at every layer: when stored (at rest), when transmitted (in transit), and when backed up. Each of these layers has its own requirements and its own pitfalls.

AES-256-GCM for sensitive database fields

The first line of defense is encrypting data where it is permanently stored: in the database. There are different approaches with varying levels of protection.

Full disk encryption alone is not enough

Many companies rely on Full Disk Encryption (FDE) and consider it sufficient. BitLocker on Windows, LUKS on Linux, or FileVault on macOS encrypt the entire disk. This protects against one specific attack vector: the physical theft of the storage medium. If someone removes the hard drive from the server, they cannot do anything with it without the decryption key.

But FDE does not protect against the more common attack vector: an attacker who gains access to the running system over the network. Once the server is running and the disk is decrypted, the database is available in plaintext. Any process with access to the database files can read them. An attacker who gains root access to the server, a compromised backup process, or a database administrator with overly broad permissions sees everything unencrypted.

Full disk encryption is necessary, but it is the bottom layer. For ISMS data, you need an additional layer.

Transparent Data Encryption (TDE) as an intermediate step

Transparent Data Encryption encrypts the database files on disk, so copying the database files without the TDE key is useless. SQL Server, PostgreSQL, and MySQL offer TDE natively. The advantage: it requires no changes to the application. Encryption happens transparently at the database level.

The limitation: TDE protects data at rest at the file level, but not within the running database. A SQL query returns data in plaintext. An attacker with valid database credentials — whether through phishing, credential stuffing, or a SQL injection in the application — sees all data unencrypted.

For many use cases, TDE is a good compromise. For ISMS data, where confidentiality is the highest priority, it is not enough.

Field-level encryption with AES-256-GCM

The strongest protection for particularly sensitive data is field-level encryption. Rather than encrypting entire database files, specific columns or fields containing sensitive information are selectively encrypted. Encryption and decryption happen in the application layer, before the data is passed to the database.

ISMS Lite uses exactly this approach. Sensitive fields such as risk descriptions, vulnerability details, and audit findings are encrypted with AES-256-GCM before being written to the database. AES-256-GCM provides two properties that are particularly relevant for ISMS data:

Authenticated encryption. GCM (Galois/Counter Mode) is an authenticated encryption mode. It ensures not only confidentiality (no one can read the data) but also integrity (no one can tamper with the encrypted data undetected). If an attacker manipulates encrypted database fields, decryption fails instead of returning manipulated data. For a risk register whose integrity is audit-relevant, this is an important characteristic.

256-bit key length. AES-256 is considered secure against brute-force attacks by current standards, even considering potential quantum computers. The German Federal Office for Information Security (BSI) recommends AES with 128 or 256 bits in its Technical Guideline TR-02102-1. For data that needs long-term protection — like ISMS documentation — 256-bit is the right choice.

What gets encrypted and what does not

Not every database field needs to be encrypted. Field-level encryption has a performance overhead and makes certain database operations impossible (you cannot search or sort by encrypted fields without first decrypting them). The art lies in the correct classification.

Fields that should be encrypted:

Fields that do not need encryption:

The boundary follows the question: can an attacker derive an attack or identify a vulnerability from this field alone? If yes, encrypt. If no, it can remain in plaintext — which preserves performance and functionality.

TLS for all connections: Not just the web interface

The second layer of encryption concerns data in motion. Every time ISMS data is transferred from one system to another, it must be encrypted. This sounds obvious but is surprisingly often not the case in practice.

The web interface: TLS 1.3 as the minimum

That the web interface of an ISMS tool must run over HTTPS is obvious. Less obvious is which TLS version and which cipher suites are acceptable.

TLS 1.2 is still widely used and fundamentally secure when cipher suites are correctly configured. TLS 1.3, however, offers tangible improvements: the handshake is faster (one round-trip instead of two), insecure cipher suites are excluded by design, and forward secrecy is mandatory. For new installations, there is no reason to configure less than TLS 1.3.

What you must avoid:

• TLS 1.0 and 1.1 have been officially deprecated since 2021 and rejected by all major browsers
• SSL in any version (yes, this still exists on some older systems)
• Cipher suites with CBC mode (vulnerable to padding oracle attacks)
• Cipher suites without forward secrecy (RSA key exchange without ECDHE)

For self-hosted instances, a reverse proxy like Traefik or Caddy handles TLS termination automatically with Let's Encrypt certificates and secure defaults. You do not need to worry about cipher suite configuration yourself, as long as you keep the reverse proxy current.

API connections: The blind spot

Many ISMS tools offer a REST API for integrations: importing asset data from IT asset management, exporting risk data for management reporting, connecting to ticketing systems for control tracking. Each of these connections transmits ISMS data and must be encrypted.

In practice, API connections within the company network are often run unencrypted, on the logic that "it is only internal." This is a fallacy. An attacker moving through the internal network (lateral movement after an initial compromise) can read unencrypted internal traffic just as easily as external traffic. Network segmentation helps limit the blast radius, but it does not replace encryption.

All API calls must run over HTTPS — even within the internal network. Additionally, API authentication should use API keys or OAuth tokens that are regularly rotated.

Encrypting database connections

If the application and the database run on different systems (which is the case with a clean architecture), the connection between both must also be encrypted. MariaDB, PostgreSQL, and other databases natively support TLS-encrypted connections. With a Docker-based architecture — typical for self-hosted ISMS instances — this can be enforced through database configuration.

What frequently happens in practice: the application runs in the same Docker network as the database, and the connection runs unencrypted over the Docker bridge network. This is acceptable for a single server with both containers, as long as the server is physically and logically secured. Once the application and database run on different hosts, TLS for the database connection is non-negotiable.

Backup transfers: Often forgotten

If your backups are transferred over the network to a separate storage server or to the cloud, this transfer must be encrypted. Tools like restic, BorgBackup, and Veeam encrypt the transfer natively. If you transfer backups via rsync or SCP, encryption runs over SSH. Unencrypted backup transfers (FTP, unencrypted NFS) are not acceptable — not even on the internal network.

Backup encryption: The most commonly forgotten layer

Of the three encryption layers (at rest, in transit, backup), backup encryption is the most frequently overlooked. This is paradoxical because backups are often the easiest target.

Why backups are an attractive attack target

Backups have properties that make them particularly interesting for attackers:

They contain everything. A database backup contains all data, including historical data that may have already been deleted from the production system. An ISMS backup thus contains not just the current risk assessments, but also those from recent months and years — old incident reports and completed audit findings.

They often reside in less protected locations. The production system sits in a secured data center with physical access control, firewalls, and monitoring. Backups reside on a NAS in the server room, on external storage at the hosting provider, or in an S3 bucket — not always with the same security measures as the production system.

They are monitored less frequently. Access to the production system is logged and often monitored in real time. Access to backup storage goes unlogged or only rudimentarily logged in many companies.

They are retained for a long time. Backup policies often specify retention periods of 30, 90, or even 365 days. This means: if a backup created six months ago is compromised, the attacker has the data as of six months ago — including all vulnerabilities documented at that time.

Implementing encryption at the backup level

Every backup must be encrypted before storage. Not on the storage medium (that would again be just disk encryption), but as part of the backup process itself. The backup client encrypts the data before transferring it to backup storage. This way, the data is encrypted both during transfer and on the storage medium.

Common backup tools support this:

restic encrypts by default — you cannot even turn it off. That is the right design decision: encryption must be the default, not the option. For ISMS backups, restic is therefore a good choice.

The key must not reside with the backup

A common mistake: the backup password or encryption key resides in a configuration file on the same server that creates the backups. If an attacker compromises this server, they have both the encrypted backups and the key. The encryption is then worthless.

The key must be stored separately from the backup. Options include:

• Secrets manager like HashiCorp Vault, which provides the key at runtime without storing it on disk
• Key Management Service (KMS) of the cloud provider, if backups are stored in the cloud
• Offline storage of the master key in a physical safe, combined with an automated mechanism that derives working keys
• HSM (Hardware Security Module) for organizations with particularly high requirements

For an MSP operating ISMS instances for customers, the most pragmatic solution is a central secrets manager that manages the backup keys for all customer instances. This keeps the keys separated from the backup data and centrally administrable.

Key management with self-hosted: You hold the key

The most important question with any encryption is not the algorithm. AES-256 is secure — that is not up for debate. The most important question is: who has the key?

The key management problem with SaaS

With a SaaS solution, the provider manages the encryption keys. This is often the only practical solution technically, because the provider must decrypt the data to deliver the application. Even when the provider advertises that all data is "stored encrypted," they typically have access to the keys — and thus to the data in plaintext.

Some SaaS providers offer "Bring Your Own Key" (BYOK): you supply the encryption key, and the provider uses it for encryption. That sounds good but has a fundamental catch: as soon as the provider uses the key, it resides at least temporarily in the memory of their servers. An attacker who compromises the SaaS server can capture the key there. BYOK shifts trust; it does not eliminate it.

Other providers use a Key Management Service (KMS) from a cloud provider (AWS KMS, Azure Key Vault, Google Cloud KMS). That is better than a local key on the application server, but it means the cloud provider holds the master key. For the question "Who can read my ISMS data?" that means: the SaaS provider can, because they operate the application. The cloud provider theoretically can, because they operate the KMS.

Self-hosted: Full control over the key

With a self-hosted solution, you keep the encryption key. It resides on your infrastructure, under your control. No third party has access — neither the software vendor nor a cloud provider.

In ISMS Lite, the encryption key is generated during initial setup and stored in a configuration file on the server. You can move it to a secrets manager, offload it to an HSM, or implement any other key management that fits your infrastructure. The software accesses the key through a configurable interface and does not dictate where or how you store it.

For an MSP operating customer instances, this creates a clear model: each customer instance has its own encryption key. If instance A is compromised, instance B's data is unaffected because a different key is used. This is the isolation principle applied to cryptography.

Key rotation

Encryption keys should be regularly rotated. BSI TR-02102-1 does not specify a fixed deadline but recommends limiting the usage period of cryptographic keys. In practice, annual rotation for database keys has become established.

During key rotation, a new key is generated and the data is re-encrypted with the new key. With field-level encryption, this is more involved than with TDE because each encrypted field must be individually re-encrypted. However, the process can be automated and run in the background without interrupting operations.

What happens to the old key? It must be retained as long as backups encrypted with it exist. If you retain backups for 90 days, the old key must remain available for at least 90 days after rotation. Document the lifecycle of your keys in the cryptography policy.

Comparison: Who has the key with SaaS vs. self-hosted?

The following table summarizes how the encryption models differ:

The central insight: with SaaS you have encrypted data, but not exclusive control over the key. With self-hosted, you have both. For the auditor, the question "Who can decrypt your ISMS data?" has a clear answer with self-hosted: only you.

What this means for GDPR

GDPR mentions encryption in Article 32 as an appropriate technical measure. Even more relevant is Article 34(3)(a): if the affected data was encrypted during a data breach and the key was not compromised, notification of affected individuals may under certain circumstances be waived. This requires that the encryption was effective, the key is secure, and both can be demonstrated.

With self-hosted, this demonstration is easier because you control the key and can prove it was not compromised. With SaaS, you must rely on the provider's statements, making the demonstration to the supervisory authority more complex.

What this means for NIS2

NIS2 requires in Article 21(2)(h) "policies and procedures for the use of cryptography and, where appropriate, encryption." This encompasses not only the question of whether encryption is used, but also how and with which keys. Companies must be able to demonstrate that their encryption strategy meets current standards and that key management is appropriate.

For a company that self-hosts its ISMS, documenting its own encryption strategy is a direct compliance proof. For a company using a SaaS ISMS, it is a reference to the provider's documentation — over which it has no direct control.

Checklist: Encryption for ISMS data

At rest

• Full disk encryption active on the ISMS server (LUKS, BitLocker)
• Field-level encryption for sensitive database fields (AES-256-GCM)
• Encryption key stored separately from the database
• Key rotation documented and scheduled (at least annually)
• Old keys retained for the duration of backup retention

In transit

• TLS 1.3 configured for the web interface
• TLS 1.0 and 1.1 disabled
• API connections exclusively over HTTPS
• Database connection encrypted (if application and DB on different hosts)
• Backup transfers encrypted (SSH, TLS)
• HSTS header set for all web interfaces

Backup

• Backup encryption activated (AES-256)
• Backup key stored separately from backup storage
• Restore test with encrypted backup performed
• Backup retention periods defined and documented
• Old backups securely deleted after retention expiry

Key management

• All encryption keys inventoried
• Key lifecycle documented (generation, rotation, archival, destruction)
• Emergency process for key loss defined
• Access to keys restricted to named individuals
• Cryptography policy created and approved

Common mistakes when encrypting ISMS data

Encryption on only one layer. TLS for the browser, but unencrypted database fields and unencrypted backups. Or encrypted database, but backups in plaintext. Encryption only works when consistently implemented across all layers. The weakest layer determines the overall protection level.

Key in the source code or in the configuration file next to the database. If the encryption key resides in the same directory as the database, it offers no additional protection against an attacker with filesystem access. The key must be physically or logically separated from the encrypted data.

No restore test. Encryption makes backups more complex. If you lose the key or the decryption process has a bug, your backups are worthless. Regularly test whether you can actually restore an encrypted backup. Bare-metal recovery should be part of your test plan.

Outdated algorithms. 3DES, RC4, SHA-1 have no place in a current encryption strategy. Regularly check whether the algorithms and key lengths in use meet current BSI recommendations.

Encryption without documentation. If you have not documented which data is encrypted how, which algorithms and key lengths you use, and how key management is organized, you cannot demonstrate in an audit that the encryption meets requirements. The cryptography policy is not optional.

Conclusion: Encryption is an architecture decision, not a feature checkbox

Encrypting ISMS data is more than a technical feature you activate and check off. It is an architecture decision that determines who actually has access to your company's security documentation.

AES-256-GCM at the field level, TLS 1.3 for all connections, and encrypted backups together form a consistent protection layer. But the encryption is only as good as the key management behind it. And in key management, the fundamental difference between SaaS and self-hosted becomes apparent: with SaaS, the provider has the key. With self-hosted, you do. For data that documents where your company is vulnerable, the answer to the question "Who can read this data?" should include exactly one party: you.

Further reading

• Encryption in the Enterprise: What, Where, and How to Encrypt
• Creating a Cryptography Policy: Algorithms, Key Lengths, and Lifecycle
• Self-Hosted vs. Cloud: Data Sovereignty for Compliance Software
• Secrets Management: Securely Managing Passwords, API Keys, and Certificates
• Backup Strategy and Restore Tests: Because Backups Alone Are Not Enough