How To Handle Sensitive Customer Data In A CDP

The safest sensitive field in a customer data platform is often the one that was never loaded.

That sounds obvious until a source system begins sending something the CDP team never intended to collect.

A health condition appears in a form field. An application starts transmitting precise location. A support agent types a diagnosis into free text. A model infers financial distress from a customer's behavior. An identity feed includes a government identifier that nobody realized was present.

Once that information enters the CDP, it can be copied into profiles, warehouses, audience definitions, exports, analytics systems, and activation destinations.

The question should therefore come before ingestion:

Does this sensitive data need to be in the CDP at all?

If the answer is no, exclude it.

If the use case can operate on something less sensitive, transform it.

If the information must remain in a more tightly controlled source system, query the answer rather than copying the raw value into a marketing-oriented customer profile.

Only when a named purpose genuinely requires the data should the organization consider bringing it into the CDP.

Handling sensitive customer data in a CDP means deciding whether each sensitive attribute should enter the platform at all, transforming it into a less sensitive form where possible, and, for what does enter, applying a named purpose, the required consent, field-level protection, narrow access, enforced activation restrictions, short retention, and evidence that those controls work. Sensitive data includes information that applicable laws or the organization's own policy subject to heightened protection, such as health information, precise location, biometrics, certain financial and government identifiers, protected characteristics, and some derived inferences.

That order matters.

The objective is not to make a CDP capable of storing everything.

It is to make sure the platform stores only what it has a defensible reason to hold and cannot casually send high-risk data somewhere it should never go.

This article provides technical and operational guidance, not legal advice. Definitions of sensitive data and the rules governing it vary by jurisdiction, industry, and use case. Privacy counsel should confirm the requirements that apply to your organization.

What Counts As Sensitive Customer Data?

There is no single global list that works for every organization.

GDPR uses the concept of special categories of personal data. California defines sensitive personal information. State privacy laws use their own definitions. Sector-specific rules add additional requirements for health, financial, payment, children's, biometric, and other information.

For CDP architecture, the safer approach is to maintain a high-common-denominator internal sensitivity model and then let privacy counsel map the applicable legal requirements by jurisdiction.

Health And Consumer Health Data

Health-related information can include diagnoses, symptoms, medications, fertility information, mental health information, health-related searches, and purchases that reveal a condition.

The operational default should generally be restrictive.

If the CDP does not genuinely require the raw health attribute, exclude it or convert the use case into a safer eligibility flag.

Consumer health data deserves particular attention because it may be protected even when the organization is not subject to HIPAA. Washington's My Health My Data Act, for example, was designed specifically to regulate consumer health information outside the traditional HIPAA framework and requires consent for covered collection and sharing practices.

Precise Geolocation

Exact GPS coordinates and detailed location history can reveal where someone lives, works, worships, receives medical care, or spends time.

A marketing use case often does not need that level of precision.

If regional context is enough, transform precise coordinates into a less granular geographic value before they enter the general customer profile.

Biometric And Genetic Information

Face templates, fingerprints, voiceprints used for unique identification, and genetic information deserve highly restrictive treatment.

For many CDP use cases, these values should remain in purpose-built systems rather than in customer profiles used for segmentation and activation.

The CDP may need a derived status such as identity_verified = true.

It rarely needs the biometric template that produced that result.

Government And Financial Identifiers

Social Security numbers, passport numbers, driver's license numbers, bank credentials, and similar identifiers are usually poor candidates for a CDP.

If another process requires a stable reference, consider tokenization or another surrogate identifier so analysts and marketers never interact with the underlying value.

Protected Characteristics

Information revealing racial or ethnic origin, religion, sexual orientation, union membership, or similar protected characteristics can create significant legal and ethical risk.

Do not collect these attributes for marketing simply because a source system can provide them.

The same caution applies to models that infer those characteristics indirectly.

Children's Data

Information about minors should not enter the CDP casually.

Where the business genuinely serves children or families and collection is necessary, consent, retention, access, and activation rules need stricter treatment than ordinary marketing profile data.

Contents Of Communications

Support tickets, chat transcripts, call notes, email content, and form comments can contain almost anything.

That makes free text inherently risky.

A customer may disclose medical, financial, family, or other sensitive information in a field the CDP team originally considered harmless.

Where possible, extract structured operational information and redact or exclude the underlying text.

Sensitive Inferences

A field does not need to come directly from the customer to be sensitive.

A model might infer pregnancy, financial distress, a health condition, or another sensitive characteristic from otherwise ordinary transactions or behavior.

Treat the inference according to what it reveals, not according to the fact that it was generated by a model.

The Legal Landscape In Brief

The purpose of a CDP architecture guide is not to replace legal analysis.

It is to recognize that sensitive data requires different treatment before the technical design begins.

GDPR And UK GDPR

Article 9 generally prohibits processing special categories of personal data unless one of the listed conditions applies. Explicit consent is one possible condition, but not the only one. The categories include data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, certain biometric data, health data, and information about sex life or sexual orientation.

For a CDP team, the practical requirement is to establish the applicable condition and purpose before ingestion rather than collecting the field and resolving the basis later.

US State Privacy Laws

State requirements differ materially.

Many comprehensive state privacy regimes require opt-in consent before processing certain sensitive data, while other jurisdictions use different rights, notices, or limitation mechanisms.

Because the number and details of state laws continue to change, do not build CDP policy around a static article claiming one nationwide rule.

Maintain jurisdiction-aware policy and have counsel review the current requirements.

Consumer Health Data

Health information deserves special scrutiny even outside traditional healthcare environments.

Washington's My Health My Data Act regulates covered consumer health information and provides enforcement through Washington's Consumer Protection Act, including private action.

The practical architecture lesson is straightforward: a retail, wellness, mobile, or digital business should not assume health-related customer information is low risk simply because HIPAA does not apply.

Two Enforcement Cases That Show Where CDPs Can Go Wrong

The highest-risk failure often occurs when sensitive information moves from a customer-facing system into advertising infrastructure.

GoodRx: Health Data And Advertising Destinations

In 2023, the FTC announced its first enforcement action under the Health Breach Notification Rule against GoodRx.

The FTC alleged that GoodRx shared sensitive personal health information, including prescription medications and health conditions, with companies including Facebook, Google, and Criteo after making privacy promises to users. The matter included a $1.5 million civil penalty and restrictions on sharing health information for advertising.

The CDP lesson is not merely “protect health data.”

It is to control the full activation path.

A sensitive field can be protected perfectly inside a database and still create a serious problem if someone builds an audience from it and sends that audience to an advertising platform.

BetterHelp: Privacy Promises Must Match Activation Behavior

The FTC's final BetterHelp order required the company to pay $7.8 million for partial consumer refunds and barred it from sharing consumers' health data for advertising. The FTC alleged that BetterHelp shared information including email addresses, IP addresses, and responses to health questions with advertising platforms and other third parties despite privacy promises to consumers.

The architectural lesson is broader than healthcare.

What the privacy notice says and what the activation layer permits must agree.

If the organization tells customers one thing while the CDP allows another, the governance control has failed.

Decide First: Exclude, Transform, Keep At The Source, Or Ingest

Stable Kernel recommends treating sensitive-data ingestion as a four-option decision rather than a binary yes-or-no question.

Option 1: Exclude It At The Source

This is the strongest option when the field has no approved use case or the risk exceeds the value.

Examples include blocking a health-condition field or government identifier through the source data contract and removing the field from the form or integration.

Do not rely on downstream deletion as the primary control.

By the time the record is removed from the CDP, it may already have propagated elsewhere.

Option 2: Transform It Before Ingestion

A less sensitive representation may be enough.

Instead of storing a diagnosis, the CDP may need only a carefully governed eligibility flag.

Instead of storing precise GPS coordinates, the use case may need region.

Instead of storing a raw identifier, another system can tokenize it and expose only the surrogate value.

Transformation reduces the amount of sensitive information available to the wider platform.

Option 3: Keep It In The Source Or A Purpose-Built Store

Sometimes the raw value is necessary, but the CDP does not need to possess it.

Keep the information in the system designed to protect it and query only the answer the CDP needs.

For example, a controlled service might return whether a customer is eligible for a program without sending the underlying sensitive fact into the customer profile.

Option 4: Ingest It With Controls

Use this option only when:

• A specific purpose requires the information.
• The organization has the appropriate legal basis.
• Required consent has been obtained.
• No less sensitive alternative meets the use case.
• The business accepts the residual risk.

Before approving ingestion, answer five questions:

1. What exact purpose requires the data?
2. What basis and consent requirements apply?
3. Which destinations, if any, may receive it?
4. Can a flag, range, region, token, or on-demand lookup replace the raw value?
5. What would happen to customers and the organization if the information were exposed or misrouted?

If those questions do not have clear answers, the field is not ready to enter the CDP.

Nine Controls For Sensitive Data That Does Enter The CDP

Once sensitive information enters the platform, every control should end in a test.

1. Classify And Tag It

Tag sensitive attributes, events, and derived values using the organization's taxonomy.

Classification should include both the internal sensitivity tier and, where useful, the applicable statutory category.

Do not classify only the dataset while leaving individual high-risk fields invisible.

Test: Inventory every approved sensitive attribute and confirm each carries the expected classification.

2. Block Unapproved Fields At Ingestion

Use schema allow lists or equivalent data contracts to specify what each source may send.

Unexpected fields should be rejected or quarantined instead of automatically becoming new profile attributes.

Test: Send a fictional sensitive field through the source integration. It should fail or quarantine and generate an alert.

3. Minimize And Transform

Use the least sensitive representation capable of supporting the use case.

That may involve:

• Generalizing a value
• Tokenizing an identifier
• Hashing for a narrow matching purpose
• Replacing detail with an approved flag

Tokenization and encryption solve different problems. Tokenization substitutes a surrogate for the original value, while encryption preserves the original value in reversible form protected by a key.

Security should determine the correct combination.

Test: Confirm ordinary analysts cannot recover the original protected value.

4. Isolate Sensitive Data

Do not automatically store sensitive fields beside every general marketing attribute.

Use a restricted schema, separate store, or equivalent boundary with its own access model where appropriate.

Test: General CDP roles should not be able to query the isolated information.

5. Narrow Access

Sensitive data should be masked by default and revealed only to tasks that genuinely require it.

Use task-based roles, explicit approvals, and temporary privilege elevation where appropriate.

Test access through every route, not only the CDP interface.

Test: A restricted role should fail to retrieve the raw value through the UI, API, and export.

6. Enforce Activation Restrictions

This is one of the most important controls.

Sensitive data should generally follow a default-deny activation model.

Approved use cases and destinations are explicitly allowed. Everything else is blocked.

Derived audiences should inherit the sensitivity of the information used to build them.

A health-related customer list does not stop being sensitive merely because the raw health field is absent from the exported audience.

Adobe Experience Platform illustrates one implementation pattern: labels classify data, policies define permitted or restricted marketing actions, audiences inherit relevant labels, and policy violations can prevent activation to destinations. Adobe also makes clear that labels alone do not create enforcement. Policies have to be configured and enabled.

Other CDPs behave differently, so test your own platform rather than assuming the feature name guarantees the control.

Test: Build a fictional audience using a tagged sensitive field and attempt to activate it to an advertising destination. The action should be blocked with an auditable reason.

7. Connect Consent And Purpose To The Data

Consent cannot live only inside the banner.

The data and activation layer need to know which purposes are permitted for the customer.

Where consent is withdrawn, the change should propagate to all systems that depend on it.

Test: Revoke consent for a fictional profile and confirm sensitive processing and activation stop within the agreed window.

8. Use Short Retention And Complete Deletion

Sensitive information should generally be kept only as long as its named purpose requires.

Deletion needs to consider:

• Profile stores
• Warehouses
• Destination copies
• Backups
• Time travel
• Derived attributes

Do not delete the raw value while indefinitely preserving a sensitive inference derived from it.

Test: Allow a controlled test record to expire and verify that it disappears from every system covered by the deletion process.

9. Log, Review, And Alert

Log access, exports, destination changes, and privileged actions involving sensitive data.

Include sensitive-data access in regular access reviews and alert on events such as unusual bulk export or a new destination receiving tagged information.

Test: Export a controlled tagged dataset and confirm the event creates the expected log and alert.

Two Places Sensitive Data Hides

The most dangerous sensitive data may be information nobody classified as sensitive because it was never explicitly collected as such.

Inferences

A customer may never tell the organization they are pregnant, financially distressed, or dealing with a particular health condition.

A model may infer it.

Treat a sensitive inference with the sensitivity of what it reveals.

Document the inputs and model version, limit where the resulting value can be used, and review models for sensitive proxies.

Do not assume “machine generated” means low risk.

Free Text

Support notes, chat messages, call transcripts, and open-form responses can bypass almost every neat schema rule.

A support agent may record medical information inside a general comment field. A customer may include financial credentials in a help request.

Reduce this risk by minimizing free-text ingestion, scanning for high-risk content, redacting sensitive values where technically appropriate, and restricting the domains where raw free text is available.

The same principle applies to audience seeds.

A lookalike or suppression audience created from sensitive customers can reveal sensitive membership even if the exported record contains only identifiers.

Five Sensitive Data Tests To Run This Month

A company should be able to prove that its sensitive-data controls work without waiting for an incident.

Test 1: Ingestion Blocking

Send a fictional sensitive field through every major source.

Pass: The field is rejected or quarantined and an alert is created.

Test 2: Activation Blocking

Build a test audience based on a sensitive attribute and attempt to send it to a prohibited advertising destination.

Pass: The activation is blocked and the reason is logged.

Test 3: Masking

Query the sensitive test field as a restricted user through the interface, API, and export path.

Pass: The value is masked or access is denied in every route.

Test 4: Consent Revocation

Withdraw the relevant consent for a test customer.

Pass: The sensitive purpose stops using the data across applicable storage and activation systems within the defined service level.

Test 5: Deletion And Free-Text Detection

Delete a controlled test record and separately insert a fictional sensitive string into an approved free-text test field.

Pass: The deleted record disappears through the required cascade and the scanning control identifies the sensitive string.

Run these tests again whenever the organization adds or changes a source, destination, policy, or sensitive-data category.

When Sensitive Data Goes To The Wrong Place

Sensitive-data incidents need a rehearsed response rather than improvisation.

Contain

Pause the affected destination or audience and block the field from further activation.

If the architecture supports an activation kill switch, use it.

Scope

Use logs and lineage to determine:

• Which data was sent
• Which customers were affected
• Which destination received it
• When the transfer occurred
• Whether the data propagated further

Assess

Privacy and legal counsel determine whether regulatory or customer notification obligations apply.

Notification requirements vary by law, data type, and incident.

Do not embed one jurisdiction's deadline into a generic technical playbook.

Remediate

Where possible, delete the information from the destination, revoke access, fix the rule that failed, and rerun the relevant sensitive-data tests.

Learn

Turn the failure into a permanent regression test.

If an incident exposed a path the organization had not considered, that path should become part of future release and policy testing.

A Seven-Step Method For Handling Sensitive Customer Data In A CDP

Step 1: Classify

Identify sensitive attributes, event properties, free-text domains, and derived values.

Apply the organization's sensitivity taxonomy and statutory mappings.

Step 2: Decide

For every sensitive data element, choose among four outcomes:

• Exclude
• Transform
• Keep in the source
• Ingest with controls

Do not make ingestion the default.

Step 3: Establish The Purpose And Basis

Document the exact use case and confirm the required legal basis and consent with privacy counsel.

Purpose should be specific enough to determine what processing and activation are allowed.

Step 4: Isolate And Protect

Block unexpected fields at ingestion, minimize the stored value, tokenize or encrypt where appropriate, and isolate high-risk data from general profile access.

Step 5: Restrict Access And Activation

Mask by default.

Use narrow roles.

Treat destinations as default deny and make sensitive derived audiences inherit the same restrictions as their source attributes.

Step 6: Set Retention And Deletion

Keep the information for the shortest defensible period and verify that deletion reaches warehouses, destinations, backups, and derived data as required.

Step 7: Monitor, Test, And Rehearse

Run the five sensitive-data tests.

Alert on exports and destination changes.

Include sensitive access in access reviews.

Rehearse the incident playbook before a real failure occurs.

How Stable Kernel Approaches Sensitive Customer Data In A CDP

Stable Kernel treats sensitive-data architecture as a sequence of decisions rather than a list of security features.

Decide What Should Enter Before Protecting What Already Did

Stable Kernel can help enterprise teams classify sensitive customer data, map it to approved purposes, identify fields that should be excluded or transformed, and design ingestion boundaries so unnecessary sensitive information never becomes part of the general customer profile.

Make Sensitive-Data Restrictions Enforceable

Stable Kernel can also help design field-level protection, access boundaries, consent-aware processing, default-deny activation policies, short retention, and the tests required to prove those controls operate across the CDP and connected destinations.

If your organization can identify its sensitive attributes but cannot answer why each one is in the CDP, which destinations are technically prevented from receiving it, whether sensitive inferences inherit the same protection, and when the last enforcement test passed, the control model is incomplete.

Request a sensitive customer data assessment from Stable Kernel to classify high-risk information, decide what belongs in the CDP, design protection and activation restrictions, and build the tests that demonstrate those controls actually work.

Three Questions About Your Sensitive Data This Week

1. Can You List Every Sensitive Attribute And Inference In The Platform?

For each one, name the business purpose.

If no owner can explain why the information exists, question whether it belongs there.

2. What Stops A Sensitive Audience From Reaching Advertising?

The answer should be a technical control, not “the marketer knows not to do that.”

3. Does Your Privacy Notice Match The Activation Layer?

Compare what the organization tells customers with what the CDP can actually send downstream.

A “no” to any of these questions identifies the first control to fix.

FAQ

What Is Sensitive Customer Data?

Sensitive customer data is information that laws or company policy subject to heightened protection, such as health information, precise location, biometric or genetic data, government and certain financial identifiers, protected characteristics, children's data, and communication contents. Definitions vary by law and jurisdiction, and sensitive inferences should generally be treated according to what they reveal.

Should Sensitive Data Go Into A CDP At All?

Only when a named use case genuinely requires it, the organization has an appropriate basis for processing it, and a less sensitive representation will not meet the need. The strongest control is not ingesting the raw information. Other options include transforming the value or querying a controlled source system instead.

Do I Need Consent To Process Sensitive Data In A CDP?

Often, but the answer depends on the jurisdiction and category. GDPR Article 9 generally prohibits processing special categories unless an applicable condition exists, including explicit consent in some cases, while US state regimes use different consent and limitation models. Counsel should confirm the correct requirement for each purpose and market.

Can I Send Sensitive Data To Advertising Platforms?

Treat that as prohibited by default and require specific legal and privacy review for any exception. The FTC's GoodRx and BetterHelp matters demonstrate the risk of sharing health-related customer information with advertising platforms in ways that conflict with privacy promises. Both matters resulted in restrictions on health-data advertising use.

How Do Tokenization, Encryption, And Masking Differ?

Tokenization replaces a sensitive value with a surrogate while the original remains in a controlled system. Encryption makes the value unreadable without the appropriate key, while masking hides all or part of a value from users who do not need it. Enterprise designs often use more than one technique because they solve different problems.

Can An Inference Be Sensitive Data?

Yes. A model can derive a sensitive characteristic such as health status, pregnancy, or financial distress from otherwise ordinary behavior. Treat the inference according to what it reveals, document its inputs and intended purpose, and prevent sensitive inferred attributes from flowing into inappropriate activation.

How Do You Stop Sensitive Data From Reaching Destinations?

Classify the field, define policies specifying which uses and destinations are allowed, and enforce those policies during activation using a default-deny approach. Some CDPs provide automatic policy enforcement, but the details vary, so test with fictional sensitive fields and audiences instead of assuming labels alone are sufficient. Adobe, for example, states that labels work with configured and enabled policies to enforce marketing-use restrictions.

How Long Should Sensitive Customer Data Be Retained?

Keep it only for the period required by the approved purpose and any applicable legal obligations. Retention should cover active profile stores, warehouses, downstream destinations, recovery windows, backups, and derived information. There is no universal period that is appropriate for every sensitive category.

Can Stable Kernel Help Handle Sensitive Customer Data In A CDP?

Yes. Stable Kernel helps enterprise teams classify sensitive information, decide whether it should enter the CDP, design transformation and field-level controls, restrict access and activation, connect consent and retention to the classification, and create tests that prove the controls work. The goal is to reduce sensitive-data exposure before it becomes a governance or activation problem.