CDP Privacy And Security Requirements

CDP privacy and security requirements are the controls a customer data platform must provide, and the proof an enterprise buyer should demand for each, to protect customer personal data across collection, identity resolution, storage, access, activation, and deletion. A useful requirement does not simply state that a vendor must be “secure” or “compliant.” It identifies the evidence that demonstrates the control exists and the test that confirms it works in the environment the enterprise intends to deploy.

For enterprise CDP evaluations, the requirements should cover seven domains:

• Independent assurance and certifications
• Data protection and key management
• Access control, including vendor staff access
• Data residency, tenancy, and international transfers
• Logging, incident response, and resilience
• Contract terms and subprocessors
• AI and agent access to customer profiles

That last step matters because vendor selection often fails at the point where a requirement becomes a checkbox.

A vendor says it supports encryption.

The buyer checks the box.

But which databases are encrypted? What about backups? Logs? File transfers? Are encryption keys stored separately from the data? Can the enterprise control the keys? Does the same protection apply when data leaves the platform for an activation destination?

The same problem appears with access controls, deletion, residency, consent, breach notification, and AI.

A requirement is useful only when the buyer can answer three questions:

What exactly are we requiring? What evidence proves it? How will we test it?

This article addresses technical, operational, procurement, and architecture considerations. It is not legal advice. Regulatory requirements and contractual terms should be reviewed by qualified counsel and the organization’s security team.

Why A CDP Raises The Stakes For Privacy And Security

A CDP is not simply another marketing application.

Its architecture makes privacy and security failures unusually consequential.

A CDP Concentrates And Recombines Customer Data

A CRM may know contact information. An ecommerce system knows transactions. A loyalty platform knows tier and rewards. A mobile application knows behavior. A support platform knows service history.

The CDP combines those records.

The resulting profile may reveal substantially more about an individual than any source system does on its own.

That makes the CDP both a high-value business asset and a high-impact security target.

A CDP Creates New Relationships And Distributes Data

Identity resolution creates connections between records that did not previously exist.

Activation then distributes the resulting profiles or audiences to other systems, such as advertising platforms, email tools, CRM systems, warehouses, personalization engines, and analytics environments.

One incorrect access rule, identity relationship, consent state, or transfer configuration can therefore propagate across multiple destinations.

Customer Profiles Are Increasingly Read By Machines

Real-time APIs, automated workflows, recommendation systems, and AI agents increasingly query customer profiles without a human reviewing every request.

Security design therefore needs to assume that the caller may be mistaken, compromised, manipulated, or overly privileged.

OWASP’s GenAI guidance identifies prompt injection, sensitive information disclosure, and excessive agency among important risks for LLM-enabled applications. For a CDP, those risks become especially important when an AI system can read or change customer data.

Scope First: Which Requirements Should Be Knockouts?

Not every enterprise needs exactly the same CDP security requirements.

Before issuing an RFP, classify requirements as:

• Knockout: Failure removes the vendor from consideration.
• Must Have: Required before production use, but potentially remediable during contracting or implementation.
• Nice To Have: Valuable but not required for the intended deployment.

Stable Kernel recommends setting those tiers based on the data being processed, jurisdictions involved, regulatory environment, architecture, and planned use cases.

If You Process Data About EU Or UK Residents

Likely requirements include explicit residency information for every relevant store, an executed data processing agreement, subprocessor transparency, a defined transfer mechanism, and support for transfer impact assessments where required.

For EU–US transfers, organizations should verify whether the vendor relies on the EU–US Data Privacy Framework, Standard Contractual Clauses, or both.

As of October 27, 2026, the appeal in Latombe v Commission, C-703/25 P, challenging the Data Privacy Framework adequacy decision, remains pending before the Court of Justice. That makes it prudent to verify the vendor’s current transfer mechanism rather than assuming one framework will remain sufficient indefinitely.

If You Operate In A Regulated Industry

Financial services, healthcare, insurance, and other regulated enterprises may need stronger controls around independent assurance, key management, vendor access, audit rights, and data minimization.

SOC 2 Type II may be a knockout. Healthcare organizations may also require HIPAA-related contractual and technical controls where applicable.

The important point is to have counsel and security determine which regimes apply before the vendor demonstration begins.

If The CDP Will Hold Sensitive Data

Health data, biometric information, precise location, children's data, and other high-risk categories warrant stricter treatment.

Requirements may include:

• Field-level classification
• Masking or tokenization
• Stronger consent controls
• Shorter retention periods
• More restrictive access
• A documented decision about whether the data should enter the CDP at all

The strongest security control for an unnecessary sensitive attribute is often not collecting it.

If AI Agents Will Read Customer Profiles

Require scoped agent identities, tool-level permissions, complete audit trails, model-provider disclosure, and contractual restrictions against training on customer data without permission.

High-impact agent actions should require stronger authorization and, where appropriate, human confirmation.

If The CDP Serves Multiple Brands Or Regions

A shared enterprise CDP should support separation across brands, legal entities, and jurisdictions.

Requirements may include per-brand permissions, regional deployment options, centrally managed policies, and local stewardship.

The larger the shared service, the more important those boundaries become.

The CDP Privacy And Security Requirements Register

The following seven domains form the core requirements register.

The exact tier should be set by the enterprise. The requirement, evidence, and verification logic should remain explicit.

Domain 1: Independent Assurance And Certifications

Independent assurance does not prove that a platform is secure in every situation, but it gives the security team a structured body of evidence to evaluate.

Current SOC 2 Type II Coverage

For many enterprise buyers, a current SOC 2 Type II report covering the actual CDP service should be a must have or knockout.

Evidence to request:

• Full report under NDA
• Reporting period
• Trust Services Criteria included
• Scope of systems and products
• Exceptions and management responses
• Bridge letter if the reporting period has ended

Verify: Confirm that the service you intend to purchase is actually inside the report scope.

A Type I report covers control design at a point in time. A Type II report evaluates whether controls operated during an observation period.

Red flags include a Type I report presented as equivalent evidence, “SOC 2 in progress” without a completed report, or a report whose scope excludes the CDP product.

ISO/IEC 27001

Request the vendor’s current ISO/IEC 27001:2022 certificate and scope statement.

Verify that the certificate covers the product, hosting environment, and organizational entities involved in service delivery.

ISO/IEC 27701

Where privacy information management is important, ISO/IEC 27701 can provide additional evidence around the vendor's privacy management system.

It complements security assurance. It does not by itself establish compliance with every applicable privacy law.

Independent Penetration Testing

Request evidence of a recent independent penetration test and remediation status for material findings.

An internal vulnerability scan alone is weaker evidence.

The security team should understand whether high-severity findings remain open and whether the tested environment represents the service being purchased.

Domain 2: Data Protection And Key Management

Encryption claims need to cover the entire data lifecycle.

Encryption In Transit

Require TLS 1.2 or stronger, subject to the enterprise security standard, across:

• Web interfaces
• APIs
• SDK traffic
• File transfers
• Service-to-service communication

Red flag: any path that transmits customer data in plaintext.

Encryption At Rest

Require strong encryption for customer data stored in:

• Operational databases
• Object storage
• Backups
• Logs
• Temporary storage

The enterprise security team should determine the acceptable algorithms and implementation standard.

Key Management

The vendor should document how encryption keys are:

• Generated
• Stored
• Accessed
• Rotated
• Retired

Keys should not simply live beside the data they protect.

Enterprises with stricter requirements should evaluate customer-managed key capabilities and understand exactly which services those keys cover.

Field-Level Protection

Sensitive attributes may require hashing, masking, or tokenization.

Do not accept a feature statement alone.

Run a test.

Send a protected identifier through the intended activation workflow and confirm that a user, application, or destination without permission cannot access the raw value.

Data Minimization At Ingestion

The CDP should support schema controls or field allow lists.

A useful proof-of-concept test is to send an intentionally unapproved field.

The system should reject or quarantine it rather than silently add it to the customer profile.

Retention And Secure Deletion

Retention requirements should cover more than the primary profile database.

Ask how deletion applies to:

• Backups
• Logs
• Data lakes
• Staging stores
• Downstream systems

A vendor that promises immediate profile deletion while retaining the same customer information indefinitely elsewhere has not solved the full requirement.

Domain 3: Access Control And Vendor Staff Access

Internal access deserves the same scrutiny as external threats.

Enterprise Identity And Provisioning

Require SSO using the organization’s approved federation mechanism, MFA, and automated user provisioning and deprovisioning through SCIM where appropriate.

Verify which pricing tier actually includes these features.

A feature that exists only in a package the company is not buying is not part of the security design.

Role And Attribute-Based Access

The platform should support sufficiently granular roles to enforce least privilege.

Where sensitive customer information is involved, field-level restrictions may be necessary.

Run the test through all access paths:

• User interface
• API
• Export

A role that hides a sensitive field in the UI but can export it through the API is not properly restricted.

Vendor Employee Access

Ask how vendor employees obtain access to customer data during support or incident response.

Stronger designs use:

• Least privilege
• Just-in-time approval
• Time-limited access
• Logging
• Named employee identity

Red flags include broad standing access, missing logs, or support access from regions the enterprise did not approve.

API Credential Management

API keys and credentials should be scoped, rotatable, revocable, and protected from unnecessary exposure.

Test whether a credential can be rotated or revoked without creating unacceptable downtime.

Domain 4: Data Residency, Tenancy, And International Transfers

Residency claims frequently sound simpler than the architecture actually is.

Residency Must Cover Every Relevant Store

Request an architecture diagram showing where the following live:

• Primary profile store
• Backups
• Logs
• Analytics systems
• Support tooling
• Temporary processing
• Identity services

“EU hosting” is insufficient if logs or support data are transferred elsewhere.

Ask whether residency is included in the contracted deployment or is an additional paid option.

Tenant Isolation

The vendor should explain whether isolation is logical or physical and how the control is tested.

Do not stop at “we are multi-tenant.”

Ask for evidence of the mechanisms that prevent one customer's users or workloads from reaching another tenant's data.

International Transfer Mechanisms

For transfers outside the EEA, document the mechanism the vendor relies upon and the fallback available if legal circumstances change.

The EU–US Data Privacy Framework remains in force, but its adequacy decision is currently under appeal before the Court of Justice. Enterprises should therefore recheck the status during vendor review and consider how Standard Contractual Clauses and transfer impact assessment support fit the architecture.

Government Access Requests

Request the vendor's government-access request policy and transparency practices.

A complete vendor review should understand how the provider evaluates, responds to, and reports legally binding requests where permitted.

Domain 5: Logging, Incident Response, And Resilience

A secure system needs evidence after something changes or goes wrong.

Exportable Audit Logs

Audit logs should record meaningful administrator and user actions and be exportable to the enterprise SIEM where required.

Test the export.

Check whether the log includes:

• User or service identity
• Timestamp
• Action
• Object affected
• Administrative changes
• Relevant access events

A vendor saying “we keep logs” is different from providing logs the customer can actually investigate.

Documented Incident Response

Request the incident response process and evidence that it has been exercised.

The program should identify escalation paths, communication responsibilities, and customer notification mechanisms.

Breach Notification

GDPR Article 33 requires a controller to notify the competent supervisory authority without undue delay and, where feasible, within 72 hours after becoming aware of a qualifying personal data breach. The processor has a separate obligation to notify the controller without undue delay; GDPR itself does not impose a fixed 24-hour processor deadline.

For that reason, enterprises commonly negotiate a specific processor-to-controller notice window in the DPA so the controller has enough time to investigate and meet its own obligations.

The exact contractual window should be agreed with counsel.

Availability And Disaster Recovery

Require stated recovery time and recovery point objectives appropriate to the use case.

Request evidence of disaster recovery testing.

A CDP supporting time-sensitive customer activation needs stronger resilience expectations than an offline analytical store.

Vulnerability Management

Ask for the vendor’s vulnerability management and patching policy and compare it with penetration-testing evidence.

A policy promising rapid remediation means little if material findings remain open without explanation.

Domain 6: Contract Terms And Subprocessors

Technical controls and contractual controls need to agree.

Data Processing Agreement

The DPA should address the processing relationship, including obligations relevant to the deployment.

Typical areas for counsel to evaluate include:

• Processing on documented instructions
• Confidentiality
• Security measures
• Assistance with data subject requests
• Assistance with required impact assessments
• Deletion or return at termination
• Audit or inspection rights
• Breach notification
• International transfer mechanisms

Subprocessor Transparency

Request the current subprocessor list, processing locations, notification mechanism for changes, and contractual rights applicable when subprocessors change.

A CDP may depend on infrastructure providers, support systems, analytics services, and AI model providers.

The buyer needs to know who else can touch customer data.

No Unapproved Secondary Use

The contract should state whether the vendor can use customer data to:

• Train AI models
• Benchmark customers
• Create aggregated insights
• Develop unrelated products
• Sell information or derived insights

If the enterprise does not authorize those uses, the contract should say so explicitly.

A default right hidden in general terms is a red flag.

Deletion, Return, And Portability

The enterprise should know how it gets its data back and how the vendor deletes remaining copies when the relationship ends.

Request a representative export during evaluation.

Portability should be tested before the company becomes dependent on the platform.

DPIA Support

Where systematic profiling, large-scale processing of sensitive information, or another high-risk use may trigger a Data Protection Impact Assessment, the vendor should provide the information the enterprise needs to perform one.

Whether a specific deployment legally requires a DPIA is a determination for counsel.

Domain 7: AI And Agent Access To Customer Profiles

AI creates a new privileged access path into the CDP.

It should be governed as such.

Use Individual Service Identities

Agents and automated services should use scoped, identifiable identities rather than one shared account or static credential.

Every action should be traceable to the caller that performed it.

Authorize At The Tool And Field Level

An agent should receive only the tools and data its task requires.

Separate:

• Read access
• Write access
• Sensitive-field access
• High-impact actions

An agent allowed to summarize a customer profile does not automatically need permission to edit it.

For consequential actions, human confirmation can provide an additional control.

OWASP describes excessive agency as the risk created when an LLM-enabled system is given permissions or capabilities that allow damaging actions following unexpected or manipulated model output.

Log Every Agent Call

Audit trails should record the identity, tool call, customer or profile involved, operation performed, and relevant profile state.

That makes agent activity investigable rather than opaque.

Defend Against Prompt Injection And Data Disclosure

Prompt injection can cause an AI system to disregard intended instructions or attempt unauthorized tool actions. Sensitive information disclosure can expose PII or other confidential information through model output.

Ask the vendor for evidence covering:

• Input handling
• Output filtering
• Sensitive-data masking
• Tool authorization
• Testing against malicious prompts

Authorization should be enforced outside the language model rather than depending on the model's willingness to follow instructions.

Disclose Model Providers And Training Terms

The enterprise should know:

• Which model providers process customer data
• In which regions processing occurs
• Whether prompts or outputs are retained
• Whether customer data is used for training
• Whether the AI feature can be disabled

Undisclosed model providers are a serious procurement concern.

Privacy Capabilities The Product Must Provide

Security controls alone do not complete the requirements register.

The platform should also support the privacy operations the enterprise needs to run.

At minimum, evaluate whether the CDP can support:

• Consent and opt-out enforcement at segmentation and activation
• Per-destination consent tests
• Erasure and correction across relevant destinations
• Attribute-level retention rules
• Field classification
• Purpose tags
• Data subject request workflows
• Audit evidence

Privacy capability claims should be tested in the same way as security claims.

Create an opted-out test customer. Attempt activation. Delete a test profile. Trace what happens downstream.

The result is more useful than a feature checklist.

Packaged, Composable, And Hybrid CDPs Have Different Security Responsibilities

A composable architecture can give the enterprise more control.

That does not automatically make it more secure.

It transfers more responsibility to the enterprise.

Where Customer Data Lives

In a packaged CDP, the profile normally lives primarily in the vendor-managed environment.

In a warehouse-native or composable approach, much of the data may remain in the enterprise warehouse while identity, transformation, and activation services interact with it.

That changes whose certifications, regions, and controls matter.

Every component that touches customer data still requires review.

Encryption And Key Responsibility

Packaged vendors usually operate the encryption infrastructure, sometimes offering customer-managed keys.

In composable environments, the enterprise may control warehouse encryption and keys directly.

That gives more control, but it also means the enterprise owns configuration and rotation.

Access Control

A packaged platform may provide one role model.

A composable stack may combine warehouse roles with separate permissions across identity, transformation, orchestration, reverse ETL, and activation services.

Security needs to be mapped across the whole chain so one tool does not become an unintended bypass.

Residency

A warehouse in the required region does not guarantee that every composable component processes data in the same region.

Review identity services, activation tools, logs, support systems, and subprocessors individually.

Audit Evidence

A packaged architecture may centralize much of its logging.

A composable environment often requires evidence from several systems.

The organization should have a way to combine those records into an effective investigation trail.

Vendor Review Surface

A packaged implementation may concentrate risk in one major vendor.

Composable architectures can spread the review across several providers.

More control therefore comes with more security ownership.

A hybrid architecture requires both views.

From Requirements To A Verified CDP Vendor: Six Steps

Step 1: Set Scope And Tiers

Determine which requirements are knockout criteria, must haves, and nice to haves.

Security, privacy, legal, procurement, engineering, and the CDP program team should agree on the classification before vendor scoring begins.

Otherwise important controls tend to become negotiable once a preferred product performs well in a demonstration.

Step 2: Pre-Qualify On Knockouts

Send shortlisted vendors a concise pre-qualification questionnaire before the full RFP.

Require written answers and the evidence required for every knockout.

Do not spend weeks evaluating functionality before discovering that the vendor cannot satisfy a non-negotiable residency or contractual requirement.

Step 3: Read The Evidence

Do not substitute a trust-center badge for the underlying evidence.

For SOC 2, inspect scope, reporting period, criteria, and exceptions.

For ISO certifications, inspect scope and version.

Read the DPA and subprocessor list.

Review penetration test findings, access policies, incident response documentation, and architecture diagrams.

Step 4: Test The Controls

Run tests on representative data and the actual product configuration wherever possible.

Useful proof-of-concept tests include:

• Restricted-role test: confirm a limited user cannot access sensitive attributes through the UI, API, or export.
• Field-protection test: send protected identifiers to a test destination and verify raw values remain inaccessible.
• Vendor-access review: inspect a sample support-access log and approval process.
• Residency walkthrough: trace primary storage, backups, logs, support tooling, and analytics through the architecture.
• Deletion test: delete a test profile and collect evidence from relevant destinations.
• Consent test: confirm an opted-out test profile is excluded from every applicable activation destination.
• Audit-log test: export logs and verify they contain the events the security team needs.
• Incident tabletop: simulate a security incident and measure whether the vendor's notification and escalation process works as contracted.

Vendor capabilities should be demonstrated, not assumed.

Step 5: Negotiate And Document

Translate the verified technical requirements into contractual commitments where appropriate.

Examples include:

• Breach-notification window
• Subprocessor notification
• Objection rights
• Secondary-use restrictions
• Data return and deletion
• Audit rights
• Transfer mechanism
• SCC fallback where required

A capability shown in a demo but absent from the purchased tier or contract can disappear when the implementation begins.

Step 6: Re-Verify Annually And When The Architecture Changes

Security review is not a one-time procurement event.

At minimum:

• Collect updated SOC 2 reports.
• Review new subprocessors.
• Recheck transfer mechanisms.
• Review recent penetration testing.
• Revalidate residency.
• Reassess new AI features.
• Repeat critical proof-of-concept tests after meaningful architectural changes.

A vendor that passed the assessment three years ago may not represent the same risk today.

CDP Security Red Flags That Should Pause An Evaluation

Several findings should trigger deeper review before the vendor progresses:

• SOC 2 is “in progress” with no completed report, or the report excludes the CDP product.
• The vendor relies only on a Type I report where ongoing control operation is required.
• Encryption keys are stored with the data or secrets are handled manually.
• SSO or SCIM is missing, or available only on a tier the enterprise will not purchase.
• Residency covers the primary database but not backups, logs, support tools, or analytics.
• The vendor cannot provide a current subprocessor list or advance notice of changes.
• AI model providers are not disclosed.
• Customer data can be used for model training or benchmarking by default.
• Vendor employees maintain broad standing access to customer data.
• Audit logs cannot be exported.
• The vendor refuses a representative proof of concept.
• Deletion cannot be demonstrated beyond the primary profile store.

None automatically proves the platform is unsafe.

Each is a reason to stop and resolve the uncertainty before signing.

How Stable Kernel Approaches CDP Privacy And Security Requirements

Stable Kernel treats privacy and security requirements as evaluation criteria that need evidence and validation, not procurement language that sits beside the functional requirements.

Create The Requirements Register Before Vendor Scoring

Stable Kernel can help facilitate a requirements workshop with security, privacy, legal, procurement, engineering, and the CDP program team.

The output can include:

• Knockout criteria
• Must-have requirements
• Nice-to-have requirements
• Evidence required from each vendor
• Proof-of-concept test criteria
• Contract and DPA review items
• Owners and sign-off requirements

That gives the evaluation team a security and privacy standard before a preferred vendor begins influencing what is considered “necessary.”

Verify The Claims Before The Contract

Stable Kernel can also help translate the register into the vendor questionnaire, RFP, proof-of-concept plan, and implementation acceptance criteria.

If your CDP vendor evaluation currently asks whether a platform is SOC 2 certified, encrypts data, supports GDPR, or offers role-based access but does not specify which evidence to inspect or how to test those controls, the evaluation is incomplete.

Request a CDP privacy and security requirements assessment from Stable Kernel to define the knockout criteria, build the evidence register, design the proof-of-concept tests, and turn vendor security claims into verifiable requirements before the platform is selected.

Three Questions For Your Security And Privacy Leads This Week

1. Do We Hold The Actual Assurance And Contract Evidence?

For each shortlisted vendor, do you have a current SOC 2 Type II report whose scope and period someone has reviewed?

Do you also have the proposed DPA and its actual breach-notification language?

If not, that is the next request.

2. Can The Vendor Show Where Every Copy Of Customer Data Lives?

Ask for an architecture diagram covering:

• Primary databases
• Backups
• Logs
• Analytics
• Support tooling
• Subprocessors
• AI providers

If the vendor cannot identify where the data goes, residency and deletion requirements cannot be validated.

3. Have We Tested The Controls Instead Of Reading About Them?

Before selection, run at least:

• One access-control test
• One consent-enforcement test
• One deletion test

A “no” identifies the gap between the vendor's security story and verified behavior.

FAQ

What Privacy And Security Requirements Should A CDP Meet?

A CDP should be evaluated across seven areas: independent assurance, data protection and key management, access control including vendor staff access, data residency and transfers, logging and incident response, contract terms and subprocessors, and AI or agent access. Each requirement should specify both the evidence the vendor must provide and the test the enterprise will use to verify it.

Which Security Certifications Should You Require From A CDP Vendor?

Many enterprise buyers require a current SOC 2 Type II report covering the CDP service and an ISO/IEC 27001:2022 certificate. ISO/IEC 27701 may provide additional privacy-management assurance where relevant. Always inspect scope, period, exceptions, and a recent independent penetration-testing summary rather than relying on badges.

What Is The Difference Between SOC 2 Type I And Type II?

A SOC 2 Type I report assesses control design at a particular point in time, while a Type II report evaluates operation of those controls over a period. That makes Type II stronger evidence when the buyer needs confidence that controls work consistently. The enterprise should still confirm that the report covers the actual CDP product and environment being purchased.

What Should A CDP Data Processing Agreement Include?

A DPA should address the processor relationship, security requirements, confidentiality, assistance with data subject rights and required assessments, deletion or return, audit rights, subprocessors, breach notification, transfer mechanisms, and other terms counsel determines are necessary. Enterprises should also address whether customer data can be used for AI training, benchmarking, or other secondary purposes.

How Should A CDP Handle EU–US Data Transfers?

The vendor should identify the legal transfer mechanism it relies on and support the documentation the enterprise requires. The EU–US Data Privacy Framework remains in force, but its adequacy decision is under appeal in case C-703/25 P as of October 27, 2026, so enterprises should recheck the status and understand whether Standard Contractual Clauses and transfer-impact-assessment support are available.

How Quickly Must A CDP Vendor Notify You Of A Breach?

Under GDPR Article 33, a processor must notify the controller without undue delay after becoming aware of a personal data breach. The controller's separate supervisory-authority obligation is without undue delay and, where feasible, within 72 hours for qualifying breaches. GDPR does not itself impose a fixed 24-hour processor deadline, so enterprises should negotiate an appropriate contractual notice period with counsel.

Is A Composable CDP More Secure Than A Packaged CDP?

Not automatically. A composable architecture gives the enterprise more direct control over data location, warehouse security, encryption keys, and governance, but it also transfers more responsibility to the enterprise and expands the number of components and vendors requiring security review. Both architectures should be evaluated against the same requirements register.

What Security Requirements Apply To AI Features And Agents In A CDP?

Require scoped service identities, tool-level authorization, separate read and write permissions, strong audit trails, and human confirmation for high-impact actions where appropriate. The vendor should also demonstrate defenses against prompt injection and sensitive information disclosure, disclose model providers and processing locations, and confirm whether customer data is retained or used for model training.

Can Stable Kernel Help Define And Verify CDP Privacy And Security Requirements?

Yes. Stable Kernel helps enterprise teams turn privacy, security, legal, and procurement needs into a tiered requirements register with evidence and test criteria, then incorporate those requirements into vendor pre-qualification, RFPs, proofs of concept, and implementation acceptance criteria. The objective is to verify the controls before the organization commits to the platform.