ISO 27001 A.8.19 - Installation of Software on Operational Systems

Requirement

“Procedures and measures shall be implemented to securely manage software installation on operational systems.”

Plain-language meaning

Operational systems should not accept software changes just because someone has technical ability to install them. New software, updates, libraries, patches, scripts, packages, and configuration-affecting components should follow an approved process before they reach production.

The key point is integrity. Unauthorized or untested software can break services, introduce vulnerabilities, bypass segregation of duties, create licence issues, or hide fraud.

Why this matters

Production software installation is one of the fastest ways to damage confidentiality, integrity, and availability. A competent developer or administrator can still create risk by installing a “standard library”, hotfix, plugin, or vendor package without approval, testing, rollback, licence confirmation, or support validation.

This control connects strongly to A.8.4 Access to Source Code, A.8.8 Management of Technical Vulnerabilities, A.8.9 Configuration Management, A.8.15 Logging, and A.5.37 Documented Operating Procedures.

Implementation guidance

1. Define installation authority

Only authorized and competent personnel should install or update software on operational systems. Separate development, approval, release, and production installation duties where practical.

2. Require business justification and approval

New products, libraries, utilities, vendor packages, and updates should have a business requirement and approval before installation. Emergency installation should still be recorded and reviewed afterwards.

3. Test before production

Software should be tested before installation, including security checks, compatibility checks, regression testing, operational impact, and rollback validation where practical.

4. Preserve rollback capability

Before installation, retain backups of relevant software, configuration, data, and deployment artifacts. Define a fallback strategy so the previous version can be restored if the installation fails.

5. Control licences and vendor support

Confirm that software licences permit the intended use and scale. For vendor-supplied software, confirm that support is available for as long as the organization depends on the software.

6. Log and review installations

Record what was installed, by whom, when, why, from what source, under what approval, with what test evidence, and with what fallback path.

Audit guidance

Auditors should verify:

• software installation procedures exist and are used;
• installation privileges are restricted to authorized staff;
• production changes have business justification and approval;
• testing and regression testing occur before installation;
• source code is not unnecessarily included on operational systems;
• system files, object code, libraries, and deployment artifacts are protected;
• previous versions and configurations can be restored;
• backups are taken before significant changes;
• licence and support requirements are checked;
• developers and maintenance staff understand the risk of unapproved production code.

Auditors should interview developers, administrators, release managers, and maintenance staff. The weak point is often informal “small” changes that bypass the process.

Evidence examples

Strong evidence

• Production installation links to a change ticket or release record.
• Security and regression testing are completed before installation.
• Deployment is performed by authorized personnel.
• Installation logs identify installer, date/time, package/version, and target system.
• Rollback procedure and backup evidence exist.
• Licence entitlement and vendor support are confirmed.
• Emergency installation is retrospectively reviewed.

Weak evidence

• Developers install directly into production.
• “Small” libraries or tools are installed without change control.
• Testing evidence is verbal or missing.
• Rollback depends on memory or manual recreation.
• Licences are assumed rather than verified.
• Vendor support has expired but the software remains operational.
• Source code is present on production systems without justification.

Common failures

Exam traps

Related controls and concepts

• A.8 Technological Controls MOC
• A.8.4 Access to Source Code
• A.8.8 Management of Technical Vulnerabilities
• A.8.9 Configuration Management
• A.8.15 Logging
• A.5.3 Segregation of Duties
• A.5.32 Intellectual Property Rights
• A.5.37 Documented Operating Procedures
• Risk Assessment
• Statement of Applicability
• Operational Software Installation Procedure
• Operational Software Release and Installation Record
• Software Rollback and Fallback Checklist
• Software Licence and Support Verification Checklist
• A.8.19 Audit Evidence Pack
• A.8.19 Audit Checklist

KB-ready summary

• Restrict production installation rights.
• Require business justification and approval.
• Test before installation.
• Back up and define fallback.
• Verify licences and support.
• Log all production installations.

Templates and checklists

• Operational Software Installation Procedure
• Operational Software Release and Installation Record
• Software Rollback and Fallback Checklist
• Software Licence and Support Verification Checklist
• A.8.19 Audit Checklist