By NeuralMedic GmbH · Ingolstadt, Germany · Version 1.0 · 2026

Why this checklist exists

If you're building AI or data systems that touch patient data, biometric data, or any other special category of personal data under GDPR Art. 9, three regulatory regimes apply to you at the same time:

GDPR — for personal data, always
MDR (Medical Device Regulation 2017/745) — if your software classifies as a medical device
EU AI Act — fully applicable to high-risk medical AI systems from 2 August 2027

Most of the architectures we audit fail at least one of these on the first pass. Not because the engineering is bad — because the compliance requirements weren't translated into specific architectural and operational controls early enough.

This checklist is what we run, internally, before any healthcare-grade system we build is allowed to go to production. We're publishing it because every team building in this space deserves access to the same operational rigour, regardless of whether they hire us.

How to use it:

For each control, mark Pass, Fail, or N/A. Each control includes (a) the question, (b) why it matters, (c) what "good" looks like, (d) the most common way teams fail.

If you have more than 3 Fail marks in any single section, your system isn't ready for a regulated production environment yet. That's not a value judgement — it's a stage marker.

A clean version of this checklist (as a printable PDF and as a fillable Notion template) is available on request: info@neuralmedic.de.

Section 1 — GDPR / DSGVO (17 controls)

GDPR applies to all personal data processing in the EU, regardless of MDR status. For medical AI systems handling patient data, GDPR Art. 9 (special categories) raises the bar — you need an explicit legal basis beyond consent in most cases.

1.1 Legal basis for processing documented per data flow

Question: For every data flow into your system, is the GDPR Art. 6 and Art. 9 legal basis documented in writing?

Why it matters: Under GDPR Art. 5(2), you must be able to demonstrate compliance. "We have consent" is not enough — auditors expect to see which legal basis applies to each processing activity.

What good looks like: A records-of-processing register (RoPA) per Art. 30 that names each dataset, source, purpose, Art. 6 basis, and Art. 9 basis (where applicable).

Common failure: A single blanket legal basis claimed for "all patient data," with no per-purpose breakdown.

1.2 Data Protection Impact Assessment (DPIA) completed

Question: Has a DPIA been completed and documented for high-risk processing (which any AI on patient data almost certainly is)?

Why it matters: GDPR Art. 35 requires a DPIA when processing is likely to result in high risk. Automated decision-making on health data is explicitly named in the WP29/EDPB guidance as a trigger.

What good looks like: Signed DPIA with risk assessment, mitigation measures, residual risk, and DPO sign-off (or consultation with the supervisory authority where residual risk is high).

Common failure: DPIA started but never formally signed off; or skipped because "the legal team will handle it later."

1.3 Pseudonymisation at the system boundary

Question: Are direct identifiers stripped or pseudonymised at the entry point of your ML pipeline, before training data hits the model environment?

Why it matters: GDPR Art. 25 (Data Protection by Design) requires technical measures appropriate to the risk. Pseudonymisation at the boundary minimises the surface area where re-identification is possible.

What good looks like: A documented pseudonymisation layer at ingest. The mapping table (pseudonym ↔ real ID) lives in a separate system with separate IAM credentials. The ML training environment never sees direct identifiers.

Common failure: Patient IDs flow through to the ML environment "for joining purposes," with a vague promise to "anonymise the model outputs."

1.4 Pseudonymisation key isolation

Question: Is the pseudonymisation key stored in a system with a different IAM boundary than the data it pseudonymises?

Why it matters: If the key and the pseudonymised data sit under the same access boundary, you've achieved nothing — anyone with access can re-identify.

What good looks like: Key in a dedicated KMS / HSM in a separate AWS account / Azure subscription / GCP project. Key access requires a different role than data access. Key access logged separately.

Common failure: Key and data both in the same S3 bucket / same database — different folders, but the same IAM principal can read both.

1.5 Data residency in EU regions only

Question: Is all personal data — including derived data, embeddings, model artifacts trained on personal data, and logs — guaranteed to remain in EU regions?

Why it matters: Chapter V of GDPR governs international transfers. Post-Schrems II, US transfers require Standard Contractual Clauses plus supplementary measures, which is hard to defend for healthcare data.

What good looks like: All compute, storage, backups, logs, and replicas explicitly in EU regions (eu-central-1, eu-west-1, europe-west3, etc.). Documented architecture diagram showing data residency boundaries.

Common failure: Application logs default to us-east-1; CloudWatch metrics aggregate in a US region; backup replication "for redundancy" crosses regions.

1.6 Cross-region data flows audited and documented

Question: Have you actively audited for hidden cross-region data flows (logging services, monitoring tools, third-party SaaS integrations)?

Why it matters: Default configurations on AWS, Azure, GCP, and observability tools routinely send logs and metrics to non-EU regions. Without an explicit audit, you have probably already breached residency.

What good looks like: A network flow diagram showing every cross-region data flow, with each flow classified by whether it contains personal data. Personal data flows blocked or contractually covered.

Common failure: The team believes data is "all in EU" because the application runs in eu-central-1, but Datadog/Sentry/New Relic/CloudWatch is shipping logs containing PII to the US.

1.7 Personal data NOT in application logs

Question: Have you actively verified that application logs (web logs, ORM-generated SQL logs, error stack traces) do not contain personal data?

Why it matters: This is the single most common GDPR breach we find in audits. Logs are personal data when they contain personal data — and then their retention, access controls, and residency rules must follow GDPR.

What good looks like: Logging library configured with PII filters; structured logs schema reviewed; production logs sampled and inspected; team trained to use IDs not names in error messages.

Common failure: Stack traces from form validation errors contain patient names and emails because the validation library echoes the input.

1.8 Data Processing Agreement (DPA) with every processor

Question: Is there a signed DPA (per GDPR Art. 28) with every external party that processes personal data on your behalf — including cloud providers, SaaS tools, and contractors?

Why it matters: Art. 28 is non-negotiable. Without a DPA, you are unlawfully processing data through that processor.

What good looks like: Centralised DPA register; each agreement reviewed against the processor's standard terms; sub-processor list checked against the agreed list.

Common failure: DPA with the cloud provider exists, but Sentry, Mixpanel, Cal.com, HubSpot, and the AI vendor have no DPA in place. Or the DPA exists but the sub-processor list was not reviewed and it includes US entities for which no Standard Contractual Clauses were signed.

1.9 Sub-processor list reviewed and approved

Question: Have you reviewed the sub-processor list of every primary processor (especially cloud providers) and accepted only those that meet your standards?

Why it matters: Article 28(2) requires you to authorise sub-processors. Most teams click through cloud DPAs without checking which downstream parties are involved.

What good looks like: A documented review of each sub-processor; non-EU sub-processors either removed, isolated, or covered by valid transfer mechanisms.

Common failure: Provider's sub-processor page contains 40 entities including US analytics tools you've never heard of. No active acceptance documented.

1.10 Right of access (Art. 15) operational and tested

Question: Can you respond to a Subject Access Request within 30 days, with all personal data including data in ML training sets, model embeddings, and backups?

Why it matters: GDPR Art. 12 requires response within one month. ML systems make this hard because training data may have been processed into a form that doesn't trivially expose which individual contributed which signal.

What good looks like: A documented and tested process. Test it with a fake subject access request once a quarter.

Common failure: "We'd query the database" — but nobody has actually done it for a real patient with data in three different systems plus a model trained months ago.

1.11 Right to erasure (Art. 17) operational for ML artifacts

Question: Can you erase a specific individual's data from ML training sets, model checkpoints, and embeddings? If the model has already been trained on their data, what's the plan?

Why it matters: Right to erasure applies to all personal data processing. Models trained on personal data may "remember" individuals in extractable ways (membership inference).

What good looks like: Training data versioned with per-individual identification; retraining process documented for erasure requests; model retention policy aligned with subject rights.

Common failure: "The model has already been trained, we can't un-train it." This is not a defence.

1.12 Consent (where used as basis) is specific, informed, granular, and revocable

Question: Where consent is your legal basis, is it specific to each purpose, informed, granular, freely given, and easily revocable?

Why it matters: GDPR sets a high bar for valid consent. "By using this service you consent to AI processing" is invalid consent.

What good looks like: Per-purpose checkboxes; plain-language consent text; in-app revocation that propagates to ML systems; consent log with timestamp + version of consent text shown.

Common failure: Single global consent checkbox at signup with no granular purpose disclosure.

1.13 Data retention periods defined and enforced

Question: Is there a documented retention period for every dataset, and is it technically enforced (not just policy)?

Why it matters: Storage limitation (Art. 5(1)(e)) requires deletion when the purpose is fulfilled. "We'll keep it for a while" is not lawful.

What good looks like: Lifecycle policies on storage (S3 lifecycle, BigQuery table expiration); scheduled deletion jobs; audit log showing actual deletions.

Common failure: Retention is in a policy document. No technical enforcement. Data from 2019 still sits in production storage.

1.14 Encryption in transit (TLS 1.2+ everywhere)

Question: Is every data flow encrypted in transit using TLS 1.2 or higher, including internal service-to-service traffic?

Why it matters: GDPR Art. 32 requires appropriate technical measures. TLS is table stakes.

What good looks like: TLS termination at the edge AND service-to-service TLS (mTLS for sensitive flows). No HTTP endpoints in production. Cipher suites restricted to current standards.

Common failure: Public-facing TLS is fine, but internal traffic between services is plain HTTP because "it's behind the firewall."

1.15 Encryption at rest with customer-managed keys (CMK)

Question: Is personal data encrypted at rest with keys that you control (not just the cloud provider's default keys)?

Why it matters: Provider-managed keys are encryption. CMK is encryption + your control over key access. For healthcare, the latter is a meaningful additional safeguard.

What good looks like: AWS KMS / Azure Key Vault / Google Cloud KMS with customer-managed keys; key rotation policy; key access logged separately.

Common failure: Default provider encryption only. No CMK in use. Key rotation never tested.

1.16 Privacy by Default in every new feature

Question: Does every new feature go through a privacy review that defaults to minimum data collection and minimum access?

Why it matters: GDPR Art. 25 requires Privacy by Default. New features routinely add data collection that wasn't reviewed.

What good looks like: PR template includes a privacy checklist; product reviews include a privacy section; default settings minimise data.

Common failure: Privacy review happens once at architecture, never again. New endpoints log everything by default.

1.17 Breach notification process tested

Question: Is your breach notification process documented and tested, with the 72-hour clock from awareness to supervisory authority notification understood?

Why it matters: Art. 33 mandates 72-hour notification for most breaches. Most teams have never run this drill.

What good looks like: Documented IR runbook; on-call has the supervisory authority contact info; tabletop exercise run once per year.

Common failure: "We'll figure it out if it happens" — by which point the 72-hour clock has already expired.

Section 2 — Medical Device Regulation (MDR) (10 controls)

MDR applies to software classified as a medical device. AI-based diagnostic, screening, or treatment-support tools are typically Class IIa or higher. If you're not sure whether your software is a medical device, that itself is a fail — get the classification opinion in writing.

2.1 Medical device classification documented

Question: Is your software's MDR classification (Class I, IIa, IIb, III) documented in writing, with rationale?

Why it matters: Classification determines the conformity assessment pathway. Wrong classification = wrong assessment = unlawful CE marking.

What good looks like: Written classification opinion (internal or from a regulatory consultancy); reviewed against MDR Annex VIII rules; updated when intended purpose changes.

Common failure: "We think we're Class I" with no written rationale.

2.2 Intended purpose statement is precise and stable

Question: Is there a single, precise, written intended purpose statement that everyone in product/engineering/clinical understands and follows?

Why it matters: The intended purpose drives classification, clinical evaluation, and risk management. Drift here breaks everything downstream.

What good looks like: A 1–3 sentence intended purpose; reviewed by clinical, regulatory, and product; locked in the technical file; version-controlled.

Common failure: Marketing claims drift beyond the intended purpose. The website says "diagnoses X" but the cleared intended purpose is "assists in screening for X." Now you're marketing an unapproved indication.

2.3 Quality Management System (QMS) compliant to ISO 13485

Question: Do you operate a QMS that meets ISO 13485, including documented procedures for design control, document control, CAPA, supplier management, and post-market surveillance?

Why it matters: MDR Art. 10(9) requires a QMS. ISO 13485 is the de facto standard. Without it, you cannot CE-mark.

What good looks like: Certified ISO 13485 QMS (for Class IIa and above), or for smaller teams, a documented QMS aligned to ISO 13485 with internal audits.

Common failure: QMS is a folder of PDFs nobody reads. No internal audits. CAPA process exists in name only.

2.4 Risk Management File per ISO 14971

Question: Is there a Risk Management File documenting hazards, harms, risk estimation, risk control measures, and residual risk?

Why it matters: MDR Annex I (General Safety and Performance Requirements) requires risk management throughout the lifecycle. ISO 14971 is the harmonised standard.

What good looks like: Living Risk Management File; hazard analysis specific to AI failure modes (data drift, adversarial inputs, edge cases); residual risk accepted by management in writing.

Common failure: Risk Management File written once for the conformity assessment, never updated as the model evolves.

2.5 Clinical evaluation supports the intended purpose

Question: Is the clinical evaluation up to date, and does it support the current intended purpose (not an older version)?

Why it matters: MDR Art. 61 + Annex XIV require clinical evidence demonstrating the software meets its intended purpose. AI tools need performance studies on populations representative of the intended use.

What good looks like: Clinical Evaluation Report (CER) with peer-reviewed studies or internal performance studies; statistical methodology defensible; ongoing post-market clinical follow-up (PMCF) plan in place.

Common failure: CER cites studies done on a different model version, or on a population not representative of the deployment population.

2.6 Software bill of materials and lifecycle per IEC 62304

Question: Is the software developed and maintained according to IEC 62304 (medical device software lifecycle), with documented Software Safety Class?

Why it matters: Harmonised standard for medical device software. CE marking under MDR effectively requires it for software medical devices.

What good looks like: Software safety class assigned (A/B/C); SOUP (Software of Unknown Provenance) inventory; lifecycle artifacts (architecture, detailed design, unit tests, integration tests, system tests) versioned.

Common failure: No SOUP inventory; open-source dependencies not tracked; safety class not assigned.

2.7 Audit trail on every production inference

Question: For every inference run in production, is there an immutable audit log capturing: model version (SHA), input hash, output, timestamp, and reviewer identity?

Why it matters: MDR requires traceability and post-market surveillance. EU AI Act Art. 12 explicitly requires logging for high-risk AI systems. Without per-inference logging, you can't investigate incidents.

What good looks like: Inference results written to an append-only log (object storage with versioning + object lock, or a dedicated logging service); model version tied to a specific commit + container SHA; logs retained for the regulatory retention period (typically 10+ years for medical devices).

Common failure: Inferences logged but model version is "v1" — not a SHA. Or logs are mutable. Or logs are deleted after 90 days because nobody set the retention policy.

2.8 Model version control with regulatory snapshot

Question: For every deployed model version, is there a regulatory snapshot containing: training data manifest, training code commit, hyperparameters, validation results, and approval signature?

Why it matters: When the auditor asks "show me the validation that justifies the model running in production today," you need to produce it.

What good looks like: Model registry where each registered version includes all artifacts; documented sign-off process; production deployment locked to registered versions only.

Common failure: Model registry exists, but training data manifest is missing. Or registry is operational, but production can pull from any version.

2.9 Post-Market Surveillance (PMS) operational

Question: Is there an operational PMS system that monitors real-world performance and reports findings annually (Class I/IIa) or biennially with PSUR (Class IIb/III)?

Why it matters: MDR Art. 83–86 mandates PMS. Failure to operate PMS is a common cause of regulatory enforcement.

What good looks like: Monitoring dashboards measuring real-world performance vs. claims; complaint handling process; trend analysis; annual PMS report + PSUR where applicable.

Common failure: PMS plan exists on paper. No actual monitoring of model performance in production. No complaint pathway documented.

2.10 Notified Body engaged for Class IIa+ (where applicable)

Question: For Class IIa and above, has a Notified Body been engaged and the conformity assessment completed?

Why it matters: You cannot legally place a Class IIa+ device on the EU market without conformity assessment by a Notified Body.

What good looks like: Notified Body contract in place; conformity assessment scheduled or completed; CE certificate valid.

Common failure: "We'll engage a Notified Body later" — but the product is already in beta with real patients.

Section 3 — ISO 27001 alignment (10 controls)

We use ISO 27001 as our information security baseline. Full certification is overkill for many teams; documented alignment is the more realistic target.

3.1 Information Security Management System (ISMS) scoped and documented

Question: Is the scope of your ISMS defined, with assets, processes, and interfaces identified?

Why it matters: ISO 27001 starts with scope. Without a defined scope, controls have no anchor.

What good looks like: A scope statement that names systems, locations, business functions, and excluded items.

Common failure: "Our security policy covers everything" — vague scope, no specifics.

3.2 Risk assessment and treatment plan in place

Question: Have you conducted a documented information security risk assessment with risk treatment decisions?

Why it matters: Clause 6.1 of ISO 27001 requires risk-based controls.

What good looks like: Risk register; risk owners; treatment options (mitigate, accept, transfer, avoid); reviewed at least annually.

Common failure: Risk register hasn't been updated in 18 months. Owners have left the company.

3.3 Access control: least privilege enforced

Question: Does every production system enforce least-privilege access, with no shared accounts and no standing admin privileges?

Why it matters: Annex A controls A.5.15, A.5.18 require this.

What good looks like: Role-based access; just-in-time privileged access (JIT) for admin operations; access reviewed quarterly.

Common failure: "Admin" role granted broadly because it was easier than configuring fine-grained access.

3.4 Multi-factor authentication on every privileged access

Question: Is MFA enforced on all privileged access — cloud consoles, code repositories, secret stores, production databases?

Why it matters: Credential theft is the most common breach vector. MFA closes most of it.

What good looks like: Hardware MFA (YubiKey) for privileged ops; phishing-resistant MFA enforced via IdP policy; no SMS as fallback.

Common failure: MFA on the front door but not on the database; or SMS fallback that defeats the protection.

3.5 Secrets management out of source code and logs

Question: Are all secrets (API keys, database credentials, certificates) stored in a dedicated secrets manager, with no secrets in source code, environment variable dumps, or logs?

Why it matters: Annex A.8.24; also a routine reality of GitHub leaks.

What good looks like: Secrets in AWS Secrets Manager / Azure Key Vault / HashiCorp Vault; secret scanning enabled on Git repos; CI/CD pipelines use ephemeral credentials.

Common failure: Secrets in .env files committed to private repos. Or secret-rotation never tested.

3.6 Endpoint protection on engineering workstations

Question: Do all engineering workstations have endpoint protection (EDR), disk encryption, and centralised management?

Why it matters: Annex A.8.1.

What good looks like: MDM enrolment; full-disk encryption; EDR (CrowdStrike / SentinelOne / similar); patch enforcement.

Common failure: BYOD engineers with personal laptops accessing production. No EDR. No central visibility.

3.7 Network segmentation between environments

Question: Are production, staging, and development environments network-isolated, with no shared databases or shared secrets?

Why it matters: Annex A.8.22.

What good looks like: Separate VPCs / subscriptions / projects per environment; no flat network; cross-environment traffic requires explicit firewall rules.

Common failure: "Dev can read prod for debugging." This is a finding.

3.8 Logging and monitoring with retention

Question: Is security-relevant activity (authentication, access changes, configuration changes) logged centrally with adequate retention?

Why it matters: Annex A.8.15. Also required for incident investigation.

What good looks like: SIEM or centralised log store; alerts on anomalies; log retention ≥ 1 year (longer for regulated industries).

Common failure: Logs exist per-service but no central correlation. Or retention is 30 days.

3.9 Vulnerability management and patching

Question: Is there an operational vulnerability management process with documented SLAs by severity?

Why it matters: Annex A.8.8.

What good looks like: Container image scanning in CI/CD; dependency scanning (Dependabot / Snyk); critical CVE patched within 7 days; documented exceptions.

Common failure: Container images last scanned 6 months ago. No SLA. Critical CVE open for 4 months.

3.10 Incident response runbook tested

Question: Is there a documented incident response process, and has it been tabletop-tested in the last 12 months?

Why it matters: Annex A.5.24.

What good looks like: IR runbook covering detection, triage, containment, eradication, recovery, post-mortem; named roles; communication tree; tested annually with a tabletop exercise.

Common failure: Runbook exists, never tested. Senior engineer who wrote it has left.

Section 4 — SOC 2 alignment (10 controls)

SOC 2 is North American-leaning but widely requested by enterprise buyers. We track the Trust Services Criteria: Security (always), Availability (usually), Processing Integrity (if ML inferences matter), Confidentiality (always for health data), Privacy (always).

4.1 Documented information security policy approved by management

Question: Is there an information security policy, approved by management, communicated to all staff, and reviewed annually?

Why it matters: CC1.x — entity-level controls. Auditors will ask.

What good looks like: Policy document, current within 12 months; staff acknowledgement on hire and annually; management sign-off.

Common failure: Policy from 2 years ago that no current staff have read.

4.2 Change management process with approvals

Question: Are production changes subject to peer review and approval before deployment?

Why it matters: CC8.x — change management.

What good looks like: All production changes via PR with required reviewer; deployment audit logs; emergency change process for break-glass cases.

Common failure: Senior engineers can push directly to main. Audit trail incomplete.

4.3 Vendor management with security review

Question: Are new vendors evaluated for security posture before onboarding?

Why it matters: Supply chain is a routine breach vector. Auditors expect formal evaluation.

What good looks like: Vendor inventory; security questionnaire (or SOC 2 / ISO 27001 cert review) before onboarding; reviewed annually.

Common failure: Tools onboarded without security review. Trial signups become production dependencies.

4.4 Backup and restore tested

Question: Are backups tested by performing real restores at least annually, and is the result documented?

Why it matters: A backup you've never restored is not a backup.

What good looks like: Documented test restores; RTO and RPO measured against requirements; restored data integrity verified.

Common failure: Backups run nightly. No restore has ever been attempted.

4.5 Business continuity and disaster recovery plan

Question: Is there a documented BC/DR plan with defined RTO and RPO, and has it been tested?

Why it matters: Availability criterion.

What good looks like: BC/DR plan; RTO/RPO per business service; failover tested at least annually.

Common failure: "We use AWS multi-AZ" — and that's the entire plan.

4.6 Service-level monitoring with customer-facing SLAs

Question: Is service availability monitored with metrics that match your SLA commitments, and are SLA breaches reported to customers per contract?

Why it matters: Availability criterion. Also commercial obligation.

What good looks like: Public status page; uptime monitoring; SLA breach process; credits issued where contractually required.

Common failure: SLA in the contract. No measurement of whether you actually meet it.

4.7 Onboarding and offboarding access control

Question: Is there a documented process to provision access on hire and de-provision access within 24 hours of departure?

Why it matters: Departed staff retaining access is one of the most common audit findings.

What good looks like: HR-triggered offboarding checklist; cloud accounts, SSO, secrets, on-call all revoked within 24 hours; documented.

Common failure: Engineer left 6 months ago. Their GitHub access is still active.

4.8 Background checks for staff with privileged access

Question: Are background checks performed for staff with production access, where lawful and proportionate?

Why it matters: SOC 2 expects basic personnel security. Local labour law matters — in Germany, scope is more constrained than in the US.

What good looks like: Documented background check policy; criminal record check (Führungszeugnis) where the role justifies it; consistent application.

Common failure: Some hires checked, others not. No policy.

4.9 Security awareness training annually

Question: Do all staff complete security awareness training on hire and annually?

Why it matters: Human risk is the largest residual risk in most environments.

What good looks like: Training platform (or internal sessions); completion tracked; phishing simulations periodically.

Common failure: Training was done once on hire, never repeated. No tracking.

4.10 Customer commitments tracked against actuals

Question: Where your service commitments include processing integrity guarantees (e.g., "inference results are reproducible from input + model version"), are those commitments measured and reported?

Why it matters: Processing Integrity criterion. For ML services this is unique terrain — your "correct output" is statistical, not deterministic.

What good looks like: Documented processing integrity claim; measurement framework; deviation reporting.

Common failure: Customer contract says "AI-powered insights" with vague accuracy claims. No measurement of whether those claims hold.

Quick-reference matrix

Section	# Controls	Hardest controls (top failures)
GDPR / DSGVO	17	1.4 (key isolation), 1.6 (hidden cross-region flows), 1.7 (PII in logs), 1.11 (erasure from models)
MDR	10	2.7 (per-inference audit trail), 2.8 (regulatory snapshot per model version), 2.9 (operational PMS)
ISO 27001 alignment	10	3.7 (network segmentation), 3.9 (vulnerability SLAs), 3.10 (tested IR)
SOC 2 alignment	10	4.4 (tested backups), 4.7 (offboarding), 4.10 (processing integrity for ML)
Total	47

About NeuralMedic

NeuralMedic GmbH builds production-grade data and AI platforms for the German Mittelstand, with particular experience in healthcare-regulated environments. We use this checklist internally before every go-live. If you'd like a structured audit of your own system against these controls, that's the Data & AI Readiness Audit (3 weeks, from €15,000, fixed-price).

More information:

Website: https://neuralmedic.de
Book a 30-min review: https://cal.com/neuralmedic/audit-call
Email: info@neuralmedic.de

Disclaimer: This checklist is provided for operational guidance and does not constitute legal advice. Compliance with GDPR, MDR, the EU AI Act, ISO 27001, and SOC 2 depends on the specifics of your processing, jurisdiction, and intended purpose. Consult qualified legal and regulatory counsel for binding determinations.

Version 1.0 · 2026-05-27 · © NeuralMedic GmbH. You may freely share this document. You may not modify it and republish under your own brand.