What evidence do auditors commonly ask for on 8.19 Installation of software on operational systems?

Procedures for installing and updating operational software, including authorization, testing and rollback planning; Change and deployment records showing management authorization, successful testing and the administrator who performed the installation; Configuration control records for operational software and documentation, and an audit log of updates; Evidence that development tools and compilers are absent from production systems; A software support status register flagging unsupported vendor software and unmaintained open source components, with risk decisions; Endpoint and server policies restricting user software installation by role, with permitted and prohibited categories.

What is the most common gap auditors find on 8.19?

Users can install any software on servers or workstations

ISO/IEC 27002:2022 · Technological controls

`8.19` 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. 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.

Source: ISO/IEC 27002:2022, 8.19. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open ISO/IEC 27002:2022 in the compliance library.

ISO/IEC 27002 is guidance on the Annex A controls; certification is against ISO/IEC 27001. Use this set when your sheet follows the 27002 numbering.

artefacts

held by a system

at each review

moderate

to go live

Source control / CI pipeline

where the evidence lives

teal = a system already holds it · olive = produced at each review. To go live: easy when half or more of the artefacts are already held by a system, moderate from a quarter to a half, hard below a quarter.

These are the artefacts auditors commonly ask for on this requirement, our guidance rather than text from the standard. Your assessor decides what is sufficient in your context, and asks for samples across the period when a report covers one.

system holds itEvidence a system already holds

Change and deployment records showing management authorization, successful testing and the administrator who performed the installation · Source control / CI pipeline
Configuration control records for operational software and documentation, and an audit log of updates · SIEM / log platform

periodic reviewEvidence produced at each review

Evidence that development tools and compilers are absent from production systems · Document repository

governing documentDocuments that govern the control

Procedures for installing and updating operational software, including authorization, testing and rollback planning · Policy repository / GRC workspace
A software support status register flagging unsupported vendor software and unmaintained open source components, with risk decisions · Vendor register / contract repository
Endpoint and server policies restricting user software installation by role, with permitted and prohibited categories · Policy repository / GRC workspace

First move

Start with the 2 of 6 artefacts that already live in a system (Source control / CI pipeline); keep the periodic reviews but log each one as a dated record with a named reviewer.

Common gaps auditors find

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

Do this for your whole sheet

Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.

Build my evidence sheet

8.18 Use of privileged utility programs · 8.20 Networks security