The Data Privacy Audit: What Privacy Teams Should Test

A privacy audit that confirms your policies exist is not a privacy audit. It is a document review. The question a privacy team, outside counsel, or regulator eventually asks is whether what the organization actually does with data matches what it says it does, and whether it can prove that on demand. That gap, between the privacy notice and the actual data flow, between the DSAR policy and DSAR processing time, is where the exposure lives. An effective audit tests execution, not paperwork.

Below are ten things a privacy audit should actually verify, and what it takes to have the systems in place to answer each one without a six-week scramble.

Build the Data Inventory From Your Systems, Not Your Policy

Start with what is actually running: the website, the app, the CRM, the payment processor, the HR system, the analytics stack, any AI features, the data warehouse, and every vendor integration. Map what each one collects and where it ends up. A data inventory built from policy language describes what a company intended to build. A data inventory built from systems describes what it actually built, and audits test the second one.

Concord's data mapping is a single source of truth for the systems and data across an organization, cataloged against a library of hundreds of pre-built data systems, so the map an audit pulls from is not a spreadsheet someone updated eighteen months ago.

Check the Privacy Notice Against What the Systems Actually Do

Once the inventory exists, compare it to the public privacy notice line by line: categories of data collected, purposes, third-party sharing, sensitive data handling, retention, and the rights the notice promises. A notice that describes intentions rather than reality is a liability, not a disclosure.

When the Privacy Policy and Cookie Policy are generated on the same platform as the data map and tracker inventory, that comparison happens in one place instead of across three tools and a shared drive.

Inspect the Site at the Network Level, Not Just the Cookie Banner

A cookie banner tells you what a company configured. It does not tell you what is actually firing. Trackers, pixels, session-replay tools, chat widgets, ad tags, embedded content, and fingerprinting scripts often outpace what the consent tool has cataloged, especially after a marketing team adds a new tag without looping in legal.

Concord blocks scripts, iframes, and images in the browser as they load, not only cookies. New scripts and iframes are added to the tracker inventory as visitors encounter them, and scheduled scans pick up cookies. The audit is then checking an inventory that keeps up, not a snapshot from deployment day.

Test Consent Instead of Trusting the Banner

A consent management platform is a control, and controls should be tested, not assumed. Does the banner present the correct choice in the correct jurisdiction, strict opt-in for GDPR, opt-out with a do-not-sell option for CCPA/CPRA? Does a rejection actually stop the script from firing? Does the platform honor browser-level signals like Global Privacy Control?

Concord's consent management is location- and language-aware, honors Global Privacy Control, and blocks scripts in real time rather than after the fact, which is the difference between a banner that displays correctly and one that actually restricts processing.

Look Past the Vendor List to What Vendors Actually Receive

A current vendor list is a start, not an answer. The audit question is what data each vendor receives, where they process it, how long they retain it, whether they use subprocessors, what the contract requires on deletion, and what happens to the data after the relationship ends.

Vendor relationships tracked in Concord's data mapping connect directly to the systems and data categories they touch, so a vendor review does not start from a blank document.

Run a Real DSAR From Intake to Close

The only way to know whether a data subject access request workflow works is to submit one and watch it move: intake, identity verification, retrieval across every system that holds the person's data, and a response a regulator would accept. A defensible workflow does not depend on one person who happens to know where everything lives.

Concord's privacy requests pair configurable intake forms and identity verification with a task checklist for each data system already in the data map, so retrieval does not fall to institutional memory.

Audit Retention, Not Just Collection

Every data category needs a retention period with a reason attached, and the audit has to confirm deletion actually happens, in production systems, in backups, and at vendors, not only in a retention schedule document. A litigation hold is the documented exception, not a quiet default.

Retention that is tied to a live data map, rather than a policy written once and never revisited, is what makes this testable instead of aspirational.

Flag the Processing That Needs a Documented Risk Assessment

Sensitive data, precise location, children's data, health data, large-scale profiling, behavioral advertising, automated decision-making, employee monitoring, biometrics, and AI systems all raise the bar for what needs a documented assessment before it ships. The EU AI Act in particular reshapes this for any company shipping AI features, and treating an AI policy as an afterthought is no longer viable.

Concord's AI Policy Generator, an industry first, builds AI-specific disclosures from a dedicated questionnaire instead of generic boilerplate, and regenerating it is how the policy keeps pace as your AI use changes.

Go Looking for the Technology No One Approved

Shadow technology rarely shows up in a document review. It shows up when someone asks marketing which browser extension they installed last quarter, or when sales admits they are running a call-recording tool nobody cleared. AI assistants, lead-enrichment plugins, meeting transcription tools, and experimental analytics accumulate quietly between audits.

Scheduled scanning, plus detection of new scripts as visitors load your pages, is what catches a tag that went live in March before an audit that runs in September.

Keep the Evidence, Not Just the Outcome

Consent logs, preference histories, prior versions of published privacy notices, vendor reviews, and DSAR records are what a privacy program uses to demonstrate it works, to a regulator, to outside counsel, or to a court. A program that cannot produce this evidence on request has not proven anything, no matter how current its policies look today.

A single source of truth for systems and data, maintained continuously rather than reconstructed after the fact, is what turns "we have a privacy program" into something a company can actually produce.

Path Forward

None of this is testable from a policy binder. It requires an accurate, current map of what data your systems actually touch, and proof that consent, requests, and retention behave the way your notices say they do.

That is the case for treating consent management, policy generation, privacy requests, and data mapping as one connected system instead of four separate tools bolted together after the fact. An audit against a unified platform tests one source of truth. An audit against four disconnected tools tests whether they still agree with each other, and increasingly, they do not.

Book a demo to see how Concord keeps your data map, consent records, and privacy request workflow in one place, so the next audit tests a system built to pass one.