R-TF-030-005 NIS2-Compliant Incident Response Plan

Executive Summary

Purpose and Scope

This Incident Response Plan (IRP) establishes a comprehensive framework for detecting, responding to, and recovering from cybersecurity incidents affecting the Legit.Health Plus medical device software. The plan ensures rapid incident response, regulatory compliance with NIS2 Article 23 notification requirements, and maintains patient safety through coordinated incident management procedures.

The scope includes establishing and maintaining procedures to monitor for cybersecurity threats, assess their impact, and implement timely and appropriate mitigations. Specifically, this plan covers:

• Identifying personnel responsible
• Documenting sources, methods, and frequency for monitoring and identifying vulnerabilities (e.g., researchers, NIST national vulnerability database (NIST NVD), third-party software manufacturers
• Identifying and addressing vulnerabilities identified in CISA Known Exploited Vulnerabilities Catalog
• Performing periodic security testing
• Update processes
• Patching capability (i.e., rate at which update can be delivered to devices)
• Description of how forthcoming remediations, patches, and updates to customers are communicated.

Alignment with NIS2 Article 23 Requirements

This plan specifically addresses the notification obligations under EU Directive 2022/2555 (NIS2), requiring:

• 24-hour early warning to competent authorities (INCIBE-CERT in Spain)
• 72-hour incident notification with detailed incident information
• Monthly progress reports for ongoing incidents
• Final report upon incident resolution

Integration with Medical Device Regulations

This IRP operates in conjunction with:

• EU MDR 2017/745 - Medical Device Regulation incident reporting
• FDA 21 CFR Part 806 - Medical Device Reporting (MDR)
• ISO 14971:2019 - Risk management for medical devices
• IEC 62304:2015 - Medical device software lifecycle processes
• MDCG 2019-16 - Guidance on Cybersecurity for medical devices

Document Control

Version	Date	Author	Description
1.0	2025-08-29	Technical Team	Initial NIS2-compliant incident response plan

Terms and definitions

Terms	Definition/Description
Threat Monitoring	The continuous process of detecting, identifying, and analyzing potential security threats and malicious activities within an organization's systems and networks to ensure timely response and risk mitigation.
Threat	Potential cause of an unwanted incident, which may result in harm to individuals, a system or organization.
Vulnerability	Weaknesses in an information system, security procedures, internal controls, or implementation that could be exploited or triggered by a threat source.
CVSS	The Common Vulnerability Scoring System (CVSS) will be used to rank vulnerabilities and estimate security risk. Each vulnerability will receive a CVSS score to indicate the level of risk.
SBOM	Software Bill of Materials. It is a formal, structured inventory that lists all components, libraries, and dependencies included in a piece of software.
SCA	A security practice that identifies vulnerabilities, license compliance issues, and outdated components in open-source and third-party libraries used within a software project. It helps manage risks associated with external dependencies.
SAST	A security testing technique that scans an application's source code, bytecode, or binary code without executing it. It detects vulnerabilities early in the development process, such as SQL injection or insecure coding practices, by analysing code structure and logic.
DAST	A security testing method that analyses a running application to identify vulnerabilities by simulating real-world attacks. Unlike SAST, it does not require access to the source code and tests applications in their runtime environment, detecting issues like authentication flaws or misconfigurations.
System Hardening	Process of securing a system by reducing its surface of vulnerability. This involves configuring systems, removing unnecessary services, applying patches, and implementing security controls to minimize potential attack vectors.
Development Team	A group responsible for researching, designing, and developing new products or improving existing ones. This team focuses on innovation, product functionality, and aligning solutions with market needs and business goals.
Information Sharing and Analysis Organizations (ISAO)	Groups formed to gather, analyze, and share cybersecurity threat information among members and with other stakeholders. ISAOs aim to enhance collective defense by improving situational awareness and enabling coordinated responses to cyber threats across various sectors or communities.
CAPA System (Corrective and Preventive Action System)	A structured approach used to identify, investigate, and resolve issues or non-conformities within an organization. It focuses on implementing corrective actions to fix existing problems and preventive actions to eliminate the root causes and avoid recurrence, ensuring continuous improvement and compliance.
CISA (Cybersecurity and Infrastructure Security Agency)	A U.S. government agency responsible for enhancing the security, resilience, and reliability of the nation's cybersecurity and infrastructure. CISA leads national efforts to protect against and respond to cyber threats, manage risks, and ensure the safe operation of critical systems and services.
PHI (Protected Health Information)	Any information about health status, provision of healthcare, or payment for healthcare that can be linked to an individual. This includes medical records, billing information, and any other data that can identify a patient.
PII (Personally Identifiable Information)	Any data that can be used to identify a specific individual, such as name, address, social security number, or biometric data. PII is sensitive information that requires protection to prevent identity theft and privacy breaches.

Incident Classification Framework

Security Incident Definitions

A cybersecurity incident is defined as any event that:

• Compromises the Confidentiality, Integrity, Availability, or Authenticity (CIAA) of the device or its data
• Violates security policies or acceptable use policies
• Attempts unauthorized access to systems, data, or networks
• Results in unexpected behavior that could impact patient safety or data protection

Impact Assessment Criteria

Patient Safety Impact

• Critical: Direct patient harm possible
• High: Indirect patient harm possible
• Medium: Delayed or degraded care possible
• Low: No patient impact

Financial impact

• Critical. Estimated loss > 250.000€ (including fines, contract penalties, remediation costs, and business interruption)
• High. 50.000€ - 250.000€
• Medium. 10.000€ – 50.000€
• Low. < 10.000€

Data Impact

Classification:

• Personal Health Information (PHI)
• Personal Identifiable Information (PII)
• Proprietary algorithms/IP
• Authentication credentials

Decision criteria:

• Critical. Any of:
  • PHI: > 1,000 patient records
  • Authentication credentials: any compromise of production credentials, or more than 20 user credentials
  • Proprietary algorithms / model weights / core IP: full or partial exposure
  • PII: > 50,000 records exposed
• High. Any of:
  • PHI: 100-1.000 records
  • Authentication credentials: 1.20 user credentials
  • Proprietary algorithms/IP: metadata exposure, architecture details, or partial leaks that aid reverse engineering
  • PII: 5.000-50.000 records
• Medium. Any of:
  • PHI: 10-100 records
  • Authentication credentials: minor leak of hashed/non-privileged credentials that cannot directly authorize access
  • Proprietary algorithms/IP: internal documentation exposed without model weights
  • PII: 500-5.000 records
• Low. Otherwise, including:
  • PHI: < 10 records
  • Authentication credentials: no credentials leaked
  • Proprietary algorithms/IP: no exposure or purely non-sensitive docs
  • PII: < 500 records
  • Or no personal data involved

System Availability Impact

• Critical: Complete system outage > 2 hours
• High:
  • Complete system outage < 2 hours, or
  • Partial system outage or degradation > 3 hours
• Medium:
  • Partial system outage or degradation < 3 hours, or
  • Limited functionality impact > 4 hours
• Low: No availability impact

Severity Levels

Severity	Definition	Response Time	Examples
Critical	Immediate threat to patient safety or massive data breach	< 1 hour	Ransomware encryption, complete system compromise, patient harm
High	Significant security breach with potential patient impact	< 4 hours	Data exfiltration, authentication bypass, critical vulnerability exploitation
Medium	Security incident with limited impact	< 24 hours	Isolated malware, failed attack attempts, minor data exposure
Low	Minor security event with minimal impact	< 72 hours	Policy violations, unsuccessful scans, low-risk vulnerabilities

NIS2 Significant Incident Criteria

An incident is considered significant under NIS2 if it:

1. Causes or is capable of causing:
   • Substantial operational disruption (> 20% of users affected)
   • Financial loss exceeding €100,000
   • Impact on > 100,000 users in the EU
   • Duration > 24 hours
2. Affects critical healthcare services:
   • Diagnostic capabilities unavailable
   • Patient safety compromised
   • Healthcare delivery disrupted
3. Cross-border impact:
   • Affects users in multiple EU Member States
   • Involves cross-border data flows

Relationship between Severity, Impact Assessment and NIS2 Significance

This section explains how:

• Impact assessment (patient safety, data, availability) feeds into the overall internal severity level.
• Internal severity and impact metrics are used to determine whether an incident is NIS2-significant.

Decision process:

1. For every confirmed incident, the incident response plan must:

   • Rate Patient Safety Impact (Critical / High / Medium / Low)
   • Rate Data Impact
   • Rate System Availability Impact

2. Define the overall severity as:

   • If any dimension is Critical → overall severity = Critical.
   • Else if two or more dimensions are High → overall severity = High.
   • Else if the mayority of dimensions are Medium → overall severity = Medium.
   • Else → Low.

3. Then, evaluate NIS2 significance:

   • If overall severity is Critical, the IRT must always check NIS2 significance and document the decision.
   • Medium/High can be NIS2-significant if thresholds are met (e.g. cross-border, many users, long duration).
   • Low severity incidents are normally non-significant unless they clearly meet a legal threshold (e.g. a small technical glitch that nonetheless affected >100,000 users).

Escalation rules

Escalate to High (and consider IRT activation) if any of the following occur:

• If impact assessment for "Patient Safety Impact" is High.
• Incident affects two or more customers/hospitals, or more than 5 clinical end-users.
• Estimated duration exceeds 2 hours.
• If partial system outage is next to 3 hours or limited functionality impact is more thant 8 hours.

Incident Response Team (IRT)

Team Structure and Roles

Role	Primary Responsibilities	Backup
Quality Manager & PRRC (JD-004)	Collaborate with security teams to prioritize and address vulnerabilities found in the product and ensure timely patches and fixes are implemented. Assist with the investigation and analysis of potential cybersecurity vulnerabilities. Ensure that security patches and updates are tested, validated, and deployed effectively. Maintaining the design history file in conjunction with R&D including cybersecurity testing evidence and post-market cybersecurity process artifacts. Provide regulatory support for cybersecurity vulnerabilities including decisions on whether to report vulnerabilities to regulatory agencies. Provide guidance on the regulatory expectations of cybersecurity across different jurisdictions. Provide regulatory support for cybersecurity vulnerabilities including decisions on whether to report vulnerabilities to regulatory agencies. Provide guidance on the regulatory expectations of cybersecurity across different jurisdictions.	JD-003
Legal Advisor (external)	Monitor the product's compliance with applicable laws, regulations, and industry standards related to product security. Handle product liability issues related to security incidents or breaches. Ensure compliance with privacy and data protection laws. Ensure third-party contracts include appropriate security provisions, such as data protection requirements, security audits, and incident response protocols. Determine the legal obligations for vulnerability reporting and disclosure, both internally and externally. Assess the need for product recalls or other legal notifications due to cybersecurity vulnerabilities.	JD-004
Technology Manager (JD-007)	Evaluation of potential cybersecurity vulnerabilities. Updating this plan based on the latest information obtained through execution. Partnering with the Product R&D team to confirm product applicability of vulnerabilities. Performing cybersecurity risk assessments. Performing and/or monitoring periodic cybersecurity testing in conjunction with Product development, and maintaining the vulnerability disclosure process and mechanisms. Maintaining the post-market cybersecurity management processes and templates.	JD-003
Product development / Incident commander (JD-003)	Evaluation and remediation of any security issues or vulnerabilities that are discovered after the product is released to the market. Managing and distributing security patches or updates to address known vulnerabilities. Collaborating with the quality assurance team to ensure that patches are properly tested, validated, and deployed. Conducting security testing and code reviews to identify and address vulnerabilities. Perform static code analysis (SAST), dynamic application security testing (DAST), vulnerability scanning, and software composition analysis (SCA). Maintaining the design history file in conjunction with Quality including cybersecurity testing evidence and post-market cybersecurity process artifacts.	JD-011
Customer success / Incident response (JD-016)	Serve as the first point of contact for customers experiencing security-related issues or breaches. Collect relevant information about incidents or vulnerabilities, assess their severity, and escalate to security, R&D, or incident response teams for investigation and resolution. Assist customers with applying security patches and updates to their product installations. Provide guidance on patch management processes and ensure customers have access to the latest security updates. Help customers understand the importance of keeping products up to date with security patches to mitigate potential risks. Educate customers on common security risks, best practices, and preventive measures. Provide documentation, user guides, and knowledge base articles addressing security-related topics to help customers enhance product security. Work closely with product marketing and security teams to ensure accurate and timely communication to customers regarding security matters. Collect feedback from customers regarding security-related concerns or suggestions. Document customer feedback, including reports of potential vulnerabilities or security improvements, and escalate them to R&D or security for analysis and action.	JD-003

Contact Information and Escalation Matrix

See Phase 3: Detection and Analysis.

External Stakeholders

Organization	Purpose	Contact Method	Timeframe
INCIBE-CERT	Spanish national CSIRT (NIS2 notification)	incidents@incibe-cert.es	24h/72h per NIS2
CCN-CERT	Spanish government CERT	incidents@ccn-cert.cni.es	As required
AEMPS	Spanish medical device authority	notificaciones.ps@aemps.es	Per MDR timeline
FDA	US medical device authority	Via FDA ESG	Within 30 days
AWS Security	Cloud provider incident support	AWS Support Portal	Immediate for Critical
Customers	Affected healthcare organizations	Via secure channels	Per SLA agreements

NIS2 Notification Requirements

24-Hour Early Warning Procedure

Trigger: Any incident meeting NIS2 significant incident criteria

Required Information:

1. Entity identification (Legit.Health, NIS2 registration number)
2. Initial incident classification
3. Preliminary impact assessment
4. Whether incident is ongoing
5. Cross-border impact indication

Template: See Appendix A - Early Warning Template

Process:

72-Hour Incident Notification Process

Required Information:

1. Detailed incident description
2. Severity and impact assessment
3. Root cause (if known)
4. Affected systems and data categories
5. Number of affected users
6. Geographic spread
7. Incident timeline
8. Mitigation measures implemented
9. Cross-border implications

Template: See Appendix B - 72-Hour Notification Template

Monthly Reporting Requirements

For ongoing incidents exceeding 1 month:

1. Progress update on investigation
2. Mitigation measures effectiveness
3. Updated impact assessment
4. Estimated resolution timeline
5. Additional support needs

Template: See Appendix C - Monthly Progress Report Template

Final Report Requirements

Upon incident closure:

1. Complete incident timeline
2. Root cause analysis
3. Total impact assessment
4. Remediation actions taken
5. Lessons learned
6. Preventive measures implemented

Template: See Appendix D - Final Report Template

Communication Channels with Spanish INCIBE-CERT

Channel	Purpose	Details
Primary Email	Incident notifications	incidents@incibe-cert.es
Secure Portal	Sensitive information	https://www.incibe-cert.es/en
Emergency Phone	Critical incidents	+34 017 (National Cybersecurity Helpline)

Incident Response Phases

Phase 1: Preparation

Objectives

• Maintain readiness for incident response

Activities

1. Tool Preparation
   • Alerting systems configuration
   • Monitoring systems configuration
   • Communication channels testing
2. Documentation Maintenance
   • Contact lists updates
   • Roles and responsibilities review
   • Template updates
3. Preventive Measures
   • Vulnerability management

Phase 2. Threat Monitoring

Objectives

Continuous monitoring for potential threats as described in R-TF-030-001 Cyber Security Risk Management Plan

Phase 3: Detection and Analysis

Objectives

Rapidly identify and assess security incidents

Workflow

Evidence Collection Checklist

• System logs (application, security, access)
• Network traffic captures
• Configuration files
• User activity logs
• Database query logs
• API access logs
• Cloud provider logs

Phase 4: Containment, Eradication, and Recovery

Objectives

Effectively contain, eliminate, and recover from security incidents

Workflow

Containment Strategies

Short-term Containment:

• Isolate affected systems
• Block malicious IPs/domains
• Disable compromised accounts
• Implement emergency patches

Long-term Containment:

• Deploy temporary fixes
• Increase monitoring
• Implement additional controls
• Prepare for eradication

Eradication Activities

1. Remove malicious artifacts
2. Patch vulnerabilities
3. Reset compromised credentials
4. Update security configurations
5. Verify threat elimination

Recovery Procedures

System Restoration:

1. Restore from clean backups
2. Rebuild compromised systems
3. Apply all security updates
4. Verify system integrity
5. Gradual service restoration
6. Enhanced monitoring period

Update and Patch Management Process

To address identified security vulnerabilities in the solution, both temporary mitigations and long-term remediation strategies may be required. Immediate remediation efforts may focus on containing the issue, implementing a temporary workaround, or delivering a permanent fix.

Permanent remediation may include compensating controls or guidance that the solution consumers can implement to avoid, reduce, or accept associated risks. If the risk level, as determined by the Cybersecurity Risk Assessment process, warrants it, a patch or code update may be developed.

All patches must comply with established design and change control procedures. Criteria for validating the effectiveness and system impact of any remediation should be defined based on the cybersecurity risk analysis.

Each identified vulnerability must be assessed for its applicability to the specific solution's version and endpoints. New vulnerabilities should be reviewed in the context of existing records to determine whether they represent a novel risk or are already known.

Known vulnerabilities require a review and possible update of relevant security documentation, including threat models, Cybersecurity Risk Assessments, security requirements, software bill of materials (SBOM), and testing artifacts.

If a vulnerability or patch is newly discovered, it may require a formal risk evaluation—outlined in the Product Security Plan—to determine its severity and response priority.

Patches and remediations must be validated to ensure:

• The vulnerability is reduced to an acceptable risk level.
• No new security issues are introduced because of the applied fix.

Routine updates and patching for the device are managed through a structured deployment process that includes development, testing, and staged rollout of changes. Validated patches are first applied in a controlled test environment, and once verified, updates are deployed to production via automated pipelines with minimal service disruption, following established change management procedures.

This integrated update process ensures both responsiveness to emerging threats and the ongoing security and stability of the solution through consistent, well-managed patching practices.

Phase 5: Post-Incident Activity

Objectives

Learn from incidents and improve security posture

Activities

1. Communicate the incdident resolution to stakeholders
2. Lessons Learned Meeting (within 5 business days)
   • What went well?
   • What could be improved?
   • Were procedures adequate?
   • Were tools effective?
3. Documentation Updates
   • Update incident response procedures
   • Revise contact lists
   • Improve detection rules
   • Update threat models
4. Metrics Collection
   • Time to detection
   • Time to containment
   • Time to recovery
   • Total impact assessment
5. Improvement Implementation
   • Security control enhancements
   • Process improvements
   • Training needs identification
   • Tool acquisitions/updates

Specific Procedures

Ransomware Response

Immediate Actions:

1. ISOLATE - Disconnect affected systems immediately
2. IDENTIFY - Determine ransomware variant
3. REPORT - Notify law enforcement and INCIBE-CERT
4. ASSESS - Evaluate backup availability and integrity

Evidence Collection:

• Ransom note (screenshots, files)
• Encrypted file samples
• Process execution logs
• Network connections before encryption
• Email headers (if phishing)
• User activity logs
• Backup status before incident
• Communication with threat actor

Decision Tree:

Recovery Steps:

1. Ensure threat is fully eradicated
2. Restore from clean backups
3. Apply all security patches
4. Reset all credentials
5. Implement additional monitoring
6. Conduct threat hunt

Data Breach Response

Response Actions:

1. Immediate(< 1 hour):
   • Stop ongoing exfiltration
   • Preserve evidence
   • Document affected data
2. Short-term (< 24 hours):
   • Complete impact assessment
   • Prepare notifications
   • Engage legal counsel
3. Notification Requirements:
   • GDPR: 72 hours to DPA
   • NIS2: 24 hours early warning
   • Affected individuals: Without undue delay
   • Business partners: Per agreements

Evidence Collection:

• Access logs showing unauthorized access
• Data transfer logs
• Database query logs
• Network traffic captures
• User account audit
• File access history
• Email/data exfiltration evidence
• Timeline of access
• Volume of data accessed
• Data classification/sensitivity

Breach Severity Matrix:

For data breaches, the "Data Impact" rating in the Impact Assessment Criteria must be assigned.

Supply Chain Compromise

Detection Indicators:

• Unexpected software behavior
• Unauthorized network connections
• Certificate anomalies
• Version inconsistencies

Response Protocol:

1. Isolate affected components
2. Inventory all instances of compromised software
3. Analyze potential impact and lateral movement
4. Coordinate with vendor/supplier
5. Patch/Replace affected components
6. Verify supply chain integrity

SOUP Component Response (Software of Unknown Provenance):

• Immediate isolation if compromise suspected
• Review all integration points
• Assess medical device functionality impact
• Implement compensating controls
• Plan for component replacement

DDoS Attacks

AWS Shield and CloudFront Protection:

1. Detection:

   • CloudWatch metrics anomalies
   • AWS Shield alerts
   • Performance degradation reports

2. Mitigation:

   • Enable AWS Shield Advanced
   • Implement rate limiting
   • Geographic restrictions if appropriate
   • Scale resources as needed

3. Communication:

   • Status page updates
   • Customer notifications
   • AWS support engagement

Insider Threats

Detection Methods:

• Anomalous access patterns
• Data exfiltration attempts
• Privilege escalation
• After-hours access
• Large data transfers

Evidence Collection:

• User access patterns
• Abnormal working hours
• Data download history
• Email communications
• Print logs
• System privilege changes
• Resignation/termination status

Response Considerations:

1. Preservation of evidence for potential legal action
2. Discretion to prevent alerting the insider
3. Coordination with HR and Legal
4. Access revocation planning
5. Chain of custody maintenance

Investigation Steps:

1. Covert monitoring implementation
2. Access log comprehensive review
3. Data movement tracking
4. Communication analysis (if legally permitted)
5. Interview preparation
6. Termination and access revocation coordination

Evidence Collection and Forensics

Chain of Custody Procedures

Documentation Requirements:

Field	Description	Example
Evidence ID	Unique identifier	EVD-2025-001
Date/Time Collected	UTC timestamp	2025-08-29T14:30:00Z
Collector	Name and role	John Doe (Security Analyst)
Source System	System/location	prod-api-server-01
Hash Value	SHA-256 hash	[64-character hash]
Storage Location	Secure storage path	/evidence/case-2025-001/
Access Log	Who accessed and when	Timestamped access records

Handling Procedures:

1. Collection:
   • Use write-blockers for physical media
   • Create bit-for-bit copies
   • Calculate and document hash values
   • Secure original evidence
2. Storage:
   • Encrypted storage mandatory
   • Access control implementation
   • Backup copies creation
   • Retention per legal requirements
3. Transfer:
   • Documented handoff process
   • Verification of integrity
   • Secure transport methods
   • Receipt confirmation

Log Preservation Requirements

Retention Periods:

Log Type	Standard Retention	Incident Retention	Regulatory Requirement
Security logs	90 days	7 years	GDPR/NIS2
Access logs	90 days	7 years	MDR traceability
Application logs	30 days	3 years	IEC 62304
Database logs	90 days	7 years	GDPR audit
Cloud provider logs	90 days	7 years	NIS2 compliance

Preservation Process:

Legal Considerations

Data Protection Requirements:

• GDPR compliance for EU data
• Minimize personal data collection
• Pseudonymization where possible
• Legal basis documentation

Evidence Admissibility:

• Maintain chain of custody
• Document collection methods
• Preserve metadata
• Expert witness availability

Regulatory Obligations:

• MDR serious incident reporting
• GDPR breach notification
• NIS2 incident reporting
• FDA MDR requirements

Legal Holds:

• Immediate preservation upon notice
• Suspend deletion policies
• Notify relevant teams
• Document compliance

Communication Plan

Internal Communication Protocols

Communication Hierarchy:

Update Frequency:

Severity	Executive Updates	Team Updates	Status Page
Critical	Every 30 min	Every 15 min	Every 30 min
High	Every 2 hours	Every hour	Every hour
Medium	Every 6 hours	Every 2 hours	Every 4 hours
Low	Daily	Every 4 hours	As needed

Communication Channels:

• Primary: Dedicated Slack channel (#incident-response)
• Backup: Email distribution lists
• Emergency: Phone tree activation
• Documentation: Google Drive incident folder

Customer Notification Procedures

Notification trigers:

Impact Level	Initial Notice	Update Frequency	Resolution Notice
Critical - All customers	< 30 minutes	Every hour	Immediately
High - Multiple customers	< 1 hour	Every 2 hours	Within 30 min
Medium - Limited customers	< 4 hours	Every 4 hours	Within 1 hour
Low - Individual customers	< 24 hours	Daily	Within 24 hours

Communication Templates: See Appendix E - Customer Communication Templates

Media and Public Relations

Media Response Protocol:

1. No unauthorized communications - All media inquiries directed to designated spokesperson
2. Prepared statements only - Use approved messaging
3. Coordination with legal and executive teams
4. Transparency balanced with security
5. Regular updates to prevent speculation

Key Messages Framework:

• Patient safety is our top priority
• We are actively investigating and responding
• We are cooperating with relevant authorities
• We will provide updates as appropriate
• We maintain robust security measures

Regulatory Body Communications

Required Notifications:

Authority	Trigger	Timeline	Method
INCIBE-CERT (NIS2)	Significant incident	24h/72h	Secure portal/email
AEMPS (MDR)	Serious incident	Immediately/10 days	Official portal
DPA (GDPR)	Personal data breach	72 hours	Official notification
FDA	Device malfunction	30 days	FDA ESG
Customers	Service impact	Per SLA	Multiple channels

Documentation Requirements:

• Timestamped communications
• Response acknowledgments
• Follow-up requirements
• Compliance evidence

Recovery and Business Continuity

Recovery Time Objectives (RTO)

System/Service	RTO	Priority	Dependencies
Authentication Service	1 hour	Critical	Database
API	2 hours	Critical	Infrastructure
Core Diagnostic Engine	4 hours	Critical	ML Models, Processing

Recovery Point Objectives (RPO)

Data Type	RPO	Backup Method	Verification
System Configuration	24 hours	Daily snapshot	Weekly test
Audit Logs	Real-time	Stream replication	Continuous
User Accounts	1 hour	Hourly snapshot	Hourly verification

Backup and Restore Procedures

Backup Strategy:

Restore Procedures:

1. Assessment Phase:
   • Determine data loss extent
   • Identify recovery point
   • Estimate recovery time
   • Notify stakeholders
2. Preparation Phase:
   • Prepare recovery environment
   • Verify backup integrity
   • Allocate resources
   • Update DNS if needed
3. Restoration Phase:
   • Restore system components
   • Restore data from backups
   • Verify data integrity
   • Test functionality
4. Validation Phase:
   • Security scanning
   • Performance testing
   • User acceptance testing
5. Cutover Phase:
   • Gradual traffic migration
   • Monitor system health
   • Verify full functionality
   • Document recovery

Testing and Improvement

Plan Update Procedures

Review Triggers:

• After each incident
• Regulatory changes
• Organizational changes
• Technology changes
• Annually (minimum)

Update Process:

Version Control:

• Major version: Significant structural changes
• Minor version: Procedural updates
• Patch version: Contact/template updates

Appendices

Appendix A: Early Warning Template (24-hour NIS2)

EARLY WARNING - CYBERSECURITY INCIDENT NOTIFICATION

To: INCIBE-CERT
From: Legit.Health Incident Response Team
Date/Time: [UTC Timestamp]
Reference: [Incident ID]

ENTITY INFORMATION:

- Organization: Legit.Health
- NIS2 Registration: [Registration Number]
- Sector: Healthcare - Medical Device Software
- Contact: [Incident Commander Name/Phone/Email]

INCIDENT CLASSIFICATION:

- Type: [Ransomware/Data Breach/DDoS/Other]
- Severity: [Critical/High/Medium/Low]
- Status: [Ongoing/Contained/Resolved]

PRELIMINARY IMPACT:

- Patient Safety Impact (C/H/M/L)
- Data Impact (C/H/M/L)
  - Personal Health Information: [Yes/No - Volume]
  - Personal Identifiable Information: [Yes/No - Volume]
  - Proprietary Information: [Yes/No - Type]
- Availability Impact (C/H/M/L)
  - Duration: [Hours/Days]
  - Services Affected: [List]
  - User Impact: [Detailed Numbers]
- Overall Severity
- NIS2 Significant? (Yes/No)
- Financial Impact: [Estimated EUR]

CROSS-BORDER IMPACT:

- Other EU Member States Affected: [Yes/No - List]
- Critical Infrastructure Impact: [Yes/No]

INITIAL RESPONSE:

- Containment Measures: [Brief Description]
- Investigation Status: [In Progress/Planning/Complete]

ADDITIONAL INFORMATION:

- 72-hour detailed report will follow
- Point of Contact for queries: [Name/Role/Contact]

[Digital Signature]

Appendix B: 72-Hour Notification Template

72-HOUR INCIDENT NOTIFICATION - DETAILED REPORT

To: INCIBE-CERT
From: Legit.Health Incident Response Team
Date/Time: [UTC Timestamp]
Reference: [Incident ID]
Early Warning Reference: [Previous Reference]

INCIDENT DETAILS:

- Detection Time: [UTC Timestamp]
- Attack Vector: [Detailed Description]
- Threat Actor: [Known/Unknown - Attribution if available]
- Tactics, Techniques, Procedures (TTPs): [MITRE ATT&CK References]

COMPREHENSIVE IMPACT ASSESSMENT:

- Patient Safety Impact (C/H/M/L)
- Data Impact (C/H/M/L)
  - Personal Health Information: [Yes/No - Volume]
  - Personal Identifiable Information: [Yes/No - Volume]
  - Proprietary Information: [Yes/No - Type]
- Availability Impact (C/H/M/L)
  - Duration: [Hours/Days]
  - Services Affected: [List]
  - User Impact: [Detailed Numbers]
- Overall Severity
- NIS2 Significant? (Yes/No)
- Financial Impact: [Estimated EUR]

ROOT CAUSE ANALYSIS:

- Primary Cause: [Description]
- Contributing Factors: [List]
- Vulnerability Exploited: [CVE if applicable]

TIMELINE OF EVENTS:
[Chronological list with UTC timestamps]

RESPONSE ACTIONS:

- Immediate Containment: [Actions Taken]
- Eradication Measures: [Actions Taken]
- Recovery Status: [Percentage/Timeline]
- Evidence Preserved: [Types/Volumes]

MITIGATION MEASURES:

- Technical Controls Implemented: [List]
- Process Improvements: [List]
- Additional Monitoring: [Description]

REGULATORY COMPLIANCE:

- GDPR Notification: [Status]
- MDR Reporting: [Status]
- Other Obligations: [Status]

LESSONS LEARNED:

- Key Findings: [List]
- Improvement Areas: [List]
- Planned Actions: [List]

ONGOING ACTIVITIES:

- Investigation Status: [Percentage Complete]
- Recovery Activities: [List]
- Expected Resolution: [Date/Time]

ASSISTANCE REQUIRED:

- Technical Support Needed: [Yes/No - Type]
- Threat Intelligence Sharing: [Requested Information]
- Coordination with Other CSIRTs: [Requirements]

CONTACT INFORMATION:

- Incident Commander: [Name/Role/Contact]
- Technical Lead: [Name/Role/Contact]
- 24/7 Hotline: [Phone Number]

ATTACHMENTS:

- Technical Indicators of Compromise (IoCs)
- Network Diagrams (Sanitized)
- Log Excerpts (Relevant)

[Digital Signature]

Appendix C: Monthly Progress Report Template

MONTHLY INCIDENT PROGRESS REPORT

To: INCIBE-CERT
From: Legit.Health Incident Response Team
Date: [Date]
Reporting Period: [Start Date] to [End Date]
Incident Reference: [Incident ID]

INCIDENT STATUS:

- Current Phase: [Investigation/Containment/Recovery/Monitoring]
- Percentage Complete: [%]
- Estimated Resolution: [Date]

PROGRESS SINCE LAST REPORT:

- Completed Activities: [List with dates]
- Ongoing Activities: [List with status]
- Planned Activities: [List with timeline]

UPDATED IMPACT ASSESSMENT:

- Patient Safety Impact (C/H/M/L)
- Data Impact (C/H/M/L)
  - Personal Health Information: [Yes/No - Volume]
  - Personal Identifiable Information: [Yes/No - Volume]
  - Proprietary Information: [Yes/No - Type]
- Availability Impact (C/H/M/L)
  - Duration: [Hours/Days]
  - Services Affected: [List]
  - User Impact: [Detailed Numbers]
- Overall Severity
- NIS2 Significant? (Yes/No)
- Financial Impact: [Estimated EUR]

INVESTIGATION FINDINGS:

- New Evidence Discovered: [Summary]
- Threat Actor Updates: [Attribution/TTP updates]
- Root Cause Refinement: [Updates]

MITIGATION EFFECTIVENESS:

- Controls Implemented: [List with effectiveness rating]
- Residual Risk: [Assessment]
- Additional Measures Needed: [List]

CHALLENGES AND BLOCKERS:

- Technical Challenges: [Description]
- Resource Constraints: [Description]
- External Dependencies: [Description]

SUPPORT REQUIREMENTS:

- Assistance Needed: [Specific requests]
- Information Sharing: [Requirements]

NEXT MONTH OUTLOOK:

- Key Milestones: [List with dates]
- Expected Achievements: [List]
- Risk Factors: [List]

[Digital Signature]

Appendix D: Final Report Template

FINAL INCIDENT REPORT

To: INCIBE-CERT
From: Legit.Health Incident Response Team
Date: [Date]
Incident Reference: [Incident ID]
Incident Duration: [Start Date/Time] to [End Date/Time]

EXECUTIVE SUMMARY:
[Brief overview of incident, impact, and resolution]

COMPLETE INCIDENT TIMELINE:
[Detailed chronological timeline with all significant events]

ROOT CAUSE ANALYSIS:

- Primary Root Cause: [Detailed explanation]
- Contributing Factors: [Comprehensive list]
- Systemic Issues: [Organizational/process issues]

TOTAL IMPACT ASSESSMENT:

- Patient Safety Impact (C/H/M/L)
- Data Impact (C/H/M/L)
  - Personal Health Information: [Yes/No - Volume]
  - Personal Identifiable Information: [Yes/No - Volume]
  - Proprietary Information: [Yes/No - Type]
- Availability Impact (C/H/M/L)
  - Duration: [Hours/Days]
  - Services Affected: [List]
  - User Impact: [Detailed Numbers]
- Overall Severity
- NIS2 Significant? (Yes/No)
- Financial Impact: [Estimated EUR]

RESPONSE EFFECTIVENESS:

- Detection Capability: [Assessment and metrics]
- Response Time: [Actual vs. target]
- Containment Effectiveness: [Assessment]
- Recovery Success: [Metrics]
- Communication Effectiveness: [Stakeholder feedback]

REMEDIATION ACTIONS:
Completed:

- Technical Fixes: [Detailed list with verification]
- Process Improvements: [List with implementation status]
- Training Conducted: [Programs and attendance]

Planned:

- Long-term Improvements: [List with timeline]
- Investment Requirements: [Technology/resources]
- Policy Changes: [List with approval status]

LESSONS LEARNED:
What Worked Well:

- [List of successful elements]

What Needs Improvement:

- [List with improvement plans]

Key Recommendations:

- [Prioritized list of recommendations]

PREVENTIVE MEASURES:

- Technical Controls: [New/enhanced controls]
- Process Controls: [New/updated procedures]
- People Controls: [Training/awareness programs]
- Third-party Controls: [Vendor management improvements]

COMPLIANCE STATUS:

- Regulatory Notifications: [Complete list with confirmation]
- Legal Obligations: [Status of all requirements]
- Customer Commitments: [SLA adherence]

INCIDENT CLOSURE:

- All threats eliminated: [Confirmed]
- Systems fully recovered: [Confirmed]
- Monitoring enhanced: [Details]
- Documentation complete: [Confirmed]

APPENDICES:

1. Detailed Technical Analysis
2. Forensic Report
3. Cost Breakdown
4. Stakeholder Communications Log
5. Evidence Inventory
6. External Audit Report (if applicable)

APPROVAL:

- Incident Commander: [Name/Signature/Date]
- CISO: [Name/Signature/Date]
- CEO: [Name/Signature/Date]

[Digital Signature]

Appendix E: Customer Communication Templates

Service Disruption Notification

Subject: [SEVERITY] Service Disruption Notification - Legit.Health Plus

Dear [Customer Name],

We are currently experiencing a service disruption affecting [affected services]. Our team is actively working to resolve this issue.

IMPACT:

- Affected Services: [List]
- Start Time: [Time with timezone]
- Expected Resolution: [Estimate]
- Workaround Available: [Yes/No - Details]

WHAT WE'RE DOING:
[Brief description of response actions]

WHAT YOU SHOULD DO:
[Any required customer actions or recommendations]

We apologize for any inconvenience and will provide updates every [frequency].

For urgent medical needs, please [alternative instructions].

Status Page: [URL]
Support Contact: [Contact information]

Sincerely,
Legit.Health Incident Response Team

Data Breach Notification

Subject: Important Security Notification - Action Required

Dear [Customer Name],

We are writing to inform you of a security incident that may have affected your organization's data on the Legit.Health Plus platform.

WHAT HAPPENED:
[Clear, factual description without technical jargon]

WHEN IT HAPPENED:
[Date range of incident]

WHAT INFORMATION WAS INVOLVED:
[Specific data categories affected]

WHAT WE ARE DOING:

- Immediate actions taken to secure the system
- Investigation by security experts
- Notification to relevant authorities
- Implementation of additional security measures

WHAT WE RECOMMEND YOU DO:

1. [Specific action items]
2. [Monitor for suspicious activity]
3. [Password reset if applicable]
4. [Additional precautions]

FOR MORE INFORMATION:

- Dedicated Hotline: [Phone number]
- Email: security@legit.health
- FAQ: [URL]

We take the security of your data seriously and sincerely apologize for any concern or inconvenience this may cause.

Sincerely,
[Executive Name]
[Title]
Legit.Health

Appendix F: Compliance Mapping

ENISA Guidelines Compliance

ENISA Requirement	IRP Section	Implementation
Incident Classification	Section 4	Severity levels and criteria defined
Response Team Structure	Section 5.1	IRT roles and responsibilities
Detection Capabilities	Section 7.1	Detection sources and analysis
Containment Strategies	Section 7	Short and long-term containment
Evidence Handling	Section 9	Chain of custody procedures
Communication Plans	Section 10	Internal and external protocols
Lessons Learned	Section 7.5	Post-incident improvement process
Testing Program	Section 7.1	Exercises and simulations

NIS2 Article 23 Compliance

NIS2 Requirement	IRP Section	Compliance Evidence
24-hour early warning	Section 13.1	Template and process defined
72-hour notification	Section 13.2	Detailed template provided
Incident classification	Section 4	Significant incident criteria
Impact assessment	Section 4	Multi-factor assessment matrix
Cross-border coordination	Section 5.3	CSIRT contact procedures
Supply chain incidents	Section 7.3	Specific response procedures

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

• Author: Team members involved
• Reviewer: JD-003, JD-004
• Approver: JD-001

This document is classified as Confidential and is subject to controlled distribution. Unauthorized disclosure may compromise security response capabilities.