The Blueprint

The 5 Levels of FDA
Cybersecurity Readiness

Five levels. One model. Use it to benchmark your team and eliminate premarket documentation risks before filing.

Start free assessment →
1
Coming from: Baseline / Ad-hoc entry
Moving toward: Level 2 — Documented

Level 1: Reactive

Cybersecurity treated as an operational afterthought.

Security measures are completely detached from product architecture. Device design progresses until compliance friction forces an emergency check. Technical documentation is non-existent or purely nominal until an official FDA demand arrives.

Typically Present

  • Basic off-the-shelf OS security assumptions
  • Standard commercial developer methodologies
  • Informal engineering logs or notes

Missing Architecture

  • No dedicated SPDF lifecycle framework
  • No documented threat modeling assets
  • No production-ready SBOM artifacts
Regulatory Outcome Status High probability of a direct Refuse to Accept (RTA) decision or an extended 12+ month deficiency cycles during formal review.
Transition to Level 2:
  1. Formally isolate cybersecurity criteria into a separate engineering review checklist.
  2. Extract initial software composition inventories to build a static snapshot.
  3. Run an introductory vulnerability sweep on top-level runtime environments.
2
Coming from: Level 1 — Reactive
Moving toward: Level 3 — Integrated

Level 2: Documented

Basic compliance artifacts exist, but stay isolated in siloed silos.

Technical assets (like basic threat maps or static spreadsheets) are maintained internally but remain completely disconnected from the actual design controls process. Deliverables are checked off manually but lack system traceability features.

Typically Present

  • Manual or spreadsheet-based SBOM tracks
  • Drafted static threat matrices
  • Basic software update procedures outlined

Missing Architecture

  • Lack of cross-referenced component CVE traces
  • No full 524B gap validation matrix mappings
  • Threat model lacks end-to-end verification data
Regulatory Outcome Status Successfully bypasses basic RTA filters, but triggers significant Additional Information (AI) requests, delaying clinical commercial timelines.
Transition to Level 3:
  1. Convert static spreadsheets into standard machine-readable formats (CycloneDX JSON).
  2. Map every discovered system threat directly to design mitigation assets.
  3. Formalize a dedicated Vulnerability Management and Cybersecurity Plan.
3
Coming from: Level 2 — Documented
Moving toward: Level 4 — Proactive

Level 3: Integrated (The Compliance Baseline)

Cybersecurity formally engineered into 21 CFR 820.30 design controls.

Your Secure Product Development Framework (SPDF) is completely operational. Security controls are treated exactly like regular clinical indicators: designed with precision, tested dynamically, and structured to withstand institutional scrutiny.

Typically Present

  • CycloneDX / SPDX files cross-referenced with CVE databases
  • Dynamic threat modeling maps tied to active validation
  • Documented VMMP and live Coordinated Vulnerability Disclosure (CVD)

Missing Architecture

  • Automated post-market live alerting systems
  • Continuous deployment runtime testing sequences
  • Cross-functional institutional security governance
Regulatory Outcome Status High predictability for clean first-cycle FDA reviews with zero major cybersecurity deficiencies or structural documentation setbacks.
Transition to Level 4:
  1. Implement active vulnerability tracking software on internal deployment lines.
  2. Establish formal institutional SLAs to evaluate and patch runtime CVE alerts.
  3. Incorporate pre-submission guidance cycles with FDA reviewers for complex systems.
4
Coming from: Level 3 — Integrated
Moving toward: Level 5 — Continuous

Level 4: Proactive

Continuous postmarket monitoring paired with rapid response pipelines.

Compliance transitions from a premarket submission hurdle into an ongoing postmarket shield. The organization detects, patches, and publishes hotfixes long before third-party research networks identify downstream vectors.

Typically Present

  • Continuous automated dependency security scanners
  • Rigid internal critical patch deployment SLAs
  • Active vulnerability intake and testing operations

Missing Architecture

  • Automated regression tests during live compilation
  • Unified compliance indicators mapped to performance metrics
  • Fully integrated continuous AI/ML governance tracking
Regulatory Outcome Status Maintains pristine institutional compliance histories. Highly protected from unexpected field recalls or postmarket device safety alerts.
Transition to Level 5:
  1. Automate SBOM updates and compliance validations directly inside CI/CD lines.
  2. Establish ongoing metrics loops connecting security health to business KPIs.
  3. Formulate proactive testing playbooks for dynamic AI/ML models (PCCP tracks).
5
Coming from: Level 4 — Proactive
Moving toward: Total Operational Excellence

Level 5: Continuous

Compliance engineered directly into runtime code delivery systems.

Cybersecurity functions seamlessly as a competitive value asset rather than an administrative drag. Software changes automatically validate security indicators during active deployment. Regulatory frameworks expand naturally alongside scale expansion.

Typically Present

  • Automated compliance sign-offs integrated into code commits
  • Full alignment with active NIST CSF and ISO 27001 tracks
  • Predictive security operations built into systemic enterprise goals

Missing Architecture

  • None. Product development matches top military and critical asset standards.
Regulatory Outcome Status Unlocks total commercial freedom. Security infrastructure operates as an institutional trust magnet during major hospital enterprise sales cycles.
The Other Axis · Per-Device Requirement

How much documentation does your device need?

The five levels above measure how mature your team’s practice is. This is a different question — and it has a different answer for every product: how much software documentation does this specific device owe its premarket submission? The FDA’s answer is binary — Basic or Enhanced — and it turns on a single test.

Enhanced

The higher bar

Required when a failure or flaw of any device software function could present a hazardous situation with a probable risk of death or serious injury — to a patient, the user, or others in the environment of use. Crucially, this is assessed before your risk controls are applied.

Basic

Everything else

Applies to any submission with software functions where the Enhanced bar isn’t met. Still real documentation — just calibrated to a lower risk of serious patient harm.

Three categories default to Enhanced regardless of the test above: Class III devices, devices that are a constituent part of a combination product, and blood-related devices (BECS, donor screening, and donor/recipient compatibility). If you fall here and believe Basic is appropriate, you must document a detailed rationale for why.

Basic — FDA worked examples

  • Non-contact infrared thermometer
  • Non-invasive blood pressure monitor (cuff)
  • Optical pulse & breathing-rate measurement
  • Computerized behavioral therapy (psychiatric)
  • TBI eye-movement assessment aid
  • Implantable pulmonary-artery pressure sensor
  • OTC irregular-heart-rhythm app
  • IVD HPV nucleic-acid test (qualitative)
  • IVD influenza nucleic-acid test (qualitative)
  • Software on a commercial AR head-mounted display
  • Laser system for acne treatment
  • Radiological display device
  • Electric breast pump

Enhanced — FDA worked examples

  • Implantable cardiac pacemaker (bradycardia)
  • Facility-use continuous ventilator
  • Multi-parameter patient monitor
  • Blood Establishment Computer Software (BECS)
  • IVD Babesia blood-screening test
  • Infusion pump (healthcare facility)
  • IVD CMV nucleic-acid test (quantitative)
  • Sepsis-alarm software function
  • Continuous glucose monitoring system
  • Powered lower-extremity exoskeleton
  • Retinal diagnostic software device
  • Radiation therapy system (linear accelerator)

Notice the pattern: measurement, screening, and decision-support aids tend to land in Basic, while anything life-sustaining, high-acuity, or tied to the blood supply lands in Enhanced. An implantable sensor that only measures pressure is Basic; an implantable pacemaker that sustains a heartbeat is Enhanced. Intended use — not the device category — decides it.

Where the two axes meet

Your Documentation Level tells you how high the bar is. Your readiness level — the five above — tells you whether you can clear it on the first try. A device that needs Enhanced documentation, owned by a team operating at Level 1 or 2, is the exact profile that draws a Refuse to Accept. Reaching Level 3 (Integrated) is what lets you produce Enhanced-grade documentation as an output of your process, not a fire drill before filing.

Examples drawn from Appendix A of the FDA guidance “Content of Premarket Submissions for Device Software Functions.” They are illustrative, not definitive — the FDA is explicit that the appropriate Documentation Level must be determined uniquely for each device based on its intended use and risk assessment.

Where does your team sit?

Take the free 5-minute diagnostic assessment to benchmark your current level against official FDA Section 524B submission expectations.

Find Your Readiness Level