A privacy audit is often mistaken for a document review.
Open the privacy policy. Check the DPA. Look at the consent form. Write a report.
That approach misses the most important question:
Does the company's actual data processing match what the company says it does?
For a SaaS or consumer product, the answer lives across databases, cloud storage, analytics, logs, vendors, product flows, and operational teams.
What a real privacy audit covers
A useful audit usually has six layers:
- Governance
- Data inventory
- Notice and consent
- Rights and deletion
- Third parties
- Security and evidence
The exact scope depends on the business and applicable laws.
Step 1: Define the audit scope
Do not start with “audit everything.” Pick the boundary.
Examples:
- Customer-facing product
- Indian personal data
- Marketing stack
- KYC environment
- AI processing workflow
- Enterprise customer environment
State:
- Systems
- Data subjects / Data Principals
- Jurisdictions
- Processing activities
- Time period
Step 2: Discover the data
Start with infrastructure.
Find:
- Databases
- Buckets
- Warehouses
- Logs
- Analytics
- SaaS tools
- Backups
- Test environments
Then identify personal data.
This is where automated discovery is useful because interview-based inventories routinely miss copies.
Step 3: Compare processing to the notice
For each material processing activity:
Observed system behaviour
vs.
Published notice
Find mismatches.
Example:
Policy:
We use email for account communications.
Production:
Email is also sent to the marketing platform for behavioural targeting.
That is a finding.
Step 4: Test consent
Do not just inspect the checkbox.
Test:
- Notice shown
- Action captured
- Purpose recorded
- Withdrawal
- Downstream propagation
- Evidence
A consent database entry is not proof that every processor stopped processing.
Step 5: Test rights
Pick a real test user and simulate:
- Access
- Correction
- Erasure
- Grievance
Time the workflow.
See how many people have to get involved.
Then check whether the final evidence is enough to reconstruct what happened.
Step 6: Audit processors
Build a vendor inventory and classify roles.
Check:
- Contract
- Purpose
- Data categories
- Location
- Sub-processors
- Deletion path
- Security assurance
- Breach notification expectations
Step 7: Test retention
Pick categories where teams claim a retention period.
Then inspect the actual system.
Policy says 90 days
↓
Database says 3 years
The system wins.
Step 8: Review evidence
A mature program can answer:
Show me what happened to this user's data.
Not:
“We believe we do this.”
Evidence may include:
- Consent events
- Rights requests
- Deletion actions
- Vendor communications
- Configuration states
- Security logs
- Remediation tickets
The audit output
A good report should separate:
Statutory gap
A requirement is not being met.
Control weakness
A control exists but is unreliable or incomplete.
Best practice
An improvement that is useful but not necessarily a legal requirement.
This distinction stops audits from turning into giant lists of “recommendations” with no prioritisation.
Prioritise findings
Rank by:
- Regulatory exposure
- Data sensitivity
- Scale
- Likelihood
- Ease of remediation
- Dependency on vendors
Then assign owners and dates.
Common failure modes
Point-in-time audit with no follow-up.
Only legal interviews.
Only security tests.
No processor testing.
No evidence verification.
Where Privra fits
Privra combines continuous discovery, privacy analysis, implementation workflows, and evidence generation so the audit becomes a starting point for remediation rather than a one-off PDF.
The best audit result is not a high score.
It is knowing exactly what must change and having proof that it changed.