Compliance Evidence Checklist: What to Collect for GDPR, SOC 2, and HIPAA

Overview

A practical compliance evidence checklist should answer four questions for every requirement: what control exists, who owns it, what artifact proves it, and how current that artifact is. Teams often lose time because evidence lives across ticketing systems, cloud consoles, HR tools, shared drives, and email approvals. The result is a scramble every time an auditor, prospect, or internal stakeholder asks for proof.

The better approach is to maintain an evidence library by control area rather than by framework alone. Many artifacts support multiple requirements at once. For example, an access review record can help support SOC 2 readiness, show reasonable HIPAA administrative discipline, and support broader data protection compliance. A vendor inventory can support privacy operations under GDPR and also improve your third party risk assessment process.

For most SMB and SaaS teams, it helps to organize evidence into five folders or database views:

• Governance: policies, standards, risk decisions, role assignments, training records
• Technical controls: screenshots, exports, configuration baselines, system settings, monitoring evidence
• Operational records: tickets, approvals, review logs, change management samples, incident records
• Privacy and legal documents: notices, DPAs, BAAs, subprocessor terms, records of processing
• Third-party assurance: vendor reviews, questionnaires, certifications, contract clauses, onboarding and offboarding evidence

Each artifact should be labeled with an owner, date, system, and review frequency. That simple metadata makes your evidence library much more reusable. It also reduces repeat work when you respond to customer due diligence requests. If questionnaire volume is becoming a burden, it is worth building a response library in parallel with your evidence set. The process is similar to the one described in Security Questionnaire Response Library: How to Standardize Answers and Evidence.

Use the checklist below as a cross-framework starting point, not as legal advice or a substitute for a formal audit scope. The goal is to help you collect evidence that is specific, current, and tied to real operations.

Checklist by scenario

This section gives you a practical evidence list by control scenario so you can map one artifact set across GDPR, SOC 2, and HIPAA.

1. Governance, ownership, and risk management

• Policy set: information security policy, access control policy, incident response policy template, data retention policy template, acceptable use, encryption, backup, vendor management, privacy policy, and if relevant HIPAA-specific procedures
• Policy approval records: version history, approver names, approval dates, and review cadence
• Control ownership list: named owners for security, privacy, HR, IT, engineering, and vendor management
• Risk assessment records: risk register, treatment plan, open issues, remediation tickets, and evidence of periodic review
• Meeting records: security committee notes, privacy review notes, and management review summaries
• Training records: employee security awareness completion, privacy training completion, and role-specific training where applicable

Why it matters: This evidence supports the operating backbone of all three frameworks. For HIPAA, risk assessment and workforce training are especially important. For SOC 2, governance and risk management establish the control environment. For GDPR, documented accountability is a recurring theme. If you need more context on risk work, see HIPAA Risk Assessment Guide for Small Practices and Health Tech Vendors.

2. Access control and identity management

• User provisioning and deprovisioning records: onboarding and offboarding tickets, approval paths, timestamped completion records
• Access review evidence: periodic review spreadsheets or exports, reviewer signoff, remediation actions for stale access
• MFA settings: screenshots or configuration exports showing MFA requirements for privileged and workforce accounts
• Role definitions: RBAC matrix, privileged access list, break-glass procedures
• Password and authentication settings: policy settings or identity provider configurations
• Contractor and vendor access logs: proof of scoped access and timely removal when work ends

Why it matters: Access control is one of the most requested evidence areas in audits and customer reviews. It also cuts across SOC 2 controls, HIPAA safeguards, and broader data protection compliance. For related control detail, see SOC 2 Controls List Explained: Common Criteria, Evidence, and Ownership and HIPAA Safeguards Explained: Administrative, Physical, and Technical Requirements.

3. Change management, system operations, and monitoring

• Change management samples: tickets linked to code changes, approvals, test evidence, deployment records, rollback notes
• Vulnerability management records: scan reports, triage records, remediation tickets, retest evidence
• Patch management logs: update schedules, exception approvals, emergency patch records
• Logging and monitoring configuration: enabled log sources, retention settings, alert rules, SIEM or monitoring screenshots
• Backup and recovery evidence: backup schedules, restoration test records, exception handling
• Availability and incident records: incident tickets, post-incident reviews, root cause analyses

Why it matters: These records demonstrate that controls are not just written down but actually operating. For SOC 2 readiness, this is central. For HIPAA, operational safeguards and resilience matter. For SaaS teams storing sensitive data in cloud systems, it also aligns well with the baseline in Cloud Compliance Checklist: Core Controls for Storing Sensitive Business Data.

4. Privacy operations and GDPR documentation

• Privacy notice and internal policy records: current published privacy notice, internal privacy procedures, review logs
• Records of processing activities: system list, categories of personal data, purpose, recipients, retention, transfer notes
• Lawful basis mapping: internal documentation connecting processing activities to legal bases where relevant
• DSAR process evidence: request intake workflow, identity verification steps, response templates, completion logs
• Cookie and consent records: consent manager settings, category definitions, implementation review records if applicable
• DPA and subprocessor records: signed DPA template versions, subprocessor agreement terms, vendor list, notice workflow for updates
• Retention and deletion evidence: retention schedule, automated deletion settings, manual deletion procedures, exception list
• Cross-border transfer documentation: transfer assessment notes or contractual support where applicable

Why it matters: GDPR compliance documentation is often scattered between legal, product, and engineering. Pulling it into one evidence set makes it much easier to answer enterprise customer diligence questions. If your company is US-based but serves EU users, GDPR for US SaaS Companies: What Still Applies and Where Teams Get Stuck is a useful companion.

5. HIPAA-specific documentation

• HIPAA risk analysis and management plan: documented analysis scope, identified risks, remediation priorities, review dates
• HIPAA policies and procedures: administrative, physical, and technical safeguard procedures mapped to your environment
• Workforce access records: role-based access decisions, sanction policy acknowledgment, training completion
• Business Associate Agreements: executed BAAs, tracking list, renewal dates, exceptions
• Device and media controls: inventory, disposal records, encryption status where relevant
• Contingency planning records: backup, disaster recovery, emergency mode operations evidence
• Breach and incident response records: internal workflow, notification decision logs, tabletop exercises

Why it matters: HIPAA evidence is often more procedural than teams expect. Keep both the written procedure and an example record showing that the procedure was followed. For BAA details, see Business Associate Agreement Requirements: What Covered Entities and Vendors Need to Check.

6. Vendor risk and third-party assurance

• Vendor inventory: systems, data categories handled, business owner, criticality rating, contract status
• Due diligence records: completed vendor security questionnaire, review notes, approvals, remediation requests
• External assurance artifacts: SOC reports, ISO certificates, penetration test summaries, privacy terms, subprocessors
• Contractual protections: DPAs, BAAs, security addenda, subprocessor agreement clauses
• Ongoing review records: annual refreshes, trigger-based reviews after incidents or scope changes

Why it matters: Vendor evidence supports GDPR accountability, HIPAA third-party diligence, and customer expectations during security reviews. A structured scoring approach is covered in Vendor Risk Assessment Guide: Scoring Critical Vendors by Data Access and Business Impact.

7. SOC 2 audit preparation evidence

• Control matrix: criterion, control description, owner, evidence source, testing frequency
• Population lists: complete lists for users, tickets, incidents, vendors, changes, and assets that auditors can sample from
• Point-in-time and period evidence: policies and configurations for design, plus recurring review records for operating effectiveness
• Exceptions log: known gaps, temporary workarounds, remediation plans, compensating controls
• Audit calendar: requested-by dates, review milestones, evidence refresh plan

Why it matters: A clean SOC 2 evidence list usually depends less on writing new documents and more on gathering complete populations and recurring records. If timing is a concern, SOC 2 Timeline: How Long Readiness, Remediation, and Audit Usually Take can help set expectations, and SOC 2 vs ISO 27001 for SaaS: Which Framework to Tackle First helps with sequencing.

What to double-check

Before you mark evidence as complete, review these details. They are where many otherwise solid programs break down.

• Dates: Is the artifact current enough for the review period? A strong policy with a stale review date still creates friction.
• Scope: Does the evidence cover the right environment, business unit, product, or data set? Teams often submit a screenshot from one system while the actual in-scope workflow happens elsewhere.
• Named ownership: Can someone explain the artifact if a customer or auditor asks follow-up questions?
• Traceability: Can you connect the artifact to a written policy or control statement?
• Completeness: For sample-based testing, do you have a full population list, not just a few handpicked examples?
• Redaction: Have you removed secrets, personal data, or unnecessary sensitive details before sharing evidence externally?
• Consistency: Do policy statements, system settings, and operational records agree with each other?

A useful rule is to store both a narrative artifact and an operational artifact. For example, pair an access control policy with an access review report; pair an incident response policy with a tabletop record or incident ticket; pair a retention policy with an actual deletion log or workflow export.

Common mistakes

The fastest way to create audit stress is to collect evidence only when someone asks for it. These are the most common issues to avoid.

• Treating screenshots as the whole evidence program. Screenshots are useful, but they do not replace logs, exports, approvals, or review records.
• Saving files without context. An unlabeled PDF called final-v3 tells you very little six months later. Include owner, system, date, and purpose.
• Keeping policies but not records. Audits and diligence reviews often ask whether a control operates, not just whether it exists on paper.
• Ignoring privacy artifacts. Security-heavy teams sometimes neglect GDPR compliance documentation such as records of processing, DSAR handling, retention logic, and DPA tracking.
• Not versioning legal and compliance documents. You need to know what terms, notice, or procedure was active at a given time.
• Forgetting third parties. Vendors can create some of the highest risk and some of the most frequent customer questions.
• Building separate evidence silos for each framework. Cross-mapping one core evidence library is usually more sustainable than maintaining three disconnected programs.

If customer questionnaires are driving the urgency, standardize your evidence references as you go. One approved answer linked to one current artifact is more efficient than rewriting the same explanation in every spreadsheet.

When to revisit

This checklist is most useful when you return to it on a schedule and after meaningful change. Do not wait for the audit kickoff email.

Revisit your evidence library at these moments:

• Before seasonal planning cycles: review open gaps, policy review dates, vendor renewals, and training refresh needs
• When workflows or tools change: identity provider migration, new ticketing system, new cloud environment, logging changes, HRIS changes, or a new consent platform
• When you launch a new product or process new data types: especially if personal data or PHI scope changes
• When vendors change: new subprocessors, critical vendor replacements, updated BAAs or DPAs, or new hosting regions
• After incidents or near misses: refresh evidence to reflect process improvements and control updates
• Before a formal audit or enterprise sales push: confirm that your populations, approvals, and review records are complete for the expected period

A simple operating rhythm works well for many teams:

1. Assign one owner for the evidence library and one backup.
2. Map every control to one source system and one recurring artifact.
3. Review high-value evidence monthly: access reviews, vendor changes, incidents, backups, and open risks.
4. Review policy and privacy documentation quarterly or at least on a defined schedule.
5. Run a lightweight readiness check before major customer diligence periods.

If you want this checklist to stay evergreen, turn it into a living index instead of a one-time project folder. Add last-reviewed dates, owners, and framework tags such as GDPR, SOC 2, and HIPAA. That small layer of structure makes future updates faster, improves handoffs between security, legal, and operations, and gives your team a cleaner answer when someone asks, “What proof do we already have?”

The end goal is not to collect more files. It is to maintain evidence that is accurate, explainable, and ready to reuse. That is what makes compliance operations less reactive and much easier to sustain.