One unauthorized tool on a production server is all it takes to open a backdoor, break a compliance audit, or bring down a system that your customers depend on. When organizations fail to control what software reaches their operational environments, the consequences range from shadow IT sprawl to full-blown security incidents — and auditors notice both.
What 8.19 Requires
ISO 27001 control 8.19 requires your organization to establish and enforce strict procedures governing software installation on operational systems. You need to control who can install software, what software is permitted, and how it reaches production environments. Only authorized, securely configured, and tested software should ever be deployed to systems that support live business operations, as defined in ISO/IEC 27001:2022.
In practice, this means maintaining an approved software list, restricting installation privileges to qualified personnel, and routing every installation through a formal approval and change management process. The control applies broadly — servers, workstations, endpoints, and any system classified as operational within your ISMS scope.
The requirement exists because every piece of unvetted software on a production system expands your attack surface. Uncontrolled installations introduce malware vectors, create licensing liabilities, and make incident response harder by polluting your baseline configuration. If you cannot account for what is running in your environment, you cannot protect it.
Why 8.19 Matters
Organizations that fail to implement software installation controls often discover the consequences through their incident response process rather than their compliance program. In a common pattern, an engineer installs a productivity tool or open-source utility directly onto a production server without going through change management. The tool contains a vulnerable dependency — or worse, a supply chain compromise — and within weeks, attackers have a foothold in the environment that nobody knew existed.
The damage compounds because uncontrolled software creates blind spots. Your vulnerability scanner cannot patch what your asset inventory does not track. Your SIEM cannot alert on behavior patterns for applications it does not know are running. Shadow IT turns your carefully managed environment into a patchwork of unknown risk, and the gap between what you think is running and what is actually running widens with every unmanaged installation.
The risk class here is integrity and availability of operational systems. A compromised production environment can disrupt services, expose sensitive data, and invalidate your entire ISMS posture during an audit. This is not a theoretical concern — it is one of the most common paths from a minor policy gap to a material security incident.
What attackers exploit
- Unrestricted local admin rights — users who can install anything become the easiest initial access vector for social engineering and malware delivery
- No approved software list — without a whitelist, anything can run on production systems, including remote access tools, cryptominers, and backdoors
- Missing integrity verification — software installed without checksum or digital signature validation may have been tampered with in transit or at the source
- Unmonitored software changes — installations and updates that bypass change management leave no audit trail for forensic investigation
- End-of-life software in production — unmaintained applications accumulate known vulnerabilities that attackers actively scan for
- Unvetted third-party tools — supply chain compromises increasingly target popular open-source libraries and developer utilities that enter environments through casual installation
How to Implement 8.19
Effective implementation requires both procedural and technical controls. The procedural layer defines the rules; the technical layer enforces them so you are not relying on people to remember the policy.
For your organization (first-party)
1. Define a software installation policy. Document who has authority to install software, on which systems, and under what conditions. Distinguish between servers, user endpoints, and development environments — each needs different rules. Make installation privileges the exception, not the default.
2. Maintain an Approved Software List (ASL). Create and regularly review a register of authorized software. Include product name, version, vendor, business justification, and the system types where it is permitted. Anything not on the list requires a formal request before installation. For a broader view of what you need, see our implementation checklist.
3. Remove local admin rights. This is the single most effective technical control for endpoints. Use endpoint management platforms (categories like Microsoft Intune, Jamf, or SCCM) to enforce standard user permissions. Where elevated privileges are required, implement just-in-time access that auto-revokes after a defined period.
4. Implement approval workflows. Every new software installation should go through a lightweight request-and-approve process. For standard endpoints, this can be automated through a self-service catalog. For production servers, require security review and change management sign-off.
5. Test before deploying to production. Install and validate software in a non-production environment first. Check functionality, security configuration, network behavior, and compatibility with existing systems. Define a rollback plan before the change window opens.
6. Maintain a software inventory. Track what is installed across your estate using software asset management tooling. Reconcile the inventory against your ASL periodically to catch drift. This inventory also feeds your vulnerability management and patch management processes.
7. Monitor for unauthorized installations. Deploy endpoint detection and response (EDR) or SIEM rules that flag new software installations outside your managed deployment channels. Treat unauthorized installations as security events that require investigation.
8. Integrate with change management. Software installation on operational systems is a change. Link your installation process to your change management workflow so every deployment has a ticket, an approval, and a record.
Common mistakes:
- Granting local admin rights “temporarily” during onboarding and never revoking them
- Maintaining an approved software list on paper but never enforcing it technically
- Skipping testing for “minor” updates or patches that later break production services
- Ignoring browser extensions, plugins, and SaaS applications as out of scope
- Failing to include cloud infrastructure and container images in your software installation controls
For your vendors (third-party assessment)
Understanding your third-party risk requirements is essential before assessing vendors against 8.19. Your security questionnaire should cover these areas:
- Do you maintain a formal approved software list for production systems?
- How are software installation privileges managed and restricted?
- What approval process is required before software is deployed to production?
- How do you verify the integrity and authenticity of software before installation?
- What testing occurs in non-production environments before live deployment?
Evidence to request: Software installation policy, endpoint configuration baselines showing restricted privileges, sample change management records for recent software deployments, and the current approved software list.
Red flags in vendor responses:
- No formal approval process — software is installed at individual discretion
- All users or most users have administrator rights on their systems
- No maintained software inventory or approved software list
- Software installation is not integrated with change management
- No distinction between production and non-production deployment processes
To verify beyond self-attestation, request screenshots from endpoint management consoles showing privilege restrictions, sample change tickets with approval chains for recent software deployments, and evidence of periodic reconciliation between installed software and the approved list. You can use our vendor questionnaire template to structure these requests.
Audit Evidence for 8.19
| Evidence Type | Example Artifact |
|---|---|
| Policy documentation | Software Installation Policy defining authorized installers, approval workflows, and scope of operational systems |
| Approved Software List | Current ASL register with product names, versions, vendors, approval dates, and permitted system types |
| Privilege restriction | Endpoint management console export showing standard user (non-admin) configuration across endpoints |
| Change records | Change management tickets for recent software installations with request, approval, testing, and deployment steps documented |
| Software inventory | Automated software asset inventory report reconciled against the ASL within the last review period |
| Monitoring evidence | SIEM or EDR alert rules configured to detect unauthorized software installations, with sample alert logs |
| Testing records | Evidence of pre-production testing for recent software deployments, including test plans and results |
| Periodic review | Minutes or records from the most recent ASL review meeting, including additions, removals, and justifications |
For a complete walkthrough on gathering this evidence, see how to prepare for an audit.
Cross-Framework Mapping
| Framework | Equivalent Control(s) | Coverage |
|---|---|---|
| NIST 800-53 | CM-05 (Access Restrictions for Change) | Full |
| NIST 800-53 | CM-07 (Least Functionality) | Full |
| NIST 800-53 | CM-07(04) (Unauthorized Software / Blocklisting) | Full |
| NIST 800-53 | CM-07(05) (Authorized Software / Allowlisting) | Full |
| NIST 800-53 | CM-11 (User-Installed Software) | Full |
| SOC 2 TSC | CC8.1 (Change Management) | Partial |
| CIS Controls v8.1 | CIS Control 2 (Inventory and Control of Software Assets) | Full |
| NIST CSF 2.0 | PR.IP (Information Protection Processes and Procedures) | Partial |
| DORA (EU) | Article 9 (ICT Risk Management Framework) | Partial |
The NIST SP 800-53 Rev. 5 mappings above come from the official OLIR crosswalk maintained by NIST. The CM family controls collectively address configuration management, least functionality, and user-installed software — the same territory that 8.19 covers from the ISO perspective. For more on how these frameworks intersect, see our ISO 27001 compliance hub. SOC 2, CIS, and DORA mappings reflect partial overlap where the frameworks address software control as part of broader change management or risk management requirements.
Related ISO 27001 Controls
| Control ID | Control Name | Relationship |
|---|---|---|
| 8.8 | Management of technical vulnerabilities | Vulnerability scanning and patching depend on knowing what software is installed — 8.19 provides the inventory foundation |
| 8.9 | Configuration management | Baseline configurations define the expected software state; 8.19 enforces how that state changes |
| 8.7 | Protection against malware | Anti-malware controls complement 8.19 by detecting threats that bypass installation controls |
| 8.18 | Use of privileged utility programs | Restricting privileged tools prevents bypassing software installation controls |
| 8.32 | Change management | Software installation is a change — 8.32 provides the process framework that 8.19 implementations feed into |
| 5.9 | Inventory of information and other associated assets | Software inventory under 8.19 is a subset of the broader asset inventory required by 5.9 |
| 5.15 | Access control | Access control policies determine who has installation privileges on operational systems |
| 5.18 | Access rights | Privilege assignment and review directly governs who can perform software installations |
| 8.20 | Networks security | Network controls can restrict software download sources and enforce repository allowlists |
Frequently Asked Questions
What is ISO 27001 8.19?
ISO 27001 control 8.19 requires organizations to implement strict procedures for managing software installation on operational systems, ensuring only authorized, tested, and securely configured software reaches production environments. It is a preventive control in Annex A Domain 8 designed to protect the integrity and availability of live systems.
What happens if 8.19 is not implemented?
Without 8.19 controls, organizations face unmanaged shadow IT, expanded attack surfaces, and potential malware introduction through unvetted installations. Auditors will flag the absence as a non-conformity, and the organization loses the ability to maintain a reliable baseline of what is running in production.
How do you audit 8.19?
Auditors verify 8.19 by examining the software installation policy, checking that an approved software list is actively maintained, and confirming that installation privileges are technically restricted. They typically sample recent change records, inspect a random endpoint for unauthorized applications, and review monitoring rules that detect out-of-process installations.
How UpGuard Helps
Monitor vendor compliance with software installation controls across your third-party ecosystem.
UpGuard’s platform continuously assesses your vendors’ security posture, including configuration management and software control practices that map directly to ISO 27001 8.19 requirements. Instead of relying on point-in-time questionnaires, you get ongoing visibility into whether your vendors maintain the controls that protect their — and your — operational environments.