MDSAP for Medical Device Compliance

The Medical Device Single Audit Program (MDSAP) lets one audit by one authorized auditing organization satisfy five regulators. That is a real reduction in audit burden, but it is frequently misunderstood in two directions: manufacturers assume it does less than it does for cybersecurity, and then assume it does more than it does for submissions. This post explains the audit model, what each participating regulator adds on top of ISO 13485, exactly where cybersecurity surfaces in an MDSAP audit, and how to prepare for that part.

Why this matters

Two things changed the calculus on MDSAP. First, Health Canada made it mandatory, so any manufacturer planning a Canadian licence has no opt-out. Second, security risk management moved from an informal practice into the quality system: ANSI/AAMI SW96:2023 and IEC 81001-5-1 describe procedures, records, and traceability, and procedures with records are exactly what an MDSAP auditor is trained to sample.

The result is that cybersecurity has quietly become auditable in a way it was not five years ago. A manufacturer can hold a clean FDA clearance and still take a nonconformity because the security risk management procedure exists on paper but produced no records for the last two releases, or because a reported vulnerability never entered the complaint-handling and CAPA process.

What MDSAP Actually Covers

MDSAP audits a manufacturer's quality management system against ISO 13485:2016 plus the country-specific requirements of each participating regulator you elect to include in scope. It is a QMS audit, not a product review and not a technical file review.

The audit is organized around seven processes rather than around ISO clauses:

1. Management (including management review and resourcing)
2. Device marketing authorization and facility registration
3. Measurement, analysis, and improvement (including internal audit, data analysis, and CAPA)
4. Medical device adverse events and advisory notices reporting
5. Design and development
6. Production and service controls
7. Purchasing (including supplier controls)

Design and development, purchasing, and measurement/analysis/improvement are where cybersecurity evidence is most likely to be sampled.

The Five Regulators and What Each Adds

You elect the jurisdictions in scope. Adding a jurisdiction adds its country-specific tasks to the audit, which lengthens the audit but avoids a separate one later.

The Audit Model and Cycle

MDSAP runs on a three-year certification cycle:

Nonconformities are graded on a points-based scheme that escalates with the seriousness of the affected process and with repeat or systemic findings. High-grade findings trigger notification to the participating regulators, which is the mechanism that gives MDSAP its teeth: a serious finding does not stay between you and the auditing organization.

Audits are performed by Auditing Organizations authorized and monitored by the participating regulators, not by the regulators themselves.

Where Cybersecurity Surfaces in an MDSAP Audit

This is the part manufacturers under-prepare. Cybersecurity is not a separate audit process, so it gets sampled inside the processes that already exist.

What MDSAP Does Not Do for Your Submission

See also: Health Canada Cybersecurity Requirements, IMDRF Cybersecurity Guidance Explained, and TGA Medical Device Cybersecurity.

MDSAP certifies that your processes conform. It says nothing about whether a particular device's cybersecurity evidence is sufficient.

• It does not replace premarket cybersecurity content. A Section 524B package, a Health Canada licence application, or a TGA Essential Principles mapping still has to be written per device.
• It does not replace an FDA pre-approval or for-cause inspection. The FDA accepts MDSAP reports in lieu of most routine surveillance inspections only.
• It does not certify your threat model. No auditor evaluates whether your threat model correctly identified the attack surface. They evaluate whether you have a procedure, followed it, and kept records.
• It does not transfer conditions between regulators. Each jurisdiction still applies its own licence, registration, and reporting rules.

The clean mental model: MDSAP is the process argument, the submission is the product argument. You need both, and reviewers in Canada and Australia will notice when a strong process certificate sits behind a thin device file.

Preparing for the Cybersecurity Parts of the Audit

1. Write the security risk management procedure into the QMS, not alongside it. Reference ANSI/AAMI SW96:2023 and connect it explicitly to the ISO 14971 risk management procedure.
2. Add security activities to design control checkpoints so design reviews generate records that mention security by name.
3. Make the SBOM a controlled output with a defined regeneration trigger per release and a named owner.
4. Route vulnerability intake through complaint handling. A reported vulnerability should look, in the record trail, like any other quality signal that gets assessed, risk-rated, and closed.
5. Define reportability criteria for cybersecurity events per jurisdiction, and keep the decision records even when the decision was "not reportable."
6. Put security on the management review agenda with a standing metric, such as open vulnerabilities by severity and age.
7. Run a mock sample. Pick your last release and try to produce the full security record trail in an hour. Whatever you cannot find is what the auditor will ask for.

How Blue Goat Approaches MDSAP Readiness

We work the cybersecurity side of the quality system: writing the security risk management procedure so it integrates with the existing ISO 14971 and IEC 62304 processes, building the record trail an auditor will sample, and producing the device-level artifacts (threat model, SBOM, security risk assessment, penetration test reports) that the procedures are supposed to generate. Our team holds CISSP, OSCP, and prior military red-team credentials, and the work is anchored in IEC 81001-5-1, ANSI/AAMI SW96:2023, ISO 14971, and the FDA February 3, 2026 final premarket guidance. See our medical device cybersecurity services.

If a regulator raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.

FAQ

What is MDSAP?

MDSAP is the Medical Device Single Audit Program. One audit of a manufacturer's quality management system, performed by an authorized Auditing Organization against ISO 13485:2016 plus country-specific requirements, satisfies the QMS requirements of five participating regulators at once.

Which countries participate in MDSAP?

The United States (FDA), Canada (Health Canada), Brazil (ANVISA), Australia (TGA), and Japan (MHLW and PMDA). Other regulators participate as observers or affiliates without accepting audit reports in the same way.

Is MDSAP mandatory?

It is mandatory for a Health Canada Class II, III, or IV medical device licence. It is voluntary for the other participating regulators, though ANVISA registration pathways make it effectively necessary for many manufacturers entering Brazil.

Does MDSAP cover cybersecurity?

Indirectly but meaningfully. There is no cybersecurity audit process, but security risk management, software lifecycle controls, SBOM and supplier controls, vulnerability handling, and reportability decisions are all sampled inside design and development, purchasing, measurement and improvement, and adverse event reporting.

Does an MDSAP certificate satisfy premarket cybersecurity requirements?

No. MDSAP demonstrates process conformity. Device-specific cybersecurity evidence, including the threat model, SBOM, verification results, labeling, and postmarket plan, still has to be produced for each submission in each market.

Does the FDA accept MDSAP audits instead of inspections?

The FDA accepts MDSAP audit reports in lieu of most routine surveillance inspections. Pre-approval inspections, for-cause inspections, and compliance follow-up inspections are not replaced.

How long is an MDSAP certificate valid?

Certification runs on a three-year cycle: an initial certification audit, surveillance audits in years one and two, and a recertification audit in year three. Serious nonconformities can trigger notification to the participating regulators between audits.

Related reading

• IMDRF Cybersecurity Guidance Explained
• Health Canada Medical Device Cybersecurity
• TGA Medical Device Cybersecurity
• Steganography in Medical Devices