Sensitive Data

What is Sensitive Data?

Sensitive data is any information whose unauthorised disclosure, access, or loss could cause harm — to individuals whose information it is, to the organisation that holds it, or to both. Harm takes different forms: regulatory fines, legal liability, competitive damage, reputational harm, or direct harm to individuals whose personal or financial information is exposed.

That definition is deliberately broad, because "sensitive data" isn't a single category. It spans three distinct domains with different types of data, different protection requirements, different regulatory frameworks, and different consequences when breached.

The three domains of sensitive data

Understanding sensitive data means distinguishing these domains clearly. Security programmes that treat all sensitive data as equivalent, applying the same controls to employee financial records as to developer API keys, are simultaneously over-protecting some data and under-protecting other data.

Domain 1: Regulated personal data

This is the category most people think of first, and for good reason: it's where regulatory obligations are most explicit and penalties for failure are most concrete.

PII (Personally Identifiable Information) is any data that can be used to identify a specific individual, directly or in combination with other data. Names and email addresses are PII. Social security numbers, government-issued ID numbers, and passport numbers are PII. Home addresses and phone numbers are PII. An IP address combined with a timestamp and a user ID is PII if it can identify a specific person. The regulatory frameworks triggered by PII include GDPR for EU residents, DPDP for Indian personal data, CCPA for California residents, and many sector-specific regulations that incorporate PII protection requirements.

PHI (Protected Health Information) is health and medical data about identifiable individuals. Under HIPAA in the United States, PHI includes diagnoses, treatment records, prescription data, health insurance information, and any data that connects a health condition to a specific individual. PHI triggers strict encryption requirements, access controls, and audit obligations that go beyond general PII protection in many jurisdictions.

PCI data (Payment Card Industry data) includes card numbers, cardholder names, expiration dates, CVVs, PINs, and the transaction records that associate those payment identifiers with specific individuals. PCI DSS (Payment Card Industry Data Security Standard) applies to any organisation that stores, processes, or transmits payment card data. PCI scope is one of the most precisely defined in data security: the boundary between in-scope and out-of-scope environments is drawn around specific data elements, and misclassifying payment data as out of scope is a compliance finding.

Special categories under GDPR and similar frameworks extend beyond basic PII to include data whose exposure creates heightened individual harm risk: racial or ethnic origin, political opinions, religious beliefs, trade union membership, genetic data, biometric data, health data, and data about sexual orientation or gender identity. These categories trigger additional consent and processing requirements beyond standard personal data.

Domain 2: Business-confidential data

This domain covers data whose exposure harms the organisation rather than, or in addition to, individuals.

Financial data includes unreported earnings, M&A plans, budget projections, investor relations materials not yet in the public domain, and detailed cost structures that would disadvantage the organisation if disclosed to competitors or the market. Financial data is often also regulated: MNPI (material non-public information) under SEC rules creates legal obligations for how it's handled and who can access it.

Intellectual property includes source code, product designs, research findings, patent applications before filing, trade secrets, manufacturing processes, and proprietary algorithms. IP exposure doesn't create regulatory fines in most cases, but competitive harm is often irreversible. Source code exposed through a misconfiguration or insider theft can't be unexposed. The competitive advantage it represents is gone.

Strategic business information includes customer lists, pricing structures, vendor contracts, partnership agreements, go-to-market plans, and acquisition targets. This data may not trigger specific regulatory frameworks, but its disclosure creates direct business harm. A competitor who obtains your pricing model and customer list has a material advantage that takes years to recover from.

Legal and HR data includes employment records, disciplinary proceedings, salary information, contracts with third parties, and legal holds. Employee salary data is sensitive for privacy and potential discrimination reasons. Legal holds are sensitive for litigation privilege reasons. Neither falls into the regulated personal data categories necessarily, but both carry specific access and handling requirements.

Domain 3: Technically sensitive data

This category is frequently underestimated in classification programmes that focus on personal and business data.

Credentials and authentication secrets include passwords, API keys, tokens, cryptographic keys, certificates, and SSH keys. A developer who commits database credentials to a public GitHub repository has exposed data that isn't personal information and isn't a trade secret, but has created a direct attack vector into production infrastructure. Technically sensitive data exposure is often the first step in a breach that eventually exposes all the other categories.

System configuration and architecture data includes network topology diagrams, firewall rule sets, system architecture documents, and vulnerability scan reports. This data doesn't contain personal information and isn't regulated, but it reduces the work required for an attacker to plan an intrusion. Organisations routinely underclassify this category.

Secrets embedded in code and configuration files include database connection strings, third-party API credentials, encryption keys, and service account tokens that developers embed in application code or infrastructure configuration. This is technically sensitive data that appears in environments not traditionally covered by classification programmes.

Why context determines sensitivity

One of the most common misconceptions about sensitive data is that sensitivity is a fixed property of a data type. It isn't. Sensitivity is determined by context as much as content.

A customer's email address in a marketing database is PII and triggers GDPR obligations. The same email address in a published press release is public information. The sensitivity didn't come from the data type; it came from the context: who it belongs to, how it was collected, what it's combined with, and whether the person consents to its use.

A database containing names, addresses, and email addresses is PII. The same database, with phone numbers, national ID numbers, and health insurance identifiers added, has escalated to a much higher sensitivity level because the combination creates a richer profile of each individual with more harmful potential if exposed.

A set of financial projections is sensitive before the quarterly earnings announcement. After the announcement, the same numbers are public information. Sensitivity has a time dimension.

That context-dependence is why accurate classification requires semantic understanding of what data means in context, not just pattern matching on what it looks like. A column of nine-digit numbers in a test database may look like Social Security numbers. In context, surrounded by obviously synthetic data, it isn't sensitive. The same column in a healthcare database next to patient names and diagnosis codes is highly sensitive. The numbers look identical. The classification should be different.

How sensitive data accumulates beyond what security teams expect

Most organisations significantly underestimate the volume and distribution of their sensitive data estate. There are four reasons for this.

Data replication through pipelines. Production databases get copied to analytics environments for reporting. Those copies inherit the sensitivity of the source but are often outside the access control and monitoring scope applied to production. The sensitive data is now in two places, but security posture covers one.

Developer workflows. Developers routinely export production data samples to test new features or reproduce bugs. Those exports sit on developer laptops or in development S3 buckets. They carry full production sensitivity. They're rarely classified, rarely encrypted, and rarely monitored.

SaaS integration. When Salesforce syncs customer records to a marketing automation platform, or when Workday exports HR data to a benefits portal, those integrations create copies of sensitive data in environments the security team may not have inventoried. Each integration is a new sensitive data location.

Shadow data accumulation. Data backups, orphaned snapshots, and forgotten exports from years of operational activity sit in storage environments nobody actively manages. These are the highest-risk sensitive data locations precisely because nobody is watching them.

What protecting sensitive data requires

Protecting sensitive data across all three domains requires three capabilities working together.

Continuous discovery: finding where sensitive data exists, including the copies and derivatives that accumulate through normal business operations, not just the governed primary datastores.

Accurate classification: identifying what type of sensitive data each asset contains, with high enough accuracy to drive meaningful DLP policies, risk scores, and compliance reporting. Classification that misidentifies test data as production PII produces noise. Classification that misses production PII in an unstructured export produces blind spots.

Continuous posture monitoring: tracking whether the access controls, encryption posture, and sharing configurations around sensitive data remain acceptable as the environment changes. Sensitive data that was correctly secured last week may be exposed today because an automation pipeline deposited a copy in an unprotected location, or because an access policy was modified without security review.

Frequently asked questions

What is sensitive data?

Sensitive data is any information whose unauthorised disclosure, access, or loss could cause legal, financial, reputational, or personal harm. It spans three main categories: regulated personal data including PII, PHI, and PCI data; business-confidential data including financial information, intellectual property, and strategic plans; and technically sensitive data including credentials, secrets, and system configuration information.

What are examples of sensitive data?

Regulated personal data examples: customer names and email addresses, social security numbers, passport details, patient diagnoses, credit card numbers, and biometric identifiers. Business-confidential examples: source code, M&A plans, customer pricing, employee salary records, and trade secrets. Technically sensitive examples: database passwords, API keys, SSH private keys, and embedded application credentials.

Is all PII sensitive data?

PII is always sensitive data in the regulatory sense because it triggers obligations under GDPR, DPDP, CCPA, and similar frameworks. But the degree of sensitivity varies by context: an email address in a marketing database carries different risk than an email address combined with a medical diagnosis. The sensitivity level assigned to PII should account for what other data it's combined with and what harm its exposure could cause to the individual.

What is the difference between sensitive data and confidential data?

"Confidential" is a specific sensitivity level in classification schemes, typically one tier below "restricted" or "highly confidential." "Sensitive data" is the broader category that spans all data requiring special handling due to its harm potential. All confidential data is sensitive. Not all sensitive data is classified as "confidential": some sensitive data is restricted (higher sensitivity), and technically sensitive data like credentials may not fit cleanly into the personal data classification tiers at all.