Every duty your device class actually carries - traced to the provision that imposes it.
Aigis binds Regulation (EU) 2017/745, Regulation (EU) 2017/746, the MDCG guidance, the ISO and IEC standards your QMS already runs on, and the FDA's premarket, postmarket, QMSR and AI expectations into a single register - gated to the device you actually make, with the provision behind every requirement.
262
Requirement checks across 13 instruments
Every one
Cited to the provision it comes from
Class I → III
Device class changes what you're asked
EU + US
Both markets in one register
Checklists that don't know what you make
A device company's burden is defined by class, market and software safety class. Almost nothing on the market models any of them.
One checklist for every class
A flat MDR checklist asks a Class I manufacturer for a PSUR it doesn't owe, and asks an implantable manufacturer for nothing extra. Class is what changes the duty, and a list can't express it.
A paraphrase of a paraphrase
Requirements copied from a consultant's deck, two removes from the regulation. When a notified body asks where a requirement comes from, nobody can produce the provision.
Two markets, three spreadsheets
MDR and IVDR tracked in one place, FDA's cybersecurity expectations and the QMSR in another, ISO 13485 in a third. The same control gets evidenced three times and reconciled never.
Regulatory duty as structured, cited data
Not a content library. Each requirement is a check with an activation condition, a parameter set and the provision it comes from.
The provision behind every check
Every EU and US requirement check carries the verbatim text of the article, section or CFR provision it derives from. For the ISO and IEC standards, each check carries the clause reference and the text stays with your licensed copy. Spot-audit any one of them in seconds - which is what an auditor will do.
Class-gated obligations
Class I gets the Article 85 post-market surveillance report. Class IIa and above get the Article 86 PSUR. Class III and implantables - other than custom-made or investigational devices - add the Article 32 SSCP, and Article 61 adds the clinical investigation and PMCF duties subject to its equivalence route. IVD classes A to D gate the same way.
The real clocks, as parameters
Serious incidents in 15 days (Art. 87(3)), a serious public-health threat in 2 (Art. 87(4)), death or unanticipated serious deterioration in 10 (Art. 87(5)). Technical documentation kept at least 10 years after the last device covered by the EU declaration of conformity is placed on the market, and at least 15 for implantables.
One control, read across frameworks
ISO 13485:2016, ISO 14971:2019 and ISO/TR 24971:2020 sit under the same canonical obligations as MDR and IVDR - so risk-management evidence is gathered once and read across all of them, rather than assembled per framework.
Software lifecycle by safety class
IEC 62304 class B and above trigger defect-category identification, SOUP functional-requirement specification and anomaly-list evaluation. Class C adds documented development standards, methods and tools (Cl. 5.1.4). The class you declare is the class you're held to.
US duties tracked as duties
The FD&C Act §524B(b) duties - the (b)(1) monitoring plan with coordinated disclosure, (b)(2)(A) on-cycle and (b)(2)(B) out-of-cycle patching, the (b)(2) cybersecure-design processes and the (b)(3) SBOM - bound as four separate checks, activating only for the five submission pathways §524B(a) names, and only for internet-connectable devices - tracking the §524B(c) cyber-device definition.
AI-enabled devices, both sides
MDCG 2025-6 covers how the AI Act interacts with MDR and IVDR for high-risk AI medical devices. The FDA's Predetermined Change Control Plan guidance covers AI-enabled device software functions entering the US market.
The postmarket clocks, in context
For vulnerabilities with uncontrolled risk, FDA's 30-day customer-communication and 60-day fix expectations. Meeting them - together with FDA's other two conditions, no known serious adverse events or deaths and active ISAO membership - is what takes you out of enforced 21 CFR Part 806 reporting, not what routes you into it.
SBOM split the way FDA splits it
The machine-readable SBOM, the per-component support level and end-of-support date, and the statutory §524B(b)(3) SBOM are three distinct requirements - because FDA treats them as three distinct things.
What we bind, and where it comes from
Every instrument below is implemented as cited requirement checks, not as a summary page. Counts are of individual checks, which are not deduplicated across instruments.
Regulation (EU) 2017/745 (MDR)
EU
Arts. 10, 13, 14, 16(4), 32, 61, 83–87
43 requirement checks across 9 obligation families. The class-specific duties - Arts. 32, 61(4), 61(11), 85 and 86 - activate on the declared device class.
MDR - cybersecurity requirements
EU · same regulation
Annex I §§ 17.1, 17.2, 17.4, 18.8, 23.4
20 checks on Regulation (EU) 2017/745 - 5 on the Annex I software and IT-security requirements, and 15 restating Article-level MDR duties, all but the Art. 86 PSUR carrying a software activation condition.
Regulation (EU) 2017/746 (IVDR)
EU
Arts. 10, 48(1), 80, 81
24 checks for software-containing IVDs. Classes A and B get the Art. 80 PMS report; Classes C and D get the Art. 81 PSUR.
MDCG 2019-16 Rev. 1 (July 2020)
EU guidance
§§ 3.1, 3.2, 3.3, 3.6, 3.8, 4.1, 5.1, 5.2, among others
19 checks against the MDCG's cybersecurity guidance for MDR and IVDR, cited to its own sections.
MDCG 2025-6 / AIB 2025-1 (June 2025)
EU guidance
Q7, Q22, Q36, among others
8 checks on the interaction between the AI Act and MDR/IVDR, activating only for high-risk AI medical devices placed on the EU market.
ISO 13485:2016
International
Cl. 4.2.5, 7.1
31 quality-management-system checks, including records retained across the lifetime of the device.
ISO 14971:2019
International
Cl. 4.1
7 risk-management checks, sharing canonical obligations with MDR Art. 10(2) so the evidence is gathered once.
ISO/TR 24971:2020
International
Cl. 4.2, 4.4, Annex H.6.2
21 checks carried on ISO/TR 24971's own clause numbering, which parallels ISO 14971's, so the guidance resolves against the same canonical obligations as the standard it explains.
IEC 62304:2006+AMD1:2015
International
Cl. 5.1.4, 5.2.2, 5.3.3
24 software-lifecycle checks; the class-specific ones activate on the declared software safety class.
FDA premarket cybersecurity guidance
US guidance
FD&C Act § 524B(b), (c); Sections V.A.4, V.A.6, V.B.1
20 checks against the 3 February 2026 revision, which supersedes the 27 June 2025 edition, including the Section V.B.1 requirement covering all eight FDA security-control categories.
FDA postmarket cybersecurity guidance
US guidance
Section VII.B; 21 CFR Part 806
12 checks. For vulnerabilities with uncontrolled risk, the 30-day customer-communication and 60-day fix expectations, ISAO membership, and the Part 806 reporting duty FDA will not enforce where all four circumstances are met.
21 CFR Part 820 (QMSR)
US
§§ 820.1(a), 820.10, 820.35, 820.45
18 mandatory checks against the quality management system regulation as amended, including the seven complaint-record fields required under § 820.35(a)(1)–(7).
FDA PCCP guidance
US guidance
Sections III, V, VI, VII
15 checks for AI-enabled device software functions, covering the change-control plan and its modification protocol.
