Privacy Impact Assessments (PIAs) are a tool for a diverse range of engineers, analysts, product owners, compliance, legal, and idealistically, anyone who uses data. PIAs help members evaluate what impact any proposed changes have to your data and privacy profile. In the world of Blob, NoSQL, and other more typical relational type storage, Machine Learning and AI algorithms, all data is heavily-interconnected as soon as it's integrated. Systems are so complex that it's rare where anyone fully understands the impact of change on a detailed level. While not all industries will need this level of precision, certain ones do. To date, in my experience, PIAs are often managed by some type of project management group via an Excel Spreadsheet with various questions that are used to highlight KRI (Key Risk Indicators).
In more basic privacy regulatory burden landscapes (e.g. consumer retail), the KRI categories of sensitive data usually focus on:
Credit card info,
SSNs (if applicable), and
PII (Personally Identifiable Information) - think Name, Address, Phone, and Email
at a minimum. However, with the proposed regulatory changes to cookies continually looming, other smart devices:
TV
Xbox
Video Doorbell
Security Cameras in or outside your come
any of these could become PII fairly soon! Also, one has to consider the expanding definition of "Consumer Healthcare" data. This data isn't in HIPAA's scope, so states are extending protections into other businesses that even tangentially involve a person's medical health record (at least in Washington - See The Washington My Health My Data Act, "the Act" coming effective 31MAR2024). Places like CVS or Rite Aid which were historically only subject to breach notification laws now need to be more prepared with documentation to reflect what data needs additional protection given some of "the Act's" requirements.
In more complex regulatory burden landscapes, the PIA would need to be a more diversified and co-created assessment. One would likely start with Compliance and Legal cohorts to create an initial assessment, get a group of leaders in a room to hash out risks, and come to some sort of conclusion of whether the data is ok to bring into your architecture, in best case scenario before the data even is loaded from a file, API, or other gateway. When Engineering or Data people are in that hashing process, conversation in my experience, inevitably falls to permissible purpose and the controls surrounding how it's been defined. How does one prove (and ensure) one client/customer/user cannot see another's data and if someone were to access from the outside, it would have to be under this 24 hour monitored role (as an example). The more you can include those baseline assumptions or controls into the PIA itself, the better prepared you'll be if/when an internal, external, or breach auditor is asking. Combine those systemic assumptions/controls with info about the product, purpose, and pathways, and any changes a PIA is intended to highlight can be easily be laid bare. So, do yourself a favor and spend more time to reflect on your audience and how best to describe the change's impact to that info and if you don't know, then you'll need to get that answer before you request a change or new data to be introduced.
While some may question the necessity of a PIA for seemingly minor changes, it is crucial for maintaining a solid audit trail. In the event of a breach or other disasters, a well-documented PIA can withstand judicial scrutiny and protect the company's interests in the long run. When will engineering start seeing all changes as changes, because in my experience, they don't!
Further info on the impact of cookieless future here