<< All versions

Skill v1.0.0

currentAutomated scan100/100
nguyencongnamit/skills-library/compliance-awareness
──Details
PublishedOctober 4, 2026 at 10:13 AM
Content Hashsha256:aba4cf50a95942b1...
Git SHA617c977343ba
──Files
Files (1 file, 4.4 KB)
SKILL.md4.4 KBactive
SKILL.md · 99 lines · 4.4 KB

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-06-20" 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.

Verify & lock (triaging a finding)

A compliance gap flagged in review is a candidate, not a confirmed gap. Confirm the control is actually missing, remediate, then lock it so the control can't silently regress between audits.

  1. Confirm the gap is real (map to the control + check for evidence). Tie the

finding to a specific clause — SOC 2 CC-series, PCI DSS requirement, HIPAA Security Rule safeguard, GDPR article — then check whether the technical evidence for that control actually exists: encryption-at-rest flag enabled, audit logging on for the security-relevant action, MFA enforced on the access path, PII/PHI classification tags present, the data-retention/erasure job scheduled and running. Real gap if the evidence is absent; false positive if a compensating control (tokenization service, network segmentation, an existing managed-encryption layer) already satisfies the clause.

  1. Remediate, then lock with an automated control test (unit or integration —

dev's call). Write a CI check that asserts the control's technical evidence as compliance-as-code: the config flag is set, the audit-log entry is emitted for the sensitive action, the classification comment/tag is present on the data-handling module, the retention policy exists. Add a passing baseline and commit it, so the control is verified continuously rather than rediscovered at the next audit.

References

All versions