The Security Management Plan: Your Foundation

A security management plan is the document that defines which security activities your device program will run, who owns them, when they happen, and how they connect to your quality system. FDA reviewers and auditors look for it first, and every later activity in this chapter traces back to it.

3.2.1 What Is a Security Management Plan?

A security management plan is like a project charter specifically for cybersecurity. It defines:

• What security activities will happen
• Who is responsible for each activity
• When activities occur in the development process
• How security integrates with other processes
• Why each activity matters for patient safety

According to the Joint Security Plan (JSP), this plan "establishes the foundation for all cybersecurity activities throughout the Total Product Life Cycle (TPLC)."

3.2.2 Key Elements of an Effective Plan

Your security management plan should address these essential components:

Integration with Risk Management

Security risk management doesn't exist in isolation. Per the FDA's expectations and ISO 14971 requirements, it must integrate seamlessly with your overall risk management process. This means:

• Unified risk files: Security risks appear alongside safety risks
• Common risk scales: Use consistent severity and probability ratings
• Shared review processes: Security and safety teams review risks together
• Integrated documentation: One risk management report covers both domains

Clear Risk Definitions

Define what makes a security risk acceptable or unacceptable. For example:

• Unacceptable: Any risk that could lead to patient death or serious injury
• Acceptable with controls: Risks reduced to levels comparable to similar devices
• Acceptable as-is: Risks with extremely low probability and minimal impact

These definitions must align with your overall risk acceptability criteria under ISO 14971.

Roles and Responsibilities

Clearly define who does what:

Security Risk Manager

• Owns the security risk management process
• Ensures activities happen on schedule
• Reports to leadership on security posture
• Coordinates between teams

Development Team

• Implements security requirements
• Participates in threat modeling
• Fixes security vulnerabilities
• Documents security decisions

Quality Team

• Reviews security documentation
• Ensures process compliance
• Manages security within QMS
• Approves security risk acceptability

Leadership

• Provides resources for security
• Makes final risk acceptance decisions
• Ensures organizational commitment
• Reviews security metrics

Documentation Structure

Plan how security documentation will be organized:

• Where security requirements live
• How threat models are stored
• Risk assessment locations
• Traceability approaches
• Version control methods

3.2.3 Creating Your Security Management Plan

The JSP provides this guidance for inputs to consider:

Potential Inputs:

• Development Plan
• User Needs
• Change Impact Assessment
• Risk Management Plan (safety)
• Security Risk Procedure and/or Product Security Policy

The Output: A comprehensive Security Risk Management Plan that guides all security activities

Here's a practical template structure:

1. Purpose and Scope

   • Device/system covered
   • Lifecycle phases included
   • Integration points with other processes

2. Security Objectives

   • Alignment with FDA's five objectives
   • Device-specific security goals
   • Success criteria

3. Organization

   • Roles and responsibilities
   • Reporting structure
   • Decision-making authority

4. Activities and Deliverables

   • Security requirements development
   • Architecture and design reviews
   • Threat modeling sessions
   • Risk assessments
   • Verification and validation
   • Post-market monitoring

5. Risk Management Integration

   • How security risks flow into ISO 14971 process
   • Risk acceptability criteria
   • Review and approval procedures

6. Tools and Methods

   • Threat modeling approaches
   • Risk scoring methods (e.g., CVSS)
   • Security testing tools
   • Documentation tools

7. Schedules and Milestones

   • Activity timing
   • Review gates
   • Deliverable due dates