What Part 7 actually is
Part 7 is informative, not normative — it doesn't add requirements of its own. It's the reference catalog that Parts 2 and 3 point to when they say a technique is "Highly Recommended," "Recommended," or "Not Recommended" at a given SIL: Part 7 is where each of those named techniques actually gets defined, in a page or two apiece, with what it is and when it applies.
The five annexes
Highlighted: Annex B, which explicitly covers both hardware (Part 2) and software (Part 3) since systematic failure isn't unique to either one — and Annex C, the software-specific technique catalog.
Where FMEA formally sits
FMEA appears in Annex B, under B.6.6, "Failure analysis" — one of the techniques listed for E/E/PES safety validation, alongside cause-consequence diagrams, event tree analysis, FMECA, and fault tree analysis. Because it's written into Annex B rather than the software-only Annex C, it's framed as a general E/E/PE technique that applies across hardware and software both — not a method Part 7 ever tailors specifically for software.
Annex C's own toolkit
Annex C — the software-specific annex Part 3 actually points to — opens with structured methods for requirements and detailed design (C.2.1) and builds out its own catalog: modelling, formal methods, defensive programming, and structured programming among them. FMEA isn't one of Annex C's named entries; when a project wants to run one against software, it's importing B.6.6's generic hardware-flavored version rather than following software-specific instructions Part 7 provides.
The gap this leaves
A short, general description of FMEA as an E/E/PES failure-analysis technique — component-oriented in spirit, with no discussion of software failure modes, no occurrence guidance, and no software-specific worked example.
The same needs identified elsewhere in this series — a real software failure-mode taxonomy such, evidence-based occurrence rating and an approach that doesn't assume software fails at the discrete component level the way hardware does. The 6D CDE Software FMEA approach is exactly what fills these gaps. It is based on a structured software failure mode taxonomy - the Common Defect Enumeration. It assumes that software failures because of faulty design flows and specifications as opposed to the hardware centric CSCI/piece part viewpoint. It also considers the software failure modes within the context of the software, electronics, system, user, mission and environment.
How this connects to the rest of IEC 61508
This is the same split covered on the companion IEC 61508 page: Part 2 leans on FMEA/FMEDA to quantify random hardware failure, Part 3 has no failure rate to quantify, so it favors process and structural techniques instead. Part 7's B.6.6 entry doesn't resolve that gap — it just confirms that FMEA is on the books for software validation, without adapting it. Filling that gap is exactly the job the 6D CDE FMEA -based approaches (SAE1025, IEEE 1633, the 6D CDE model) were built to do.