The development is structured into defined phases and activities and all information pertinent to the software is recorded through its lifecycle. A lifecycle model is selected and set out in the software quality assurance plan; that plan, verification and validation plan(s), maintenance plan and configuration management plan are drawn up at the start and maintained throughout; quality assurance procedures run in parallel with the lifecycle using the same terminology; all activities of a phase are defined and planned before it starts, each phase divided into elementary tasks with defined inputs, outputs and activities; the SQAP says which verification steps and reports must be produced. Documents are structured for continued expansion, traceable by unique reference with documented relationships, use each term, acronym and abbreviation with one meaning (a glossary), contain or implement every applicable condition of their predecessor and never contradict it, refer to each item by the same name, and are held in a form suitable to be handled, processed and stored; documents may be merged or split without loss of required detail but documents produced by independent roles are not combined; the documents of Table A.1 and Annex C are produced to the extent the SIL requires; a different lifecycle or document structure must be shown to meet all the standard's objectives and requirements (5.3.2.1 to 5.3.2.14).
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.