22 of 22 topic areas shown. Everything runs in your browser; nothing is sent anywhere.

1. Which areas do you want to see?

Leave everything unselected to see the full crosswalk.

2. Which columns matter to you?

CR515 topic	GMLP	PCCP	AIBOM	Section 524B	Evidence
Program governanceNamed ownership for ML security riskML risk usually splits between a data science team outside the QMS and a security team with no model access, so nothing is owned end to end.	Multi-disciplinary expertise applied across the product lifecycle.	Name the role that approves each permitted modification before it ships.	An owner recorded against each model artifact and dataset entry.	Cybersecurity plan: the process description reviewers read first.	Cybersecurity management plan section covering ML roles and approvals.
Program governanceTraining pipeline inside the quality systemTraining infrastructure is frequently treated as research tooling and therefore sits outside design controls entirely.	Good software engineering and data quality practices applied to the pipeline.	The pipeline that executes permitted retraining has to be a controlled environment.	Pipeline components and their versions listed alongside runtime dependencies.	Cybersecurity plan and the reasonable-assurance argument.	Procedure covering the ML pipeline, plus tool validation records.
ML asset identificationModel, weights, and checkpoints as named assetsA threat model cannot assess an asset that was never enumerated, and standard SBOM tooling does not emit model artifacts.	Clinically relevant model documented and version controlled.	The cleared baseline model version the plan measures changes against.	Core AIBOM entries: artifact, version, hash, serialization format.	SBOM: the model is a software component of the device.	AIBOM in CycloneDX ML-BOM or SPDX 3.0 AI profile.
ML asset identificationTraining, validation, and test datasets as assetsDatasets determine clinical behavior, carry patient data, and are the entry point for poisoning, yet rarely appear in any inventory.	Training data representative of the intended population and independent of test data.	Data sources permitted for retraining, and what makes a new source acceptable.	Dataset entries with source, size, de-identification, and licensing.	SBOM and the reasonable-assurance argument.	Dataset provenance table and de-identification records.
ML asset identificationInference runtime and preprocessing codePreprocessing is as safety-relevant as the model; a change in normalization changes outputs without touching a weight.	Model development and deployment environment documented.	Runtime or preprocessing changes are usually outside a model-focused PCCP scope.	Runtime and framework versions actually deployed, not the ones in requirements.txt.	SBOM component completeness.	Deployed-runtime inventory reconciled against the build.
ML threat modelingTraining data poisoningPoisoned behavior survives functional testing because the device performs exactly as trained.	Data collection protocols and dataset independence.	Any permitted retraining reopens the poisoning path and needs stated controls.	Dataset hashes and provenance make an unexpected change detectable.	Reasonable assurance of cybersecurity: the harm argument.	Threat model rows scored through the SW96 patient-harm columns.
ML threat modelingAdversarial evasion of the inference pathPerturbed inputs flip the output while the clinician sees nothing unusual, producing a confident wrong answer.	Performance evaluated under clinically relevant conditions.	Performance thresholds in the plan should include robustness, not accuracy alone.	Identifies the model version any robustness result applies to.	Security testing evidence supporting reasonable assurance.	Adversarial input test report against the deployed inference path.
ML threat modelingModel inversion and membership inferenceQuery access can leak training-data characteristics, which is a patient confidentiality failure with consequences beyond the device file.	Training data managed with appropriate privacy safeguards.	Changes that widen query access change this exposure.	Records whether training data contained PHI and what de-identification applied.	Reasonable assurance, and confidentiality within the security objectives.	Threat model rows plus query rate limiting and output granularity controls.
ML threat modelingModel extraction and weight theftWeights are often the most valuable company asset and are shipped to the edge with less protection than the firmware around them.	Not directly addressed; GMLP is quality-focused, not confidentiality-focused.	Distribution changes for updated weights are in scope.	Weight files identified with hashes so integrity can be verified at load.	Reasonable assurance and the security architecture views.	Encryption at rest, signed weight files, integrity verification at load.
Data integrity and provenanceData lineage as a controlled artifactWithout lineage you cannot answer which data produced the cleared model, which makes every later question unanswerable.	Data sources traceable and representative.	The plan has to state the data lineage requirement for retraining.	Dataset entries carry source, collection window, and version.	Reasonable assurance argument.	Versioned data lineage record referenced from the DHF.
Data integrity and provenanceLabel integrity and annotation processMislabeled data is functionally equivalent to a poisoning attack and is far more common.	Reference standard and annotation quality controls.	Annotation process changes are a modification even when the architecture does not change.	Annotation tooling and version recorded with the dataset.	Reasonable assurance argument.	Annotation SOP, inter-rater records, and tool validation.
Model supply chainPretrained and foundation modelsA base model pulled from a public hub carries an unknown training history and an unverifiable provenance chain.	Model provenance documented.	Vendor-side model changes behind an API are changes you did not make and may not control.	Vendor, model identifier, version pinning strategy, and endpoint recorded.	SBOM: third-party components must be enumerated.	AIBOM third-party entries plus a supplier assessment.
Model supply chainFrameworks, serialization, and CVE exposureML frameworks and serialization formats have a real vulnerability history, and deserialization of untrusted model files is code execution.	Good software engineering practices.	Framework upgrades are typically outside PCCP scope and follow normal change control.	Framework and runtime versions with purl identifiers.	SBOM plus postmarket vulnerability monitoring.	SBOM with VEX statements for the ML dependency tree.
Model supply chainSigning and integrity of model artifactsDevices routinely verify firmware signatures and then load an unsigned weight file from disk.	Deployment environment controls.	Every permitted model update travels the signing path; the plan should say so.	Hashes recorded per artifact so the shipped model is verifiable.	Reasonable assurance, integrity controls, and secure update capability.	Signing procedure and a negative test showing a tampered model is rejected.
Security controlsProtection of model artifacts at rest and in transitThe model is both a confidentiality asset and an integrity-critical input to clinical output.	Deployment controls.	Applies to every updated artifact the plan permits.	Identifies each artifact needing protection.	Reasonable assurance and the security architecture views.	Architecture view showing artifact storage, keys, and verification points.
Security controlsInput validation and inference-path hardeningOut-of-distribution detection and input sanity checks are the practical mitigation for both evasion and garbage-in failures.	Performance monitored under real-world conditions.	Threshold changes to these checks are modifications.	Preprocessing code identified as a component.	Reasonable assurance and security testing.	Control described in the threat model with test results.
Security controlsLogging that distinguishes drift from attackDegrading performance looks identical from the outside whether the cause is population shift or adversarial input.	Real-world performance monitoring.	The monitoring the plan relies on has to be able to make this distinction.	Model version stamped into logs so events attach to an artifact.	Postmarket monitoring obligation.	Monitoring plan with the signals and thresholds used.
Verification and testingAdversarial and robustness testingStandard penetration testing exercises the network surface around the model and never the model itself.	Performance testing independent of training data.	Re-run scope after each permitted modification should be stated.	Ties each result to the model version tested.	Security testing evidence in the premarket submission.	Penetration test report including adversarial input testing.
Verification and testingArtifact integrity and negative testingA signing control with no negative test is an assertion, not evidence.	Verification activities documented.	Part of the verification bundle for each permitted change.	Provides the hashes the test verifies against.	Security testing evidence.	Test case showing a modified or unsigned model fails to load.
Postmarket and changeRetraining as a security eventRetraining changes the attack surface, not just the performance numbers, so a performance-only gate misses the security question.	Retraining governed and monitored.	Core PCCP content: which retraining is permitted and under what conditions.	New model and dataset versions appended, prior versions retained.	Postmarket obligations and update capability.	PCCP with a threat model review trigger written into the change protocol.
Postmarket and changeVulnerability handling for ML componentsFramework CVEs land in the ML dependency tree, and reachability from the inference path is what determines whether they matter.	Not addressed; this is a security lifecycle obligation.	Patch paths for ML dependencies are usually outside PCCP scope.	The component list vulnerability feeds are matched against.	Postmarket monitoring, disclosure, and patching.	CVD process plus VEX statements for the ML dependency tree.
Postmarket and changeIncident response for model-level eventsAn adversarial or poisoning event does not look like a conventional intrusion and needs a defined path, including rollback to a known-good model.	Real-world performance monitoring and response.	Rollback to the cleared baseline is the safety net the plan depends on.	Identifies the known-good version to roll back to.	Postmarket plan and coordinated vulnerability disclosure.	Incident response procedure with a model rollback path.

Planning aid, not regulatory advice, and not a substitute for the AAMI document. AAMI CR515:2025 is a consensus report: there is no conformity assessment and no certification. Applicability and evidence sufficiency are determinations you own and document in your quality system.

Related guides and tools

• AAMI CR515:2025 and ML device cybersecurity for the narrative behind this table.
• GMLP controls crosswalk for the lifecycle control evidence.
• FDA PCCP and change control plans for scoping permitted modifications.
• AIBOM for medical devices for the inventory the threat model attaches to.
• PCCP Builder to draft the change control plan itself.
• Standards Mapper for the wider standards chain that applies to your device.