Zum Hauptinhalt springen
CENEDRIL WIKI
DE
Annex A · Technological Control

A.8.19 — Installation of Software on Operational Systems

Updated on 4 min Reviewed by: Cenedril Editorial
A.8.19 ISO 27001ISO 27002BSI APP.6

A system administrator installs a new monitoring tool on a production database server. The tool works well — but it also opens a network port that bypasses the firewall rules. Three weeks later, a scanner finds the open port and reports it as a critical finding. A.8.19 requires a formal process for installing software on operational systems — testing before deployment, authorization and rollback capability.

Uncontrolled software installation on production systems introduces vulnerabilities, compatibility issues and unauthorized functionality. This control ensures that only tested, approved software reaches operational environments.

What does the standard require?

  • Restrict installation authority. Only trained, authorized administrators may install software on operational systems.
  • Install only approved software. Software must be tested and formally approved before installation on production systems.
  • Test before deployment. Verify compatibility, security and functionality in a test environment before installing on production.
  • Define rollback procedures. If an installation causes problems, a documented rollback process must exist.
  • Log all installations. Record what was installed, when, by whom and which version.
  • Manage software lifecycle. Track installed software versions, assess risks of unsupported or end-of-life software and plan migration.

In practice

Maintain an approved software list. Create and regularly update a catalogue of approved software for each system type. Software not on the list requires a formal request, security assessment and approval before installation.

Use centralized deployment tools. Deploy software through SCCM, Intune, Ansible or similar tools. This ensures consistent versions, automatic logging and the ability to roll back across the entire fleet.

Test in a staging environment. Before any production deployment, test the software in a staging environment that mirrors production. Verify functionality, check for conflicts with existing software and run vulnerability scans.

Monitor for unauthorized installations. Use endpoint management tools to detect software installed outside the approved process. Flag unauthorized installations for review and remediation.

Typical audit evidence

Auditors typically expect the following evidence for A.8.19:

  • Software installation policy — documented rules for approval, testing and deployment (see IT Operations Policy in the Starter Kit)
  • Approved software list — current catalogue of approved software
  • Installation logs — records of software installed on production systems
  • Test evidence — documentation of pre-production testing
  • Lifecycle inventory — list of installed software with version, support status and end-of-life dates

KPI

Percentage of operational systems with enforced software installation policy

Measured as a percentage: how many production systems restrict software installation to authorized administrators with logging enabled? Target: 100%.

Supplementary KPIs:

  • Number of unauthorized software installations detected per month
  • Percentage of installed software that is within active support lifecycle
  • Mean time from software request to approved deployment

BSI IT-Grundschutz

A.8.19 maps to BSI modules for software management:

  • APP.6 (General Software) — requirements for managing software throughout its lifecycle, including approval, installation and decommissioning.
  • OPS.1.1.6 (Software Testing and Approval) — testing and formal approval before production deployment.
  • OPS.1.1.3 (Patch and Change Management) — software installation as part of the change management process.

Sources

Frequently asked questions

Can end users install software themselves?

ISO 27001 requires that installation is restricted to authorized personnel. If end users are permitted to install certain categories of software (e.g., from an approved app store), this must be documented in the policy and the approved software list must be maintained.

What about automatic updates?

Automatic updates for security patches are generally desirable (A.8.8), but major version upgrades should go through the change process. Define which update categories are auto-approved and which require testing and approval.

How do we handle open-source software?

Open-source software follows the same approval process as commercial software. Additionally, assess licence compliance, maintenance status (is the project actively maintained?) and known vulnerabilities. Abandoned projects with no security updates pose significant risk.