Data Protection

Data Protection

Overview

Data protection spans both compliance requirements and technical controls. Organizations must protect data not only to meet regulatory obligations but also to maintain customer trust and limit business risk. Privacy by design — the principle of embedding privacy considerations into every stage of system development — is mandatory under GDPR and is increasingly becoming the expectation under other frameworks. Effective data protection requires understanding what data you have, where it lives, how it flows, who can access it, and how long it must be retained.

Data Classification

Data classification assigns sensitivity levels to information assets, enabling organizations to apply proportionate security controls. Every piece of data should be classified, and the classification should drive technical and procedural safeguards.

Encryption Requirements

At Rest

Data at rest — stored in databases, file systems, object storage, or backups — must be encrypted to protect against unauthorized access in the event of physical theft, unauthorized backup access, or misconfigured storage permissions.

In Transit

Data in transit — moving between clients and servers, between services, or between data centers — must be protected from eavesdropping and tampering.

Privacy Regulations

The following table compares the major privacy regulations that most organizations must consider. This is a summary — consult legal counsel for jurisdiction-specific compliance requirements.

PII Handling

Personally Identifiable Information (PII) requires specific technical and procedural controls throughout its lifecycle.

Data Minimization

Collect only the personal data that is strictly necessary for the stated purpose. Review data collection forms, API request schemas, and database schemas to identify and eliminate unnecessary fields. Ask: "Do we need this data to provide the service?" If not, do not collect it.

Purpose Limitation

Use personal data only for the purpose for which it was collected. If a new use case arises, assess whether it is compatible with the original purpose or whether new consent is required. Document the purpose for each data element in a data inventory.

Tokenization and Pseudonymization

• Tokenization: Replace sensitive data with non-sensitive tokens that map back to the original data via a secure token vault. Tokens have no mathematical relationship to the original data.
• Pseudonymization: Replace identifying fields with pseudonyms; the data can be re-identified with a separate key. GDPR recognizes pseudonymization as a risk-reduction measure but still treats pseudonymized data as personal data.

Right to Erasure (Right to be Forgotten)

Implement a process to delete or anonymize all personal data associated with a data subject upon verified request. This must cover primary databases, backups, caches, logs, analytics systems, and third-party processors. Key considerations:

• Define what "erasure" means for each data store (hard delete vs. cryptographic erasure vs. anonymization).
• Propagate deletion requests to all downstream systems and third-party processors.
• Maintain a record of the deletion request and its execution (without retaining the deleted data itself).
• Handle exceptions for legal holds and regulatory retention requirements.

Data Subject Access Requests (DSAR)

Build automated or semi-automated workflows to respond to DSARs within regulatory timelines (30 days under GDPR). The system must be able to locate, extract, and export all personal data associated with a given identity across all data stores.

Data Masking and Tokenization

Key decisions:

• Use tokenization when you need to reverse the process for legitimate business operations.
• Use static masking for non-production environments — never use real PII in development or testing.
• Use dynamic masking for production access control scenarios where different users need different levels of data visibility.

Data Retention

Data retention policies define how long data is kept and what happens when the retention period expires. Retaining data longer than necessary increases risk, storage costs, and regulatory exposure.

Define Retention Policies

• Establish retention periods based on regulatory requirements, business needs, and contractual obligations.
• Document retention policies in a data retention schedule that covers every data category.
• Ensure retention periods are specific (e.g., "3 years after account closure") rather than vague (e.g., "as long as needed").

Automated Deletion

• Implement automated processes to delete or anonymize data when the retention period expires.
• Use database-level TTL (Time-to-Live) features, scheduled jobs, or lifecycle policies (e.g., S3 lifecycle rules) to enforce retention.
• Verify automated deletion is working through regular audits.

Legal Hold

• Implement a legal hold process that can suspend automated deletion for data relevant to litigation, regulatory investigations, or audits.
• Legal holds must be granular — hold only the specific data relevant to the matter, not all data for a given user or category.
• Track all active legal holds and release them promptly when they are no longer needed.

Backup Considerations

• Retention policies must account for backup cycles. Data deleted from primary storage may still exist in backups.
• Define how long backups are retained and how deletion requests are handled for data in backups (e.g., delete upon next backup rotation vs. cryptographic erasure of the backup encryption key).
• Regularly test the ability to restore from backups and verify that retained data is still usable.

Best Practices

• Maintain a comprehensive data inventory — you cannot protect data you do not know about; catalog all personal and sensitive data, where it is stored, how it flows, and who has access.
• Apply privacy by design from the start — embed data protection into architecture decisions, not as a retrofit; conduct Data Protection Impact Assessments (DPIAs) for new systems that process personal data.
• Encrypt by default — enable encryption at rest and in transit for all data stores and communication channels; treat encryption as baseline, not an add-on for sensitive data only.
• Implement least-privilege access to sensitive data — restrict access to personal and confidential data based on role and business need; review access permissions regularly and revoke unnecessary grants.
• Automate compliance processes — manual compliance processes do not scale; automate DSAR fulfillment, retention enforcement, consent management, and breach detection to reduce human error and response times.
• Test your data deletion capabilities — regularly verify that erasure requests result in actual deletion across all systems, including backups, caches, logs, and third-party processors.
• Monitor for data exfiltration — deploy Data Loss Prevention (DLP) tools to detect unauthorized data transfers via email, cloud storage, USB, and API calls; alert on anomalous data access patterns.
• Train all employees on data handling — security and privacy training should cover data classification, acceptable use, incident reporting, and regulatory obligations; tailor training to roles (developers, support, executives).