Privacy by Design and by Default

Introduction

Article 25 of the GDPR requires organizations to implement data protection principles into their processing activities and business practices. This means privacy must be embedded into the design of systems, processes, and business practices from the outset, not added as an afterthought.

Core Concepts

Privacy by Design

Definition: Integrating data protection into the development of business processes, products, and services from the earliest stage of design.

Philosophy:

Proactive not reactive
Preventative not remedial
Privacy as the default setting
Privacy embedded into design
Full functionality (positive-sum, not zero-sum)
End-to-end security
Visibility and transparency
Respect for user privacy

Privacy by Default

Definition: Ensuring that personal data is processed with the highest privacy protection by default, so that by default personal data is not made accessible to an indefinite number of individuals.

Requirements:

Only process data necessary for the specific purpose
Data is not automatically public
Minimal data collection by default
Shortest retention period by default
Limited accessibility by default

The Seven Foundational Principles

1. Proactive not Reactive; Preventative not Remedial

Principle: Anticipate and prevent privacy issues before they occur.

Implementation:

Identify privacy risks early in project planning
Conduct Data Protection Impact Assessments (DPIAs)
Build privacy controls into systems from the start
Regular privacy reviews and audits
Continuous monitoring and improvement

Emily Helps Example:

Privacy risks assessed during feature development
Security controls built into all features
Regular security audits and penetration testing
Continuous monitoring for vulnerabilities

2. Privacy as the Default Setting

Principle: Personal data must be protected by default, without any action required by individuals.

Implementation:

Minimal data collection by default
Data not public by default
Strictest privacy settings enabled automatically
Opt-in rather than opt-out for data sharing
Purpose limitation enforced by default

Emily Helps Example:

Optional fields truly optional
Data visibility restricted by default
Strict access controls by default
Consent required for optional features
Conservative retention periods by default

3. Privacy Embedded into Design

Principle: Privacy is an essential component of core functionality, not an add-on.

Implementation:

Privacy requirements in project specifications
Privacy considerations in architecture decisions
Security in all development stages
Privacy testing alongside functional testing
Privacy metrics in performance monitoring

Emily Helps Example:

Data protection in system architecture
Encryption at all layers
Privacy-aware feature design
Security requirements in development standards
Privacy test cases in QA process

4. Full Functionality (Positive-Sum, not Zero-Sum)

Principle: Privacy and functionality can coexist; it’s not an either/or proposition.

Implementation:

Seek innovative solutions that provide both privacy and functionality
Avoid false dichotomies between privacy and usability
Design systems that are both secure and user-friendly
Balance competing interests without compromising either

Emily Helps Example:

Secure yet intuitive interfaces
Privacy-preserving features that enhance user experience
Encrypted yet searchable data
Audit logging that doesn’t impact performance

5. End-to-End Security (Full Lifecycle Protection)

Principle: Protect data throughout its entire lifecycle, from collection to deletion.

Implementation:

Secure collection methods
Encryption in transit and at rest
Secure processing and storage
Protected during use and sharing
Secure deletion at end of life
Backup security

Emily Helps Example:

TLS 1.2+ for data transmission
AES-256 encryption for stored data
Secure APIs and integrations
Automated retention policies
Secure deletion procedures
Encrypted backups

See: Data Security Measures

6. Visibility and Transparency

Principle: Operations remain visible and transparent to users and stakeholders.

Implementation:

Clear privacy notices
Transparent data processing practices
Accessible privacy information
User dashboards showing their data
Regular privacy communications
Open about data practices

Emily Helps Example:

Clear privacy notices at data collection
User self-service data access
Transparent processing purposes
Regular privacy updates
Accessible documentation
Open communication about security

7. Respect for User Privacy

Principle: Keep user interests central and provide strong privacy defaults and controls.

Implementation:

User-centric design
Meaningful consent mechanisms
Easy-to-use privacy controls
Honor user choices and preferences
Empower users to exercise their rights
Minimize data collection

Emily Helps Example:

Self-service rights management
Granular privacy controls
Easy consent withdrawal
Simple data export and deletion
Responsive to user requests
Regular user feedback collection

Data Protection Impact Assessment (DPIA)

When Required

A DPIA is required when processing is likely to result in a high risk, particularly when:

Systematic and extensive automated processing (including profiling)
Large-scale processing of special category data
Systematic monitoring of publicly accessible areas on a large scale

When Recommended

Even if not legally required, conduct a DPIA when:

Implementing new technology
New data uses or purposes
Significant changes to processing
Processing children’s data
Using new data sources
Changing data processors
High volume of personal data

DPIA Process

Step 1: Identify the Need

Describe the processing
Define the purpose and necessity
Identify all data flows
Document legal basis

Step 2: Describe the Processing

What data will be collected?
How will it be collected?
Who will have access?
How will it be stored?
How long will it be retained?
Who will it be shared with?
Will it be transferred internationally?

Step 3: Assess Necessity and Proportionality

Is the processing necessary for the purpose?
Is there a less intrusive way to achieve the purpose?
Is the data collected proportionate?
Are retention periods appropriate?
Can data be anonymized or pseudonymized?

Step 4: Identify and Assess Risks

Assess risks to individuals’ rights and freedoms:

Likelihood: How likely is harm to occur?
Severity: How serious would the impact be?
Risk Level: Combine likelihood and severity

Consider risks such as:

Unauthorized access or disclosure
Identity theft or fraud
Discrimination
Psychological harm
Physical harm
Financial loss
Reputational damage

Step 5: Identify Measures to Mitigate Risks

For each identified risk:

What measures will reduce likelihood?
What measures will reduce severity?
What is the residual risk after mitigation?
Is the residual risk acceptable?

Step 6: Consult Stakeholders

Consult Data Protection Officer
Consult affected individuals (where appropriate)
Consult processor representatives
Consult security experts
Seek advice from supervisory authority (if high residual risk)

Step 7: Document and Approve

Document all findings
Get sign-off from senior management
Integrate into project documentation
Make available for supervisory authority review

Step 8: Review and Update

Review when circumstances change
Review regularly (e.g., annually)
Update as new risks identified
Document review activities

DPIA Template

Emily Helps provides a comprehensive DPIA template including:

Project description form
Data flow mapping tools
Necessity and proportionality assessment
Risk assessment matrix
Mitigation planning tools
Sign-off and approval workflows
Review scheduling

Privacy by Design in Practice

System Design

Architecture:

Modular design for easier security
Segregation of sensitive data
Defense in depth
Fail-secure mechanisms
Secure APIs and interfaces

Data Design:

Minimize data fields
Separate identification from other data
Use pseudonymization where possible
Design for data portability
Plan for deletion from the start

Access Design:

Role-based access control
Least privilege principle
Need-to-know access
Separation of duties
Regular access reviews

Process Design

Data Collection:

Just-in-time data collection
Progressive data collection (collect only when needed)
Clear purpose communication
Granular consent options
Easy consent withdrawal

Data Use:

Purpose limitation enforcement
Automated compliance checks
User notification of new uses
Data minimization in processing
Privacy-preserving analytics

Data Sharing:

Minimize sharing
Encrypted transmission
Access controls on shared data
Audit trail of sharing
Agreements with recipients

Data Deletion:

Automated retention enforcement
Easy user-initiated deletion
Secure deletion methods
Verification of deletion
Documentation of deletion

User Interface Design

Transparency:

Clear, concise privacy information
Just-in-time notices
Visual privacy indicators
Privacy dashboards
Accessible privacy settings

Control:

Easy-to-find privacy settings
Intuitive privacy controls
Granular options
Immediate effect of changes
Confirmation of actions

Consent:

Separate from other terms
Specific and granular
Affirmative action required
Easy to understand
Easy to withdraw

Privacy by Default Settings

Data Collection

Default Setting: Collect only mandatory fields

Optional fields clearly marked
No pre-population of optional fields
Progressive collection as needed
Clear explanation for each field

Default Setting: No sharing with third parties

Explicit consent required for sharing
Clear explanation of sharing purpose
Granular control over what is shared
Easy to revoke sharing consent

Data Visibility

Default Setting: Minimum necessary visibility

Data visible only to authorized users
User data not public by default
Need-to-know access restrictions
User can control additional visibility

Communications

Default Setting: Essential communications only

Marketing requires opt-in
Newsletter requires explicit consent
Transactional emails only by default
Easy unsubscribe mechanism

Data Retention

Default Setting: Shortest necessary retention

Conservative retention periods
Automatic deletion when no longer needed
User can request earlier deletion
Clear retention period communication

Accountability Measures

Documentation

Maintain records of:

Privacy design decisions
DPIAs conducted
Risk assessments
Mitigation measures
Privacy reviews
Training activities

Records of Processing Activities (Article 30)

Document for each processing activity:

Purpose of processing
Categories of data subjects
Categories of personal data
Recipients of data
Transfers to third countries
Retention periods
Security measures

Emily Helps Features:

Processing activity register
Automated documentation
Template library
Version control
Export capabilities

Policies and Procedures

Essential privacy policies:

Privacy policy (external)
Data protection policy (internal)
Data retention policy
Data breach response plan
Data subject rights procedures
Vendor management policy
Security policy

Training and Awareness

Staff Training:

GDPR fundamentals
Privacy by design principles
Data handling procedures
Security awareness
Incident reporting
Regular refreshers

Developer Training:

Secure coding practices
Privacy-preserving techniques
Threat modeling
Security testing
Privacy patterns

Management Training:

GDPR obligations
Risk management
Compliance oversight
Resource allocation
Accountability

Continuous Improvement

Regular Reviews

Quarterly: Review new processing activities
Biannually: Review existing DPIAs
Annually: Full privacy program review
Ad hoc: When significant changes occur

Monitoring and Metrics

Track:

Privacy incidents
Data subject requests
Compliance with retention policies
Access control reviews
Training completion
DPIA coverage

Lessons Learned

Learn from:

Privacy incidents
Near misses
Data subject complaints
Regulatory guidance
Industry best practices
Peer organizations

Updates and Improvements

Update procedures based on lessons learned
Implement new privacy-enhancing technologies
Refine risk assessments
Improve documentation
Enhance training
Update policies for legal changes

Emily Helps Privacy by Design

Built-In Privacy Features

Minimal Data Collection: Only essential fields required
Purpose Limitation: Features enforce intended use
Granular Consent: Fine-grained consent management
Access Controls: Role-based permissions
Audit Logging: Complete activity trail
Retention Management: Automated enforcement
Encryption: All sensitive data encrypted
Anonymization: Privacy-preserving analytics

Privacy-First Development

Security requirements in all user stories
Privacy review in design phase
DPIA for new features
Security testing in QA
Privacy documentation
Regular security audits

Continuous Compliance

Regular GDPR updates
Industry best practices
Security certifications
Transparency reports
Customer feedback integration

Best Practices

Start Early: Consider privacy from project inception
Be Proactive: Anticipate and prevent privacy issues
Document Everything: Record privacy decisions and assessments
Default to Privacy: Make the privacy-friendly choice the default
Empower Users: Give users control over their data
Be Transparent: Clearly communicate data practices
Minimize Data: Collect only what you need
Secure Everything: Implement security at all layers
Review Regularly: Continuously assess and improve
Train Staff: Ensure everyone understands their role

Resources

Templates and Tools

DPIA template and guide
Processing activity register template
Privacy by design checklist
Risk assessment matrix
Privacy policy template

Privacy by Design and by Default

Introduction

Core Concepts