When it comes to data security and privacy, in context of a virtual world, we are faced with an uncomfortable situation to choose from a variety of compliance frameworks – ISMS, ISO, GDPR, SOC 2 Type 2, HIPAA just to name a few. SaaS data security and privacy is no different.

While all of these are targeted towards one single goal of “data security & maintaining the privacy of the user”, not all of them are applicable for all types of organizations/companies. Some are important for service-based industries, some for SAAS based cloud product/services, while some for healthcare and some for organizations working with data from EU or storing data of users from EU.

Since, I have worked with SAAS products and platforms for more than a one and half decade, and have had the experience of driving compliance for these organizations, I would touch upon three key data security and privacy compliance that have become industry standards today – GDPR, SOC 2 Type 2 and HIPAA.

At SmartKarrot, we regard the privacy and security of our clients’ personal & business data as sacrosanct for our progress. Every member of SmartKarrot team, right from the founders to the bottom of the pyramid truly believe that ensuring our clients’ data security & privacy is our fundamental responsibility. With that being said, we are happy to announce that we have achieved one key security and privacy milestones – GDPR and are truly on our way to achieve SOC 2 Type 2 compliance as well by mid-2020.

This article highlights the key aspects and requirements of SOC2, GDPR and HIPAA

Service Organization Control (SOC) 2 Type 2:  

Prior to SOC 2 Type 2, the standard of auditing service organizations was SAS 70 (Statement of Auditing Standards No. 70). These audits were performed by Certified Public Accountant (CPAs) with the original intent to report on the effectiveness of internal financial controls. But overtime, this started to be used as a way to report on the effectiveness of internal financial controls. But somewhere around 2010, SOC 1 and SOC 2 reports were introduced by AICPA with the explicit purpose of addressing the growing need of companies (especially operating out of cloud infrastructure) to externally validate and communicate their state of security.

SOC 2 Type II reports are the most comprehensive certification within the Systems and Organization Controls protocol. Businesses seeking a vendor such as an I.T. services provider will find SOC 2 Type II is the most useful certification when considering a possible service provider’s credentials.

There is one common misconception across the industry that SOC is a certification, and to that extent a SOC auditor at the end of the audit certifies an organization control protocols. SOC 2 Type 1 / SOC 2 Type 2 is not a certification-based compliance, but it is a framework for an auditor to audit an organization control protocols. Hence at the end of the audit, the auditor hands over an audit report known as “SOC Attestation Report” to the organization and ranks the organization across all key points noted in SOC compliance by AICPA.

A business entity shares this attestation report with its existing customer as a confidence building measure as well as passes this on to new customers that are signing up with the business entity. Based on the report, the security office for the customers’ company can ask for additional policy and procedure documentations.

SOC is based on these 5 criteria’s which it calls as Trust Service Criteria.

Security
Availability
Processing
Integrity
Confidentiality
Privacy 

GDPR (General Data Protection Regulation) 

The GDPR (General Data Protection Regulation) was adopted by the European Parliament and the Council on the 27th of April 2016 and comes into force on the 25th of May 2018. This is the latest privacy and data protection legislation of the European Union (EU).

GDPR has implications for all companies no matter their size. A lot of smaller companies don’t even realize they are impacted, which is a dangerous situation to be in, because they could be subject to substantial or even crippling fines.

GDPR creates many new rights for individuals and new obligations for those who process personal data. It also defines what ‘processing’ of personal data means – any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means. Such operations include, among others, collection, recording, organization, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction of personal data. To put it simply – processing includes everything that is done with personal data by an organization.

Pivotal Point in GDPR

GDPR being a set of legislation set by the EU defines personal data broadly and put the individual at the center of data protection. It gives every individual resident of EU, the right to know and decide how his or her personal data will be stored, processed, transferred and deleted. 

With the above stated point as the most important aspect of GDPR, organizations are required to make full review of their practices regarding collection, use and protection of potentially huge amount of data.  

Global reach – who does GDPR affect?

The new European data protection law applies to the processing of personal data of data subjects (natural persons) who are in the Union by any public or private organization (or a single natural person) not established in the Union. In this case though, the processing activities must be related to either:

1. the offering of goods or services, irrespective of whether a payment from the individual is required; or
2. the monitoring of their behavior as far as their behavior takes place within the Union.

This means, for example, that if a US or Asia based company wants to conduct e-commerce in the EU (for which it needs to process some personal data such as name, shipping address, bank information, etc.), the GDPR applies to it. Furthermore, it applies also if no payment is involved at all, as with Facebook and most of Google’s services.

GDPR Implications for SaaS

Under the previous data protection directive, TalkTalk was found guilty of security failings in 2016 that gave hackers access to customer data. The company was then given a 450,000 euro fine. Pharmacy2U was found responsible for a similar failure, and they had to pay a 150,000 euro fine. But these fines are a fraction of what the GDPR fines will add up to. The NCC Group recently found that if the GDPR had been in place when TalkTalk was fined, they would have paid over 65 million euros. Pharmacy2U would like to have been fined around 5 million euros. In general, the existing fines will be 79 times higher under GDPR.

The above data begs the question, how do SaaS companies become GDPR compliant?

Under the GDPR, both SaaS customers (i.e., data controllers) and vendors (i.e., data processors) have new duties that they are responsible for. SaaS vendors’ primary obligation will be to guarantee that all customer product agreements are in compliance. This means that the agreement should state:

1. Customer rights, requirements, and responsibilities.
2. The type of data being processed.
3. The duration, purpose, and nature of the data processing.
4. Whether an instruction of providing personal data to the customer breaches the GDPR or other data regulation laws.
5. A clarification that the customer must give recorded instructions in order for personal data to be processed.
6. How they will help the customer to comply with their duties to the GDPR.

Additionally, from the vendors’ side:

1. The SaaS supplier or customer must implement safeguards to make personal data transfers outside of the European Economic Area.
2. Customers may have their data returned or deleted if mandatory laws don’t require storage.
3. Suppliers are required to report obligation breaches to customers.
4. In short, SaaS vendors will need to make significant updates to their procedures, internal policies, and product agreements.

What is a GDPR breach notification?

GDPR sets out a duty for all organizations to report certain types of data breaches which involve unauthorized access to or loss of personal data to the relevant supervisory authority. In some cases, organizations must also inform individuals affected by the breach and set up an integrated data protection solution.

Organizations are obliged to report any breaches which are likely to result in a risk to the rights and freedoms of individuals and lead to discrimination, damage to reputation, financial loss, loss of confidentiality, or any other economic or social disadvantage.

What comes next for GDPR and data protection?

Countries and regions around the world appear to be taking cues from GDPR by introducing or modifying data protection legislation. Countries which have signaled they’ll change their privacy laws since the introduction of GDPR include Brazil, Japan, South Korea, India and others. 

Silicon Valley, California, is also set to introduce its own data privacy laws in the California Consumer Privacy Act, which comes into force as of 1st January 2020.

The legislation follows in the footsteps of GDPR by allowing individuals to have a greater say about how their personal data is used, but in many ways it doesn’t go nearly as far: there’s no set time-limit for notifying consumers about a breach and organizations won’t face fines for non-compliance.

However, the introduction of this legislation into the heat of the technology industry appears to suggest that privacy and consent are issues that could change how Silicon Valley operates.

HIPAA Compliance

The Standards for Privacy of Individually Identifiable Health Information (Privacy Rule) sets forth, for the first time, a set of national standards for the protection of certain health information. The U.S. Department of Health and Human Services (HHS) issued the HIPAA Privacy Rule to implement the requirement of the Health Insurance Portability and Accountability Act of 1996 (HIPAA).

The HIPAA Privacy Rule addresses the use and disclosure of individuals’ health information called “Protected Health Information (PHI)”.   The HIPAA Privacy Rule is to assure that an individual’s health information is properly protected while allowing the individual’s necessary health information that is needed to provide and promote quality health care, is protected. The HIPAA Privacy Rule permits important uses of information, while protecting the privacy of people who seek healthcare. 

The HIPAA Privacy Rule is designed to be flexible and comprehensive to cover the variety of uses and disclosures that need to be addressed. Covered entities regulated by the Rule are required to comply with all of its applicable HIPAA requirements.

The Privacy Rule applies to health plans, healthcare clearinghouses, and to any health care provider who transmits health information in any form in connection with transactions for which the Secretary of HHS has adopted standards under HIPAA (the “covered entities”).

HIPAA SECURITY

The Security Rule requires covered entities to maintain reasonable and appropriate administrative, technical, and physical safeguards for protecting e-PHI. The Security Rule defines confidentiality to mean that e-PHI is not available or disclosed to unauthorized persons. The Security Rule’s confidentiality HIPAA requirements support the Privacy Rule’s prohibitions against improper uses and disclosures of PHI. Under the Security Rule, integrity means that e-PHI is not altered or destroyed in an unauthorized manner. Availability means that e-PHI is accessible and usable on demand by an authorized person.5

HHS recognizes that covered entities range from the smallest provider to the largest, so the Security Rule is flexible and scalable to allow covered entities to analyze their own needs and implement solutions appropriate for their specific environments.
When a covered entity is deciding which security measures to use, the Rule does not dictate those measures but requires the covered entity to consider:

1. Its size, complexity, and capabilities
2. Its technical, hardware, and software infrastructure
3. The costs of security measures
4. The likelihood and possible impact of potential risks to e-PHI.

Covered entities must review and modify their security policies to continue protecting e-PHI in their ever changing environment.7

HIPAA Risk Analysis and Management

The Administrative Safeguards provisions in the Security Rule require covered entities to perform risk analysis as part of their security management processes. The risk analysis and management provisions of the Security Rule are addressed separately here because, by helping to determine which security measures are reasonable and appropriate for a particular covered entity, risk analysis affects the implementation of all of the safeguards contained in the Security Rule.

A risk analysis process includes, but is not limited to, the following activities:

1. Evaluate the likelihood and impact of potential risks to e-PHI;
2. Implement appropriate security measures to address the risks identified in the risk analysis;
3. Document the chosen security measures and, where required, the rationale for adopting those measures;
4. Maintain continuous, reasonable, and appropriate security protections.

Risk analysis should be an ongoing process, in which a covered entity regularly reviews its records to track access to e-PHI and detect security incidents, periodically evaluates the effectiveness of security measures put in place, and regularly reevaluates potential risks to e-PHI.

Administrative Safeguards

Security Management Process: A covered entity must identify and analyze potential risks to e-PHI, and it must implement security measures that reduce risks and vulnerabilities to a reasonable and appropriate level.
Security Personnel: A covered entity must designate a security official who is responsible for developing and implementing its security policies and procedures.
Information Access Management: The Security Rule requires a covered entity to implement policies and procedures for authorizing access to e-PHI only when such access is appropriate based on the user or recipient’s role (role-based access). Workforce Training and Management: A covered entity must provide for appropriate authorization and supervision of workforce members who work with e-PHI. A covered entity must train all workforce members regarding its security policies and procedures, and must have and apply appropriate sanctions against workforce members who violate its policies and procedures.
Evaluation:  A covered entity must perform a periodic assessment of how well its security policies and procedures meet the HIPAA requirements of the Security Rule.

Physical Safeguards

Facility Access and Control: A covered entity must limit physical access to its facilities while ensuring that authorized access is allowed.
Workstation and Device Security: A covered entity also must have in place policies and procedures regarding the transfer, removal, disposal, and re-use of electronic media, to ensure appropriate protection of electronic protected health information (e-PHI).

Technical Safeguards

Access Control: A covered entity must implement technical policies and procedures that allow only authorized persons to access electronic protected health information (e-PHI).
Audit Controls: A covered entity must implement hardware, software, and/or procedural mechanisms to record and examine access and other activity in information systems that contain or use e-PHI.
Integrity Controls: A covered entity must implement policies and procedures to ensure that it is compliant by the federal requirements, which means that the federal requirements will apply unless the state law is more stringent.

Compliance Dates

Compliance Schedule: All covered entities, except “small health plans,” must have been compliant with the Security Rule.

Industry compliance and regulations are very helpful in ensuring quality, security and privacy. This empowers the systems and brings confidence in the technology community to be able to design and build systems that can carry complex and high potential transactions leading to high value to end users. Systems today are so powerful, efficient to be able to not only change technology landscape but business landscape as well. 

Concluding Thoughts

In this blog, we have addressed the topics of SaaS data security and subscription model software privacy. In addition, we’ve gone out of our way to thoroughly clarify the differences between GDPR, SOC2, and HIPAA by presenting all the fine print. In addition to these three laws, you should take the time in understanding the CPRA. It will aid in protecting the legal rights of B2B SaaS users operating in California.

---