Encryption
Encryption uses a secret key to turn readable data into unintelligible ciphertext that only authorised recipients can decrypt again. In an ERP context, it protects sensitive customer, payment and document data during transmission and storage from unauthorised access.
Encryption is a method that uses a secret key to turn readable information (plaintext) into an unintelligible form (ciphertext), so that only whoever holds the matching key can return the data to its original state. If the ciphertext falls into the wrong hands – for example through an intercepted data stream or a stolen storage medium – it remains worthless without the key. Encryption thus answers the question "How do I make sure only authorised people can read my data?" and is a cornerstone of information security.
In an ERP environment encryption carries particular weight, because the system consolidates highly sensitive data: customer and supplier master records, bank details, payment information, calculations, contracts and tax-relevant documents. This data is constantly in motion – between browser and server, between ERP and online shop, between application and database – and is at the same time stored permanently. Encryption protects it in both states and is therefore a technical prerequisite for being able to meet data protection and compliance obligations at all.
At a glance
- Encryption = turning plaintext into ciphertext with a secret key
- Protects data "in transit" (transmission) and "at rest" (storage)
- Symmetric (one key) vs. asymmetric (key pair)
- Security rests on the key, not on keeping the method secret
- In the ERP a mandatory building block for GDPR, PCI DSS and ISO 27001
How encryption works: key, algorithm and ciphertext
Encryption always consists of three components: the plaintext (the source data), an algorithm (the mathematical rule) and a key (a secret string of characters). The algorithm combines plaintext and key into a ciphertext that cannot be reversed without the matching key. What is decisive is the so-called Kerckhoffs principle: security may depend solely on keeping the key secret, not on keeping the method secret. Established algorithms such as AES or RSA are therefore publicly known and have been examined millions of times – their strength lies in the key length and the mathematical complexity.
Encryption is distinguished from related but different techniques. With hashing, a fixed check value is computed from data that deliberately cannot be reversed – suitable for passwords or integrity checks, not for data that needs to become readable again. With tokenisation, a sensitive value is replaced by a placeholder whose mapping is stored separately. Encryption, by contrast, is reversible: with the right key, the ciphertext becomes exactly the original plaintext again.
Symmetric and asymmetric methods
With symmetric encryption, sender and recipient use the same key to encrypt and decrypt. This is very fast and suits large volumes of data (e.g. AES for an entire database), but requires both sides to exchange the key securely. With asymmetric encryption, a key pair exists: a public key for encrypting, which anyone may know, and a private key for decrypting, which stays secret. This solves the exchange problem but is more computationally intensive. In practice both are combined (hybrid encryption): the slow asymmetric part only secures the exchange of a symmetric session key, which then encrypts the actual data quickly – this is exactly how TLS works behind the scenes.
Encryption "in transit" and "at rest"
In practice a distinction is made between two protection states. Encryption "in transit" (during transmission) protects data on its way through networks – implemented above all via TLS, recognisable by the "https" and the padlock symbol in the browser. Without it, an attacker could read or manipulate the traffic between user and ERP or between two systems. Every reputable API connection, every interface to the shop system and every login runs over TLS today.
Encryption "at rest" (in the idle state) protects stored data – on hard drives, in databases, in backups. If a server, a disk or a backup tape is stolen, the data stays unreadable without the key. This is implemented via disk or database encryption, in part down to field or column level for particularly sensitive details such as bank data. Only both states together provide end-to-end protection: a perfectly encrypted transmission is of little use if the data then sits in plaintext on an unprotected server.
End-to-end encryption
A special case is end-to-end encryption: here data is already encrypted at the sender and only decrypted again at the final recipient – no system in between, not even the transmitting service provider, can view it in plaintext. For ERP operators this is relevant wherever data travels across several intermediate stations and even the platform operator should have no access.
Why encryption matters in an ERP system
An ERP system is a company's central data hub and therefore a worthwhile target for attacks. Encryption reduces the risk across several layers: it protects communication between users and server, secures interfaces and API calls to shops, marketplaces and payment service providers, and preserves stored records even when another safeguard fails. It thus interlocks with authorisation concepts, two-factor authentication and a well-thought-out backup – encryption replaces none of these measures but complements them.
How much a company has to handle itself depends on the operating model. With a cloud ERP in the SaaS model, the provider takes care of encryption "in transit" and "at rest" in the data centre; the details are set out in the security and data processing agreements and are often evidenced through certifications such as ISO 27001. With on-premise operation or self-hosting the responsibility lies with the company – including the configuration of TLS, database encryption and above all key management, i.e. the secure generation, storage, rotation and destruction of keys. A lost key makes data irretrievably unreadable, a compromised key nullifies the entire protection.
Encryption and compliance in the DACH region
In the DACH region encryption is not only good practice but legally underpinned. The GDPR expressly names encryption in Article 32 as an appropriate technical measure to protect personal data. A positive side effect: if data is effectively encrypted during a breach and the key is not compromised, the obligation to notify affected individuals may lapse, because no high risk arises. For companies, encryption is therefore also an instrument for limiting liability.
Anyone processing card payments is additionally subject to the PCI DSS standard, which mandates the encryption of card and transmission data. The BSI IT-Grundschutz and ISO 27001 anchor encryption as a fixed building block of information security management. Important in practice: encrypted data must remain compatible with the statutory retention obligations and the GoBD – stored documents may be held in encrypted form, but must remain legibly recoverable throughout the entire retention period. A well-thought-out, documented key management is therefore part of a sound procedural documentation.
Example
Example: Stolen laptop with ERP access
At a mid-sized wholesaler, the laptop of a field sales employee is stolen from a car. On the device are a local ERP client, cached customer lists with revenues and an export file with bank details. Because the hard drive is fully encrypted and access was additionally secured by two-factor authentication, the data is unreadable to the thief – without the key and the second factor the device remains an empty shell.
IT remotely locks the access and rotates the affected keys and passwords. Because it can be demonstrated that no plaintext leaked, the incident must be documented, but the affected customers do not have to be notified individually. Without disk encryption the same theft would have triggered a reportable data breach with considerable reputational and liability risk.
Frequently asked questions
Related services
Questions about Encryption in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.