CRA Compliance Checklist: Hospital IT & Clinical Information Systems
Annex III Class I likely — hospital IT and clinical information systems are important products with digital elements processing sensitive patient data at scale; not excluded by MDR unless classified as SaMD
Hospital IT systems — including electronic health record (EHR) systems, clinical information systems, hospital information systems (HIS), and clinical decision support tools not classified as Software as a Medical Device (SaMD) — are not excluded from the CRA by the MDR carve-out. These systems are critical to patient care, process sensitive patient data at scale, and face sophisticated threat actors. They likely qualify as Annex III Class I products.
1. Scope & Classification
Confirm whether your system is classified as Software as a Medical Device (SaMD) under MDR — if not, full CRA applies
EHR systems, hospital information systems, and most clinical IT are not MDR-classified SaMD unless they perform a medical diagnostic or therapeutic function. Confirm using MDCG 2019-16 qualification criteria.
Assess whether Annex III Class I applies given the scale of patient data processing and critical healthcare infrastructure role
Hospital IT systems managing patient records across an entire hospital or network are important products with significant potential impact. Class I is likely appropriate.
Assess intersection with NIS2 Directive for healthcare sector operators — hospital IT must support their essential entity obligations
Hospitals are NIS2 essential entities. Clinical systems must support the security requirements hospitals need to meet their NIS2 obligations, including incident detection, response, and reporting.
Compile a comprehensive SBOM covering all clinical application software, database components, integration middleware, and third-party libraries
Hospital IT systems are architecturally complex. Include EHR core, HL7/FHIR integration layer, reporting tools, and all third-party components. Track CVEs across all components.
2. Product Security (Annex I Part I)
Implement role-based access control with least privilege for all clinical system roles — clinicians, nurses, administrators, auditors
Clinical staff require access only to patient data relevant to their care responsibilities. Implement granular RBAC with MFA for all access, including emergency break-glass access that is logged.
Encrypt all patient data at rest and in transit — apply encryption to database storage, backups, and API communications
Patient health data is special category under GDPR. Encrypt database storage with AES-256, all inter-system communications with TLS 1.3, and all backups with hardware-managed keys.
Implement comprehensive audit logging of all patient data access, modifications, and exports — logs must be tamper-evident
Healthcare audit logs are required for regulatory compliance (GDPR, national healthcare regulations) and forensic investigation. Logs must be immutable and stored separately from the application.
Apply patch management processes that maintain system integrity while minimising clinical service disruption
Hospital systems operate 24/7 with patient safety implications. Provide patch packages with documented testing procedures, rollback capability, and maintenance window guidance.
3. CVD Policy & Vulnerability Handling
Publish a CVD policy and dedicated security contact for clinical system vulnerabilities
Hospital IT systems are prime ransomware targets. A mature CVD programme helps identify vulnerabilities before attackers exploit them. Engage the health-ISAC for sector threat intelligence.
Define security patching SLAs aligned with clinical operations — critical patches within 30 days, emergency patches on accelerated timeline
Hospital customers need clear patching SLAs to plan maintenance windows. Provide risk-stratified patch timelines with clinical impact assessments for each patch.
Provide CVE IDs and security advisories for all vulnerabilities fixed in software updates
Hospital security teams need CVE IDs to assess risk and plan patching. Ensure all security fixes are accompanied by formal advisories.
4. Article 14 Incident Reporting
Establish telemetry and anomaly detection to identify active exploitation of clinical system vulnerabilities
Ransomware attacks against hospital systems are regularly actively exploited vulnerabilities. Monitoring must identify exploitation at the product level, not just the network level.
Coordinate Article 14 ENISA reporting with customer NIS2 reporting and GDPR breach notification obligations
A clinical system breach simultaneously triggers CRA Article 14 (your obligation), NIS2 incident reporting (hospital's obligation), and GDPR Article 33 (potentially both). Pre-align procedures with major customers.
5. CE Marking & Technical Documentation
Prepare technical file with clinical system security architecture, patient data flow diagrams, SBOM, and penetration test results
Market surveillance authorities and hospital procurement teams will scrutinise clinical system security documentation. Invest in thorough, well-evidenced technical documentation.
Issue EU Declaration of Conformity referencing the CRA before placing software on the EU market
Software products must have a DoC referencing the CRA. For software updates, maintain the DoC and update the technical file to cover new releases.
Track your Hospital IT & Clinical Information Systems compliance progress in CVD Portal.
Public CVD submission portal, Article 14 deadline alerts, SBOM tracking, and CSAF advisory generation. Free forever for manufacturers.
Start your free portalFrequently asked
Our EHR system integrates with medical devices — does the MDR exclusion apply to our system?+
No. Integration with MDR-classified medical devices does not make your EHR system a medical device. The MDR exclusion applies only to the medical device itself. Your EHR system, as general-purpose clinical software, is not MDR-classified and is fully in scope for the CRA. The medical devices connecting to your system remain subject to MDR.
Our clinical system is hosted as a cloud service (SaaS) — does CRA apply to it?+
Purely cloud-based services are generally excluded from CRA scope. However, if you supply on-premises software, hybrid deployments, or software that runs locally at the hospital alongside cloud components, those local components are in scope. Clarify your deployment model carefully. If any executable software runs on hospital premises, it is likely in scope.
Hospitals frequently customise our software — who is responsible for CRA compliance after customisation?+
You, as the manufacturer, are responsible for CRA compliance of the base product. If a hospital makes substantial modifications that change the security characteristics of the product, they may take on manufacturer obligations for the modified version. However, your base product must meet CRA requirements. Provide customisation guidelines that help customers maintain CRA compliance in their configurations.
Need a CVD policy for Hospital IT & Clinical Information Systems?
Download a free CRA-compliant disclosure policy template and deploy it in minutes.