Privacy Audit Template and Checklist for Startups (2025)

Quick Facts

What Is It? A privacy audit is a systematic examination of your organization's data processing activities, policies, and security controls to assess compliance with privacy laws (GDPR, CCPA, CPRA) and identify gaps.
Who Needs It? Any company that processes personal data, especially companies subject to GDPR (EU/UK), CCPA/CPRA (California), or other privacy laws. Recommended for all startups handling customer data.
Frequency At least annually, or more frequently if: (1) new products/services are launched, (2) data processing activities change significantly, (3) privacy laws change, (4) after a data breach.
Key Components Data inventory and mapping, legal basis assessment, security controls review, vendor management, data subject rights procedures, breach response readiness, documentation audit.
Compliance Frameworks GDPR (EU), UK GDPR, CCPA (California), CPRA (California), state privacy laws (Virginia, Colorado, Connecticut, Utah, Montana), LGPD (Brazil), PIPEDA (Canada).
Related Documents Privacy Policy, Cookie Policy, DPA, Records of Processing Activities (ROPA), Data Protection Impact Assessment (DPIA).

What This Template Includes

This comprehensive privacy audit template includes:

  • Data inventory and mapping (What data? From where? Why? Who has access? Where stored? How long?)
  • Legal basis assessment (GDPR Article 6 legal bases, consent management, legitimate interest assessments)
  • Security controls assessment (Encryption, access controls, logging, incident response, vulnerability management)
  • Vendor and third-party management (DPAs, subprocessors, international transfers)
  • Data subject rights procedures (Access, deletion, rectification, portability, objection)
  • Privacy policy and notice review (Transparency, completeness, accessibility)
  • Cookie and tracking technology audit (Cookie consent, cookie policy, tracking technologies)
  • Breach response readiness (Incident response plan, breach notification procedures, 72-hour notification capability)
  • Documentation and recordkeeping (ROPA, DPIAs, consent records, training records)
  • International data transfer mechanisms (SCCs, adequacy decisions, BCRs, TIAs)
  • CCPA/CPRA-specific requirements (Do Not Sell/Share, GPC support, consumer rights, risk assessments)

This template is designed for tech startups, SaaS companies, and e-commerce businesses but can be customized for any industry. Use this checklist to conduct your own internal audit or prepare for an external audit.

Privacy Audit Checklist

PRIVACY AUDIT CHECKLIST

Company: [COMPANY NAME]

Audit Date: [DATE]

Audit Scope: [e.g., "All data processing activities related to [PRODUCT/SERVICE]" or "Company-wide privacy compliance"]

Auditor(s): [NAME(S) and ROLE(S)]

Audit Period: [DATE RANGE] (e.g., "January 1, 2025 - December 31, 2025")

1. EXECUTIVE SUMMARY

Purpose of Audit: [Brief description of why the audit is being conducted, e.g., "Annual compliance audit to assess GDPR and CCPA compliance" or "Pre-funding due diligence privacy audit"]

Scope of Audit: [What data processing activities, systems, or business units are covered by this audit?]

Key Findings: [High-level summary of major findings - to be completed after audit]

  • [ ] Critical Issues: [Number] critical issues identified (immediate action required)
  • [ ] High-Priority Issues: [Number] high-priority issues identified (action required within 30 days)
  • [ ] Medium-Priority Issues: [Number] medium-priority issues identified (action required within 90 days)
  • [ ] Low-Priority Issues: [Number] low-priority issues identified (action required within 180 days)

Overall Compliance Status:

  • [ ] Compliant: All requirements met
  • [ ] Mostly Compliant: Minor issues identified, low risk
  • [ ] Partially Compliant: Significant issues identified, moderate risk
  • [ ] Non-Compliant: Major issues identified, high risk

2. DATA INVENTORY AND MAPPING

Objective: Identify all personal data processed by the organization, where it comes from, why it's collected, who has access, where it's stored, and how long it's retained.

2.1 Data Inventory

Complete the following table for each type of personal data processed:

Data Category Data Elements Source Purpose Legal Basis (GDPR) Retention Period Storage Location Who Has Access?
Customer Contact Information Name, email, phone, address Website signup form Provide services, send marketing emails Consent (marketing), Contract (services) Until account deletion + 30 days AWS us-east-1 Sales, Support, Engineering
Usage Data IP address, browser type, pages viewed, session duration Website analytics (Google Analytics) Improve website performance, personalize experience Legitimate Interest 26 months Google Cloud Product, Engineering
Payment Information Credit card number (last 4 digits), billing address Stripe checkout Process payments Contract 7 years (tax compliance) Stripe (PCI-compliant) Finance, limited
[ADD MORE ROWS]

Questions to Answer:

  • [ ] Have we identified all personal data we collect and process?

    • [ ] Yes
    • [ ] No → Action required: Conduct comprehensive data discovery

  • [ ] Do we have a complete data inventory document (Records of Processing Activities / ROPA)?

    • [ ] Yes → Attach ROPA or link: [LINK]
    • [ ] No → Action required: Create ROPA (required for GDPR Article 30)

  • [ ] Do we process special categories of personal data (health, biometric, genetic, racial/ethnic origin, political opinions, religious beliefs, trade union membership, sexual orientation)?

    • [ ] No
    • [ ] Yes → List special categories: [LIST]
    • [ ] Action required: Ensure explicit consent or legal basis under GDPR Article 9

  • [ ] Do we process children's personal data (under 13 in U.S./COPPA, under 16 in EU/GDPR, under 13 in California/CCPA)?

    • [ ] No
    • [ ] Yes → Age gate implemented: [ ] Yes [ ] No
    • [ ] Action required: Implement parental consent mechanisms (COPPA, GDPR Article 8)

2.2 Data Flow Mapping

For each major data processing activity, document the data flow:

Example Data Flow: Customer Signup

  1. Collection: User submits name, email, password on website signup form
  2. Transmission: Data transmitted via HTTPS to application server (AWS)
  3. Processing: Password hashed (bcrypt), email verified
  4. Storage: User data stored in PostgreSQL database (AWS RDS, encrypted at rest)
  5. Access: Engineering, Support, Sales teams have access (role-based access control)
  6. Third-party sharing: Email address shared with SendGrid (email delivery service - DPA in place)
  7. Retention: Retained until account deletion + 30 days for legal compliance
  8. Deletion: Securely deleted from database and backups after retention period

Data Flow Checklist:

  • [ ] Have we mapped data flows for all major processing activities?

    • [ ] Yes
    • [ ] No → Action required: Create data flow diagrams

  • [ ] Are data flows documented and accessible to relevant personnel?

    • [ ] Yes
    • [ ] No → Action required: Centralize data flow documentation

3. LEGAL BASIS AND LAWFULNESS OF PROCESSING

Objective: Ensure every data processing activity has a valid legal basis under GDPR Article 6 (and Article 9 for special categories).

3.1 GDPR Legal Bases (Article 6)

Review each data processing activity and identify the legal basis:

Processing Activity Legal Basis Evidence/Documentation Compliant?
Providing SaaS services to customers Contract (Article 6(1)(b)) Terms of Service, customer agreement [ ] Yes [ ] No
Sending marketing emails to prospects Consent (Article 6(1)(a)) Consent records, opt-in forms [ ] Yes [ ] No
Fraud detection and prevention Legitimate Interest (Article 6(1)(f)) Legitimate Interest Assessment (LIA) on file [ ] Yes [ ] No
Complying with tax regulations Legal Obligation (Article 6(1)(c)) Tax laws (e.g., IRS, HMRC) [ ] Yes [ ] No
[ADD MORE ROWS] [ ] Yes [ ] No

Legal Basis Assessment Questions:

  • [ ] Have we identified a valid legal basis for every processing activity?

    • [ ] Yes
    • [ ] No → Action required: Review all processing activities and assign legal bases

  • [ ] For processing based on Legitimate Interest, have we conducted Legitimate Interest Assessments (LIAs)?

    • [ ] Yes → LIAs on file: [ ] Yes [ ] No
    • [ ] No → Action required: Conduct LIAs for all legitimate interest processing
    • [ ] N/A (no legitimate interest processing)

  • [ ] For processing based on Consent, do we have valid consent records?

    • [ ] Yes → Consent records include: date, time, what user consented to, how they consented
    • [ ] No → Action required: Implement consent management system
    • [ ] N/A (no consent-based processing)

  • [ ] Can we prove the legal basis for each processing activity if challenged by a data protection authority?

    • [ ] Yes
    • [ ] No → Action required: Improve documentation

3.2 Consent Management

Questions:

  • [ ] Is consent freely given, specific, informed, and unambiguous?

    • [ ] Yes
    • [ ] No → Action required: Review consent language and mechanisms

  • [ ] Do we use pre-ticked boxes or opt-out consent?

    • [ ] No (good - compliant with GDPR)
    • [ ] Yes → Action required: Change to opt-in consent (pre-ticked boxes are not valid under GDPR)

  • [ ] Can users withdraw consent as easily as they gave it?

    • [ ] Yes → Withdrawal method: [e.g., "Unsubscribe link in emails, account settings page"]
    • [ ] No → Action required: Implement easy consent withdrawal mechanisms

  • [ ] Do we keep records of consent (who consented, when, what they consented to, how they consented)?

    • [ ] Yes → Consent records stored in: [SYSTEM]
    • [ ] No → Action required: Implement consent logging

4. PRIVACY POLICIES AND NOTICES

Objective: Ensure privacy policies and notices are accurate, complete, transparent, and accessible.

4.1 Privacy Policy Review

  • [ ] Do we have a comprehensive privacy policy?

    • [ ] Yes → Link: [PRIVACY POLICY URL]
    • [ ] No → Action required: Create privacy policy using this template

  • [ ] Is the privacy policy easily accessible?

    • [ ] Yes → Link in footer: [ ] Yes [ ] No
    • [ ] Link in signup forms: [ ] Yes [ ] No
    • [ ] No → Action required: Make privacy policy accessible from all pages

  • [ ] Does the privacy policy include all required information?

    • [ ] Identity and contact details of data controller
    • [ ] Contact details of Data Protection Officer (DPO) or privacy point of contact
    • [ ] Purposes of processing
    • [ ] Legal basis for each purpose
    • [ ] Legitimate interests (if applicable)
    • [ ] Recipients or categories of recipients of personal data
    • [ ] International data transfers (if applicable) and safeguards (SCCs, adequacy decisions)
    • [ ] Retention periods or criteria for determining retention periods
    • [ ] Data subject rights (access, rectification, deletion, portability, objection, restriction, withdraw consent)
    • [ ] Right to lodge a complaint with a supervisory authority
    • [ ] Whether providing personal data is a statutory/contractual requirement, and consequences of not providing it
    • [ ] Automated decision-making and profiling (if applicable)
    • [ ] Changes to the privacy policy and notification procedures

  • [ ] Is the privacy policy written in clear, plain language?

    • [ ] Yes
    • [ ] No → Action required: Simplify language, avoid legalese

  • [ ] Is the privacy policy up to date?

    • [ ] Yes → Last updated: [DATE]
    • [ ] No → Action required: Update privacy policy to reflect current practices

  • [ ] For CCPA/CPRA compliance, does the privacy policy include:

    • [ ] Categories of personal information collected
    • [ ] Sources of personal information
    • [ ] Business or commercial purpose for collecting personal information
    • [ ] Categories of third parties with whom we share personal information
    • [ ] Categories of personal information sold or shared (if applicable)
    • [ ] Notice of right to opt out of sale/sharing ("Do Not Sell or Share My Personal Information")
    • [ ] Notice of right to limit use of sensitive personal information (if applicable)
    • [ ] Non-discrimination notice

4.2 Privacy Notices at Point of Collection

  • [ ] Do we provide privacy notices at the point of data collection?

    • [ ] Yes
    • [ ] No → Action required: Add privacy notices to all data collection forms

  • [ ] Do privacy notices include:

    • [ ] Identity of data controller
    • [ ] Purpose of processing
    • [ ] Legal basis
    • [ ] Retention period
    • [ ] Data subject rights
    • [ ] Link to full privacy policy

5. DATA SUBJECT RIGHTS

Objective: Ensure procedures are in place to honor data subject rights under GDPR and CCPA/CPRA.

5.1 Data Subject Rights Procedures

  • [ ] Do we have documented procedures for handling data subject requests (DSRs)?

    • [ ] Yes → Procedures documented in: [LOCATION]
    • [ ] No → Action required: Create DSR procedures

  • [ ] Can we fulfill the following data subject rights within the required timeframes?

    Right Timeframe Can We Fulfill? How?
    Right of Access (GDPR Article 15) 1 month (extendable to 3 months) [ ] Yes [ ] No [Process/system]
    Right to Rectification (GDPR Article 16) 1 month (extendable to 3 months) [ ] Yes [ ] No [Process/system]
    Right to Erasure ("Right to be Forgotten") (GDPR Article 17) 1 month (extendable to 3 months) [ ] Yes [ ] No [Process/system]
    Right to Restriction of Processing (GDPR Article 18) 1 month (extendable to 3 months) [ ] Yes [ ] No [Process/system]
    Right to Data Portability (GDPR Article 20) 1 month (extendable to 3 months) [ ] Yes [ ] No [Process/system]
    Right to Object (GDPR Article 21) 1 month (extendable to 3 months) [ ] Yes [ ] No [Process/system]
    Right to Opt Out of Sale/Sharing (CCPA/CPRA) 15 business days (CCPA) [ ] Yes [ ] No [Process/system]
    Right to Delete (CCPA/CPRA) 45 days (extendable to 90 days) [ ] Yes [ ] No [Process/system]
    Right to Correct (CPRA) 45 days (extendable to 90 days) [ ] Yes [ ] No [Process/system]

  • [ ] Do we verify the identity of individuals making DSRs?

    • [ ] Yes → Verification method: [e.g., "Email confirmation, account login, two-factor authentication"]
    • [ ] No → Action required: Implement identity verification procedures

  • [ ] Do we log and track all DSRs?

    • [ ] Yes → DSR tracking system: [SYSTEM]
    • [ ] No → Action required: Implement DSR tracking system

  • [ ] Have we handled any DSRs in the past 12 months?

    • [ ] No
    • [ ] Yes → Number of DSRs: [NUMBER]
    • [ ] Access requests: [NUMBER]
    • [ ] Deletion requests: [NUMBER]
    • [ ] Rectification requests: [NUMBER]
    • [ ] Portability requests: [NUMBER]
    • [ ] Objection requests: [NUMBER]
    • [ ] Opt-out of sale/sharing (CCPA): [NUMBER]

  • [ ] Were all DSRs fulfilled within the required timeframe?

    • [ ] Yes
    • [ ] No → Action required: Improve DSR response procedures

6. CONSENT MANAGEMENT

Objective: Ensure consent is obtained, managed, and documented properly for all consent-based processing activities.

6.1 Consent Mechanisms

  • [ ] Do we use consent as a legal basis for any processing activities?

    • [ ] No → Skip to Section 7
    • [ ] Yes → List consent-based processing activities: [LIST, e.g., "Marketing emails, cookie placement, newsletter subscription"]

  • [ ] Is consent obtained before processing begins?

    • [ ] Yes
    • [ ] No → Action required: Implement "opt-in" consent (do not process data before obtaining consent)

  • [ ] Is consent clearly distinguished from other terms and conditions?

    • [ ] Yes → Consent is obtained separately from T&Cs: [ ] Yes [ ] No
    • [ ] No → Action required: Separate consent from T&Cs

  • [ ] Do consent requests include all required information?

    • [ ] Identity of data controller
    • [ ] Purpose of processing (specific and granular)
    • [ ] Type of data to be processed
    • [ ] Right to withdraw consent at any time
    • [ ] Consequences of withholding consent (if applicable)

  • [ ] Do we use granular consent (separate consent for different purposes)?

    • [ ] Yes (e.g., separate consent for marketing emails vs. product updates)
    • [ ] No → Action required: Implement granular consent

  • [ ] Can users withdraw consent as easily as they gave it?

    • [ ] Yes → Withdrawal methods: [e.g., "Unsubscribe link, account settings, contact form"]
    • [ ] No → Action required: Implement easy consent withdrawal

6.2 Consent Records

  • [ ] Do we keep records of all consents obtained?

    • [ ] Yes
    • [ ] No → Action required: Implement consent logging system

  • [ ] Do consent records include:

    • [ ] Who consented (user ID, email, or other identifier)
    • [ ] When they consented (date and time)
    • [ ] What they consented to (specific purpose, data types)
    • [ ] How they consented (checkbox, button click, opt-in form)
    • [ ] Version of privacy policy at the time of consent

  • [ ] Can we produce consent records upon request (e.g., for a data protection authority or in case of a dispute)?

    • [ ] Yes
    • [ ] No → Action required: Ensure consent records are accessible and searchable

7. COOKIE AND TRACKING TECHNOLOGY COMPLIANCE

Objective: Ensure cookies and tracking technologies comply with GDPR, ePrivacy Directive, and CCPA/CPRA requirements.

7.1 Cookie Audit

  • [ ] Do we use cookies or other tracking technologies (pixels, web beacons, local storage, SDKs)?

    • [ ] No → Skip to Section 8
    • [ ] Yes → List tracking technologies: [e.g., "Google Analytics, Facebook Pixel, Hotjar, Intercom"]

  • [ ] Have we scanned our website/app to identify all cookies?

    • [ ] Yes → Cookie scanner used: [e.g., "Cookiebot, OneTrust, Osano"]
    • [ ] No → Action required: Scan website/app for cookies

  • [ ] Do we have a cookie policy?

    • [ ] Yes → Link: [COOKIE POLICY URL]
    • [ ] No → Action required: Create cookie policy using this template

  • [ ] Does the cookie policy list all cookies by name, provider, purpose, duration, type, and legal basis?

    • [ ] Yes
    • [ ] No → Action required: Update cookie policy with comprehensive cookie table

7.2 Cookie Consent (GDPR / ePrivacy Directive)

For websites targeting EU/UK users:

  • [ ] Do we obtain prior consent before setting non-essential cookies?

    • [ ] Yes
    • [ ] No → Action required: Implement cookie consent banner that blocks non-essential cookies until consent is obtained

  • [ ] Do we use a Consent Management Platform (CMP)?

    • [ ] Yes → CMP: [e.g., "Cookiebot, OneTrust, Osano, Termly"]
    • [ ] No → Action required: Implement CMP

  • [ ] Does the cookie consent banner:

    • [ ] Block non-essential cookies until consent is obtained (not just display a notice)
    • [ ] Provide granular controls (allow users to accept/reject specific cookie categories)
    • [ ] Make it as easy to reject as to accept (no "dark patterns")
    • [ ] Include a link to the cookie policy
    • [ ] Allow users to change their preferences at any time (e.g., "Cookie Preferences" link in footer)

  • [ ] Do we use pre-ticked boxes or cookie walls?

    • [ ] No (good - compliant with GDPR)
    • [ ] Yes → Action required: Remove pre-ticked boxes and cookie walls (not compliant with GDPR)

7.3 Cookie Opt-Out (CCPA / CPRA)

For websites targeting California users:

  • [ ] Do we honor Global Privacy Control (GPC) signals?

    • [ ] Yes
    • [ ] No → Action required: Implement GPC support (required for CCPA/CPRA compliance)
    • [ ] N/A (we don't sell or share personal information)

  • [ ] Do we provide a "Do Not Sell or Share My Personal Information" link?

    • [ ] Yes → Link in footer: [ ] Yes [ ] No
    • [ ] No → Action required: Add "Do Not Sell or Share" link

8. SECURITY CONTROLS AND DATA PROTECTION

Objective: Ensure appropriate technical and organizational measures are in place to protect personal data (GDPR Article 32).

8.1 Access Controls

  • [ ] Do we use role-based access control (RBAC) to limit access to personal data?

    • [ ] Yes
    • [ ] No → Action required: Implement RBAC

  • [ ] Do employees have access only to the personal data they need to perform their job functions?

    • [ ] Yes (principle of least privilege)
    • [ ] No → Action required: Review and restrict access

  • [ ] Do we use multi-factor authentication (MFA) for access to systems containing personal data?

    • [ ] Yes
    • [ ] No → Action required: Implement MFA

  • [ ] Do we conduct regular access reviews (at least quarterly) to remove unnecessary access?

    • [ ] Yes → Last access review: [DATE]
    • [ ] No → Action required: Schedule regular access reviews

8.2 Encryption

  • [ ] Is personal data encrypted in transit?

    • [ ] Yes → Encryption protocol: [e.g., "TLS 1.2+, HTTPS"]
    • [ ] No → Action required: Implement encryption in transit

  • [ ] Is personal data encrypted at rest?

    • [ ] Yes → Encryption method: [e.g., "AES-256, database encryption, full-disk encryption"]
    • [ ] No → Action required: Implement encryption at rest

  • [ ] Are backups encrypted?

    • [ ] Yes
    • [ ] No → Action required: Encrypt backups

8.3 Logging and Monitoring

  • [ ] Do we log access to personal data?

    • [ ] Yes → Logs include: [ ] User ID [ ] Timestamp [ ] Action (read, write, delete) [ ] Data accessed
    • [ ] No → Action required: Implement access logging

  • [ ] Do we monitor logs for suspicious activity?

    • [ ] Yes → Monitoring system: [e.g., "SIEM, Splunk, Datadog"]
    • [ ] No → Action required: Implement log monitoring

  • [ ] How long are logs retained?

    • [ ] [X] months/years
    • [ ] No retention policy → Action required: Define log retention period (minimum 12 months recommended)

8.4 Vulnerability Management

  • [ ] Do we conduct regular vulnerability scans?

    • [ ] Yes → Frequency: [e.g., "Quarterly"] | Last scan: [DATE]
    • [ ] No → Action required: Implement vulnerability scanning

  • [ ] Do we conduct penetration testing?

    • [ ] Yes → Frequency: [e.g., "Annually"] | Last test: [DATE]
    • [ ] No → Action required: Conduct penetration testing (at least annually)

  • [ ] Do we apply security patches within [30] days of release?

    • [ ] Yes
    • [ ] No → Action required: Implement patch management policy

8.5 Physical Security

For on-premises data centers or offices:

  • [ ] Are servers and data storage facilities physically secured?
    • [ ] Yes → Security measures: [e.g., "Badge access, surveillance cameras, 24/7 security guards"]
    • [ ] No → Action required: Implement physical security controls
    • [ ] N/A (cloud-only, no on-premises infrastructure)

8.6 Security Certifications

  • [ ] Do we have any security certifications?
    • [ ] SOC 2 Type II → Date: [DATE]
    • [ ] ISO 27001 → Date: [DATE]
    • [ ] PCI DSS → Level: [1/2/3/4]
    • [ ] Other: [CERTIFICATION]
    • [ ] None → Action required: Consider obtaining SOC 2 or ISO 27001 certification

9. VENDOR AND THIRD-PARTY MANAGEMENT

Objective: Ensure all vendors and third parties that process personal data on our behalf have appropriate data protection agreements (DPAs) and security measures.

9.1 Vendor Inventory

List all vendors/third parties that process personal data on your behalf (processors):

Vendor Name Service Provided Data Processed DPA in Place? DPA Date Security Certifications Compliant?
AWS Cloud hosting All customer data [ ] Yes [ ] No [DATE] SOC 2, ISO 27001 [ ] Yes [ ] No
Stripe Payment processing Payment data, billing address [ ] Yes [ ] No [DATE] PCI DSS Level 1, SOC 2 [ ] Yes [ ] No
SendGrid Email delivery Email addresses, names [ ] Yes [ ] No [DATE] SOC 2 [ ] Yes [ ] No
Google Analytics Website analytics IP addresses, usage data [ ] Yes [ ] No [DATE] ISO 27001 [ ] Yes [ ] No
[ADD MORE ROWS] [ ] Yes [ ] No [ ] Yes [ ] No

9.2 Data Processing Agreements (DPAs)

  • [ ] Do we have signed DPAs with all processors (vendors who process personal data on our behalf)?

    • [ ] Yes → DPAs filed in: [LOCATION]
    • [ ] No → Action required: Execute DPAs with all processors (use this template)

  • [ ] Do the DPAs include all GDPR Article 28(3) requirements?

    • [ ] Processing instructions
    • [ ] Confidentiality obligations
    • [ ] Security measures
    • [ ] Sub-processor authorization and notification
    • [ ] Assistance with data subject rights
    • [ ] Assistance with security and breach notification obligations
    • [ ] Deletion or return of data upon termination
    • [ ] Audit rights

  • [ ] Do we have a process for reviewing and approving new vendors before they process personal data?

    • [ ] Yes → Approval process: [DESCRIPTION]
    • [ ] No → Action required: Implement vendor approval process

9.3 Sub-processor Management

  • [ ] Do we maintain a list of all sub-processors (vendors' subcontractors)?

    • [ ] Yes → List updated: [DATE]
    • [ ] No → Action required: Request sub-processor lists from all vendors

  • [ ] Do our DPAs allow vendors to use sub-processors?

    • [ ] Yes → Authorization model: [ ] General authorization [ ] Specific authorization
    • [ ] No

  • [ ] Do we receive notification of new sub-processors in advance?

    • [ ] Yes → Notification period: [30/60/90] days
    • [ ] No → Action required: Update DPAs to require advance notification

  • [ ] Do we have the right to object to new sub-processors?

    • [ ] Yes
    • [ ] No → Action required: Negotiate objection rights in DPAs

10. INTERNATIONAL DATA TRANSFERS

Objective: Ensure all international data transfers comply with GDPR Chapter V and have appropriate safeguards.

10.1 Transfer Inventory

  • [ ] Do we transfer personal data outside the EEA/UK?
    • [ ] No → Skip to Section 11
    • [ ] Yes → List destination countries: [e.g., "United States, Canada, Australia"]

10.2 Transfer Mechanisms

For each international transfer, identify the legal mechanism:

Destination Country Data Transferred Recipient Transfer Mechanism Compliant?
United States Customer data AWS (cloud hosting) EU-U.S. Data Privacy Framework (adequacy decision) [ ] Yes [ ] No
United States Payment data Stripe EU-U.S. Data Privacy Framework (adequacy decision) [ ] Yes [ ] No
India Customer support data Support vendor Standard Contractual Clauses (SCCs) [ ] Yes [ ] No
[ADD MORE ROWS] [ ] Yes [ ] No

Transfer Mechanism Options:

  • Adequacy Decision: EU Commission or UK government has recognized the destination country as providing adequate data protection.

    • [ ] Countries with EU adequacy decisions (as of 2025): Andorra, Argentina, Canada (commercial), Faroe Islands, Guernsey, Israel, Isle of Man, Japan, Jersey, New Zealand, South Korea, Switzerland, UK, Uruguay, United States (Data Privacy Framework participants)

  • Standard Contractual Clauses (SCCs): Pre-approved contract clauses for transfers to countries without adequacy decisions.

    • [ ] Have we executed SCCs for all transfers to countries without adequacy decisions?
    • [ ] Yes
    • [ ] No → Action required: Execute SCCs (use DPA template with SCCs annex)

  • UK International Data Transfer Agreement (UK IDTA): Required for transfers from the UK to countries without UK adequacy decisions.

    • [ ] Have we executed UK IDTA for transfers from the UK?
    • [ ] Yes
    • [ ] No → Action required: Execute UK IDTA

  • Binding Corporate Rules (BCRs): Internal policies for multinational companies.

    • [ ] Do we have approved BCRs?
    • [ ] Yes
    • [ ] No → N/A (only applicable to multinational corporations with intra-group transfers)

10.3 Transfer Impact Assessments (TIAs)

  • [ ] Have we conducted Transfer Impact Assessments (TIAs) for transfers using SCCs?
    • [ ] Yes → TIAs on file: [ ] Yes [ ] No
    • [ ] No → Action required: Conduct TIAs for all SCC-based transfers
    • [ ] N/A (no SCC-based transfers)

TIA assesses:

  • Nature of the personal data
  • Purposes and duration of processing
  • Risks to data subjects
  • Legal framework of destination country (government access, surveillance)
  • Supplementary measures (if needed)

11. DATA BREACH RESPONSE AND INCIDENT MANAGEMENT

Objective: Ensure procedures are in place to detect, report, and respond to personal data breaches.

11.1 Incident Response Plan

  • [ ] Do we have a documented incident response plan?

    • [ ] Yes → Plan documented in: [LOCATION]
    • [ ] No → Action required: Create incident response plan

  • [ ] Does the incident response plan include:

    • [ ] Roles and responsibilities (incident response team)
    • [ ] Detection and reporting procedures
    • [ ] Containment and investigation procedures
    • [ ] Notification procedures (supervisory authority, data subjects, customers)
    • [ ] Post-incident review and remediation

  • [ ] Have we tested the incident response plan?

    • [ ] Yes → Last test: [DATE]
    • [ ] No → Action required: Conduct tabletop exercise or simulation

11.2 Breach Notification Capability

GDPR Requirements:

  • [ ] Can we notify the relevant supervisory authority within 72 hours of becoming aware of a personal data breach?

    • [ ] Yes
    • [ ] No → Action required: Improve breach detection and notification procedures

  • [ ] Do we know which supervisory authority to notify?

    • [ ] Yes → Supervisory authority: [e.g., "Irish DPC, UK ICO, German BfDI"]
    • [ ] No → Action required: Identify lead supervisory authority

  • [ ] Can we notify affected data subjects "without undue delay" if the breach poses a high risk to their rights and freedoms?

    • [ ] Yes
    • [ ] No → Action required: Implement data subject notification procedures

CCPA/CPRA Requirements:

  • [ ] If we experience a data breach affecting California residents, do we comply with California breach notification law (Cal. Civ. Code § 1798.82)?
    • [ ] Yes
    • [ ] No → Action required: Review California breach notification requirements

11.3 Breach Records

  • [ ] Do we maintain records of all personal data breaches, including:

    • [ ] Facts relating to the breach
    • [ ] Effects of the breach
    • [ ] Remedial action taken

  • [ ] Have we experienced any personal data breaches in the past 12 months?

    • [ ] No
    • [ ] Yes → Number of breaches: [NUMBER]
    • [ ] Breaches reported to supervisory authority: [NUMBER]
    • [ ] Breaches reported to data subjects: [NUMBER]
    • [ ] Lessons learned documented: [ ] Yes [ ] No

12. DATA RETENTION AND DELETION

Objective: Ensure personal data is retained only as long as necessary and securely deleted when no longer needed.

12.1 Retention Policies

  • [ ] Do we have a documented data retention policy?

    • [ ] Yes → Policy documented in: [LOCATION]
    • [ ] No → Action required: Create data retention policy

  • [ ] Have we defined retention periods for each category of personal data?

    • [ ] Yes → Retention schedule: [LINK OR TABLE]
    • [ ] No → Action required: Define retention periods based on legal requirements and business needs

Example Retention Schedule:

Data Category Retention Period Legal/Business Justification Deletion Method
Customer account data Until account deletion + 30 days Business need (provide service), Legal obligation (dispute resolution) Secure deletion from database and backups
Payment data 7 years Legal obligation (tax compliance, fraud prevention) Secure deletion after 7 years
Marketing email data Until unsubscribe + 30 days Consent (user can withdraw anytime) Secure deletion from email platform
Website logs 12 months Legitimate interest (security, fraud detection) Automated deletion after 12 months
[ADD MORE ROWS]

12.2 Data Deletion Procedures

  • [ ] Do we have procedures for securely deleting personal data?

    • [ ] Yes
    • [ ] No → Action required: Document deletion procedures

  • [ ] Do we use secure deletion methods (e.g., overwriting, degaussing, physical destruction)?

    • [ ] Yes → Deletion method: [METHOD]
    • [ ] No → Action required: Implement secure deletion (simple file deletion is not sufficient)

  • [ ] Do we delete personal data from backups?

    • [ ] Yes → Backup deletion process: [PROCESS]
    • [ ] No → Action required: Implement backup deletion process, or document why backups are retained (e.g., "Backups retained for [X] days and then securely deleted")

  • [ ] Do we have automated deletion processes (e.g., scripts that delete data after retention period expires)?

    • [ ] Yes
    • [ ] No → Action required: Implement automated deletion

13. EMPLOYEE TRAINING AND AWARENESS

Objective: Ensure employees understand their data protection obligations and know how to handle personal data properly.

13.1 Training Program

  • [ ] Do we provide data protection training to all employees?

    • [ ] Yes
    • [ ] No → Action required: Implement data protection training program

  • [ ] Is training provided:

    • [ ] During onboarding (for new hires)
    • [ ] Annually (for all employees)
    • [ ] When policies change
    • [ ] For specific roles (e.g., engineers, support, sales)

  • [ ] Does training cover:

    • [ ] Overview of GDPR, CCPA, and applicable privacy laws
    • [ ] Principles of data protection (lawfulness, fairness, transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity, confidentiality)
    • [ ] Employees' responsibilities for protecting personal data
    • [ ] How to handle data subject requests (DSRs)
    • [ ] How to report security incidents and data breaches
    • [ ] Confidentiality obligations
    • [ ] Consequences of non-compliance

13.2 Training Records

  • [ ] Do we maintain training records (who was trained, when, what topics were covered)?

    • [ ] Yes → Training records stored in: [SYSTEM]
    • [ ] No → Action required: Implement training tracking

  • [ ] What percentage of employees have completed data protection training?

    • [ ] 100%
    • [ ] 75-99%
    • [ ] 50-74%
    • [ ] Below 50% → Action required: Increase training completion rate

14. DOCUMENTATION AND RECORDKEEPING

Objective: Ensure all required privacy documentation is in place and up to date.

14.1 Required Documentation

  • [ ] Records of Processing Activities (ROPA) / Article 30 Record (required for GDPR)

    • [ ] Complete and up to date
    • [ ] Incomplete or outdated → Action required: Update ROPA
    • [ ] Does not exist → Action required: Create ROPA

  • [ ] Data Protection Impact Assessments (DPIAs) (required for high-risk processing)

    • [ ] DPIAs conducted for all high-risk processing activities
    • [ ] DPIAs not conducted → Action required: Conduct DPIAs (see Section 16)
    • [ ] N/A (no high-risk processing)

  • [ ] Legitimate Interest Assessments (LIAs) (required for legitimate interest processing)

    • [ ] LIAs conducted for all legitimate interest processing
    • [ ] LIAs not conducted → Action required: Conduct LIAs
    • [ ] N/A (no legitimate interest processing)

  • [ ] Data Processing Agreements (DPAs) with all processors

    • [ ] DPAs signed with all processors
    • [ ] Missing DPAs → Action required: Execute DPAs

  • [ ] Standard Contractual Clauses (SCCs) or UK IDTA for international transfers

    • [ ] SCCs/IDTA executed for all international transfers
    • [ ] Missing SCCs/IDTA → Action required: Execute SCCs/IDTA
    • [ ] N/A (no international transfers)

  • [ ] Consent records (if consent is a legal basis)

    • [ ] Consent records maintained
    • [ ] Consent records not maintained → Action required: Implement consent logging
    • [ ] N/A (no consent-based processing)

  • [ ] Breach notification records

    • [ ] Breach records maintained
    • [ ] Breach records not maintained → Action required: Create breach log
    • [ ] N/A (no breaches)

  • [ ] Training records

    • [ ] Training records maintained
    • [ ] Training records not maintained → Action required: Implement training tracking

  • [ ] Privacy policy and cookie policy

    • [ ] Up to date and published
    • [ ] Outdated or missing → Action required: Update/create policies

14.2 Data Protection Officer (DPO) or Privacy Point of Contact

  • [ ] Are we required to appoint a Data Protection Officer (DPO)?

    • [ ] No (GDPR Article 37 - DPO required if: (1) public authority, (2) core activities involve large-scale monitoring, or (3) core activities involve large-scale processing of special categories of data)
    • [ ] Yes → DPO appointed: [ ] Yes [ ] No
    • [ ] DPO Name: [NAME]
    • [ ] DPO Contact: [EMAIL]
    • [ ] DPO registered with supervisory authority: [ ] Yes [ ] No

  • [ ] Do we have a designated privacy point of contact?

    • [ ] Yes → Contact: [NAME / EMAIL]
    • [ ] No → Action required: Designate privacy point of contact

15. CCPA/CPRA-SPECIFIC REQUIREMENTS

Objective: Ensure compliance with California Consumer Privacy Act (CCPA) and California Privacy Rights Act (CPRA) requirements.

Note: This section applies only if you are subject to CCPA/CPRA (i.e., you do business in California and meet the revenue, data volume, or data sales thresholds).

15.1 CCPA/CPRA Applicability

  • [ ] Are we subject to CCPA/CPRA?
    • [ ] Yes → We meet the following threshold(s):
    • [ ] Annual gross revenues exceed $25 million
    • [ ] Buy, sell, or share personal information of 100,000+ California consumers or households
    • [ ] Derive 50%+ of annual revenues from selling or sharing personal information
    • [ ] No → Skip to Section 16

15.2 Consumer Rights (CCPA/CPRA)

  • [ ] Do we provide the following consumer rights to California residents?
    • [ ] Right to Know (categories and specific pieces of personal information collected)
    • [ ] Right to Delete (with exceptions for certain legal obligations)
    • [ ] Right to Correct (inaccurate personal information) - CPRA only
    • [ ] Right to Opt Out of Sale or Sharing (for targeted advertising)
    • [ ] Right to Limit Use of Sensitive Personal Information (if applicable)
    • [ ] Right to Non-Discrimination (for exercising CCPA/CPRA rights)

15.3 "Do Not Sell or Share" Mechanisms

  • [ ] Do we sell or share personal information?

    • [ ] No → Skip to Section 15.4
    • [ ] Yes → Sale/sharing activities: [e.g., "Sharing data with advertising partners for targeted ads"]

  • [ ] Do we provide a "Do Not Sell or Share My Personal Information" link?

    • [ ] Yes → Link prominently displayed: [ ] Homepage [ ] Footer [ ] Privacy Policy
    • [ ] No → Action required: Add "Do Not Sell or Share" link

  • [ ] Do we honor Global Privacy Control (GPC) signals as opt-out requests?

    • [ ] Yes
    • [ ] No → Action required: Implement GPC support (required by CPRA)

15.4 Risk Assessments (CPRA)

  • [ ] Do we conduct risk assessments for:

    • [ ] Processing personal information that presents a significant risk to consumers' privacy or security (required by CPRA Section 1798.185(a)(15)(B))

    • [ ] Yes → Risk assessments conducted: [DATE]

    • [ ] No → Action required: Conduct risk assessments

    • [ ] N/A (no significant-risk processing)

    • [ ] Using personal information to train AI systems (required by CPRA if applicable)

    • [ ] Yes → AI risk assessments conducted: [DATE]

    • [ ] No → Action required: Conduct AI risk assessments

    • [ ] N/A (no AI training using personal information)

15.5 CCPA/CPRA-Specific Disclosures

  • [ ] Does our privacy policy include all CCPA/CPRA-required disclosures?
    • [ ] Categories of personal information collected (in past 12 months)
    • [ ] Sources of personal information
    • [ ] Business or commercial purposes for collecting or selling personal information
    • [ ] Categories of third parties with whom we share personal information
    • [ ] Categories of personal information sold or shared (if applicable)
    • [ ] Categories of personal information disclosed for business purposes (if applicable)
    • [ ] Retention periods for each category of personal information
    • [ ] Consumer rights and how to exercise them
    • [ ] Non-discrimination notice

16. PRIVACY IMPACT ASSESSMENTS (PIAs/DPIAs)

Objective: Identify and mitigate privacy risks for high-risk processing activities.

16.1 DPIA Requirements (GDPR Article 35)

  • [ ] Do we conduct Data Protection Impact Assessments (DPIAs) for high-risk processing activities?
    • [ ] Yes
    • [ ] No → Action required: Conduct DPIAs for high-risk processing
    • [ ] N/A (no high-risk processing)

High-risk processing includes:

  • Systematic and extensive profiling or automated decision-making with legal or similarly significant effects
  • Large-scale processing of special categories of data (health, biometric, etc.)
  • Systematic monitoring of publicly accessible areas on a large scale
  • Use of new technologies that pose high privacy risks
  • Processing that prevents data subjects from exercising their rights

16.2 DPIA Inventory

List all DPIAs conducted:

Processing Activity DPIA Conducted? Date Outcome Mitigations Implemented
AI-powered recommendation engine [ ] Yes [ ] No [DATE] [High/Medium/Low Risk] [List mitigations]
Biometric authentication (facial recognition) [ ] Yes [ ] No [DATE] [High/Medium/Low Risk] [List mitigations]
[ADD MORE ROWS] [ ] Yes [ ] No

16.3 DPIA Content

  • [ ] Do DPIAs include:
    • [ ] Description of processing operations and purposes
    • [ ] Assessment of necessity and proportionality
    • [ ] Assessment of risks to data subjects' rights and freedoms
    • [ ] Measures to address risks (mitigations)
    • [ ] Consultation with data subjects or their representatives (if applicable)

17. FINDINGS AND RECOMMENDATIONS

Summary of Audit Findings:

17.1 Critical Issues (Immediate Action Required)

# Issue Risk Level Affected Area Recommendation Owner Due Date
1 [Issue description] Critical [Area] [Recommendation] [Owner] [Date]
[ADD MORE ROWS]

17.2 High-Priority Issues (Action Required Within 30 Days)

# Issue Risk Level Affected Area Recommendation Owner Due Date
1 [Issue description] High [Area] [Recommendation] [Owner] [Date]
[ADD MORE ROWS]

17.3 Medium-Priority Issues (Action Required Within 90 Days)

# Issue Risk Level Affected Area Recommendation Owner Due Date
1 [Issue description] Medium [Area] [Recommendation] [Owner] [Date]
[ADD MORE ROWS]

17.4 Low-Priority Issues (Action Required Within 180 Days)

# Issue Risk Level Affected Area Recommendation Owner Due Date
1 [Issue description] Low [Area] [Recommendation] [Owner] [Date]
[ADD MORE ROWS]

18. ACTION PLAN

Remediation Plan:

Action Item Priority Owner Due Date Status Notes
[Action] [Critical/High/Medium/Low] [Owner] [Date] [Not Started / In Progress / Completed] [Notes]
[ADD MORE ROWS]

Follow-Up Audit:

  • [ ] Schedule follow-up audit to verify remediation: [DATE]

Audit Completed By:

Name: ___

Title: ___

Date: ___

Signature: ___

END OF PRIVACY AUDIT CHECKLIST

Download

Download Privacy Audit Template (Markdown) Download Privacy Audit Template (Excel) Download Privacy Audit Template (PDF)

(Download buttons to be implemented by your development team.)

How to Use This Template

  1. Schedule the audit: Set aside dedicated time (1-4 weeks depending on company size and complexity).
  2. Assign responsibilities: Identify who will conduct the audit (internal privacy team, legal counsel, or external auditor).
  3. Gather documentation: Collect all relevant privacy documentation (privacy policies, DPAs, consent records, etc.).
  4. Complete each section: Work through the checklist systematically, answering all questions and checking all boxes.
  5. Document findings: For any "No" answers, document the issue in Section 17 (Findings and Recommendations).
  6. Create action plan: Prioritize findings by risk level and assign owners and due dates in Section 18 (Action Plan).
  7. Implement remediation: Work through the action plan to address all identified issues.
  8. Schedule follow-up audit: Conduct a follow-up audit to verify that all issues have been resolved.
  9. Maintain continuous compliance: Update the audit checklist annually or whenever significant changes occur (new products, new vendors, law changes).

Related Resources

Next Steps

  1. Download this template and customize it for your organization.
  2. Conduct your first privacy audit using this checklist.
  3. Address all identified issues according to the action plan.
  4. Schedule annual audits to maintain continuous compliance.
  5. Consult legal counsel for complex privacy issues or regulatory questions.

Need help conducting a privacy audit or achieving GDPR/CCPA compliance? Contact Promise Legal for personalized guidance.

This button allows you to scroll to the top or access additional options. Alt + A will toggle accessibility mode.