Installation of software on operational systems
Procedures and measures are to be put in place so that installing software on operational systems is managed securely.
What the requirement asks
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. In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.
What the guidance adds
Software installation is a change. The guidance asks for the approval, the source, the test and the record.
Status of the guidance. The guidance lens for 8.19 reads the draft, which is at stage 40.00 and is not published, against the published ISO/IEC 27001:2022 requirement above. It is our reading, not a quotation, and it is not a requirement.
What good looks like
Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep procedures for installing and updating operational software, including authorization, testing and rollback planning and one live sample together.
Evidence an assessor asks for
- Software installation controlProcedures for installing and updating operational software, including authorization, testing and rollback planning
- Software installation controlChange and deployment records showing management authorization, successful testing and the administrator who performed the installation
- Software installation controlConfiguration control records for operational software and documentation, and an audit log of updates
- Software installation controlEvidence that development tools and compilers are absent from production systems
- Software installation controlA software support status register flagging unsupported vendor software and unmaintained open source components, with risk decisions
- Software installation controlEndpoint and server policies restricting user software installation by role, with permitted and prohibited categories
The question an assessor will ask
An assessor will ask for procedures for installing and updating operational software, including authorization, testing and rollback planning, then trace it to the system it protects. For A.8.19 the test is whether that record ties to a live sample, not whether the control is named in a policy.
Common gaps
- Users can install any software on servers or workstations
- Production systems contain compilers and development code
- Unsupported software versions remain in production without a risk decision
- Externally hosted dependencies are pulled at build or run time without integrity controls
Before the next audit
Before the next audit, check one live sample for this gap: users can install any software on servers or workstations.