The QMS process approach means running your quality management system as a set of interacting processes, not as a binder of procedures. EN ISO 13485:2016+A11:2021 clause 4.1.1 requires the manufacturer to document the QMS and to implement, maintain, and continually improve its effectiveness in accordance with the standard and applicable regulatory requirements. Clause 4.1.2 requires the manufacturer to determine the processes needed for the QMS, their application throughout the organisation, the sequence and interaction of those processes, and the criteria and methods needed to ensure their operation and control are effective. For a startup, the process approach means: list the real processes you actually run, draw how they feed each other, document the flow in plain language, measure whether they work, and refuse to invent aspirational processes that exist only on paper. This is the legal basis of a QMS that matches MDR Article 10(9).

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • The process approach is the organising principle of EN ISO 13485:2016+A11:2021. Clause 4.1.1 and clause 4.1.2 require a QMS built from identified, interacting, measured processes — not a stack of standalone procedures.
  • MDR Article 10(9) requires the QMS to ensure compliance in the most effective manner, proportionate to the risk class and type of device. The process approach is how "effective" becomes concrete.
  • A startup's real processes usually look nothing like the table of contents in a generic QMS template. The process approach starts from what the team actually does.
  • Process interactions matter as much as the processes themselves. An auditor checking handoffs finds more gaps than an auditor reading procedures one at a time.
  • Measurement is part of the requirement. If a process is not measured, the standard does not consider it under control.
  • The trap to avoid is the aspirational process map: a diagram that describes processes nobody runs. It fails audit on first contact.

Two companies, two process maps

The QA manager in Vienna we have mentioned in earlier QMS posts did something specific on her second day at the startup. Before she wrote a single procedure, she drew a map on the whiteboard. On one side: every activity that happened in the company each week. Design reviews. Pull request merges. Customer calls. Supplier emails. Release approvals. Bug triage. Board updates. On the other side: every clause of EN ISO 13485:2016+A11:2021 that would apply to a device of this class. Then she drew lines between them. Some activities mapped cleanly to one clause. Some mapped to several. Some clauses had no activity on the other side yet and needed one. Some activities had no clause and were just real work that did not need to become a QMS process.

That whiteboard drawing, refined and redrawn over the following weeks, became the foundation of the QMS. Not the procedures. Not the forms. The map of processes and their interactions. Everything else followed from it.

The Berlin company that bought the template QMS had a process map too. It was printed on page three of the quality manual they received from the vendor. It showed beautiful arrows between management responsibility, resource management, product realisation, and measurement and analysis. It was copied from the ISO 13485 figure. It described a company that did not exist anywhere in Berlin. Nobody on the team could have walked an auditor through it without lying.

The process approach is the difference between these two maps. One describes reality. The other describes a textbook.

What the standard actually says — clause 4.1.1 and clause 4.1.2

EN ISO 13485:2016+A11:2021 clause 4.1.1 requires the organisation to document a quality management system and maintain its effectiveness in accordance with the requirements of the standard and applicable regulatory requirements. The organisation must establish, implement, and maintain any requirement, procedure, activity, or arrangement required by the standard or by applicable regulatory requirements.

Clause 4.1.2 is where the process approach becomes concrete. The organisation is required to apply a risk-based approach to the control of the appropriate processes needed for the QMS, and must:

  • determine the processes needed for the QMS and the application of these processes throughout the organisation, taking into account the roles undertaken by the organisation;
  • apply a risk-based approach to the control of the appropriate processes needed for the quality management system;
  • determine the sequence and interaction of these processes.

Read that carefully. The standard does not say "write procedures." It says determine the processes, determine how they apply across the organisation, determine their sequence and interaction, and apply risk-based control. Procedures and records come later. The process architecture comes first.

This is the legal anchor inside the harmonised standard. MDR Article 10(9) of Regulation (EU) 2017/745 requires the manufacturer to establish a QMS that ensures compliance in the most effective manner, proportionate to the risk class and type of device. Following EN ISO 13485:2016+A11:2021 gives presumption of conformity with that obligation. Clause 4.1.2 is where the standard operationalises "effective": a QMS whose processes are identified, sequenced, and controlled.

A QMS that jumps straight into procedures without doing the clause 4.1.2 work is building walls without a foundation. It may look standing for a while. It will not survive a serious audit.

What the process approach means in practice

The practical meaning of the process approach for a startup comes down to four moves.

First, you identify processes, not procedures. A process is a thing the company does repeatedly that takes inputs and produces outputs. "We handle customer complaints" is a process. "Complaint handling procedure document version 1.2" is an artefact that describes the process. The process exists whether or not the document does. The document should describe the process, not replace it.

Second, you identify interactions, not silos. The output of the complaint process feeds the CAPA process and the PMS process. The output of the design change process feeds the risk management process and the technical documentation process. The output of the supplier evaluation process feeds the purchasing process. When you draw the QMS, every arrow between boxes is a real handoff that has to happen in real work.

Third, you define criteria and methods for each process. What counts as a successful run of this process? How do we know it worked? What data shows it is under control? This is clause 4.1.2 again, read to its end. Control is not the same as documentation.

Fourth, you size everything to the risk class. A Class I software startup will have fewer processes, shorter interaction chains, and lighter measurement than a Class IIb implantable manufacturer. Both can be compliant. Both follow the process approach. The depth differs because MDR Article 10(9) requires proportionality.

Identifying your real processes

The starting move in any honest process approach exercise is a list of the processes your company actually runs. Not a list of the processes a template company runs. Yours.

Sit with the founders and the first hires for an afternoon. Go week by week through a typical month. For every recurring activity, write one sentence: what the activity is, who does it, what comes in, what goes out. Do not filter against the standard yet. Capture everything that recurs.

You will end up with a list somewhere between fifteen and forty items. Some of them are obviously QMS processes: design review, change control, complaint handling, supplier qualification. Some are clearly not: fundraising updates, board meeting scheduling, hiring interviews. Some are ambiguous: release planning, sprint retros, customer onboarding. The ambiguous ones are where the judgement lives, and where a generic template will fail you because it does not know what your team does.

Now filter against the clauses of EN ISO 13485:2016+A11:2021. For each clause that applies to your device, find the activity on your list that corresponds to it. If you find one, name it as your QMS process for that clause. If you do not, you have a gap — either the clause does not apply and you will document non-applicability, or the clause applies and you have to start running a real process. The list of real processes and the list of applicable clauses must reconcile. Reconciliation is the work.

The output of this step is a named set of processes — typically eight to fifteen for a small startup — where each process has a one-sentence description, an owner, inputs, outputs, and a connection to one or more clauses of the standard. Not procedures yet. Just the map.

For the operational playbook of how this connects to the full QMS build, see how to build a lean QMS for your MedTech startup.

Interactions between processes

A process in isolation is not enough. The standard requires the sequence and interaction of processes to be determined. Interactions are where most audit findings appear.

Draw the handoffs explicitly. The complaint handling process produces outputs that enter the CAPA process. The CAPA process produces outputs that can feed back into design changes, risk management updates, and PMS reports. The design change process triggers re-evaluation of risk management outputs and technical documentation updates. The supplier evaluation process feeds purchasing. Internal audit feeds management review. Management review feeds resource planning.

For a startup, the common failure mode is that the processes exist in isolation but the arrows between them do not. Complaints pile up and never trigger a CAPA. CAPAs close without feeding back into design. Risk management lives in one file while the design history file lives in another and they never meet. Each process looks fine on its own. The system does not work because nothing flows.

A useful exercise: pick one process and walk its output. Where does it go? Who receives it? Do they know they received it? What do they do with it? Trace three hops. If you lose the trail before three hops, that chain of interactions is broken and the auditor will find it.

The process interaction map does not need to be a pretty diagram. A whiteboard photo with boxes and arrows is enough as long as the arrows reflect real handoffs. Pretty diagrams are where aspirational process maps hide.

Documenting the flow

Once processes and interactions are clear, documentation becomes straightforward. The documentation exists to describe what happens, so that a new hire or an auditor can follow it. If the process is clear, the document is short. If the document is long, usually the process is unclear.

For each process, write a short procedure that answers: who, when, what inputs, what outputs, against what criteria, recorded where, linked to which other processes. A page is often enough. Two pages is fine if the process genuinely needs it. Ten pages is a warning sign.

Avoid the bureaucratic voice. Write in the voice of the people who run the process. If the release process is really "the engineering lead runs the release checklist, two reviewers approve, the release is tagged in the repository, the release record is updated," write exactly that. Do not translate it into passive constructions that make the procedure unreadable.

The document should reference the clauses of EN ISO 13485:2016+A11:2021 it addresses and the MDR Article 10(9) aspects it supports. This traceability is not decoration. It is how the auditor confirms that every standard and regulatory requirement is covered by at least one real process, and it is how you catch gaps when the Regulation or the standard is revised.

For the companion discipline on document control itself — how versions, approvals, and archives are handled once the procedures exist — see document control for startup QMS.

Measurement of effectiveness

Clause 4.1.2 requires criteria and methods to ensure processes are controlled and effective. Effectiveness is not a feeling. It is a measured property.

For each process, define at least one measurable indicator. The indicator does not need to be sophisticated. It needs to be real, it needs to be captured as part of running the process, and it needs to produce data that a human actually looks at.

Examples from lean startup QMSs we have seen work. Complaint handling: number of complaints open past the target resolution time, reviewed monthly. CAPA: number of CAPAs open past their planned closure date, reviewed monthly. Internal audit: number of findings from the last cycle closed versus open, reviewed before management review. Supplier evaluation: number of suppliers overdue for re-evaluation. Design review: number of design changes closed without a documented review. Release: number of releases shipped without the release checklist completed.

None of these indicators require sophisticated dashboards. A shared spreadsheet or a simple project tracker is enough. The requirement is that the data exists, that someone reviews it on a defined cadence, and that the review produces decisions when the numbers go wrong. That is the "control" the standard asks for. Linking these indicators into management review closes the loop that clause 4.1.2 and the management review clauses together demand. For the internal audit side of this loop, see internal audits for small MedTech teams.

The trap of aspirational process maps

The failure mode that kills QMS projects faster than any other is the aspirational process map. A diagram that describes processes the company would run if it were twice as big, with roles that do not exist, handoffs that nobody performs, and records that are never produced.

Aspirational maps come from three sources. Templates — because the template was drawn for a larger company. Consultants who have never worked inside a three-person team — because they are pattern-matching from their last Class III client. And founders who confuse the picture of quality with the practice of quality — because a beautiful diagram feels like progress when the actual work is harder.

The test for aspirational content is always the same. For every process on the map, ask: who runs this next week, on what day, producing what record? If the answer is specific and names a real person, the process is real. If the answer is "we will figure it out" or "once we hire the QA lead," the process is aspirational and will fail audit.

The cure is subtraction. Cut the aspirational process. Either replace it with a real process you can start running immediately, or justify its absence with reference to the standard and the device. Do not leave aspirational content in the map hoping nobody will notice. Auditors notice on the first walkthrough.

The Subtract to Ship angle

The process approach is one of the cleanest places in the QMS where Subtract to Ship discipline produces a visibly better outcome. The default failure mode is addition — more processes, more arrows, more procedures, more dashboards. The Subtract to Ship move is to cut every process that does not trace back to an applicable clause of EN ISO 13485:2016+A11:2021 or a specific requirement of MDR Article 10(9), and to cut every arrow on the interaction map that does not correspond to a real handoff.

Two practical moves. First: before drawing the process map, walk the actual work for a week and note every handoff that already happens. Then draw the map from the notes. Second: when the map is drawn, delete every box that does not have a named owner and every arrow whose two endpoints are not both on the whiteboard. What remains is the QMS you can actually run. Everything else is theatre.

This connects directly into the minimum viable QMS for early-stage teams and into the broader how to build a lean QMS playbook.

Reality Check — Where do you stand?

  1. Can you list the processes of your QMS in under a minute, by memory, and name the owner of each one?
  2. Can you draw the interactions between your processes on a whiteboard without referring to a template?
  3. For each process, is there a measurable indicator that someone actually reviews on a defined cadence?
  4. When was the last time an interaction between two of your processes produced a real handoff — a complaint that triggered a CAPA, a CAPA that triggered a design review, a design review that updated the risk file?
  5. Does every process on your map trace to a clause of EN ISO 13485:2016+A11:2021 that applies to your device?
  6. Are there any processes on your map that nobody has actually run yet?
  7. If an auditor walked in next week and asked you to walk them from any clause to a real record through the process map, could you do it?

Frequently Asked Questions

What is the process approach in ISO 13485? The process approach is the organising principle of EN ISO 13485:2016+A11:2021. Clause 4.1.2 requires the manufacturer to determine the processes needed for the QMS, the application of those processes across the organisation, the sequence and interaction between them, and the criteria and methods needed to control them. It treats the QMS as a system of interacting processes rather than a collection of standalone procedures.

How many processes does a startup QMS need? There is no fixed number. A small startup building a Class I software device typically identifies eight to fifteen QMS processes. A Class IIb device manufacturer will have more. The number is driven by the clauses of EN ISO 13485:2016+A11:2021 that apply to the device and by MDR Article 10(9)'s proportionality principle. The test is coverage, not count.

Is a process map required by EN ISO 13485:2016+A11:2021? The standard requires the sequence and interaction of processes to be determined. It does not prescribe a specific format. A process map — whether a diagram, a table, or a narrative description — is the usual way to demonstrate compliance with this requirement. Notified Body auditors expect to see one and will ask to be walked through it.

What happens if my processes are not measured? If a process is not measured, the standard does not consider it under control, and clause 4.1.2 is not satisfied. This will surface as an audit finding. The measurement does not have to be elaborate — a single indicator captured and reviewed on a defined cadence is enough for most processes in a small startup QMS.

Can I copy a process map from a template? You can use a template as a reference, but you cannot submit a copied process map as your own. The map must reflect the processes your company actually runs, with the interactions that actually happen, owned by the people who actually run them. A copied map describes a company that does not exist and will fail the first walkthrough audit.

Where does the process approach connect to MDR Article 10(9)? MDR Article 10(9) requires the QMS to ensure compliance in the most effective manner, proportionate to the risk class and type of device. The process approach in clause 4.1.2 of EN ISO 13485:2016+A11:2021 is how "effective" becomes concrete: identified processes, determined interactions, criteria for control. Following the clause correctly supports presumption of conformity with the Article 10(9) obligation.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10 (general obligations of manufacturers, including paragraph 9 on the quality management system). Official Journal L 117, 5.5.2017.
  2. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes, clause 4.1.1 (general QMS requirement) and clause 4.1.2 (determination of processes, their application, sequence, interaction, and control).

This post is part of the Quality Management Under MDR series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. The process approach is where the QMS stops being a binder and starts being the way the company actually runs. Get the processes right, and the procedures, records, and audit outcomes follow. Get them wrong, and no amount of documentation will save the system.