The Role of Encryption in Data Security Best Practices

The Role of Encryption in Data Security Best Practices

Every 39 seconds, a cyberattack occurs somewhere in the world. In 2025 alone, the average cost of a data breach reached $4.88 million globally — a figure that climbs to $5.17 million for organizations that failed to implement encryption across their data infrastructure. For CTOs, DPOs, and security engineers tasked with protecting personally identifiable information (PII), encryption is no longer a nice-to-have. It is the baseline expectation of every major privacy regulation on the planet.

Yet encryption remains one of the most misunderstood pillars of data security. Too many organizations encrypt data in transit but leave it exposed at rest. Others rely on outdated algorithms that offer a false sense of security. And a surprising number still have no encryption strategy at all for the unstructured data — spreadsheets, PDFs, chat logs — where PII most commonly hides. The gap between "we use encryption" and "we use encryption correctly" is where breaches happen, fines land, and trust evaporates.

This guide breaks down how encryption fits into a modern data security strategy, what regulators actually expect, and how to build an encryption posture that protects PII across every layer of your infrastructure.

Why Encryption Is Central to GDPR and CCPA Compliance


Both the GDPR and CCPA reference encryption as a critical safeguard, but their approaches differ in important ways.

GDPR (Article 32) explicitly names encryption as an "appropriate technical measure" for protecting personal data. More importantly, Article 34 provides a powerful incentive: if encrypted data is breached, you may be exempt from notifying affected individuals — because the data is rendered unintelligible to unauthorized parties. This safe harbor provision alone can save organizations millions in breach response costs and reputational damage.

CCPA (§1798.150) takes a different angle. The law's private right of action — which allows consumers to sue for $100–$750 per incident — only applies to data that was "nonencrypted and nonredacted." In other words, encryption is a direct legal shield against class-action lawsuits under California law.

Consider the real-world consequences: in 2023, the Irish Data Protection Commission fined Meta €1.2 billion for transferring EU user data to the US without adequate encryption safeguards. On the other end of the spectrum, organizations that demonstrated robust encryption during breach investigations have consistently received reduced penalties from regulators in the UK, France, and Germany.

The takeaway is clear: encryption does not just protect data. It protects your organization from the full financial and legal blast radius of a breach.

Encryption at Rest vs. In Transit vs. In Use: Know the Difference


A comprehensive encryption strategy must cover data in three distinct states. Failing to address even one creates an exploitable gap.

Encryption at rest protects stored data — databases, file systems, backups, and archives. This is your defense against stolen hard drives, compromised storage accounts, and insider threats. Use AES-256 for symmetric encryption of stored data. Most cloud providers (AWS, GCP, Azure) offer server-side encryption by default, but you must verify that customer-managed keys (CMKs) are enabled for sensitive PII datasets.

Encryption in transit protects data as it moves between systems — API calls, file transfers, browser sessions. TLS 1.3 is the current standard. Older protocols like TLS 1.0 and 1.1 have known vulnerabilities and are explicitly deprecated by PCI DSS 4.0 and most regulatory frameworks. Enforce TLS 1.2+ at minimum across all endpoints.

Encryption in use is the emerging frontier. Technologies like confidential computing, homomorphic encryption, and secure enclaves allow data to remain encrypted even while being processed. While fully homomorphic encryption remains computationally expensive for production workloads, Intel SGX and AMD SEV enclaves are already practical for sensitive PII processing pipelines.

A quick self-audit checklist:

• [ ] All databases containing PII use AES-256 encryption at rest
• [ ] All API endpoints enforce TLS 1.2 or higher
• [ ] Backup volumes are encrypted with keys separate from production
• [ ] Internal service-to-service communication uses mTLS
• [ ] Key rotation occurs at least every 90 days

Key Management: The Part Most Organizations Get Wrong


Encryption is only as strong as your key management. A perfectly encrypted database is worthless if the decryption key sits in a plaintext config file on the same server — and this scenario is far more common than most security teams want to admit.

Principle 1: Separate keys from data. Never store encryption keys alongside the data they protect. Use a dedicated key management service (KMS) such as AWS KMS, Google Cloud KMS, Azure Key Vault, or HashiCorp Vault.

Principle 2: Implement key rotation. Rotate encryption keys on a defined schedule. NIST SP 800-57 recommends cryptoperiods based on key type, but a practical starting point is rotating data encryption keys every 90 days and master keys annually.

Principle 3: Enforce least-privilege access to keys. Key access policies should be as restrictive as your most sensitive data access policies. Audit key usage logs regularly.

Here is an example of setting up automatic key rotation with AWS KMS using Terraform:

`hcl resource "aws_kms_key" "pii_encryption_key" { description = "KMS key for PII data encryption" enable_key_rotation = true deletion_window_in_days = 30

policy = jsonencode({ Version = "2012-10-17" Statement = [ { Sid = "RestrictKeyAccess" Effect = "Allow" Principal = { AWS = "arn:aws:iam::role/PiiDataProcessor" } Action = [ "kms:Decrypt", "kms:GenerateDataKey" ] Resource = "*" } ] })

tags = { Environment = "production" DataClass = "pii-sensitive" } } `

Principle 4: Plan for key compromise. Have a documented runbook for emergency key rotation. If a key is suspected compromised, you need to re-encrypt all affected data with a new key — and the time it takes to execute that process is directly proportional to how much you have prepared for it.

Field-Level Encryption: Protecting PII Where It Lives


Database-level encryption (transparent data encryption, or TDE) is a solid baseline, but it has a critical limitation: once an application connects to the database, the data is decrypted for every query. If an attacker compromises the application layer — through SQL injection, a vulnerable ORM, or stolen credentials — TDE offers zero protection.

Field-level encryption (FLE) solves this by encrypting individual columns or fields that contain PII. A user's email, national ID number, or phone number can be encrypted with a separate key so that even application-layer compromises do not expose the raw values.

For a PostgreSQL database, you can implement field-level encryption using the pgcrypto extension:

`sql -- Enable the extension CREATE EXTENSION IF NOT EXISTS pgcrypto;

-- Insert encrypted PII INSERT INTO customers (name, email_encrypted, created_at) VALUES ( 'Jane Doe', pgp_sym_encrypt('jane.doe@example.com', current_setting('app.encryption_key')), NOW() );

-- Query encrypted PII (only by authorized roles) SELECT name, pgp_sym_decrypt(email_encrypted::bytea, current_setting('app.encryption_key')) AS email FROM customers WHERE id = 42; `

The tradeoff is that FLE makes searching and indexing encrypted fields difficult. You cannot run a WHERE email = 'x' query on an encrypted column without decrypting every row first. Solutions include maintaining a separate HMAC-based search index or using deterministic encryption for fields that require exact-match lookups (with the understanding that deterministic encryption leaks equality patterns).

This is precisely where PII discovery tools become essential. Before you can encrypt PII at the field level, you need to know exactly which fields contain PII — and in sprawling data architectures with hundreds of tables, that is rarely obvious.

Encrypting Unstructured Data: The Blind Spot in Most Strategies

Most encryption strategies focus on databases. But according to Gartner, over 80% of enterprise data is unstructured — documents, emails, images, logs, spreadsheets, chat exports. This is where PII hides in the most unexpected places: a customer's passport scan in a shared drive, social security numbers in a CSV export someone forgot to delete, medical records embedded in PDF attachments.

Practical steps for encrypting unstructured PII data:

1. Scan first, encrypt second. You cannot encrypt what you have not found. Run automated PII discovery scans across cloud storage buckets (S3, GCS, Azure Blob), shared drives, and file servers. Tools like PrivaSift can detect PII patterns — names, emails, national IDs, financial data — across dozens of file formats without manual review.

2. Classify and tag. Not all unstructured data requires the same encryption treatment. Implement a classification scheme (e.g., Public, Internal, Confidential, Restricted) and apply encryption policies based on classification level.

3. Encrypt at the storage layer. Enable default encryption on all cloud storage buckets. For AWS S3, enforce this with a bucket policy:

`json { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyUnencryptedUploads", "Effect": "Deny", "Principal": "*", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::pii-sensitive-bucket/*", "Condition": { "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" } } } ] } `

4. Lifecycle management. Encrypted or not, PII data that is no longer needed should be securely deleted. Implement retention policies that automatically purge unstructured files beyond their required retention period.

Building an Encryption-First Culture Across Engineering Teams

Technology alone does not solve the encryption problem. The most common encryption failures are human, not algorithmic: a developer hardcoding an API key, a data engineer exporting PII to an unencrypted staging environment, a DevOps engineer disabling TLS for "quick debugging" and forgetting to re-enable it.

Embed encryption in your CI/CD pipeline. Add automated checks that flag unencrypted PII before code reaches production. Static analysis tools can catch hardcoded secrets. Infrastructure-as-code scanners (Checkov, tfsec) can verify that encryption is enabled on every provisioned resource.

Make encryption the default, not the exception. Configure cloud accounts so that new storage resources are encrypted by default. Use service control policies (SCPs) in AWS Organizations or organization policies in GCP to prevent the creation of unencrypted resources entirely.

Run tabletop exercises. Simulate a scenario where encrypted PII data is breached. Walk through the incident response: Can you identify which keys were used? Can you rotate them within your SLA? Can you prove to regulators that the data was, in fact, encrypted at the time of breach? These exercises expose gaps that architecture diagrams cannot.

Track encryption coverage as a metric. Measure the percentage of PII-containing systems that have encryption at rest, in transit, and (where applicable) in use. Report this metric to leadership alongside other security KPIs. What gets measured gets managed.

Post-Quantum Readiness: Preparing Your Encryption for Tomorrow

The emergence of quantum computing poses a real, if not yet immediate, threat to current encryption standards. RSA-2048 and ECC-256, which underpin most public-key infrastructure today, are theoretically breakable by a sufficiently powerful quantum computer using Shor's algorithm. While that capability does not exist today, the "harvest now, decrypt later" threat is real: adversaries are already collecting encrypted data with the intent of decrypting it once quantum capabilities mature.

In August 2024, NIST finalized three post-quantum cryptographic standards: ML-KEM (formerly CRYSTALS-Kyber) for key encapsulation, ML-DSA (formerly CRYSTALS-Dilithium) for digital signatures, and SLH-DSA (formerly SPHINCS+) for hash-based signatures.

What security teams should do now:

• Inventory your cryptographic dependencies. Know which algorithms you use, where, and for what purpose. This crypto-agility assessment is the foundation of any migration plan.
• Prioritize long-lived data. If you store PII that must remain confidential for 10+ years (medical records, financial data, government records), begin transitioning those systems to hybrid encryption schemes that layer post-quantum algorithms on top of classical ones.
• Monitor your TLS libraries. OpenSSL 3.x and BoringSSL already have experimental support for post-quantum key exchange. Stay current with updates.

FAQ

Is encryption alone enough to be GDPR compliant?

No. Encryption is one of several technical measures required under GDPR Article 32. Compliance also requires access controls, regular security testing, data minimization, breach notification procedures, and demonstrated accountability (documentation of your processing activities and risk assessments). However, encryption is one of the most impactful single measures you can implement because of the safe harbor it provides under Article 34 regarding breach notifications.

What encryption algorithm should we use for PII data at rest?

AES-256 in GCM mode (AES-256-GCM) is the current gold standard for symmetric encryption of data at rest. It provides both confidentiality and integrity (authenticated encryption). Avoid ECB mode, which leaks patterns in plaintext. For asymmetric encryption scenarios (key exchange, digital signatures), use RSA-4096 or ECC with P-384 curves at minimum, and begin evaluating post-quantum alternatives for new deployments.

How does encryption interact with the CCPA's private right of action?

The CCPA's private right of action under §1798.150 only applies to breaches involving personal information that was "nonencrypted and nonredacted." If your data is properly encrypted at the time of a breach, consumers cannot bring private lawsuits under this provision. This does not eliminate all CCPA liability — the California Attorney General can still pursue enforcement actions — but it removes the most financially dangerous exposure vector: class-action lawsuits seeking statutory damages of $100–$750 per consumer per incident.

We already use TDE on our databases. Do we still need field-level encryption?

It depends on your threat model. TDE protects against physical theft of storage media and unauthorized access to raw database files. However, TDE does not protect data from threats at the application layer — SQL injection, compromised application credentials, or malicious insiders with database query access. If your PII data faces these risks (and most organizations' data does), field-level encryption adds a critical additional layer of defense. At minimum, consider FLE for high-sensitivity fields: government IDs, financial account numbers, health records, and biometric data.

How do we know which fields and files actually contain PII before we encrypt them?

This is the foundational challenge. Manual audits are slow, error-prone, and quickly outdated as data architectures evolve. Automated PII discovery tools solve this by scanning structured databases, unstructured files, and cloud storage to identify and classify PII automatically. This gives you a continuously updated inventory of where PII lives, which directly informs your encryption priorities and ensures no sensitive data falls through the cracks.

Start Scanning for PII Today

PrivaSift automatically detects PII across your files, databases, and cloud storage — helping you stay GDPR and CCPA compliant without the manual work.

[Try PrivaSift Free →](https://privasift.com)