What is a test readiness review?

It is the first-week check in a Blue Goat Cyber medical device penetration test. We review your threat model, hazard analysis, and architecture against a fixed list, mark each item met, partly met, or not met, and confirm the test can trace each finding back to a threat, a hazard, and a component.

What if items are not met?

Testing still goes ahead. The memo tells you what each gap means for traceability and what to fix before you submit. If the gaps are large, we can scope deeper rework separately at a fixed fee.

Is it the same as a threat model gap assessment?

No. The readiness review is a short check inside a penetration test, focused on whether the test can be aimed and traced. A gap assessment is a stand-alone, deeper review of your threat model and hazard analysis against FDA expectations, starting at $5,000.

Does it cover the eSTAR software documents?

Part C checks that the eSTAR software architecture diagram, the security architecture views, the threat model, and the SBOM describe the same system and version. It does not review the other software documents, which your team prepares.

Part of every penetration test

Week 1 test readiness review

Before we test, we check that your threat model, hazard analysis, and eSTAR architecture diagram line up, so every finding traces from diagram to threat to patient harm.

How it works

In the first week of a medical device penetration test, we review your threat model, hazard analysis, security architecture views, and eSTAR software architecture diagram against the checklist below. You get a short review memo with each item rated, in three parts.

Met

Ready for testing and traceable.

Partly met

Testing can proceed; fix before you submit.

Not met

A traceability gap a reviewer is likely to question.

Part A: Threat model

Is the threat model complete enough to aim the test at the right places?

ID	What we check	Why it matters for the test
A1	The system is modeled with data flows, data stores, processes, external entities, and trust boundaries.	Without the full system, test targets are guesses.
A2	Every entry point in scope is represented, with protocols named on high-value flows.	Each entry point becomes a test target.
A3	Threats are listed per element using STRIDE, each with a stable threat ID.	Findings in the report trace back to these IDs.
A4	STRIDE sorts threats into types; it is not used to score them.	Mixing the two hides which threats matter most.
A5	Risk is scored on exploitability, not likelihood or probability.	The FDA expects exploitability for security risk.
A6	Each threat has a control strategy: eliminate, mitigate, accept, or transfer.	Mitigated threats get tests that prove the control works.
A7	Assumptions and security context are stated, including the update path and system boundaries.	Unstated assumptions become untested gaps.

Part B: Hazard analysis

Does each security threat connect to patient harm?

ID	What we check	Why it matters for the test
B1	Cybersecurity-initiated hazards are included, especially the patient effects of losing confidentiality, integrity, or availability.	Test findings are rated by patient harm, not CVSS alone.
B2	Severity is rated on the ISO 14971 scale, separately from security scoring.	Severity and exploitability are two different questions.
B3	Threat IDs map to hazard IDs.	This is the link a reviewer follows from finding to harm.

Part C: eSTAR architecture diagram and security views

Do the eSTAR software architecture diagram, the security architecture views, and the threat model describe the same system?

ID	What we check	Why it matters for the test
C1	The security views start from the same system as the eSTAR software architecture diagram.	Two different pictures of one device draw reviewer questions.
C2	Components use the same names in the diagram, views, threat model, and SBOM.	Mismatched names break traceability.
C3	Every external interface in the diagram crosses a trust boundary in the views and appears in the threat model.	Missing interfaces are missing test targets.
C4	The global system view shows which paths could reach many devices from one entry point.	Multi-patient harm paths get their own tests.
C5	The updatability view matches the update path in the threat model.	Update-path tests, such as unsigned or older firmware, come from here.
C6	The diagram, views, threat model, and SBOM all describe the same software version.	The test must run on the version you submit.

How Part C matches the eSTAR diagram

The eSTAR asks for a software architecture diagram in the software section and security architecture views in the cybersecurity section. They should be two views of one system. Part C checks that rule before testing, because the test targets come from the interfaces and trust boundaries in those pictures. See FDA cybersecurity architecture views for the side-by-side comparison, and eSTAR software documents and cybersecurity for how the two sections stay consistent.

Get ready before testing

Try the free Threat Model Starter, read the cybersecurity hazard analysis guide, or book a threat model gap assessment for a deeper review.

FAQ

What is a test readiness review?: It is the first-week check in a Blue Goat Cyber medical device penetration test. We review your threat model, hazard analysis, and architecture against a fixed list, mark each item met, partly met, or not met, and confirm the test can trace each finding back to a threat, a hazard, and a component.
What if items are not met?: Testing still goes ahead. The memo tells you what each gap means for traceability and what to fix before you submit. If the gaps are large, we can scope deeper rework separately at a fixed fee.
Is it the same as a threat model gap assessment?: No. The readiness review is a short check inside a penetration test, focused on whether the test can be aimed and traced. A gap assessment is a stand-alone, deeper review of your threat model and hazard analysis against FDA expectations, starting at $5,000.
Does it cover the eSTAR software documents?: Part C checks that the eSTAR software architecture diagram, the security architecture views, the threat model, and the SBOM describe the same system and version. It does not review the other software documents, which your team prepares.

Ready to scope a test? Book a discovery call.