Detailed designs are produced, recorded and worked out step by step with agreed phased or agile techniques, dealing with every component (business processes with their related manual and automated controls, the applications that support them, infrastructure, services and information stores), and the design is reviewed and approved: the workflows and business process activities that will run with the new application are designed progressively, manual control activities included; application processing steps are designed, including transaction types, business rules, automated controls, data definitions, use cases, external interfaces, constraints on the design and any other requirements; data inputs and outputs are classified according to architecture standards, and the design for collecting source data and validating input is documented; the solution's interface and automated data exchange are designed, along with how data is stored, located, retrieved and recovered, with suitable redundancy, recovery and backup; the user interface is simple to use and explains itself; the infrastructure performance the solution needs is taken into account; weaknesses in the design are evaluated proactively across the life cycle; and transactions are auditable and the root causes of processing errors can be traced.
This control maps to 2 controls across 2 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.