Skill — Compliance as Code
When this skill activates
Any task involving automated compliance verification, policy-as-code implementation,
audit evidence generation, regulatory control mapping, or compliance CI integration.
Mandatory actions when this skill is active
Before writing any code
- Identify the compliance framework(s) applicable (SOC2, HIPAA, PCI-DSS, GDPR).
- Map specific controls to technical policies that can be automated.
- Define evidence requirements for each control.
During implementation
- Write policies as code (OPA/Rego, Sentinel, Conftest).
- Integrate policy checks into CI pipeline (fail on violation).
- Generate machine-readable evidence automatically.
After implementation
- Verify all mapped controls have automated verification.
- Set up continuous compliance dashboard with drift alerts.
- Document policy-to-control mapping in ARCHITECTURE.md.
Policy Engines
OPA (Open Policy Agent) with Rego
- General-purpose policy engine.
- Declarative policy language (Rego).
- Use for: infrastructure policies, API authorization, data access control.
- Integrations: Kubernetes (Gatekeeper), Terraform, CI pipelines, API gateways.
package terraform.aws
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])
}
HashiCorp Sentinel
- Policy-as-code for Terraform Enterprise/Cloud.
- Enforces infrastructure policies before apply.
- Use for: cost controls, naming conventions, required tags, approved regions.
import "tfplan"
main = rule {
all tfplan.resources.aws_instance as _, instances {
all instances as _, r {
r.applied.tags contains "environment"
}
}
}
Conftest
- Testing framework for structured configuration data.
- Uses OPA/Rego policies against YAML, JSON, HCL, Dockerfile.
- Use for: Kubernetes manifests, Docker configs, CI pipelines.
package main
deny[msg] {
input.kind == "Deployment"
not input.spec.template.spec.securityContext.runAsNonRoot
msg := "Containers must run as non-root"
}
Control Framework Mapping
SOC2 Trust Service Criteria
| Control |
Policy |
Automated Check |
| CC6.1 (Logical Access) |
IAM least privilege |
No wildcard permissions in policies |
| CC6.6 (System Boundaries) |
Network segmentation |
Security groups restrict ingress |
| CC7.2 (Monitoring) |
Log aggregation |
All services emit structured logs |
| CC8.1 (Change Management) |
PR approval required |
Branch protection rules enforced |
HIPAA Security Rule (164.312)
| Control |
Policy |
Automated Check |
| 164.312(a)(1) Access Control |
Role-based access |
RBAC policies enforced |
| 164.312(a)(2)(iv) Encryption |
Data encrypted at rest |
All storage encrypted |
| 164.312(b) Audit Controls |
Audit logging |
All PHI access logged |
| 164.312(e)(1) Transmission Security |
TLS required |
No HTTP endpoints |
PCI-DSS
| Requirement |
Policy |
Automated Check |
| 2.2 System hardening |
CIS benchmark |
Configuration scanner passes |
| 3.4 Data encryption |
Encryption at rest |
Storage encryption verified |
| 6.5 Secure development |
SAST/DAST |
No critical findings in scan |
| 10.2 Audit trails |
Comprehensive logging |
All access events captured |
Evidence Generation
Automated Evidence Types
- Configuration snapshots: point-in-time state of security configs.
- Policy evaluation results: pass/fail with details for each control.
- Access review reports: who has access to what, generated automatically.
- Deployment audit trails: who deployed what, when, with what approval.
Evidence Requirements
- Timestamped and immutable (stored in append-only log).
- Machine-readable (JSON/structured format for automated processing).
- Traceable (linked to specific control and policy).
- Continuous (generated on every change, not just at audit time).
Example Evidence Output
{
"control": "CC6.1",
"framework": "SOC2",
"policy": "no-wildcard-iam-permissions",
"result": "PASS",
"timestamp": "2024-01-15T10:30:00Z",
"resource": "arn:aws:iam::123456:policy/app-service",
"details": "No wildcard actions found in policy document",
"evidence_hash": "sha256:abc123..."
}
CI Pipeline Integration
Pipeline Stage: Policy Check
stages:
- name: compliance-check
steps:
- conftest test --policy policies/ deployment.yaml
- opa eval --data policies/ --input tfplan.json "data.terraform.deny"
on_failure: block_deployment
Enforcement Levels
- Advisory: log warning, don't block (for new policies being rolled out).
- Soft mandatory: block with override option (requires approval).
- Hard mandatory: block deployment, no override (critical security controls).
Gradual Rollout of New Policies
- Deploy policy in advisory mode (2 weeks).
- Review violations, adjust policy if false positives.
- Promote to soft mandatory (2 weeks).
- Promote to hard mandatory after all violations resolved.
Compliance Dashboard
Key Metrics
- Compliance score: percentage of controls with passing automated checks.
- Drift count: controls that passed previously but now fail.
- Time to remediate: average time from violation detection to fix.
- Coverage: percentage of controls with automated verification.
Alerting
- Drift detected: immediate alert to security team.
- New violation in PR: block merge, notify developer.
- Compliance score drops below threshold: escalate to CISO.
- Evidence generation failure: alert compliance team.
Reporting
Continuous Compliance Report
- Generated on demand or on schedule (weekly/monthly).
- Shows: all controls, current status, evidence links, violation history.
- Format: PDF for auditors, JSON for automated systems.
Audit Preparation
- Pre-audit checklist: verify all evidence is current and complete.
- Gap analysis: identify controls without automated verification.
- Remediation tracking: SLA for fixing violations.
Self-check before task completion
Before marking a task done when this skill was active:
1---2name: compliance-as-code3description: Skill — Compliance as Code4---56# Skill — Compliance as Code78## When this skill activates9Any task involving automated compliance verification, policy-as-code implementation,10audit evidence generation, regulatory control mapping, or compliance CI integration.1112## Mandatory actions when this skill is active1314### Before writing any code151. Identify the compliance framework(s) applicable (SOC2, HIPAA, PCI-DSS, GDPR).162. Map specific controls to technical policies that can be automated.173. Define evidence requirements for each control.1819### During implementation20- Write policies as code (OPA/Rego, Sentinel, Conftest).21- Integrate policy checks into CI pipeline (fail on violation).22- Generate machine-readable evidence automatically.2324### After implementation25- Verify all mapped controls have automated verification.26- Set up continuous compliance dashboard with drift alerts.27- Document policy-to-control mapping in ARCHITECTURE.md.2829## Policy Engines3031### OPA (Open Policy Agent) with Rego32- General-purpose policy engine.33- Declarative policy language (Rego).34- Use for: infrastructure policies, API authorization, data access control.35- Integrations: Kubernetes (Gatekeeper), Terraform, CI pipelines, API gateways.3637```rego38package terraform.aws3940deny[msg] {41 resource := input.resource.aws_s3_bucket[name]42 not resource.server_side_encryption_configuration43 msg := sprintf("S3 bucket '%s' must have encryption enabled", [name])44}45```4647### HashiCorp Sentinel48- Policy-as-code for Terraform Enterprise/Cloud.49- Enforces infrastructure policies before apply.50- Use for: cost controls, naming conventions, required tags, approved regions.5152```hcl53import "tfplan"5455main = rule {56 all tfplan.resources.aws_instance as _, instances {57 all instances as _, r {58 r.applied.tags contains "environment"59 }60 }61}62```6364### Conftest65- Testing framework for structured configuration data.66- Uses OPA/Rego policies against YAML, JSON, HCL, Dockerfile.67- Use for: Kubernetes manifests, Docker configs, CI pipelines.6869```rego70package main7172deny[msg] {73 input.kind == "Deployment"74 not input.spec.template.spec.securityContext.runAsNonRoot75 msg := "Containers must run as non-root"76}77```7879## Control Framework Mapping8081### SOC2 Trust Service Criteria82| Control | Policy | Automated Check |83|---------|--------|-----------------|84| CC6.1 (Logical Access) | IAM least privilege | No wildcard permissions in policies |85| CC6.6 (System Boundaries) | Network segmentation | Security groups restrict ingress |86| CC7.2 (Monitoring) | Log aggregation | All services emit structured logs |87| CC8.1 (Change Management) | PR approval required | Branch protection rules enforced |8889### HIPAA Security Rule (164.312)90| Control | Policy | Automated Check |91|---------|--------|-----------------|92| 164.312(a)(1) Access Control | Role-based access | RBAC policies enforced |93| 164.312(a)(2)(iv) Encryption | Data encrypted at rest | All storage encrypted |94| 164.312(b) Audit Controls | Audit logging | All PHI access logged |95| 164.312(e)(1) Transmission Security | TLS required | No HTTP endpoints |9697### PCI-DSS98| Requirement | Policy | Automated Check |99|-------------|--------|-----------------|100| 2.2 System hardening | CIS benchmark | Configuration scanner passes |101| 3.4 Data encryption | Encryption at rest | Storage encryption verified |102| 6.5 Secure development | SAST/DAST | No critical findings in scan |103| 10.2 Audit trails | Comprehensive logging | All access events captured |104105## Evidence Generation106107### Automated Evidence Types108- **Configuration snapshots**: point-in-time state of security configs.109- **Policy evaluation results**: pass/fail with details for each control.110- **Access review reports**: who has access to what, generated automatically.111- **Deployment audit trails**: who deployed what, when, with what approval.112113### Evidence Requirements114- Timestamped and immutable (stored in append-only log).115- Machine-readable (JSON/structured format for automated processing).116- Traceable (linked to specific control and policy).117- Continuous (generated on every change, not just at audit time).118119### Example Evidence Output120```json121{122 "control": "CC6.1",123 "framework": "SOC2",124 "policy": "no-wildcard-iam-permissions",125 "result": "PASS",126 "timestamp": "2024-01-15T10:30:00Z",127 "resource": "arn:aws:iam::123456:policy/app-service",128 "details": "No wildcard actions found in policy document",129 "evidence_hash": "sha256:abc123..."130}131```132133## CI Pipeline Integration134135### Pipeline Stage: Policy Check136```yaml137stages:138 - name: compliance-check139 steps:140 - conftest test --policy policies/ deployment.yaml141 - opa eval --data policies/ --input tfplan.json "data.terraform.deny"142 on_failure: block_deployment143```144145### Enforcement Levels146- **Advisory**: log warning, don't block (for new policies being rolled out).147- **Soft mandatory**: block with override option (requires approval).148- **Hard mandatory**: block deployment, no override (critical security controls).149150### Gradual Rollout of New Policies1511. Deploy policy in advisory mode (2 weeks).1522. Review violations, adjust policy if false positives.1533. Promote to soft mandatory (2 weeks).1544. Promote to hard mandatory after all violations resolved.155156## Compliance Dashboard157158### Key Metrics159- **Compliance score**: percentage of controls with passing automated checks.160- **Drift count**: controls that passed previously but now fail.161- **Time to remediate**: average time from violation detection to fix.162- **Coverage**: percentage of controls with automated verification.163164### Alerting165- Drift detected: immediate alert to security team.166- New violation in PR: block merge, notify developer.167- Compliance score drops below threshold: escalate to CISO.168- Evidence generation failure: alert compliance team.169170## Reporting171172### Continuous Compliance Report173- Generated on demand or on schedule (weekly/monthly).174- Shows: all controls, current status, evidence links, violation history.175- Format: PDF for auditors, JSON for automated systems.176177### Audit Preparation178- Pre-audit checklist: verify all evidence is current and complete.179- Gap analysis: identify controls without automated verification.180- Remediation tracking: SLA for fixing violations.181182## Self-check before task completion183184Before marking a task done when this skill was active:185186- [ ] Did I read the full SKILL.md before starting? (Not just the triggers)187- [ ] Is every control mapped to an automated policy?188- [ ] Are policies integrated into CI (blocking on violation)?189- [ ] Is evidence generated automatically (not manually)?190- [ ] Is there a compliance dashboard with drift alerting?191- [ ] Are enforcement levels appropriate (advisory → soft → hard)?192- [ ] Is the policy-to-control mapping documented?