/compliance-review

name: compliance-review
description: >
  Build or review code for compliance with the EU AI Act, GDPR, the NIS2
  Directive (EU 2022/2555), and secure-development (SSDLC) best practice.
  Three modes. REVIEW: audit a repo and produce an evidence-based gap analysis —
  triggers on "compliance review", "gap analysis", "NIS2 check", "is this repo
  GDPR compliant", "security audit of the code". DESIGN/BUILD: apply the same
  requirements as compliance-by-design guardrails while writing new code, then
  self-check — triggers on "build X with GDPR/AI Act/NIS2 in mind",
  "compliant/secure/privacy by design". DATA MASKING: when the user shares a
  dataset (CSV, JSON, query result) that may contain personal data, never read
  it raw — ask whether to pseudonymise (keeps joins) or anonymise
  (k-anonymity), then protect it first — triggers on "anonymise/mask this
  data" or any dataset handed over for analysis. Use
  whenever code or data must meet a security/privacy/AI regulation, even if no
  framework is named. Advisory only, not legal advice.
license: MIT

Compliance Review & Design

Help code **meet** the EU AI Act, the GDPR, the NIS2 Directive (EU 2022/2555), and secure-development (SSDLC) best practice — either by **reviewing** an existing repository or by **building it in from the start**. The EU frameworks are public legal texts (articles cited directly); the SSDLC pillar aligns with OWASP SAMM / ASVS and NIST SSDF. The reference files are the shared source of truth in all modes:

• EU AI Act → `references/eu-ai-act.md`
• GDPR → `references/gdpr-quickcheck.md`
• NIS2 → `references/nis2.md`
• Secure development (SSDLC) → `references/secure-development.md`
• Data masking (safe dataset handling) → `references/data-masking.md`

Read this first: scope and honesty (applies to all modes)

A codebase is only part of an organisation's compliance posture. NIS2 and GDPR are largely governance regimes — policies, risk treatment, training, and reporting to authorities live outside any code. Be honest about that boundary: address only what code can actually carry, and flag the rest as organisational.

• This is an **advisory aid**, not a certification or legal opinion, and not

legal advice. It helps prioritise and build correctly; it does not prove conformity.

• **Never read, print, or hardcode secret values.** Secrets come from env vars or

a secret store — never committed or embedded. If you find a committed credential, report its location and that it must be rotated; do not print it.

Avoid double-counting across frameworks

The four references overlap on purpose — NIS2 Art. 21(2)(e), the SSDLC practices, and GDPR Art. 32 all touch SAST, dependency scanning, encryption, access control and vulnerability handling. Assess each underlying fact **once**: record the full finding (evidence, severity, remediation) in the **most specific section** — usually SSDLC for engineering practice, NIS2 for the legal measure, GDPR when personal data is the point — and in the other tables add a one-line cross-reference (e.g. "see SSDLC §2.2") instead of repeating it. Count each underlying gap **once** in the severity totals.

Choose the mode

• The user has an **existing** repo/app and wants it checked → **Review mode**.
• The user is **starting or writing** something new (or adding a feature) and

wants it done compliantly → **Design/build mode**.

• The user **shares a dataset** (file, paste, query result) that may contain

personal data → **Data-masking mode** first, whatever else follows.

If both apply (e.g. "build this and then check it"), do Design/build first, then finish with a Review-mode self-check.

---

Design/build mode (compliance-by-design)

The goal is to bake the requirements in *while writing*, not to bolt them on later. The reference files stop being an audit checklist and become a **requirements list**.

1. Scope what applies

Before writing, work out which requirements are live for this project:

• **Personal data?** If the app processes personal data, GDPR applies — note the

data categories (and whether any are special-category, Art. 9). See `references/gdpr-quickcheck.md`.

• **AI/ML component?** If it builds, integrates, or deploys AI, the AI Act

applies — infer the likely risk class first. See `references/eu-ai-act.md`.

• **Security baseline (NIS2)** applies to essentially any networked service;

treat Art. 21 technical measures as the security floor. See `references/nis2.md`.

• **Secure development (SSDLC)** applies to *all* code, always — treat

`references/secure-development.md` as the engineering baseline (environment separation, secure coding, SAST/dependency scanning, security testing).

State these as premises so the user can correct them.

2. Turn the relevant items into build requirements

Read the applicable reference file(s) and translate each relevant item into a concrete thing to implement. For example:

• Secrets → load from env/secret store from the first commit; add `.env` to

`.gitignore`; never hardcode.

• Access control → put an authN/authZ model in from the start (RBAC, session/token

expiry, least privilege); add MFA support where accounts matter.

• Cryptography → TLS everywhere, encryption at rest for sensitive data, strong

password hashing (bcrypt/argon2).

• Logging/traceability → log security and access events with actor + timestamp;

for AI, log inferences (input/output/model version) for record-keeping.

• Data minimisation & retention → collect only what's needed; add a deletion/

retention path (GDPR Art. 5, 17) early, not later.

• Transparency (AI) → if it's a chatbot or generative AI, disclose AI use and

mark AI-generated content.

• Supply chain → pin dependencies, add a lockfile, wire dependency/vulnerability

scanning into CI from the start.

• Secure SDLC → separate dev/test/prod config, SAST in CI, input validation and

parameterised queries by default, code review before release.

Prefer building the gu