S
Suzanne Scacca
Guest
If your website or app collects user data, it may be subject to various regulatory requirements. Learn the most common ones and how to maintain compliance.
With so much of our lives taking place online, the job of a web designer has grown extremely complex. Not only are you tasked with turning a brand’s vision into a workable and successful digital product, but you have to build enjoyable, frictionless experiences for their users.
It’s not just a brand’s list of requirements or web standards that you have to design around either. With more transactions taking place online, consumers are rightly more concerned over their data privacy and security.
As such, it’s now become a designer’s job to understand what types of regulatory compliance affect the products they build.
Because there are a lot of policies and legislation floating around—and it differs based on locale as well as industry—this post will serve as a basic resource for web designers. If you’re wondering how to make your digital products compliant, keep reading to learn about the most prominent regulations impacting the work you do.
It might seem like an impossible feat—to build a digital product that complies with every law, policy or regulation that dictates how it should handle users’ info.
The trick is to narrow down the list to the most relevant regulations. So what I’ve done below is break out the most common types of regulatory compliance:
It’s a good idea to review each of them just so you’re acquainted with what’s happening in the world of regulatory compliance.
GDPR
In 2018, the General Data Protection Regulation (GDPR) rocked the internet. Its aim was and is to protect EU citizens’ data.
Initially, there were people saying, “Hold up. This regulation only covers EU citizens. So what’s the big deal?”
While the regulation protects EU citizens, anyone collecting data on them is accountable to this law. This applies to everyone—from California-based ecommerce websites selling goods to bloggers in Melbourne who have newsletter subscription forms on their sites.
The GDPR revolves around seven principles:
Another important piece of this regulation is consent. Your digital product is free to collect data following the seven guiding principles only once you’ve obtained consent from the user. And if you plan to do anything with it besides hold onto it for administrative or billing purposes, you need to gain their consent again (like to share it with a third party).
Cookie consent notices help with the superficial adherence to the regulation. However, you really should be thinking more about how your product is collecting, storing and securing your users’ data. Penalties for violating GDPR are steep.
The EU isn’t the only region with personal data privacy regulations. SecurityScorecard has a list of 16 countries with similar laws.
CCPA
Although the U.S. doesn’t currently have any such laws in place, the state of California does.
The California Consumer Privacy Act (CCPA) provides protections for California consumers. Specifically, it gives consumers:
This law affects for-profit organizations who primarily serve California citizens and who generate a gross annual revenue of $25 million. So, unlike GDPR which has far-reaching effects on most people doing business online, CCPA mainly affects enterprises in and around the state of CA.
HIPAA
It’s not just consumers’ personal information that needs protecting online. Regulations are in place to protect their private medical information as well.
In the United States, Health Insurance Portability and Accountability Act (HIPAA) has been around since 1996. It doesn’t strictly apply to online data protections though. It safeguards the privacy of patients—specifically, data that is classified as protected health information (PHI).
The act gives patients the ability to determine who can see and use their PHI. This applies to oral, written, as well as electronic forms of their data.
Although HIPAA primarily applies to medical providers and insurance companies that deal in patient data on a regular basis, business associates are impacted by this law as well. So even if you’re not building a website, app or patient portal for, say, a hospital, physician’s office or health insurance carrier, organizations that partner with medical entities such as these can be subject to HIPAA’s regulations.
Think about a service like Honeybee. They have to exchange data with a patient or their physician in order to get their drug prescription. As such, that would make them susceptible to this law.
It’s not just direct partners you have to think about either. Tracking technologies can be responsible for HIPAA violations as this post about the Meta Pixel tracking code explains.
As with user data protections, it’s not just one part of the world that’s implementing regulations around it. There are other countries and regions enacting legislation to secure protected health information. So if you’re building apps or sites outside of the U.S., make sure you’re adhering to those local mandates.
Bottom line: When it comes to private health information, you can never be too careful. Even if you’ve added extra security layers at every level and you’ve checked and double-checked the HIPAA compliance of the organization’s partners, sometimes a line of code or tracking pixel can put you in violation of the law.
Health Breach Notification Rule
Health data protections don’t end with HIPAA. The FTC has put something in place called the Health Breach Notification Rule.
This rule impacts anyone not covered by HIPAA. So if your product handles personal health information that doesn’t identify who the patient is, then you’d be subject to this one.
For example, HIPAA would go into effect if something like a dermatologist office’s patient portal had been hacked, and information about a patient’s unique medical condition was accessed. The Health Breach Notification Rule, on the other hand, would go into effect if your fitness facility app were hacked and information about the customer’s heart rate and BMI were accessed.
If you’re developing apps that collect this type of personal health information or sync with other devices or apps that do (like a fitness tracker app), then this is something you’ll have to think about as you design your products.
PCI DSS
In 2004, we got the Payment Card Industry Data Security Standard (PCI DSS). This standard refers to a list of 12 security standards related to the processing of credit cards and the protection of cardholder data.
These requirements are as follows:
If a business accepts, transmits, processes or stores credit card data, they are subject to these standards. Failure to comply can result in heavy fines.
That said, there is no law governing PCI DSS. Credit card companies and payment processors are responsible for maintaining compliance. However, there are very good reasons why you’ll want to ensure that your digital products stay on the right side of these security standards.
If your website gets hacked or a disgruntled employee steals customer card information, for example, your company will be on the line for the data breach and monetary loss. Not only that, but the damage to your reputation will be hard to repair.
Implementing the security standards above is critical. So too will be choosing an online payment processor that is PCI DSS compliant.
The Safeguards Rule
Similar to how the FTC stepped in and added extra health security protections, they’ve done the same here with the Safeguards Rule. This rule aims to protect private personal information that financial institutions collect from customers.
While PCI compliance applies to anyone accepting credit cards as a form of payment, the Safeguards Rule applies to financial institutions and related entities. If you’re building digital products for anyone in these spaces, this is a regulation you’ll have to be mindful of.
This includes institutions like:
This particular rule also requires companies to develop an information security program with the proper safeguards in place.
SOC 2
Last but not least, we have Service Organization Control (SOC) 2. SOC 2 isn’t a law. It’s an auditing procedure that ensures that SaaS providers meet the minimal security requirements set forth by the AICPA.
This regulation can impact you in a couple of ways.
As a software user, you’ll want to ensure that you’re using SOC 2–compliant SaaS providers. While that might not be a big deal for an app where you’re managing something like internal tasks, it will be a very big deal for an app where you store customer data—like your CRM, contract software or even your email provider.
It will also impact you if you’re developing cloud-based software for an organization. If your product isn’t SOC 2 compliant, it could end up causing tons of issues. First, the organization won’t be able to claim that it’s compliant with a critical regulation like SOC. Secondly, it could put your users’ own operations at risk if they end up mishandling their customers’ data as a result of the vulnerable software.
So if this particular regulation is relevant to you, there are five criteria to address:
You’re likely planning to prioritize all of this stuff already. Stuff like adding a firewall, implementing DDoS detection, creating a disaster recovery plan, using 2FA, enforcing encryption, etc.
That said, SOC 2 is an auditing procedure, not a regulation. So if you haven’t already built a security and performance checklist for your software design workflow, now is the time to do it. This will ensure that every SaaS product you build is SOC 2–compliant and ready for certification.
When starting a new project, ask yourself the following:
Use those answers to add relevant privacy and security measures to your design workflow and checklists.
I’d also suggest doing research into this. While I’ve covered the most common types of regulatory compliance that affect digital product design, there might be additional local or industry regulations that haven’t received as much fanfare but are just as serious. You’ll want to have as many bases covered as possible to keep your clients’ products safe to use and their users’ data well-protected.
Continue reading...
With so much of our lives taking place online, the job of a web designer has grown extremely complex. Not only are you tasked with turning a brand’s vision into a workable and successful digital product, but you have to build enjoyable, frictionless experiences for their users.
It’s not just a brand’s list of requirements or web standards that you have to design around either. With more transactions taking place online, consumers are rightly more concerned over their data privacy and security.
As such, it’s now become a designer’s job to understand what types of regulatory compliance affect the products they build.
Because there are a lot of policies and legislation floating around—and it differs based on locale as well as industry—this post will serve as a basic resource for web designers. If you’re wondering how to make your digital products compliant, keep reading to learn about the most prominent regulations impacting the work you do.
Regulatory Compliance for Digital Product Design
It might seem like an impossible feat—to build a digital product that complies with every law, policy or regulation that dictates how it should handle users’ info.
The trick is to narrow down the list to the most relevant regulations. So what I’ve done below is break out the most common types of regulatory compliance:
- User data protections (on the local level)
- Private health information privacy
- Financial data security
- Software integrity and security
It’s a good idea to review each of them just so you’re acquainted with what’s happening in the world of regulatory compliance.
User Data Protections
GDPR
In 2018, the General Data Protection Regulation (GDPR) rocked the internet. Its aim was and is to protect EU citizens’ data.
Initially, there were people saying, “Hold up. This regulation only covers EU citizens. So what’s the big deal?”
While the regulation protects EU citizens, anyone collecting data on them is accountable to this law. This applies to everyone—from California-based ecommerce websites selling goods to bloggers in Melbourne who have newsletter subscription forms on their sites.
The GDPR revolves around seven principles:
- Consumers should be aware that their personal data is being collected.
- There should be a legitimate reason to collect the data.
- Only the most necessary bits of data should be collected and nothing more.
- Anyone storing consumer data must keep it up to date.
- Data can only be stored for as long as you need it.
- All captured data must be properly encrypted for security and confidentiality.
- The party collecting the data must have a way to prove their compliance with GDPR.
Another important piece of this regulation is consent. Your digital product is free to collect data following the seven guiding principles only once you’ve obtained consent from the user. And if you plan to do anything with it besides hold onto it for administrative or billing purposes, you need to gain their consent again (like to share it with a third party).
Cookie consent notices help with the superficial adherence to the regulation. However, you really should be thinking more about how your product is collecting, storing and securing your users’ data. Penalties for violating GDPR are steep.
The EU isn’t the only region with personal data privacy regulations. SecurityScorecard has a list of 16 countries with similar laws.
CCPA
Although the U.S. doesn’t currently have any such laws in place, the state of California does.
The California Consumer Privacy Act (CCPA) provides protections for California consumers. Specifically, it gives consumers:
- The right to online privacy
- The ability to control which parts of their personal information is collected
- The ability to request that their data be deleted
- The ability to request a copy of the data that’s been collected on them
- The chance to opt-out of the sale of their data to other parties
This law affects for-profit organizations who primarily serve California citizens and who generate a gross annual revenue of $25 million. So, unlike GDPR which has far-reaching effects on most people doing business online, CCPA mainly affects enterprises in and around the state of CA.
Private Health Info Privacy
HIPAA
It’s not just consumers’ personal information that needs protecting online. Regulations are in place to protect their private medical information as well.
In the United States, Health Insurance Portability and Accountability Act (HIPAA) has been around since 1996. It doesn’t strictly apply to online data protections though. It safeguards the privacy of patients—specifically, data that is classified as protected health information (PHI).
The act gives patients the ability to determine who can see and use their PHI. This applies to oral, written, as well as electronic forms of their data.
Although HIPAA primarily applies to medical providers and insurance companies that deal in patient data on a regular basis, business associates are impacted by this law as well. So even if you’re not building a website, app or patient portal for, say, a hospital, physician’s office or health insurance carrier, organizations that partner with medical entities such as these can be subject to HIPAA’s regulations.
Think about a service like Honeybee. They have to exchange data with a patient or their physician in order to get their drug prescription. As such, that would make them susceptible to this law.
It’s not just direct partners you have to think about either. Tracking technologies can be responsible for HIPAA violations as this post about the Meta Pixel tracking code explains.
As with user data protections, it’s not just one part of the world that’s implementing regulations around it. There are other countries and regions enacting legislation to secure protected health information. So if you’re building apps or sites outside of the U.S., make sure you’re adhering to those local mandates.
Bottom line: When it comes to private health information, you can never be too careful. Even if you’ve added extra security layers at every level and you’ve checked and double-checked the HIPAA compliance of the organization’s partners, sometimes a line of code or tracking pixel can put you in violation of the law.
Health Breach Notification Rule
Health data protections don’t end with HIPAA. The FTC has put something in place called the Health Breach Notification Rule.
This rule impacts anyone not covered by HIPAA. So if your product handles personal health information that doesn’t identify who the patient is, then you’d be subject to this one.
For example, HIPAA would go into effect if something like a dermatologist office’s patient portal had been hacked, and information about a patient’s unique medical condition was accessed. The Health Breach Notification Rule, on the other hand, would go into effect if your fitness facility app were hacked and information about the customer’s heart rate and BMI were accessed.
If you’re developing apps that collect this type of personal health information or sync with other devices or apps that do (like a fitness tracker app), then this is something you’ll have to think about as you design your products.
Financial Data Security
PCI DSS
In 2004, we got the Payment Card Industry Data Security Standard (PCI DSS). This standard refers to a list of 12 security standards related to the processing of credit cards and the protection of cardholder data.
These requirements are as follows:
- Have security systems in place.
- Implement a firewall.
- Use antivirus software.
- Regularly manage and change passwords connected to your product.
- Assign user IDs to everyone with access to your system.
- Secure stored cardholder data.
- Encrypt cardholder data that you transmit.
- Restrict cardholder data to those who must have access to it.
- Keep physical access to card data heavily restricted and monitored.
- Track every person who’s accessed cardholder data.
- Perform vulnerability scans, monitor for breaches regularly, etc.
- Write and maintain an information security policy for your organization.
If a business accepts, transmits, processes or stores credit card data, they are subject to these standards. Failure to comply can result in heavy fines.
That said, there is no law governing PCI DSS. Credit card companies and payment processors are responsible for maintaining compliance. However, there are very good reasons why you’ll want to ensure that your digital products stay on the right side of these security standards.
If your website gets hacked or a disgruntled employee steals customer card information, for example, your company will be on the line for the data breach and monetary loss. Not only that, but the damage to your reputation will be hard to repair.
Implementing the security standards above is critical. So too will be choosing an online payment processor that is PCI DSS compliant.
The Safeguards Rule
Similar to how the FTC stepped in and added extra health security protections, they’ve done the same here with the Safeguards Rule. This rule aims to protect private personal information that financial institutions collect from customers.
While PCI compliance applies to anyone accepting credit cards as a form of payment, the Safeguards Rule applies to financial institutions and related entities. If you’re building digital products for anyone in these spaces, this is a regulation you’ll have to be mindful of.
This includes institutions like:
- Banks
- Financial services or fintech
- Mortgage companies
- Financial advisors
- Tax prep software
- Credit unions
- Collection agencies
- Wire transfer services
This particular rule also requires companies to develop an information security program with the proper safeguards in place.
Software Integrity & Security
SOC 2
Last but not least, we have Service Organization Control (SOC) 2. SOC 2 isn’t a law. It’s an auditing procedure that ensures that SaaS providers meet the minimal security requirements set forth by the AICPA.
This regulation can impact you in a couple of ways.
As a software user, you’ll want to ensure that you’re using SOC 2–compliant SaaS providers. While that might not be a big deal for an app where you’re managing something like internal tasks, it will be a very big deal for an app where you store customer data—like your CRM, contract software or even your email provider.
It will also impact you if you’re developing cloud-based software for an organization. If your product isn’t SOC 2 compliant, it could end up causing tons of issues. First, the organization won’t be able to claim that it’s compliant with a critical regulation like SOC. Secondly, it could put your users’ own operations at risk if they end up mishandling their customers’ data as a result of the vulnerable software.
So if this particular regulation is relevant to you, there are five criteria to address:
- Security
- Availability
- Processing integrity
- Confidentiality
- Privacy
You’re likely planning to prioritize all of this stuff already. Stuff like adding a firewall, implementing DDoS detection, creating a disaster recovery plan, using 2FA, enforcing encryption, etc.
That said, SOC 2 is an auditing procedure, not a regulation. So if you haven’t already built a security and performance checklist for your software design workflow, now is the time to do it. This will ensure that every SaaS product you build is SOC 2–compliant and ready for certification.
Wrap-up
When starting a new project, ask yourself the following:
- Does your product have to collect data?
- If so, what type?
- Is any of it considered sensitive or private?
- Which regulations pertain to this type of data transmission, storage or sharing?
- What sort of measures do you need to implement to properly secure it?
Use those answers to add relevant privacy and security measures to your design workflow and checklists.
I’d also suggest doing research into this. While I’ve covered the most common types of regulatory compliance that affect digital product design, there might be additional local or industry regulations that haven’t received as much fanfare but are just as serious. You’ll want to have as many bases covered as possible to keep your clients’ products safe to use and their users’ data well-protected.
Continue reading...