One document that ties every planned change in your PCCP to your threat model and risk assessment, so a reviewer can see what each change touches and how you will prove it is still secure.
The PCCP cybersecurity appendix is a deliverable in our PCCP cybersecurity engagements. For each class of planned change, it names the threat model elements and Threat Table rows affected, the security risk impact traced to your ISO 14971 file, the triggers that force a full reassessment, and the tests and pass criteria needed before release.
Every planned change in your PCCP, grouped into classes (for example model retraining, cryptographic library upgrade, OS baseline update). Each class gets an ID that the rest of the appendix refers back to.
For each class, the data flow elements, trust boundaries and entry points it can touch, and the Threat Table rows it could change. A class that touches nothing security-relevant says so, with the reason.
For each affected Threat Table row, how the change could move exploitability, which harm in your ISO 14971 file it traces to, and whether residual risk could cross your acceptance criteria. Severity stays on your existing safety scale.
The conditions that send a change back to the full threat model and risk assessment instead of the PCCP route: a new entry point, a new trust boundary, a new data type, or a residual risk that would no longer be acceptable.
The security tests each class needs before release: SBOM regeneration and vulnerability check, security regression suite, and when a scoped penetration test is required. Each test has a written pass criterion.
What takes a change outside the PCCP, and which route it then follows: your postmarket cybersecurity plan, a letter to file, or a new submission.
An illustrative entry for one modification class. Real appendices use your own IDs.
| Threat model elements | Device to cloud link (DF-4), mobile app to device link (DF-2); entry points EP-2 and EP-4 |
|---|---|
| Threat Table rows | T-07 spoofed cloud endpoint, T-11 session hijack, T-12 downgrade to weak cipher |
| Risk impact | Exploitability may drop (fixes) or rise (new defaults). Harms H-03 and H-05 unchanged. Residual risk must stay at or below current rating. |
| Reassessment trigger | New cipher suite, certificate handling change, or any change to authentication flow |
| Verification | SBOM diff and vulnerability check; TLS configuration scan; regression tests for T-07, T-11, T-12; no pen test unless a trigger fires |
| Pass criteria | No new high or critical vulnerability; TLS 1.2 or later only; all three regression tests pass |
| Outside the PCCP if | A major version change or any trigger above fires |
The appendix uses the IDs from your threat model: data flow elements, entry points, and Threat Table rows. When a change ships, the matching rows are updated and the test-case IDs in the Threat Table point to the regression tests that ran. If a change would add an entry point or trust boundary, it leaves the PCCP route and goes back to a full threat model update.
Each affected Threat Table row carries its exploitability rating and the harm it traces to in your ISO 14971 file. The appendix states how a change could move exploitability and confirms residual risk stays inside the acceptance criteria you set before scoring. If it would not, the change is outside the PCCP. For how the two risk files fit together, read ISO 14971 and AAMI SW96.
If any of these are missing, we start with a threat model and hazard analysis gap assessment. To draft the plan itself, try the free PCCP Builder or read the FDA PCCP guide.
Tell us about your device and the changes you plan to make. We'll set up a short scoping call and quote a fixed fee.
