How SPDF Maps to IEC 81001-5-1 Activities

Part of our medtech cybersecurity framework choice series (SPDF, JSP2, IEC 81001-5-1). For the full overview, start with JSP2 vs SPDF vs IEC 81001-5-1: Framework Pick.

Teams shipping into both the United States and the European Union often ask the wrong version of this question. It is not "SPDF or IEC 81001-5-1?" It is "how do we run one lifecycle that satisfies both?" This post is the crosswalk that makes that possible.

If you are still choosing between frameworks, start with JSP2 vs SPDF vs IEC 81001-5-1: which framework should medtech pick? and IEC 81001-5-1 vs IEC 62304. This post assumes you have picked, or are planning to run, both.

Key Takeaways

• SPDF and IEC 81001-5-1 are the same lifecycle described in two vocabularies, not two lifecycles.
• Every SPDF outcome maps to one or more IEC 81001-5-1 clauses that produce the same evidence.
• The right operating model is one lifecycle, one artifact set, two labels.
• Run IEC 81001-5-1 as the spine when EU MDR/IVDR is in scope; label the artifacts SPDF-side for the FDA reviewer.
• The FDA's four architecture views live inside IEC 81001-5-1 clause 5.3 (security architecture) with no extra work.
• Postmarket vulnerability handling is where the two frameworks most obviously converge; do not duplicate CVD processes.

Table of Contents

• Key Takeaways
• Why this crosswalk exists
• Phase-by-phase mapping table
• Management and planning: SPDF outcomes → IEC 81001-5-1 clause 4
• Security requirements: SPDF → IEC 81001-5-1 clause 5.2
• Security architecture and threat modeling: SPDF → clauses 5.3 and 5.4
• Implementation: SPDF → clauses 6.1 and 6.2
• Verification and testing: SPDF → clause 7
• Release and transfer: SPDF → clause 8
• Postmarket: SPDF → clauses 9 and 10
• How to run one lifecycle with two labels
• How Blue Goat Cyber Approaches This
• Frequently Asked Questions
• CTA

Why This Matters

Running SPDF and IEC 81001-5-1 as two separate programs is a common and expensive mistake. The evidence is the same, the risk file is the same, the postmarket obligations are substantially the same. Teams that duplicate processes end up producing two threat models, two risk files, and two vulnerability management workflows that drift out of sync within 12 months. The next audit or deficiency letter forces a painful reconciliation.

The Feb 3, 2026 FDA final guidance explicitly says a manufacturer may use any of the four listed frameworks (SPDF, JSP2, IEC 81001-5-1, ISA/IEC 62443-4-1) provided the resulting submission contains the required content.[^fda2026] It does not require SPDF vocabulary. It requires SPDF-shaped artifacts. IEC 81001-5-1 produces those artifacts natively when the mapping is done up front.

Why this crosswalk exists

The FDA's guidance describes SPDF as a set of outcomes and expected artifacts: security risk management, threat modeling with four architecture views, SBOM with VEX, security testing, cybersecurity management plan, labeling, postmarket monitoring. IEC 81001-5-1 organizes the same territory as a numbered clause structure that ties directly to lifecycle phases.[^iec81001]

The crosswalk below is the one we use in engagements. It is not a formal FDA / IEC concordance (none exists); it reflects how reviewers and notified bodies actually consume the artifacts.

Phase-by-phase mapping table

SPDF outcome / artifact	IEC 81001-5-1 clause(s)	Shared artifact
Cybersecurity management plan	4.1 Quality management, 4.2 Security-management processes	One plan, dual-labeled
Security risk management (integrated with ISO 14971)	4.4 Security risk management process	ISO 14971-shaped risk file (extended per AAMI SW96)
Security requirements	5.2 Security requirements analysis	One requirements set, traceable both ways
Threat model with four architecture views	5.3 Security architecture (with 5.4 secure design)	One threat model document
Secure implementation and coding	6.1 Secure implementation, 6.2 Secure coding	Coding standard + static analysis output
SBOM (SPDX or CycloneDX) with VEX	6.3 Software of unknown origin / third-party components	One SBOM, one VEX
Security verification and validation	7.1-7.4 Security verification, including penetration testing	One security V&V report
Security release criteria and residual risk	8.1 Release, 8.2 Residual risk communication	One release checklist
Coordinated Vulnerability Disclosure (CVD)	9.4 Vulnerability handling, 9.5 CVD	One CVD process
Postmarket cybersecurity management plan	9.1-9.3 Postmarket security activities, 10 Maintenance	One postmarket plan
Labeling and customer security documentation	8.3 Documentation for the user / operator	One user-facing security guide

The pattern holds: every SPDF artifact has a home inside IEC 81001-5-1, and every IEC 81001-5-1 clause produces something the FDA expects to see. Duplication is unnecessary.

Management and planning: SPDF outcomes → IEC 81001-5-1 clause 4

SPDF opens with a cybersecurity management plan and the surrounding governance. IEC 81001-5-1 clause 4 covers the same ground under three sub-clauses: quality management integration (4.1), security-management processes (4.2), and security risk management (4.4). Produce one plan document that maps each of its sections to both structures. Reviewers on either side see a coherent governance artifact, not a translation exercise.

Security requirements: SPDF → IEC 81001-5-1 clause 5.2

SPDF expects security requirements traceable to threats and to verification. IEC 81001-5-1 clause 5.2 requires the same, with a slightly heavier emphasis on secure-by-design and secure-by-default posture. Produce a single requirements set. Tag each requirement with both the SPDF outcome it satisfies and the IEC 81001-5-1 clause it derives from. Traceability is the shared spine.

Security architecture and threat modeling: SPDF → clauses 5.3 and 5.4

This is where the mapping is most often mishandled. The FDA guidance calls for four architecture views: global system, multi-patient harm, updateability, and security use cases. IEC 81001-5-1 clause 5.3 requires a documented security architecture; clause 5.4 requires secure-design decisions. The four FDA views satisfy both clauses without modification. Produce the four views once, label them as the security architecture under IEC 81001-5-1, and reviewers on both sides get the artifact they expect.

Threat modeling itself sits alongside the architecture. Use STRIDE (or an equivalent) once, harm-oriented, and feed the outputs into the ISO 14971 risk file. Both frameworks accept the same threat model.

Talk to a MedTech cybersecurity expert about running one lifecycle across both frameworks

Operationalizing the SPDF against IEC 81001-5-1?

Blue Goat Cyber is a medical-device-only cybersecurity firm. Our team runs the threat modeling, penetration testing, and FDA-facing documentation MedTech submissions live or die on. → Secure MedTech product design consulting

Implementation: SPDF → clauses 6.1 and 6.2

SPDF asks for secure implementation and coding standards. IEC 81001-5-1 clauses 6.1 and 6.2 require the same, with an explicit call-out for tool-supported analysis (SAST). A single coding standard, a single SAST configuration, and a single static-analysis output stream serve both frameworks. The FDA does not need to see the tool configuration; it needs to see that findings were triaged, remediated or accepted, and traced back to requirements. IEC 81001-5-1 asks for the same evidence.

SBOM handling belongs here too. Clause 6.3 covers software of unknown origin (SOUP) and third-party components. One SBOM in SPDX or CycloneDX with a VEX overlay satisfies both frameworks and Section 524B(b)(3).

Verification and testing: SPDF → clause 7

See also: IEC 81001-5-1 vs AAMI SW96, AAMI TIR57 vs TIR97 vs SW96, and MedTech Cyber Standards Every Device.

SPDF's security testing expectation matches IEC 81001-5-1 clause 7 point for point: security verification, security validation, and penetration testing where the risk profile warrants it. Produce one V&V report. Penetration test evidence goes in the same artifact. The FDA's guidance is more prescriptive on penetration-test scope for connected devices; IEC 81001-5-1 defers to risk-proportionate testing. Meet the FDA's bar and the IEC clause is satisfied automatically.

Release and transfer: SPDF → clause 8

Both frameworks require a security release decision with documented residual risk. IEC 81001-5-1 clause 8 splits this into the release decision (8.1), residual-risk communication to the operator (8.2), and user documentation (8.3). SPDF bundles the same content into the cybersecurity management plan and labeling. One release checklist, one residual-risk statement, and one user-facing security document cover both.

Postmarket: SPDF → clauses 9 and 10

SPDF's postmarket obligations (monitoring, patching, CVD, incident response) map to IEC 81001-5-1 clauses 9 (postmarket security activities) and 10 (maintenance). The pairing is straightforward: run one CVD process, one vulnerability triage cadence, one patching workflow. The FDA's postmarket cybersecurity management plan is the artifact; IEC 81001-5-1 clause 9 is the process behind it.

For the deeper postmarket picture, see how JSP2 and MDS2 fit together — MDS2 lives in this postmarket space regardless of which framework you pick.

How to run one lifecycle with two labels

Three operational rules make this work in practice:

1. Pick the spine, then dual-label everything. For US-only devices, SPDF is the natural spine and IEC 81001-5-1 mapping is optional. For dual FDA + EU submissions, run IEC 81001-5-1 as the spine and label the artifacts with SPDF outcome names in the artifact headers or the cybersecurity management plan. Reviewers on either side see native vocabulary.
2. One risk file. Do not maintain a separate security risk file per framework. Use ISO 14971 as the container (extended per AAMI SW96) and let both frameworks read from it.
3. One CVD process. Do not stand up two vulnerability workflows. One inbox, one triage, one disclosure log, mapped to both frameworks.

Teams that follow these three rules typically see 30-40 percent less lifecycle documentation overhead than teams running parallel programs.

How Blue Goat Cyber Approaches This

Blue Goat Cyber's dual-framework engagement produces a single artifact set with SPDF and IEC 81001-5-1 dual-labeling embedded from day one. The output is a cybersecurity management plan, threat model with four FDA views, integrated ISO 14971 + AAMI SW96 risk file, SBOM + VEX, security V&V report, and postmarket plan, all labeled to both frameworks. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.

Christian Espinosa, our founder, has led dual FDA + EU MDR cybersecurity submissions on more than 60 devices under this exact operating model.

Frequently Asked Questions

Do I have to pick between SPDF and IEC 81001-5-1?

No, not if you produce the artifacts correctly. The FDA lists both as acceptable; the EU expects IEC 81001-5-1. Run IEC 81001-5-1 as the spine for dual submissions and label artifacts with SPDF outcome names.

Does the FDA reviewer need the IEC 81001-5-1 clause numbers in the submission?

No. Reviewers grade the artifacts against the guidance's expected content, not the clause number they came from. Include the mapping in the cybersecurity management plan so the reviewer can trace it if they want; do not clutter every artifact with clause references.

What about ISO 14971 and AAMI SW96?

Both frameworks assume ISO 14971 as the risk-management container. AAMI SW96:2023 formalizes the security extension. One risk file, one process, feeds both SPDF and IEC 81001-5-1.

Where do the four FDA architecture views live in IEC 81001-5-1?

Inside clause 5.3 (security architecture) with support from clause 5.4 (secure design). Produce the four views (global system, multi-patient harm, updateability, security use cases) once, and both frameworks are satisfied.

Can I map JSP2 the same way?

Yes. JSP2 has a similar phase structure and maps cleanly onto both SPDF outcomes and IEC 81001-5-1 clauses. See JSP2 vs SPDF vs IEC 81001-5-1 for how JSP2 fits into the framework choice, and treat this crosswalk as the SPDF ⇄ 81001-5-1 backbone underneath.

What is the biggest failure mode?

Running two parallel programs. Two threat models, two risk files, two CVD processes drift out of sync fast, and the next audit or FDA deficiency letter forces a costly reconciliation. Pick one spine, dual-label the artifacts, run one workflow.

CTA

If you are running SPDF and IEC 81001-5-1 as two separate programs, you are paying twice for the same lifecycle. Blue Goat Cyber runs a three-week dual-framework consolidation engagement that collapses the two into a single artifact set with dual-labeling, ready for FDA reviewers and EU notified bodies alike. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Book a discovery session.

Christian Espinosa, Founder, Blue Goat Cyber. CISSP, CCISO, ex-military red team. Has led dual SPDF + IEC 81001-5-1 cybersecurity submissions on 60+ FDA- and EU-cleared devices. More on the author.

References