Medical AI Compliance Gate

Medical AI compliance gate (GDPR · MDR · ISO 27001 · SOC 2, verified)

Prepare a medical/health-AI system for compliance and prove the machine-decidable part — gaps are surfaced by a scanner that runs over the repo, fixed by severity, and re-scanned until green; then a mandatory human attestation completes the gate.

Core principle

Gaps are measured, not assumed. The loop is: scan → triage by severity → fix the cause → re-scan, until the automated gate is green; then complete the manual attestation before any readiness claim.

Be honest about scope (this is the rule that keeps the skill correct): this is engineering assistance to prepare for compliance, nothing more. It is NOT legal advice, NOT a regulatory certification, NOT an EU MDR conformity assessment or CE marking, NOT a Notified Body audit, NOT an ISO 27001 certification, and NOT a SOC 2 attestation. MDR conformity for medical-device software (MDSW) additionally requires a QMS (ISO 13485), risk management (ISO 14971), a clinical evaluation, and — for most classes — a Notified Body, none of which this replaces. Heuristics have false positives and negatives. Passing the gate ≠ compliant. Never report "GDPR/MDR/ISO/SOC 2 compliant" on a green scan — report "0 blocking automated controls; manual attestation pending/complete." → references/01-frameworks-and-scope.md

When to use vs. not

• Use for: a compliance/readiness gap analysis of a health-AI codebase or data pipeline against GDPR / MDR / ISO 27001 / SOC 2; adding a compliance CI gate; drafting a DPIA / Records of Processing; preparing engineering evidence for an upcoming audit.
• Not for: obtaining an actual certification, CE mark, or audit opinion (those need external bodies); clinical validation or risk-management file authoring (regulatory program work); legal sign-off (needs counsel/DPO).

Inputs to gather first

1. What to audit — path to the repo / pipeline (targetDir), and what to skip (vendored code, build output). → references/03-running-the-scan.md
2. Which frameworks — default all four (GDPR, MDR, ISO27001, SOC2); scope down if, e.g., the product isn't (yet) a medical device. → references/01-frameworks-and-scope.md
3. Is it MDSW? — does the software diagnose/treat/monitor/predict? That decides whether MDR applies and at what risk class (a regulatory call, not a code check).
4. Gate bar — default blocks on blocking only; add major for a release/ audit-readiness bar.

Workflow

Load each reference when you reach its step.

1. Set frameworks & scope; internalize the honest scope. Confirm which of the four apply, whether the software is MDSW, and that a green scan ≠ compliance. → references/01-frameworks-and-scope.md

2. Review the control catalog. 47 controls grouped by framework; ~29 are automated heuristics, the rest are manual attestations. → references/02-control-catalog.md

3. Configure and run the scan over the target repo; triage by severity. → references/03-running-the-scan.md

   cp scripts/compliance.config.example.json scripts/compliance.config.json   # edit targetDir, frameworks, gateSeverities, ignore
   python3 scripts/compliance_scan.py --config scripts/compliance.config.json
   echo "exit code: $?"     # 0 = gate green, 1 = blocking failure(s)
   

4. Fix root causes — secrets out of source, PII out of logs, encryption/TLS/ RBAC/audit/retention config present, EU residency, ML artifacts (model card, lineage, SBOM, pinning). Re-scan after each fix. → references/05-remediation-patterns.md

5. Re-scan until green — RESULT: PASS and exit 0 on your chosen gateSeverities. A green run is necessary, not sufficient. → references/03-running-the-scan.md

6. Draft the evidence the audit needs — Records of Processing, a DPIA, and the ISO/SOC 2 evidence index. → references/04-evidence-and-dpia.md

7. Complete the manual attestation — DPIA, DPAs, ISO 14971 risk file, clinical evaluation, QMS, access reviews, incident response, vendor management — reviewed and signed by the right humans. → references/06-manual-attestation.md

What's in this skill

• scripts/compliance_scan.py — the gate backbone: stdlib-only scanner that runs every automated heuristic over targetDir, maps findings to control + framework + severity, writes report.json + report.md, prints PASS/FAIL, and exits non-zero on blocking failures. Lists manual controls for attestation.
• scripts/controls.json — the 47-control catalog (GDPR / MDR / ISO 27001 / SOC 2), each {id, title, frameworks, severity, check, heuristic?, remediation}.
• scripts/compliance.config.example.json — targetDir, frameworks, gateSeverities, ignore globs, outDir.
• scripts/requirements.txt — intentionally dependency-free; the scan is standard-library Python 3.12.
• references/01–06 — frameworks & honest scope, the control catalog, running/triaging the scan, evidence/RoPA/DPIA, remediation patterns, and the manual attestation with a sign-off record.

Definition of done

• compliance_scan.py reports 0 blocking automated controls on the chosen gateSeverities, and exits 0, across the in-scope frameworks.
• Every automated failure was fixed at the cause (not silenced); evidence lines were checked, and any ignore/scope exclusion has a written reason.
• major/minor findings triaged into a backlog before external audit.
• RoPA drafted; DPIA drafted and DPO-reviewed; ISO/SOC 2 evidence index started.
• Every check:"manual" control attested by the right human, recorded in the sign-off block.
• Report archived (CI artifact); result stated as "0 blocking automated controls; manual attestation complete" — not "compliant."

Guardrails — avoid these mistakes

• Don't claim "compliant" from a green scan. Overclaiming is the cardinal error here. State "0 blocking automated controls; manual attestation pending/complete." Compliance/certification requires external auditors, a Notified Body, and legal review — not this gate.
• A pass is a non-detection, not a guarantee. Heuristics miss things (false negatives) and flag innocents (false positives). Verify the cited evidence; the manual controls exist precisely because automation can't decide them.
• Don't game the gate — an empty MODEL_CARD.md or a .gitignore line isn't evidence of a real control. Auditors see through evidence theatre.
• Don't widen gateSeverities or over-broaden ignore to go green. Fix the cause; reserve scoping for genuine non-applicability, with a reason.
• MDR is about intended purpose, not tech. If the software diagnoses/treats/ predicts, it's likely MDSW — get regulatory/clinical input early; this gate only checks engineering artifacts exist.
• Never put real patient data in the repo — fixtures, seeds, and notebooks use synthetic data only; rotate any secret that was ever committed.