For a product manager, GDPR is mostly a set of design decisions: what personal data a feature collects, why, how long it is kept, who can see it, and how a breach would be handled. Article 25 requires data protection by design and by default, so those choices are not left to legal review at the end.
Which articles matter most to product work?
Article 5 sets the principles. Among them are purpose limitation, data minimisation, storage limitation, and integrity and confidentiality, with the controller accountable for showing compliance. Each translates to a product question. Why do we collect this field? Do we need all of it? When does it get deleted? Who can read it?
Article 25 is the design duty. It asks the controller to implement appropriate measures, such as minimisation, at the time of designing processing and during it, and to ensure by default that only personal data necessary for each purpose is processed.
Article 32 covers security of processing. It requires technical and organisational measures appropriate to the risk, and lists examples including pseudonymisation and encryption, the ability to ensure ongoing confidentiality, integrity, availability and resilience, the ability to restore availability in time after an incident, and a process for regularly testing and evaluating effectiveness.
Article 33 deals with breaches. The controller must notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to people. A processor must tell the controller without undue delay.
What should you decide per feature?
Purpose. Write one sentence for why each new data element exists. If you cannot, drop the element.
Defaults. If a setting affects how much data is processed, the default should be the privacy protective one.
Retention. Choose a deletion time and build it, including for backups and analytics copies.
Access. Decide which roles may see personal data, and keep support tooling in view, since it often shows more than the product does.
Vendors. Every analytics, support or AI service that receives personal data needs a role analysis and a contract. Ask legal.
A constructed example
A team adds session recordings to understand drop off in a sign-up flow. The first proposal records everything, retains it for a year and gives all staff access. The product manager applies the Article 5 and 25 questions: record only the sign-up flow, mask form fields by default, keep the recordings for thirty days, restrict viewing to the design team and log access. The insight value is the same, and the privacy risk is a fraction.
What to do
- Add a short data statement to every feature spec: data, purpose, retention, access.
- Make the privacy protective option the default for any optional processing.
- Build deletion and retention into the feature, not as a later ticket.
- Review who can access personal data in admin and support tools.
- List vendors that receive personal data, and ask legal to confirm roles and contracts.
- Check that your team knows the breach path: who decides, who notifies, and the 72 hour clock.
- Test security measures regularly, and keep records of the tests.
Safeguard can support the technical side of Article 32 by finding vulnerable dependencies and exposed secrets in your code. Legal analysis and notification decisions rest with your organisation and its advisers.
Quick check
What does data protection by default mean?
By default, only the personal data necessary for each specific purpose is processed, per Article 25.
What is the breach notification window?
Without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to risk people's rights and freedoms.
Sources
- GDPR Article 5, principles
- GDPR Article 25, data protection by design and by default
- GDPR Article 32, security of processing
- GDPR Article 33, breach notification
Last reviewed: 18 October 2026.
