What is data encryption? How it works, and where it fails in document workflows

Data encryption converts readable data, called plaintext, into unreadable ciphertext using an algorithm and a secret key, so only someone with the right key can turn it back. It protects files while they're stored (at rest) and while they move across networks (in transit), so a stolen disk or an intercepted upload of tax returns reveals nothing useful.

This guide covers how encryption algorithms work, symmetric vs asymmetric encryption, at rest vs in transit, the rules that expect encryption, key management, and where encryption leaves gaps in document workflows.

What is data encryption?#

NIST defines encryption as the cryptographic transformation of data into ciphertext, which hides its meaning; the reverse is decryption. Think of a lockbox: the algorithm is the lock's design and the key is what opens it. A strong lock with the key left under the doormat protects nothing.

How encryption algorithms work#

An encryption algorithm takes plaintext and a key and outputs ciphertext that looks like random noise. Its strength comes from the complexity of its operations and the length of its key. AES, the Advanced Encryption Standard, runs data through repeated rounds of substitution and permutation: 10 rounds with a 128-bit key, 12 with a 192-bit key and 14 with a 256-bit key.

Key length matters because every extra bit doubles the number of possible keys. A 256-bit key has 2^256 possibilities, far more than any brute-force attack could try with today's computers.

Symmetric vs asymmetric encryption#

Most systems use both. Symmetric encryption uses one shared key to encrypt and decrypt: it's fast, so it handles bulk data, but both sides need the same secret. Asymmetric encryption uses a key pair: a public key anyone can use to encrypt, and a private key only the owner holds to decrypt.

A TLS connection combines them: public-key cryptography sets up a shared session key, then symmetric encryption carries the data.

Encryption at rest vs in transit#

Where data sits decides which control applies, and there's a third state that standard encryption doesn't cover.

• At rest

  Stored data: files on disk, database records, backups. Full-disk encryption covers whole volumes; file- or field-level encryption protects specific values.

• In transit

  Data moving between systems. TLS is the standard for web traffic and APIs, and stops eavesdropping and tampering on the way.

• In use

  Data on a review screen or in an API response is decrypted so people and systems can work with it. Access controls and audit logs protect this window.

Why businesses encrypt sensitive data#

Encryption keeps data confidential even after a breach, and several rules expect it for the data in business documents:

• HIPAAEncrypting electronic health information is an "addressable" safeguard: implement it, or document why not and use an equivalent measure (45 CFR 164.306 and 164.312). Data encrypted to HHS guidance, with the key kept safe, isn't "unsecured," so losing it doesn't trigger breach notification.
• PCI DSSCard numbers must be unreadable wherever they're stored, and sent over open, public networks only with strong cryptography (requirements 3.5.1 and 4.2.1, PCI SSC).
• FTC Safeguards RuleNon-bank financial institutions, such as mortgage lenders, must encrypt customer information at rest and in transit over external networks, or use approved compensating controls (16 CFR 314.4).
• GDPREncryption is named as a security measure (Article 32), and if breached data was encrypted, you may not have to tell the people affected (Article 34) (GDPR text).

In January 2025 HHS proposed making encryption of electronic health information required rather than addressable; as of September 2026 the rule isn't final. More on health data in what HIPAA compliance means for document teams.

Common encryption standards and protocols#

A handful of standards cover most business systems:

Two changes are worth watching. TLS 1.3 dropped legacy algorithms and made forward secrecy standard, so a vendor that still accepts TLS 1.0 or 1.1 deserves questions. And in August 2024 NIST published its first post-quantum encryption standards (FIPS 203, 204 and 205), built to resist future quantum computers, and urged organizations to start adopting them.

Key management fundamentals#

Encryption is only as strong as key management, and this is where implementations fail in practice.

Envelope encryption is the usual design. A data encryption key (DEK) encrypts the data; a key encryption key (KEK) encrypts the DEK and stays in a key management service (KMS) or hardware security module (HSM) with tight access controls. An attacker who breaches storage but not the key service finds only wrapped keys they can't use. HHS makes the same point: keep keys apart from the data they protect.

Key rotation replaces keys on a schedule to limit the damage a compromised key can do. There's no universal interval: NIST suggests a cryptoperiod for each key type, such as up to 2 years for a symmetric key encrypting new data, and PCI DSS requires keys to be changed at the end of the cryptoperiod you define.

When you evaluate vendors, ask about key custody: who can use the decryption keys, what logs record key use, and whether you can bring your own keys (BYOK).

Where encryption fails in document workflows#

Encryption doesn't protect data at every moment. These are the usual gaps:

• Temporary files and caches

  A document encrypted in storage may be decrypted into a temp folder for OCR. If that folder isn't secured and wiped, the plaintext stays there.

• Previews and thumbnails

  A system may render an unencrypted thumbnail of an encrypted file, and the thumbnail is readable.

• Exports and integrations

  Once data syncs to another system or downloads as a spreadsheet, that system's controls decide what protects it.

• Logs and debug output

  A debug log can capture API payloads, customer data included, in plain text.

That's why encryption works alongside access controls, audit trails, data minimization and retention rules, not instead of them.

How to evaluate vendor encryption claims#

Vendors often promise "bank-grade" or "military-grade" encryption. Ask what's behind it:

Also ask about scope: backups, logs, temporary files and derived data such as thumbnails and extracted fields. For how to read the report itself, see what SOC 2 compliance tells you about a vendor.

Docsumo, an intelligent document processing platform, encrypts data in transit with TLS and at rest with AES-256, offers role-based access, single sign-on and multi-factor authentication, is SOC 2 Type 2 audited and ISO/IEC 27001:2022 certified, supports HIPAA and GDPR compliance with a BAA and DPA available, and doesn't use customer data to train shared or third-party models. More is on its security page.

The bottom line#

Encryption makes stolen or intercepted data useless without the key, which is why rules from HIPAA to PCI DSS expect it. It doesn't protect data while it's in use, and it's only as good as the key management behind it, so pair it with access controls and audit logs, and ask vendors specific questions instead of accepting "bank-grade."

Book a demo to go through Docsumo's security with your team, or start a free trial.

Frequently asked questions#