---
id: compliance-awareness
version: "1.0.0"
title: "Compliance Awareness"
description: "Map generated code against OWASP, CWE, and SANS Top 25 controls for traceability"
category: compliance
severity: medium
applies_to:
  - "when generating code in regulated environments"
  - "when writing audit-relevant comments or documentation"
  - "when refactoring code that crosses compliance boundaries (PII, PHI, PCI scope)"
languages: ["*"]
token_budget:
  minimal: 400
  compact: 700
  full: 2000
rules_path: "frameworks/"
related_skills: ["secure-code-review", "api-security"]
last_updated: "2026-05-14"
sources:
  - "OWASP Top 10 2021"
  - "CWE Top 25 2023"
  - "PCI DSS v4.0"
  - "HIPAA Security Rule"
  - "SOC 2 Trust Services Criteria"
---

# Compliance Awareness

## Rules (for AI agents)

### ALWAYS
- Tag functions that handle PII / PHI / PCI data with a comment indicating the
  classification (e.g. `// classification: PII`).
- Log audit events for security-relevant actions (login, permission change, data
  export, admin operations) — log who, what, when, NOT the sensitive payload.
- Identify the CWE / OWASP category for security-relevant code in comments when the
  team's convention is to include traceability (`// addresses CWE-79 — XSS`).
- For PCI scope, segregate card-data-handling code into clearly-named modules so
  scope boundaries are visible.
- For HIPAA workloads, prefer encryption at rest AND in transit, with documented key
  management.

### NEVER
- Include PII / PHI / PCI in log messages, error messages, or telemetry events.
- Store payment card numbers, CVVs, or full magnetic stripe data outside of a PCI
  DSS-compliant tokenization service.
- Mix PII-handling code into general utility modules without explicit classification.
- Generate code that processes EU residents' personal data without considering GDPR
  obligations (right to erasure, data minimization, lawful basis).
- Suggest workarounds that bypass compliance controls "for development" — these
  workarounds always leak into production.

### KNOWN FALSE POSITIVES
- Logs of *types* of data accessed ("user accessed claim record") are usually fine;
  the rule is against logging the *contents* of sensitive fields.
- Test fixtures using clearly fake data (`555-0100` phone numbers,
  `4111-1111-1111-1111` PAN, `John Doe`) are not PII.
- Audit log retention is intentionally long (often years) and should not be filtered
  by general data-retention sweeps.

## Context (for humans)

Compliance frameworks (PCI DSS, HIPAA, SOC 2, ISO 27001, GDPR) prescribe controls but
don't tell developers what code to write. This skill bridges the gap by attaching
control-relevant guidance to AI generation steps, so the resulting code is
audit-friendly by default.

## References

- `frameworks/owasp_mapping.yaml`
- `frameworks/cwe_mapping.yaml`
- [OWASP Top 10 2021](https://owasp.org/Top10/).
- [CWE Top 25 2023](https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html).
- [PCI DSS v4.0](https://www.pcisecuritystandards.org/document_library/).
