Data protection by design and by default
Data protection by design requires integrating privacy and data protection safeguards into the development of systems, services, or processes from the earliest planning stage. Data protection by default ensures that, by default, only personal data necessary for a specific purpose is processed without requiring user intervention.
What it means
In practice, "by design" means that privacy cannot be an afterthought or a layer added after a product is built. Organizations must proactively integrate technical and organizational measures—such as pseudonymization—into the architecture of their processing activities to protect the rights of data subjects.
"By default" refers to the baseline configuration of a system. It mandates that the strictest privacy settings are applied automatically. A user should not have to navigate a settings menu to ensure their data is not being processed for purposes beyond what is strictly necessary for the primary service.
This requirement applies broadly to both software engineering (e.g., app development) and business operations (e.g., creating a new HR onboarding process). The objective is to minimize risk and limit the volume of personal data handled by default.
How to meet it
- Conduct Data Protection Impact Assessments (DPIAs) during the design phase to identify and mitigate privacy risks before implementation.
- Implement data minimization by auditing all data collection forms and removing fields that are not strictly necessary for the stated purpose.
- Configure system defaults so that the most restrictive privacy settings are active upon account creation or process initiation.
- Use pseudonymization, encryption, and hashing as standard architectural components rather than optional add-ons.
- Establish automated data retention schedules that trigger deletion or anonymization once the processing purpose is fulfilled.
- Apply Role-Based Access Control (RBAC) to ensure that personal data is only accessible to employees who require it for their specific job function.
Evidence an auditor asks for
- Completed DPIAs and risk registers showing how privacy concerns were addressed during the project planning phase.
- System architecture diagrams or design specifications highlighting integrated security controls like encryption or pseudonymization.
- Screenshots of default system settings demonstrating that restrictive privacy options are pre-selected.
- Data flow maps documenting exactly what data is collected, where it resides, and why each element is necessary.
- Configuration logs or scripts proving that automated deletion/archiving policies are active and functioning.
Common pitfalls
- Treating privacy as a "compliance checklist" performed at the end of development rather than an integrated design requirement.
- Relying on user opt-outs (asking users to turn off data sharing) instead of using opt-ins for non-essential processing.
- Collecting excessive data "just in case" it becomes useful later, which violates the principle of purpose limitation and minimization.