Security and Privacy as Complementary Controls
Security protects data. Privacy protects the person behind that data. Adarsh Nair opens with a simple analogy: security is the lock on the door, privacy is the curtain on the window. Both are necessary but serve different goals. Most application security programs address confidentiality, integrity, and availability. Privacy threat modeling adds a different layer: data minimization, purpose limitation, and user accountability. Building both into the same development cycle is what makes protection complete.
Privacy Debt and the Cost of Deferral
Greeshma Nair describes privacy debt: missing consent prompts, absent privacy notices, and undocumented data flows that teams defer to a later sprint. In one scenario she describes, a feature captured user email addresses without consent or a deletion option. Developers treated it as service data. Regulators count it as personal data. The result was a full redesign that delayed the launch by weeks. GDPR fines for similar decisions have reached 1.2 billion euros. The debt is never cheap to pay down.
Privacy by Design: Seven Foundational Principles
Privacy by Design originated in the 1990s with Dr. Ann Cavoukian, then the Information and Privacy Commissioner of Ontario. She proposed seven principles: anticipate privacy issues before they occur; make privacy the default setting; embed it in the product’s architecture; treat privacy and functionality as non-competing; protect data through its full lifecycle; maintain transparency about data use; and give users control over what they share. GDPR Article 25 now formally requires these practices. India’s DPDPA, UAE’s personal data law, and California’s CCPA follow the same language.
LINDDUN: A Framework for Naming Privacy Threats
LINDDUN gives teams a structured way to name privacy threats. The acronym covers Linkability (connecting data points to infer behavior), Identifiability (re-identifying a supposedly anonymous person), Non-repudiation (being held accountable for actions you cannot deny), Detectability (knowing an action occurred even without knowing its content), Disclosure of information (data shared beyond its intended scope), Unawareness (users not informed of collection or purpose), and Non-compliance (failing to follow applicable regulations). Developed at KU Leuven, LINDDUN is applied alongside STRIDE in the same threat modeling session.
Adding Privacy to Sprints Without Slowing Teams Down
One question per sprint keeps overhead low. Sprint one: what data are we collecting? Sprint two: how is it stored and for how long? Sprint three: where is it transferred? Each question looks simple but triggers thinking about data sources, geographic regions, and applicable regulations. Privacy scorecards give developers a binary entry point: does this feature collect personal data? If yes, privacy factors apply. If no, only security controls are needed. Data flow diagrams catch cross-border transfer issues before they become GDPR violations.
Q&A
Where can teams find the LINDDUN privacy cards? The cards are freely downloadable from the LINDDUN website and explain each threat category through real-world examples. ▶ 38:00
If you only raise one privacy question per sprint, won’t the system design evolve past the window where changes are still cheap? Each question seeds deeper analysis covering data sources, jurisdictions, and applicable regulations. The intent is to trigger granular thinking, not limit it. ▶ 38:39
What are the privacy nudges in Miro? Miro is used as a brainstorming whiteboard to map what personal data a feature collects and how sensitive it is. The data flow diagram is built after that brainstorm completes. ▶ 40:38
Notable Quotes
privacy is about protecting the person Adarsh Nair · ▶ 1:19
privacy aspect was not visible during Greeshma Nair · ▶ 4:40
privacy should not be something you add Greeshma Nair · ▶ 10:42
Key Takeaways
- Privacy debt accumulates when consent prompts, notices, and data flow controls are deferred to later sprints.
- LINDDUN maps seven privacy threat categories and applies alongside STRIDE in the same threat modeling session.
- One privacy question per sprint, translated from legal language into developer terms, prevents late redesigns without adding process overhead.
About the Speakers
Adarsh Nair is Director and Global Head of Information Security Compliance at UST, where he leads information security and business continuity programs across global operations.
Greeshma Nair is a certified privacy and security professional specializing in GDPR, DPDPA, and global data protection frameworks. She holds CIPP/E certification, is an ISO 27701 Lead Implementer, and has completed Data Protection Officer training.