Suppliers should work under a QMS, ideally grounded in recognised standards, that sets out: how products are delivered and supported; how customer needs are understood and business, quality and regulatory requirements captured; who is responsible for what, with quality assurance holding authority separate from development, support, finance and marketing; the deliverables; how documents, records and information are managed; scheduled QMS reviews and internal audits; how incidents, problems and nonconformities are handled; and how the organisation keeps improving, including by taking up current development models and tools. The QMS rests on a life cycle concept, any sound life cycle (Agile among them) being acceptable, and contains procedures for managing and releasing software, controlling development changes, configuration management, traceability, training staff, managing documents and records, and backup and restore. Supporting documentation for software products is used through the life cycle, custom modules are documented in full, and industry guidance informs but never overrides the supplier's own QMS.
This control maps to 1 controls across 1 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
The graph holds this control, the 1 it maps to, and the evidence behind each claim, over MCP and REST.