Short answer:Privacy by design means that you build in protection for personal data from the very first decision of the project - in architecture, database and interface - instead of adding it afterwards. It is a legal requirement in the GDPR (Article 25) and makes the service both safer and easier to maintain.
What does privacy by design mean?
The term was coined long before GDPR, but the regulation made it a requirement. In Swedish, the term is often usedbuilt-in data protection. The idea is simple: it is always cheaper and safer to think about privacy from the beginning than to try to fix a leak or a poorly built database afterwards.
A closely related principle isprivacy by default– built in as standard. It says that the most privacy-friendly setting should be the default. A user should not have to look in menus to protect themselves; the protection must be on from the start.
What principles should I follow?
Here are the guiding principles, translated into what you actually do in a project:
- Collect as little as possible (data minimization).For each field on a form, ask yourself: do we really need this? Phone numbers you never call are a risk without benefit.
- Determine purpose and keep no longer than necessary.Have a clear reason why you save something, and purge when the reason disappears.
- Protect at all levels.Encryption in transit (HTTPS) and at storage, plus access control so that only the right people have access to the right data.
- Pseudonymize where possible.Replace direct identifiers with codes, making a leak less sensitive.
- Give the user control.Make it easy to see, correct and delete your data.
- Be open.Clearly explain what you are collecting and why.
How does it look in practice?
Principles are nice, but it's the decisions in the code that count. Some concrete examples:
In the database
Do not store social security numbers in fields where they are not needed. Separate sensitive data from others. Set up access rules (in Supabase for example with Row Level Security) so that a user can only read their own data - not everyone else's.
In forms and interfaces
Only have the fields you really use. Leave marketing checkboxes aloneuncheckedby default. Show a clear and brief explanation of what happens with the data.
In logs and tracking
Do not log more than you need for troubleshooting. Avoid sending personal data to third-party tools for statistics without thinking it through.
A good rule of thumb: data you never collected can never be leaked. The simplest protection is often to simply not ask for information you don't need.
Why is it worth it?
In addition to the fact that it is a legal requirement that the Swedish Privacy Protection Authority (IMY) can review, you gain from it in practical terms. Less data means less to protect, less to leak and less to clean up. Clear access rules make the system easier to troubleshoot. And users trust more companies that clearly respect their privacy.
That's how you get started
- Inventory.What personal data does your service collect today - and why?
- Peel away.Remove fields and collection you don't use.
- Set protection as default.Encryption, permissions and privacy-friendly presets.
- Build it into your next project from day one.That's when it gets really cheap.
Do you want to build right from the start?
At ZORC, we build websites, e-commerce, apps and AI solutions - and we have data protection built into the way we work, not as an afterthought. Are you going to build something new or do you feel unsure whether your current solution handles personal data correctly? Get in touch with ZORC, and we'll help you do it safely from the first line of code.
