MDSAP Revision 11 is Out. What Now?

MDSAP AU P0002.011, the document defining how an MDSAP audit is conducted, was published on August 3, 2026.

It replaces Revision 010, and this is the model according to which your next audit will be conducted.

MDSAP AU P0002 is neither a standard nor a regulation.

It is the guidance document for the joint audit program, and it dictates how the auditor works.

When it is updated, the audit updates with it.

The auditor will arrive with Revision 011 in hand, and a quality system built against Revision 010 will have gaps against it.

In recent days, I accompanied a client through this transition.

I want to describe the approach we took, because it is suitable for any company participating in the MDSAP program.

Why reading the list of changes is not enough

At the end of the document, on page 163, there is a section called Summary of Changes from Prior Revisions.

It details the changes from 010 to 011 in 17 lines.

Many companies read this list, check it off, and move on.

But the list of changes and the document itself do not always align.

Two examples from the client's work:

The list of changes states that FDA cyber requirements were added to Design and Development Task 7.

In the body of the document, in Task 7, there is no cyber requirement.

The text is found in Task 5.

Conversely, in Task 5, there is a requirement concerning design inputs – that they should include the necessary physical and performance requirements to prevent or reduce known security vulnerabilities, and it does not appear in the list of changes at all.

Anyone working solely from the list will look for a cyber requirement in Task 7 and will not find it, and will miss the requirement that does exist in Task 5.

The gap assessment should be performed against the text of both revisions.

A similar point concerns articles and summaries published after a new revision.

Many of us read them, assume they are accurate, and implement changes based on them.

It is advisable to go back to the source.

An example from this revision is the Predetermined Change Control Plan: in Revision 010, the paragraph referred to AI-based devices, and in Revision 011, this reference was removed, and the paragraph applies to any device covered by a predetermined change plan.

Step One: Gap Assessment

The gap assessment is a comparison between 010 and 011, change by change. For each change, three questions:

  1. What actually changed in the text? Not what is written in the list of changes, but what is written in the Task itself in both revisions.

  2. Does it apply to us? Some changes depend on the device's characteristics or the markets you sell in. A change concerning implanted or life-sustaining devices is not relevant to a company that does not manufacture such devices. A change concerning Australia is not relevant to those not registered there.

  3. What is required of us? This is where most of the work lies. Sometimes the requirement is already implemented and just needs to be documented. Sometimes a new clause is needed in an existing procedure. Sometimes a decision needs to be documented.

The tool for documenting the assessment is a table with three columns: the change in Revision 011, what it means for us, and where it is addressed.

It is advisable to arrange the table according to the order of the changes in the document, so you can follow along.

Step Two: Transition Plan

A quality plan for transition takes the gap assessment and turns it into something that can be implemented and demonstrated during an audit.

What was included in the plan we wrote:

  1. Objective and Scope. What will be examined, against what, and what is out of scope.

  2. Assumptions. Things you have determined and want to be documented. For example, that we will not create a new procedure but rather the requirement will be incorporated into an existing procedure that already covers the process. Or that a requirement the document limits to devices approved after a certain date will only apply to them.

  3. Changes Appendix. The table from the first step, including lines deemed irrelevant and lines that do not require document changes.

  4. Documents Appendix. A list of examined documents, current revision, whether a change is required, and status. For the client, 22 documents were examined. 17 were revised. 5 were reviewed and it was decided that no changes were needed.

  5. Records and Forms Appendix. This part is easily forgotten. A change in a procedure usually entails a change in a form or record derived from it. If you added a requirement to a procedure that an investigation of non-conformity should assess whether insufficient competence contributed to it, the investigation form should allow this to be recorded. If a new requirement concerns complaints about information security, the classification of complaints should include this category.

  6. Activities and Dates. Who does what and by when.

Step Three: Implementation

The plan defines three actions that recur in almost every case.

Updating documents according to the appendix.

Releasing revisions and training employees according to the competence and training procedure. The auditor will ask how employees know the procedure has changed, and training is the answer.

And recording decisions that the revision expects to be recorded, even when the conclusion is that nothing needs to be changed.

What was decided not to change

In the client's work, two changes from the list of changes were classified as irrelevant, and five documents were reviewed and not revised.

The auditor arrives with the list of changes, points to a line, and asks what you did with it.

"We checked and decided it doesn't apply to us" is a good answer when it is recorded, with its justification, in real-time.

When it is only stated orally during the audit, the auditor will ask to see the record.

A decision of non-applicability is an output of the process, as is the decision not to change a document. Both should be in the plan, with their justification.

The revision itself implements this principle in several places and requires that the determination be recorded, including when the conclusion is that no action is required. For example, in change control, the determination of whether a change requires a new UDI is a documented output of the control, even when the answer is negative.

Where most of the work lies

Without going into every change, three clusters generate most of the work.

  • Cybersecurity. The revision introduced security requirements in several places simultaneously: for design inputs, software design, and post-market information. Some requirements depend on the device's approval date, and some apply regardless of the date. This distinction is important, as it determines what applies to you now.

  • UDI. UDI requirements were added in Australia. Implementation at the device level is derived from the TGA's timeline according to device classification, but the determination of when it applies to you should be recorded now, even if the date is far off.

  • Competence. The Task that dealt with training now focuses on competence. In practice, the effectiveness assessment should demonstrate that competence has been achieved. Attendance at training is not enough. The action chosen to close a competence gap should also be recorded.

What to do this week

Download Revision 011 — it is available on the MDSAP Audit Procedures and Forms page on the mdsap.global website.

Open it alongside 010, and allocate time for a comparative reading.

After that, you will have an idea of how much work there is.