6.2 Auditing the Privacy Program

Certified Information Privacy Manager CIPM

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 CIPM Exam Facts & Format 1.2 The CIPM Body of Knowledge: Six Domains & How the Exam Is Built 1.3 Study Strategy, Timeline & How to Use This Guide

2 Domain I: Developing a Privacy Program Framework

2.1 Program Scope, Strategy & Governance Model 2.2 Stakeholders, Privacy Team Structure & Common Vocabulary 2.3 Applicable Regulations, Oversight Agencies & Non-Compliance Impact 2.4 Personal Information Sources, Cross-Border Operations & AI Privacy Risk 2.5 Business Model, Operating Environment & Risk Appetite 2.6 Structuring the Privacy Team: DPO, CPO, Representatives & Resourcing 2.7 Vision, Mission & the Privacy Program Communication Plan 2.8 Policy Access, Version Control & Role-Relevant Updates 2.9 Codes of Conduct, Certifications & Self-Certification Mechanisms

3 Domain II: Establishing Program Governance

3.1 Privacy Policies & Life-Cycle Processes 3.2 Breach, Complaint, DSR & Retention Plans 3.3 Roles, Responsibilities, Metrics & Continuous Legal Monitoring 3.4 Training & Awareness Activities 3.5 Governance Bodies, Program Charter & Escalation Paths 3.6 Governing Internal & External Data Sharing and Disclosure 3.7 Retention Schedules & Defensible Disposal 3.8 Regulatory Change Monitoring & Enforcement Systems

4 Domain III: Operational Life Cycle — Assessing Data

4.1 Data Inventories, Flows & Life-Cycle Mapping 4.2 Data Discovery, System Integrations & Keeping the Inventory Current 4.3 Policy Compliance Measurement & Gap Analysis 4.4 Processor/Vendor Evaluation & Physical/Environmental Controls 4.5 Third-Party Risk Life Cycle & Sub-Processor Chains

5 Domain III (continued): Assessing Data — Technical & Physical Controls, M&A Risk

4.6 Technical Controls, Use/Retention Limits & Data Location 4.7 Physical & Environmental Controls in Depth 4.8 Mergers, Acquisitions & Divestitures Data Risk

6 Domain IV: Operational Life Cycle — Protecting Personal Data

5.1 Information Security Practices, Data Classification & Access Controls 5.2 Privacy by Design Principles & the SDLC 5.3 Organizational Guidelines for Data Use & Secondary-Use Governance 5.4 Privacy-Enhancing Technologies & Technical Control Enforcement 5.5 Technical, Administrative & Organizational Measures 5.6 Access Reviews, Monitoring & Enforcing Technical Controls

7 Domain V: Operational Life Cycle — Sustaining Program Performance

6.1 Privacy Metrics for Program Performance 6.2 Auditing the Privacy Program 6.3 Continuous Assessment: PIA, DPIA, TIA, LIA & PTA 6.4 Risk Mitigation, Post-M&A Assessment & Ethical AI Use

8 Domain VI: Operational Life Cycle — Responding to Requests & Incidents

7.1 Data Subject Access Requests & Consent/Rights Processes 7.2 Global Privacy Legislation on Data Subject Rights 7.3 Incident Handling, Breach Response & Records 7.4 Post-Incident Review & IR Plan Improvement 7.5 Privacy Notices & Transparency Obligations 7.6 Complaint Handling & Regulator Interaction 7.7 Breach Communications to Regulators, Individuals & Other Stakeholders

9 Final Review & Exam Strategy

8.1 Mixed-Domain Scenarios & Common Exam Traps 8.2 Test-Day Logistics, Score Strategy & Credential Maintenance

6.2 Auditing the Privacy Program

Key Takeaways Explain This Topic AI

An audit is a risk-based, scoped examination against defined criteria — not a fishing expedition; V.B requires the privacy manager to understand the types, purposes, and life cycles of audits and to select the applicable form of monitoring based on program goals rather than applying the same depth everywhere

First-party audits are conducted by the organization's own audit function on itself; second-party audits are conducted by a customer (or its auditor) on a supplier/vendor; third-party audits are conducted by independent certification bodies or regulators — the exam tests the parties and their distinct purposes

The audit life cycle has five sequential stages — plan, fieldwork, report, remediation, follow-up — and skipping a stage weakens both audit value and the program's ability to remediate; findings are closed at follow-up after remediation is validated, not when the report is issued

Continuous monitoring (automated control telemetry, log analysis, drift detection) is a complement to point-in-time audits, not a replacement — continuous monitoring catches drift between audits; periodic audits provide independent assurance and depth that automation cannot

Compliance monitoring audits against industry standards (ISO/IEC 27701, NIST Privacy Framework), regulatory changes (new DPA guidance), and legislative changes (CPRA amendments, EU AI Act) — a regulatory-change audit asks whether controls are still sufficient under the new rule

Last updated: August 2026

Audits as a Control-Evaluation Tool

Auditing is the systematic, independent examination of the privacy program's controls, policies, and processes to determine whether they are designed appropriately and operating effectively. The CIPM Body of Knowledge (V.B) expects the privacy manager to understand the types and purposes of audits, select the right form of monitoring for each program goal, and complete compliance monitoring against industry standards and regulatory or legislative changes. An audit is not a fishing expedition — it is a risk-based, scoped examination against defined criteria.

Internal vs External Audits

Internal audits are conducted by the organization's own audit function (or a functionally independent internal team) and report to the audit committee or board. Their purpose is continuous improvement and early detection. External audits are conducted by outside parties — regulators, certification bodies, or third-party auditors engaged by the organization. Their purpose is independent assurance, certification (e.g., ISO/IEC 27701, ISO/IEC 27001), or regulatory enforcement.

First-, Second-, and Third-Party Audits

The exam distinguishes three audit parties by who performs the audit and who is audited:

Party Auditor Audited Purpose Example

First-party Organization's own audit function The organization itself Internal assurance and continuous improvement Internal audit of the DSR process

Second-party A customer (or its auditor) A supplier/vendor Vendor-risk assurance before or during a contract A bank audits its cloud processor's privacy controls

Third-party Independent certification body Any organization Independent certification or regulatory inspection ISO/IEC 27701 certification audit by an accredited body; a DPA inspection

A common exam trap is confusing a second-party audit (customer-audits-vendor) with a vendor's own internal first-party audit of itself. A vendor's SOC 2 Type II report is a third-party attestation the customer can rely on; the customer's own on-site audit of the vendor is a second-party audit.

Audit Life Cycle

A mature audit follows a defined life cycle. Skipping a stage weakens the audit's value and the program's ability to remediate findings.

Stage Activities Output

1. Plan Define scope, objectives, criteria, and risk; confirm resources and schedule; notify auditee Audit plan / engagement letter

2. Fieldwork Test controls, interview personnel, review evidence, sample transactions Working papers, draft findings

3. Report Classify findings (critical/high/medium/low), agree findings with auditee, issue audit report Audit report with agreed findings

4. Remediation Auditee develops and implements corrective action plan; owner and due date per finding Corrective action plan (CAP)

5. Follow-up Auditor validates that remediation is effective and sustained; closes findings Follow-up report; finding closure

Findings are closed at follow-up after the auditor validates that remediation is effective and sustained — not when the report is issued and not when the auditee declares the fix complete. This is a frequent exam point.

Continuous Monitoring vs Point-in-Time Audit

A point-in-time audit is a snapshot — it tells you the control was effective on the day tested. Continuous monitoring uses automated tooling (log analysis, configuration drift detection, DLP dashboards, control telemetry) to test controls on an ongoing basis. The exam treats continuous monitoring as a complement to, not a replacement for, periodic audits: continuous monitoring catches drift between audits; periodic audits provide the independent assurance and depth that automation cannot.

Selecting the Form of Monitoring

The BoK requires the privacy manager to select applicable forms of monitoring based upon program goals — audits, control testing, or subcontractor monitoring — rather than applying the same depth everywhere. High-risk processing, new systems, and new vendors warrant audit-grade scrutiny; mature, low-change processes may warrant continuous monitoring with a lighter periodic audit. Subcontractor monitoring may include right-to-audit contract clauses, third-party attestations (e.g., SOC 2 Type II), or on-site second-party audits depending on the data sensitivity and risk.

Compliance Monitoring Against Standards and Legal Change

The privacy manager audits not only against the organization's own policies but also against industry standards (ISO/IEC 27701, NIST Privacy Framework, AICPA Trust Services Criteria), regulatory changes (new DPA guidance, a new state privacy law), and legislative changes (CPRA amendments, EU AI Act). A regulatory-change audit asks: "Are our controls still sufficient under the new rule?" A gap analysis (covered in 4.2) feeds the audit scope; the audit validates that the gaps have been closed.

Worked Scenario — Selecting an Audit Approach for a SaaS Vendor

A health-tech SaaS company onboards a new subprocessor that will store patient identifiers. The privacy manager's program goal is to verify the subprocessor's privacy controls before go-live and sustain assurance annually. The manager selects a second-party audit before contract signature (right-to-audit clause already in the MSA), scoped to encryption, access controls, breach notification, and DSR support. Because the data is high-sensitivity, the manager supplements the second-party audit with a SOC 2 Type II review (third-party attestation) and requires annual re-attestation. Internal audit then schedules a first-party follow-up six months post-go-live to confirm the integration is operating as designed. This layered approach matches audit depth to risk: second-party for pre-contract assurance, third-party attestation for ongoing control validation, first-party for integration-specific assurance.