Electronic CAPA workflow for medical device manufacturers: ISO 13485, FDA and Power Platform

CAPA stands for Corrective and Preventive Action. Through it, a company establishes the cause of a problem, removes it and checks that the problem does not come back. In ISO 13485 it is covered by clauses 8.5.2 and 8.5.3.

Take a hypothetical medical device manufacturer with 150 employees. It keeps its CAPA register in Excel and its root cause analyses in Word, and decisions are made by email. Before an audit, the quality manager spends several days gathering evidence from three places and checking which version of a form is final.

This set-up has three weak points. You cannot see who changed a record and when. Deadlines are tracked by one person, so an effectiveness check due several months later is easily missed. And the evidence that actions were carried out sits in individual employees’ mailboxes.

The requirements come from several sources that are often confused. In the table below we have summarised what each of them means for the IT system, not for the quality management system as a whole.

Two things have changed recently or are often described incorrectly. Since 2 February 2026, the FDA has applied the QMSR, which replaced the old text of 21 CFR 820 and refers to ISO 13485:2016. Companies selling in the US and the EU therefore have a common reference point for CAPA – ISO 13485 – although the QMSR adds a few requirements of its own.

The second issue is the record retention period. ISO 13485 does not set a fixed “5 years”: records must be kept for the lifetime of the device, and for no less than 2 years from its release by the manufacturer. In the EU, the MDR’s 10 or 15 years apply on top of this, so the system must keep data for longer than a typical company archive.

Whatever the tool, a CAPA case goes through the same stages. For each one it is worth deciding in advance who is responsible, how much time they have and what evidence they leave in the system:

In a company that already has Microsoft 365, a CAPA workflow usually consists of four elements. SharePoint stores the documents: analysis reports, plans and evidence of completion. Dataverse, the Power Platform database, holds the CAPA cases themselves, with fields such as status, deadline, device and cause.

Power Automate sends tasks and reminders and escalates cases when deadlines pass. Power Apps provides forms for the quality department, and Teams provides notifications and simple approvals. Power BI shows the management board how many cases are open, how long they take and where they come from.

Three settings decide whether the whole thing will pass an audit. First, auditing in Dataverse has to be switched on for the environment, the table and the columns – it does not switch itself on. It records who changed a field, when, and what the previous value was.

Second, the permission to delete the change history must be limited to a very small group of people – ideally no one from the quality department. Third, a single Power Automate flow run lasts at most 30 days. So plan an effectiveness check due several months later as a daily check of deadlines, not as a flow that waits.

Many myths have grown up around electronic signatures. 21 CFR 11.200 requires two distinct identification components, such as an ID and a password. Multi-factor authentication, i.e. an extra code from a phone, is good practice, but the regulation does not require it.

The signature must show the signer’s full name, the date and time, and the meaning of the signature, such as “I approve the action plan” (11.50). It must be permanently linked to the record, so that it cannot be copied to another document (11.70).

There is also an obligation that companies are often unaware of. Before using electronic signatures, you must certify to the FDA in writing that they are the legally binding equivalent of handwritten signatures (11.100). In Microsoft 365, the signature is usually built in Power Apps: the user re-enters their sign-in details through Microsoft Entra ID, enters the meaning, and the record is saved in Dataverse.

Companies that sell only in the EU are not subject to Part 11. The MDR has no equivalent, and the requirements come from ISO 13485: a record must be legible and every change must be identifiable. Many companies design their system to Part 11 anyway, so they do not have to rebuild it when entering the US market.

Validation is documented evidence that a system does what the company requires of it. ISO 13485 requires it before software is first used in the quality management system and after every significant change. An application built by an employee and used for CAPA cases without validation is a common audit nonconformity.

You validate the specific application, not the whole platform. For Microsoft 365 and Power Platform, Microsoft publishes GxP guidelines – a description of good practice for regulated industries such as pharmaceuticals and medical devices. They describe Microsoft’s safeguards and how responsibility is split with the customer. This helps when assessing the supplier, but it does not replace testing your application.

The scope of validation should follow from risk, not from a habit of filling thick binders. ISO 13485 and the FDA’s September 2025 guidance on software assurance put it the same way. Functions that affect decisions about device safety are tested in detail; a report showing the number of open cases is tested more lightly.

In practice you prepare user requirements, a risk assessment of the functions, test scripts and a report with the results. Every later change to the application goes through change control and an assessment of whether it needs retesting. That is why validation is planned from the start of the project, together with the quality department.

Not every company should build its own CAPA system. Off-the-shelf quality management systems for the medical sector have validated modules and validation documentation packages from the vendor. However, they require separate licences and add yet another place people have to log in to. The comparison in the table below will help you choose a direction.

Most audit problems do not stem from the choice of tool but from skipped steps. These are the most common:

The first step is not choosing a tool but assessing the current process. The following order works in most companies: