SPDF vs IEC 62304: Avoid Costly Documentation Mistakes

June 25, 2025

How FDA’s Secure Product Development Framework Enhances Software Lifecycle Processes While Requiring Separate Documentation Packages

TL;DR

Understanding SPDF vs IEC 62304 is crucial for medical device teams navigating today’s regulatory landscape. SPDF (Secure Product Development Framework) is “a set of processes that reduce the number and severity of vulnerabilities throughout the device lifecycle”—it enhances rather than replaces your existing IEC 62304 software development processes.

Key distinction: While SPDF integrates with IEC 62304 workflows, FDA requires separate documentation packages—software submissions need 9-10 attachments while cybersecurity submissions require 12 distinct attachments plus specialized testing documentation.

What you’ll learn: How to implement SPDF within existing IEC 62304 processes, coordinate dual documentation requirements, and leverage security activities that serve both software and cybersecurity submission needs without duplicating effort.

Two Frameworks, One Goal

Software teams have spent years mastering IEC 62304’s disciplined approach to medical device software lifecycle processes. Your team follows established procedures for planning, requirements analysis, architectural design, and verification. Life was structured, predictable, and compliant.

Then FDA added new rules around cybersecurity.

Suddenly, your proven software development framework faces new challenges. The medical device cybersecurity framework requirements seem to demand entirely new processes, documentation, and expertise. Teams are asking: How do SPDF vs IEC 62304 requirements actually fit together?

The answer isn’t replacement—it’s intelligent enhancement. SPDF represents the security evolution of proven software lifecycle practices, designed to work alongside, not against, your existing IEC 62304 foundation.

What is SPDF and Why Software Teams Need It

SPDF Defined

The Secure Product Development Framework (SPDF) is FDA’s recommended approach for integrating cybersecurity throughout the device lifecycle. According to FDA’s 2023 cybersecurity guidance, SPDF is “a set of processes that reduce the number and severity of vulnerabilities in products throughout the device lifecycle.”

SPDF isn’t a competing standard—it’s a software lifecycle security overlay that complements existing frameworks. FDA explicitly recognizes that manufacturers may use frameworks like IEC 62304 that “satisfy the QS regulation and align with FDA’s recommendations for using an SPDF.”

The Documentation Reality: Separate But Coordinated

Here’s what many teams miss in the SPDF vs IEC 62304 discussion: while these frameworks work together operationally, they require distinct documentation packages for FDA submissions.

Software documentation requirements:

Basic Documentation Level: 9 attachments
Enhanced Documentation Level: 10 attachments
Can leverage IEC 62304 Declaration of Conformity for lifecycle processes

Cybersecurity documentation requirements:

12 separate attachments regardless of software documentation level
Plus cybersecurity labeling requirements
Plus interoperability documentation
Specialized testing reports (penetration testing, fuzz testing, etc.)

Understanding this distinction is crucial for resource planning and avoiding submission delays. Your secure software development lifecycle activities can inform both packages, but each requires specific deliverables.

The Dual Documentation Landscape

FDA’s Software Documentation Framework

FDA uses a risk-based approach to determine software documentation requirements. The Basic vs Enhanced Documentation Level decision depends on whether software failure could present “a probable risk of death or serious injury.”

Basic Documentation Level includes:

Software Attachments
Documentation Level Evaluation
Software / Firmware Description
Risk Management File
Software Requirements Spec (SRS)
System and Software Architecture Design (SAD) Chart
Software Life Cycle Process Description
Software Testing as Part of Verification & Validation
Software Version / Revision Level History
Unresolved Software Anomalies

Enhanced Documentation Level adds:

Detailed Software Design Specifications (SDS)
Enhancements to “Basic” documents:
- Complete configuration management documentation
- Unit and integration level test protocols
- More comprehensive verification evidence

Teams can satisfy some these requirements through IEC 62304 Declaration of Conformity, particularly for lifecycle processes, configuration management, and maintenance practices.

FDA’s Cybersecurity Documentation Requirements

FDA premarket cybersecurity submissions require a completely separate package focusing on security-specific considerations:

Cybersecurity Management Plan – distinct from Software Development Plan
Risk Management Report
Threat Model – particularly for connected devices
Cybersecurity Risk Assessment – using frameworks like CVSS
Software Bill of Materials
Software Level of Support
Safety and Security Assessment
Security Assessment of Unresolved Anomalies
Cybersecurity Metrics
Cybersecurity Controls
Security Architecture Views – beyond basic software architecture
Cybersecurity Testing

In addition, FDA requests information on Cybersecurity Labeling and Interoperability.

The Integration Opportunity

Smart teams recognize that while documentation packages are separate, the underlying SPDF activities can efficiently serve both requirements. Cybersecurity starts with security architecture planning that informs both software design and security documentation needs.

SPDF Integration Within IEC 62304 Processes

Software Development Planning Enhancement (IEC 62304 Section 5.1)

Enhanced Software Development Plan

Your existing IEC 62304 Software Development Plan can incorporate security considerations without losing its primary focus:

Security risk management planning alongside traditional software risk management
Security standards and tools identified within development methodology
Security verification planning integrated with software verification activities
Security configuration management within existing change control processes

The key insight in SPDF vs IEC 62304 integration: your enhanced Software Development Plan becomes more comprehensive while maintaining IEC 62304 compliance.

Separate Cybersecurity Management Plan Required

However, FDA cybersecurity requirements mandate a distinct Cybersecurity Management Plan addressing:

Post-market vulnerability monitoring and identification processes
Coordinated vulnerability disclosure procedures
Customer communication protocols for security issues
Security update deployment and patch management processes
Integration with healthcare delivery organization security frameworks

This plan complements but doesn’t replace your Software Development Plan—think of it as the security lifecycle management companion to your software lifecycle management.

Software Requirements Analysis Security Integration (IEC 62304 Section 5.2)

Enhanced Software Requirements Specification

SPDF integration transforms requirements analysis by incorporating FDA’s five security objectives:

Authenticity (including integrity)
Authorization
Availability
Confidentiality
Secure and timely updatability and patchability

These security requirements integrate naturally with functional requirements while maintaining clear traceability to both safety hazards and security threats.

Threat Modeling Integration

While IEC 62304 focuses on hazard analysis for safety, SPDF adds threat modeling for security. Teams can conduct both analyses using similar systematic approaches:

Safety hazard analysis: “What could go wrong with the software?”
Security threat analysis: “How could an attacker exploit the software?”

Both analyses inform requirements, but serve different risk management objectives.

Software Architectural Design Security Enhancement (IEC 62304 Section 5.3)

Security-Enhanced Architecture Documentation

Your software architecture documentation can satisfy both IEC 62304 and SPDF needs by including:

Security domains and boundaries within the software architecture
Security control placement and implementation strategy
Data flow security considerations and data flow diagrams
Interface security for internal and external connections

Separate Security Architecture Views

However, cybersecurity submissions require dedicated Security Architecture Views that go beyond software architecture:

Global System View: Device within healthcare IT ecosystem
Multi-Patient Harm View: Security controls preventing cross-patient impact
Updatability and Patchability View: Secure update mechanisms
Security Use Case View: Threat scenarios and mitigations

These views use your software architecture as foundation but focus specifically on security concerns.

Software Testing: Enhancement vs. Separation

Software Verification and Validation Enhancement

Your existing IEC 62304 testing processes can incorporate security verification:

Unit testing: Include verification of security controls within existing unit test protocols
Integration testing: Verify security interfaces and data protection during integration
System testing: Validate security requirements alongside functional requirements
Test traceability: Link security tests to security requirements and risk controls

This enhanced approach leverages existing testing infrastructure while ensuring security controls receive proper verification.

Separate Cybersecurity Testing Documentation

However, FDA requires specialized cybersecurity testing that goes beyond traditional software verification:

Vulnerability Testing Requirements:

Fuzz testing for robustness validation
Attack surface analysis to identify exposure points
Vulnerability scanning using automated tools
Static and dynamic code analysis including security code review

Penetration Testing Requirements:

Independent testing: Documentation of tester independence from development team
Comprehensive scope: Network, application, and physical security testing
Detailed reporting: Methods, findings, and manufacturer assessment of results
Remediation plans: How identified vulnerabilities will be addressed

This specialized testing complements but doesn’t replace software verification and validation—it provides security-specific validation that traditional testing cannot achieve.

Risk-Based Documentation Alignment

IEC 62304 Safety Classes Meet FDA Documentation Levels

Understanding how medical device cybersecurity framework requirements align with existing safety classifications helps teams plan efficiently:

Class A Software (No injury or damage possible):

Usually qualifies for Basic Documentation Level
Minimal security risk typically doesn’t elevate requirements
SPDF integration focuses on foundational security practices

Class B Software (Non-life-threatening injury possible):

May require Enhanced Documentation if cybersecurity risks are significant
Security controls implementation becomes more rigorous
Cybersecurity risk assessment can influence documentation level decision

Class C Software (Death or serious injury possible):

Almost always requires Enhanced Documentation Level
Comprehensive cybersecurity documentation expected
Full SPDF implementation typically necessary

Security Risk Influence: In the SPDF vs IEC 62304 comparison, remember that cybersecurity threats can elevate documentation requirements beyond traditional safety classification. A Class A device with significant connectivity and data handling may require Enhanced Documentation due to cybersecurity risk.

Documentation Package Resource Planning

Basic Software + Full Cybersecurity Documentation:

9 software attachments + 12 cybersecurity attachments
Streamlined software package but comprehensive security documentation
Common for devices with lower software risk but significant connectivity

Enhanced Software + Full Cybersecurity Documentation:

10 software attachments + 12 cybersecurity attachments
Maximum documentation burden requiring significant resources
Typical for Class C software in connected devices

Teams should budget accordingly—cybersecurity documentation represents substantial additional effort regardless of software documentation level.

Lifecycle Management: Coordinated But Distinct

Software Maintenance Enhancement (IEC 62304 Section 6)

SPDF enhances existing software maintenance processes:

Problem Resolution Integration:

Security vulnerability handling within existing software problem resolution
Security impact assessment for software changes
Coordinated approach to safety and security anomalies

Configuration Management Enhancement:

Security patches managed through existing software configuration control
Version control includes security-relevant changes
Change impact assessment includes security implications

Change Control Integration:

Security considerations integrated into existing change control processes
FDA cybersecurity requirements addressed within established workflows
Unified approach to software change management

Separate Post-Market Cybersecurity Requirements

However, cybersecurity lifecycle management requires distinct processes:

Cybersecurity Management Plan Execution:

Vulnerability monitoring: Systematic surveillance of security threat landscape
Threat intelligence: Integration with industry security information sources
Security signal processing: Evaluation and triage of potential security issues

Coordinated Vulnerability Disclosure:

Stakeholder notification: Communication with healthcare delivery organizations
Industry coordination: Information sharing with other manufacturers and security organizations
Regulatory reporting: Notification to FDA and international regulators as required

Customer Security Communication:

Security advisories: Timely notification of security issues
Patch deployment: Secure update delivery and installation
Configuration guidance: Ongoing security configuration recommendations

Beyond Software: Cybersecurity-Specific Requirements

Cybersecurity Labeling Requirements

Traditional IEC 62304 processes don’t address cybersecurity labeling, but FDA requires comprehensive security information for users:

Instructions for Use Enhancement:

Security configuration guidance: How to securely set up and operate the device
Network requirements: Security prerequisites for device connectivity
User security responsibilities: What healthcare organizations must do to maintain security

Vulnerability Contact Information:

Clear reporting pathways: How to report suspected security vulnerabilities
Contact mechanisms: Email, phone, or web form for security issues
Response expectations: Timeline and process for security issue handling

End-of-Life Security Information:

End-of-support notifications: When security updates will no longer be available
Risk transfer process: How cybersecurity risks transfer to customers after support ends
Decommissioning guidance: Secure disposal and data sanitization procedures

Interoperability Documentation

Connected medical devices require security analysis beyond individual software functionality:

System Integration Security:

Healthcare IT ecosystem analysis: How device security integrates with hospital networks
Data flow security: Protection of data in transit and at rest
Third-party integration: Security implications of connected systems and services

Network Security Requirements:

Connectivity prerequisites: Network security controls required for safe operation
Interface security: Protection of communication interfaces and APIs
Authentication and authorization: How device integrates with healthcare identity management

This interoperability analysis extends beyond traditional software architecture documentation and requires specialized cybersecurity expertise.

Implementation Strategy: Coordinated Development

Process Integration Planning

Unified Security Activities: The smartest approach to SPDF vs IEC 62304 implementation recognizes that single security activities can inform multiple documentation requirements:

Security risk assessment: Serves both software risk management and cybersecurity risk assessment needs
Security architecture design: Informs software architecture documentation and security architecture views
Security testing: Provides evidence for both software verification and cybersecurity testing requirements

Resource Allocation Strategy:

Cross-functional teams: Software and cybersecurity experts working together
Shared deliverables: Security activities that serve multiple documentation needs
Coordinated timelines: Parallel development of software and cybersecurity documentation

Tool Integration:

Requirements management: Tools that handle both functional and security requirements
Test management: Systems that coordinate software and security testing
Document management: Platforms that maintain traceability across both documentation packages

Practical Implementation Steps

Phase 1: Assessment and Planning

Current state analysis: Evaluate existing IEC 62304 implementation maturity
Gap assessment: Identify where SPDF integration is needed
Resource planning: Budget for dual documentation requirements
Team preparation: Train existing software teams on security concepts

Phase 2: SPDF Integration

Enhanced planning: Update Software Development Plans with security considerations
Requirements integration: Incorporate security requirements into existing requirements management
Architecture enhancement: Add security considerations to software architecture design
Process integration: Embed security activities within existing software development workflows

Phase 3: Documentation Preparation

Software documentation: Prepare enhanced IEC 62304-compliant documentation
Cybersecurity documentation: Develop separate cybersecurity submission package
Cross-reference management: Ensure traceability between software and security documentation
Review and validation: Verify both packages meet FDA requirements

Phase 4: Continuous Improvement

Process refinement: Optimize integration based on experience
Tool enhancement: Improve systems for managing dual documentation requirements
Team development: Build expertise in both software and cybersecurity domains
Stakeholder feedback: Incorporate lessons learned from regulatory interactions

Cost-Benefit Analysis: Investment vs. Value

Understanding the Investment

Increased Documentation Burden: Teams must plan for significantly expanded documentation requirements:

Dual submission packages: Software documentation (9-10 attachments) plus cybersecurity documentation (12 attachments)
Specialized expertise: Security testing, threat modeling, and vulnerability assessment capabilities
Ongoing maintenance: Post-market cybersecurity management and vulnerability response
Training investment: Building team capabilities in both domains

Resource Implications: The SPDF vs IEC 62304 discussion isn’t just about technical integration—it’s about resource allocation. Cybersecurity adds substantial documentation and ongoing management requirements that teams must budget for appropriately.

Value Proposition

Regulatory Efficiency: Coordinated SPDF implementation provides significant benefits:

Reduced duplication: Single security activities serving multiple documentation needs
Faster submissions: Well-integrated processes reduce preparation time
Lower rejection risk: Comprehensive approach reduces common FDA rejection reasons
Market access: Meeting both software and cybersecurity requirements enables device approval

Operational Benefits:

Risk mitigation: Comprehensive safety and security coverage protects patients and business
Competitive advantage: Strong cybersecurity posture differentiates products in the market
Future readiness: Preparation for evolving regulatory landscape and emerging threats
Customer confidence: Healthcare organizations increasingly require strong cybersecurity

Long-term Value: While the initial investment is substantial, the medical device cybersecurity framework requirements are only going to become more stringent. Early investment in coordinated SPDF and IEC 62304 processes positions teams for long-term success.

Integration with Clear Boundaries

The SPDF vs IEC 62304 question isn’t really about choosing between frameworks—it’s about understanding how they work together while maintaining distinct requirements. SPDF enhances your existing software lifecycle processes while requiring separate cybersecurity documentation that goes far beyond traditional software development.

Key insights for implementation:

Process Integration: SPDF security activities should be embedded within existing IEC 62304 workflows wherever possible. Your Software Development Plan, requirements analysis, architectural design, and testing processes can all be enhanced with security considerations without losing their primary focus.

Documentation Separation: While processes integrate, documentation packages remain distinct. Plan for 9-10 software attachments plus 12 cybersecurity attachments, each requiring specific content and expertise.

Resource Planning: The dual documentation requirement represents significant additional effort. Budget accordingly and build cross-functional teams that can efficiently serve both software and cybersecurity submission needs.

Continuous Evolution: Both software lifecycle security requirements and cybersecurity threats continue evolving. Build processes that can adapt to changing regulatory expectations and emerging security challenges.

Future Readiness: Teams that successfully integrate SPDF with IEC 62304 now will be best positioned for future regulatory changes and market demands. The investment in coordinated processes pays dividends as cybersecurity requirements become more stringent.

Start with SPDF integration planning that serves both your software and cybersecurity documentation needs. Focus on security activities that efficiently support multiple submission requirements. Build the capability to manage dual documentation packages while leveraging the strong foundation your IEC 62304 processes already provide.

The future belongs to teams that can seamlessly blend software safety and security throughout the device lifecycle—without losing the discipline and structure that made their software development successful in the first place.

Need help with your cybersecurity or IEC 62304 process and documentation? Email us at [email protected].