T-024-007 Cybersecurity Post-Market Surveillance Plan

Executive Summary

Purpose and Scope

This Cybersecurity Post-Market Surveillance Plan establishes a comprehensive framework for monitoring, assessing, and responding to cybersecurity threats and vulnerabilities affecting the Legit.Health Plus medical device software throughout its operational lifecycle. The plan ensures continuous security monitoring, timely vulnerability remediation, and compliance with regulatory requirements while maintaining patient safety and data protection.

Regulatory Alignment

This plan has been developed in accordance with:

• FDA Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (September 2023)
• FDA Postmarket Management of Cybersecurity in Medical Devices (December 2016)
• EU Medical Device Regulation (MDR) 2017/745 Article 83 and Annex III
• EU Directive 2022/2555 (NIS2) on measures for high common level of cybersecurity
• MDCG 2019-16 - Guidance on Cybersecurity for medical devices
• IMDRF/CYBER WG/N60FINAL:2020 - Principles and Practices for Medical Device Cybersecurity
• IEC 62443-4-1:2018 - Product security lifecycle requirements
• ISO/IEC 29147:2018 - Vulnerability disclosure
• ISO/IEC 30111:2019 - Vulnerability handling processes

Integration with Overall Post-Market Surveillance

This cybersecurity-specific plan operates as an integral component of the broader post-market surveillance system described in:

• GP-009: Post-Market Surveillance Procedure
• R-TF-007-002: Post-Market Clinical Follow-up (PMCF) Plan
• R-TF-007-001: Post-Market Surveillance Plan

The cybersecurity activities outlined herein shall be coordinated with general post-market surveillance activities to ensure comprehensive risk management and regulatory compliance.

Document Control

Version	Date	Author	Description
1.0	2025-08-29	Technical Team	Initial cybersecurity post-market surveillance plan

Vulnerability Monitoring Program

Vulnerability Intelligence Sources

Primary Sources

Source ID	Source Name	Type	Monitoring Frequency	Responsible Role
VIS-001	National Vulnerability Database (NVD)	Government Database	Daily automated	Security Team
VIS-002	CISA Known Exploited Vulnerabilities	Government Advisory	Daily automated	Security Team
VIS-003	ICS-CERT Medical Device Advisories	Sector-Specific	Daily automated	Security Team
VIS-004	FDA MAUDE Database	Medical Device Reports	Weekly	Quality Team
VIS-005	EU Medical Device Coordination Group	Regulatory Updates	Weekly	Regulatory Affairs

Secondary Sources

Source ID	Source Name	Type	Monitoring Frequency	Responsible Role
VIS-006	MITRE CVE Database	Vulnerability Database	Daily automated	Security Team
VIS-007	Healthcare ISAC Alerts	Industry Sharing	Real-time alerts	Security Team
VIS-008	Vendor Security Bulletins	Vendor Notifications	As published	Development Team
VIS-009	CERT Coordination Center	Research Institution	Weekly	Security Team
VIS-010	Security Research Publications	Academic/Industry	Monthly	R&D Team

SOUP/Third-Party Component Monitoring

Component Inventory Management

All Software of Unknown Provenance (SOUP) and third-party components shall be maintained in a comprehensive Software Bill of Materials (SBOM) including:

• Component name and version
• Vendor/maintainer information
• License type
• Known vulnerabilities (CVEs)
• End-of-life/support dates
• Security contact information

Monitoring Process

Activity	Frequency	Tool/Method	Output
SBOM Update	Monthly	Automated scanning	Updated component list
Vulnerability Scanning	Daily	Trivy, Snyk	Vulnerability report
License Compliance Check	Quarterly	License scanner	Compliance report
EOL Component Review	Quarterly	Manual review	Update plan
Security Patch Assessment	As released	Manual review	Patch decision

Threat Intelligence Integration

Threat Intelligence Feeds

Feed ID	Feed Name	Coverage	Integration Method
TIF-001	Healthcare Threat Intel	Healthcare-specific threats	API integration
TIF-002	Cloud Security Alliance	Cloud infrastructure threats	Email alerts
TIF-003	STIX/TAXII Feeds	Structured threat information	Automated ingestion
TIF-004	Dark Web Monitoring	Credential leaks, exploits	Vendor service
TIF-005	Social Media Monitoring	Early warning indicators	Manual review

Intelligence Processing Workflow

1. Collection: Automated gathering from configured sources
2. Normalization: Standardize data format and severity ratings
3. Enrichment: Add context from internal systems
4. Analysis: Assess applicability to Legit.Health Plus
5. Prioritization: Rank by potential impact and exploitability
6. Distribution: Alert relevant teams based on severity

Security Bulletin Monitoring

Security bulletins shall be monitored for all components in the technology stack:

• Operating Systems: Linux distributions, container base images
• Runtime Environments: Python, Node.js
• Frameworks: FastAPI, React
• Libraries: PyTorch, NumPy, OpenCV
• Cloud Services: AWS services and features
• Databases: MongoDB, AWS DocumentDB
• Infrastructure: Docker, Kubernetes

Vulnerability Assessment Process

CVSS Scoring Methodology

All identified vulnerabilities shall be assessed using the Common Vulnerability Scoring System (CVSS) v3.1:

Base Score Calculation

Metric	Values	Description
Attack Vector (AV)	Network/Adjacent/Local/Physical	How the vulnerability is exploited
Attack Complexity (AC)	Low/High	Conditions beyond attacker's control
Privileges Required (PR)	None/Low/High	Level of privileges needed
User Interaction (UI)	None/Required	Whether user must participate
Scope (S)	Unchanged/Changed	Whether impact extends beyond vulnerable component
Confidentiality (C)	None/Low/High	Impact on data confidentiality
Integrity (I)	None/Low/High	Impact on data integrity
Availability (A)	None/Low/High	Impact on resource availability

Environmental Score Modifiers

Environmental metrics shall be adjusted based on Legit.Health Plus deployment:

• Confidentiality Requirement: High (patient data protection)
• Integrity Requirement: High (diagnostic accuracy)
• Availability Requirement: Medium (non-life-supporting)
• Modified Attack Vector: Consider network segmentation
• Modified Attack Complexity: Account for existing controls

Risk Assessment Criteria

Severity Classification

CVSS Score	Severity Level	Response Time	Escalation Required
9.0-10.0	Critical	24 hours	Executive team
7.0-8.9	High	7 days	Management team
4.0-6.9	Medium	30 days	Team lead
0.1-3.9	Low	90 days	Standard process
0.0	None	Monitor only	None

Medical Device Specific Factors

Additional factors for medical device context:

1. Patient Safety Impact

   • Direct harm potential
   • Diagnostic accuracy impact
   • Treatment delay risk

2. Clinical Setting

   • Healthcare facility exposure
   • Internet connectivity requirements
   • User access levels

3. Data Sensitivity

   • Protected health information (PHI)
   • Personally identifiable information (PII)
   • Clinical research data

Prioritization Matrix

Vulnerabilities shall be prioritized using a risk-based approach:

Priority Score = CVSS Base Score × Exploitability Factor × Asset Criticality × Exposure Factor

Where:
- Exploitability Factor: 0.5-2.0 based on exploit availability
- Asset Criticality: 1.0-3.0 based on component importance
- Exposure Factor: 0.5-2.0 based on attack surface exposure

Priority Levels

Priority Score	Priority Level	Action Required
>20	P1 - Critical	Immediate action, emergency patch
15-20	P2 - High	Expedited patch within 7 days
10-14	P3 - Medium	Standard patch cycle (30 days)
5-9	P4 - Low	Next maintenance window
<5	P5 - Minimal	Monitor and batch update

Impact Analysis Procedures

Technical Impact Assessment

1. Component Analysis

   • Identify affected components
   • Determine dependency chain
   • Assess function criticality

2. Attack Surface Evaluation

   • External exposure assessment
   • Authentication requirements
   • Network accessibility

3. Exploit Viability

   • Exploit code availability
   • Technical skill requirements
   • Attack complexity analysis

Business Impact Assessment

1. Operational Impact

   • Service availability effects
   • Performance degradation
   • Functionality limitations

2. Compliance Impact

   • Regulatory requirement violations
   • Certification implications
   • Audit findings

3. Reputational Impact

   • Customer trust implications
   • Market perception
   • Competitive positioning

Incident Response Framework

Detection and Reporting Procedures

Detection Mechanisms

Detection ID	Method	Coverage	Alert Threshold
DET-001	SIEM Monitoring	All systems	Anomaly detection
DET-002	IDS/IPS	Network traffic	Signature match
DET-003	File Integrity Monitoring	Critical files	Any change
DET-004	User Behavior Analytics	User activities	Deviation from baseline
DET-005	Vulnerability Scanning	All components	New vulnerabilities
DET-006	Customer Reports	Production issues	Any security concern
DET-007	Third-Party Notifications	Supply chain	Vendor alerts

Reporting Channels

1. Internal Reporting

   • Security hotline: [24/7 contact number]
   • Email: security@legithealth.com
   • Incident portal: [Internal URL]
   • Slack channel: #security-incidents

2. External Reporting

   • Responsible disclosure: security@legithealth.com
   • Bug bounty program: [If applicable]
   • Customer support: Through standard channels

NIS2 24/72-Hour Notification Requirements

24-Hour Early Warning (Significant Incidents)

Criteria for Significant Incident:

• Causes or is capable of causing substantial operational disruption
• Affects more than 100 users
• Duration exceeds 1 hour for critical services
• Data breach involving patient information

Notification Content:

• Initial assessment of incident
• Potential impact scope
• Initial containment measures
• Contact information for follow-up

Recipients:

• National CSIRT
• Competent sectoral authority
• Affected customers (if applicable)

72-Hour Incident Notification

Required Information:

• Detailed incident description
• Severity and impact assessment
• Root cause analysis (preliminary)
• Mitigation measures implemented
• Timeline of events
• Affected systems and data
• Customer impact assessment

Notification Format:

• Use NIS2 standard template
• Include ENISA taxonomy classification
• Provide incident reference number

Classification and Severity Levels

Incident Classification

Class	Type	Description	Examples
IC-1	Data Breach	Unauthorized access to data	Patient data exposure, credential theft
IC-2	System Compromise	Unauthorized system access	Malware infection, backdoor installation
IC-3	Denial of Service	Service availability impact	DDoS attack, resource exhaustion
IC-4	Data Integrity	Data modification/corruption	Database tampering, file modification
IC-5	Supply Chain	Third-party compromise	Vendor breach, component vulnerability

Severity Levels

Severity	Impact	Response Time	Team Activation
SEV-1	Critical - Patient safety risk	15 minutes	Full incident response team
SEV-2	High - Major service disruption	1 hour	Core response team
SEV-3	Medium - Limited impact	4 hours	On-call team
SEV-4	Low - Minimal impact	24 hours	Standard team
SEV-5	Info - No immediate impact	72 hours	Monitoring only

Response Team Roles and Responsibilities

Incident Response Team Structure

Role	Primary Responsibilities	Backup
Incident Commander	Overall incident coordination, decision authority	Technical Director
Security Lead	Technical investigation, forensics	Senior Security Engineer
Operations Lead	System stability, service restoration	DevOps Manager
Communications Lead	Internal/external communications	Marketing Director
Legal Advisor	Legal implications, regulatory compliance	External Counsel
Quality Representative	QMS compliance, documentation	Quality Manager
Clinical Safety Officer	Patient safety assessment	Medical Director

RACI Matrix for Incident Response

Activity	Incident Commander	Security Lead	Operations	Communications	Legal	Quality
Initial Assessment	A	R	C	I	I	I
Containment Decision	A	R	C	I	C	I
Investigation	I	R	C	I	I	C
Recovery Planning	A	C	R	I	I	C
Communication	A	I	I	R	C	I
Documentation	C	R	R	C	I	R
Post-Incident Review	R	C	C	C	C	C

R=Responsible, A=Accountable, C=Consulted, I=Informed

Communication Protocols

Internal Communication

1. Immediate Notification (0-15 minutes)

   • Security team activation
   • Management alert for SEV-1/2
   • Initial assessment communication

2. Status Updates (Every 2 hours during incident)

   • Incident status dashboard
   • Email updates to stakeholders
   • Slack channel updates

3. Resolution Communication

   • Incident closure notification
   • Lessons learned summary
   • Action items distribution

External Communication

1. Customer Communication

   • Timing: Based on impact assessment
   • Channel: Email, status page, direct contact for major customers
   • Content: Impact, mitigation, timeline, recommendations

2. Regulatory Communication

   • FDA notification for recalls or safety issues
   • NIS2 compliance notifications
   • MDR vigilance reporting if applicable

3. Public Communication

   • Security advisories on website
   • Coordinated vulnerability disclosure
   • Media response if required

Security Update Management

Patch Development Process

Vulnerability Remediation Workflow

1. Triage (PMS-VUL-001)

   • Vulnerability identification
   • Initial risk assessment
   • Priority assignment

2. Analysis (PMS-VUL-002)

   • Root cause analysis
   • Impact assessment
   • Fix identification

3. Development (PMS-VUL-003)

   • Code modification
   • Security testing
   • Code review

4. Testing (PMS-VUL-004)

   • Unit testing
   • Integration testing
   • Security validation

5. Release (PMS-VUL-005)

   • Release notes preparation
   • Deployment planning
   • Customer notification

Testing and Validation Procedures

Security Patch Testing Requirements

Test Type	Scope	Success Criteria	Documentation
Unit Tests	Modified code	100% pass rate	Test results
Integration Tests	Affected modules	No regression	Test report
Security Tests	Attack vectors	Vulnerability resolved	Security scan
Performance Tests	System-wide	No degradation	Performance metrics
Clinical Validation	Clinical functions	Accuracy maintained	Validation report

Validation Checklist

• Vulnerability successfully remediated
• No new vulnerabilities introduced
• Existing functionality preserved
• Performance requirements met
• Security controls effective
• Documentation updated
• Release notes prepared
• Rollback procedure tested

Deployment Strategies

Deployment Models

Strategy	Use Case	Risk Level	Rollback Time
Immediate Push	Critical vulnerabilities	High	< 1 hour
Phased Rollout	Standard updates	Medium	< 4 hours
Scheduled Maintenance	Low-priority patches	Low	< 24 hours
Customer-Controlled	Optional updates	Minimal	Customer-dependent

Deployment Process

1. Pre-Deployment (PMS-DEP-001)

   • Customer notification (T-24 hours)
   • Backup verification
   • Rollback procedure ready

2. Deployment (PMS-DEP-002)

   • Canary deployment (5% of instances)
   • Monitoring and validation
   • Full deployment authorization

3. Post-Deployment (PMS-DEP-003)

   • Health checks
   • Performance monitoring
   • Customer feedback collection

Customer Notification Procedures

Notification Timeline

Severity	Pre-Notification	Patch Available	Post-Deployment
Critical	Immediate	Within 24 hours	Immediate confirmation
High	48 hours	Within 7 days	Within 24 hours
Medium	1 week	Within 30 days	Within 48 hours
Low	With patch	Within 90 days	With next update

Notification Content Template

Subject: [SEVERITY] Security Update for Legit.Health Plus - [CVE-ID]

Dear Customer,

We are writing to inform you of a security update for Legit.Health Plus.

VULNERABILITY DETAILS:
- CVE ID: [CVE-YYYY-NNNNN]
- Severity: [Critical/High/Medium/Low]
- CVSS Score: [X.X]
- Component Affected: [Component name]

IMPACT:
[Description of potential impact]

MITIGATION:
[Temporary mitigation if available]

PATCH INFORMATION:
- Version: [X.X.X]
- Release Date: [YYYY-MM-DD]
- Installation: [Automatic/Manual]

ACTION REQUIRED:
[Specific actions customer needs to take]

SUPPORT:
For assistance, contact support@legithealth.com

Regards,
Legit.Health Security Team

Emergency Patch Procedures

Emergency Patch Criteria

Patches qualify as emergency when:

• CVSS score ≥ 9.0
• Active exploitation detected
• Patient safety impact identified
• Regulatory mandate issued
• Zero-day vulnerability discovered

Emergency Response Process

1. Hour 0-1: Assessment (PMS-EMR-001)

   • Vulnerability verification
   • Impact assessment
   • Resource mobilization

2. Hour 1-6: Development (PMS-EMR-002)

   • Fix development
   • Expedited testing
   • Management approval

3. Hour 6-24: Deployment (PMS-EMR-003)

   • Emergency change approval
   • Staged deployment
   • Real-time monitoring

4. Hour 24-48: Stabilization (PMS-EMR-004)

   • Performance monitoring
   • Issue resolution
   • Documentation completion

Coordinated Vulnerability Disclosure

Disclosure Policy

Responsible Disclosure Program

Legit.Health maintains a coordinated vulnerability disclosure program aligned with ISO/IEC 29147:2018:

Scope:

• All Legit.Health Plus components
• Associated infrastructure
• Third-party integrations
• Documentation and processes

Out of Scope:

• Social engineering attacks
• Physical security testing
• Third-party services not under our control
• Denial of service attacks

Safe Harbor: Researchers acting in good faith will not face legal action if they:

• Make good faith effort to avoid privacy violations
• Avoid service disruption
• Report findings promptly
• Provide reasonable time for remediation

Researcher Engagement

Communication Channels

Channel	Purpose	Response Time
security@legithealth.com	Primary disclosure	24 hours acknowledgment
PGP-encrypted email	Sensitive disclosures	24 hours acknowledgment
Bug bounty platform	If applicable	Per platform SLA
Security advisory page	Public information	Updated as needed

Researcher Recognition

• Public acknowledgment (with permission)
• Security hall of fame listing
• Bounty payments (if applicable)
• CVE credit attribution
• Reference in security advisories

Timeline for Remediation

Standard Disclosure Timeline

Phase	Duration	Activities
Receipt	Day 0	Acknowledge receipt, initial assessment
Triage	Days 1-3	Verify vulnerability, assess severity
Fix Development	Days 4-30	Develop and test patch
Coordination	Days 31-60	Coordinate with affected parties
Disclosure Preparation	Days 61-75	Prepare advisory, notifications
Public Disclosure	Day 90	Publish advisory, CVE details

Expedited Timeline Triggers

• Severity score ≥ 9.0
• Active exploitation
• Public disclosure imminent
• Multiple researchers reporting
• Significant public interest

Public Disclosure Process

Advisory Publication

1. CVE Assignment (PMS-CVE-001)

   • Request CVE from MITRE
   • Provide vulnerability details
   • Coordinate numbering

2. Advisory Preparation (PMS-CVE-002)

   • Technical description
   • Impact assessment
   • Mitigation guidance
   • Patch information

3. Stakeholder Notification (PMS-CVE-003)

   • Customer pre-notification
   • Regulatory notification
   • CERT coordination

4. Public Release (PMS-CVE-004)

   • Website publication
   • Security mailing list
   • Social media announcement
   • RSS feed update

Metrics and KPIs

Performance Metrics

Mean Time to Detect (MTTD)

Metric	Target	Measurement	Reporting
Critical vulnerabilities	< 24 hours	Time from publication to detection	Monthly
High vulnerabilities	< 72 hours	Time from publication to detection	Monthly
Medium vulnerabilities	< 1 week	Time from publication to detection	Quarterly
Low vulnerabilities	< 1 month	Time from publication to detection	Quarterly

Calculation: MTTD = Timestamp(Detection) - Timestamp(Publication)

Mean Time to Respond (MTTR)

Metric	Target	Measurement	Reporting
Critical incidents	< 1 hour	Time from detection to containment	Per incident
High incidents	< 4 hours	Time from detection to containment	Monthly
Medium incidents	< 24 hours	Time from detection to containment	Monthly
Low incidents	< 72 hours	Time from detection to containment	Quarterly

Calculation: MTTR = Timestamp(Containment) - Timestamp(Detection)

Patch Deployment Rate

Metric	Target	Measurement	Reporting
Critical patches	100% within 24h	Percentage deployed on time	Monthly
High patches	95% within 7d	Percentage deployed on time	Monthly
Medium patches	90% within 30d	Percentage deployed on time	Quarterly
Low patches	85% within 90d	Percentage deployed on time	Quarterly

Calculation: Deployment Rate = (Patches Deployed on Time / Total Patches) × 100

Vulnerability Closure Rate

Metric	Target	Measurement	Reporting
Critical	100%	Percentage remediated	Monthly
High	> 95%	Percentage remediated	Monthly
Medium	> 90%	Percentage remediated	Quarterly
Low	> 80%	Percentage remediated	Annually

Calculation: Closure Rate = (Vulnerabilities Closed / Total Vulnerabilities) × 100

Trend Analysis

Incident Frequency and Severity Trends

Monthly Tracking:

• Number of incidents by severity
• Number of incidents by type
• Time to resolution trends
• Repeat incident analysis

Quarterly Analysis:

• Incident root cause distribution
• Attack vector trends
• Threat actor analysis
• Control effectiveness

Annual Review:

• Year-over-year comparisons
• Emerging threat patterns
• Security posture evolution
• Investment effectiveness

KPI Dashboard

KPI	Current	Target	Trend	Status
MTTD (Critical)	[Value]	< 24h	[↑↓→]	[🔴🟡🟢]
MTTR (Critical)	[Value]	< 1h	[↑↓→]	[🔴🟡🟢]
Patch Compliance	[Value]%	> 95%	[↑↓→]	[🔴🟡🟢]
Vulnerability Backlog	[Value]	< 10	[↑↓→]	[🔴🟡🟢]
Security Incidents	[Value]	< 5/month	[↑↓→]	[🔴🟡🟢]
False Positive Rate	[Value]%	< 10%	[↑↓→]	[🔴🟡🟢]

Periodic Security Activities

Penetration Testing Schedule

Annual Penetration Testing Plan

Quarter	Test Type	Scope	Provider	Plan ID
Q1	External Network	Internet-facing systems	Third-party	PMS-PEN-001
Q2	Web Application	Legit.Health Plus application	Third-party	PMS-PEN-002
Q3	API Security	REST APIs, integrations	Internal + Third-party	PMS-PEN-003
Q4	Red Team Exercise	Full scope attack simulation	Third-party	PMS-PEN-004

Testing Requirements

Scope Definition:

• Production-like environment
• All external interfaces
• Authentication mechanisms
• Data handling processes
• Integration points

Methodology:

• OWASP Testing Guide
• PTES (Penetration Testing Execution Standard)
• NIST SP 800-115
• Medical device specific scenarios

Security Audits

Audit Schedule

Audit Type	Frequency	Scope	Auditor	Plan ID
Code Security Review	Quarterly	New features	Internal	PMS-AUD-001
Configuration Audit	Monthly	Infrastructure	Automated	PMS-AUD-002
Access Control Review	Quarterly	User permissions	Security team	PMS-AUD-003
Compliance Audit	Annually	Full QMS	External	PMS-AUD-004
SOUP Assessment	Semi-annually	Third-party components	Security team	PMS-AUD-005

Audit Criteria

• Compliance with security policies
• Implementation of security controls
• Vulnerability remediation status
• Incident response effectiveness
• Security training completion
• Documentation accuracy

Third-Party Assessments

Assessment Types

Assessment	Provider Type	Frequency	Output	Plan ID
SOC 2 Type II	Certified Auditor	Annual	Attestation report	PMS-TPA-001
ISO 27001 Surveillance	Certification Body	Annual	Audit report	PMS-TPA-002
Cloud Security Assessment	Cloud Provider	Annual	Compliance report	PMS-TPA-003
Supply Chain Review	Security Vendor	Semi-annual	Risk report	PMS-TPA-004

SBOM Updates

Software Bill of Materials Management

Update Frequency:

• Production changes: Real-time
• Routine review: Monthly
• Comprehensive audit: Quarterly
• Regulatory submission: As required

SBOM Components:

Element	Description	Format	Plan ID
Component Inventory	All software components	SPDX/CycloneDX	PMS-SBOM-001
Version Tracking	Component versions	JSON	PMS-SBOM-002
Vulnerability Mapping	Known CVEs	CVRF	PMS-SBOM-003
License Inventory	License compliance	SPDX	PMS-SBOM-004
Dependency Graph	Component relationships	Graph format	PMS-SBOM-005

Update Process:

1. Automated scanning of codebase
2. Manual verification of changes
3. Vulnerability correlation
4. Risk assessment update
5. Stakeholder notification

Documentation and Reporting

Monthly Security Reports

Report Components

Executive Summary

• Key security metrics
• Critical incidents summary
• Major vulnerabilities addressed
• Upcoming security initiatives

Detailed Sections:

1. Vulnerability Management (PMS-REP-001)

   • New vulnerabilities identified
   • Patches deployed
   • Outstanding vulnerabilities
   • SOUP component updates

2. Incident Response (PMS-REP-002)

   • Incidents by severity
   • Response time analysis
   • Root cause summaries
   • Lessons learned

3. Threat Intelligence (PMS-REP-003)

   • Emerging threats
   • Threat actor activity
   • Industry trends
   • Relevance assessment

4. Compliance Status (PMS-REP-004)

   • Regulatory updates
   • Audit findings
   • Corrective actions
   • Certification status

Distribution List

Recipient	Role	Format	Delivery
Executive Team	Oversight	Executive summary	Email
Quality Manager	QMS compliance	Full report	Document system
Development Team	Technical details	Technical sections	Jira
Regulatory Affairs	Compliance status	Compliance section	Email
Board of Directors	Governance	Quarterly summary	Board package

Quarterly Trend Analysis

Analysis Framework

Metrics Trending:

• Vulnerability discovery rate
• Patch deployment velocity
• Incident frequency patterns
• Control effectiveness metrics
• Resource utilization trends

Predictive Analytics:

• Vulnerability forecast modeling
• Threat probability assessment
• Resource requirement projections
• Risk score evolution

Comparative Analysis:

• Quarter-over-quarter comparison
• Year-over-year trends
• Industry benchmark comparison
• Peer organization metrics

Annual Security Review

Comprehensive Annual Assessment

Review Sections:

1. Security Posture Assessment (PMS-ANN-001)

   • Overall security maturity
   • Control effectiveness evaluation
   • Gap analysis results
   • Improvement recommendations

2. Incident Analysis (PMS-ANN-002)

   • Annual incident statistics
   • Major incident post-mortems
   • Systemic issue identification
   • Process improvement opportunities

3. Vulnerability Trends (PMS-ANN-003)

   • Vulnerability statistics
   • Remediation performance
   • SOUP component analysis
   • Emerging vulnerability patterns

4. Compliance Review (PMS-ANN-004)

   • Regulatory compliance status
   • Audit findings summary
   • Corrective action effectiveness
   • Upcoming regulatory changes

5. Investment Analysis (PMS-ANN-005)

   • Security investment ROI
   • Tool effectiveness assessment
   • Resource allocation review
   • Budget recommendations

Regulatory Reporting Requirements

FDA Reporting

Report Type	Trigger	Timeline	Plan ID
Medical Device Report (MDR)	Security issue causing adverse event	30 days	PMS-FDA-001
Correction and Removal Report	Security patch as correction	10 days	PMS-FDA-002
Annual Report	Routine update	Annually	PMS-FDA-003
PMA Supplement	Major security changes	Before implementation	PMS-FDA-004

EU MDR Reporting

Report Type	Trigger	Timeline	Plan ID
Serious Incident Report	Security breach with patient impact	15 days	PMS-MDR-001
Field Safety Notice	Security vulnerability requiring action	Immediately	PMS-MDR-002
Periodic Safety Update	Routine reporting	Annually	PMS-MDR-003
Trend Report	Significant increase in incidents	20 days	PMS-MDR-004

NIS2 Compliance Reporting

Report Type	Trigger	Timeline	Plan ID
Early Warning	Significant incident potential	24 hours	PMS-NIS-001
Incident Notification	Confirmed significant incident	72 hours	PMS-NIS-002
Final Report	Incident closure	1 month	PMS-NIS-003
Annual Summary	Compliance demonstration	Annually	PMS-NIS-004

Integration Points

Risk Management Integration

Link to R-TF-013-002

Risk Identification Updates:

• New vulnerabilities → Risk assessment
• Incident analysis → Risk re-evaluation
• Threat intelligence → Risk identification
• Control effectiveness → Risk mitigation validation

Risk Management Synchronization:

Activity	Risk Management Update	Frequency	Plan ID
Vulnerability assessment	Risk likelihood update	Monthly	PMS-RSK-001
Incident post-mortem	New risk identification	Per incident	PMS-RSK-002
Penetration test results	Control effectiveness	Quarterly	PMS-RSK-003
Threat model review	Risk scenario update	Annually	PMS-RSK-004

Threat Model Maintenance

Link to T-024-006

Threat Model Updates Triggered By:

• New attack vectors discovered
• Architecture changes
• New integration points
• Vulnerability patterns
• Incident learnings

Update Process:

1. Quarterly Review (PMS-THR-001)

   • Review new vulnerabilities
   • Assess threat landscape changes
   • Update attack vectors

2. Annual Revision (PMS-THR-002)

   • Comprehensive threat reassessment
   • Architecture review
   • Control effectiveness evaluation

Post-Market Surveillance Integration

Link to GP-009

Data Sharing:

• Security incidents → Post-market surveillance database
• Customer security complaints → Trend analysis
• Security-related field actions → Vigilance reporting
• Performance metrics → Quality metrics

Coordination Points:

Activity	PMS Integration	Responsible	Plan ID
Incident reporting	Add to PMS database	Quality team	PMS-PMS-001
Trend analysis	Include security trends	Analytics team	PMS-PMS-002
Customer feedback	Security complaint analysis	Support team	PMS-PMS-003
Regulatory reporting	Consolidated reporting	Regulatory team	PMS-PMS-004

Cybersecurity Procedures Alignment

Link to GP-013/GP-024

Procedure Implementation:

• GP-013 Information Security controls
• GP-024 Cybersecurity lifecycle processes
• Incident response procedures
• Change management integration
• Access control enforcement

Process Touchpoints:

Process	Integration Point	Verification	Plan ID
Change Management	Security impact assessment	Change review board	PMS-PRO-001
Access Control	Privilege reviews	Quarterly audit	PMS-PRO-002
Software Development	Security testing	Release criteria	PMS-PRO-003
Supplier Management	SOUP assessment	Procurement review	PMS-PRO-004

Plan Maintenance and Review

Review Schedule

Review Type	Frequency	Participants	Output
Operational Review	Monthly	Security team	Action items
Management Review	Quarterly	Management team	Strategy updates
Effectiveness Review	Semi-annually	Cross-functional	Process improvements
Comprehensive Review	Annually	All stakeholders	Plan revision

Update Triggers

The plan shall be updated when:

• Major security incident occurs
• Significant vulnerability discovered
• Regulatory requirements change
• Architecture significantly modified
• New threat vectors emerge
• Organizational changes occur
• Annual review cycle

Change Control

All changes to this plan shall:

1. Be reviewed by Security Team
2. Approved by Quality Manager
3. Validated by Regulatory Affairs
4. Communicated to stakeholders
5. Version controlled in QMS

Appendices

Appendix A: Plan ID Reference

Plan ID Series	Description	Count
PMS-VUL-XXX	Vulnerability management	005
PMS-DEP-XXX	Deployment processes	003
PMS-EMR-XXX	Emergency response	004
PMS-CVE-XXX	CVE management	004
PMS-PEN-XXX	Penetration testing	004
PMS-AUD-XXX	Security audits	005
PMS-TPA-XXX	Third-party assessments	004
PMS-SBOM-XXX	SBOM management	005
PMS-REP-XXX	Reporting processes	004
PMS-ANN-XXX	Annual reviews	005
PMS-FDA-XXX	FDA reporting	004
PMS-MDR-XXX	MDR reporting	004
PMS-NIS-XXX	NIS2 reporting	004
PMS-RSK-XXX	Risk management	004
PMS-THR-XXX	Threat model	002
PMS-PMS-XXX	PMS integration	004
PMS-PRO-XXX	Process integration	004

Total Unique Plan IDs: 73

Appendix B: Regulatory Cross-Reference

Regulation	Section	Requirement	Plan Section
FDA Cybersecurity Guidance	Section V.C	Vulnerability monitoring	Section 2
FDA Cybersecurity Guidance	Section VI	Coordinated disclosure	Section 6
MDR 2017/745	Article 83	Post-market surveillance	Section 9
MDR 2017/745	Annex III	Technical documentation	Section 9
NIS2 Directive	Article 23	Incident notification	Section 4.2
ISO/IEC 29147	Section 6	Disclosure policy	Section 6.1
IEC 62443-4-1	Section 7.4	Security updates	Section 5

Appendix C: Contact Information

Function	Contact	Availability
Security Hotline	+[Number]	24/7
Security Email	security@legithealth.com	Monitored 24/7
On-Call Security	Via PagerDuty	24/7
Regulatory Affairs	regulatory@legithealth.com	Business hours
Customer Support	support@legithealth.com	Business hours
Legal Counsel	legal@legithealth.com	Business hours

Appendix D: Acronyms and Definitions

• CVSS: Common Vulnerability Scoring System
• CVE: Common Vulnerabilities and Exposures
• CSIRT: Computer Security Incident Response Team
• DDoS: Distributed Denial of Service
• ENISA: European Union Agency for Cybersecurity
• FDA: Food and Drug Administration
• ICS-CERT: Industrial Control Systems Cyber Emergency Response Team
• ISAC: Information Sharing and Analysis Center
• MAUDE: Manufacturer and User Facility Device Experience
• MDR: Medical Device Regulation
• MITRE: Not an acronym (research organization)
• NIS2: Network and Information Security Directive 2
• NVD: National Vulnerability Database
• SBOM: Software Bill of Materials
• SIEM: Security Information and Event Management
• SOC: Security Operations Center / Service Organization Control
• SOUP: Software of Unknown Provenance
• SPDX: Software Package Data Exchange
• STIX/TAXII: Structured Threat Information Expression / Trusted Automated Exchange of Intelligence Information

Document Approval

This Cybersecurity Post-Market Surveillance Plan has been reviewed and approved by:

Role	Name	Date	Signature
Technical Director	[Name]	[Date]	[Signature]
Quality Manager	[Name]	[Date]	[Signature]
Security Officer	[Name]	[Date]	[Signature]
Regulatory Affairs Manager	[Name]	[Date]	[Signature]
Medical Director	[Name]	[Date]	[Signature]

---

End of Document - Version 1.0

This document is part of the Legit.Health Plus Quality Management System and is subject to change control procedures as defined in GP-001.