Data protection impact assessments (DPIA), sometimes referred to as a Privacy Impact Assessment (PIA), are a tool used to describe how you intend to process and protect the personal information(PI, PII, etc) of individuals. Many forms of regulation including the GDPR and some compliance standards will require a DPIA depending on the risk levels associated with the data you are processing.
As builders of software we like to talk about user-centered design. We put ourselves in the mindset of the person using our app, service, or product. Successful user-driven companies bake this process into every part of their software lifecycle. It doesn’t stop at the initial research. Every decision is paired with the question: What about the user? The same approach can be taken when building with privacy in mind. The notion of Privacy By Design (PbD) does that.
Mapping and cataloging personal information collected from users is time-consuming. It is error-prone, and relies on hunting down information from multiple departments. For many teams, creating an accurate data flow map will be the hardest part of completing GDPR Article 35's data privacy impact assessment (DPIA) or any privacy impact assessment (PIA). Even for smaller businesses with limited departments and fewer software offerings, determining how data exists and how it moves can be a challenge.
In the fall of 2020, voters in California approved the California Privacy Rights Act (CPRA). Touted as California Consumer Protection Act (CCPA) 2.0, the CPRA is more an addendum and expansion of CCPA rather than an entirely new law. Think of it as an update that fixes unclear parts of the previous law and adds new systems to better handle the existence of the law itself. As there are a few “breaking changes”, the 2.0 moniker is pretty apt for those in the software world.
The General Data Protection Regulation (GDPR) set a huge precedent in modern digital privacy regulation. We've seen regions throughout the world adopt similar data protection laws in the time since its inception, and the financial liabilities are only part of the story. Customers and users of software products are now savvier than ever when it comes to understanding the importance of data privacy rights.
In order to ensure compliance with the growing list of personal privacy regulations—like GDPR, CCPA, and PDPA—your company needs to know how it handles the personal information of your customers, users, and even visitors.
Modern privacy regulation is centered around the concept of personal information. The General Data Privacy Regulation (GDPR) popularized it, but since then similar initiatives—like the California Consumer Privacy Act—have expanded on the definition of "Personal Information." If your application collects any kind of information about your users or customers, it is important that you track when, how, and for what purpose you are collecting their data.
ISO 27001 is a way for companies to prove a certain standard of security to their customers. You may recognize ISO as the standards body that issues international standards and classifiers for all kinds of products and services, including date and time standards, country and currency codes, and structural systems—like the ones we’ll be discussing in this article.
On December 1st 2020, New Zealand’s revamped privacy act went into effect. The Privacy Act originally passed in 1993 and has been revisited multiple times, but the 2020 act clarifies its reach and outlines what organizations need to do in order to be compliant.
Your business relies on third-party APIs to operate. Sometimes they enhance your capabilities, and other times they bridge the gap between your business and where your customers are through integrations. Either way, the intermingling of data and services between your business and these third-party vendors can put your business at risk. When it comes to ensuring these providers are handling data securely, SOC 2 has become one of the most common security frameworks for tech companies.
