Privacy Engineering Principles
Purpose Limitation Purpose limitation requires declaring specific purposes for data collection and processing, with enforcement through access policies and audit logging. Data should only be used for declared purposes, with additional purposes requiring new consent or legal basis. Access policies should encode purpose limitations, restricting data access to systems and users with legitimate purposes. Audit logs enable verification that data is used only for declared purposes. Purpose declarations should be specific and understandable, avoiding vague purposes like “business operations” that could justify any use. Data Minimization Data minimization requires collecting only data necessary for specific purposes, reducing privacy risk through reduced data collection. Prefer derived, transient, or aggregated data forms over raw personal data. Derived data including aggregations and statistics often provides sufficient utility without exposing individual-level data. Transient data processing without persistent storage reduces privacy risk. Data minimization should be evaluated during design, questioning whether each data element is truly necessary. Default to not collecting data unless clear necessity exists. Transparency and Control Users should have transparency into what data is collected, how it’s used, and who it’s shared with. Privacy notices should be clear and accessible, avoiding legal jargon. User control through access, correction, and deletion rights enables users to manage their data. Data Subject Access Requests (DSAR) should be supported through automated workflows. Event trails documenting data access and processing support DSAR responses and demonstrate compliance with privacy commitments.Privacy-Enhancing Technologies
De-Identification and Re-Identification Risk De-identification removes or obscures identifiers to reduce privacy risk, but de-identified data can sometimes be re-identified through linkage attacks. K-anonymity ensures that each record is indistinguishable from at least k-1 other records. L-diversity extends k-anonymity by ensuring diversity in sensitive attributes within each equivalence class. T-closeness requires that sensitive attribute distribution in each equivalence class is close to overall distribution. Linkage attacks combine de-identified data with external datasets to re-identify individuals. De-identification should consider available external data and linkage risks. Differential Privacy Differential privacy adds calibrated noise to query results, providing mathematical privacy guarantees. Privacy budgets limit total information leakage across multiple queries. Differential privacy works best for aggregations and statistical queries, not individual record access. Noise addition reduces data utility, requiring careful balance between privacy and utility. Privacy budget management prevents privacy degradation through repeated queries. Once privacy budget is exhausted, no additional queries should be allowed. Pseudonymization Pseudonymization replaces identifiers with stable tokens, enabling data joining without exposing identifiers. Pseudonymization provides weaker privacy than anonymization but maintains data utility. Token vaults should be separate from pseudonymized data, with strict access controls. Token vault compromise enables re-identification of all pseudonymized data. Pseudonymization enables analytics and data sharing while reducing privacy risk. However, pseudonymized data remains personal data under most privacy regulations.Privacy-Preserving Architecture
Data Contracts with Privacy Attributes Data contracts should include privacy attributes including data classification, retention period, allowed purposes, and access restrictions. Privacy attributes should be machine-readable and enforceable. Column-level and row-level security enforce privacy policies at data layer, preventing unauthorized access regardless of application-layer controls. Database-level enforcement provides defense-in-depth. Privacy-preserving defaults including encryption, access logging, and retention limits should be built into data platforms. Secure defaults reduce privacy risk from configuration errors. Governed Data Access Data access should occur through services that enforce privacy policies rather than direct database access. Service-layer enforcement enables consistent policy application and comprehensive audit logging. Analyst access through governed workbenches provides controlled environments with privacy controls including query logging, result screening, and export restrictions. Workbenches balance analyst productivity with privacy protection. Self-service analytics platforms should include privacy guardrails preventing accidental privacy violations. Guardrails may include automatic de-identification, query result limits, and sensitive data detection.Privacy Reviews and Operations
Privacy Threat Modeling LINDDUN (Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance) provides privacy-specific threat modeling methodology. LINDDUN identifies privacy threats beyond security threats. Privacy Impact Assessments (PIA) and Data Protection Impact Assessments (DPIA) evaluate privacy risks for new systems or significant changes. PIAs should be triggered by risk changes including new data collection or processing. Privacy threat modeling should occur during design phase, when addressing privacy risks is cheapest. Post-deployment privacy fixes are expensive and may require data deletion. Data Retention and Deletion Retention policies should specify maximum retention periods based on purpose and legal requirements. Data should be deleted at source when retention periods expire. Tombstones mark deleted records, enabling deletion propagation to derived datasets and backups. Deletion propagation ensures that data deletion is comprehensive. Backup retention creates challenges for data deletion, as backups may contain deleted data. Backup policies should balance disaster recovery needs with privacy requirements. Privacy Metrics Data minimization scores measure what percentage of collected data is actually used, identifying unnecessary data collection. Low utilization indicates over-collection. DSAR SLAs measure how quickly data subject requests are fulfilled. Slow DSAR response indicates process inefficiencies or technical limitations. Privacy incident rate measures privacy violations including unauthorized access, accidental disclosure, and policy violations. Trending privacy incidents identifies systemic issues.Regulatory Compliance
GDPR and CCPA General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA) establish privacy rights including access, correction, deletion, and data portability. Technical systems should support these rights through automated workflows. Legal basis for processing including consent, contract, legal obligation, vital interests, public task, and legitimate interests should be documented and enforced. Processing without legal basis violates regulations. Cross-border data transfers require appropriate safeguards including Standard Contractual Clauses, adequacy decisions, or Binding Corporate Rules. Data residency requirements may require regional data storage. Privacy Frameworks NIST Privacy Framework provides risk-based approach to privacy management with five functions: Identify, Govern, Control, Communicate, and Protect. Framework enables systematic privacy program development. ISO/IEC 27701 extends ISO 27001 with privacy-specific requirements, providing certification path for privacy management systems. Certification demonstrates privacy commitment to customers and regulators.Conclusion
Privacy engineering requires treating privacy as system property requiring architectural design, technical controls, and operational processes. Security engineers build privacy-respecting systems through data minimization, purpose limitation, and privacy-enhancing technologies. Success requires cultural commitment to privacy beyond legal compliance, with privacy considered throughout system lifecycle from design through decommissioning. Organizations that invest in privacy engineering fundamentals build user trust while reducing regulatory risk.References
- GDPR (General Data Protection Regulation)
- CCPA (California Consumer Privacy Act)
- NIST Privacy Framework
- ISO/IEC 27701 Privacy Information Management
- LINDDUN Privacy Threat Modeling
- Differential Privacy Resources