Compliance Checker

Compliance Checker

Perform thorough regulatory compliance audits against one or more frameworks, identify gaps, and produce actionable remediation guidance with evidence requirements suitable for certification preparation.

Contents

• references/frameworks.md — the five supported frameworks (GDPR, HIPAA, SOC 2, CCPA, PCI-DSS): scope, key articles/requirements, penalties, and reference links.
• references/scan-patterns.md — the seven scan categories, their search patterns, scan execution rules, and common pitfalls to always check.
• references/classification.md — compliance status values, risk severity rubric, and the remediation detail fields.
• references/cross-framework-mapping.md — control-area-to-framework mapping and the glossary.
• references/output-template.md — the full compliance-report.md structure, including per-framework gap-analysis tables and evidence packs.

Workflow

Run the full methodology for every audit. Do not skip steps.

Phase 1: Discovery and Scoping

1. Identify the target: codebase, infrastructure configuration, business process documentation, or a combination. 2. Determine applicable frameworks from the data types processed, geographic scope, industry, and business model. See references/frameworks.md. When none are specified, assess all five and note applicability. 3. Map the data flow: where regulated data enters, how it is processed, where it is stored, and how it exits. 4. Inventory data categories present (PII, PHI, CHD, sensitive PI, special category data).

Phase 2: Scanning and Evidence Collection

5. Scan each of the seven categories — PII/sensitive data, data retention, encryption, access controls, audit logging, consent management, and data transfer. Apply the search patterns and execution rules in references/scan-patterns.md. Record exact file paths, line numbers, and snippets for both positive findings and gaps.

Phase 3: Gap Analysis

6. Map each finding to specific framework requirements, assign a compliance status, and assign a risk severity to every non-compliant or partial finding. Use the rubric in references/classification.md.

Phase 4: Remediation Planning

7. For each non-compliant or partial finding, produce the remediation detail (description, regulatory reference, current state, required state, steps, evidence, effort, dependencies) per references/classification.md. Cross-reference references/cross-framework-mapping.md to flag when one action closes gaps across multiple frameworks.

Phase 5: Report Generation

8. Generate compliance-report.md in the project root (or a user-specified location), following the mandatory structure in references/output-template.md. Every section is required; if a section has no findings, state that explicitly.

Behavioral Rules

1. Never fabricate findings. Back every finding with scan evidence. When evidence is absent, mark UNABLE TO ASSESS rather than guess. 2. Be specific. Reference exact file paths, line numbers, function names, and configuration keys. 3. Distinguish technical from organizational controls. Note when a finding requires verifying organizational controls (training, policies, physical security) that code review alone cannot confirm. 4. Consider the full stack: application code, database schemas, infrastructure configuration, CI/CD pipelines, dependency manifests, documentation, and environment configuration. 5. Prioritize actionable findings. Specify exact changes; avoid vague recommendations like "improve security". 6. Respect the scope. Audit only what is provided. Do not assume broader infrastructure without evidence. 7. Account for frameworks and libraries that handle compliance concerns (ORM parameterized queries, framework CSRF protection); credit them as positive findings but verify configuration. 8. Avoid false positives. Missing a marginal finding is better than reporting a non-gap. Err toward accuracy. 9. Cross-reference across frameworks. Note when a single remediation addresses multiple regulations. 10. Date and version everything so the report can be compared against future audits.

Responding to Requests

• "Audit this codebase" / "check compliance": Confirm which frameworks to focus on (or assess all five), run Phases 1-5, generate compliance-report.md, and summarize the most critical findings.
• "Check for [framework]": Focus on that framework, still scan all seven categories, and map findings only to it.
• "Check [category]" (e.g., "check encryption"): Focus the scan on that category and map findings to all applicable frameworks.
• "Are we [requirement] compliant?" (e.g., GDPR Art. 17): Focus on the relevant controls, give a direct assessment with evidence, and offer remediation if gaps exist.
• Business process documentation instead of code: Adapt the methodology to document analysis, focus on policy and procedure requirements, and note that technical controls cannot be verified without codebase access.

Classification, Severity, and Remediation Rubric

Compliance Status

Classify each finding against each applicable framework requirement:

• COMPLIANT: Requirement fully met with sufficient evidence.
• PARTIAL: Some controls exist but are incomplete or inconsistently applied.
• NON-COMPLIANT: Requirement not met or no evidence of controls exists.
• NOT APPLICABLE: Requirement does not apply to this system.
• UNABLE TO ASSESS: Insufficient information to make a determination (specify what additional information is needed).

Risk Severity

Assign a severity to each non-compliant or partial finding:

Remediation Detail

For each non-compliant or partial finding, provide: 1. Description: What the gap is and why it matters. 2. Regulatory Reference: The specific article, section, requirement, or criterion that is not met. 3. Current State: What currently exists, if anything. 4. Required State: What must be in place to achieve compliance. 5. Remediation Steps: Specific, actionable steps to close the gap, including code changes, configuration changes, policy documents, or process changes. 6. Evidence Requirements: What documentation, artifacts, or technical evidence an auditor would need to verify compliance. 7. Estimated Effort: T-shirt size (XS/S/M/L/XL). 8. Dependencies: Other findings or external factors that must be addressed first.

Cross-Framework Requirement Mapping

Many regulatory requirements overlap. Use this mapping to identify when a single control satisfies multiple frameworks, and note in the remediation plan when one action closes gaps across several regulations.

Glossary

Supported Regulatory Frameworks

Audit against the following frameworks. When the user does not specify which frameworks to check, audit against all of them and note which apply based on the nature of the codebase or business process.

1. GDPR (General Data Protection Regulation)

• Scope: Any system that processes personal data of EU/EEA residents
• Key Articles: Art. 5 (principles), Art. 6 (lawful basis), Art. 7 (consent), Art. 12-23 (data subject rights), Art. 25 (data protection by design), Art. 28 (processors), Art. 30 (records of processing), Art. 32 (security), Art. 33-34 (breach notification), Art. 35 (DPIA), Art. 44-49 (international transfers)
• Penalties: Up to 4% of annual global turnover or EUR 20 million

2. HIPAA (Health Insurance Portability and Accountability Act)

• Scope: Covered entities and business associates handling Protected Health Information (PHI)
• Key Rules: Privacy Rule, Security Rule (Administrative/Physical/Technical Safeguards), Breach Notification Rule, Enforcement Rule
• Key Standards: 164.308 (Administrative), 164.310 (Physical), 164.312 (Technical), 164.314 (Organizational), 164.316 (Policies/Documentation)
• Penalties: $100 to $50,000 per violation, up to $1.5 million per year per category

3. SOC 2 (Service Organization Control 2)

• Scope: Service organizations that store, process, or transmit customer data
• Trust Service Criteria: Security (CC1-CC9), Availability (A1), Processing Integrity (PI1), Confidentiality (C1), Privacy (P1)
• Common Criteria: CC1 (Control Environment), CC2 (Communication), CC3 (Risk Assessment), CC4 (Monitoring), CC5 (Control Activities), CC6 (Logical/Physical Access), CC7 (System Operations), CC8 (Change Management), CC9 (Risk Mitigation)

4. CCPA (California Consumer Privacy Act) / CPRA

• Scope: Businesses collecting personal information of California residents meeting revenue/data thresholds
• Key Rights: Right to Know, Right to Delete, Right to Opt-Out of Sale/Sharing, Right to Non-Discrimination, Right to Correct, Right to Limit Use of Sensitive PI
• Key Sections: 1798.100 (general duties), 1798.105 (deletion), 1798.110 (disclosure), 1798.115 (sale/sharing disclosure), 1798.120 (opt-out), 1798.121 (limit sensitive PI), 1798.125 (non-discrimination)
• Penalties: $2,500 per unintentional violation, $7,500 per intentional violation

5. PCI-DSS (Payment Card Industry Data Security Standard) v4.0

• Scope: Any entity that stores, processes, or transmits cardholder data
• Requirements: Req 1 (Network Security Controls), Req 2 (Secure Configurations), Req 3 (Protect Stored Account Data), Req 4 (Cryptography in Transit), Req 5 (Malware Protection), Req 6 (Secure Development), Req 7 (Restrict Access), Req 8 (Identify Users/Auth), Req 9 (Physical Access), Req 10 (Log/Monitor), Req 11 (Security Testing), Req 12 (Security Policies)
• Penalties: $5,000 to $100,000 per month of non-compliance, potential loss of card processing privileges

Regulatory Reference Links

• GDPR Full Text: https://eur-lex.europa.eu/eli/reg/2016/679/oj
• HIPAA Security Rule: https://www.hhs.gov/hipaa/for-professionals/security/index.html
• SOC 2 Trust Service Criteria: https://us.aicpa.org/interestareas/frc/assuranceadvisoryservices/trustservicescriteria
• CCPA/CPRA Text: https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5
• PCI-DSS v4.0: https://www.pcisecuritystandards.org/document_library/

Output Template

Generate the final report as compliance-report.md in the project root (or a user-specified location). Every section is mandatory. If a section has no findings, state explicitly that none were identified.

# Compliance Audit Report

**Audit Date**: [Date of audit]
**Audit Scope**: [Description of what was audited]
**Auditor**: Claude Code Compliance Checker
**Frameworks Assessed**: [List of applicable frameworks]

---

## Executive Summary

[2-3 paragraph summary of overall compliance posture, key risks, and top priority actions. Include a summary table:]

| Framework | Status | Critical | High | Medium | Low | Info |
|-----------|--------|----------|------|--------|-----|------|
| GDPR      | [status] | [n]   | [n]  | [n]    | [n] | [n]  |
| HIPAA     | [status] | [n]   | [n]  | [n]    | [n] | [n]  |
| SOC 2     | [status] | [n]   | [n]  | [n]    | [n] | [n]  |
| CCPA      | [status] | [n]   | [n]  | [n]    | [n] | [n]  |
| PCI-DSS   | [status] | [n]   | [n]  | [n]    | [n] | [n]  |

**Overall Risk Rating**: [Critical / High / Medium / Low]
**Total Findings**: [N] ([breakdown by severity])
**Immediate Actions Required**: [count]

---

## Table of Contents

1. Audit Scope and Methodology
2. Data Inventory
3. Findings by Scan Category
   3.1 PII and Sensitive Data Handling
   3.2 Data Retention
   3.3 Encryption
   3.4 Access Controls
   3.5 Audit Logging
   3.6 Consent Management
   3.7 Data Transfer
4. Gap Analysis by Framework
   4.1 GDPR Gap Analysis
   4.2 HIPAA Gap Analysis
   4.3 SOC 2 Gap Analysis
   4.4 CCPA Gap Analysis
   4.5 PCI-DSS Gap Analysis
5. Remediation Plan
6. Evidence Requirements for Certification
7. Appendices

---

## 1. Audit Scope and Methodology

### Scope
[Describe what was included: repositories, services, infrastructure, documentation]

### Methodology
[Describe the approach: automated scanning, manual code review, configuration review, documentation review]

### Limitations
[Describe any limitations: areas that could not be assessed, information that was unavailable, assumptions made]

### Framework Applicability Determination
[For each framework, explain why it is or is not applicable to this system]

---

## 2. Data Inventory

### Data Categories Identified

| Category | Data Elements | Storage Location(s) | Classification |
|----------|--------------|---------------------|----------------|
| [category] | [elements] | [locations] | [PII/PHI/CHD/Sensitive/Public] |

### Data Flow Summary
[Describe how regulated data flows through the system: ingestion points, processing steps, storage locations, output/transfer points, deletion]

---

## 3. Findings by Scan Category

Repeat the following structure for each of the seven categories (3.1 through 3.7):

### 3.X [Category Name]

#### Positive Findings (Evidence of Compliance)
[List controls and practices that support compliance, with file paths and line numbers]

#### Gaps and Issues

**Finding [ID]: [Title]**
- **Severity**: [CRITICAL/HIGH/MEDIUM/LOW/INFO]
- **Location**: [File path and line numbers]
- **Description**: [What was found or what is missing]
- **Affected Frameworks**: [Which frameworks this impacts]
- **Evidence**: [Code snippet or configuration excerpt]
- **Risk**: [What could go wrong if not addressed]

[Repeat for each finding]

---

## 4. Gap Analysis by Framework

### 4.1 GDPR Gap Analysis

| Article/Requirement | Description | Status | Severity | Finding Ref |
|---------------------|-------------|--------|----------|-------------|
| Art. 5(1)(a) | Lawfulness, fairness, transparency | [status] | [severity] | [ref] |
| Art. 5(1)(b) | Purpose limitation | [status] | [severity] | [ref] |
| Art. 5(1)(c) | Data minimisation | [status] | [severity] | [ref] |
| Art. 5(1)(d) | Accuracy | [status] | [severity] | [ref] |
| Art. 5(1)(e) | Storage limitation | [status] | [severity] | [ref] |
| Art. 5(1)(f) | Integrity and confidentiality | [status] | [severity] | [ref] |
| Art. 5(2) | Accountability | [status] | [severity] | [ref] |
| Art. 6 | Lawful basis for processing | [status] | [severity] | [ref] |
| Art. 7 | Conditions for consent | [status] | [severity] | [ref] |
| Art. 12 | Transparent information | [status] | [severity] | [ref] |
| Art. 13 | Information at collection | [status] | [severity] | [ref] |
| Art. 14 | Information not obtained from data subject | [status] | [severity] | [ref] |
| Art. 15 | Right of access | [status] | [severity] | [ref] |
| Art. 16 | Right to rectification | [status] | [severity] | [ref] |
| Art. 17 | Right to erasure | [status] | [severity] | [ref] |
| Art. 18 | Right to restriction | [status] | [severity] | [ref] |
| Art. 20 | Right to data portability | [status] | [severity] | [ref] |
| Art. 21 | Right to object | [status] | [severity] | [ref] |
| Art. 22 | Automated decision-making | [status] | [severity] | [ref] |
| Art. 25 | Data protection by design/default | [status] | [severity] | [ref] |
| Art. 28 | Processor obligations | [status] | [severity] | [ref] |
| Art. 30 | Records of processing | [status] | [severity] | [ref] |
| Art. 32 | Security of processing | [status] | [severity] | [ref] |
| Art. 33 | Breach notification to authority | [status] | [severity] | [ref] |
| Art. 34 | Breach notification to data subjects | [status] | [severity] | [ref] |
| Art. 35 | Data protection impact assessment | [status] | [severity] | [ref] |
| Art. 37 | Data Protection Officer | [status] | [severity] | [ref] |
| Art. 44-49 | International transfers | [status] | [severity] | [ref] |

### 4.2 HIPAA Gap Analysis

| Standard | Requirement | Status | Severity | Finding Ref |
|----------|-------------|--------|----------|-------------|
| 164.308(a)(1) | Security Management Process | [status] | [severity] | [ref] |
| 164.308(a)(2) | Assigned Security Responsibility | [status] | [severity] | [ref] |
| 164.308(a)(3) | Workforce Security | [status] | [severity] | [ref] |
| 164.308(a)(4) | Information Access Management | [status] | [severity] | [ref] |
| 164.308(a)(5) | Security Awareness Training | [status] | [severity] | [ref] |
| 164.308(a)(6) | Security Incident Procedures | [status] | [severity] | [ref] |
| 164.308(a)(7) | Contingency Plan | [status] | [severity] | [ref] |
| 164.308(a)(8) | Evaluation | [status] | [severity] | [ref] |
| 164.310(a) | Facility Access Controls | [status] | [severity] | [ref] |
| 164.310(b) | Workstation Use | [status] | [severity] | [ref] |
| 164.310(c) | Workstation Security | [status] | [severity] | [ref] |
| 164.310(d) | Device and Media Controls | [status] | [severity] | [ref] |
| 164.312(a) | Access Control | [status] | [severity] | [ref] |
| 164.312(b) | Audit Controls | [status] | [severity] | [ref] |
| 164.312(c) | Integrity | [status] | [severity] | [ref] |
| 164.312(d) | Person or Entity Authentication | [status] | [severity] | [ref] |
| 164.312(e) | Transmission Security | [status] | [severity] | [ref] |
| 164.314(a) | Business Associate Contracts | [status] | [severity] | [ref] |
| 164.316(a) | Policies and Procedures | [status] | [severity] | [ref] |
| 164.316(b) | Documentation | [status] | [severity] | [ref] |
| 164.402-414 | Breach Notification | [status] | [severity] | [ref] |

### 4.3 SOC 2 Gap Analysis

| Criteria | Description | Status | Severity | Finding Ref |
|----------|-------------|--------|----------|-------------|
| CC1.1 | COSO Principle 1: Integrity and Ethics | [status] | [severity] | [ref] |
| CC1.2 | COSO Principle 2: Board Oversight | [status] | [severity] | [ref] |
| CC1.3 | COSO Principle 3: Management Structure | [status] | [severity] | [ref] |
| CC1.4 | COSO Principle 4: Competence Commitment | [status] | [severity] | [ref] |
| CC1.5 | COSO Principle 5: Accountability | [status] | [severity] | [ref] |
| CC2.1 | COSO Principle 13: Quality Information | [status] | [severity] | [ref] |
| CC2.2 | COSO Principle 14: Internal Communication | [status] | [severity] | [ref] |
| CC2.3 | COSO Principle 15: External Communication | [status] | [severity] | [ref] |
| CC3.1 | COSO Principle 6: Risk Objectives | [status] | [severity] | [ref] |
| CC3.2 | COSO Principle 7: Risk Identification | [status] | [severity] | [ref] |
| CC3.3 | COSO Principle 8: Fraud Risk | [status] | [severity] | [ref] |
| CC3.4 | COSO Principle 9: Change Impact | [status] | [severity] | [ref] |
| CC4.1 | COSO Principle 16: Monitoring | [status] | [severity] | [ref] |
| CC4.2 | COSO Principle 17: Deficiency Evaluation | [status] | [severity] | [ref] |
| CC5.1 | COSO Principle 10: Control Selection | [status] | [severity] | [ref] |
| CC5.2 | COSO Principle 11: Technology Controls | [status] | [severity] | [ref] |
| CC5.3 | COSO Principle 12: Control Deployment | [status] | [severity] | [ref] |
| CC6.1 | Logical and Physical Access - Security Software | [status] | [severity] | [ref] |
| CC6.2 | Logical and Physical Access - Credentials | [status] | [severity] | [ref] |
| CC6.3 | Logical and Physical Access - New Access | [status] | [severity] | [ref] |
| CC6.6 | Logical and Physical Access - External Threats | [status] | [severity] | [ref] |
| CC6.7 | Logical and Physical Access - Data Transmission | [status] | [severity] | [ref] |
| CC6.8 | Logical and Physical Access - Malicious Software | [status] | [severity] | [ref] |
| CC7.1 | System Operations - Vulnerability Detection | [status] | [severity] | [ref] |
| CC7.2 | System Operations - Anomaly Monitoring | [status] | [severity] | [ref] |
| CC7.3 | System Operations - Incident Evaluation | [status] | [severity] | [ref] |
| CC7.4 | System Operations - Incident Response | [status] | [severity] | [ref] |
| CC7.5 | System Operations - Incident Recovery | [status] | [severity] | [ref] |
| CC8.1 | Change Management - Authorization | [status] | [severity] | [ref] |
| CC9.1 | Risk Mitigation - Business Disruption | [status] | [severity] | [ref] |
| CC9.2 | Risk Mitigation - Vendor Management | [status] | [severity] | [ref] |
| A1.1 | Availability - Capacity Planning | [status] | [severity] | [ref] |
| A1.2 | Availability - Recovery Infrastructure | [status] | [severity] | [ref] |
| A1.3 | Availability - Recovery Testing | [status] | [severity] | [ref] |
| C1.1 | Confidentiality - Identification | [status] | [severity] | [ref] |
| C1.2 | Confidentiality - Disposal | [status] | [severity] | [ref] |

### 4.4 CCPA Gap Analysis

| Section | Requirement | Status | Severity | Finding Ref |
|---------|-------------|--------|----------|-------------|
| 1798.100(a) | Right to know categories | [status] | [severity] | [ref] |
| 1798.100(b) | Notice at collection | [status] | [severity] | [ref] |
| 1798.100(d) | Purpose limitation | [status] | [severity] | [ref] |
| 1798.100(e) | Data minimization | [status] | [severity] | [ref] |
| 1798.105 | Right to delete | [status] | [severity] | [ref] |
| 1798.106 | Right to correct | [status] | [severity] | [ref] |
| 1798.110 | Right to know specific pieces | [status] | [severity] | [ref] |
| 1798.115 | Right to know sale/sharing | [status] | [severity] | [ref] |
| 1798.120 | Right to opt-out of sale/sharing | [status] | [severity] | [ref] |
| 1798.121 | Right to limit sensitive PI use | [status] | [severity] | [ref] |
| 1798.125 | Non-discrimination | [status] | [severity] | [ref] |
| 1798.130 | Verification of requests | [status] | [severity] | [ref] |
| 1798.135 | Do Not Sell/Share link | [status] | [severity] | [ref] |
| 1798.140(v) | Service provider obligations | [status] | [severity] | [ref] |
| 1798.185 | Reasonable security | [status] | [severity] | [ref] |

### 4.5 PCI-DSS Gap Analysis

| Requirement | Description | Status | Severity | Finding Ref |
|-------------|-------------|--------|----------|-------------|
| 1.1 | Network security controls defined | [status] | [severity] | [ref] |
| 1.2 | Network security controls configured | [status] | [severity] | [ref] |
| 1.3 | Network access restricted | [status] | [severity] | [ref] |
| 1.4 | Network connections controlled | [status] | [severity] | [ref] |
| 1.5 | Risks to CDE mitigated | [status] | [severity] | [ref] |
| 2.1 | Secure configurations applied | [status] | [severity] | [ref] |
| 2.2 | System components configured securely | [status] | [severity] | [ref] |
| 2.3 | Wireless environments secured | [status] | [severity] | [ref] |
| 3.1 | Account data storage minimized | [status] | [severity] | [ref] |
| 3.2 | Sensitive authentication data not stored post-auth | [status] | [severity] | [ref] |
| 3.3 | PAN displayed securely (masked) | [status] | [severity] | [ref] |
| 3.4 | PAN secured when stored | [status] | [severity] | [ref] |
| 3.5 | PAN secured where stored | [status] | [severity] | [ref] |
| 3.6 | Cryptographic keys managed | [status] | [severity] | [ref] |
| 3.7 | Stored account data protected | [status] | [severity] | [ref] |
| 4.1 | Strong cryptography in transit | [status] | [severity] | [ref] |
| 4.2 | PAN secured in end-user messaging | [status] | [severity] | [ref] |
| 5.1 | Malware protection deployed | [status] | [severity] | [ref] |
| 5.2 | Malware prevention maintained | [status] | [severity] | [ref] |
| 5.3 | Anti-malware active and monitored | [status] | [severity] | [ref] |
| 5.4 | Anti-phishing mechanisms | [status] | [severity] | [ref] |
| 6.1 | Secure development processes | [status] | [severity] | [ref] |
| 6.2 | Bespoke software developed securely | [status] | [severity] | [ref] |
| 6.3 | Security vulnerabilities identified and addressed | [status] | [severity] | [ref] |
| 6.4 | Public-facing web apps protected | [status] | [severity] | [ref] |
| 6.5 | Changes managed securely | [status] | [severity] | [ref] |
| 7.1 | Access restricted by need to know | [status] | [severity] | [ref] |
| 7.2 | Access appropriately defined | [status] | [severity] | [ref] |
| 7.3 | Access control system configured | [status] | [severity] | [ref] |
| 8.1 | User identification management | [status] | [severity] | [ref] |
| 8.2 | User identification enforced | [status] | [severity] | [ref] |
| 8.3 | Strong authentication established | [status] | [severity] | [ref] |
| 8.4 | MFA implemented | [status] | [severity] | [ref] |
| 8.5 | MFA systems configured properly | [status] | [severity] | [ref] |
| 8.6 | Application/system accounts managed | [status] | [severity] | [ref] |
| 9.1 | Physical access restricted | [status] | [severity] | [ref] |
| 9.2 | Physical access controls manage entry | [status] | [severity] | [ref] |
| 9.3 | Physical access for personnel authorized | [status] | [severity] | [ref] |
| 9.4 | Media physically secured | [status] | [severity] | [ref] |
| 9.5 | POI devices protected | [status] | [severity] | [ref] |
| 10.1 | Logging mechanisms defined | [status] | [severity] | [ref] |
| 10.2 | Audit logs capture details | [status] | [severity] | [ref] |
| 10.3 | Audit logs protected | [status] | [severity] | [ref] |
| 10.4 | Audit logs reviewed | [status] | [severity] | [ref] |
| 10.5 | Audit log history retained | [status] | [severity] | [ref] |
| 10.6 | Time synchronization mechanisms | [status] | [severity] | [ref] |
| 10.7 | Detection of logging failures | [status] | [severity] | [ref] |
| 11.1 | Wireless access points detected | [status] | [severity] | [ref] |
| 11.2 | Wireless access points authorized | [status] | [severity] | [ref] |
| 11.3 | Vulnerabilities identified and addressed | [status] | [severity] | [ref] |
| 11.4 | Penetration testing performed | [status] | [severity] | [ref] |
| 11.5 | Network intrusions detected and responded | [status] | [severity] | [ref] |
| 11.6 | Unauthorized changes detected | [status] | [severity] | [ref] |
| 12.1 | Security policy established | [status] | [severity] | [ref] |
| 12.2 | Acceptable use policies | [status] | [severity] | [ref] |
| 12.3 | Risks formally identified | [status] | [severity] | [ref] |
| 12.4 | PCI-DSS responsibilities assigned | [status] | [severity] | [ref] |
| 12.5 | PCI-DSS scope documented | [status] | [severity] | [ref] |
| 12.6 | Security awareness program | [status] | [severity] | [ref] |
| 12.7 | Personnel screened | [status] | [severity] | [ref] |
| 12.8 | Third-party service provider risk managed | [status] | [severity] | [ref] |
| 12.9 | TPSPs acknowledge responsibilities | [status] | [severity] | [ref] |
| 12.10 | Incident response plan | [status] | [severity] | [ref] |

---

## 5. Remediation Plan

### Priority Matrix

| Priority | Finding ID | Title | Framework(s) | Severity | Effort | Owner |
|----------|-----------|-------|--------------|----------|--------|-------|
| 1 | [ID] | [title] | [frameworks] | [severity] | [XS-XL] | [TBD] |

### Detailed Remediation Steps

For each finding requiring remediation:

**[Finding ID]: [Title]**
- **Regulatory Reference**: [specific article/section/requirement]
- **Current State**: [what exists today]
- **Required State**: [what must be in place]
- **Remediation Steps**:
  1. [Step 1 with specific technical or process action]
  2. [Step 2]
  3. [Step N]
- **Evidence Required**: [what documentation or artifacts to produce]
- **Estimated Effort**: [XS/S/M/L/XL]
- **Dependencies**: [other findings or external factors]
- **Suggested Timeline**: [specific date range based on severity]

---

## 6. Evidence Requirements for Certification

This section outlines the documentation and technical artifacts needed for each framework's certification or audit process.

### GDPR Evidence Pack
| Evidence Item | Description | Status | Location |
|--------------|-------------|--------|----------|
| Records of Processing Activities (ROPA) | Art. 30 register of all processing activities | [exists/needed] | [path] |
| Privacy Impact Assessments (DPIAs) | Art. 35 impact assessments for high-risk processing | [exists/needed] | [path] |
| Privacy Policy | Art. 12-13 public-facing privacy notice | [exists/needed] | [path] |
| Consent Records | Art. 7 records of consent given and withdrawn | [exists/needed] | [path] |
| Data Subject Request Procedures | Art. 15-22 procedures for handling DSARs | [exists/needed] | [path] |
| Data Processing Agreements | Art. 28 DPAs with all processors | [exists/needed] | [path] |
| Breach Response Plan | Art. 33-34 incident response procedures | [exists/needed] | [path] |
| Transfer Mechanisms | Art. 44-49 SCCs, adequacy, or BCRs | [exists/needed] | [path] |
| Legitimate Interest Assessments | Art. 6(1)(f) LIA documentation | [exists/needed] | [path] |
| Data Protection Officer Appointment | Art. 37 DPO designation (if required) | [exists/needed] | [path] |
| Training Records | Staff privacy training evidence | [exists/needed] | [path] |
| Technical and Organizational Measures | Art. 32 security measures documentation | [exists/needed] | [path] |

### HIPAA Evidence Pack
| Evidence Item | Description | Status | Location |
|--------------|-------------|--------|----------|
| Risk Analysis | 164.308(a)(1) comprehensive risk assessment | [exists/needed] | [path] |
| Risk Management Plan | 164.308(a)(1) risk mitigation strategy | [exists/needed] | [path] |
| Security Policies and Procedures | 164.316 complete policy documentation | [exists/needed] | [path] |
| Business Associate Agreements (BAAs) | 164.314 agreements with all BAs | [exists/needed] | [path] |
| Workforce Training Records | 164.308(a)(5) training evidence | [exists/needed] | [path] |
| Access Authorization Records | 164.308(a)(4) access management evidence | [exists/needed] | [path] |
| Incident Response Plan | 164.308(a)(6) security incident procedures | [exists/needed] | [path] |
| Contingency Plan | 164.308(a)(7) disaster recovery documentation | [exists/needed] | [path] |
| Audit Log Samples | 164.312(b) system activity records | [exists/needed] | [path] |
| Encryption Documentation | 164.312(a)(2)(iv) & 164.312(e)(2)(ii) encryption implementation records | [exists/needed] | [path] |
| Physical Safeguard Documentation | 164.310 facility security measures | [exists/needed] | [path] |
| Breach Notification Procedures | 164.402-414 breach response plan | [exists/needed] | [path] |
| Minimum Necessary Documentation | 164.502(b) minimum necessary determinations | [exists/needed] | [path] |
| Sanctions Policy | 164.308(a)(1)(ii)(C) workforce sanctions | [exists/needed] | [path] |

### SOC 2 Evidence Pack
| Evidence Item | Description | Status | Location |
|--------------|-------------|--------|----------|
| Security Policies | Comprehensive information security policies | [exists/needed] | [path] |
| Risk Assessment Report | Formal risk assessment documentation | [exists/needed] | [path] |
| Access Control Matrix | User access rights and role definitions | [exists/needed] | [path] |
| Change Management Records | Change request, approval, and deployment records | [exists/needed] | [path] |
| Incident Response Plan | Security incident response procedures | [exists/needed] | [path] |
| Vendor Management Documentation | Third-party risk assessment and monitoring | [exists/needed] | [path] |
| Business Continuity Plan | Disaster recovery and continuity documentation | [exists/needed] | [path] |
| Monitoring and Alerting Configuration | System monitoring and alerting setup | [exists/needed] | [path] |
| Penetration Test Reports | Annual penetration testing results | [exists/needed] | [path] |
| Vulnerability Scan Reports | Regular vulnerability scan results | [exists/needed] | [path] |
| Employee Handbook / Code of Conduct | Organizational commitment to integrity | [exists/needed] | [path] |
| Onboarding and Offboarding Checklists | User provisioning and deprovisioning | [exists/needed] | [path] |
| System Description | Description of the system and boundaries | [exists/needed] | [path] |
| Control Activities Documentation | Detailed control descriptions and evidence | [exists/needed] | [path] |

### CCPA Evidence Pack
| Evidence Item | Description | Status | Location |
|--------------|-------------|--------|----------|
| Privacy Policy (CCPA-specific) | Notice at collection with all required disclosures | [exists/needed] | [path] |
| Do Not Sell/Share Page | Consumer-facing opt-out mechanism | [exists/needed] | [path] |
| Data Inventory | Catalog of personal information collected and purposes | [exists/needed] | [path] |
| Consumer Request Procedures | Verified request handling workflows | [exists/needed] | [path] |
| Service Provider Agreements | Contracts restricting use of shared PI | [exists/needed] | [path] |
| Opt-Out Mechanism Documentation | Technical implementation of opt-out signals (GPC) | [exists/needed] | [path] |
| Training Records | Staff training on CCPA obligations | [exists/needed] | [path] |
| Financial Incentive Notices | If offering incentives for PI collection | [exists/needed] | [path] |
| Data Retention Schedule | Retention periods for each category of PI | [exists/needed] | [path] |
| Metrics / Request Log | Records of consumer requests received and fulfilled | [exists/needed] | [path] |

### PCI-DSS Evidence Pack
| Evidence Item | Description | Status | Location |
|--------------|-------------|--------|----------|
| Network Diagram | Current network topology with CDE boundaries | [exists/needed] | [path] |
| Data Flow Diagram | Cardholder data flow documentation | [exists/needed] | [path] |
| System Inventory | All systems in CDE scope | [exists/needed] | [path] |
| Security Policies | Information security policy document | [exists/needed] | [path] |
| Vulnerability Scan Reports | Internal and external (ASV) scan results | [exists/needed] | [path] |
| Penetration Test Reports | Annual internal and external pen test results | [exists/needed] | [path] |
| Access Control Documentation | User access management procedures and logs | [exists/needed] | [path] |
| Change Management Records | System change documentation and approvals | [exists/needed] | [path] |
| Incident Response Plan | Cardholder data breach response procedures | [exists/needed] | [path] |
| Encryption Key Management | Key lifecycle documentation | [exists/needed] | [path] |
| Security Awareness Training | Annual training records for all personnel | [exists/needed] | [path] |
| Vendor Risk Assessments | Third-party service provider evaluations | [exists/needed] | [path] |
| Firewall/NSC Rule Review | Documented review of network security controls | [exists/needed] | [path] |
| Anti-Malware Configuration | Malware protection deployment evidence | [exists/needed] | [path] |
| Log Retention Evidence | 12 months of audit log history (3 months immediately available) | [exists/needed] | [path] |
| Physical Security Documentation | Physical access control measures for CDE | [exists/needed] | [path] |
| Wireless Security Assessment | Wireless access point inventory and testing | [exists/needed] | [path] |
| Segmentation Testing Results | Validation that segmentation controls are effective | [exists/needed] | [path] |

---

## 7. Appendices

### Appendix A: Files Scanned
[List all files that were examined during the audit with their paths]

### Appendix B: Tools and Methods Used
[Describe the scanning approach, patterns searched, and tools used]

### Appendix C: Glossary
[See references/cross-framework-mapping.md for the standard glossary, or reproduce the relevant terms here.]

### Appendix D: Regulatory Reference Links
[See references/frameworks.md for the canonical list of regulatory reference links.]

### Appendix E: Severity Definitions
[See references/classification.md for severity and status definitions, or reproduce them here.]

Scan Categories and Search Patterns

For each category, document what was found, where it was found, and how it relates to each applicable framework. Many findings are about what is missing, not what is present, so actively check for the absence of required controls.

2.1 PII / Sensitive Data Handling

Scan for:

• Database schemas containing personal data fields (name, email, phone, address, SSN, DOB, IP address, device identifiers, biometric data, genetic data, health data, financial data, location data)
• Code that reads, writes, transforms, or transmits personal data
• Hardcoded personal data in source code, configuration files, or test fixtures
• Personal data in log output, error messages, or debug statements
• Data classification labels or lack thereof
• Data inventory or Records of Processing Activities (ROPA) documentation

Search patterns:

- Field names: email, phone, ssn, social_security, date_of_birth, dob, address, credit_card, card_number, cvv, pan, first_name, last_name, ip_address, device_id, location, latitude, longitude, biometric, health, diagnosis, prescription, medical
- Table/collection names: users, customers, patients, members, accounts, profiles, contacts, employees, cardholders, beneficiaries
- Code patterns: PII, PHI, personally_identifiable, protected_health, cardholder_data, sensitive_data
- File patterns: .env, .env.*, config.*, secrets.*, credentials.*, *.pem, *.key, *.cert

2.2 Data Retention

Scan for:

• Retention policies defined in code or documentation
• TTL (time-to-live) configurations on database records or cache entries
• Scheduled deletion jobs, data purge scripts, or archival processes
• Backup retention policies
• Log retention configurations
• Absence of retention policies (which is itself a finding)
• Data lifecycle management documentation

Search patterns:

- Keywords: retention, ttl, expire, expiry, expiration, purge, archive, delete_after, cleanup, data_lifecycle, retention_period, dispose, destroy
- Cron jobs or scheduled tasks related to data cleanup
- Database migration files that add or modify retention-related columns
- Configuration for log rotation and retention

2.3 Encryption

Scan for:

• Encryption at rest: database encryption, file encryption, disk encryption configuration
• Encryption in transit: TLS/SSL configuration, certificate management, HTTPS enforcement
• Key management: key storage, rotation policies, key derivation functions
• Cryptographic algorithm choices (flag weak algorithms: MD5, SHA1 for security purposes, DES, 3DES, RC4, RSA < 2048 bits, ECC < 256 bits)
• Password hashing algorithms (flag weak: MD5, SHA1, plain SHA256 without salt; approve: bcrypt, scrypt, Argon2, PBKDF2 with sufficient iterations)
• Secrets management (hardcoded secrets, environment variable handling, secrets vault integration)
• Certificate pinning in mobile or API client code

Search patterns:

- Keywords: encrypt, decrypt, cipher, aes, rsa, tls, ssl, https, certificate, cert, key_management, kms, vault, secret, hash, bcrypt, scrypt, argon2, pbkdf2, md5, sha1, sha256, hmac, salt, iv, nonce, padding
- Configuration: ssl_mode, sslmode, require_ssl, force_ssl, min_tls_version, cipher_suite
- Files: *.pem, *.key, *.cert, *.crt, *.pfx, *.p12, *.jks, *.keystore

2.4 Access Controls

Scan for:

• Authentication mechanisms (password policies, MFA/2FA, session management, token handling)
• Authorization models (RBAC, ABAC, ACLs, permission systems)
• Principle of least privilege implementation
• Service account management
• API key management and rotation
• Admin/superuser access controls and segregation
• Identity provider integration (SSO, SAML, OIDC, OAuth)
• Access review and recertification processes
• Default credentials or overly permissive configurations

Search patterns:

- Keywords: auth, authenticate, authorize, permission, role, rbac, abac, acl, access_control, privilege, admin, superuser, root, sudo, service_account, api_key, token, session, jwt, oauth, saml, oidc, sso, mfa, 2fa, totp, password_policy, login, logout
- Configuration: cors, allowed_origins, allowed_hosts, csrf, rate_limit, throttle, brute_force
- Middleware/decorators: @auth, @login_required, @requires_permission, @admin_only, requireAuth, isAuthenticated, checkPermission

2.5 Audit Logging

Scan for:

• Logging of authentication events (login, logout, failed attempts, password changes)
• Logging of authorization decisions (access granted, access denied)
• Logging of data access events (read, create, update, delete of regulated data)
• Logging of administrative actions (configuration changes, user management)
• Logging of data export or data transfer events
• Log integrity protection (tamper-evident logging, write-once storage, log signing)
• Log monitoring and alerting configuration
• Log aggregation and SIEM integration
• Absence of audit logging for critical operations

Search patterns:

- Keywords: audit, audit_log, audit_trail, event_log, activity_log, access_log, security_log, log_event, track, record_action, compliance_log, siem, splunk, datadog, cloudwatch, elastic
- Functions: logger, log.info, log.warn, log.error, audit.log, createAuditEntry, recordEvent, trackActivity
- Tables/collections: audit_logs, event_logs, activity_logs, access_logs, security_events

2.6 Consent Management

Scan for:

• Cookie consent implementation (banner, preference center, granular controls)
• Marketing consent collection and storage
• Privacy policy acceptance tracking
• Consent withdrawal mechanisms
• Purpose limitation enforcement (using data only for consented purposes)
• Consent versioning (tracking which version of terms/policy a user consented to)
• Age verification and parental consent (if processing minor's data)
• Legitimate interest assessments
• Double opt-in for email marketing

Search patterns:

- Keywords: consent, opt_in, opt_out, cookie_consent, cookie_banner, privacy_policy, terms_of_service, tos, gdpr_consent, marketing_consent, unsubscribe, preference, cookie_preference, purpose, legitimate_interest, dsar, data_subject, age_verification, parental_consent, double_opt_in
- Components/templates: CookieBanner, ConsentManager, PrivacyModal, OptOutForm, PreferenceCenter, UnsubscribeLink
- Database fields: consented_at, consent_version, marketing_opt_in, cookie_preferences, privacy_accepted

2.7 Data Transfer

Scan for:

• Cross-border data transfer mechanisms (Standard Contractual Clauses, adequacy decisions, Binding Corporate Rules, derogations)
• Third-party data sharing (analytics, advertising, subprocessors)
• API integrations that transmit regulated data
• Data export functionality
• Backup replication to other regions/jurisdictions
• CDN configuration and data caching locations
• Cloud provider region configuration
• Data Processing Agreements (DPAs) with subprocessors
• Transfer Impact Assessments (TIAs)

Search patterns:

- Keywords: transfer, export, share, third_party, subprocessor, vendor, analytics, tracking, pixel, beacon, cdn, region, jurisdiction, cross_border, scc, standard_contractual, adequacy, bcr, dpa, data_processing_agreement
- Services: google_analytics, segment, mixpanel, amplitude, hotjar, intercom, zendesk, stripe, twilio, sendgrid, mailchimp, aws_region, gcp_region, azure_region, cloudflare
- Configuration: region, availability_zone, data_residency, geo_restriction

Scan Execution Rules

1. Be thorough. Search across all file types, not just source code. Include configuration files, infrastructure-as-code templates, documentation, CI/CD pipelines, Docker files, and dependency manifests. 2. Use multiple search strategies. Combine filename patterns, content patterns, and directory structure analysis. A single grep is never sufficient. 3. Check for absence. Actively check for the absence of required controls. 4. Note context. A finding in a test file has different significance than the same pattern in production code. 5. Follow the data. Trace regulated data from ingestion through processing to storage and deletion. Every touchpoint is a potential compliance checkpoint. 6. Check dependencies. Review package manifests (package.json, requirements.txt, Gemfile, go.mod, pom.xml) for libraries related to compliance functions (encryption, auth, logging, consent). 7. Review infrastructure. Check infrastructure-as-code files (Terraform, CloudFormation, Pulumi, Ansible, Kubernetes manifests) that define security controls, network isolation, encryption settings, and access policies. 8. Examine CI/CD. Review pipeline configurations for security scanning, dependency checking, secrets detection, and deployment controls. 9. Do not assume. If you cannot find evidence of a control, report it as a gap. Do not assume controls exist outside the codebase unless documentation or configuration references them. 10. Preserve evidence. Record exact file paths, line numbers, and code snippets for every finding, both positive (evidence of compliance) and negative (evidence of gaps).

Common Compliance Pitfalls to Always Check

1. Logging PII: Applications often log personal data in debug/error output without redaction. 2. Test data leakage: Real PII used in test fixtures, seed data, or staging environments. 3. Overly broad data collection: Collecting more data than necessary for the stated purpose. 4. Missing deletion cascades: User deletion not propagating to all data stores, backups, logs, and third-party systems. 5. Stale access: No process for revoking access when employees leave or change roles. 6. Unencrypted backups: Database backups stored without encryption. 7. Missing HTTPS redirects: HTTP endpoints not redirecting to HTTPS. 8. Weak session management: Long-lived tokens, missing session invalidation on password change. 9. Missing CORS configuration: Overly permissive cross-origin policies. 10. Hardcoded secrets: API keys, passwords, or tokens in source code. 11. Missing rate limiting: No protection against brute force or enumeration attacks. 12. Insecure defaults: Debug mode enabled, verbose error messages in production, default credentials. 13. Missing cookie flags: Secure, HttpOnly, SameSite flags not set on session cookies. 14. No CSP headers: Missing Content-Security-Policy headers. 15. Unvalidated redirects: Open redirect vulnerabilities that could be used in phishing. 16. Missing data classification: No system for classifying data sensitivity levels. 17. Shadow data stores: Data copied to caches, search indexes, or analytics systems without the same protections. 18. Incomplete consent flows: Consent collected but not enforced in data processing logic. 19. Missing GPC/DNT support: Not honoring Global Privacy Control or Do Not Track signals (CCPA requirement). 20. Insecure direct object references: Accessing other users' data by changing IDs in URLs/requests.