The Privacy Tech Directory serves two purposes: 

1. it empowers users to enhance their privacy and
2. provides a list of tools that can help to maintain compliance with relevant data protection laws. 

It offers a large selection of tools categorized meticulously to address different aspects of privacy and security.

It should be noted that the directory is not an exhaustive list but rather an initial stepping point to figure out what services and/or products are available to help with your specific privacy or security concern.

Here’s a detailed look at the categories available:

Features of the Privacy Tech Directory 

The tools are divided into the following categories: 

• Consent Management Platforms: Manage user consent and ensure compliance with the GDPR and other regulations.
• Access Control: Implement secure access controls to protect sensitive information.
• Analytics: Use privacy-focused analytics tools to gather insights without compromising user data.
• File Management: Secure file storage and sharing solutions to protect data integrity.
• Privacy Alternatives: Discover privacy-respecting alternatives to mainstream services.
• AI: Leverage AI tools designed with privacy in mind.
• Forms: Create and manage forms that prioritize user data protection.
• Fonts: Use fonts that respect user privacy.
• Encryption: Employ encryption tools to secure data in transit and at rest.
• Bookmarking: Find privacy-focused bookmarking tools.
• Advertising: Access advertising tools that prioritize user privacy.
• Compliance/Risk Management: Simplify compliance and risk management processes.
• DPO-as-a-Service: Utilize data protection officer services for expert guidance.

The diversity of tools underscores multiple ways technology intersects with privacy, and seeks to highlight the necessity of preserving privacy on various fronts.

The Creation and Evolution of the Privacy Tech Directory 

The Privacy Tech Directory was crafted through independent research and the innovative use of generative AI. Should any inaccuracies be found in the tool descriptions, users are encouraged to contact TechGDPR at privacydirectory@techgdpr.com to correct the information. The directory aggregates information from various sources, including Privacy Guides, Web3 Privacy on GitHub, and the IAPP privacy vendor directory, alongside independent research efforts.

The directory attempts to highlight open source and free tools. There is a landing page to navigate all of the tools with the following options presented.

This database is located on our Privacy Tech Directory landing page. It allows for users to search the database directly by Name, Format, Category or even words that appear in Short Description such as for example: “GDPR.”

For each tool described in the directory, we strive to include the: 

• Name
• Short description (AI generated)
• Format category (Is this tool for developers (low level code)? Is it a working software or application?)
• Long descriptions (AI generated)
• URL / Github
• Languages supported
• Whether the tool is free or not, if the tool is not free, the cost is included if it could be discerned from the website
• Open Source (if applicable)
  • Link Github/open source (if applicable)

If you have new tools to add or wish to feature or remove a tool from the Privacy Tech Directory, please reach out to TechGDPR at privacydirectory@techgdpr.com.

Conclusion

The Privacy Tech Directory by TechGDPR is a resource for anyone interested in data protection and privacy compliance. The directory is a curated collection of tools to enhance security, streamline compliance, and maintain transparency. 

For any requests and issue reporting, contact TechGDPR at privacydirectory@techgdpr.com.

The post Introducing the Privacy Tech Directory: A Tool for Data Protection and Compliance appeared first on TechGDPR.

Data localization is the practice of storing and processing data within a set geographical space. This is different than data residency which is often used interchangeably with data localization; however, it is slightly different. Data residency refers to the actual location of the servers and other infrastructure used to store and process the data. While data localization includes the concept of data residency, it also incorporates the idea of data sovereignty. Data sovereignty refers to the rights of the legal authority or any entity to exercise control over data within its borders. Data localization is the combination of both data sovereignty and data residency. 

The EU’s General Data Protection Regulation (GDPR) prioritizes strong data protection practices and indirectly favors the storage of personal data within the EU. However, data localization is not a strict legal requirement therein. 

What is required to transfer data outside of the EEA?

The GDPR does specify the need for “appropriate safeguards” for transferring data outside the EU. Articles 44 to 50 of the GDPR detail the requirements for storing and transferring data outside of the EEA, including adequacy decisions, standard contractual clauses, certifications and binding corporate rules as well as when processing activities are exempt from these requirements. 

Standard contractual clauses as described in GDPR Art.46 are legally binding data protection clauses approved by the European Commission. Binding corporate rules (BCRs) as described in GDPR Art.47 internal rules adopted by multinational companies or groups of enterprises for transfers within a group. BCRs serve to ensure all members maintain appropriate levels of GDPR compliance regardless of their locations. If a company decides to rely on BCRs as a transfer mechanism, all its EU-based entities must adhere to the binding corporate rules when transferring data outside the Union. There are also certification mechanisms for transfers; however, these alone are not sufficient for data transfers outside of the EEA. 

An adequacy decision states that a country outside of the EEA provides adequate data protection measures. If an adequacy decision is in place, then no additional data protection safeguards are required. There are currently adequacy decisions with the following countries: Andorra, Argentina, Canada (commercial organizations), Faroe Islands, Guernsey, Israel, Isle of Man, Japan, Jersey, New Zealand, Republic of Korea, Switzerland , the United Kingdom under the GDPR and the LED, the United States (commercial organizations participating in the EU-US Data Privacy Framework) and Uruguay. 

Addressing the US

Many tech companies and third party service providers are located in the U.S. The Schrems II case, in July 2020 invalidated the U.S. Privacy shield, which allowed for U.S.-EU data transfers. This was due to concerns related to data sovereignty. Essentially, the personal data of EU data subjects that was located in the U.S. could be processed and subject to U.S. surveillance, meaning that US laws did not actually provide adequate privacy protection in accordance with the GDPR for EU data subjects. This case made data localization within Europe more common to avoid transfers to the U.S. when possible. 

The GDPR does not mandate data localization, but it outlines strict rules and requirements for processing data outside of the EEA. Storing and processing data of EU data subjects within the EU helps to make compliance with the GDPR easier; however, compliance is not just data localization, data security and minimization are also crucial to consider. 

Understanding Data Practices 

In recent years there has been a growing trend of organizations using third party services such as content distribution networks (CDNs) and cloud storage services. CDNs have become increasingly popular, serving a majority of web traffic, including traffic from major sites like Facebook, Netflix, and Amazon. Server location means where the servers physically are. Large service providers such as Amazon, Google or Cloudflare allow for companies to choose the location of the servers holding the information. While Amazon might be a US entity, information stored in an Amazon server located in Germany for example is subject to German legal requirements on data sovereignty.

In 2021, a report was published revealing that within the calendar year 44% of organizations experienced a data breach, and the majority of these data breaches were due to not properly assessing the risks of third party vendors. Many organizations see the use of third parties as a security risk, but not a high security risk leading to insecure and poor data management practices. It is important to utilize strong security practices such as always sending personal information using TLS and encryption as opposed to directly over HTTP. While location of the third parties utilized is important, arguably it is not as important as the data management practices or security practices implemented by said third parties.

The Global Landscape of Data Privacy and Data Localization

Some countries have stronger data localization laws. In 2017, there were 67 data localization laws; however, by 2021 that number had grown to 144. There is a growing trend towards regulating data localization. The most notable data localization laws effect: China, Brazil, Russia, and India. 

• China has the personal information protection law (PIPL) which has various localization requirements in regards to personal information. It requires companies to store and process data within China’s borders.
• Russia enforces the Federal Law on Personal Data No.152-ФЗ, dated 27 July 2006 (PDL), and updated it in March 2023 to include strict data localization requirements, mandating the maintenance of data within Russia.
• India’s Digital Personal Data Protection (DPDP) Act, 2023, authorizes the Central Government to impose localization restrictions on certain data categories and potentially require storing specific types of personal data within the country.

There are other countries that require data localization, and when processing information about data subjects located in specific countries it is important to be aware of any data localization requirements. Specific industries such as healthcare have regulations that deal with data residency requirements, such as UAE Health Data Law. 

Conclusion

While data localization can facilitate compliance and potentially simplify certain regulatory aspects, based on the GDPR: the ultimate focus must remain on implementing strong, consistent data protection practices. The GDPR prioritizes securing data through comprehensive safeguards, regardless of physical location, and emphasizes mechanisms such as standard contractual clauses, binding corporate rules, and adequacy decisions to ensure protection across borders. There is an increase in a trend towards data localization as more regulations are requiring data residency, and this article does not take into account other possible local regulations. Furthermore, the evolution of global data privacy laws suggests a continuous shift towards balancing data sovereignty with international data flows, underscoring the importance of robust security practices over mere geographic constraints.

Therefore, when asking, “Does server location really matter under GDPR?”; the answer lies in balancing data security and compliance measures, regardless of geographical constraints. TechGDPR can help to better understand how to navigate data privacy regulations and ensure a high level of compliance. 

The post Does Server Location Really Matter Under GDPR? Understanding Data Localization in the Context of Data Protection Compliance appeared first on TechGDPR.

What are HIPAA and the GDPR?

HIPAA refers to the Health Insurance Portability and Accountability Act of 1996. HIPAA was enacted to specifically deal with how medical data are shared and processed. Unlike HIPAA the GDPR regulates any information which can lead to the identification of a living person whether it is health-related or not. The GDPR denotes health data as special categories of personal data, commonly referred to as sensitive data. This means that non-consensual processing of health-related data is strictly prohibited unless the processing purposes are related to medical diagnosing, preventative or occupational medicine, provision and management of health or social care or treatment, in accordance with a contract with a medical professional or based on Union or Member State law. 

The GDPR defines health data as personal data related to the physical or mental health of a natural person, including the provision of health care services, which reveal information about his/her health status (GDPR Art.4). HIPAA denotes protected health information as any data uncovering an agent’s identity in respect to his or her past, future or present physical or mental condition, provision of and payment for the health treatment and services. Both definitions are similar, yet HIPAA also designates financial information of the recipient of the treatment as health data. The GDPR applies to all organizations operating in the EU or offering goods or services to individuals located in the EU territorially no matter of the citizenship. HIPAA, on the other hand, applies to special covered entities within the US, those include healthcare providers, health care clearinghouses and health plan providers.

The key differences between HIPAA and GDPR relevant to MedTech 

The principal difference between the regulations is obviously their scope. As previously stated, the GDPR relates to all organizations processing all types of data relating to a person. Furthermore, the GDPR applies to a much broader range of entities. Even if the company is located in the US (or anywhere in the world) and processes data of subjects located in the EU, it must comply with the GDPR. Contrastingly HIPAA only applies to covered entities located in the US. 

The right to be forgotten is another aspect specific only to the GDPR. It stipulates that under certain conditions, such as the revoking of previously granted consent or when the data is no longer necessary, the data subject may exercise a right to request a free of charge erasure of his or her personal data. If a company relies on third-party cloud storage services, it should ensure that it is able to locate and erase the data when required. The GDPR is also stricter on data breaches, it only grants 72 hours to report a data breach while HIPAA allows for up to 60 days to report a data breach if more than 500 individuals. If less than 500 people are affected, the data breach may be reported by the final day of reporting each year. 

The GDPR also introduced the notion of privacy by design and by default. The concept postulates that when developing new services related to MedTech, or any other sector, involving processing personal data, the company must always consider privacy. HIPAA makes no mention of such a framework for launching new services is present in HIPAA. 

Both regulations are compulsory and impose fines for non-compliance. HIPAA fines are mostly around $25.000 per violation, although in the worst case circumstances a company may be fined of up to $1.5 million per year. GDPR opens the door to potentially much larger maximum fines of up to 4% of the annual worldwide turnover. 

Do HIPAA and GDPR overlap?

There are some similarities and overlap between HIPAA and the GDPR which is good news for companies required to comply with both regulations. Firstly, both include obligations relating to individuals or entities handling data on behalf of covered entities who control the processing of data. Under HIPAA, those are distinguished as business associates and are required to sign a business associate agreement (BAA), this is similar to the data processors under the GDPR.

Secondly, HIPAA, as is the case with the GDPR, requires companies to ensure safeguards are in place to protect the data collected and stored from unauthorised access and disclosure. Article 32 of the GDPR specifically deals with the obligation of minimising risks of a security breach. Appropriate measures include pseudonymisation and encryption of data, maintenance of ‘ongoing confidentiality, integrity, availability and resilience of processing systems and services’ as well as ‘ability to restore availability and access to data in the event of an accident’. The same article prescribes regularly testing, assessing and evaluating the effectiveness of security measures in place. Furthermore, the entity subject of the GDPR shall ensure all personnel processing data on their behalf adheres to the code of conduct prescribed by the legislation and does not process data except on their instructions.

Parallel obligations of the covered entities can be found under HIPAA’s Security Rule. HIPAA also postulates confidentiality, integrity, and availability of protected health information in electronic form (ePHI). Likewise, covered entities must ensure potential security threats, or unlawful uses or disclosures of ePHI, are considered and addressed. HIPAA also obliges the covered entities to ‘ensure compliance of the workforce’. 

Both regulations call for minimisation of data collection and minimisation of data disclosure. Data should be disclosed for research purposes, judicial proceedings, public health interest and if required by law in both legislations.

HIPAA and the GDPR grant data subjects analogous rights. In particular, with a few exceptions, such as access to psychotherapy notes, both regulations grant the data subject the right to access and review a copy of the processed data. Moreover, if the information is inaccurate or incomplete, the data subject has a right to request an amendment of the information.

HIPAA and the GDPR grant data subjects a right to be informed of how and for what purpose their personal data is used and processed, this includes information regarding the recipients or categories of recipient to whom the personal data have been or will be disclosed. The privacy notice must include information on individual rights with respect to their personal information and how those rights may be exercised, and the covered entities obligations as well as the purpose of data usage and processing. Interestingly, both GDPR and HIPAA require the privacy notice to be written in clear and plain language.  

HIPAA and GDPR application

Two global trends may be identified with regards to MedTech and data processing. On one hand, there is an evident explosion of consumer health data. Technological advancement has stimulated vast growths in consumer-generated health data. Those can be put to work through data analytics to extract powerful insights. Secondly, as life expectancy increases and larger sections of the population account for senior citizens, the market boom for healthcare is explained by a demand to further digitise and employ analytics to identify the most cost and health effective treatments and insurance plans. 

Beyond the similarities and differences outlined earlier, there is a fair amount of divergence in how the two frameworks are implemented. Consider an app developer seeking to re-use healthcare data to extract insights. Under the GDPR, this app developer handles a special category of data and this handling is subject to strict safeguards. However, in the US, the same app developer will not be is not a subject HIPAA and the GDPR -provided they do not process personal data from an EU data subject. That is because HIPAA postulates that only covered entities of healthcare providers and insurers or their business associates are subject to the legislation. In other words, medical data that is collected and processed in a hospital will be subject to HIPAA and considered PHI.

If an individual voluntarily provides his or her health information to a mobile app, which is not connected to healthcare activities of a covered entity (i.e. not a business associate of any covered entity), most likely this falls outside of HIPAAs’ jurisdiction but the app developer remains subject to additional state or federal law. An example of such laws is the FTC Act that generally regulates commercial use of personal data or the Children Online Privacy Protection Act with regards to the use of children’s data. Ultimately, this has an effect on how consent should be extracted to process the data, as well as on the appropriate security and organisational protection measures, regardless of HIPAA. 

This article is for information purposes only, and does not constitute or replace legal advice. Seek professional support for any specific questions you may have.

The post HIPAA, the GDPR and MedTech appeared first on TechGDPR.