Compliance review

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 guardrail in now; if the user explicitly defers something, note it as a known gap rather than silently skipping it.

3. Write the code applying them

Implement the feature/app normally, but with the requirements above as non-negotiable defaults. When a requirement would materially change the design (e.g. needing a secret store, or an audit-log table), call it out and do it rather than choosing the non-compliant shortcut.

4. Self-check before finishing

Do a short Review-mode pass over what you just wrote (see below) and report which requirements are now satisfied and which remain open (with a reason). This gives the user a compliance-by-design summary, not just code.

Output: the code, plus a brief "compliance built in" summary — a short list per framework of what was implemented and any deliberate gaps left for later.

---

Data-masking mode (safe dataset handling)

When a dataset that may contain personal data enters the conversation, do not read the raw file, and ask the user which strategy they want before processing (unless they already said). One short question with the trade-off:

• Pseudonymise (default) — PII replaced by deterministic salted-hash tokens. Keeps full analytical utility (joins, group-bys, dedup, row-level detail), but the result is still personal data under GDPR Art. 4(5).
• Anonymise — direct identifiers, id columns, health and free-text columns are dropped; dates generalised (birth → decade, dates → year); numerics binned; k-anonymity enforced by suppressing rare combinations. Aims at leaving GDPR scope, at a real cost in detail and rows. Ask for the k threshold too if the user cares (default 5).

Then run the helper and work only on its output:

python scripts/data_masking.py <file> [--out masked.csv]            # pseudonymise
python scripts/data_masking.py <file> --anonymize --k 5 [--out ...] # anonymise

It infers the schema, detects likely-PII columns (names, value patterns, health terms), and prints only structure + protected values; with --out it writes a protected copy safe for analysis. Read references/data-masking.md for the method and its honest limits (pseudonymised data is still personal data; anonymisation here is strong risk reduction, not a legal guarantee — verify quasi-identifiers and context). If code execution is unavailable, say you cannot process the raw file safely and ask for a masked export — do not open it anyway.

This mode composes with the others: write loaders/models/pipelines from the masked schema (the code will run on real data on the user's machine), and cite GDPR Art. 25/32 when recommending which columns to mask before sharing.

---

Review mode (audit an existing repo)

1. Scope the review

Confirm which frameworks apply and which repo. Default to all four (AI Act, GDPR, NIS2, secure-development/SSDLC). AI Act only truly applies if there's an AI/ML component (else mark it Not applicable); NIS2 organisational applicability is a legal premise, not a code finding; secure-development practices apply to any codebase.

2. Inventory the repo

Build a factual picture first. If code execution is available, run the optional helper for a fast, deterministic pass (it never prints secret values):

python scripts/repo_inventory.py <repo-path>

The script is just an accelerator — if you can't run it, do the same inventory by reading the repo directly. Either way, read what matters by hand: entrypoints, auth/session code, logging, data-access layers, IaC/Docker/CI, dependency manifests, backup/monitoring config. Note what personal data is processed, how authentication and secrets work, and whether encryption/logging exist.

3. Map to requirements

Open each applicable reference file and work through it. For every item assign a Status (Compliant / Gap / Partial / N/A / Out-of-scope (org)), cite Evidence (file:line — no evidence ⇒ don't claim Compliant), and for gaps a Severity (High/Medium/Low, weighted by exposure and data sensitivity) and a one-line Remediation. Apply the double-counting rule above: one full finding in the most specific table, cross-references elsewhere.

4. Write the report

Fill in assets/review-template.md exactly. Save it where the user asks; if not specified, propose a path (e.g. compliance/<repo>.md) and confirm. Lead with the summary and highest-severity gaps.

Output: a verdict summary (one paragraph + a counts line like High: 2 · Medium: 5 · Low: 3), one table per framework, then a prioritised remediation list.

---

Examples

Design/build: "Build a small FastAPI service to store customer contacts, GDPR-compliant." → Scope: personal data (names, emails) ⇒ GDPR + NIS2 baseline + SSDLC, no AI. Build with: secrets from env, TLS, hashed auth, access control, a delete endpoint (Art. 17), a documented data-map, access logging, SAST and dependency scanning in CI. Deliver the code + a "compliance built in" summary noting what's done and that lawful-basis/consent is an org decision.

Review: "Do a compliance review of the payments-api repo against NIS2 and GDPR." → Inventory, map to nis2.md + gdpr-quickcheck.md (+ SSDLC baseline), produce the table report with severities and a prioritised fix list. Example rows:

Requirement	Status	Evidence	Sev.	Remediation
NIS2 Art. 21(2)(h) Cryptography	Compliant	TLS enforced config/server.py:20; bcrypt auth.py:55	—	—
NIS2 Art. 21(2)(d) Supply chain	Gap	no dependency scanning in CI	Medium	Add automated dependency scanning to the pipeline
GDPR Art. 30 Records / data inventory	Gap	no documented list of PII fields	Medium	Add a data-map doc enumerating personal-data fields & purpose