Encryption

For years, data that had made it inside the server was treated as safe. Guarding the login screen was assumed to guard everything behind it, so names, phone numbers, and the documents customers wrote all sat in the database in plain readable text.

Every breach broke that assumption. One administrator account gets taken over, or a backup file lands in the wrong storage bucket, and the single file the attacker walks away with holds 120,000 customer records laid out as a readable table. The notice that goes out the next day carries the same two sentences every time: the way in has been closed, and there is no way to take back what already left. Data crossing the network was no better off. Logging in over café Wi-Fi meant anyone else on that network could watch the username and password go past.

Encryption assumes the gate gets opened at least once and prepares for that moment in advance, so that whatever leaves is an unreadable block. Authentication, which confirms who is connecting, and authorization, which decides whether that person may do what they just asked for, both work at the door. This method works on the far side of it.

Pick what needs protecting, choose a method for data in transit and data at rest separately, and keep the keys somewhere other than the data.

1. Pick the targets — not everything gets encrypted. An encrypted value can't be searched or sorted, so the cost lands on product features. Start with personally identifiable information (PII), meaning names, phone numbers, national ID numbers, anything that pins down one person, and with the body text of documents customers write. Signup dates and view counts can leak without hurting anyone, so leave them readable.
2. Split by state — treat data moving across the network and data sitting in storage as two separate problems. For data in transit, add TLS. That's the padlock in the address bar, and with it in place nobody else on the same network can read what goes by. Data at rest splits again. Encrypting the whole disk only helps when someone physically carries the server away, because anyone who gains query access still sees plain text. Answering an actual leak means encrypting individual fields.
3. Choose the scheme — using one key to both lock and unlock is fast. Splitting the key in two, publishing one half and hiding the other, is slow but makes it safe to hand a key to someone. Real services combine them: the slow scheme carries the key, the fast scheme handles the content.
4. Store the keys elsewhere — keys don't live next to the data they open. Written into a code repository or a config file, they travel alongside the data the moment anyone gets access to either one. That is what secret management is for: holding keys and passwords apart and injecting them only at runtime.
5. Plan rotation and recovery — rotate keys on a schedule, and decide in advance how data locked with an old key still gets read after the switch. Losing a key loses the data with it. The outcome matches deleting it, which is why key backups get the same care as data backups.

It fits data whose original content has to be readable again later: document bodies, contact details, signed contract files. Being reversible is the feature here rather than a weakness.

It doesn't fit data whose original value nobody ever needs back. Passwords are the standard example, and hashing, which mangles a value so it can't be turned back, is the right tool for them. For data heading to an analytics team or outside the company, anonymization, which reworks records so individuals can't be picked out, fits better. Encryption means handing over the key as well, and nothing controls what happens after that.

Plenty of encryption gets added because of contracts. The security questionnaires enterprise customers send before signing, including the ones behind SOC 2, almost always ask whether stored data is encrypted.

There are three limits. First, it is plain text to whoever holds the key. A service has to hold the key to display anything, so a fully compromised server hands over the key too. Second, it doesn't replace permission checks. A logged-in user changing a number in the URL to open someone else's document is the service decrypting on request exactly as designed, and encryption has no opinion about it. Third, it costs something to operate. Encrypt a field and you either give up searching on that field or build a separate path for it, and that path is a feature someone has to design and keep working.

"That column is encrypted at rest, so we can't search by name on it."

Not a refusal of the feature, but a request to design the search path on purpose if the feature is needed.

"If the key is sitting in the same repository, we may as well not have encrypted it."

What decides real safety is where the key lives, not that a lock exists.

"The customer's questionnaire has a line about encryption at rest, so it goes into this sprint."

The schedule came from a contract rather than from an engineering judgment.

At Pagedeck this came up the first time the company was close to signing an enterprise customer. The security questionnaire Sofia brought back from sales asked whether customer data was encrypted at rest, and Theo encrypted the document body field. What broke afterward wasn't performance but search: the feature that found documents by title also scanned their bodies, and with the bodies unreadable the results came back empty. The team settled on a separate search index and left the bodies locked.

The most common belief is that encrypted data is safe data. Locked sounds like safe, which makes the jump easy to take. What actually decides safety is where the key sits. A key written into a config file on the same server leaves with whoever takes the data. A breach in that state gets announced as encrypted data being exposed, while the practical result is no different from plain text walking out the door.

The other frequent mistake is reading the padlock in the address bar as proof that stored data is covered too. One word covers both, so protecting data feels like a one-time job. In transit and at rest are separate states and each needs its own treatment. With only the first in place, a leaked backup file holds content that was never locked at all.