Lessons Learned While Building a Privacy Operations Center at Headspace Health

my name is shobhit and today I am going to talk about Lessons Learned while building a privacy Operation Center at headspace health before I jump into the talk a bit about me I am currently the security and compliance director at space health before that I had security and GRC roles at HSBC Deutsche Bank people fitted Investments I did my masters in information assurance and cyber security at Northeastern Boston and I'm highly interested in healthcare compliance privacy running and writing so if you have civil interest as mine please feel free to connect after the talk and we can have a very good conversation so what are the goals for the talk today and why we are here to speak about the Privacy Operation Center at the first place the goal is to speak about why build a dedicated POC at the first place secondly I also want to talk about some of the considerations for building a privacy Operation Center and lastly I want to leave you with some guidance or initiating successful privacy programs across multiple org beat engineering privacy product or legal with the goals I also have few assumptions that you have some familiarity with privacy laws such as gdpr CCPA cpra and you are kind of aware for the requirements of HIPAA Your Role is at the intersection of privacy GRC product and engineering and lastly you have at least one security or privacy exec to Garner the support from other management teams now why why do we need to build a privacy Operation Center in the first place first and foremost there are legal and regulatory requirements coming up all the time if you're working in the industry you are well aware of the different state laws from New York Virginia of course California gdpr and then some requirements from HIPAA as well which mandates that you work across uh across the organization with different teams to fulfill these requirements secondly there are mandatory requirements from the App Stores so on the screen I have two screenshots one from Apple the other one from Google Apple mandates you to have a deletion button in the app if you're allowing your users to have a defect functionality to create the the account from the app itself and secondly Google requires you to declare all the data that you're collecting from your third parties and how you are sharing the data with your third parties third in the last quarter itself there were three uh FTC slabs from uh flaps on the FTC on companies which are in the similar spaces us and this the the second screenshot is on the HHS website where so far as of April 10th of 2023 there are 145 breaches reported on the HSS website and this is that's not the the right way for organizations to to prevent their financial reputation losses and once you have this POC it becomes a lot easier to manage this different uh requirements for for compliance and lastly there are there is always this ongoing Midas scrutiny the screenshot on the screen is from Mozilla they publish this report called privacy not included every year and each year they give their score on how the application is performing with respect to their privacy and security practices this screenshot for headspace is from last year where the results were not very favorable for us and this is not the the correct way to to work or functional application where you have like millions of users using your application every single day so it either helps you earn the trust of your users or lose the trust of your users but with all that being said and while we want to bring all of this together we truly believe that privacy is an existential risk for headspace health if we don't have privacy at the Forefront of every single thing that we do it's going to be extremely hard for us to compete and to survive in this space and for that regard every single thing that we do from releasing to a new feature to building a new product we have to have privacy at the Forefront of everything now before I jump into the price Operation Center I always speak about what privacy is and how I look at the Privacy at the first place first privacy is a fundamental human right if you are having privacy in your product and application it's not an add-on it's a fundamental human right and you have to take care of that secondly it's a competitive Advantage for organizations I work with prospective customers all the time and once we have this this conversations regarding our competitors and ours it just becomes evident that privacy is a competitive Advantage for us and if we are showing our leadership and thought leadership in building this privacy practices it's good for the organization and lastly it's a foundation of trust we have millions and millions of users across the world and if you don't have this Foundation of trust with our users it's extremely hard for us to to survive and grow now how do we build this Foundation of trust is an extremely simple process first we make promises we make promises via our privacy policies by our terms of service by our notice of privacy practices and then secondly we keep promises we don't want to do anything which is not aligned with the with the benefit of our customers or which doesn't enrich the user experience of our members so this is how we build the foundation of trust just by making promises and then keeping promises secondly we should also talk about what privacy is not so privacy is not only security and I can give an example of that let's say you are having your data encrypted with the best encryption methods in the world and you have this encryption key distributed to all the engineers is that data really secure yes but is the data really private when all the engineers can access the data no secondly privacy is not a zero-sum game privacy can and need to coexist with Innovation efficiency transparency usability and accountability many times we have this contention with the product teams and the engineering teams that hey we want to build this feature but we have to keep this into account for our privacy and we always come to this conclusion that we have to coexist both of these together it's not in either or for privacy or usability can anybody give you an example of a company which does this really really well Apple yep Apple does this really well and they are like the Hallmark for us to be uh to make sure that we don't take privacy as a zero-sum game and lastly privacy is not solely an individual or organization's responsibility we need the legal and regulative Frameworks to make sure that we have boundaries defined secondly we need the industry best practices there are a lot of best practices around security but there are not best the best practices around privacy that for example if I want to share a piece of data with one of the research Partners how should I go about it that's still uh we don't have an industry practice best practice for and lastly we have to foster a culture of privacy awareness we speak a lot about security awareness in the organizations that we want to prevent malicious insiders we want to make sure that all folks are aware of the security practices at the company but we don't give enough uh importance to privacy awnings which is equally important this essentially means that do your members know when they need to share data with some other third parties what communication tools they can use or are your employees aware of the research projects going on and how they can anonymize the data for their research purpose and lastly I want to speak a bit about the guiding principles of privacy before jumping jumping into the POC so for every single thing that we do at headspace Health we Define principles and then we do the actual work we have principles for our technology Arc we have principles for our Security Org and while we were thinking about having this privacy Operation Center built we realized that we need to have guiding principles so if there's ever an Ever contention that which decision should be the right decision for us we can come back to these principles and take our our guidance from these first one is consent we want to be extremely specific in the consent that we ask but at the same time we want to give this right to users to withdraw the consent second is accuracy we want the member information to be accurate all the time and they should have the right to correct the information if there is an incorrect information about our systems or databases third we want to secure all the databases and we want to make sure that there is no unauthorized access disclosure or use via physical technical administrative set cards fourth we are accountable for complying with all the legal and privacy requirements there is no other way around it we have six or seven requirements that is required by gdpr CCPA to comply and we want to provide all those rights to our members next we want to be extremely transparent about our data classification collection used in Sharing practices what data would we collect from our members what data would we share with with other members and so forth next we want to make sure that the information is confidential and next we want to embed privacy by Design from the Forefront of all the systems that we develop we truly believe that privacy should not be an afterthought once we create the applications also systems it has to be integrated with the sdlc and I will speak about it a bit more that how we can integrate stlc and privacy together if and when things go wrong we want to make sure that we have the resources and we are prepared to inform members uh in a timely and transparent manner we want to minimize the collection of data that we use we don't want any data that will not use for the benefit our members which essentially means to provide them either better recommendations in the headspace app or to just improve their experience when they're using the application and lastly while we are collecting all this data if at some time we determine that this data is not required anymore we need to delete the data or at least anonymize so it just doesn't hang around as a as a risk that you are collecting a lot of data which is not required now what constitutes a POC at the first place so while we were thinking about building this POC and there were like so many things that we could do we realized there were four things that we really need to do and we could just bucket all these things in this four pillars the first one is governance in management the second one is Partnerships the third one is tools and lastly security and awareness so every single thing that we were doing at headspace Health we wanted to have all of those bucketed in either of these four buckets over the next few slides what I want to do is maybe take some guidance from what we developed in our policies and procedures and then go through each of these different buckets and how we can use that guidance for your data classification and your your price Operation Center the first one is data management versus data governance this is the base of everything that we do at headspace health by data management I mean that you have to have organized organization of your data you should have the storage of your data adequately protected you have to protect the data and then you have to maintain the data for adequate reasons and if I talk about data governance it essentially deals with Frameworks policies procedures and distribution now you can if I can sum up all the data governance points in one word that would be strategic all these things are driven by strategy and if I can sum up all the things on the data management side that would be classification which is the base of every single thing that we do so what I'm going to do what the next few slides is to start from classification and then slowly transition into Data governance piece so for data classification this is the traditional data classification I'm sure you all must have seen this in some form or the other where you have public confidential restricted or highly restricted but this data classification did not fit our requirements because headspace health is extremely unique we are a Telehealth organization with two products headspace which is on the consumer side ginger on the care side and this data classification just did not fit our requirements so in this case what we did was We Invented our own so this is the headspace Health Data classification on the First Column we have the parent classification which is sensitive private customer confidential company confidential research and public the second classification speaks to the child classification which is Phi SBI pii customer confidential and so forth and there are a few examples for each of these so right now here is on the screen you are seeing only two or three of these examples but when you are working with our engineering teams we gave them at least 15 examples of each so when they are doing their data tagging for disa requests or when they are doing their data tagging for a deletion request it doesn't come as a surprise and they know exactly how to categorize and tag the data but data classification is incomplete without inventory we all know that you can have the best classification in the world but if you are not inventoring your data and you're not tagging your data it just doesn't make any sense it will just line a spreadsheet and nobody will use it but at the same time complete data inventory is extremely hard when we started doing this for the first time across the company we realized that this is such a critical problem for organizations which are unique which are in healthcare or which are complying with different requirements uh at the same time such as gdpr and HIPAA which information you should delete which information you should hold it's just an extremely hard problem so what we did we had this initial milestone for the data inventory we wanted to have this nine columns just the name purpose internal external storage and the other columns fill this columns to the best of our abilities for all the data that we had and we thought that once we'll do this exercise to the best of our abilities it will make the other processes a lot smoother we did that and then we realized that this only covered the information we have it did not cover the information that we were planning to uh collect by uh provide new features or via our new practices that we're releasing so we'll come back to this slide to tackle this problem that they we did the initial data classification but how should we keep this data inventory alive now relatedly I just have this one slide for these are requests for those of you who are not aware these SARS are data subject access rise request where users can come to you and then asked you to delete your information or delete their information ask further information and there are six additional rights that they can ask for and while we were looking for a decent tour in the market we realized that there is no one-size-fits all if you are in a Telehealth company you have to comply with the requirements of gdpr CCPA but at the same time you also have to comply with the requirements of HIPAA which are very very unique HIPAA requires you to retain all the data for a period of time and you just can't delete the data no matter what so we realized that after uh the entire year we spent on our demo and POC it's just that not the right solution for us so we build our solution for processing the DSA request so this is one slide that I wanted to highlight that if you are thinking about onboarding a tool such as one trust or security please be extremely mindful that your use case could be very very different from what they are already serving and it just might make more sense for you to to build your own tool and not onboard one of those tools and lastly whatever you choose to do just keep it alive if you are inventoring your database make sure that that's that's uh alive if you are having your DSR till built yourself make sure that the scripts that you have are up to date and they are collecting or deleting data when you are storing the data in a new third party so coming back to the earlier slide where we only covered the data that we already had and we only invented that data how it go about collecting the data or inventing the data which will cover or which will collect in the future so for this phase we realized that privacy impact assessments are extremely helpful when you're collecting New pieces of information from your members but if I'm part of the security team and I go to the product team and say hey I need to do a privacy impact assessments can you help me out with that they'll be like no we have some road maps for on our quarter and we have to do this as soon as possible and from my experience I realized that anytime there is legal team in your email chain it just makes the entire conversation a lot easier so I would implore you to make legal team use best friend for every single thing that you're doing now this is one of the procedures that we developed across headspace health and while we want to do a privacy impact assessment for each of the new features we realize that unless and until we have a dedicated workflow for how we want to do that with the product teams and the engineering teams it's not going to serve our purpose so on the screen right now we have three different buckets product engineering legal privacy and security and this is something that we recently rolled out that every time we want to build a new feature at headspace health it goes via this reviews so the product team they built their PRD they give the PRD to the incident team the incident team creates a text back in later relation to the PRD both of those are submitted to the security privacy and legal team for their reviews the legal team performs their own review which essentially means checking all the regulatory requirements that we need to fulfill for example if you want to roll out a new feature in France the French authorities want all the Privacy policies in terms of service in French so those are some things that we want to highlight as much as as early in the process as possible rather than going to the product event saying hey we did all the development but we still don't comply with all the legal requirements the second thing is the Privacy review now here privacy team they go in and make sure that every single piece of pii Slash Phi we are collecting it's cataloged it's remarked that why we are collecting that pii and then if we need to minimize that data collection we propose that to the product team and lastly the security team performs the threat modeling on that PRD so if I receive a new feature request uh me or either my team they perform the threat modeling and also once we develop the feature we conduct an internal pen test so if you are releasing a feature which is going to affect millions of users we don't want to roll that feature out unless we do an internal pen test so we created this entire workflow to make sure that all of these different pieces are covered once we do all of these we propose our recommendations to the product team some of these are blockers some of these are good to have but this has served us really really well so far we rolled out this process in April of this year and so far we pen tested three features we've been tested we reviewed four prds and tech specs and this just uh streamlines the process a lot more when you have the entire chain in your jira ticket now while we want to have all these processes done we don't want our Engineers to keep hanging in and just thinking hey what we are doing to embed privacy by Design in the sdlc so right now we use these three tools for shifting our privacy Focus from left to right the first one is Privado and what Privado does is every time a developer asks for a new piece of pii or Phi in the code it