10-21, 13:30–13:55 (US/Eastern), ENG 103
Privacy compliance is a hot, top-of-mind topic for legal, security, and governance teams alike, especially with the advent of things like GDPR and the Trans-Atlantic Data Privacy Framework. Here in Canada, we have PIPEDA. In the US, we have CCPA/CPRA, NYPA, etc. What do these acronyms mean? What do the regulations cover? And more importantly, how can we navigate this new era of data regulations, across legal, security, and governance, that doesn't involve overwhelming ourselves with immense amounts of paperwork?
We'll walk through the basic fundamentals of a Privacy Program that cover the typical broad set of data/privacy regulations, in addition to how they may work well (or not well!) with other existing security compliance/legislations. We'll cover the core software components required to support such a Privacy Program. Finally, we'll talk through how to build a successful Privacy Engineering team within your security organization that both complements both your existing security engineering needs in tandem with your Privacy Legal functions.
And if we have time, we can talk about lessons learnt along the way. :)
Given the need to respond to existing privacy regulations, what are the common critical components that form a base privacy program (privacy program is analogous to say, a vulnerability management program, a vendor assessment program, a security compliance (e.g. PCI, SOX, etc) program etc. so “program” here refers to a set of processes)? Given that privacy program and its process subcomponents, how does one ensure such a program is manageable/sustainable? What functions of this program can be functionally solved with software services, and how does one build out a privacy engineering team (a software engineering team focused on privacy engineering functions) to support these processes within this program?
Another way of wording this is: I frequently get CISOs or other heads of security who come to me and ask me “I want to build out our privacy program/privacy engineering team, but I don’t know where to start, because I haven’t been following industry best practices. What are the basics that I need to know, and how do I build out this program or engineering team?”
Presentation Outline:
- 1: What is Privacy (Compliance)? (3min)
- Why? A brief (global) history
- Acronym salad - what do these terms mean?
- What we are NOT covering (PETs (e.g. Differential Privacy), Personal Privacy, Trust/Safety, etc.)
- 2: Building a Privacy Program (5min)
- The people (lawyers, program managers, product managers, engineers)
- The components:
- Data Subject Access Requests (DSAR) (aka fulfilling customer delete/export requests)
- Data Privacy Impact Assessments (DPIA) (aka vendor/data inventory)
- Data Policy Management (aka data classification and retention)
- Consent management (e.g. cookie compliance)
- Bonus features: Granular access control; data operation flow tracing
- Conflicts and considerations with things like PCI, SOC2, SOX, etc.
- 3: Building the Privacy Program Processes (5min)
- Where does this fit in your SDLC?
- Keeping documentation generated by your privacy program up-to-date (and ideally: real-time!)
- Hint: automate, automate, automate!
- Engineering privacy (compliance) by design
- Creating incentives for your Product, Engineering, and Data teams
- 4: Building a Privacy Engineering team (5min)
- Why (not) in a Security organization?
- Complementing privacy to existing security teams/programs
- Skillsets to look for/hire for
- Sample vision/mission statements
- Why (not) in a Security organization?
- 5: Bringing it all together (2min)
- 6: Q&A (5min)
Sarah is a recovering privacy engineering practitioner based out of the Toronto area. She leads (or has led) teams in security, privacy, and infrastructure engineering at large finance and e-commerce tech companies. She is also a core organizer for BSidesSF, overseeing the program and presenter operations.
Outside of work, she enjoys hanging out with her celebrity cat Sprinkles, playing video games, and playing the accordion poorly.