ISO 27001 Software Installation Control: A.8.19 in Practice

Direct answer: ISO 27001 software-installation control should ensure that only authorised, licensed and risk-assessed software is installed on operational systems. A complete design combines request and approval, trusted distribution, restricted privileges, technical enforcement, current inventory, exception control and detection of unauthorised software.

Uncontrolled software can introduce malware, exploitable components, licence exposure, unsupported dependencies and tools capable of bypassing monitoring. The risk is not limited to traditional desktop installers. Browser extensions, command-line packages, portable applications, mobile applications, infrastructure agents, scripts and container images can all change the operational environment.

ISO/IEC 27001:2022 Annex A control 8.19 addresses installation of software on operational systems. The organisation should interpret it with ISO/IEC 27002 guidance, its risk assessment, legal and contractual requirements and technology context. The practical measures below are guidance, not reproduced standard text.

Define what counts as installation

Set a scope that reflects how software enters the environment:

• managed workstation and server packages;
• mobile applications and device profiles;
• browser extensions and add-ins;
• developer libraries and package-manager dependencies;
• portable executables and scripts;
• agents deployed through cloud marketplaces;
• container images and orchestration components;
• firmware and device utilities; and
• software installed by suppliers or support personnel.

Distinguish production, test and development environments, but do not assume development has no risk. Developers may hold sensitive data, signing keys or access to production pipelines.

Create an authorised software model

An approved catalogue is useful when it records more than a product name.

Field	Decision supported
Product, publisher and version channel	Identifies what is permitted and who maintains it
Business purpose and owner	Confirms legitimate need and accountability
Permitted platforms and user groups	Prevents broad installation beyond need
Licence and procurement status	Addresses legal and commercial conditions
Security assessment	Records source, permissions, vulnerabilities and data access
Update and support route	Shows how risk will remain managed
Distribution source	Prevents downloads from untrusted locations
Expiry or review date	Prompts reassessment of temporary or specialised software

Connect the catalogue to the ISO 27001 asset inventory guide. Discovery data should reconcile to an approved source rather than become a disconnected list.

Design the request and approval path

Capture enough information for a proportionate decision:

1. requester, device or service and business purpose;
2. product, publisher, version and download source;
3. required permissions and integrations;
4. information accessed, stored or transmitted;
5. licence and contractual conditions;
6. security assessment and known vulnerabilities;
7. business and technical approvers;
8. approved installation method; and
9. removal, update and support responsibility.

Low-risk pre-approved software can follow an automated route. Privileged tools, remote-access products, code-signing utilities and applications processing sensitive information should receive stronger review.

Avoid making the process so slow that staff seek alternatives. Publish realistic service levels and provide a controlled expedited route for urgent needs.

Enforce least privilege

Standard users should not receive permanent local administrative rights merely for convenience. Use managed elevation, just-in-time access or approved deployment tools where practical.

Privileged installation accounts should be named, logged, restricted to authorised staff and reviewed. Separate software approval from deployment where risk warrants it. The access-control governance guide explains how business need, privilege and review evidence should connect.

Administrator restriction alone is not sufficient. Some applications run without formal installation, and users may add browser components or execute portable tools. Combine privilege management with execution control and monitoring.

Use trusted distribution and integrity controls

Obtain software from approved repositories, managed stores or verified publishers. Protect internal repositories from unauthorised upload and maintain an accountable release route.

Depending on risk, verify:

• publisher and digital signature;
• file hash or package integrity;
• supported version and security updates;
• malware and reputation results;
• requested permissions;
• known vulnerabilities and dependencies; and
• compatibility with security monitoring and recovery.

Application allowlisting can prevent unapproved code from running, including portable applications. NIST describes application allowlisting as authorising applications and related components against a defined baseline. CISA also recommends allowlisting to restrict unwanted software in its ransomware guidance.

Treat allowlisting as an engineered control. Poorly maintained rules may block essential work or allow overly broad paths, publishers or interpreters.

Discover and reconcile installed software

Collect inventory through endpoint, mobile, server, cloud and development tooling. Reconcile observed installations with approved software and exception records.

Define response categories:

• approved and current;
• approved but unsupported or vulnerable;
• authorised temporarily;
• unknown and under investigation;
• unauthorised but non-malicious; and
• prohibited or suspected malicious.

Assign response time according to risk. Removal should preserve evidence where malicious activity is suspected. Repeated unauthorised installation may indicate a design problem, missing business capability or deliberate misconduct; investigate rather than treating every case identically.

Control special environments

Servers and production platforms

Link installation to change management, maintenance windows, testing, rollback and baseline configuration. Prevent direct package changes that bypass deployment records.

Developer workstations and pipelines

Use approved package sources, dependency scanning, lock files, isolated environments and pipeline controls. A legitimate library can still introduce supply-chain risk.

Bring-your-own and contractor devices

Define whether organisational information can be accessed from unmanaged devices. Where permitted, use separation, access conditions and monitoring appropriate to the data and service.

Operational technology

Vendor support and safety constraints may limit control options. Use strict authorisation, integrity checks, maintenance evidence and tested rollback. Do not apply enterprise desktop tooling without evaluating operational impact.

Integrate change and vulnerability processes

Approval at installation time does not keep software safe. Link installed products to:

• patch and vulnerability management;
• supplier and support lifecycle;
• baseline and configuration management;
• licence and contract review;
• backup and recovery;
• incident monitoring; and
• removal when no longer needed.

The secure development lifecycle guide shows how dependencies and release gates can be controlled before production deployment.

Preserve evidence of design and operation

Design evidence

• scope and software-control rules;
• authorised catalogue and risk criteria;
• approval and exception workflow;
• privileged-access design;
• repository and integrity controls;
• discovery coverage and response rules; and
• ownership for updates, support and removal.

Operating evidence

• representative requests and approvals;
• deployment logs and software inventory;
• privilege-elevation records;
• allowlisting events;
• reconciliation and unauthorised-software investigations;
• temporary exceptions and expiry evidence;
• vulnerability and support actions; and
• verified removals.

Sample across workstations, servers, developers, cloud services and remote users. Compare observed software with approval evidence, not only with a management statement.

Worked control test

An auditor selects a remote administration product discovered on three laptops. One installation was approved for the support team, one belongs to a temporary exception that expired, and one has no record.

A strong response disables the expired and unknown installations, preserves investigation evidence, confirms whether remote sessions occurred, corrects the catalogue and analyses why enforcement allowed the software. The control owner then verifies that the technical restriction works across the affected device group.

Result	Example
Pass	Observed software reconciles to approved need, trusted sources and current support; unauthorised attempts are blocked or promptly investigated.
Partial	Approval and inventory operate, but browser extensions, portable tools or contractor devices are outside discovery.
Fail	Users have uncontrolled installation rights, no reliable inventory exists or known unauthorised software remains without action.

The Annex A control lookup can help teams explore related controls, but it does not replace licensed requirements or a risk-based control design.

Common questions

Must all software be installed by IT?

Not necessarily. The organisation may delegate installation where approval, competence, privilege, source, recording and monitoring remain controlled.

Is a software inventory enough?

No. Inventory supports visibility. The control also needs authorisation, secure installation, ongoing support, detection and response.

Are software-as-a-service applications included?

They may not be installed on endpoints, but adoption still creates access, data, supplier and integration risk. Manage SaaS through the relevant asset, supplier and access processes.

Control the full software lifecycle

Effective software-installation control begins before deployment and continues through updates, monitoring and removal. Combine a usable approval route with technical enforcement and reconciliation so that the approved software baseline matches the operating environment.