When organisations evaluate an electronic Quality Management System, the conversation tends to follow a familiar path.
Does it support CAPA? Change control? Training records? Document control?
Most modern platforms tick those boxes. The feature lists are long, the demos are polished, and the differences between vendors can feel marginal. Yet many eQMS implementations still fail to deliver value, frustrating users, creating compliance gaps, and generating audit findings rather than preventing them.
The problem is rarely missing functionality.
Configurability in eQMS is often the more important question.
Configurability in eQMS matters because regulated teams don’t just need a system with the right modules; they need one that can reflect their actual procedures, roles, risk levels, and approval logic without forcing risky custom code.
In practice, that means choosing an eQMS that is flexible enough to evolve with your business while still supporting control, traceability, and proportionate validation under ISO 13485, EU MDR, and the FDA’s current QMSR framework.
The systems that create lasting value are not always the ones with the longest feature lists. They are the ones that can reflect how a regulated business actually works: who approves what, what evidence is required, where risk is higher, how different teams interact, and how process variation should be controlled across products, sites, and functions.
In regulated environments, this matters because quality systems are expected to be defined, followed, maintained, and kept current; under the EU MDR, the manufacturer’s quality management system is also expected to be proportionate to the device's risk class and type.
Feature-heavy platforms promise coverage of every quality process imaginable. On paper, that sounds reassuring. In reality, quality systems are never truly one-size-fits-all, even for companies operating under the same standards.
Organisations differ materially in product complexity, risk classification, approval hierarchies, organisational structure, and regulatory strategy. A system that works well for a ten-person startup managing Class I devices will create real problems for a mid-size company handling Class III products across multiple markets.
When a system cannot be shaped to reflect these differences, teams adapt their processes to the software instead of the other way around. The consequences are predictable: manual workarounds that live outside the system, workflows so over-engineered that users bypass them, shadow spreadsheets, uncontrolled documents, and the kind of inconsistency that generates audit findings.
Ironically, the more features a system has, the easier it becomes to use it incorrectly.
These two terms are used interchangeably, but they describe fundamentally different things; the distinction matters, especially in regulated environments.
A configurable eQMS lets you adjust workflows, fields, states, forms, notifications, and role-based permissions without writing code. Done properly, it supports an upgrade-safe configuration, letting you adapt the system as your business changes without turning every process change into a software project.
Customisation is different. It usually means hard-coded changes, heavier vendor dependence, more complex change control, and a higher validation burden over time. Even when it solves an immediate process gap, it can make future upgrades slower, riskier, and more expensive.
That is why configuration vs customisation should be treated as a core evaluation issue, not a technical footnote. Quality teams need enough flexibility to model their real processes accurately, but they also need to preserve system integrity, traceability, and maintainability.
Regulators are less interested in how many modules your eQMS contains and far more concerned with whether your system reflects your documented procedures, enforces consistent execution, maintains data integrity, and produces complete, intelligible audit trails.
Configurability supports all of this by aligning workflows directly to standard operating procedures, ensuring approvals and reviews match real accountability, and allowing the system to adapt to regulatory change without significant rework.
Under ISO 13485, organisations are expected to operate a quality management system specific to the medical device lifecycle, with stronger emphasis on risk management and regulatory expectations. In the US, the FDA’s Quality Management System Regulation, effective from 2 February 2026, amended 21 CFR Part 820 by incorporating ISO 13485:2016 by reference.
Under the EU MDR, manufacturers must establish, document, implement, maintain, keep up to date, and continually improve a quality management system in a way that is proportionate to device risk and type.
These regulations have a practical implication for software selection. Regulators are not primarily asking whether your eQMS has a training module or a CAPA module. They are asking whether your system consistently executes your documented procedures, maintains traceability, and produces intelligible records and audit trails when inspected. A rigid platform makes it harder to sustain that alignment over time. A configurable one makes it easier to keep the system matched to the way the organisation actually operates.
It is worth being direct about something the configurability argument sometimes glosses over.
In regulated environments, whether under FDA, MDR, or ISO 13485, system changes, including configuration changes, can trigger validation activity. Installation qualification, operational qualification, and performance qualification protocols do not disappear simply because no code was written. Experienced quality professionals know this, and a vendor that implies otherwise will quickly lose credibility.
A well-designed, configurable system won’t eliminate validation burden but will reduce it. When configuration is controlled, versioned, traceable, and separated from the core platform logic, teams are better positioned to assess impact proportionately and document changes clearly. That is far more defensible than a heavily customised system where even small changes may require vendor intervention and wider revalidation.
So one of the best vendor questions is not “Can we configure it?” but “How is configuration governed?” Is it version-controlled? Is there an audit trail? Can changes be assessed and documented without involving developers? Can validated configurations survive platform upgrades cleanly?
The real test of any eQMS is not how it performs at implementation. It is how it performs eighteen months later, when the business has changed in ways nobody fully anticipated.
A mid-sized medical device company may begin with one site, a focused product portfolio, and relatively straightforward approval paths. Eighteen months later, it may have added a contract manufacturer, entering a new market, preparing for an FDA 510(k) submission, or introducing a software-enabled product with different documentation and design control expectations. Each of those changes creates legitimate pressure on the quality system.
A feature-led system often reaches its limits at that point, not because it lacks a CAPA screen or a training record, but because it cannot absorb process variation without disruption. Suddenly, the business needs different approval chains by site, different review logic by product family, tighter access rules for selected records, and different levels of control depending on risk. That is where multi-site workflows, configurable forms, and role-based permissions stop being nice-to-haves and start becoming operational necessities.
A configurable system can evolve alongside the business: different workflows per site or product where justified, role-based access that reflects real governance, and progressive tightening of controls as risk increases.
When users struggle with an eQMS, the instinctive response is more training. Sometimes that is the right answer. Often it isn’t.
Persistent adoption problems usually point to poor structural design choices: irrelevant mandatory fields, screens cluttered with information most users do not need, approval chains that do not reflect actual accountability, or workflows that are far more bureaucratic than the underlying risk justifies.
None of these problems is solved by training. They are solved by configuration.
This matters because adoption is central to compliance. A system that is theoretically robust but routinely bypassed is a weak control environment. A system that is right-sized for each role is far more likely to be used consistently. That is why configurability in eQMS should also be viewed as a usability and change-management issue, not just a technical one.
Good configuration helps teams create controls that people will actually follow, and compliance becomes a natural by-product of execution rather than a separate administrative burden. The friction does not disappear; it simply becomes proportional.
Configurability is easy to claim and harder to verify. A vendor demonstration will always show the system at its most flexible. The right questions are specific:
The answers will reveal whether configurability is a genuine architectural principle or a marketing position.
A useful rule of thumb is this: if the answer depends heavily on services, scripting, or developer involvement, you may be looking at customisation dressed up as configuration.
The more sustainable model is controlled flexibility: enough freedom for quality teams to shape workflows to SOPs and operational reality, but within a system that preserves traceability, version control, audit history, and upgradeability.
Principles only matter if they can be executed in real regulated environments, so it is worth illustrating what this looks like with a concrete example.
Cognidox was built around the premise that quality systems should reflect how regulated organisations actually operate, rather than impose a vendor-defined process model. Configurable workflows, approval paths, and state transitions can be aligned directly to standard operating procedures without hard-coded changes or developer dependency. Quality events, records, and documents can be structured using configurable fields, so teams capture what is relevant to their risk profile without cluttering the system with inputs that serve nobody.
Document and design control, CAPA and non-conformance, supplier management, and training sit within a single system model, and organisations can decide how tightly or loosely these processes are connected based on their regulatory strategy and maturity. As the business grows, multiple sites and entities can be supported with role-based permissions that reflect real accountability, variation where justified, and consistency where required.
Importantly, none of this configurability comes at the expense of auditability. Full traceability, version control, and defensible audit trails are preserved throughout. That combination of flexibility without compromising control is the design principle, not the feature list.
When choosing an eQMS, the key question is not whether the platform contains every feature on a comparison sheet.
It is whether the system can accurately reflect how you operate today, and adapt as you grow, without creating unnecessary validation burden, upgrade risk, or user resistance.
In regulated environments, precision usually beats breadth. A system that mirrors your procedures, supports clean audit trails, and lets you apply the right level of control in the right places will usually outperform a broader platform that your teams never fully adopt.
That is why configurability in eQMS is not a nice-to-have. It is one of the clearest predictors of whether the system will still be working for you when the organisation, the regulation, and the product portfolio have moved on.
See how Cognidox is designed to support controlled, upgrade-safe configuration for regulated teams in a dedicated demo, or contact our team to find out more.
Configurability in eQMS means being able to adjust workflows, fields, permissions, forms, and approval logic without custom code. In practice, it is what allows the system to match your SOPs, roles, and risk profile while staying controlled and maintainable.
Configuration usually means controlled changes made within the platform’s existing framework. Customisation usually means code-level or bespoke changes. The first is generally easier to govern and keep upgrade-safe; the second often brings more vendor dependence and validation overhead.
It can reduce validation burden, but it does not remove it. Configuration changes may still need documented assessment and validation. The advantage is that controlled, versioned configuration is usually easier to assess and justify than bespoke software changes.
A configurable eQMS can support different workflows, approvals, and access rules by site, entity, or product line while maintaining central control. That matters when organisations scale, add partners, or operate across different regulatory and operational contexts.
Yes. That is why teams should ask whether configurations are upgrade-safe and how existing validated configurations are handled during platform updates. A mature platform vendor should be able to explain that clearly.