Aim: perform the integration work and the integration testing of software alone and of software on hardware, and show software and hardware interact correctly to deliver their functions. Integration progressively combines separately tested components into a whole so that interfaces and the assembled software are proven before system integration and test. Any change to the integrated system during software/hardware integration gets an impact study naming affected components and the re-verification needed. The Tester writes the software integration test report per the generic rules: results and whether the specification's objectives and criteria were met, the circumstances of any failure, recorded cases and results (preferably machine readable), repeatable and where practicable automated tests, which items were involved and in what configuration, and correct use of the Table A.6 techniques as a set meeting 4.8 and 4.9. Where Table A.1 requires, the Tester writes the software/hardware integration test report on the same pattern. Where Table A.1 requires, the Verifier's integration verification report judges both reports as records of the specified tests and against the readability, traceability and specific requirements.
This control maps to 8 controls across 4 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 8 it maps to, and the evidence behind each claim, over MCP and REST.