Predetermined Change Control Plans (PCCPs) are now the default vehicle for shipping AI/ML model updates post-clearance. The cybersecurity catch: every model update is also a software update, and every software update can shift your SBOM, your threat model, and your attack surface.
Three things to put in your PCCP narrative if your device is a 'cyber device' under §524B:
1. A scoped statement of which cybersecurity controls are inside the PCCP envelope (typically: none - model retraining alone should not change auth, crypto, or transport).
2. A trigger that pulls a change back into a new submission if a retrain requires new data sources, new APIs, or new ML-serving infrastructure.
3. SBOM regeneration as a release gate, so each PCCP-eligible update still produces a fresh SBOM and VEX for ongoing postmarket monitoring.
The pattern reviewers reward: a PCCP that explicitly excludes cyber-relevant components from autonomous change, with a clean handoff back to the 524B process when the line is crossed.
-
MDCG 2019-16 Rev.2 at six months: Notified Body audit patternsSix months in, Notified Body audits under MDCG 2019-16 Rev.2 show three clear failure modes - narrative-only SBOMs, CVD policies without operational evidence, and traceability gaps between security risk controls and design outputs.
-
Three years of Section 524B: the deficiencies that never went awayThree-year retrospective on Section 524B enforcement: SBOM depth, VEX justification, and CVD operational evidence remain the top three categories of cyber deficiencies. Two new patterns emerged in 2026 - AI/ML threat-model gaps and weak end-of-support labeling.
-
IEC 81001-5-1 Amendment 1 reaches FDIS - what MedTech teams should trackAmendment 1 to IEC 81001-5-1 (health software security lifecycle) is in Final Draft International Standard ballot. It sharpens SBOM, CVD, and postmarket vulnerability expectations - and it's the standard EU Notified Bodies are quietly aligning MDCG 2019-16 audits against.