Data privacy regulations 101

Data privacy is obviously very important. With large companies gather huge amount of data of it’s users and with the great advancement on data mining and data analytics technologies data privacy has become one of the biggest concerns for all consumers. If you are not that concerned about this, you should be, here’s a quick read to get your concern raised - a quick survey of what data FB or google already has about you.

This concern is reflected by the various regulatory bodies and governments stepping up their regulations about what companies can do with the data, how they can share it and how they have protect it.

The problem is that the online world has not autocracy! And in those rare cases in this world where autocracies are great this is one place all software creators wish there was one single autocratic power giving out a single set of rules to abide by :) Sadly that’s not the case and a software developer that wants to serve customers around the world (i.e. every software company in the world) now has to understand a plethora of data privacy rules and regulations, create interfaces for seeking consent, show text for displaying warnings, create processes for managing the security and the privacy. This is why every website we visit today has a confusing range of popups, highlights, texts, footers and headers asking us to accept this or decline that or warn us that we will lose our soul if we don’t do this or that. In general, all this chaos has just created a fatigue in the consumers who just click accept where ever they see it just to get to the page. But that is another story.

Today’s post is for the software developers and software founders who wants to get a quick overview of where things stand now and how to navigate in this jungle.

HIPAA

The Health Insurance Portability and Accountability Act (HIPAA) is a Privacy, Security, and Breach Notification Rules protect the privacy and security of health information and provide individuals with certain rights to their health information.

If your software has anything to do with healthcare, medical services even pharmaceuticals and drugs you should be concerned about HIPPA compliance. It’s a US standard but complying with this basically ensures that you comply with any of the national rules you are likely to encounter in other countries.

Software developers play a vital role in protecting the privacy and security of patient information that comes in through thousands of software systems and interfaces in an increasingly digitalized healthcare world.

At its core HIPAA is pretty simple and based on the following 3 parts:

• Privacy

  This deals with protection, authorization and access. It sets rules for when and how any personal health information can be disclosed and used. It also gives users the ownership of their health records, the right to access them and request modifications as needed.

  So any system you develop needs to have the flexibility and security built on top of the data store.

• Security

  This is the obvious section on the standards for the security of technology used to access, store, transmit, or process any personal health information. This part is the big thing that you as the software developer need to focus on. Certain implementation specifications are either required, meaning that its mandatory to build them in your software, and some are addressable. Addressable are ones in which either you need to 1) implement the specifics as written, OR 2) implement an alternative solution, OR 3) not implement anything for that specific requirements because it is not reasonable or necessary to do so. As with most things in HIPAA, the important thing is that decisions related to addressable specifications are documented.

• Simplified Process

  This part relates to the accepted coding for data exchanged in healthcare. The transactions this applies to are financial related (claims, eligibility, enrollment, etc). To comply with this part you have to make it administratively easier to exchange data by not having to keep track of an endless number of code sets. (What’s a code set?)

GLBA

The Gramm-Leach-Bliley Act (GLBA) is a US law for control on personal financial data managed by financial institutions, and how these institutions deal with a consumer’s non-public personal information (NPI). There is a lot of very private personal financial data that organizations like banks, insurance companies etc. collect when providing a financial product or service and GLBA is the overarching rule that gives users protection on the use of that data.

If you have anything to do with a fintech app or any platform that is used by a bank or an insurance company it’s very likely you’d need to know about GLBA and comply with the it’s guidance.

From a bird’s eye level GLBA has three main parts:

• Privacy Rule

  This regulates the collection and use of NPI. This is the part you as the software developer need to focus the most. It’s pretty comprehensive and there are lots and lots of issues that you have address in this area - so you’ll need to spend time in getting to know the rules. Wikipedia article on the privacy rule does a good job in getting you a quick background.

• The Safeguards Rule

  This part requires financial institutions to implement a security program to protect NPI. So this more on the side of the institutions and their network but doesn’t stop just at physical security so intelligent monitoring of data and transactions is something software developers will probably need to integrate with other solutions within the infrastructure.

• Pretexting provisions

  This prohibits access to NPI under false pretense and is more of a legal concern for the organization and it’s workflow processes. As a software developer you will need to ensure access control and several layers of authorization and monitoring of access.

COPPA

Children's Online Privacy Protection Act (COPPA) is a set of rules that prohibits online software such as websites, apps and games from collecting personal information from children without first providing notice to parents and obtaining their consent. The rule also provides parents with the right to find out about stored data collected from or about their children, and to refuse further data collection and use.

If you are building any software that is primarily directed towards children then you need to be aware about COPPA. Although a US rule it is a rule that was used by most national rules to create their own children protection acts. COPPA is super important for game developers particularly for mobile games - as any failure may lead to a permanent ban from platforms such as apple appstore or google play. Here’s a great primar for game developers

If you didn’t know the story, a recent example where COPPA non compliance led to a big fine was Tiktok, which was fined $5,700,000 in February 2020

Here’s a bird’s eye view of different parts of COPPA you need to be aware of:

• Privacy Policy

  You need a clear and detailed privacy policy and it must be linked clearly on highly visible location within your application, especially where personal information is collected. The privacy policy need to include all information you collect from children, details about how such which the information is used, and whether it is shared with any third parties. You must also reveal the names and addresses of the owners of the software so that may be contacted by parents.

• Parent Opt in

  You need to provide parents of the child user with a message and obtain their consent before using personal information of their child. You need to tell parents that you collected information about their children, describe the information, explain what manner it may be disclosed, and that parental consent is required to do so, and also provide a link to your privacy policy, provide a way to give consent, and let them know you will delete their information if you do not receive their consent.

• Disclosure to Third Parties

  If any information collected by the software will be disclosed to others, you will need to provide a stronger method for consent, such as a signed form, or a contact number. After giving consent, parents must have access to the data for reviewing and deleting their child’s information.

SOX

Sarbanes-Oxley Act (SOX) is a set of regulations that sets the compliance needs and deadlines for public companies. SOX came out necessity when corporate America was broiled with scandals from giants like Enron, WorldCom, and Tyco. The regulation protects the general public and shareholders from accounting errors, fraud in enterprises, and it helps to improve the accuracy of corporate disclosures.

SOX is a big responsibility for public companies but for software developers there is a need to understand the basics so that the systems they build and more importantly the process they follow comply with SOX. If you are employed by a public company in US you should be aware of SOX and as with the other regulations complying with SOX probably means you comply with other national rules modelled around SOX. One of the most important thing for software developers for this regulation is that a software developer should not have any kind of write access to production systems that can affect the financial reporting of the corporation. This is not always easy to comply with and you require a proper process which separates roles of development from system administration to achieve this.

Remember SOX precludes software developers from administrating of systems they write.

Here are some of the main areas of SOX that you should know about:

• Responsibility

  Top management is directly responsible for the accuracy, documentation, and submission of all financial reports. CEOs and CFOs risk imprisonment and penalties for failures. Phew… it’s all on the bosses here unless you are one of them :)

• Internal Control

  Adequate internal control structure for their financial records. Any shortcomings must be reported up the chain as quickly as possible for transparency. As a software project lead your responsibility will be to identify lapses or possible gaps in the reporting structure for software failure.

• Data security policies

  Policies for data security and consistent enforcement of those policies is the key requirement. Companies need to develop and implement a comprehensive data security strategy.

• Independent Audit

  Companies need to maintain and provide documentation proving they are compliant and that they are continuously monitoring and measuring compliance for independent audit. This is where the software developers get involved a lot, as they are the ones that have to build audit logs, configurations, versioned histories of data, etc. required to comply.

GDPR

This is the big one, specially because of wide adoption and the fact that it’s recent. The General Data Protection Regulation (GDPR), agreed upon by the European Parliament is a European Union law that creates new rules for companies that offer goods and services to or that collect and analyze data tied to citizens of the European Union.

As EU citizens are a sizable portion of any application available online (which is every app out there) you as a software developer will need to comply with this rule. It’s pretty detailed and has all sorts of side rules to satisfy the multiple national rules within EU. As a developer you probably don’t need to know all the details to it’s fullest but here are some that you should be concerned with.

• Consent

  GDPR requires that all software you write seeks consent from the user before collecting any information. An explicit consent by statement or action signifying agreement to the processing of their personal data needs to be clearly laid out to the users. Remember that data here is wide enough to cover even cookies (and hence all those “accept cookies” forms we see these days).
  
  

• Access control

  This gives the right to the user to have access to the data that is stored in any organization. As a developer this has the huge implication of making it flexible to access data even historical ones when the user requires it.
  
  

• Data Portability

  This requires the organization in control of the data to provide the data in a format that allows for easy use with another controller. As a developer this boils down to following standard data exchange formats

• Right to be Forgotten

  This entitles the users to have the a company erase his/her personal data, cease further dissemination of the data, and potentially have third parties cease processing of the data. And for the software developer this means creating interfaces and technology that makes this possible. One huge concern for the software people in this space is that a delete essentially mean a full delete from everywhere - including historical files, backups, shadow copies, the full works.
  
  

CCPA

This is the new kid on the block and as such is becoming the new thing that every software developer is getting worried about.

California Consumer Privacy Act. (CCPA) went into effect on January 1, 2020, with a six-month grace period for companies, giving them time to comply. If a company doesn’t comply, Californians can file private lawsuits pursuing civil penalties for violations. And as California owns the software world every software company in the world are reading CCPA carefully!

For software developers the good news is that if you are covering GDPR many of the issues on CCPA is also covered, although not perfectly. So you’ll still need to double check. Here’s a great article that compares these two: GDPR vs. CCPA here’s a screen grab from there comparing them: