How To Audit Customer Data Platform Access

Imagine a quarterly access review that finished on time.

Every manager reviewed the accounts assigned to them. Every line was approved or revoked. The spreadsheet was filed. Compliance marked the review complete.

Three weeks later, the security team discovers an API credential created for a former agency partner.

The credential can still read customer profiles.

It never appeared in the review because the audit population came from the identity provider, and the API key was not a human identity.

The review worked exactly as designed.

The scope was wrong.

That is one of the central challenges of auditing access to a customer data platform. Customer data can be reached through employees, administrators, contractors, service accounts, source keys, destination credentials, warehouse roles, vendor staff, reverse ETL integrations, and increasingly AI agents.

A user access list covers only part of that surface.

A customer data platform access audit is an evidence-based check that every person, service, credential, and third party with access to customer data in the CDP and its connected systems is known, authorized, appropriate for its purpose, still required, and logged, and that access marked for removal was actually revoked. A strong audit tests both the decisions made during the access review and whether the population being reviewed was complete.

This article focuses specifically on access auditing.

If you are looking for an audit of CDP financial performance and business value, that is a different exercise from auditing who and what can access customer data.

Access Review, Access Audit, And Continuous Monitoring Are Different Controls

These terms are often used interchangeably.

They should not be.

Access Review Or Recertification

An access review is the periodic business decision about whether a specific account or privilege should:

• Remain
• Change
• Be removed

The reviewer is usually the accountable business or data owner who understands whether the access is still required.

Access Audit

An access audit independently checks whether the review and the underlying controls actually worked.

It asks:

• Was the population complete?

• Were the reviewers appropriate?
• Were leavers removed?
• Were old privileges removed after role changes?
• Were high-risk credentials reviewed?
• Were revocations implemented?
• Does the organization have evidence?

Security, compliance, internal audit, or an external assessor may perform this work depending on the organization.

Continuous Monitoring

Continuous monitoring looks for risky activity between periodic reviews.

Examples include:

• A new administrator
• An unexpected privileged role change
• A dormant credential becoming active
• A new destination connection
• A large export
• Unusual service-account behavior

Monitoring does not replace access reviews or audits.

It reduces the period during which a bad change can remain unnoticed.

What Frameworks Say About Reviewing Access

The exact requirements depend on the frameworks and obligations that apply to your organization.

That determination belongs with your compliance team or assessor.

PCI DSS 7.2.4

PCI DSS v4.0 Requirement 7.2.4 requires user accounts and their related access privileges, including third-party and vendor accounts, to be reviewed at least once every six months. Inappropriate access must be addressed, and management acknowledges that the remaining access is appropriate.

Application and system accounts are addressed separately under PCI requirements that use a risk-based review frequency.

SOC 2

SOC 2 logical-access criteria require organizations to authorize, modify, review, and remove access according to their control design.

The framework does not impose one universal quarterly schedule for every organization.

A quarterly review of privileged access may be common operating practice, but it should not be presented as mandatory SOC 2 language.

ISO/IEC 27001

ISO/IEC 27001:2022 provides the information security management framework under which organizations establish and manage access-control processes. The appropriate review cadence should be defined through the organization's policies and risk-management process rather than assumed from a generic industry schedule.

NIST SP 800-53 AC-2

NIST SP 800-53 Rev. 5 requires organizations to review accounts for compliance with account-management requirements at an organization-defined frequency. It also calls for account processes to align with terminations, transfers, changes in need to know, and account removal.

Use The Strictest Requirement That Actually Applies

Do not invent a universal cadence.

Use the strictest applicable requirement and then set a risk-based schedule for access not explicitly covered by it.

Privileged, vendor, and nonhuman access may deserve more frequent review because of their risk, but the interval should be deliberate and documented.

Scope The Entire CDP Access Surface

The most important question in an access audit is not:

Who is in the user list?

It is:

What can reach customer data?

The answer is broader.

Human Users

This includes:

• CDP administrators
• Analysts
• Marketers
• Engineers
• Contractors
• Local platform users
• Users federated through SSO

The common blind spot is a local account that bypasses the identity provider or a contractor whose HR status is not reflected correctly.

Roles And Direct Permissions

Audit:

• Role assignments
• Permission sets
• Sensitive-field access
• Direct user grants
• Destination permissions
• Administrative capabilities

Direct grants deserve special attention because they can bypass the governed role model.

Service Accounts And API Credentials

Service identities may support:

• Pipelines
• Reverse ETL
• BI
• Integrations
• Data exports
• Automation
• APIs

Each credential should have a named owner, defined purpose, current scope, and rotation or expiry expectation.

An account with no identifiable owner is itself an audit finding.

Source And Write Keys

Applications and source systems may use keys to send customer events into the CDP.

These keys can become long-lived infrastructure secrets embedded in:

• Application code
• Tag managers
• SDK configuration
• Deployment variables
• Integration middleware

Audit whether they are still needed and whether the organization can rotate them safely.

Destination Credentials

CDPs store credentials for systems such as:

• Email platforms
• Advertising platforms
• CRM systems
• Warehouses
• Personalization tools

A destination may be decommissioned while its credential remains active.

The employee who configured it may also have left years ago.

The integration lifecycle and credential lifecycle need to match.

Warehouse And Connected Tool Roles

A composable or hybrid CDP expands the access surface into the warehouse and connected tools.

Audit:

• Warehouse roles
• Reverse ETL service roles
• BI connections
• Notebook access
• Transformation jobs

A user may appear appropriately restricted inside the CDP while retaining broad raw-data access through the warehouse.

Vendor And Integrator Access

Include:

• Implementation partners
• Support engineers
• Managed service providers
• Consultants
• Other external administrators

Standing vendor access should have a clear business justification and end date.

An engagement ending should trigger an access review.

AI Agents And Agent Tokens

AI-enabled systems introduce another nonhuman identity class.

Audit:

• Agent service accounts
• Tool tokens
• Model integrations
• Read versus write scope
• Customer-data field access

A read-only agent should not inherit write access simply because it uses a shared credential.

Audit Log Access

Audit logs themselves can contain sensitive security and operational information.

Treat tokens and roles that can read broad audit data as privileged access.

Nonproduction Environments

Include:

• Sandboxes
• Test workspaces
• Development databases
• Demo environments

A test environment containing copied production customer data belongs in the access audit.

“Nonproduction” does not make the data non-sensitive.

Build A Population You Can Defend

A review conducted against the wrong population produces a confidently wrong answer.

Population completeness is therefore the audit's foundation.

Extract Directly From Each System

Do not begin and end with the identity provider.

Extract account and credential lists directly from:

• CDP
• Identity provider
• Warehouse
• Source configuration
• Destination configuration
• Integration platform
• Agent platform
• Vendor systems where relevant

The identity provider can then be used for reconciliation rather than treated as the sole inventory.

Record How The Population Was Built

For every extraction, record:

• Extraction date
• Source system
• Method
• Record count
• File or evidence location

Preserve the original extract in controlled storage.

Reconcile Against HR And Contractor Records

Compare human accounts with:

• Current employee roster
• Contractor roster
• Leaver list
• Role-change records

Every unexplained account should become a candidate finding.

Assign A Reviewer To Every Line

Human access should go to the accountable business or data owner.

Service accounts and keys should go to the named technical owner.

If nobody can identify who owns a credential, stop treating that as a documentation problem.

It is an access-control problem.

Export Audit Logs Before They Age Out

Native log retention may be shorter than the period an audit needs to cover.

Adobe Experience Platform

Adobe currently retains Experience Platform audit logs for 365 days. Its UI displays the previous 90 days, while exports can cover up to 365 days in 90-day intervals.

If the organization needs evidence beyond the native window, schedule exports before the data expires.

Salesforce Setup Audit Trail

Salesforce Setup Audit Trail allows organizations to download approximately 180 days of setup-change history. Salesforce states that setup audit records are deleted after that period.

Do not wait until an annual audit to discover the evidence you need disappeared six months earlier.

Platform Capabilities Vary

Different CDPs and pricing tiers expose different:

• User APIs
• Role exports
• Audit events
• Retention periods
• Service-account inventories

Verify every platform in scope and create an external evidence-retention schedule where native retention is insufficient.

Seven Tests To Run During A CDP Access Audit

Stable Kernel recommends seven tests as a practical audit program.

Thresholds should be set locally according to risk and applicable requirements.

Test 1: Population Completeness

Confirm that every relevant system was extracted directly.

Then reconcile those lists against the identity provider, HR records, and credential inventories.

A finding exists when:

• An account appears outside the review population.
• The extraction method cannot be explained.
• A credential exists without a corresponding inventory entry.

If population completeness fails, later review decisions cannot be fully trusted.

Test 2: Leavers

Match employees, contractors, and vendor personnel who left against current access.

Check:

• CDP accounts
• Warehouse roles
• Local accounts
• Service credentials assigned to individuals
• Vendor logins

Any active access belonging to someone who has left is a finding.

Do not stop when the identity provider account is disabled if the person still owns a local platform account or API credential.

Test 3: Movers

Employees who change jobs often accumulate access.

Compare HR role changes with current CDP and warehouse permissions.

A person who moved from data engineering to another function should not automatically retain:

• Production write access
• Admin access
• Sensitive-field access
• Pipeline credentials

Removing leaver access while ignoring mover access allows privilege to compound for years.

Test 4: Dormant Access

Identify accounts and credentials that have not been used during the organization's approved inactivity window.

There is no universal 30-, 60-, or 90-day rule for every account type.

Set thresholds according to risk and expected use.

A dormant privileged key may deserve much more scrutiny than a seasonal business user.

The finding is not simply inactivity.

It is inactivity without a documented reason for retaining the access.

Test 5: Privilege And Least Privilege

Review:

• Administrators
• Sensitive-field access
• Direct grants outside roles
• Destination publication rights
• Export permissions

Compare actual privileged users with the approved role model.

Also test separation of duties.

For example, can one user both build a sensitive audience and approve its publication to a new destination?

Excess privilege increases the impact of a compromised or misused identity.

Test 6: Nonhuman And Vendor Access

Every service account, API key, destination credential, agent token, and vendor login should have:

• Owner
• Purpose
• Scope
• Rotation or expiry expectation
• Current review decision

Look specifically for:

• Shared credentials
• Credentials with no owner
• Old agency access
• Vendor accounts after the engagement ended
• AI tokens with unnecessary write scope

Test 7: Activity And Control Effectiveness

Do not only review what access exists.

Test whether the controls actually prevent prohibited actions.

Sample audit logs for:

• Privilege changes
• New destinations
• Bulk exports
• Role modifications

Then run negative tests.

A restricted user should fail when attempting to access a protected field through:

• Interface

• API
• Export

A revoked account should fail to authenticate.

A control that exists in configuration but fails the negative test is not operating effectively.

Review The Reviewers

Access reviews can fail even when the tooling works.

The reviewer process matters.

Use Independent Reviewers

The person who provisioned the access should not be the only person deciding whether it remains appropriate.

The reviewer should usually be the accountable business or data owner.

Privileged access deserves review outside the team that holds the privilege where practical.

Give Reviewers Context

Do not send an owner a list containing only usernames and roles.

Include context such as:

• Last-used date
• Role
• Privilege level
• Sensitive-data access
• Access source
• Direct grant versus role
• Business justification

A reviewer who does not understand what the permission allows will tend to approve it.

Focus Attention On Risk

Prioritize:

• Privileged access
• Sensitive-data access
• Dormant identities
• Vendor access
• Direct-grant exceptions
• Unowned credentials

Not every review cycle needs the same depth across every account.

Avoid Rubber-Stamping

Bulk approval can turn recertification into an administrative exercise.

Limit indiscriminate select-all workflows where possible and investigate review cycles in which nobody removes or changes anything.

A zero-revocation cycle is not automatically wrong.

It is a reason to inspect whether the review was meaningful.

Build An Evidence Pack An Auditor Can Follow

A completed review is not the same as defensible evidence.

The evidence pack should show the full chain from population to decision to remediation.

1. Starting Population

Preserve the complete list as it existed when the review began, including source, extraction date, and method.

2. Reviewer Decisions

For every item, record:

• Reviewer identity
• Decision
• Timestamp
• Relevant justification

3. Revocation Records

Retain the tickets or workflow records created from removal decisions.

4. Source-System Verification

This is critical.

The ticket saying “API key revoked” is not proof that the API key no longer works.

Verify removal in the system that granted the access.

5. Exception Register

Every retained exception should have:

• Owner
• Reason
• Scope
• Expiry or review date

6. Audit Logs And Negative Test Results

Preserve the extracts and scripts used to demonstrate the controls operated.

Use Controlled Evidence Storage

Do not rely solely on:

• Screenshots
• Editable spreadsheets
• Uncontrolled local files

Evidence should be protected from silent alteration and retained according to the organization's audit requirements.

Rate Findings And Verify Remediation

Not every finding carries the same risk.

Stable Kernel recommends a severity model based on the exposure created.

High-Severity Findings

Examples include:

• Incomplete audit population
• Active account for a leaver
• Unowned service account or key
• Standing vendor access after an engagement ends

These findings can directly invalidate the review or create customer-data exposure.

Medium-Severity Findings

Examples include:

• Dormant accounts
• Excess privileged accounts
• Unexplained direct grants
• Weak audit evidence

These may not indicate immediate misuse, but they weaken the control environment.

Define Remediation Windows Before The Audit

Set the target closure period for each severity in advance.

That prevents politically inconvenient findings from receiving open-ended deadlines.

Retest Before Closing

A finding is not closed when someone updates the ticket.

It is closed when the auditor verifies the control.

For access removal, check the source system.

For a privileged-role finding, rerun the role test.

For an incomplete population, rebuild the population.

Repeated findings should be tracked separately because recurrence often indicates a process failure rather than an isolated account problem.

How Often Should You Audit CDP Access?

Use the strictest review interval required by the frameworks that actually apply.

PCI DSS, for example, requires applicable user account and privilege reviews at least every six months.

For other access, define a risk-based cadence.

Consider more frequent review for:

• Privileged identities
• Service accounts
• Vendor access
• Sensitive customer data
• AI agents

Also trigger an additional review after material changes such as:

• Reorganization
• Integrator change
• Security incident
• New destination
• New AI integration
• Major platform migration

Periodic reviews catch drift.

Event-triggered reviews catch changes between cycles.

A Seven-Step Method For Auditing Customer Data Platform Access

Step 1: Define The Objective And Scope

Identify the systems, environments, applicable frameworks, customer-data sensitivity, and access classes included in the audit.

Do not limit the scope to human users.

Step 2: Build The Population

Extract users, roles, service accounts, keys, vendor access, agent identities, destination credentials, and connected-system roles directly from their source systems.

Document every extraction.

Step 3: Reconcile The Population

Compare human identities with the identity provider and HR.

Identify:

• Unknown accounts
• Leavers
• Movers
• Local identities
• Credentials without owners

Step 4: Run The Seven Tests

Test:

• Population completeness
• Leavers
• Movers
• Dormant access
• Privilege and least privilege
• Nonhuman and vendor access
• Activity and control effectiveness

Include negative testing rather than relying only on configuration inspection.

Step 5: Review The Decisions And Reviewers

Check whether reviewers were sufficiently independent, received enough context, and made meaningful decisions.

Investigate evidence of rubber-stamping or unexplained blanket approvals.

Step 6: Rate And Remediate Findings

Assign:

• Severity
• Owner
• Remediation deadline
• Required retest
• Track each item to verified closure.

Step 7: Verify, Archive, And Schedule The Next Cycle

Confirm removals in source systems.

Archive the evidence pack.

Export audit logs before native retention periods expire.

Then schedule the next periodic or event-triggered review.

Measures For CDP Access Governance

Do not reduce the audit to “completed on time.”

Track indicators that reveal whether access is actually controlled.

Useful measures include:

• Accounts discovered outside the identity provider
• Time to remove leaver access
• Dormant accounts and credentials
• Privileged accounts compared with the approved plan
• Nonhuman credentials with named owners
• Credentials with current rotation dates
• Review completion
• Revocation rate
• Reviewer decision time
• Remediation time by severity
• Repeat findings

There is no universal benchmark for these measures.

Establish local targets based on the organization's risk and operating model.

How Stable Kernel Approaches CDP Access Audits

Stable Kernel treats an access audit as a customer-data control test, not a spreadsheet certification exercise.

Map Every Route To Customer Data

Stable Kernel can help enterprise teams identify the full access surface across the CDP, warehouse, integrations, source systems, destinations, vendor access, service credentials, and AI agents.

That gives the audit a defensible population rather than assuming the identity provider contains every identity that matters.

Turn The Review Into Verifiable Evidence

Stable Kernel can also help teams reconcile access populations, run the seven audit tests, design negative tests, establish reviewer and ownership rules, build the evidence pack, classify findings, and confirm that remediation occurred in the source system.

If your current CDP access review can show who approved the user list but cannot show whether every service account, API key, vendor login, destination credential, and AI agent was on that list, or whether removed access actually stopped working, the audit has not closed the loop.

Request a CDP access audit from Stable Kernel to map the access surface, build a defensible population, test privileges and nonhuman identities, assemble audit-ready evidence, and verify that remediation actually removes access.

Three Questions Before Your Next Access Review

1. Did We Extract Access From Every System Directly?

Or did the audit begin with the identity provider and assume everything important was represented there?

2. Can We Name The Owner Of Every Credential?

That includes service accounts, API keys, destination credentials, vendor logins, and agent tokens.

An unowned credential is a finding.

3. Who Verifies The Revocation?

If a ticket says access was removed, who confirms in the actual source system that the account or credential no longer works?

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

FAQ

What Is A Customer Data Platform Access Audit?

A customer data platform access audit is an evidence-based check that every person, service, credential, and vendor with access to customer data in the CDP and connected systems is known, authorized, appropriate, still needed, and logged. It also verifies that access marked for removal was actually revoked and tests whether the population reviewed was complete.

What Should Be In Scope For A CDP Access Audit?

Include human users, roles, direct grants, service accounts, API credentials, source write keys, destination credentials, warehouse and reverse ETL roles, vendor and integrator access, AI agent tokens, audit-log access, and nonproduction environments containing customer data. The audit should cover every meaningful route to customer data rather than only identities visible in the SSO platform.

How Often Should You Audit CDP Access?

Use the strictest interval required by the frameworks that apply to your organization and set a risk-based cadence for the rest. PCI DSS 7.2.4 requires applicable user account and privilege reviews at least once every six months, while NIST SP 800-53 AC-2 leaves review frequency organization-defined. More frequent review of privileged and nonhuman access is a risk-management choice rather than a universal requirement.

What Evidence Do Auditors Expect For An Access Review?

A defensible evidence pack should include the complete starting population with extraction source and date, reviewer decisions with timestamps, resulting revocation records, source-system confirmation that removals occurred, documented exceptions, and relevant audit logs and test results. Screenshots and editable lists are weaker than controlled evidence that shows the review from population through verified remediation.

How Do You Make Sure The Access Population Is Complete?

Extract account and credential inventories directly from every system in scope rather than relying only on the identity provider. Reconcile those populations against HR, contractors, SSO identities, platform-local users, and credential inventories. Unknown accounts and unowned credentials should be investigated as candidate findings.

How Do You Audit Service Accounts And API Keys?

Inventory every service account, API key, destination credential, integration token, and agent identity. Require a named technical owner, documented purpose, appropriate scope, last-used information where available, and rotation or expiry expectations. Remove or justify credentials that no longer support an active integration.

How Do You Prevent Rubber-Stamp Access Reviews?

Use accountable reviewers who understand the business need for access, give them context such as last use and sensitivity, focus attention on higher-risk permissions, and avoid workflows that encourage indiscriminate bulk approval. Track review decisions and investigate cycles where approvals appear automatic rather than risk based.

How Do You Prove Access Was Actually Removed?

Verify the removal in the source system after the revocation workflow completes. Where appropriate, retain a dated system export, permission check, or failed authentication test demonstrating that the account, key, or permission no longer works. A completed ticket by itself proves that someone requested removal, not that removal occurred.

Can Stable Kernel Help Audit CDP Access?

Yes. Stable Kernel helps enterprise teams map the routes to customer data, build and reconcile the audit population, test human and nonhuman access, run negative tests, establish reviewer controls, create the evidence pack and findings register, and verify remediation. The objective is to turn access recertification into an audit process that can demonstrate who and what can reach customer data and why.