CAHIR Solutions
Back to products

Compliance and governance

Medical device compliance frameworks

Medical device development sits at the intersection of quality-system regulation, risk management, software lifecycle controls, data integrity and emerging AI governance. This page sets out the frameworks MedTech Compass is designed to align with, why each matters, which device classes and product types they affect, and what the product does to keep your records defensible.

Book a live demoExplore MedTech Compass
Layered illustration representing quality, risk, software and AI governance frameworks stacked together

Framework summaries by risk class and product type

Each framework below carries a short summary, the device classes and product types it most directly affects, and how MedTech Compass supports the work it demands.

FDA and EU quality frameworks for medical devices

Quality-system regulation defines how a device is designed, produced and documented before it ever reaches a market.

FDA QSR / 21 CFR Part 820

The U.S. Quality System Regulation defines design controls, purchasing controls, production and process controls, CAPA and record-keeping expectations for medical device manufacturers. Its alignment with ISO 13485 under the Quality Management System Regulation makes a single documented system workable across both regions.

Relevant to

  • Class II and Class III devices sold in the United States
  • Any device requiring a 510(k), De Novo or PMA submission
  • Manufacturers establishing a U.S. quality management system

What MedTech Compass does here: Compass captures the device classification, product code and premarket route that set the scope of your design controls.

EU MDR 2017/745

The European Medical Device Regulation governs device classification, clinical evidence, post-market surveillance and CE marking across EU member states. Rule 11 pulls most clinical decision-support software into Class IIa or higher, which changes both the evidence burden and the notified-body route.

Relevant to

  • All classes of devices placed on the EU market (Class I, IIa, IIb, III)
  • Products requiring a notified-body conformity assessment
  • Legacy MDD certificates transitioning to MDR

What MedTech Compass does here: Compass flags the likely MDR class and conformity-assessment route alongside the U.S. pathway, so both plans move together.

UK MDR 2002 / UKCA

Post-Brexit UK rules maintain CE-recognition timelines while introducing UKCA marking and Approved Body oversight for Great Britain. Manufacturers outside the UK also need a UK Responsible Person and MHRA registration before placing a device on the market.

Relevant to

  • Devices marketed in England, Scotland and Wales
  • Manufacturers transitioning from CE to UKCA marking
  • Class I measuring or sterile devices and higher-risk classes

What MedTech Compass does here: Compass scores UK market attractiveness next to the EU, so the UKCA decision is made with reimbursement and adoption data in view.

Risk, software lifecycle and usability standards

These standards translate quality-system requirements into day-to-day engineering evidence: risk files, software records and human-factors data.

ISO 13485

The international quality-management standard for medical devices emphasises risk-based processes, traceability, design control and supplier management. It is the practical backbone for CE marking and a common baseline for FDA alignment.

Relevant to

  • All risk classes seeking a globally recognised QMS
  • EU MDR and UKCA quality-system evidence
  • Manufacturers pursuing FDA QSR alignment

What MedTech Compass does here: Structured management reviews, internal audit logs and versioned decision records keep QMS evidence consistent.

ISO 14971

The risk-management standard provides a framework for hazard identification, risk estimation, evaluation, control and residual-risk acceptability across the product lifecycle, with production and post-production feedback closing the loop.

Relevant to

  • Class II and Class III devices with clinical or biological risks
  • SaMD and connected devices with cybersecurity or algorithmic risks
  • EU MDR and FDA design-control documentation

What MedTech Compass does here: Regulatory findings are traceable to their sources, so risk rationales cite evidence rather than recollection.

IEC 62304

The medical-device software lifecycle standard defines development, maintenance, risk management and change-control activities, with the effort scaled by software safety classification (A, B or C).

Relevant to

  • Software as a Medical Device (SaMD)
  • Embedded software in Class II/III hardware
  • AI/ML-enabled devices with frequent software updates

What MedTech Compass does here: Copilot structures software lifecycle documentation so records stay aligned with the classification you are working to.

IEC 62366-1

Usability engineering reduces use-related risk through user research, formative evaluation and human-factors validation — increasingly a review focus for devices with clinician- or patient-facing interfaces.

Relevant to

  • Devices with complex user interfaces or high use-error risk
  • Class II/III devices where human factors are critical to safety
  • SaMD with clinician or patient-facing workflows

What MedTech Compass does here: Use-related risk considerations surface early, while the market and pathway decision is still open.

Illustration of a product lifecycle loop connected to an audit trail timeline

Electronic records and AI governance frameworks

AI-enabled devices carry a second layer of obligations covering records, model transparency and lifecycle monitoring.

21 CFR Part 11

Sets requirements for electronic records, electronic signatures, audit trails and system validation in FDA-regulated environments, including cloud tools used in GxP workflows.

Relevant to

  • Electronic QMS, batch records and design history files
  • Clinical and regulatory submissions prepared electronically
  • Cloud-based tools used in GxP workflows

What MedTech Compass does here: Automated record retention, validation workflows and electronic signature logs support QMS integration.

FDA AI/ML-based SaMD and GMLP

FDA guidance and Good Machine Learning Practice principles cover model development, validation, transparency, real-world performance monitoring and predetermined change control plans for AI-enabled devices.

Relevant to

  • AI/ML diagnostic, predictive or monitoring devices
  • SaMD with continuously learning or updated algorithms
  • Products subject to predetermined change control plans

What MedTech Compass does here: Total Product Lifecycle monitoring, data lineage tracking and bias analysis are built into how AI outputs are produced.

EU AI Act

The EU's risk-based AI regulation imposes transparency, quality-system, data-governance and human-oversight obligations on high-risk AI, including AI that is a medical device or a safety component of one. It layers on top of EU MDR rather than replacing it.

Relevant to

  • AI-enabled devices classified as high-risk under the AI Act
  • Products placed on the EU market with AI-driven decision support
  • SaMD and clinical decision-support systems

What MedTech Compass does here: Outputs are source-linked and reviewable, which supports the human-oversight expectations reviewers look for.

NIST AI Risk Management Framework and ISO/IEC 42001

A voluntary U.S. framework for governing, mapping, measuring and managing AI risk, paired with the ISO/IEC 42001 AI management-system standard that gives those activities an auditable structure.

Relevant to

  • AI/ML-enabled devices regardless of risk class
  • Organisations building internal AI governance programmes
  • Teams aligning AI risk with cybersecurity and safety work

What MedTech Compass does here: Management reviews, audit logs and SaMD-adjacent AI management controls give the programme a documented spine.

Illustration of data sources flowing into a shielded AI model and out to governance controls

Data protection, security and data integrity

Connected devices and cloud platforms inherit privacy, security and data-integrity obligations alongside device regulation.

GDPR / HIPAA

Privacy and security regulations governing personal data processing in the EU (GDPR) and protected health information in the United States (HIPAA), including lawful basis, minimisation and breach notification.

Relevant to

  • Devices collecting, transmitting or storing patient data
  • Connected devices and cloud-based SaMD
  • Clinical studies and real-world evidence platforms

What MedTech Compass does here: Regulatory analysis runs on device and market descriptions, not patient data.

ISO 27001

The information-security management standard for establishing, operating and continually improving an ISMS — commonly used to evidence the security expectations in FDA cybersecurity guidance and EU MDR Annex I.

Relevant to

  • Connected devices and cloud-hosted medical-device platforms
  • Organisations handling sensitive regulatory and clinical data
  • Supplier and vendor security assessments

What MedTech Compass does here: Access control, encryption in transit and at rest, and tenant separation protect your workspace content.

SOC 2

A service-organisation control framework covering security, availability, processing integrity, confidentiality and privacy — the usual vendor-diligence artefact for SaaS used by regulated manufacturers.

Relevant to

  • SaaS platforms used by regulated manufacturers
  • Vendor due-diligence and procurement reviews
  • Enterprise security questionnaires

What MedTech Compass does here: Security practices are documented so procurement reviews can move without a bespoke audit each time.

ALCOA+ data integrity

Principles ensuring data is Attributable, Legible, Contemporaneous, Original, Accurate, Complete, Consistent, Enduring and Available across GxP systems — the standard against which regulatory decision logs are judged.

Relevant to

  • Regulatory decision records and rationales
  • Electronic evidence supporting submissions
  • Any GxP system generating durable records

What MedTech Compass does here: Every scoring run and regulatory answer is timestamped, attributed and retained with the evidence it used.

Compliance frameworks at a glance

A quick comparison of region, scope and the evidence each framework ultimately drives.

FrameworkRegionApplies toEvidence it drives
FDA QSR / 21 CFR Part 820United StatesClass II and III manufacturersDesign controls, CAPA, DHF
EU MDR 2017/745European UnionAll classes on the EU marketTechnical file, clinical evaluation, PMS plan
UK MDR 2002 / UKCAGreat BritainDevices marketed in GBUKCA declaration, UK Responsible Person, MHRA registration
ISO 13485GlobalAll risk classesQMS procedures, management review, supplier controls
ISO 14971GlobalDevices with clinical or algorithmic riskRisk management file, residual-risk justification
IEC 62304GlobalSaMD and embedded softwareSoftware safety class, lifecycle and change records
21 CFR Part 11United StatesElectronic records and signaturesAudit trails, validation, signature logs
FDA AI/ML SaMD and GMLPUnited StatesAI-enabled devicesModel validation, PCCP, performance monitoring
EU AI ActEuropean UnionHigh-risk AI systemsData governance, transparency, human oversight
ISO 27001 / SOC 2GlobalCloud platforms and vendorsISMS controls, security reports

How compliance shows up inside the product

Framework alignment only counts if it is visible in the records a reviewer can open. These are the controls that carry that weight in MedTech Compass and MedTech Copilot.

  • Timestamped audit trails for every regulatory question, scoring run and configuration change.
  • Source-linked evidence, so each answer points back to the guidance, standard or database entry behind it.
  • Versioned scoring logic and custom weights, so a market decision can be reproduced months later.
  • Data lineage tracking across model inputs and outputs, supporting GMLP and AI Act expectations.
  • Exportable records that slot into design history files, technical files and management reviews.
  • Role-based access with tenant separation, encryption in transit and at rest.

How to map your device to these frameworks

  1. 1Classify the device: confirm the intended use, FDA device class, product code and the equivalent EU MDR rule.
  2. 2Fix the premarket route: 510(k), De Novo, PMA or exempt in the U.S.; the conformity-assessment route and notified-body need in the EU; UKCA in Great Britain.
  3. 3Stand up the quality system: ISO 13485 procedures mapped to FDA QSR clauses, with design controls and supplier management in place.
  4. 4Build the risk file: ISO 14971 hazard analysis covering clinical, cybersecurity and algorithmic risk, refreshed as the design changes.
  5. 5Scope the software lifecycle: assign an IEC 62304 safety class and plan the verification, maintenance and change-control records it demands.
  6. 6Add AI governance where relevant: GMLP practices, a predetermined change control plan, and EU AI Act obligations layered on top of MDR.
  7. 7Close the data loop: 21 CFR Part 11 controls, ALCOA+ integrity, and GDPR or HIPAA handling for any patient data the device touches.

For pathway detail, see the FDA regulatory pathways guide and the EU MDR and UKCA compliance guide. For market prioritisation, start with medical device market intelligence, or try DevicePath for open-source classification and predicate triage.

Share thisLinkedInXEmail

Frequently asked questions

Which compliance frameworks apply to Software as a Medical Device?
Most SaMD teams work to ISO 13485 for the quality system, ISO 14971 for risk, IEC 62304 for the software lifecycle and IEC 62366-1 for usability, plus FDA QSR in the United States and EU MDR — usually Rule 11 — in Europe. AI-enabled SaMD adds GMLP expectations and, for the EU market, the AI Act.
Does an AI tool used in regulatory work need its own device certification?
Not usually. Software that supports internal regulatory strategy and documentation is not itself a medical device, because it has no medical purpose for a patient. What matters is that it produces records you can defend: attributable, traceable and reviewable outputs that fit your own quality system.
What is the difference between FDA QSR and ISO 13485?
ISO 13485 is a voluntary international quality-management standard; FDA QSR is U.S. law. Since the Quality Management System Regulation aligned 21 CFR Part 820 with ISO 13485, most manufacturers run one quality system and document the remaining U.S.-specific requirements, such as certain record and complaint provisions, on top of it.
What does 21 CFR Part 11 require from software used in regulated work?
Validated systems, secure and attributable audit trails, controls over who can create or change records, retention that keeps records readable for their required life, and — where signatures are applied — signature manifestations linked to the record they sign.
How does the EU AI Act interact with EU MDR?
They stack. An AI-enabled device still needs MDR conformity assessment; the AI Act adds obligations on data governance, technical documentation, transparency, human oversight and post-market monitoring for high-risk AI. In practice the notified-body assessment covers both sets of requirements for medical devices.
What does ALCOA+ mean in day-to-day practice?
It means each record shows who produced it, when, from what original source, and remains legible, complete, consistent and available for as long as it is needed. For regulatory decisions that translates into keeping the evidence and the reasoning together, not just the conclusion.

See the compliance controls in a live walkthrough

We will walk through audit trails, source-linked evidence and exportable records against your own device and target markets.

Book a live demoHow MedTech Compass works