T-024-008 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.

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

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

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

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

Data Impact

• Critical: > 1000 patient records compromised
• High: 100-1000 patient records compromised
• Medium: 10-100 patient records compromised
• Low: < 10 patient records or no PHI involved

System Availability Impact

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

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

Incident Response Team (IRT)

Team Structure and Roles

Role	Primary Responsibilities	Backup	Contact
Incident Commander (JD-004)	Overall incident coordination, external communications	JD-003	[On-call rotation]
Technical Lead (JD-005)	Technical investigation and containment	JD-011	[On-call rotation]
Security Analyst (JD-011)	Forensics, threat analysis, evidence collection	JD-005	[On-call rotation]
Communications Lead (JD-003)	Customer and stakeholder communications	JD-004	[On-call rotation]
Legal Advisor	Legal implications, regulatory compliance	External Counsel	[Contact info]
Quality Manager (JD-009)	Medical device reporting, patient safety assessment	JD-004	[Contact info]

Contact Information and Escalation Matrix

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

On-Call Rotation Schedule

• Primary rotation: Weekly, Monday 09:00 CET
• Escalation: 15-minute response time for Critical/High
• Coverage: 24/7/365 with primary and backup
• Schedule management: Via PagerDuty or equivalent

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)
PGP Encryption	Confidential data	Key ID: [To be obtained]

Incident Response Phases

Phase 1: Preparation

Objectives: Maintain readiness for incident response

Key Activities:

1. Team Training

   • Quarterly tabletop exercises
   • Annual simulation exercises
   • Role-specific training programs

2. Tool Preparation

   • Forensic tools deployment and updates
   • Monitoring systems configuration
   • Communication channels testing

3. Documentation Maintenance

   • Contact lists updates
   • Playbook reviews
   • Template updates

4. Preventive Measures

   • Security awareness training
   • Vulnerability management
   • Threat intelligence integration

Phase 2: Detection and Analysis

Objectives: Rapidly identify and assess security incidents

Detection Sources:

• SIEM alerts (AWS CloudWatch, GuardDuty)
• Endpoint detection and response (EDR)
• User reports
• Third-party notifications
• Threat intelligence feeds

Analysis Activities:

Evidence Collection Checklist:

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

Phase 3: Containment, Eradication, and Recovery

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

Validation Steps:

• Functionality testing
• Security scanning
• Log review
• User acceptance testing
• Performance verification

Phase 4: Post-Incident Activity

Objectives: Learn from incidents and improve security posture

Activities:

1. Lessons Learned Meeting (within 5 business days)

   • What went well?
   • What could be improved?
   • Were procedures adequate?
   • Were tools effective?

2. Documentation Updates

   • Update incident response procedures
   • Revise contact lists
   • Improve detection rules
   • Update threat models (T-024-006)

3. Metrics Collection

   • Time to detection
   • Time to containment
   • Time to recovery
   • Total impact assessment

4. 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

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

Classification:

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

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

Breach Severity Matrix:

Data Type	Records	Severity	Notification
PHI	> 500	Critical	Immediate to all parties
PHI	< 500	High	60 days to authorities
PII	> 1000	High	72 hours to DPA
PII	< 1000	Medium	Risk assessment based

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

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

AI/ML Model Poisoning

Threat Scenarios:

• Training data manipulation
• Model parameter tampering
• Adversarial input attacks
• Feedback loop poisoning

Response Framework:

1. Detection:

   • Model performance degradation
   • Unexpected outputs
   • Statistical anomalies
   • User complaints about accuracy

2. Analysis:

   • Input data validation
   • Model version comparison
   • Training data integrity check
   • Prediction distribution analysis

3. Recovery:

   • Rollback to known-good model
   • Retrain with validated data
   • Implement additional validation
   • Enhanced monitoring deployment

Validation Requirements:

• Clinical validation of restored model
• Regulatory notification if patient impact
• Documentation per MDR requirements
• Update to risk management file (R-TF-013-002)

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
API logs	60 days	3 years	Integration tracking
Cloud provider logs	90 days	7 years	NIS2 compliance

Preservation Process:

Forensic Analysis Tools

Approved Tools Suite:

Tool	Purpose	Usage Context
AWS CloudTrail	Cloud activity analysis	API calls, resource changes
AWS GuardDuty	Threat detection analysis	Malicious activity investigation
Wireshark	Network traffic analysis	Packet capture examination
Volatility	Memory analysis	RAM dump examination
SIFT Workstation	General forensics	Comprehensive analysis
Timeline Explorer	Timeline analysis	Event correlation
Log2Timeline	Log aggregation	Multi-source timeline

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: Confluence incident page

Customer Notification Procedures

Notification Triggers:

• Service availability impact > 15 minutes
• Data breach affecting customer data
• Security vulnerability requiring customer action
• Planned emergency maintenance

Notification Timeline:

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	AWS Cognito, Database
API Gateway	2 hours	Critical	AWS API Gateway, Lambda
Core Diagnostic Engine	4 hours	Critical	ML Models, Processing
Web Application	4 hours	High	CloudFront, S3
Mobile Applications	8 hours	High	App Stores, API
Reporting Module	12 hours	Medium	Database, Analytics
Admin Portal	24 hours	Medium	Web App, Database
Training System	48 hours	Low	LMS, Content

Recovery Point Objectives (RPO)

Data Type	RPO	Backup Method	Verification
Patient Data	1 hour	Continuous replication	Daily test restore
Diagnostic Results	1 hour	Real-time backup	Automated verification
System Configuration	24 hours	Daily snapshot	Weekly test
Audit Logs	Real-time	Stream replication	Continuous
ML Models	24 hours	Version control	Pre-deployment test
User Accounts	1 hour	Multi-region sync	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:

   • Clinical validation testing
   • Security scanning
   • Performance testing
   • User acceptance testing

5. Cutover Phase:

   • Gradual traffic migration
   • Monitor system health
   • Verify full functionality
   • Document recovery

Business Continuity Activation

Activation Triggers:

• System unavailability > RTO
• Major security incident
• Natural disaster
• Pandemic/emergency situations

BC Team Activation:

Alternative Operations:

• Manual processing procedures
• Paper-based backup processes
• Alternative communication methods
• Emergency contact activation

Testing and Improvement

Tabletop Exercises Schedule

Quarterly Exercises:

Quarter	Scenario Type	Participants	Duration
Q1	Ransomware Attack	Full IRT + Executive	4 hours
Q2	Data Breach	IRT + Legal + DPO	3 hours
Q3	Supply Chain Compromise	IRT + Vendors	3 hours
Q4	AI Model Poisoning	IRT + Clinical + QA	4 hours

Exercise Objectives:

1. Test communication procedures
2. Validate decision-making processes
3. Identify gaps in procedures
4. Practice regulatory notifications
5. Evaluate team readiness

Simulation Exercises

Annual Full-Scale Simulation:

Scope: End-to-end incident response including:

• Detection and alerting
• Team mobilization
• Technical response
• Communication execution
• Recovery procedures
• Post-incident activities

Success Criteria:

• Detection within 30 minutes
• IRT activation within 1 hour
• Containment within 4 hours
• Customer communication within SLA
• Regulatory notification within timelines
• Full recovery within RTO

Red Team/Blue Team Exercises

Semi-Annual Exercises:

Red Team Objectives:

• Test detection capabilities
• Identify security gaps
• Validate response procedures
• Assess security controls effectiveness

Blue Team Objectives:

• Detect and respond to attacks
• Practice incident procedures
• Improve detection rules
• Enhance response capabilities

Exercise Scenarios:

1. External attacker simulation
2. Insider threat scenario
3. Supply chain attack
4. Social engineering campaign
5. Technical vulnerability exploitation

Plan Update Procedures

Review Triggers:

• After each incident
• Following exercises
• 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:

- Systems Affected: [List]
- Service Disruption: [Yes/No - Description]
- Data Compromise: [Yes/No/Under Investigation]
- Estimated Users Affected: [Number/Range]
- Geographic Scope: [Countries/Regions]

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:

- Total Systems Compromised: [Number and Types]
- Data Categories Affected:
  - Personal Health Information: [Yes/No - Volume]
  - Personal Identifiable Information: [Yes/No - Volume]
  - Proprietary Information: [Yes/No - Type]
- Service Availability Impact:
  - Duration: [Hours/Days]
  - Services Affected: [List]
  - User Impact: [Detailed Numbers]
- Financial Impact: [Estimated EUR]
- Operational Impact: [Description]
- Reputational Impact: [Assessment]

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:

- Additional Systems Identified: [Yes/No - Details]
- Revised User Impact: [Numbers]
- Updated Financial Impact: [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:

- Systems Affected: [Complete inventory]
- Data Compromised: [Final assessment]
- User Impact: [Final numbers and demographics]
- Financial Cost: [Total EUR including response costs]
- Regulatory Impact: [Fines/sanctions if any]
- Reputational Impact: [Measured impact]

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: Incident Response Flowcharts

Master Incident Response Flow

NIS2 Notification Decision Tree

Appendix G: Contact Lists

Internal Contacts

Role	Primary	Backup	Mobile	Email
Incident Commander	[Name]	[Name]	[Phone]	[Email]
Technical Lead	[Name]	[Name]	[Phone]	[Email]
Security Analyst	[Name]	[Name]	[Phone]	[Email]
Communications Lead	[Name]	[Name]	[Phone]	[Email]
Quality Manager	[Name]	[Name]	[Phone]	[Email]
DPO	[Name]	[Name]	[Phone]	[Email]
CEO	[Name]	-	[Phone]	[Email]
CTO	[Name]	-	[Phone]	[Email]

External Contacts

Organization	Purpose	Contact	Phone	Email
INCIBE-CERT	Spanish CSIRT	24/7 SOC	+34 017	incidents@incibe-cert.es
CCN-CERT	Government CERT	Duty Officer	[Phone]	incidents@ccn-cert.cni.es
AEMPS	Medical Device Authority	Vigilance	[Phone]	notificaciones.ps@aemps.es
Spanish DPA (AEPD)	Data Protection	Breach Notification	[Phone]	[Email]
AWS Support	Cloud Provider	Enterprise Support	[Phone]	[Portal]
External IR Firm	Incident Response	[Company]	[Phone]	[Email]
Legal Counsel	Legal Advice	[Firm]	[Phone]	[Email]
PR Agency	Crisis Comms	[Agency]	[Phone]	[Email]

Appendix H: Evidence Collection Checklists

Ransomware Evidence Checklist

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

Data Breach Evidence Checklist

• 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

Insider Threat Evidence Checklist

• User access patterns
• Abnormal working hours
• Data download history
• Email communications
• USB/removable media usage
• Cloud storage uploads
• Print logs
• Badge access logs
• System privilege changes
• Resignation/termination status

Appendix I: Integration Points

Integration with T-024-006 Threat Model

The Incident Response Plan directly addresses threats identified in the Threat Model:

Threat ID	Threat Description	Response Procedure
TM-001	API Authentication Bypass	Section 6.2 - Data Breach Response
TM-002	Ransomware Attack	Section 6.1 - Ransomware Response
TM-003	Supply Chain Compromise	Section 6.3 - Supply Chain Response
TM-004	Insider Data Theft	Section 6.5 - Insider Threat Response
TM-005	DDoS Attack	Section 6.4 - DDoS Response
TM-006	AI Model Poisoning	Section 6.6 - AI/ML Model Response

Integration with T-024-007 Post-Market Surveillance

Post-incident activities feed into the post-market surveillance system:

• Incident metrics → Surveillance KPIs
• Vulnerability discoveries → Threat landscape updates
• Customer impacts → Safety signal detection
• Response effectiveness → Process improvements
• Lessons learned → Risk management updates

Integration with Risk Management (R-TF-013-002)

Incidents trigger risk management reviews:

• New threats identified → Risk assessment updates
• Control failures → Risk control effectiveness review
• Incident impacts → Severity reassessment
• Response gaps → New risk controls
• Residual risks → Benefit-risk analysis updates

Appendix J: Compliance Mapping

ENISA Guidelines Compliance

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

NIS2 Article 23 Compliance

NIS2 Requirement	IRP Section	Compliance Evidence
24-hour early warning	Section 4.1	Template and process defined
72-hour notification	Section 4.2	Detailed template provided
Incident classification	Section 2.4	Significant incident criteria
Impact assessment	Section 2.3	Multi-factor assessment matrix
Cross-border coordination	Section 3.3	CSIRT contact procedures
Supply chain incidents	Section 6.3	Specific response procedures

---

Document Approval

Role	Name	Signature	Date
Author	Technical Team	[Signature]	2025-08-29
Reviewer	Quality Manager	[Signature]	[Date]
Approver	CISO	[Signature]	[Date]
Approver	CEO	[Signature]	[Date]

Revision History

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

---

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