10 Data Privacy and Encryption Laws Every Business Needs to Know
1 Star2 Stars3 Stars4 Stars5 Stars (3 votes, average: 5.00 out of 5)
Loading...

10 Data Privacy and Encryption Laws Every Business Needs to Know

What encryption laws does your organization need to comply with? Get started with this handy guide.

You’ve probably heard that every business needs to stay up to date on and comply with the latest encryption and privacy laws. Failure to comply will result in fines that can range upwards of tens of millions of dollars.

But which laws do you need to comply with, and what do you have to do?

If you’re like us, when you’re curling up with a book and a mug of tea (or coffee) after a hard day’s work, you don’t really want to read encryption laws. Encryption laws tend to be very broad or, in some cases, can even be described as nebulous. There are many types of data encryption laws on the books with governments and regulatory bodies around the world — some cryptography laws require encryption; others prohibit it or place restrictions on its use. International encryption laws vary by country and industry.

For example, some countries:

  • Guarantee the right for individuals to use encryption technologies and services.
  • Require a license (or another form of registration) to provide or use encryption software or services.
  • Have frameworks for voluntary and mandatory industry assistance to law enforcement concerning encryption technologies.
  • Require encryption to be used to protect the rights of data subjects (such as consumers, citizens, patients, etc.).
  • Prohibit the export of cryptography technology or algorithms.
  • Require enhanced transparency and communication about how data can be used.

For the sake of this article, we’re just going to focus on the regulations and laws that require encryption or reference the protection of encrypted data. These regulations and laws are sometimes called data encryption laws, data privacy laws or data protection laws (depending on the term you prefer to use). While narrowing down the topic helps somewhat, there are still many laws that fall into this category that govern your business and government alike depending on your location or industry. So, how do you know which laws apply and what they mean to your organization?

Grab your mug and get comfortable — you’re going to be here a while.

Let’s hash it out.

The top 10 data privacy and encryption laws from around the world

Identity theft is on the rise and companies are making headlines almost daily with news about debilitating data breaches. As such, concerns about privacy and protecting personal information are taking center stage as technology continues to evolve and more lives are becoming intricately entwined with the digital world. These concerns often manifest in data protection laws and privacy regulations.

Note: We’re just touching on the encryption and data protection aspects of these laws. There is far more information involved with these laws. For more in-depth information, you should go directly to the laws or speak with a legal professional about how these laws may apply to your organization and industry.

Here are 10 of the encryption laws or regulations you should know. They’re listed in alphabetical order and not in any order of importance because they’re all important and play essential roles in protecting user data and privacy around the world.

1.  California Consumer Privacy Act of 2018 — United States

Who this encryption law applies to:

This law applies to organizations who deal with California customers and/or their personal data. Some small companies are exempt, as it only applies to organizations who either:

  • share the personal info of at least 50,000 consumers,
  • have more than $25 million in gross revenue, or
  • derive 50% or more of their annual revenue from selling consumers’ personal information

What it requires:

The law states that companies who do not encrypt data or neglect to employ “reasonable security procedures” are liable to be sued by consumers whose data is compromised.

What you should do:

Regardless of where your business is located, if you process the data of Californians, you should ensure that you’re:

  • Encrypting all private data by using in-transit encryption (e.g., SSL) and at-rest encryption.
  • Employing reasonable security best practices to protect all nonpublic data in your possession.

The nitty-gritty details:

We’ve kicked our list off on the west coast of the United States with the first of our US quasi-encryption laws. The California Consumer Privacy Act of 2018 (CCPA) is a piece of legislation that aims to protect the right to privacy of consumers in the U.S. state of California. The Act arose after the creation of the European Union’s General Data Protection Regulation (GDPR) — which we’ll speak more about later in this article — and though it shares some similarities, it is vastly different in many ways and isn’t as stringent.

The purpose of the encryption law is to:

  • Give California consumers the right to what and how their information is used and hold businesses accountable for info compromised in breaches.
  • Require businesses to disclose any sales of California consumers’ personal information, cease sales of personal information when requested by consumers, and take “reasonable steps” to protect the information.
  • Prevent businesses from discriminating against California consumers who request info about how their info is collected or sold, or who refuse to allow businesses to sell their information.

As part of these requirements, the act states that California consumers’ personal information must be protected. According to section 1798.150:

“Any consumer whose nonencrypted or nonredacted personal information, as defined in subparagraph (A) of paragraph (1) of subdivision (d) of Section 1798.81.5, is subject to an unauthorized access and exfiltration, theft, or disclosure as a result of the business’s violation of the duty to implement and maintain reasonable security procedures and practices appropriate to the nature of the information to protect the personal information may institute a civil action…”

What does it say about methods of security? Not much. Although it doesn’t specify any specific methods of security, it does at least imply that encryption should be used to help protect the information. It’s important to note, however, that non-compliance with this regulation could spell out fines and civil penalties of up to $2,500 for each violation or $7,500 for each intentional violation.  

2. Data Protection Regulation — Denmark

Who this encryption law applies to:

This data privacy regulation applies to any public authorities as well as private companies and organizations who handle confidential and sensitive personal data via email.

What it requires:

The regulation states that encryption must be used when transmitting confidential and sensitive information via email over an open network (such as the internet).

What you should do:

So long as your organization is handling sensitive personal data, you need to ensure that you’re encrypting the information. This requires assessing your organization to determine which method of encryption would be best for your particular needs. This can include the use of:

  • Encrypting all sensitive, private data using in-transit encryption (e.g., SSL).
  • Encrypting such sensitive information using end-to-end encryption (such as S/MIME, PGP, and other methods that will be discussed below).

The nitty-gritty details:

Denmark’s Data Protection Authority is serious about email security. The Data Inspectorate, the country’s central independent authority that monitors data protection compliance, mandated the use of email encryption for all emails containing personal data beginning in January 2019. The Data Protection Regulation specifies that this protective measure needs to be used for all messages containing sensitive types of information.

According to the official notice:

“The Data Protection Authority has decided to sharpen its practice with regard to the transmission of confidential and sensitive personal data by e-mail in the private sector. In the future, it will thus be the Data Inspectorate’s opinion that it will normally be an appropriate security measure – for both public and private actors – to use encryption when transmitting confidential and sensitive personal data with e-mail via the Internet.”

To achieve end-to-end encryption, the Data Inspectorate outlines that organizations can use various methods of encryption such as pretty good privacy (PGP), NemID (Denmark’s logon solution for public self-service, online banking solutions, etc.), and secure/multi-purpose internet mail extensions (S/MIME), or what are known as email signing and encryption certificates — which we’ll speak more about later in the article.  

Although the email privacy regulation does not specify any penalties for noncompliance that we could find, it’s nice to see that they at least provided some recommendations for data security methods such as the use of S/MIME. 

3. European Banking Authority — European Banks — European Union

Who this encryption law applies to:

This law applies to:

  • all “competent authorities” in the 28 member states of the European Union,
  • EU financial institutions that handle internet payment services, and
  • third-party e-Merchants who store, process, or transmit sensitive payment data.

What it requires:

The regulation states that minimum security requirements must be put in place by financial institutions that ensure “secure, end-to-end encryption.”

What you should do:

Whether you’re a financial institution or an e-Merchant that handles payment data, you must ensure that:

  • You’re encrypting all sensitive data that can identify and authenticate customers.
  • Any e-Merchants handling or processing sensitive payment data are not storing it — or, if they are, that they have “the necessary measures in place to protect these data.”

The nitty-gritty details:

The European Banking Authority (EBA) has a series of the minimum security regulations for financial institutions concerning internet payment services and the obligations of payment service providers (PSPs). This document, known as the Final Guidelines on the Security of Internet Payments, does not affect the validity of the European Central Bank “Recommendations for the Security of Internet Payments.” The internet payment services covered under this data security regulation include:

  • Cards — the execution of card payments on the internet, including virtual card payments, as well as the registration of card payment data for use in ’wallet solutions.’
  • Credit transfers — the execution of credit transfers (CTs) on the internet.
  • E-mandate — the issuance and amendment of direct debit electronic mandates;
  • E-money — transfers of electronic money between two e-money accounts via the internet.

Did you know that all European banks are required to use extended validation (EV) SSL certificates? No, we’re not making this up just because The SSL Store™ happens to sell them. In section 4.2 (Risk Control and Mitigation), the guidelines specify that to restrict the use of fake sites, “transactional websites offering internet payment services should be identified by extended validation certificates drawn up in the PSP’s name or by other similar authentication methods.”

This is particularly interesting considering that a recent Sectigo study shows that 25% of European banks lack EV (though it’s possible that some of these institutions may be in countries that are not part of the EU).

In section 11 (Protection of Sensitive Payment Data), the guidelines specify that any data that is used to identify and authenticate customers should be appropriately secured against theft and unauthorized access or modification. Section 11.2 also specifies:

“PSPs should ensure that when exchanging sensitive data via the internet, secure end-to-end encryption is applied between the communicating parties throughout the respective communication session, in order to safeguard the confidentiality and integrity of the data, using strong and widely recognized encryption techniques.”

These types of data privacy regulations also extend to third-party e-Merchants who store, process, or transmit sensitive payment data:

“In the event e-merchants handle, i.e. store, process or transmit sensitive payment data, such PSPs should contractually require the e-merchants to have the necessary measures in place to protect these data. PSPs should carry out regular checks and if a PSP becomes aware that an e-merchant handling sensitive payment data does not have the required security measures in place, it should take steps to enforce this contractual obligation, or terminate the contract.”

When the EBA regulation was finalized in 2014, all EU financial organizations would’ve had two months to either comply with the guidelines or to notify the EBA about their reason for not being compliant. Considering it’s now 2019, though, everyone should be compliant with these guidelines at this point. 

4. Federal Information Processing Standards – United States

Who this encryption law applies to:

These federal standards pertain to non-military federal agencies, government contractors, vendors, and other organizations who work with them that “use cryptographic-based security systems to protect sensitive information.”

What it requires:

The standards state that federal agencies, contractors or vendors must develop and implement cryptographic modules that protect “sensitive but unclassified information.”

What you should do:

If your organization is a federal agency (or works with one) that uses crypto-based security systems, you should ensure that you’re using cryptographic modules that meet the standards’ four increasing, qualitative levels of security.

The nitty-gritty details:

The Federal Information Processing Standards (FIPS), which is mandated by the National Institute of Standards and Technology (NIST), is an entire computer security standards program in which certain types of data require specific levels of cryptographic security. This section of our list is, by no means, comprehensive. Rather, it should serve as more of an overview of the newest standard because there is a lot to know about FIPS and we simply don’t have enough time or space in one article to cover it all.

In a nutshell, FIPS includes four security levels to examine cryptographic modules as part of its Cryptographic Module Validation Program (CMVP) validation process. It specifies what each level comprises, going as granular as specific ciphers and elliptic curves, but there is no uniform application. It varies from one organization to the next based on their function and the data they collection. When an organization can prove it has satisfied all the requirements, it’s considered FIPS certified. The 140-1 standard was replaced by 140-2 in 2001, which focuses on the module that will still sensitive information.

The newest FIPS testing standard, FIPS 140-3, will become effective beginning on Sunday, Sept. 22, 2019. This standard specifies the requirements that any device’s encryption system must meet if it is to be used by the federal government. FIPS 140-3 — which draws from NIST SP 800-140 and, for the first time, points to the international standard ISO 19790 — will supersede FIPS 140-2. Testing for FIPS 140-2, the current standard, will continue for at least one more year after FIPS 140-3 testing commences.

So, what does all of this mean for manufacturers and product testing laboratories? As a news release from NIST states:

“Any product that adheres to the international standard—known as ISO 19790—will therefore use an encryption approach that is acceptable both within and outside the United States. This should streamline a manufacturer’s process for bringing a device to market because it reduces redundancy for companies trying to sell products internationally.” 

Although there are no penalties for being non-compliant with FIPS regulations, non-compliance does place your organization at a greater risk of data breaches. 

5. General Data Protection Regulation — European Union

Who this encryption law applies to:

This privacy law applies to organizations that use the private data of European Union citizens (known as “data subjects” in the legislation), regardless of where the organizations’ locations, for the purpose of:

  • Offering them goods or services regardless of payment
  • Monitoring their behaviors (that take place within the union).

The regulation does not apply to authorities whose purposes are the prevention, investigation, detection or prosecution of criminal offenses or execution of criminal penalties

What it requires:

The law states that any organizations who don’t protect personal data using “appropriate safeguards” are non-compliant and may be liable to fines and penalties as a result.

What you should do:

Regardless of where your business is located, if you process the data of EU citizens, you should ensure that you’re:

  • Implementing appropriate safeguards and measures to protect all private data (which could include data at rest and data in transit protection mechanisms).
  • Regularly testing and evaluating the effectiveness of your technical and organizational measures for security.

The nitty-gritty details:

The General Data Production Regulation (GDPR) is a European data protection law with teeth. Since it became effective in May 2018, this sweeping regulation gives data subjects (the EU citizens) the “right of access” to their personal data, as well as the “right to be forgotten” and “right to be informed.”

This omnibus law is comprehensive in scope and regulates much of what companies around the world are allowed (and not allowed) to do with personal information of data subjects (EU citizens) — particularly concerning its collection, use, and storage. GDPR also specifies who is responsible for the safety and security of that personal data once it is collected.

According to Chapter 4, article 32 of this European data protection law:

“The controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate:

the pseudonymisation and encryption of personal data;

the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;

the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident;

a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.”

The regulation is intentionally vague as to the technical methods that should be used to secure personal data with the exception of explicitly mentioning encryption (though it does not specify any encryption methods). It also places the responsibility on the controller and the processor to recognize and address risks concerning the processing of personal data.

When it comes to imposing fines and penalties for non-compliance, GDPR shows that it means business. Article 83 states that infringements of some of the provisions within the regulation may “be subject to administrative fines up to 20 000 000 EUR, or in the case of an undertaking, up to 4 % of the total worldwide annual turnover of the preceding financial year, whichever is higher.”

Depending on the size of the offending organization, we’re talking about serious fines and penalties for noncompliance. Just look in the headlines for examples of what we mean. Just one year after it became effective, some major companies like Google and Facebook find themselves potentially facing significant fines over data breaches involving the personal information of EU citizens.

6. Gramm-Leach-Bliley Act — United States

Who this encryption law applies to:

This law applies to financial institutions and organizations of all sizes within the United States (such as banks, securities firms, insurance companies, and other financial service providers) who are involved with providing financial products or services to consumers.

What it requires:

The law states that companies who don’t protect the integrity and security of consumers’ data are subject to criminal and civil penalties.

What you should do:

If your business is located in the U.S. and you process financial information, you should ensure that you’re:

  • Encrypt all customer information “held or transmitted” by you using both in-transit and at-rest encryption methods.
  • Protect against reasonably anticipated threats to the security of the data.
  • Establish and employ standards and best practices to protect data and access to it.

The nitty-gritty details:

Let’s head back across the “pond” to the U.S. to discuss a law that was intended to modernize the financial services industry. The Gramm-Leach-Bliley Act is one that requires financial institutions to protect the privacy of a consumer’s “nonpublic personal information” (NPI) and to communicate their information-sharing practices to them. The encryption law does distinguish between “customers” and “consumers,” and requires notice about your privacy practices to be given to all of your “customers,” and to your “consumers” as well if you share their information in certain ways.

In its Privacy Obligation Policy in Title V — Privacy, the Act states that each financial institution has “an affirmative and continuing obligation” to respect the privacy of its customers and to protect the security and confidentiality of their nonpublic personal information. It goes on to state that each financial institution:

“shall establish appropriate standards for the financial institutions subject to their jurisdiction relating to administrative, technical, and physical safeguards–
(1) to insure[sic] the security and confidentiality of customer records and information;
(2) to protect against any anticipated threats or hazards to the security or integrity of such records; and
(3) to protect against unauthorized access to or use of such records or information which could result in substantial harm or inconvenience to any customer.”

In response, the Federal Trade Commission (FTC) released its Privacy of Consumer Financial Information final rule in 2000 and its Standards for Safeguarding Customer Information final rule in 2001. The latter requires financial institutions to:

“[…] develop, implement, and maintain a comprehensive information security program that is written in one or more readily accessible parts and contains administrative, technical, and physical safeguards that are appropriate to your size and complexity, the nature and scope of your activities, and the sensitivity of any customer information at issue.” (16 CFR § 314.3)

This is where things get more specific. § 314.4 of the FTC’s 2001 standards specifies that every financial organization needs to “protect by encryption all customer information held or transmitted by you both in transit over external networks and at rest.” If the encryption of customer information isn’t possible for some reason, the rule states that you may instead “secure such customer information using effective alternative compensating controls reviewed and approved by your CISO.”

We’ll speak more to what it means to protect data at rest and data in transit later in the “Takeaway” section of this article. For now, let’s move on to the seventh encryption law on our list.

7. Healthcare Insurance Portability and Accountability Act — United States

Who this encryption law applies to:

This law applies to U.S. organizations that handle patients’ sensitive and confidential personal information, including:

  • health plans,
  • healthcare clearinghouses,
  • healthcare providers, and
  • their business associates.

What it requires:

The law states that companies who disclose confidential and personal information through any method are liable to varying levels of penalties depending on their level of intention:

  • Those who “knowingly” obtain or disclose the information face fines of up to $50,000 and up to one year in prison (or both).
  • Confidential and personal health information obtained through “false pretenses” can result in penalties of up to $100,000 and up to five years in prison (or both).
  • Offenses committed with the intent to “sell, transfer, or use individually identifiable health information for commercial advantage” can result in up to $250,000 in fines and up to 10 years in prison (or both).

What you should do:

If your business handles, stores, or processes electronic protected health information (ePHI), then you need to ensure that you’re:

  • Performing assessments to determine the best methods of protection of ePHI. 
  • Adopting integrity controls and encryption as “addressable implementation specifications.” This could include in-transit (SSL) and at-rest data encryption.

The nitty-gritty details:

What is there to know about Healthcare Insurance Portability and Accountability Act (HIPAA) data security? A lot, and yet very little at the same time. At its core, HIPAA was created to protect and regulate the availability of health insurance policies for all individuals and groups. It is administered by the Department of Health and Human Service’s (HHS’s) Office for Civil Rights (OCR) and has had multiple updates and “guidance notices” issued for it over a 10-year period, including: 

  • Privacy and Security Rules that were added in 2003.
  • The HIPAA Enforcement Rule that was added in 2006.
  • HITECH Act requirements that were incorporated in 2009.
  • The Final Omnibus Rule that was created in 2013.

Though it may seem counterintuitive, the HIPAA Security Rule itself is purposefully vague. This is because the legislation’s creators recognized that technology would evolve over time, so they didn’t want to require specific safeguards that could soon become obsolete. Their way around this was to instead outline the responsibilities that any organizations handling the sensitive information would need to address and leave the method of choice up to them. This approach aimed to protect privacy while also not limiting the affected organization from adopting new technologies that would improve patient care and efficiency.

For example, in § 164.306(a) states:

(1) Ensure the confidentiality, integrity, and availability of all electronic protected health information the covered entity or business associate creates, receives, maintains, or transmits.
(2) Protect against any reasonably anticipated threats or hazards to the security or integrity of such information.
(3) Protect against any reasonably anticipated uses or disclosures of such information

However, the rule doesn’t go much into specifics about how the affected organizations or entities should accomplish these tasks. Instead, what it does say in § 164.306(b) is that:

“Covered entities and business associates may use any security measures that allow the covered entity or business associate to reasonably and appropriately implement the standards and implementation specifications as specified in this subpart.”

A few technical safeguards mentioned in § 164.312, including:

  • (2)(iv): “Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information.”
  • (2)(e)(1): “Standard: Transmission Security. Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.”
  • (2)(ii): “Encryption (Addressable). Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate.”

If you’re looking for more info on HIPAA, the good news is that we’ve written a few blog posts relating to the HIPAA framework and how it aims to help to protect electronic protected health information (ePHI). One of these articles break down the technical safeguards that HIPAA’s Security Rule; others are examples of what happens when healthcare-related organizations are noncompliant or suffer cyber security breaches. Hopefully, these articles will provide additional insight for you concerning the HIPAA related data privacy.

Otherwise, we’re moving on to discuss financial services encryption requirements in the Northeastern U.S.

8. New York Department of Financial Services — United States

Who these encryption standards apply to:

These regulations apply to any person who participates in the business operations of a covered entity, which includes those who operate under a license, registration, charter, certificate, permit, accreditation, or similar authorization under the:

  • Banking Law,
  • Insurance Law, or
  • Financial Services Law.

Some companies and individuals are exempt from the requirements of select sections of the regulations, including covered entities:

  • with fewer than 10 employees.
  • less than $5 million in gross annual revenue in each of the last three fiscal years.
  • less than $10 million in year-end total assets.

What they require:

The law states that the superintendent can enforce these regulations with companies who are noncompliant under any applicable laws.

What you should do:

If you process or handle the nonpublic data of New York consumers, you should ensure that you’re:

  • creating a cybersecurity program that includes the use of encryption.
  • using alternate compensating controls if encryption is infeasible.
  • periodically disposing of nonpublic information that’s not necessary for business operations or required to be retained by law or regulation. 

The nitty-gritty details:

The New York State Department of Financial Services (NY DFS) put in place Cybersecurity Requirements for Financial Services Companies that went into effect in March 2017. These state-mandated requirements aim to protect consumers and businesses alike by promoting “the protection of customer information as well as the information technology systems of regulated entities.” They hold to certain regulatory minimum standards without “being overly prescriptive so that cybersecurity programs can match the relevant risks and keep pace with technological advances.”

Unlike some of the other regulations and laws on our list, the NY DFS mandate does require the use of certain controls, including encryption, as part of its cybersecurity program. This requirement aims to protect sensitive, nonpublic information that is held or transmitted — meaning it protects both data at rest and data in transit over external networks. According to Section 500.15 (a):

“As part of its cybersecurity program, based on its Risk Assessment, each Covered Entity shall implement controls, including encryption, to protect Nonpublic Information held or transmitted by the Covered Entity both in transit over external networks and at rest.”

In the event that encryption isn’t feasible for data at rest and data in transit applications — which, really, when would that realistically be the case? — “alternative compensating controls reviewed and approved by the covered entity’s CISO” could apply, and the effectiveness of such measures would need to be reviewed at least annually by the chief information security officer.

These requirements aren’t only expected of the primary organizations — they also apply to third parties who handle nonpublic information. Section 500.11 states that the organization’s policies and procedures also must address third-party service providers’ policies and procedures as well in the event that such a party has access to consumers’ sensitive data. Such documents must discuss the policies and procedures for the use of encryption.

Like the CCPA, there are certain organizational size requirements to qualify as a covered entity. For the NY regulation, entities with fewer than 10 employees, less than $5 million in gross annual income (in each of the last three fiscal years), or less than $10 million in year-end total assets are exempt from certain requirements.

For something more broad-reaching, let’s look at one of the world’s most impactful international encryption laws.

9. Payment Card Industry Data Security Standard — Global

Who these encryption standards apply to:

These standards apply to virtually any entities or organizations that handle payment card data, including financial institutions, merchants, and service providers. If a bank account number is a primary account number (PAN) or contains PAN digits, then these standards would also apply. 

What they require:

These standards require that companies who do not encrypt data and employ adequate security procedures are liable to fines and penalties that are defined by the payment card brands. The PCI Security Standards Council (PCI SSC) itself does not impose consequences, fines, or penalties for non-compliance.

What you should do:

Since these standards are issued by a global council, if your business handles, processes, or stores payment card data, you should ensure that you’re:

  • using encryption and other methods to render certain information unreadable, including data at rest and data in transit encryption methods.
  • implementing appropriate policies, processes, and procedures to protect all payment card data in your possession.

The nitty-gritty details:

If you’re an organization that processes, transmits, or stores payment card data — debit and credit cards alike — then you ought to be at least familiar with the Payment Card Industry Data Security Standard (PCI DSS) v3.2.1. This standard is essential to helping protect cardholders and the payment card ecosystem as a whole.

The most recent version of PCI DSS was developed to provide supplemental guidance and not to supersede, replace, or extend requirements in any Payment Card Industry Security Standards Council (PCI SSC) standards. Like many of the other encryption laws and regulations on our list, it also doesn’t endorse the use of any specific technologies, products, or services.

PCI DSS dictates that all entities involved in payment card processing must protect the storage and transmission of data across open, public networks. Requirements 3 and 4, respectively, provide guidelines on

  • Protecting stored cardholder data:
    • through retention and disposal policies, processes, and procedures;
    • by rendering certain types of information unreadable;
    • by using disk encryption or column-level database encryption; and
  • Encrypting the transmission of cardholder data across open, public networks (including the internet, wireless technologies, cellular technologies, general packet radio service, and satellite communications).

The Payment Card Industry Security Standards Council, a global forum, is the authority that responsible for the development of these industry standards. However, they’re not responsible for enforcing compliance with them — that’s left up to the five major payment card brands:

  • American Express,
  • Discover,
  • JCB International,
  • Mastercard, and
  • Visa.

PCI SSC also has released a number of other PCI standards and resources, including the PCI 3-D (PCI 3DS) SDK Security Standard and Payment Card Industry Point-to-Point Encryption (PCI P2PE) Standard. These documents provide additional guidance concerning security requirements, assessment procedures, and processes for software development kits and point-to-point products. The current industry standard for P2PE is PCI Point to Point Encryption v2.0. The next version of the standard, PCI P2PE v3.0, is anticipated to be published in Q4 2019 to Q1 2020. 

There is much more that could be covered about PCI DSS and other PCI-related standards at the granular level. However, we only have so much time (and we’ve already spent a lot on this so far!). So, for now, we’ll move on to encryption law that hails from the Great White North.

10. Personal Information Protection and Electronic Documents Act— Canada

Who this encryption law applies to:

This law applies to private-sector organizations that handle Canadian consumers’ personal data for commercial activity. This includes businesses that operate within the country but have personal data that crosses all provincial or national borders — with the exception of organizations that operate entirely within:

  • Alberta
  • British Columbia
  • Quebec.

The law does not apply to organizations that don’t engage in commercial, for-profit activities.

What it requires:

The law states that individuals and the Office of the Privacy Commissioner of Canada (OPC) can file complaints against companies who do not use collected personal data as specified or implement appropriate security safeguards. The results of a subsequent investigation could result in fees and penalties against the organizations.

What you should do:

If your business handles Canadian consumers’ personal data for commercial purposes, you should ensure that you’re:

  • Only using consumers’ personal information for the specific purpose that it was collected for.
  • Implementing security safeguards that are appropriate to the sensitivity of the information, which should include encryption.

The nitty-gritty details:

Canada has its own data privacy regulations — such as the Personal Information Protection and Electronic Documents Act (PIPEDA). This federal privacy law is intended for private-sector organizations and outlines how businesses must handle personal information in the course of commercial activity. Although this is a Canadian law, it does also apply to businesses that operate within the country and handle personal data that crosses provincial or national borders.

Much like GDPR, the law specifies that a person’s personal information can only be used for the purpose it was collected — so a company can’t say they’re collecting the info for service-related functions only and then turn around and use the contact information for marketing purposes. Instead, they’d have to obtain consent again while specifying that the information would be used for that new purpose. The law also specifies that people have the right to access their personal information and challenge its accuracy.

All businesses operating under PIPEDA are required to follow 10 fair information principles:

  1. Accountability
  2. Identifying Purposes
  3. Consent
  4. Limiting Collection
  5. Limiting Use, Disclosure, and Retention
  6. Accuracy
  7. Safeguards
  8. Openness
  9. Individual Access
  10. Challenging Compliance

Throughout this dense and strangely-worded regulation is the clause, “to protect that information by security safeguards appropriate to the sensitivity of the information…” Although the regulation does not specify particular safeguards — which is likely by design due to continually changing technologies — it could entail the use of encryption, firewalls, and security patches.  

Non-compliance should be a concern for covered organizations. As Global News reports:

“Failure to report the potential for significant harm could expose private-sector organizations to fines of up to $100,000 for each time an individual is affected by a security breach, if the federal government decides to prosecute a case.”

Bonus Round: The Proposed New York Privacy Act

You may have heard that individual states are now working to develop their own version of the CCPA. New York is next on the list with its proposed new privacy legislation known as the New York Privacy Act (NY SB 224), or what may be cited as the “Right to Know Act of 2019.” The goal is to modernize the state’s current privacy law to give NY residents more control of their personal information and how it is collected and disclosed.

While there are some similarities between the CCPA and the NYPA, there are some notable differences as well:

  • There is no minimum size for organizations that would be subject to the requirements of the Act.
  • More responsibilities are imposed on businesses.
  • New York residents can sue violating companies directly rather than having to wait on the district or state attorney general’s office to take action.

As of this point, the act doesn’t include any specific methods of protection for consumers’ data information, such as the use of encryption or email signing certificates. It also does not specify any government penalties or fines for violations of the act, nor does it outline any consumer actual or statutory damages. Hopefully, the legislation will be updated to provide a bit more specific recommendations or requirements concerning data security methods.

Takeaway: What these encryption laws mean for you

As we said at the beginning, some of these laws may not apply to your business depending on your industry or location. However, it’s important to be aware of which ones do because some encryption laws and regulations, such as GDPR and PCI DSS, are far-reaching and apply to organizations beyond their geological borders. The GDPR, for example, applies to organizations inside and outside the EU that handle the personal information of EU citizens, and PCI DSS applies to virtually anyone who handles card payments.

What can you do to increase data security? In general, there are some methods of protection that should be implemented across the board (regardless of industry or location) to be compliant with data privacy and encryption laws:

Use SSL/TLS to protect data in transit

When you transmit information over an open network such as the internet, you have no control over which servers and devices the information will pass through along the way. This is why it’s imperative that everything within your organization uses a secure, encrypted connection via your website.

There’s no way around it: If you handle the transfer of sensitive data such as consumers’ personal and financial information on your website, you need to use a secure, encrypted protocol (HTTPS). This means using an SSL/TLS (secure sockets layer/transport layer security) certificate. HTTP is not secure (even Google says so) and leaves your site and its visitors vulnerable.

When you use SSL on your site, it reassures site visitors by displaying a padlock indicating that shows the site is secure. In Google Chrome,

Use other encryption methods to protect data at rest

In addition to protecting data in transit, it’s also vital that your organization protects data at rest as well. What’s the difference? Data in transit only protects data while it’s being transmitted through a secure, encrypted channel. Once it arrives at its destination, though — typically a web server or even another data storage device — it’s no longer protected by the SSL/TLS protection and is vulnerable.

Let’s consider email as an example. Email involves both data and rest and data in transit. When an email sits in your email inbox, it’s considered data at rest. Once you create a new message and click “Send,” it becomes data in transit. Once it arrives in your recipient’s email box, it again becomes data at rest. Wouldn’t you want it to be secure and encrypted to ensure that no one except your intended recipient can access your plaintext message and any attachments?

A secure/multipurpose internet mail extension (S/MIME) certificate can help you do just that. S/MIME certificates is a way to keep your data at rest secure through email encryption. When you send an email using an S/MIME certificate, you’re taking the plaintext email message you’ve written and encrypt it so that only your intended recipient can decrypt it using a corresponding secret key. This means that when you send an email using an email signing certificate, it remains encrypted both when it’s in transit and at rest.

An added bonus of S/MIME is that because it’s also an email signing certificate, it means that you can use a trusted certificate authority (CA) to authenticate yourself to your email recipient and show that you really are who you claim to be.

Sounds like a win-win situation to us.

But what if you need to encrypt other data at rest that isn’t email? Other methods of data at rest encryption involve the use of third-party encryption solutions, such as BitLocker or VeraCrypt, that use various encryption algorithms including Advanced Encryption Standard (AES) or Rivest Shamir, and Adleman (RSA) encryption.

What are the differences between these two encryption algorithms? AES is a symmetric algorithm that uses up to a 256-bit key for both encryption and decryption. It’s fast, efficient, and often involves the use of a passcode. RSA, on the other hand, is what’s known as asymmetric encryption, meaning that it uses a separate public key and private key for the encryption and decryption processes. RSA is more computationally-intensive counterpart that’s best left to encrypting small amounts of data.

Commercial database solutions (such as MS SQL) also come with encryption solutions for protecting records stored in your database. Check your database documentation to see what encryption options are available and to determine whether you’re already using them.

Final thoughts

Phew. That was a lot of information — and we’ve just touched the tip of the iceberg. There are many other encryption laws in place or in the works around the world. Some laws are comprehensive while others are more simplistic. A little more than a year after the GDPR launched, we’ve seen several other laws become enacted or at least start the process of development. It’ll be interesting to see what new laws will be put into effect in the next couple of years and how the world of data privacy and encryption regulation will continue to change — hopefully, for the better.

If you want to get the most up to date news on the encryption industry, data privacy, and everything cyber security, be sure to follow us on Facebook, LinkedIn, and Twitter

As always, leave any comments or questions below…

Be the first to comment

Leave a Reply

Your email address will not be published. We will only use your email address to respond to your comment and/or notify you of responses. Required fields are marked *

Captcha *

Author

Casey Crane

Casey Crane is a regular contributor to Hashed Out with 10+ years of experience in journalism and writing, including crime analysis and IT security. She also serves as a Content Marketer at The SSL Store.