Changes are tested independently, following the defined test plan, before they move into the live environment: the development team's categorised error log is reviewed to confirm each error has been fixed or formally accepted; final acceptance is judged against the success criteria and the results are presented in a way process owners and IT can understand, so they can decide on an informed basis; acceptance is formally signed off by process owners, IT stakeholders and, where relevant, third parties before promotion; testing follows the plan and is designed and run by a testing group that is independent of the developers; tests and expected results follow the success criteria in the plan; scripted test instructions are reviewed and approved by the independent group; a suitable mix of automated and interactive user testing is used; security testing measures weaknesses and takes account of security incidents that have occurred since the plan was written; performance testing covers a range of measures, such as response times for end users and the speed of database updates; the fallback and rollback parts of the plan are addressed; and errors are identified, logged and classified, with an audit trail of results and communication as the plan requires.
This control maps to 2 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 2 it maps to, and the evidence behind each claim, over MCP and REST.