It’s been said that data is the new oil; if so, then organizations across the globe are poorly equipped to prevent increasingly sophisticated cyber attackers from compromising the digital fuel lines powering their enterprises. According to a recent report by Checkpoint, Q3 of 2022 saw a 28% increase in global attacks compared to the same period in 2021, with cyber criminals primarily targeting the healthcare and financial sectors. Malicious actors in these cases were less interested in the organizations themselves, but instead focused on their clients and customers’ Personally Identifiable Information (PII). Commercially, it's not hard to understand why: PII contained in healthcare files and financial records are worth 20 times more than a stolen credit card on the black market.
In this article, we’ll explore key facets of PII, key classifications and definitions, major causes of theft, the compliance and regulatory landscape, and crucial measures for protecting consumers’ personal information.
For most organizations, the conversation around PII primarily involves data privacy laws, regulations, and non-compliance fines and penalties; much of PII’s definition is therefore legal in nature. Crucially, a firm must understand what constitutes PII to effectively manage it according to local and federal consumer data protection laws—if an organization regularly stores, processes, and manages user data, they must also take proper care in understanding which pieces of information could be used to identify individuals, as they will most likely require additional security controls and measures for privacy protection. A myriad of legal and compliance requirements may come into play here, as well as international laws and regulations such as GDPR, depending on the data’s location.
To complicate matters, the language describing PII may vary across regions and locales. Generally, PII can be defined as information that, by itself or with other pieces of information, can be used by organizations for identifying, contacting, and/or locating an individual or identifying them in a particular context. In turn, PII can be categorized into two types that require different handling: Non-sensitive PII and Sensitive PII. Non-sensitive PII can be transmitted without the use of additional security, as its loss or theft would not cause harm to the individual. In contrast, sensitive PII requires secure handling (e.g., use of encryption, stricter data access rules), as its compromise could harm the individual.
The U.S. National Institute of Standards and Technology’s (NIST) has arguably the most definitive and widely adopted definition of PII:
“any information that can be used to distinguish or trace an individual’s identity, such as name, social security number, date and place of birth, mother’s maiden name, or biometric records; and any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment information.”
Based on NIST’ Guide to Protecting the Confidentiality of Personally Identifiable Information, several types of data can be definitively labeled as PII, as they can be used to accurately identify an individual.
Some examples of PII include, but are not limited to:
Along with these primary PII types are quasi/pseudo identifiers: data that, when combined with others, could be used to identify an individual. For example, the quasi/pseudo identifiers “Date of birth” and “place of birth” do not constitute PII on their own, since multiple people could share these attributes. However, when linked or linkable to other identifiers, they could be used to identify a specific person.
Though NIST has created the most widely accepted definition of PII, organizations should carefully analyze and understand the terminology and definitions laid out by their local and regional privacy laws. For example, the EU’s General Data Protection Regulation (GDPR) data protection requirements involve the concept of personal data, a category that covers a broader range of information than PII. In general, all PII is considered personal data, but not all personal data is PII.
GDPR defines personal data as:
“any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.”
Based on GDPR’s definition, any information that could identify a person—not just their first/last name—could be considered personal data. For example, cookie, session, and login information used for identifying return website visitors is considered personal data:
“Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them.”
Per GDPR, other examples of personal data include:
Organizations that collect and manage customer data are subject to numerous data privacy regulations, both on the local/regional/national/international level and from industry-specific oversight bodies. For example, the SEC’s Regulation-SP mandates the creation of policies and procedures for protecting customer information and records, while the Gramm-Leach-Bliley Act requires financial institutions to safeguard sensitive data, as well as disclose their information-sharing practices to their customers; similarly, the FTC’s Financial Privacy Rule requires finance firms to comply with certain limitations on disclosure of nonpublic personal information. On the state level, data privacy legislation has also been steadily taking shape across the country. The California Consumer Privacy Act (CCPA) and Massachusetts’ 201 CMR 17.00 were both recently enacted to prescribe and regulate how the PII of their respective residents is handled.
For organizations operating and/or transacting in the E.U., GDPR applies to:
Outside of the U.S. and E.U., varying definitions/concepts and legislation around data privacy and personal information have begun to take shape across the globe. For example, the Australian Privacy Act 1988’s take on personal information is broader than other countries’ definitions:
“information or an opinion, including information or an opinion forming part of a database, whether true or not, and whether recorded in a material form or not, about an individual whose identity is apparent, or can reasonably be ascertained, from the information or opinion.”
Between 2015 and 2020, cyber criminals across the globe focused their campaigns mainly on the finance/insurance industries. And though crypto theft and ransomware accounted for most of their efforts, a significant portion of their activities was related to PII theft. From lack of secure data storage to faulty cryptography, major software flaws and security glitches in banking/finance are expected to continuously increase with the growing predominance of fintech offerings (mobile banking platforms, finance tracking tools, investment apps).
A recent Accenture study involving 30 major banking applications found all of them to contain vulnerabilities ranging from insecure data storage to insecure authentication and code tampering. Organizations developing their own online banking portals and banking/finance apps should therefore be particularly wary of the following security gaps that could result in a PII compromise:
Regardless of whether they develop their own client/customer-facing apps or services, organizations should adopt common and effective frameworks for securing PII comprehensively throughout the organization. Data privacy frameworks enable firms to document, evaluate, and enhance security controls around sensitive data like payments, personal information, and intellectual property in a systematic and continuous manner based on their unique requirements and environments. Moreover, they also help organizations define sensitive data, identify risk factors affecting the data, and design the proper controls to secure the data. Popular examples include the NIST Privacy Framework—a set of protection strategies and controls for organizations to better managing privacy risk, as well as the ISO/IEC 29100:2011 privacy framework.
At Akoya, we’ve implemented numerous data privacy and security measures to reduce the risks associated with traditional financial data aggregation. For example, all client data in transit across our network is encrypted over an mTLS connection to mitigate common threats like malicious API requests and brute force attacks. Our network is optimized for security, transparency, and scalability; subsequently, our passthrough model does not copy or store any customer data, and our platform only facilitates connections and movement of consumer-permissioned data (permissioned data passing through our network is not stored). Akoya employees also do not have access to customer data.
All outputs follow the Financial Data Exchange (FDX) API standard, and we’ve implemented measures to further protect sensitive information like tokenizing account and routing numbers. To validate the effectiveness of our security controls, we carry out regular, independent security audits such as SOC 2 Type 2 attestation for demonstrating our compliance with the SOC 2 standards for security and confidentiality. Finally, our data privacy controls have been assessed and validated by major financial institutions, including some of the world’s largest banks.
To learn more about how Akoya helps its customers protect PII, read our articles about tokenized account numbers and security, or contact us for more information.