Scrambling data so it is unreadable to anyone without the key, both while it travels and while it sits stored.
Why it exists
Data in transit can be read by anyone on the network path, and data at rest can be read by anyone who gets hold of the disk or a backup. Sending or storing it in the clear means one interception or one stolen drive exposes everything. Encryption exists to scramble data so only someone with the key can read it, both in transit and at rest.
How it actually works
"In transit" encryption (HTTPS) protects data moving between user and server. "At rest" encryption protects data sitting in the database and backups, so a stolen disk or dump is useless without the key.
Together they mean that intercepting the network or stealing the storage both yield noise, not customer data. Sensitive fields like payment details get the strongest treatment.
A senior PM walks you through it
A junior PM, stuck
A partner sent a security questionnaire and one line asks "is customer data encrypted at rest?" I have to answer yes or no in writing, and I do not actually know what our database looks like on disk or what "at rest" even points at. I do not want to type yes and be wrong in a signed document.
"At rest" means the data sitting stored on disk and in backups, as opposed to "in transit," which is the same data moving over the network. Your questionnaire line is only asking about the stored half; the in-transit half is the HTTPS answer and belongs on a separate line. Below is the payments table two ways, as an engineer with the key reads it and as the raw backup file actually sits on disk, so you can answer the at-rest question from what you can see.
The payments data at rest: through the database, and on the raw disk
payments table, from a SQL client that holds the key
1 order | customer | phone | amount | card
2 o_5512 | u_88231 | 01712345678 | 649 | tok_88f2
the card column, next to what a real card looks like
3 card stored: tok_88f2 (a reference the gateway can charge)
8(no key present: the bytes decode to nothing readable)
Click a step to see the lines it points at.
Mistakes I've seen
Answering "yes, it's encrypted" without saying at rest or in transit. They are two different protections with two different mechanisms; a partner asking one line usually wants both answered separately and clearly.
Thinking encryption at rest hides data from your own app. The running database has the key and returns plain text to authorized queries; at-rest encryption protects a stolen disk or backup, not a compromised login. That is access control's job.
Assuming an encrypted card number is safe to store. Storing the raw card at all is the risk; tokenizing it so the number never lands in your database is the stronger answer and what the meeting line actually claims.
Confusing encryption with hashing. Encryption is reversible with the key so you can read the data back; a password hash is deliberately one-way. Answering a card question with the password approach, or the reverse, is wrong.
Collecting sensitive fields because they will be encrypted anyway. Encryption lowers the risk of data you must hold; it does not justify holding data you do not need. The safest personal field is the one you never stored.
Answer the questionnaire: "Yes, customer data is encrypted at rest, including database and backups, and card numbers are tokenized so the raw number is never stored. In transit is covered separately over HTTPS." You read stored data as plain text with the key and as ciphertext without it, which is the skill.
Where a PM meets this
"Is the data encrypted?" from a security review or partner should have a clear yes for both in transit and at rest.
Encryption doesn't excuse collecting data you don't need; the safest data is the data you never stored (see PII).
Hear it in a meeting
"Card data's encrypted at rest, and we tokenize it so we never store the raw number."