Howl #6: The privacy-by-design checklist you need
Your engineering team just built an incredible new feature.It's innovative. Users will love it. Your PM wants to ship it next sprint. But did anyone ask: "What personal data does this collect?" Or: "How will we handle deletion requests?" If the answer is no, you're not alone. Most product teams treat privacy as an afterthought something to "figure out later."
Here's what that costs:
→ 40+ hours of unplanned re-engineering when a DSAR arrives
→ Delayed customer deals (can't answer procurement questions)
→ GDPR violations you didn't know existed
→ Lost competitive advantage
The better approach? Privacy-by-design. Build privacy into features from day one, not after regulators or customers ask.
What is Privacy-By-Design?
Privacy-by-design means embedding data protection into your product development process from the start.
It's not about slowing down. It's about building smart.
Under GDPR Article 25, privacy-by-design isn't optional—it's legally required.
The math is simple:
Fixing privacy in planning: 1 hour
Fixing it after launch: 40+ hours
Every feature that touches personal data should answer 15 critical questions before it ships.
The 15 Privacy-By-Design Questions
Before you launch your next feature, your team needs answers to these questions!
1. What personal data does this feature collect?
Names, emails, locations, IP addresses, cookies, behavioral data, device IDs? Make a comprehensive list.
2. Why are we collecting each type of data?
"Because we can" isn't a valid reason under GDPR. What's the specific business purpose?
3. What's our legal basis for processing?
Consent? Contract necessity? Legitimate interest? This isn't just legal semantics—it determines what you can and can't do with the data.
4. Are we collecting more than we need?
GDPR requires data minimization. Less data = less liability in a breach.
5. Where will this data be stored?
Production database? Analytics tools? Third-party systems? You need to know every location to respond to DSARs.
6. Who will have access to this data?
Internal teams? Third-party vendors? Each vendor needs a Data Processing Agreement (DPA).
7. Will this data be used for other purposes?
Marketing? Analytics? ML training? GDPR requires purpose limitation—you can only use data for disclosed purposes.
8. Are we sharing this data with third parties?
Every third party touching EU data requires a signed DPA. No exceptions.
9. How long will we keep this data?
"Forever" isn't compliant. Define retention periods now, including for backups.
10. Can users access this data if requested (DSAR)?
You have 30 days to respond. Can engineering actually extract it across all systems?
11. Can users delete this data if requested?
From production, analytics, backups, AND third-party tools? Test it before you ship.
12. Can users correct or update this data?
Build user-facing controls. Don't make them email support for simple changes.
13. Does this involve high-risk processing?
Children's data? Biometrics? Health information? Large-scale profiling? These trigger DPIA (Data Protection Impact Assessment) requirements.
14. What happens if this data is breached?
GDPR requires breach notification within 72 hours. Do you know who to notify and how?
15. Have we documented everything?
When procurement asks about this feature, can you send documentation same-day or does someone spend a week scrambling?
What Most Teams Get Wrong
The gap isn't technical capability. Most teams can build privacy-compliant features.
The gap is asking the right questions at the right time.
When privacy is an afterthought:
Engineers make assumptions about legal requirements
Nobody documents data flows
Deletion becomes a nightmare
Procurement questions reveal gaps you didn't know existed
When privacy is embedded from day one:
Features ship with compliance built-in
Documentation exists when clients ask
No expensive re-engineering later
Privacy becomes a competitive advantage
Privacy-by-design isn't slower. It's smarter.
The Questions You Should Be Asking Yourself
After reading these 15 questions, here's what successful product teams realize:
"We can probably answer questions 1-5 ourselves..."
Yes. Data collection questions are straightforward.
"...but questions 6-9 get complicated fast."
Data usage involves legal basis analysis, third-party contracts, and purpose limitation nuances.
"Questions 10-12 reveal technical gaps we didn't know we had."
Most teams discover they can't easily handle DSARs or deletions. That's expensive to retrofit.
"Questions 13-15 are where we need expert guidance."
High-risk processing, DPIAs, and proper documentation require privacy expertise.
The pattern? Simple questions have simple answers. Complex questions need expert review.
When You Need More Than a Checklist
A checklist catches obvious issues. But some features need deeper privacy review.
Get expert help if your feature involves:
Health data, biometric data, or children's data
AI/ML for automated decision-making
Large-scale profiling or tracking
International data transfers
New third-party data sharing relationships
What expert privacy review provides:
Privacy Impact Assessments for high-risk processing
Legal basis analysis for complex scenarios
DPA review and negotiation with vendors
Technical privacy architecture guidance
Documentation ready for procurement and regulators
At Third Wolf, we speak both languages:
Legal requirements + technical implementation.
We work with product and engineering teams to build privacy into features from day one without slowing down development.
Book your free assessment here!
The Bottom Line
Ship fast AND ship compliant.
Privacy-by-design means asking 15 questions early that prevent 40+ hours of unplanned work later.
Your next feature should answer these questions before it ships—not after a customer asks.
The cost of getting it wrong? Expensive re-engineering, delayed deals, regulatory risk.
The cost of getting it right? 1-2 hours in planning.
Download the checklist. Build smart. Ship confidently.
Risk Down. Revenue Up. ⚡
