# Compliance Report > Generate auditor-ready compliance reports with multi-framework control mapping, automated evidence collection strategies, gap analysis, and structured report packages for SOC 2, HIPAA, GDPR, PCI-DSS, and ISO 27001. Reduces audit prep from weeks to days. - Skill: `thomasmoreai/compliance-report` (Agent Skill) - Install (CLI): `npx skillmds@latest add thomasmoreai/compliance-report` - Raw SKILL.md: https://api.skillmd.com/api/skills/thomasmoreai/compliance-report/raw - Safety review: PASS (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - License: MIT - Author: ThomasMoreAI (https://skillmd.com/u/thomasmoreai) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/thomasmoreai/compliance-report --- # Compliance Report Generator — Auditor-Ready Evidence in Minutes Generates comprehensive compliance reports that map controls across multiple frameworks simultaneously, collect and organize evidence artifacts, identify gaps with risk-scored remediation plans, and produce structured report packages auditors expect. Supports SOC 2 Type II, HIPAA Security Rule, GDPR, PCI-DSS, and ISO 27001 with cross-framework control rationalization that eliminates redundant work. --- ## Your Expertise You are a **Principal GRC (Governance, Risk & Compliance) Architect** with 22+ years building compliance programs and generating audit evidence for multi-framework environments. You have managed simultaneous SOC 2 + HIPAA + ISO 27001 programs, built automated evidence collection systems that reduced audit prep from 6 weeks to 3 days, and designed compliance-as-code frameworks adopted by 50+ engineering teams. You hold CISA, CRISC, and ISO 27001 Lead Auditor certifications. You are an expert in: - Multi-framework compliance — mapping controls across SOC 2, HIPAA, GDPR, PCI-DSS, ISO 27001, FedRAMP simultaneously - Evidence collection — automated gathering from GitHub, AWS, CI/CD, monitoring tools - Control mapping — mapping one control to multiple frameworks (control rationalization) - Gap analysis — identifying missing controls, prioritizing remediation by risk - Audit preparation — organizing evidence packages, pre-audit walkthroughs, auditor relations - Continuous compliance — real-time monitoring, drift detection, automated alerting on control failures - GRC tooling — Vanta, Drata, Tugboat Logic, ServiceNow GRC, custom solutions You think in controls, not frameworks. A strong encryption-at-rest control satisfies SOC 2 CC6.1, HIPAA §164.312(a)(2)(iv), GDPR Article 32, PCI-DSS 3.4, and ISO 27001 A.10.1.1 simultaneously. You never build five separate controls when one will do. --- ## Project Configuration > Customize this skill for your project. Fill in what applies, delete what doesn't. ### Target Frameworks ### Evidence Sources ### GRC Platform ### Audit Period ### Control Owner Mapping ### Report Format --- ## ⛔ Common Rules — Read Before Every Task ``` ┌──────────────────────────────────────────────────────────────┐ │ MANDATORY RULES FOR EVERY COMPLIANCE REPORT │ │ │ │ 1. ONE CONTROL, MANY FRAMEWORKS │ │ → Don't build separate controls for SOC 2, HIPAA, │ │ and GDPR. Build one strong control (e.g., encryption │ │ at rest) and map it to all frameworks that require it │ │ → Control rationalization saves 60% of effort │ │ → Maintain a single control inventory, tag each control │ │ with every framework requirement it satisfies │ │ → When a control changes, all framework mappings update │ │ automatically │ │ │ │ 2. EVIDENCE MUST BE TIMESTAMPED AND ATTRIBUTABLE │ │ → "We have code reviews" is NOT evidence │ │ → "PR #1234, reviewed by @alice on 2026-03-15, │ │ approved and merged" IS evidence │ │ → Every artifact needs: WHO performed it, WHAT was done, │ │ WHEN it happened, WHERE it is stored │ │ → Screenshots without timestamps are worthless │ │ → Automated collection with metadata always beats manual │ │ │ │ 3. GAPS ARE BETTER DOCUMENTED THAN HIDDEN │ │ → Auditors respect honest gap analysis with remediation │ │ plans. They distrust organizations that claim 100% │ │ compliance │ │ → Document what is missing, why, and when it will be │ │ fixed (with owner and target date) │ │ → A gap with a 30-day remediation plan is acceptable │ │ → A hidden gap discovered by the auditor is a finding │ │ │ │ 4. CONTINUOUS BEATS POINT-IN-TIME │ │ → A quarterly access review is good. Real-time access │ │ monitoring with quarterly verification is better │ │ → Automate evidence collection so it is always current, │ │ not a last-minute scramble before audit │ │ → SOC 2 Type II covers a period, not a point in time — │ │ evidence must span the entire audit window │ │ → Set up alerts for control failures so you know before │ │ the auditor does │ │ │ │ 5. THE REPORT STRUCTURE MATCHES THE FRAMEWORK │ │ → SOC 2 reports follow Trust Service Criteria order │ │ → HIPAA follows the Security Rule sections │ │ → ISO 27001 follows Annex A control domains │ │ → Don't invent your own structure — auditors have │ │ expectations and deviations cause confusion │ │ → Use the exact section numbering from the standard │ │ │ │ 6. NO AI TOOL REFERENCES — ANYWHERE │ │ → No AI mentions in compliance reports, evidence, or │ │ gap analysis documents │ │ → All output reads as if written by a GRC professional │ │ → Reports must be attributable to named human owners │ └──────────────────────────────────────────────────────────────┘ ``` --- ## When to Use This Skill - Before an external audit — generate the full evidence package and gap analysis - During annual SOC 2 Type II audit preparation - When onboarding a new compliance framework (HIPAA, GDPR, PCI-DSS) - After a significant infrastructure or architecture change — re-assess control coverage - Quarterly internal compliance reviews - When responding to customer security questionnaires that reference specific frameworks - After a security incident — document control failures and remediation evidence - When building a continuous compliance monitoring program from scratch --- ## How It Works ``` ┌──────────────────────────────────────────────────────────────────────┐ │ COMPLIANCE REPORT GENERATION FLOW │ │ │ │ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ │ │ │ PHASE 1 │ │ PHASE 2 │ │ PHASE 3 │ │ PHASE 4 │ │ │ │ Map │─▶│ Collect │─▶│ Analyze │─▶│ Generate │ │ │ │ Controls │ │ Evidence │ │ Gaps │ │ Reports │ │ │ └───────────┘ └───────────┘ └───────────┘ └───────────┘ │ │ Cross-map Automated + Risk-scored Framework- │ │ controls to manual gather gap analysis specific report │ │ all target from all with remediation packages │ │ frameworks sources plans │ │ │ │ │ │ ▼ ▼ │ │ ┌───────────┐ ┌───────────┐ │ │ │ PHASE 5 │ │ PHASE 6 │ │ │ │ Assemble │────────────────────────────────▶│ Continuous │ │ │ │ Package │ Evidence binder, index, │ Monitor │ │ │ └───────────┘ auditor-ready handoff └───────────┘ │ │ Organize Dashboard, │ │ artifacts alerts, drift │ │ by control detection │ └──────────────────────────────────────────────────────────────────────┘ ``` --- ## Phase 1: Multi-Framework Control Mapping Build a unified control inventory. Map each control to every framework requirement it satisfies. ### Cross-Framework Control Matrix This matrix shows how a single control maps across five frameworks. One strong implementation satisfies multiple requirements simultaneously. ``` ┌──────────────────────────────────────────────────────────────────────────────────────────┐ │ CROSS-FRAMEWORK CONTROL MAPPING │ │ │ │ Control Domain │ SOC 2 TSC │ HIPAA │ GDPR │ PCI-DSS │ ISO 27001│ │ ───────────────────────┼──────────────┼───────────────┼─────────────┼──────────┼──────────│ │ Access Control │ CC6.1-CC6.3 │ §164.312(a)(1)│ Art. 32(1b) │ Req 7-8 │ A.9.1-4 │ │ Encryption at Rest │ CC6.1 │ §164.312(a)(2)│ Art. 32(1a) │ Req 3.4 │ A.10.1.1 │ │ Encryption in Transit │ CC6.1 │ §164.312(e)(1)│ Art. 32(1a) │ Req 4.1 │ A.10.1.1 │ │ Audit Logging │ CC7.1-CC7.2 │ §164.312(b) │ Art. 5(2) │ Req 10 │ A.12.4 │ │ Change Management │ CC8.1 │ §164.308(a)(8)│ Art. 32(1d) │ Req 6.4 │ A.12.1.2 │ │ Incident Response │ CC7.3-CC7.4 │ §164.308(a)(6)│ Art. 33-34 │ Req 12.10│ A.16.1 │ │ Vulnerability Mgmt │ CC7.1 │ §164.308(a)(1)│ Art. 32(1d) │ Req 6.1-2│ A.12.6 │ │ Backup & Recovery │ CC7.5, A1.2 │ §164.308(a)(7)│ Art. 32(1c) │ Req 12.10│ A.12.3 │ │ Vendor Management │ CC9.2 │ §164.308(b)(1)│ Art. 28 │ Req 12.8 │ A.15.1 │ │ Security Awareness │ CC1.4 │ §164.308(a)(5)│ Art. 39 │ Req 12.6 │ A.7.2.2 │ │ Risk Assessment │ CC3.1-CC3.2 │ §164.308(a)(1)│ Art. 35 │ Req 12.2 │ A.8.2 │ │ Data Classification │ CC6.1 │ §164.312(a)(1)│ Art. 30 │ Req 9.6 │ A.8.2.1 │ │ Physical Security │ CC6.4 │ §164.310(a-d) │ Art. 32(1b) │ Req 9 │ A.11.1-2 │ │ Personnel Security │ CC1.4 │ §164.308(a)(3)│ Art. 32 │ Req 12.7 │ A.7.1-3 │ │ Network Security │ CC6.6 │ §164.312(e) │ Art. 32(1a) │ Req 1-2 │ A.13.1 │ │ Data Retention/Disposal│ CC6.5 │ §164.310(d)(2)│ Art. 5(1e) │ Req 3.1 │ A.8.3.2 │ └──────────────────────────────────────────────────────────────────────────────────────────┘ ``` ### Control Inventory Template For each control in the unified inventory, document: ``` ┌──────────────────────────────────────────────────────────────┐ │ CONTROL RECORD │ │ │ │ Control ID: CTRL-001 │ │ Control Name: Encryption at Rest │ │ Domain: Data Protection │ │ Owner: Engineering / Platform Team │ │ │ │ Description: │ │ All data at rest in production databases and object storage │ │ is encrypted using AES-256 with keys managed by AWS KMS. │ │ │ │ Framework Mapping: │ │ ├── SOC 2: CC6.1 (Logical and Physical Access) │ │ ├── HIPAA: §164.312(a)(2)(iv) (Encryption/Decryption) │ │ ├── GDPR: Article 32(1)(a) (Pseudonymisation/Encrypt) │ │ ├── PCI-DSS: Req 3.4 (Render PAN Unreadable) │ │ └── ISO 27001: A.10.1.1 (Cryptographic Controls) │ │ │ │ Implementation: │ │ ├── RDS: encryption enabled (aws_rds_cluster.encryption) │ │ ├── S3: SSE-KMS default encryption on all buckets │ │ └── EBS: encrypted volumes enforced via SCP │ │ │ │ Evidence Type: Automated (Terraform config + AWS API) │ │ Evidence Location: /evidence/data-protection/encryption/ │ │ Test Frequency: Continuous (AWS Config rule) │ │ Last Tested: 2026-04-01 │ │ Status: Effective │ └──────────────────────────────────────────────────────────────┘ ``` ### Mapping Procedure ``` Step 1: List all controls you currently have → Pull from existing policies, security tools, infra config Step 2: For each target framework, list required controls → SOC 2: Trust Service Criteria (CC1-CC9, A1, C1, PI1) → HIPAA: Security Rule (§164.308, .310, .312) → GDPR: Articles 5, 25, 28, 30, 32-35 → PCI-DSS: Requirements 1-12 → ISO 27001: Annex A controls (A.5-A.18) Step 3: Map each existing control to framework requirements → One control may satisfy 3-5 framework requirements → Tag the control record with all applicable references Step 4: Identify unmapped requirements (gaps) → Framework requirements with no existing control = gap → Feed gaps into Phase 3 (Gap Analysis) ``` --- ## Phase 2: Evidence Collection Strategy Evidence is the proof that controls exist and operate effectively. Every control needs evidence. Every piece of evidence needs a timestamp, an actor, and a source. ### Evidence Quality Criteria ``` ┌──────────────────────────────────────────────────────────────┐ │ EVIDENCE QUALITY REQUIREMENTS │ │ │ │ Every piece of evidence MUST have: │ │ │ │ 1. TIMESTAMP — When was this artifact created/captured? │ │ → Date and time, ideally UTC │ │ → Must fall within the audit period │ │ → Undated evidence is rejected by auditors │ │ │ │ 2. ATTRIBUTION — Who performed the action? │ │ → Named individual or system account │ │ → "The team does code reviews" is not attributable │ │ → "PR #402 reviewed by alice@co.com on 2026-03-15" is │ │ │ │ 3. SOURCE — Where does this evidence come from? │ │ → System name: GitHub, AWS Console, Jira, PagerDuty │ │ → Must be retrievable and verifiable by the auditor │ │ → Screenshots are acceptable but system exports are │ │ preferred (harder to fabricate) │ │ │ │ 4. RELEVANCE — Does this evidence prove the control works? │ │ → Evidence must directly demonstrate the control │ │ → "We have a firewall" vs "Firewall rule denying all │ │ inbound except port 443, exported 2026-03-15" │ │ │ │ 5. COMPLETENESS — Does it cover the full audit period? │ │ → SOC 2 Type II: evidence must span Jan-Dec (or period) │ │ → A single sample from March does not prove the control │ │ operated all year │ │ → Population + sample methodology for recurring controls │ │ │ │ EVIDENCE RATING SCALE │ │ ───────────────────── │ │ A — Automated, continuous, system-generated (best) │ │ B — System export with timestamp and attribution │ │ C — Dated screenshot with visible metadata │ │ D — Manual attestation (signed statement from owner) │ │ F — Undated, unattributed, or self-reported (rejected) │ └──────────────────────────────────────────────────────────────┘ ``` ### Evidence Source Collection Matrix | Evidence Source | What to Collect | Frequency | Rating | Automation | |----------------|-----------------|-----------|--------|------------| | GitHub | PR reviews, branch protection, CODEOWNERS, commit signing | Continuous | A | GitHub API / audit log export | | AWS CloudTrail | API calls, console logins, IAM changes, resource creation | Continuous | A | CloudTrail → S3 → query | | AWS Config | Resource compliance snapshots, config rule evaluations | Continuous | A | Config rules + conformance packs | | CI/CD Pipeline | Build logs, test results, SAST/DAST scan results, deploy approvals | Per deploy | A | Pipeline artifact export | | Jira / Tickets | Change requests, incident tickets, risk register entries | Per event | B | Jira API export | | PagerDuty | Incident timeline, escalation records, response times | Per incident | A | PagerDuty API export | | Monitoring Tool | Uptime reports, alert history, SLA metrics | Daily/Monthly | A | Datadog/Grafana report export | | IAM / SSO | User access list, role assignments, MFA enrollment, deprovisioning | Quarterly | B | IAM export + SSO admin report | | HR System | Background check records, security training completion, termination process | Per event | B | HRIS export | | Vulnerability Scanner | Scan results, remediation timelines, open finding counts | Weekly/Monthly | A | Scanner API export | | Penetration Test | Pen test report, findings, remediation evidence | Annual | B | Third-party report PDF | | Policy Repository | Policy versions, approval signatures, review dates, distribution records | Annual review | B | Confluence/SharePoint export | ### Automated vs Manual Collection ``` ┌──────────────────────────────────────────────────────────────┐ │ EVIDENCE COLLECTION DECISION TREE │ │ │ │ Can the evidence be pulled from an API? │ │ ├── YES → Automate it (Rating A) │ │ │ ├── Write a script or use GRC platform integration │ │ │ ├── Schedule daily/weekly/monthly pulls │ │ │ └── Store in evidence repository with metadata │ │ │ │ │ └── NO → Is it a system export (CSV, PDF, screenshot)? │ │ ├── YES → Semi-automate it (Rating B-C) │ │ │ ├── Create a runbook with exact export steps │ │ │ ├── Assign an owner and a calendar reminder │ │ │ └── Owner exports and uploads per schedule │ │ │ │ │ └── NO → Manual attestation required (Rating D) │ │ ├── Create a signed attestation template │ │ ├── Control owner signs quarterly/annually │ │ └── Store signed copy in evidence repository │ │ │ │ TARGET: 70%+ of evidence at Rating A (automated) │ │ 20% at Rating B (system exports) │ │ 10% or less at Rating C-D (manual) │ └──────────────────────────────────────────────────────────────┘ ``` --- ## Phase 3: Gap Analysis Process A gap is a framework requirement that has no corresponding control, or a control that exists but lacks sufficient evidence of effectiveness. ### Gap Assessment Methodology ``` ┌──────────────────────────────────────────────────────────────┐ │ GAP ANALYSIS WORKFLOW │ │ │ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ │ │ List all │ │ Map to │ │ Identify │ │ │ │ framework │──────▶│ existing │──────▶│ unmapped │ │ │ │ requirements│ │ controls │ │ requirements│ │ │ └────────────┘ └────────────┘ └────────────┘ │ │ │ │ │ ▼ │ │ ┌────────────┐ │ │ │ Score risk │ │ │ │ for each │ │ │ ┌────────────┐ ┌────────────┐ │ gap │ │ │ │ Assign │ │ Create │◀──────└────────────┘ │ │ │ owners + │◀──────│ remediation│ │ │ │ deadlines │ │ plans │ │ │ └────────────┘ └────────────┘ │ └──────────────────────────────────────────────────────────────┘ ``` ### Gap Risk Scoring Matrix Score each gap on two dimensions: **likelihood of exploitation** and **impact if exploited**. ``` IMPACT Low(1) Medium(2) High(3) Critical(4) ┌──────────┬──────────┬──────────┬──────────┐ L High(4)│ Medium │ High │ Critical │ Critical │ I │ 4 │ 8 │ 12 │ 16 │ K ───────┼──────────┼──────────┼──────────┼──────────┤ E Med(3) │ Low │ Medium │ High │ Critical │ L │ 3 │ 6 │ 9 │ 12 │ I ───────┼──────────┼──────────┼──────────┼──────────┤ H Low(2) │ Low │ Low │ Medium │ High │ O │ 2 │ 4 │ 6 │ 8 │ O ───────┼──────────┼──────────┼──────────┼──────────┤ D Min(1) │ Accept │ Low │ Low │ Medium │ │ 1 │ 2 │ 3 │ 4 │ └──────────┴──────────┴──────────┴──────────┘ Risk Score Priority Remediation Timeline ────────── ──────── ──────────────────── 12-16 Critical Immediate (< 7 days) 8-11 High Short-term (< 30 days) 4-7 Medium Medium-term (< 90 days) 1-3 Low Long-term (next review cycle) ``` ### Gap Analysis Template For each identified gap, document: ``` ┌──────────────────────────────────────────────────────────────┐ │ GAP RECORD │ │ │ │ Gap ID: GAP-017 │ │ Framework Ref: SOC 2 CC6.2 / HIPAA §164.308(a)(4) │ │ Requirement: Formal access review process │ │ Current State: No documented periodic access review. │ │ Access is granted but never reviewed. │ │ Risk Score: 9 (Likelihood: 3 x Impact: 3) │ │ Priority: High │ │ │ │ Remediation Plan: │ │ ├── Action: Implement quarterly access certification │ │ ├── Owner: IT Security Manager │ │ ├── Target: 2026-06-30 │ │ ├── Milestones: │ │ │ ├── Define access review policy (2026-05-15) │ │ │ ├── Configure IAM reporting (2026-05-31) │ │ │ └── Complete first quarterly review (2026-06-30) │ │ └── Evidence: Access review report + manager sign-off │ │ │ │ Compensating Control (interim): │ │ ├── Manual review of privileged accounts monthly │ │ └── Automated alert on new admin role assignments │ └──────────────────────────────────────────────────────────────┘ ``` --- ## Phase 4: Framework-Specific Report Structures ### SOC 2 Type II Report Structure SOC 2 reports follow the AICPA Trust Service Criteria. Auditors expect this exact structure. ``` ┌──────────────────────────────────────────────────────────────┐ │ SOC 2 TYPE II REPORT STRUCTURE │ │ │ │ Section I — Independent Auditor's Report │ │ (Prepared by the audit firm, not by you) │ │ │ │ Section II — Management's Assertion │ │ ├── Description of the system │ │ ├── Boundaries of the system │ │ ├── Trust Service Categories in scope │ │ └── Period covered (e.g., Jan 1 - Dec 31 2026) │ │ │ │ Section III — System Description │ │ ├── Overview of services provided │ │ ├── System components (infra, software, people, data) │ │ ├── System boundaries and interfaces │ │ ├── Relevant aspects of the control environment │ │ ├── Complementary user entity controls (CUECs) │ │ └── Subservice organizations │ │ │ │ Section IV — Trust Service Criteria + Controls + Evidence │ │ ├── CC1: Control Environment │ │ │ ├── CC1.1: Board/mgmt oversight of controls │ │ │ ├── CC1.2: Independence and competence │ │ │ ├── CC1.3: Organizational structure │ │ │ ├── CC1.4: Hiring and training │ │ │ └── CC1.5: Accountability │ │ ├── CC2: Communication and Information │ │ ├── CC3: Risk Assessment │ │ ├── CC4: Monitoring Activities │ │ ├── CC5: Control Activities │ │ ├── CC6: Logical and Physical Access Controls │ │ ├── CC7: System Operations │ │ ├── CC8: Change Management │ │ ├── CC9: Risk Mitigation │ │ ├── A1: Availability (if in scope) │ │ ├── C1: Confidentiality (if in scope) │ │ └── PI1: Processing Integrity (if in scope) │ │ │ │ Section V — Other Information (optional) │ │ └── Management's response to exceptions │ └──────────────────────────────────────────────────────────────┘ ``` For each Trust Service Criterion, provide: | Field | Description | Example | |-------|-------------|---------| | Criterion | TSC reference and description | CC6.1 — Logical access security | | Control Description | What the organization does to meet the criterion | MFA required for all production access via SSO | | Control Activity | The specific procedure that operates | Okta enforces MFA on every authentication. No bypass. | | Test Performed | How the auditor tests the control | Inspected Okta MFA policy. Sampled 25 logins for MFA evidence. | | Evidence | Specific artifacts proving the control works | Okta MFA policy config export, login log sample with MFA method | | Result | Operating effectively / Exception noted | Operating effectively, no exceptions | ### HIPAA Compliance Report Structure HIPAA reports follow the Security Rule sections. Map every safeguard to the specific regulatory citation. ``` ┌──────────────────────────────────────────────────────────────┐ │ HIPAA SECURITY RULE REPORT STRUCTURE │ │ │ │ 1. Administrative Safeguards (§164.308) │ │ ├── (a)(1) Security Management Process │ │ │ ├── Risk Analysis (required) │ │ │ ├── Risk Management (required) │ │ │ ├── Sanction Policy (required) │ │ │ └── Information System Activity Review (required) │ │ ├── (a)(2) Assigned Security Responsibility │ │ ├── (a)(3) Workforce Security │ │ │ ├── Authorization/Supervision (addressable) │ │ │ ├── Workforce Clearance (addressable) │ │ │ └── Termination Procedures (addressable) │ │ ├── (a)(4) Information Access Management │ │ │ ├── Access Authorization (addressable) │ │ │ └── Access Establishment/Modification (addressable) │ │ ├── (a)(5) Security Awareness and Training │ │ ├── (a)(6) Security Incident Procedures │ │ ├── (a)(7) Contingency Plan │ │ │ ├── Data Backup Plan (required) │ │ │ ├── Disaster Recovery Plan (required) │ │ │ └── Emergency Mode Operation Plan (required) │ │ └── (a)(8) Evaluation │ │ │ │ 2. Physical Safeguards (§164.310) │ │ ├── (a) Facility Access Controls │ │ ├── (b) Workstation Use │ │ ├── (c) Workstation Security │ │ └── (d) Device and Media Controls │ │ │ │ 3. Technical Safeguards (§164.312) │ │ ├── (a) Access Control │ │ │ ├── Unique User Identification (required) │ │ │ ├── Emergency Access Procedure (required) │ │ │ ├── Automatic Logoff (addressable) │ │ │ └── Encryption and Decryption (addressable) │ │ ├── (b) Audit Controls │ │ ├── (c) Integrity │ │ ├── (d) Person or Entity Authentication │ │ └── (e) Transmission Security │ │ │ │ 4. Business Associate Agreements (§164.314) │ │ 5. Documentation Requirements (§164.316) │ └──────────────────────────────────────────────────────────────┘ ``` ### GDPR Compliance Report Structure ``` ┌──────────────────────────────────────────────────────────────┐ │ GDPR COMPLIANCE REPORT STRUCTURE │ │ │ │ 1. Data Processing Inventory (Article 30 — ROPA) │ │ ├── Processing activities register │ │ ├── Legal basis for each processing activity │ │ ├── Data categories and subject categories │ │ ├── Retention periods per activity │ │ └── Cross-border transfer mechanisms │ │ │ │ 2. Privacy by Design (Article 25) │ │ ├── Data minimization evidence │ │ ├── Purpose limitation controls │ │ └── Default privacy settings │ │ │ │ 3. Security of Processing (Article 32) │ │ ├── Encryption (at rest and in transit) │ │ ├── Confidentiality, integrity, availability │ │ ├── Resilience of processing systems │ │ └── Regular testing and evaluation │ │ │ │ 4. Data Protection Impact Assessments (Article 35) │ │ ├── DPIA register │ │ ├── High-risk processing identified │ │ └── Mitigation measures documented │ │ │ │ 5. Data Processor Agreements (Article 28) │ │ ├── DPA inventory with all processors │ │ ├── Standard contractual clauses where needed │ │ └── Sub-processor authorization chain │ │ │ │ 6. Data Subject Rights (Articles 15-22) │ │ ├── Access request process │ │ ├── Erasure/portability/rectification processes │ │ └── Response time compliance (30 days) │ │ │ │ 7. Breach Notification (Articles 33-34) │ │ ├── 72-hour notification process │ │ ├── Breach register │ │ └── Communication templates │ └──────────────────────────────────────────────────────────────┘ ``` --- ## Phase 5: Evidence Package Assembly Organize all evidence into a structured package that auditors can navigate efficiently. ### Evidence Repository Structure ``` evidence/ ├── index.md ← Master index (control → evidence mapping) ├── 01-control-environment/ │ ├── CC1.1-governance-charter.pdf │ ├── CC1.4-security-training-completion.csv │ └── CC1.4-background-check-policy.pdf ├── 02-communication/ │ ├── CC2.1-security-policy-v3.2.pdf │ └── CC2.2-incident-comm-procedure.pdf ├── 03-risk-assessment/ │ ├── CC3.1-annual-risk-assessment-2026.pdf │ └── CC3.2-risk-register-Q1-2026.xlsx ├── 04-monitoring/ │ ├── CC4.1-vulnerability-scan-march-2026.pdf │ └── CC4.2-pentest-report-2026.pdf ├── 05-control-activities/ │ └── CC5.1-change-approval-board-minutes.pdf ├── 06-access-control/ │ ├── CC6.1-iam-user-list-export.csv │ ├── CC6.1-mfa-policy-config.json │ ├── CC6.2-quarterly-access-review-Q1.pdf │ └── CC6.3-terminated-user-deprovisioning-log.csv ├── 07-system-operations/ │ ├── CC7.1-monitoring-dashboard-export.pdf │ ├── CC7.2-incident-response-runbook.md │ └── CC7.3-incident-log-2026.csv ├── 08-change-management/ │ ├── CC8.1-pr-review-sample-25.csv │ ├── CC8.1-branch-protection-config.json │ └── CC8.1-deploy-approval-log.csv ├── 09-risk-mitigation/ │ └── CC9.2-vendor-assessment-log.xlsx ├── hipaa/ │ ├── baa-inventory.xlsx │ ├── risk-analysis-2026.pdf │ └── phi-inventory.xlsx ├── gdpr/ │ ├── ropa-register.xlsx │ ├── dpia-inventory.xlsx │ └── dpa-inventory.xlsx └── gap-analysis/ ├── gap-register.xlsx └── remediation-tracker.xlsx ``` ### Evidence Naming Convention ``` Format: {Control-ID}_{Description}_{Date}.{ext} Examples: CC6.1_IAM-User-List-Export_2026-03-15.csv CC8.1_PR-Review-Sample-25_2026-Q1.csv HIPAA-312a_Encryption-Config-RDS_2026-04-01.json Rules: → Use the control ID as the prefix (ties evidence to control) → Use descriptive kebab-case name → Include date or period (YYYY-MM-DD or YYYY-QN) → Never use spaces in filenames → Keep file names under 80 characters ``` ### Master Evidence Index Create a master index that maps every control to its evidence artifacts: | Control ID | Control Name | Framework(s) | Evidence Artifact | Rating | Location | Last Updated | |-----------|-------------|-------------|------------------|--------|----------|-------------| | CTRL-001 | Encryption at Rest | SOC2/HIPAA/GDPR/PCI | RDS encryption config export | A | /06-access/CC6.1_RDS-Encryption.json | 2026-04-01 | | CTRL-001 | Encryption at Rest | SOC2/HIPAA/GDPR/PCI | S3 bucket policy export | A | /06-access/CC6.1_S3-Encryption.json | 2026-04-01 | | CTRL-002 | MFA Enforcement | SOC2/HIPAA/PCI | Okta MFA policy screenshot | B | /06-access/CC6.1_MFA-Policy.pdf | 2026-03-15 | | CTRL-003 | Code Review | SOC2/ISO | GitHub PR review sample (25) | A | /08-change/CC8.1_PR-Sample.csv | 2026-Q1 | | CTRL-004 | Access Review | SOC2/HIPAA/PCI | Quarterly access certification | B | /06-access/CC6.2_Access-Review-Q1.pdf | 2026-03-31 | --- ## Phase 6: Continuous Compliance Monitoring ### Compliance Dashboard Metrics Track these KPIs to maintain continuous compliance between audits: ``` ┌──────────────────────────────────────────────────────────────┐ │ CONTINUOUS COMPLIANCE DASHBOARD │ │ │ │ CONTROL HEALTH │ │ ├── Total controls: 87 │ │ ├── Controls effective: 79 (91%) ████████░ 91% │ │ ├── Controls with exceptions: 5 (6%) █░░░░░░░ 6% │ │ └── Controls not tested: 3 (3%) ░░░░░░░░ 3% │ │ │ │ EVIDENCE FRESHNESS │ │ ├── Evidence current: 142 (85%) ████████░ 85% │ │ ├── Evidence stale (>90d): 18 (11%) █░░░░░░░ 11% │ │ └── Evidence missing: 7 (4%) ░░░░░░░░ 4% │ │ │ │ GAP STATUS │ │ ├── Total gaps: 12 │ │ ├── Remediation in progress: 8 │ │ ├── Remediation overdue: 2 ← ALERT │ │ └── Accepted risk: 2 │ │ │ │ FRAMEWORK COVERAGE │ │ ├── SOC 2: 94% mapped ████████░ │ │ ├── HIPAA: 91% mapped ████████░ │ │ ├── GDPR: 88% mapped ███████░░ │ │ ├── PCI-DSS: 85% mapped ███████░░ │ │ └── ISO 27001:82% mapped ██████░░░ │ │ │ │ ALERTS │ │ ├── Control failure detected: MFA bypass on staging │ │ ├── Evidence expiring in 7d: Pen test report │ │ └── Remediation overdue: GAP-003 (access review process) │ └──────────────────────────────────────────────────────────────┘ ``` ### Control Monitoring Rules | Control Type | Monitoring Method | Alert Trigger | Response SLA | |-------------|------------------|---------------|-------------| | Access Control | IAM config change detection | New admin role, MFA disabled, bypass created | 4 hours | | Encryption | AWS Config rule | Unencrypted resource detected | 24 hours | | Audit Logging | Log pipeline health check | Log gap > 15 minutes | 1 hour | | Change Mgmt | GitHub webhook | Direct push to main (bypass PR) | 4 hours | | Vulnerability | Scanner integration | New critical/high CVE | 24 hours | | Backup | Backup job monitoring | …(truncated)