Procedures and measures are to be put in place so that installing software on operational systems is managed securely. Purpose: keep operational systems intact and prevent technical vulnerabilities being exploited. Guidance: consider having operational software updated only by trained administrators with management authorization; installing only approved executable code, never development code or compilers, on operational systems; installing or updating software only after extensive, successful testing (8.29, 8.31); updating all related program source libraries; controlling all operational software and system documentation through a configuration control system; deciding how to roll back before any change goes in; keeping an audit log of every update to operational software; and archiving previous versions together with everything needed to run them again, such as parameters, procedures, settings and supporting software, as a contingency and for as long as they are needed to read or process archived data. Decisions to move to a new release weigh the business need and the release's security, such as new security features or the number and severity of vulnerabilities in the current version, and patches are applied where they remove or reduce vulnerabilities (8.8). Software that depends on externally hosted modules or packages should be monitored and controlled against unauthorized changes that could introduce vulnerabilities. Vendor software should be kept at a supported level and open source software at the latest suitable release, with the risks of unsupported or no longer maintained software considered. Suppliers installing or updating software get physical or logical access only when necessary and authorized, and their activity is monitored (5.22). Strict rules define which software users may install, applying least privilege: identify permitted installations such as updates or security fixes for software already in use and prohibited ones such as software for personal use or of unknown or suspect origin, and grant installation rights by role.
This control maps to 87 controls across 29 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.
ISO 27002:2022 8.19 is one control. If you already hold one of the frameworks below, a reviewed crosswalk already says how much of ISO 27002:2022 your existing evidence covers. Hold NIST SP 800-53 Rev 5 and 79 of 93 ISO 27002:2022 controls already carry evidence.
Each report names every control your existing framework evidences, every one it does not, the reasoning behind each claim, and the claims that were argued against and rejected. 180 were rejected on the NIST SP 800-53 Rev 5 pair alone.
The graph holds this control, the 87 it maps to, and the evidence behind each claim, over MCP and REST.