Compliance Checker

Compliance Checker

When to activate

Use this skill when you need to:

• Map existing security controls to regulatory frameworks (GDPR, SOC 2 Type II, PCI-DSS, HIPAA)
• Audit your current security posture against compliance requirements
• Identify compliance gaps in your infrastructure or processes
• Generate a remediation roadmap with implementation priorities
• Prepare evidence for a compliance assessment or audit
• Evaluate whether a new tool, process, or change maintains compliance

Trigger scenarios:

• Expanding into a regulated market (healthcare, finance, EU)
• Preparing for an external audit or certification
• After a security incident, to verify compliance didn't break
• Before deploying a new feature that touches sensitive data

When NOT to use

• Legal interpretation required: If you need to understand ambiguous regulatory language or interpret case law, consult legal counsel — this skill maps known controls to known requirements, not edge cases
• One-off compliance question: If you just need "does GDPR require encryption?", ask directly instead of invoking the full skill
• Post-breach investigation: This skill maps controls to requirements; forensics and root-cause analysis are separate concerns
• Real-time threat response: During an active incident, focus on containment — compliance mapping comes after stabilization
• Vendor procurement decisions: Use this skill to define vendor compliance requirements, not to evaluate salespeople

Instructions

Step 1: Define Scope and Applicability

Before mapping controls, clarify:

1. Regulatory jurisdiction: Which frameworks apply?

   • GDPR: EU/UK data processing
   • HIPAA: US healthcare data (stricter than general data protection)
   • PCI-DSS: Payment card data handling (any industry)
   • SOC 2 Type II: Service organizations (auditor-driven)
   • Others: Industry-specific (FedRAMP, FISMA, CCPA, etc.)

2. Data types and locations: What data does your system touch?

   • Personal data (GDPR, CCPA)
   • Health data (HIPAA)
   • Payment card data (PCI-DSS)
   • Regulated industry data (finance, government, etc.)

3. Scope boundaries: Which systems, teams, and processes are in scope?

   • Cloud infrastructure vs. on-premises
   • Third-party vendors and processors
   • Development, staging, and production

Step 2: Inventory Existing Security Controls

Document what you already have:

Use /security-audit or manual review to populate this table.

Step 3: Map Controls to Requirements

For each framework, cross-reference your controls against published requirements.

GDPR (Article-based):

• Article 5: Data subject rights and processor transparency
• Article 32: Technical and organizational measures (encryption, access, testing, monitoring)
• Article 33-35: Breach notification and DPIA

HIPAA (Rule-based):

• Administrative Safeguards: Workforce security, information access management
• Physical Safeguards: Facility access, workstation use and security
• Technical Safeguards: Access controls, encryption, audit controls, integrity controls

PCI-DSS (Requirement-based):

• 1-6: Infrastructure security
• 7-8: Access control and user identification
• 9-12: Monitoring, testing, and policies

SOC 2 Type II (Trust Service Criteria):

• CC (Common Criteria): Security, availability, processing integrity, confidentiality, privacy
• Each criterion has multiple sub-controls; attestation requires time-series evidence

Step 4: Identify Gaps

For each requirement, assess coverage:

Severity tiers:

• Critical: Failure exposes regulated data or violates legal requirement
• High: Creates material risk or audit finding; likely to fail certification
• Medium: Best practice gap or incomplete implementation; audit question likely
• Low: Recommended for mature programs; typically doesn't block certification

Step 5: Generate Remediation Roadmap

Prioritize by:

1. Severity: Critical first, then High, Medium, Low
2. Implementation cost: Quick wins first; defer expensive rewrites
3. Dependencies: Some controls require others to be in place first
4. Timeline: Audit dates, certification deadlines, regulatory deadlines

Roadmap template:

Step 6: Build Evidence Inventory for Audit

Create a control-evidence mapping:

Auditors ask for:

• Policies: Formal written requirements
• Evidence: Logs, screenshots, reports proving compliance
• Timelines: Dates showing sustained compliance (not one-off checks)

Example

Scenario: A US health tech startup preparing for SOC 2 Type II and HIPAA certification

Step 1: Scope

• Frameworks: HIPAA (health data) + SOC 2 Type II (service organization)
• Data: Patient records, genomic data, audit logs
• Scope: AWS cloud, three regions, third-party data processor

Step 2: Inventory

• Encryption: RDS encryption at rest (AES-256), but no TLS in transit
• Access: IAM roles + Okta SSO, but no MFA enforcement
• Logging: CloudTrail + RDS logs, but no application audit trail
• Backup: Daily snapshots, no tested restore procedure

Step 3: Map to Requirements

HIPAA Technical Safeguards § 164.312(a)(2):

• (i) Encryption and decryption → Partial: At rest ✓, in transit ✗
• (ii) Access controls → Partial: IAM ✓, MFA ✗, role audits ✗

SOC 2 CC6.1 (Logical access controls):

• "System is protected against unauthorized logical access" → Partial: MFA missing, no attribute-based access

Step 4: Gaps

Step 5: Remediation Roadmap

Step 6: Evidence Collected for Auditors

• HIPAA Compliance Checklist: Filled in, signed by Security Officer
• Encryption Audit Report: Network capture showing TLS on all data flows
• IAM Access Report: Q2 2026 access review with manager sign-offs
• Audit Log Sample: 6 months of application + system logs proving "who did what when"
• Policies: Written HIPAA Security Rule implementation policy, MFA policy, incident response plan

Related Skills

• /security-audit — Inventory and assess current security controls
• /threat-modeling — Identify new threats; cross-reference against compliance gaps
• /incident-response — When gaps are exploited; collect evidence for post-incident compliance