| name | compliance-checker |
| description | Compliance framework audit expertise covering SOC 2 Type II controls, GDPR technical requirements, HIPAA security rule, PCI DSS for developers, ISO 27001 controls, audit evidence collection, compliance-as-code, and continuous compliance monitoring for meeting regulatory and industry security standards.
Use when the user asks about compliance checker, compliance checker best practices, or needs guidance on compliance checker implementation.
Do NOT use when the user needs a different specialized skill or is asking about an unrelated technology domain.
|
| license | Apache-2.0 |
| metadata | {"author":"foundry-skills","version":"1.0.0","tags":"security compliance guide","category":"security","subcategory":"compliance-audit","depends":"","disclaimer":"none","difficulty":"advanced"} |
Compliance Checker
Overview
Compliance is the practice of meeting regulatory, legal, and industry security standards. For engineers, compliance is not paperwork -- it is the implementation of specific technical controls that protect data and systems. This skill covers the technical requirements of major compliance frameworks and how to implement and automate them.
SOC 2 Type II
SOC 2 is the most common compliance framework for SaaS companies. Type II covers a period of time (typically 6-12 months), not just a point-in-time snapshot.
Trust Service Criteria (TSC)
CC1 - Control Environment
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
Additional criteria:
A1 - Availability
PI1 - Processing Integrity
C1 - Confidentiality
P1 - Privacy
Key Technical Controls for Engineers
access_controls:
- control: CC6.1 - Access Provisioning
implementation:
- SSO with SAML/OIDC for all production systems
- Role-based access control (RBAC) with least privilege
- Access reviews quarterly (automated via SCIM)
- Unique user accounts (no shared credentials)
evidence:
- IAM policies and role definitions
- Access review reports (quarterly)
- SSO provider audit logs
-
GDPR Technical Requirements
Data Processing Principles (Article 5)
class GDPRCompliantDataProcessor:
"""Implement GDPR data processing principles in code."""
def process_personal_data(self, data, purpose, legal_basis):
"""
Article 5(1)(a): Lawfulness, fairness, transparency
"""
if legal_basis not in ['consent', 'contract', 'legal_obligation',
'vital_interests', 'public_task',
'legitimate_interests']:
raise GDPRViolationError("Invalid legal basis")
if field in pseudonymized:
pseudonymized[field] = hashlib.sha256(
(str(pseudonymized[field]) + self.salt).encode()
).hexdigest()
return pseudonymized
Data Subject Rights (Articles 15-22)
class DataSubjectRightsHandler:
"""Handle GDPR data subject requests."""
def right_of_access(self, user_id):
"""Article 15: Provide all data held about a user."""
data = {}
for source in self.data_sources:
data[source.name] = source.get_all_user_data(user_id)
return {
'personal_data': data,
'processing_purposes': self.get_purposes(user_id),
'categories': self.get_data_categories(user_id),
'recipients': self.get_data_recipients(user_id),
'retention_period': self.get_retention_info(user_id),
def right_to_portability(self, user_id):
"""Article 20: Export data in machine-readable format."""
data = self.right_of_access(user_id)
return json.dumps(data, indent=2, default=str)
Consent Management
class ConsentManager:
"""GDPR-compliant consent management."""
def record_consent(self, user_id, purpose, version):
"""Record granular, specific consent."""
consent_record = {
'user_id': user_id,
'purpose': purpose,
'consent_version': version,
'granted_at': datetime.utcnow(),
'ip_address': get_client_ip(),
'user_agent': get_user_agent(),
'method': 'explicit_opt_in',
'withdrawable': True,
record = self.db.query(
'consent_records',
{'user_id': user_id, 'purpose': purpose, 'withdrawn_at': None}
)
return record is not None
HIPAA Security Rule
Technical Safeguards (164.312)
access_control:
unique_user_identification:
requirement: Assign unique identifier to each user
implementation: SSO with unique employee IDs
status: required
emergency_access:
requirement: Procedures for accessing PHI in emergencies
implementation: Break-glass procedure with audit trail
status: required
automatic_logoff:
implementation:
- TLS 1.2+ for all network communication
- VPN for remote access to PHI systems
- Email encryption
PHI Data Classification
PHI_FIELDS = {
'name': {'type': 'direct_identifier', 'deidentify': 'remove'},
'address': {'type': 'direct_identifier', 'deidentify': 'generalize_to_state'},
'date_of_birth': {'type': 'direct_identifier', 'deidentify': 'generalize_to_year'},
'ssn': {'type': 'direct_identifier', 'deidentify': 'remove'},
'phone': {'type': 'direct_identifier', 'deidentify': 'remove'},
'email': {'type': 'direct_identifier', 'deidentify': 'remove'},
'mrn': {'type': 'direct_identifier', 'deidentify': 'pseudonymize'},
'health_plan_id': {'type': 'direct_identifier', 'deidentify': 'remove'},
'ip_address': {'type': 'direct_identifier', 'deidentify': 'remove'},
'biometric': {'type': 'direct_identifier', : },
: {: , : },
: {: , : },
: {: , : },
: {: , : },
}
PCI DSS for Developers
Requirements That Affect Code
pci_dss_v4_developer_requirements:
requirement_3:
- never_store_full_track_data: true
- never_store_cvv_after_authorization: true
- mask_pan_display: "Show only first 6 and last 4 digits"
- encrypt_pan_at_rest: "AES-256 with key management"
- use_tokenization: "Replace PAN with non-reversible token"
requirement_4:
- tls_version: "1.2 minimum, 1.3 preferred"
- never_send_pan_via: ["email", "chat", "SMS"]
requirement_6:
requirement_11:
- vulnerability_scans: "Quarterly by ASV"
- penetration_test: "Annual (or after significant changes)"
- file_integrity_monitoring: "Critical system files"
PCI-Compliant Payment Form
<div id="card-element">
</div>
ISO 27001 Controls (Annex A)
Controls Relevant to Engineering Teams
A5_information_security_policies:
A5.1: Information security policy
implementation: Documented security policy in wiki/handbook
A6_organization:
A6.1: Security roles and responsibilities
implementation: RACI matrix for security responsibilities
A8_asset_management:
A8.1: Asset inventory
implementation: CMDB or infrastructure-as-code that tracks all assets
A8.2: Information classification
implementation: Data classification labels (public, internal, confidential, restricted)
implementation: Threat modeling in design phase
A14.2: Secure
Audit Evidence Collection
Automated Evidence Collection
class ComplianceEvidenceCollector:
"""Automatically collect and organize compliance evidence."""
def __init__(self, output_dir):
self.output_dir = output_dir
def collect_access_reviews(self):
"""Collect access review evidence (SOC 2 CC6.1)."""
iam = boto3.client('iam')
users = iam.list_users()
roles = iam.list_roles()
policies = iam.list_policies(Scope='Local')
self.output_dir,
f"{name}_{datetime.utcnow():%Y%m%d}.json"
)
with open(filepath, 'w') as f:
json.dump(data, f, indent=2, default=str)
Compliance-as-Code
REGO_POLICY = """
package terraform.s3
deny[msg] {
resource := input.resource.aws_s3_bucket[name]
not resource.server_side_encryption_configuration
msg := sprintf("S3 bucket '%s' must have encryption enabled", [name])
}
deny[msg] {
# ... (condensed) ...
resource := input.resource.aws_db_instance[name]
resource.publicly_accessible
msg := sprintf("RDS instance '%s' must not be publicly accessible", [name])
}
"""
Infrastructure Compliance Scanning
# Prowler (AWS security best practices)
prowler aws --compliance soc2
prowler aws --compliance hipaa
prowler aws --compliance pci_dss_v4
# Checkov (infrastructure-as-code scanning)
checkov --directory ./terraform/ --framework terraform
checkov --file Dockerfile --framework dockerfile
# ScoutSuite (multi-cloud security auditing)
scout aws --report-dir ./scout-report
Continuous Compliance Monitoring
metrics:
access_control:
- name: users_without_mfa
query: "Count IAM users where MFA is not enabled"
threshold: 0
severity: critical
- name: inactive_users_90_days
query: "Count users with no login in 90 days"
threshold: 0
severity: high
- name: high_vulns_unpatched_7d
query: "Count high vulnerabilities older than 7 days"
threshold: 0
severity: high
Framework Comparison
| Requirement | SOC 2 | GDPR | HIPAA | PCI DSS | ISO 27001 |
|---|
| Encryption at rest | CC6.7 | Art. 32 | 164.312(a)(2)(iv) | Req 3.4 | A10.1 |
| Encryption in transit | CC6.7 | Art. 32 | 164.312(e)(1) | Req 4.1 | A10.1 |
| Access control | CC6.1-6.3 | Art. 32 | 164.312(a)(1) | Req 7-8 | A9 |
| Logging/audit | CC7.1-7.2 | Art. 30 | 164.312(b) | Req 10 | A12.4 |
| Incident response | CC7.3 | Art. 33-34 | 164.308(a)(6) | Req 12.10 | A16 |
| Vulnerability mgmt | CC7.1 | Art. 32 | 164.308(a)(5) | Req 6.1, 11 | A12.6 |
| Data retention | CC6.5 | Art. 5(1)(e) | 164.530(j) | Req 3.1 | A8.2 |
| Risk assessment | CC3.1 | Art. 35 | 164.308(a)(1) | Req 12.2 | A6.1.2 |
When to Use
Use this skill when:
- Designing or implementing compliance checker solutions
- Reviewing or improving existing compliance checker approaches
- Making architectural or implementation decisions about compliance checker
- Learning compliance checker patterns and best practices
- Troubleshooting compliance checker-related issues
Do NOT use this skill when:
- The question is about a fundamentally different technology domain
- A more specific sibling skill covers the exact topic needed
- The user needs a complete hands-on tutorial rather than expert guidance
Output Format
# Compliance Checker Analysis
## Context Assessment
[Situation summary and constraints]
## Recommended Approach
[Primary recommendation with rationale]
## Implementation Steps
1. [Step with specific details]
2. [Step with specific details]
3. [Step with specific details]
## Trade-offs and Considerations
- [Key trade-off 1]
- [Key trade-off 2]
## Next Steps
- [Immediate action item]
- [Follow-up action item]
Example
Input: "Help me implement compliance checker for a medium-scale production application"
Output: A structured analysis covering current state assessment, recommended compliance checker approach with specific patterns, implementation roadmap with milestones, and risk mitigation strategies tailored to the application scale and constraints.
Edge Cases
- Legacy system integration: When compliance checker must coexist with legacy approaches, provide a gradual migration path rather than a complete rewrite
- Scale mismatch: When the solution complexity exceeds the project scale, recommend a simpler approach and note when to revisit
- Team skill gaps: When the team lacks experience with the recommended approach, include learning resources and simpler alternatives
- Conflicting requirements: When constraints conflict (e.g., performance vs. maintainability), explicitly state the trade-off and recommend based on stated priorities
