Healthcare Software CVD Policy Template (Non-MDR)

[COMPANY NAME] develops and maintains [DESCRIPTION OF PRODUCTS, e.g. electronic health record (EHR) software, clinical workflow management systems, health and wellness applications]. Our products are used by [HEALTHCARE ORGANISATIONS / CLINICIANS / PATIENTS] in [COUNTRIES / REGIONS].

This Coordinated Vulnerability Disclosure (CVD) Policy governs how [COMPANY NAME] receives, assesses, and responds to reports of security vulnerabilities in our products.

Regulatory context: [COMPANY NAME]'s products are software products with digital elements and are subject to the EU Cyber Resilience Act (Regulation (EU) 2024/2847). Our products are [not classified as medical devices under Regulation (EU) 2017/745 (MDR) / general-purpose wellness/clinical information products not meeting the MDR definition of a medical device], and therefore fall within full CRA scope.

This policy is published in compliance with CRA Article 13 and reflects our commitment to ISO/IEC 29147.

Given the healthcare context of our products, we treat vulnerability reports involving patient safety, clinical workflow disruption, or protected health information with the highest priority.

This policy covers the following [COMPANY NAME] products:

| Product | Description | Deployed At | |---------|-------------|-------------| | [PRODUCT 1] | [e.g. Clinical scheduling and patient management software] | [Hospital systems, clinics] | | [PRODUCT 2] | [e.g. Health and wellness mobile application] | [Consumer devices (iOS, Android)] | | [PRODUCT 3] | [e.g. Clinical data integration platform] | [Hospital IT infrastructure] |

Associated cloud services: [CLOUD SERVICE ENDPOINTS] Mobile applications: [APP NAMES AND PLATFORMS]

Data categories processed: Our products may process the following categories of data relevant to vulnerability impact assessment:

• [Patient identifiers and demographic data]
• [Clinical notes, diagnoses, and treatment records]
• [Appointment and scheduling data]
• [Health and wellness metrics (non-clinical)]
• [Healthcare organisation staff credentials]

Not covered by this policy:

• Products at end-of-life (see [SUPPORT PAGE URL])
• Vulnerabilities in hospital IT infrastructure not provided by [COMPANY NAME]
• Physical access vulnerabilities to hardware not under [COMPANY NAME]'s control
• Vulnerabilities in third-party integrations (EHR systems, medical device interfaces) — report these to the relevant vendor

To report a security vulnerability in any [COMPANY NAME] product, please use:

Preferred: Submit via our vulnerability disclosure portal: [PORTAL URL]

Email: [[email protected]] PGP encryption strongly recommended for reports involving patient data: Key fingerprint: [FINGERPRINT] | Key available at: [KEY URL]

security.txt: https://[YOUR-DOMAIN]/.well-known/security.txt

For vulnerability reports involving potential patient safety risk or active exploitation, please mark your report as URGENT and contact us additionally by telephone at [EMERGENCY SECURITY CONTACT NUMBER] during business hours.

Please include in your report:

• Affected product name and version
• A description of the vulnerability and its potential impact
• Whether you believe patient data may have been accessed or at risk
• Whether you believe clinical workflow could be disrupted by exploitation
• Steps to reproduce
• Whether the vulnerability is already being exploited or publicly known

We accept reports in [LANGUAGE(S)]. Reports are treated as confidential and handled by our security team. Due to the sensitivity of healthcare data, report contents are not shared with product management or commercial teams without the security team's approval.

[COMPANY NAME] uses CVSS 4.0 as the primary severity scoring system. For healthcare software, we additionally assess the following clinical impact factors:

Patient Safety Impact

Vulnerabilities that could directly or indirectly cause harm to patients are treated as Critical regardless of their CVSS base score. Indicators of patient safety impact include:

• Ability to alter, corrupt, or delete clinical records without detection
• Ability to intercept or modify clinical data in transit
• Ability to disrupt or delay access to medication administration or treatment records
• Vulnerability in an integration with a medical device or clinical decision support system

Clinical Workflow Disruption

Vulnerabilities enabling denial-of-service or significant unavailability of [COMPANY NAME] systems in a clinical setting are elevated by one severity band due to the operational dependencies of healthcare organisations.

Protected Health Information (PHI) Exposure

Vulnerabilities enabling unauthorised access to patient health records, diagnoses, or treatment data are treated as High or Critical due to the Article 9 GDPR special category data classification of health data.

Triage SLA for Healthcare Contexts

| Severity | Triage Target | Patch Target | |----------|---------------|--------------| | Critical (incl. patient safety) | [1] business day | [15] calendar days | | High | [3] business days | [30] calendar days | | Medium | [5] business days | [60] calendar days | | Low | [10] business days | [90] calendar days |

[COMPANY NAME] commits to the following response milestones for all vulnerability reports:

| Milestone | Commitment | |-----------|------------| | Acknowledgment | Within 48 hours of receipt | | Eligibility determination | Within [3] business days | | Severity assessment shared with reporter | Within [5] business days | | Status update (if patch not yet available) | Every [21] days for Critical/High, every [30] days for Medium/Low | | Patch or documented workaround | See triage SLA table above | | Security advisory | Published upon or after patch availability | | GDPR breach notification (if applicable) | Within 72 hours to [DPA / ICO / CNIL] if a personal data breach is confirmed |

Co-ordinating with affected healthcare organisations:

Where a vulnerability affects [COMPANY NAME] software deployed at specific healthcare organisations, we will notify the affected organisations' IT security contacts under confidentiality obligations [X] days before public advisory publication. We will not name specific organisations in public advisories.

[COMPANY NAME] recognises that healthcare organisations operate strict change control and clinical system availability requirements that affect how security patches are deployed in hospital environments.

Pre-notification for Critical patches:

For Critical severity patches, [COMPANY NAME] will provide deployed healthcare organisations with a minimum of [5] business days advance notice before patch release, under embargo, to allow them to prepare for update deployment without being surprised by a public advisory.

Emergency patch support:

For Critical vulnerabilities under active exploitation, [COMPANY NAME] will provide:

• Interim mitigation measures for healthcare organisations that cannot immediately apply a patch
• Dedicated technical support contact during the patch deployment window
• A documented rollback procedure in case the patch causes clinical system issues

Point of contact for healthcare customers:

For healthcare customer IT security teams who need to escalate a security concern outside of our standard public reporting channel, please contact: [DEDICATED HEALTHCARE SECURITY CONTACT EMAIL / PHONE]

Health-ISAC and sector coordination:

[COMPANY NAME] participates in [H-ISAC / relevant sector information sharing body] and will share appropriate threat intelligence with the healthcare sector through that channel where relevant to our products.

Where a vulnerability affecting [COMPANY NAME] products meets the Article 14 threshold — actively exploited or constituting a severe security incident — [COMPANY NAME] will:

1. Submit an early warning to ENISA within 24 hours of becoming aware
2. Submit a full notification to ENISA within 72 hours
3. Submit a final report within 14 days

For healthcare software, Article 14 thresholds are particularly relevant where:

• A vulnerability is actively exploited and puts patient health data at risk
• A vulnerability causes or risks causing disruption to clinical services at healthcare organisations
• A vulnerability enables ransomware-type encryption of clinical systems (constitutes a severe security incident)
• A vulnerability in a PHI-processing component is actively exploited at scale

Interaction with GDPR Article 33:

A confirmed exploitation of a vulnerability resulting in unauthorised access to patient health data constitutes both a potential Article 14 CRA event and a GDPR personal data breach. Where both thresholds are met, [COMPANY NAME] will file:

• Article 14 early warning with ENISA within 24 hours
• Article 33 GDPR breach notification with the relevant supervisory authority within 72 hours

These are separate obligations to separate authorities and will be handled concurrently.

[COMPANY NAME] authorises good-faith security research on [COMPANY NAME] products conducted in accordance with this policy.

We will not take legal action against researchers who:

• Follow this policy
• Test only using accounts and environments they control
• Immediately cease testing and report to us if they encounter patient health data during testing
• Limit their research to confirming the vulnerability exists without accessing more data than strictly necessary
• Report to us before any public or third-party disclosure

Critical healthcare data protection obligation: If you encounter what appears to be real patient health data (names, diagnoses, treatment records) during your research — even inadvertently — you must:

1. Stop accessing the data immediately
2. Note only the minimum information needed to confirm the vulnerability type
3. Inform us immediately in your report that PHI may have been accessible
4. Delete any inadvertently downloaded patient data

Handling of patient health data is subject to healthcare data protection law regardless of whether access was inadvertent. We will not pursue security researchers who handle such situations appropriately and in good faith.

[COMPANY NAME] can provide a dedicated test environment for researchers who require access to realistic clinical data structures without risk of touching production patient data. Contact [[email protected]] to request access.