Deployment ensures that software installed in its final operating environment still does what is required and keeps its required safety integrity level and dependability. A deployment process is defined for the generic software, the application data and the application tools in a software release and deployment plan (9.1.4.1 to 9.1.4.5); each version is released with a release note identifying the version, the configuration (documents, sources, configuration items), the exported constraints or application conditions and the versions of the hardware, operating system and interfacing software it depends on (9.1.4.4-5, with 7.7.4.12); a software deployment manual defines the loading process, the check that the version loaded correctly (self-identification), the functional checks that it works in its environment, the reversal to the previous configuration if it does not, and the update of the equipment configuration records (9.1.4.12-20); deployment records log each deployment with its results and the new configuration, and a deployment verification report shows that the deployment outputs were verified (9.1.4.6-9). The software design allows the deployed version to be identified and the compatibility of software, data and hardware to be checked (9.1.4.10, .13, .16 and .20, referenced from the design specification). Plan, manual, records and verification report are R at Basic Integrity and HR above it, the release note HR at every level (Table A.1 rows 36 to 40).
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.