ISO 27001 A.8.19: Control software installed on operational systems

What A.8.19 requires in practice

A.8.19 requires procedures and measures to manage the installation of software on operational systems securely. Operational systems are those the business relies on for live work, so a poor installation can disrupt service or weaken security as well as introduce unwanted software.

In practice the organisation decides what software may be installed, who may install it, how it is checked before and after installation and what happens if the installation fails. Checking includes the source of the software and its likely effect on the operating environment. The control covers updates and supplier-delivered changes as well as new products, and it applies to local installation by users as well as by administrators.

Outputs include a clear route for approved software, restricted installation rights, records of what was installed and arrangements for backing out a bad installation. The control does not set a particular list or tool. Keeping an approved software list is one method Sterling's teams use, but a list is not stated as a requirement.

Make permitted software understandable

Define which software users may obtain through approved routes and which requests need assessment. Consider the business purpose, information handled, source, support status and integration with existing systems. A useful approval process should be accessible enough that employees can request a needed tool instead of quietly installing an unreviewed substitute.

Limit installation privileges according to roles and the environment. Some approved tools may be available through a controlled catalogue, while changes to critical systems may need a more closely managed route. The relevant question is whether the organisation can maintain an authorised, supportable state, not whether every installation uses the same human approval step.

Check the source and the operational effect

Obtain software and updates from legitimate, approved sources and verify them appropriately. Evaluate relevant dependencies and externally supplied components rather than assessing only the main application name. An apparently small addition can introduce new access, data transfers or maintenance responsibilities.

Test the change in a way proportionate to the affected service. Review the intended security benefit alongside compatibility and operational risks. Connect updates with vulnerability management so a convenient delay does not leave an important weakness untreated without a decision.

Why controlling software installation matters to the business

Software installed on a live system changes what the business depends on. An untested update can halt service; an unapproved tool can carry malware or open a path for attackers; an unsupported product can leave known weaknesses with no fix. Control over installation protects operations, reduces surprise and keeps the organisation's licensing position clear. It also helps with recovery, because a recorded installation history makes it easier to see what changed before a fault. Clients with strict service agreements expect suppliers to change live systems in a controlled way. Auditors often sample installed software and compare it with approvals, so gaps between what is permitted and what is present show up quickly.

How to implement A.8.19

Make it easy to install the right software and hard to install the wrong software. People bypass routes that are slow or unclear, so the approved path has to be practical.

1. Decide which categories of software are permitted on operational systems and who may approve additions.
2. Restrict installation rights so that only authorised roles can install, and users cannot add tools by default.
3. Check the source of each product or update, and consider its effect on the live environment before installing.
4. Test where practical in a separate environment, and schedule installation to limit the effect on service.
5. Prepare a way back, so a failed installation can be reversed and the system returned to its previous state.
6. Record what was installed, when and by whom, and link the record to the change that approved it so faults can be traced back.
7. Review support status and compare installed software with what is approved, acting on differences, including products that the supplier no longer maintains.

Evidence an auditor expects for A.8.19

An auditor will compare what is allowed with what is present and ask how the route works. Typical evidence includes:

• records of approved software categories and how approvals are given;
• settings showing who can install software on operational systems;
• records of recent installations or updates, with the approval, test and outcome;
• observation of a sample system, comparing installed software with what was approved;
• an interview with an administrator about how a failed installation would be reversed.

A sampled system that matches the approved position is strong evidence. Differences are not automatically a failing, but each needs a recorded explanation.

Common nonconformities with A.8.19

Installation findings usually involve software that arrived outside the approved route.

• Users or local administrators able to install tools on live systems with no approval.
• Updates applied directly to production with no testing and no way back.
• Unsupported or end-of-life software still running, with no recorded decision.
• No record of what was installed, so the cause of a fault cannot be traced to a change or to the person who made it.
• Software from unverified sources installed because the approved route was too slow, with no one reviewing why the route is avoided.

Illustrative BPO example: a local file-conversion tool

Illustrative construction example: a supplier's planning-system update

A hypothetical construction company arranges an update to its operational planning software. The supplier requests broad access for an unspecified period and proposes installing directly into the live environment. The project team is focused on gaining the new feature before a reporting deadline.

The company agrees the version, scope, authorisation, testing and appropriate recovery arrangements before deployment. Supplier access is limited to the necessary work and reviewed afterwards. The completion evidence includes a check of the installed version and a representative planning task, so the decision is based on the operating result rather than the supplier's statement that installation finished.

Plan for an unsuccessful installation

Before deployment, determine what the organisation will do if the software fails or has unacceptable effects. Depending on the system, this may involve a tested rollback, restoration or another recovery route. Understand limitations: some changes cannot be safely reversed by simply reinstalling an older version.

Keep relevant versions, configuration and supporting information where justified by recovery or record-access needs. Coordinate with configuration management and change management. An installation should leave both the system and its operational record in an understood state.

Review support status and actual deployment

Software that remains installed continues to need ownership. Track relevant support and maintenance arrangements, including components that are no longer maintained. Evaluate the risks and treatment options rather than assuming that a program is safe because it has worked without an obvious incident for years.

Useful evidence includes approval, source verification, relevant tests, deployment records, recovery decisions and confirmation of the installed state. These are practical evidence options rather than mandated document titles. A sample review can trace one operational application from request to current version and identify any unexplained difference.

Common failures include general administrator rights for convenience, supplier updates without internal ownership and deployment records that do not match live systems. Use operational planning and control to review these gaps. The control should make software changes dependable enough to support the business, while preserving an appropriate route for urgent security updates.