Encryption is the process of scrambling readable data into an unreadable form so that only someone with the correct key can turn it back. In cybersecurity, it is the control that protects the confidentiality of information both when it sits on a disk and when it travels across a network. If an attacker steals an encrypted database without the key, what they hold is noise. That is the whole point: encryption does not stop data from being copied, but it makes the copy useless to whoever took it.

For a small or mid-sized business, this matters in two directions at once. It is a defensive measure that reduces the damage of a breach, and it is increasingly a legal expectation baked into privacy and cybersecurity law. This guide explains what encryption does, where it fits, its limits, and how it connects to obligations such as the GDPR.

What encryption actually does

At its core, encryption takes plaintext (the readable data) and a key, runs both through an algorithm, and produces ciphertext. Decryption reverses the process using a key. The security rests almost entirely on the key, not on secrecy of the algorithm. Modern, well-reviewed algorithms are public and studied by cryptographers worldwide precisely so that weaknesses surface. A system that relies on a secret, home-grown algorithm is a warning sign, not a strength.

There are two broad families.

Symmetric encryption uses the same key to encrypt and decrypt. It is fast and suited to large volumes of data, which is why it protects the contents of hard drives, backups and file stores. The Advanced Encryption Standard (AES) is the workhorse here, standardised by the US National Institute of Standards and Technology (NIST) and used almost everywhere. The practical challenge is distributing the shared key safely without an attacker intercepting it.

Asymmetric encryption (also called public-key cryptography) uses a mathematically linked key pair: a public key that anyone can hold and a private key kept secret. Data encrypted with the public key can only be opened with the matching private key. This solves the key-distribution problem and underpins the secure connections your browser makes, digital signatures, and much of how identities are verified online. It is slower, so in practice systems often use asymmetric encryption to exchange a symmetric key, then switch to the faster symmetric method for the bulk of the traffic.

Data at rest, in transit and in use

Defenders usually think about encryption in three states:

  • Data at rest is stored data – databases, laptops, phones, backups, files in cloud storage. Full-disk encryption and database or field-level encryption cover this state.
  • Data in transit is data moving across a network. This is protected by protocols such as TLS, the technology behind the padlock and HTTPS in your browser, and by VPNs.
  • Data in use is data actively being processed in memory. This is the hardest to protect and an active area of research (confidential computing, homomorphic encryption), still maturing and not yet routine for most organisations.

Most breaches that make encryption worthwhile involve the first two states. Protecting data at rest limits the fallout of a stolen laptop or a copied backup; protecting data in transit stops eavesdropping on public or shared networks.

Where encryption fits in a real security programme

Encryption is a strong control, but it is one layer, not a strategy on its own. It protects confidentiality. It does very little against an attacker who logs in with valid stolen credentials, because to that attacker the system decrypts the data as designed. It does not stop phishing, ransomware from encrypting your files against you, or a malicious insider with legitimate access.

That is why encryption sits alongside access control, monitoring and identity management rather than replacing them. Deciding who can reach decrypted data is a separate discipline – see our guide to access control lists in cybersecurity for how permissions are enforced at a granular level. And because well-resourced attackers such as advanced persistent threats aim to steal the keys or the credentials rather than break the maths, key management often matters more than the choice of algorithm.

Key management is the hard part

The uncomfortable truth is that the algorithm is rarely the weak point. Key management is. If keys are stored next to the data they protect, written into source code, shared over chat, or never rotated, the encryption is theatre. Serious deployments keep keys separate, control who can use them, log every use, and can revoke and rotate them.

For businesses moving to the cloud, providers offer key management services that handle much of this, with the option to bring your own keys for tighter control. The trade-off is real: more control means more operational responsibility. There is no free lunch. Encryption adds friction – performance overhead, the risk of locking yourself out if you lose a key, and the burden of rotating keys without breaking systems. A good deployment is one where that friction is planned for rather than discovered during an incident.

Encryption and the law: privacy and cybersecurity obligations

Encryption has moved from a technical nicety to a legal expectation. Privacy and cybersecurity law across many jurisdictions now treats it as one of the reasonable measures organisations are expected to take when handling personal data.

The clearest example is Europe's General Data Protection Regulation. The GDPR names encryption explicitly in Article 32 as an example of an appropriate technical measure to secure personal data. It is not mandated in every case, but it is cited as the kind of safeguard regulators expect you to have considered. There is a second, very practical incentive in Article 34: if personal data is breached but was rendered unintelligible to unauthorised parties – for instance, because it was properly encrypted and the keys were not compromised – the obligation to notify affected individuals may be reduced. Encryption can therefore change how a breach plays out both technically and legally.

Similar expectations appear elsewhere. Sector rules for health and payment data, US state privacy laws, and frameworks such as the NIST Cybersecurity Framework all point toward protecting data confidentiality as a baseline. The European Union Agency for Cybersecurity (ENISA) publishes guidance on cryptographic measures for organisations that want a technical reference.

A caution worth stating plainly: this is general education, not legal advice. Whether encryption is required for your specific data, and what standard is expected, depends on your jurisdiction, sector and the nature of the data. Confirm your obligations with a qualified adviser and the primary regulatory text, not a glossary entry.

Common weaknesses and what breaks encryption in practice

Encryption fails far more often through implementation than through cryptanalysis. The recurring problems are familiar to anyone who reviews systems.

Weak or default keys and passwords let attackers guess their way in. Outdated protocols – old versions of TLS, deprecated cipher suites, or algorithms long known to be broken such as MD5 for integrity or DES for encryption – leave gaps that automated scanners find quickly. Poor key storage, as noted, undoes everything. And expired or misconfigured certificates can either break services or, worse, train users to click past security warnings.

There is also a longer-horizon concern: quantum computing. A sufficiently capable quantum computer could, in theory, break some of the asymmetric algorithms in wide use today. That machine does not exist yet at the required scale, and predictions about timing vary. What matters now is that NIST has published the first post-quantum cryptography standards, and organisations handling data that must stay confidential for a decade or more are beginning to plan migration. For most small businesses this is a watch-and-prepare item, not an emergency. The immediate risk is the "harvest now, decrypt later" idea, where an attacker stores encrypted data today hoping to decrypt it once the technology matures – relevant only for data with a very long sensitivity life.

How to approach encryption without overcomplicating it

For most organisations, sensible encryption is achievable without a cryptography specialist. Turn on full-disk encryption on every laptop and phone – the built-in tools in current operating systems are strong and largely invisible once configured. Insist on HTTPS everywhere for your websites and services, using current TLS. Encrypt your backups, because an unencrypted backup is often the easiest thing for an attacker to walk away with. Use reputable, well-reviewed tools rather than anything bespoke, and keep them updated.

The judgement call is not usually which algorithm, since sane defaults now use strong ones, but where your sensitive data actually lives and who can decrypt it. Map that first. Encryption applied to data you have not located protects nothing. This connects directly to broader planning covered in our cybersecurity checklist and to the question of what all of this costs, which we examine in the guide to cybersecurity cost.

Frequently asked questions

Is encryption the same as hashing?

No. Encryption is reversible with the correct key – the point is to get the original data back. Hashing is a one-way function that produces a fixed-length fingerprint you cannot reverse. Hashing is used to store passwords and verify integrity, not to keep data confidential for later retrieval.

Does encryption protect me from ransomware?

Only partly, and not in the way people hope. Your own encryption protects confidentiality if data is stolen. Ransomware works by encrypting your files against you, using its own keys. Reliable, tested and separately stored backups are the real defence against ransomware, not the encryption you apply to your own data.

Can encrypted data be decrypted by an attacker?

If the encryption is modern, correctly implemented, and the keys are protected, breaking it by brute force is not practical with current technology. In real incidents, attackers almost always steal the key or the credentials, or exploit a misconfiguration, rather than break the algorithm itself.

Is end-to-end encryption different?

Yes. End-to-end encryption means only the sender and recipient hold the keys; not even the service carrying the message can read it. This gives strong privacy but also means the provider cannot recover your data if you lose your keys, and cannot scan the content, which raises its own policy debates.

Does the GDPR require encryption?

The GDPR names encryption as an example of an appropriate safeguard rather than an absolute requirement in every case. It is strongly expected for sensitive personal data, and properly encrypted data can reduce breach-notification burdens. Confirm your specific obligations with a qualified adviser and the regulatory text.

What is the difference between symmetric and asymmetric encryption?

Symmetric encryption uses one shared key and is fast, ideal for bulk data at rest. Asymmetric encryption uses a public and private key pair, solves the problem of sharing keys securely, and underpins secure web connections and digital signatures. Most systems combine both.

Should small businesses worry about quantum computing?

Not urgently. A quantum computer capable of breaking today's public-key encryption does not yet exist at the required scale. Plan for migration to post-quantum standards only if you hold data that must stay confidential for many years; otherwise, treat it as something to monitor.

Where should encryption keys be stored?

Away from the data they protect, with access logged and controlled, and never hard-coded into applications or shared over insecure channels. Cloud key management services and dedicated hardware handle this well; the essential rule is separation of keys from the data they unlock.

Deciding your next step

If you take one action from this guide, make it an inventory: find where your sensitive data lives, then confirm each location is encrypted at rest and in transit. That single exercise usually reveals more risk than any algorithm debate. Once you know what you hold and who can decrypt it, key management and legal obligations become concrete questions you can answer rather than abstractions.

Try the Encryption Explainer and Strength Calculator on this page to see how key length and algorithm choice change the practical difficulty of an attack, and treat the result as a starting point for a conversation with a qualified adviser about your own environment. This article is general education, not a substitute for an audit tailored to your data and jurisdiction.

Read this guide in Español.

Educational content. Not a substitute for a qualified security audit or incident response advice for your specific environment.