Identify fields in my database that hold sensitive data beyond passwords: things like phone numbers, addresses, dates of birth, government IDs, health details, private messages, or API tokens stored for third-party integrations. Tell me first what my app actually stores before proposing anything. For data the app must read back (addresses, tokens), add application-level encryption with a well-established library for my stack (AES-256-GCM is the standard), with keys loaded from environment variables or a key management service, never from code. For data only ever compared (nothing here except passwords, which should already be hashed), hashing stays the right tool. Plan key rotation from the start: store a key version alongside encrypted values so old data can be re-encrypted later. Confirm that encrypted fields are never written to logs or returned to clients that don't need them. Do not encrypt fields that don't need it; encryption adds complexity and breaks search and indexing on those columns, so apply it only where the sensitivity justifies it, and explain each choice. Do not write a custom cipher. Deliver: an inventory of sensitive fields with a protect-or-leave decision for each, the encryption implementation, and verification that stored values are ciphertext while the app reads them transparently.