Designing lean QMS system: Pragmatic approach for teams without dedicated compliance expert

A functioning QMS covers several connected areas.

• Quality policy and objectives.
  A statement from leadership about what quality means for the organization, backed by measurable goals. This sets the direction for everything else in the system.
• Document control.
  How documents are created, reviewed, approved, versioned, and retired. For software teams, this often maps to how you already manage specifications, SOPs, and process documentation. The QMS layer adds formal approval workflows and access controls.
• Risk management.
  A structured process for identifying, evaluating, and controlling risks across the product lifecycle. The specifics vary by industry and standard: ISO 14971 for medical devices, ISO 23894 for AI systems, and security risk assessments under ISO 27001. The underlying discipline is the same.
• Corrective and preventive actions (CAPA).
  The formal method for investigating what went wrong, identifying root causes, fixing the immediate issue, and changing processes to prevent recurrence. If your team runs post-mortems or retrospectives, CAPA is the compliance-grade version of that practice.
• Internal audits.
  Regular self-assessments to verify that processes are being followed, records are complete, and the system reflects how the team actually works. Internal audits catch drift before an external auditor does.
• Management review.
  Periodic reviews where leadership examines quality data, audit results, customer feedback, and system performance to make informed decisions about where the organization needs to improve.

These elements work together. Risk management feeds into design decisions. CAPA feeds into process improvements. Internal audits verify the whole system is functioning. Management review ensures the data reaches the people making strategic decisions.

Most compliance content frames QMS system implementation as a project with defined phases: gap assessment, documentation, training, internal audit, and certification. That sequence is accurate, but it misses what product teams actually need to get right.

Build it like you’d build software

The principles of good QMS design overlap heavily with good engineering practice:

• Use the language and concepts of your domain so the system feels natural to your team.
• Prioritize readability and maintainability. A QMS gets read far more often than it gets written, the same way a codebase does.
• Start with the core processes and the simplest version that works. Get the team using it. Once the basics feel natural, add complexity where the product or regulatory scope demands it. Trying to build the complete system before anyone has used any of it produces documentation that looks thorough on paper but doesn’t reflect operational reality.
• Keep things modular. Document control, change management, risk management, and CAPA should have clear boundaries and defined ownership. When something goes wrong, you need to trace the issue back through the system without ambiguity about which process applies and who is responsible.

Think in domains, not in individual standards

The biggest structural decision product teams face is:

Should they build their QMS around a single standard or around the product itself?

Building around a single standard works at first. A medical device startup structures everything around ISO 13485. An AI company organizes their system around ISO 42001. The problems emerge when the product’s regulatory scope expands.

That medical device startup decides to enter the US market and needs to address FDA requirements alongside MDR. Or they add a cloud-connected component and need ISO 27001 for information security. Or they integrate an AI module and need to demonstrate AI governance under ISO 42001. Each new requirement asks for processes, controls, and evidence that the existing QMS was designed around a single standard and cannot easily accommodate.

The alternative is to structure the QMS around how the team builds and ships: roles, products, and processes at the center, with standards and markets connecting to them. Risk management, document control, internal audits, management review, CAPA, competence, and training all appear across ISO 13485, ISO 27001, ISO 42001, and GDPR in structurally similar forms. A QMS built around the product development lifecycle can serve as the foundation for quality, security, AI governance, and privacy management without requiring parallel systems for each domain.

This is the difference between extending your compliance system when requirements grow and rebuilding it.

Use pre-built foundations

The default approach to QMS implementation is to start from a blank page, or from a set of consultant templates, and build the system from scratch. This works, but it takes months and requires regulatory interpretation expertise that most early-stage teams don’t have.

The alternative is to start from a structured foundation that’s already mapped to the standards your product needs. Know-how sets within ins2outs provide this: pre-built policies, processes, procedures, and templates for standards like ISO 13485, ISO 27001, ISO 42001, and GDPR. The team customizes the foundation to their organization, adjusting roles, scoping processes to their products and markets, and adding depth where their specific risk profile requires it.

Starting from a working baseline means the team can focus on making the system reflect their reality, instead of spending months interpreting standards and drafting documentation from scratch.

Plan for security, privacy, and AI governance from the start

Product teams building software and connected hardware will almost certainly face requirements beyond quality management alone.

The EU’s Cyber Resilience Act introduces mandatory cybersecurity requirements for products with digital elements. If your product includes software or connects to a network, security documentation and vulnerability handling need to be part of your product lifecycle from the design phase forward.

If your product processes personal data in the EU, GDPR applies, and privacy management needs to be part of how the product is built, tested, and maintained.

If your product includes AI or machine learning components, the EU AI Act’s requirements for high-risk systems create obligations around risk assessment, data governance, model documentation, human oversight, and post-market monitoring. Standards like ISO 42001 and the emerging prEN 18286 provide structured approaches to meeting these obligations. For a closer look at prEN 18286 and how it relates to the EU AI Act, see prEN 18286: A QMS for EU AI Act compliance.

Each of these domains (security, privacy, AI governance) shares operational processes with your quality management system. Building them as separate projects creates duplicated controls, conflicting role definitions, and coordination overhead that grows with each standard you add. Building them within an integrated system means shared processes are defined once and extended when new requirements arise.

• If your team is early-stage and hasn’t built a QMS yet, start by identifying what you’re building, which markets you’re targeting, and which standards apply. That scoping exercise determines the shape of everything that follows.
• If you already have a QMS and it’s struggling with adoption, the issue is usually structural: the system was designed around a standard’s clause structure and doesn’t reflect how the team actually works. Restructuring around your products, roles, and processes can fix the adoption problem without starting over.
• If you’re scaling and facing overlapping compliance domains, evaluate whether your current system can accommodate additional standards incrementally or whether it needs architectural changes to support reuse across domains.

In all three cases, the goal is the same: a compliance system that captures the decisions and evidence your team is already producing, structured so it can grow with the product.