Keeping Your Live Environment Under Control
ISO 27001 Control 8.19 Installation of software on operational systems is about one simple idea:
Nothing gets installed – or updated – on live systems unless it’s authorised, tested, and controlled.
Uncontrolled software installs are a gift to attackers and a headache for operations: they introduce vulnerabilities, break production services, and make incidents harder to investigate. This control makes sure your production environment only runs software you actually trust and understand.
It links tightly to:
- Change management
- Asset and configuration management
- Vulnerability and patch management
- Endpoint security and insider threat reduction
Done well, 8.19 gives you a clean, predictable, supportable estate instead of a wild mix of “whatever people happened to install”.
What ISO 27001 Control 8.19 Actually Expects
In plain English, ISO 27001 Control 8.19 – Installation of software on operational systems expects you to:
- Control who can install software and where
- Only allow authorised, approved software onto operational systems
- Make sure software is tested, validated and change-controlled before it hits live
- Maintain visibility of what’s installed, where, and why
- Keep software patched and supported, and remove what’s no longer needed
- Detect and respond to unauthorised installations
The goal is not to block change – it’s to ensure changes are deliberate, traceable, and reversible.
Step 1 – Define a Clear Software Installation Policy
Start by writing down the rules. This doesn’t need to be long, but it does need to be clear.
Your software installation policy/standard should cover:
- Who can install software
- Typically: IT operations, endpoint management team, DevOps/engineering on specific platforms.
- Ordinary users should not have local admin rights on operational systems unless there is a strong, documented reason.
- Where software can be installed
- Distinguish between: servers, user endpoints, test environments, CI/CD pipelines, and production.
- What types of software are allowed
- Approved categories (e.g. business apps, dev tools, security tools)
- Prohibited categories (e.g. unauthorised remote access tools, consumer cloud sync tools, torrent clients).
- Baseline builds and images
- Standard images for servers and workstations with approved software and configurations.
- Any deviations treated as controlled changes.
- Change management link
- Make it explicit: installing/upgrading/removing software on operational systems is a change and must follow your change process (CAB, tickets, approvals, rollback plans where appropriate).
That policy is your anchor – everything else hangs off it.
Step 2 – Put Approval and Authorisation in Front of Every Install
Before anything new reaches an operational system, there should be a short but clear chain of thought:
“Do we really need this? Is it safe? Is it from a trusted source?”
For ISO 27001 Control 8.19, I recommend:
- Formal approval for new software
- New products or tools should go through a lightweight review: business justification, security considerations, licensing, support model.
- Risk assessment for higher-impact software
- For things that run on critical infrastructure or touch sensitive data, do a brief risk review:
- What access will it need?
- What data will it process?
- What happens if it fails or is compromised?
- For things that run on critical infrastructure or touch sensitive data, do a brief risk review:
- Check the origin and integrity
- Only obtain software from trusted vendors, official repositories or signed packages.
- Verify digital signatures or checksums for installers where available.
- Role-based install rights
- Use role-based access control so only the right people, on the right systems, can perform installations.
- Treat local admin rights on endpoints and root/admin on servers as exceptional and review them regularly.
For especially sensitive environments, you can require multi-step approval (e.g. system owner + security + ops) for high-risk software changes.
Step 3 – Test Before You Touch Production
Even “minor” changes can break production if you skip testing.
For ISO 27001 Control 8.19, you should:
- Use non-production environments
- Test new software and major updates in dev/test/UAT before deployment to live.
- For infrastructure tools, use lab environments or virtual clones if possible.
- Check both functionality and security
- Does it work as expected?
- Does it open unexpected ports, weaken configurations, or require unsafe permissions?
- Are default accounts disabled or changed? Are default settings hardened?
- Consider regressions and compatibility
- Test key integrations and dependencies (databases, APIs, agents, drivers).
- Make sure patches don’t break existing applications.
- Have a rollback plan
- For impactful changes, define how you’ll back out quickly if something goes wrong (previous version, snapshots, backups, blue–green deployments, etc.).
- Use phased rollout where sensible
- Start with a small group (pilot) and expand if everything looks stable.
- This reduces the blast radius if there’s a problem.
The key is: no direct path from vendor download to production.
Step 4 – Maintain Version Control and Documentation
You can’t manage what you don’t know you have.
To support ISO 27001 Control 8.19:
- Maintain a software inventory
- At minimum: product name, version, vendor, where it is installed, owner, and purpose.
- Use software asset management or endpoint management tools where you can.
- Record changes
- Log all installations, upgrades and removals in your ITSM or change tool.
- Include dates, systems affected, versions, and who carried out the work.
- Keep configuration under control
- Store configuration files and deployment scripts in version control (e.g. Git).
- Treat config changes like code changes – peer review, change records, rollback options.
- Archive old versions where needed
- Keep previous versions for rollback and forensics (securely stored, access controlled).
- Label them clearly as deprecated to prevent accidental reuse.
This gives you traceability: what changed, when, where, and why.
Step 5 – Manage Third-Party and Open-Source Software Properly
Most environments are a stack of vendor products and open-source components. ISO 27001 Control 8.19 wants those under control too.
Good practice:
- Know your dependencies
- Track third-party libraries, plug-ins, and modules used by your applications.
- Use software composition analysis tools where appropriate.
- Check support and maintenance
- Avoid unmaintained or end-of-life products and libraries.
- Ensure vendors have a security patch process and track advisories.
- Assess open-source software
- Prefer well-maintained projects with active communities and clear governance.
- Pay attention to licensing as well as security.
- Scan for vulnerabilities
- Use vulnerability scanners and dependency-check tools to identify known issues in third-party components.
- Feed results into your patch and upgrade plan.
- Control third-party integrations
- Be cautious with SDKs, browser plug-ins and extensions, and client-side components.
- Review required permissions and data access carefully.
Open-source and third-party software are fine – as long as you treat them as first-class assets, not “just stuff we pulled from the internet”.
Step 6 – Lock Down User Installation Rights
Unmanaged installs by users are a fast route to malware, data leakage and instability.
For ISO 27001 Control 8.19 you should:
- Apply least privilege
- Normal users do not need local admin on their workstations in most cases.
- Exceptions should be justified, documented and reviewed regularly.
- Define allowed vs prohibited software
- Maintain a list of approved applications (by category or specific product).
- Explicitly block or remove risky or unnecessary software.
- Use application control
- Whitelisting / allow-listing where possible: only approved executables can run.
- At minimum, block known-unwanted software categories and unsigned/untrusted installers.
- Monitor installation attempts
- Log and alert on attempts to bypass controls (e.g. portable apps, unauthorised installers).
- Treat repeated attempts as a potential policy or training issue.
- Train users
- Explain why install rights are restricted, and the risks of “just adding my own tools”.
- Make it easy for them to request new software legitimately (clear request and approval route).
The aim is to channel people into a safe, supported way of getting what they need – not just saying “no”.
Step 7 – Integrate Patch Management and Software Updates
Control 8.19 also covers updates – they are effectively reinstallation or change to existing software.
You should:
- Have a defined patching schedule
- Different cadences for critical vs non-critical systems (e.g. monthly for most, faster for high-risk or internet-facing systems).
- Emergency patch route for serious vulnerabilities.
- Prioritise based on risk
- Use vulnerability severity, exploit availability, and asset criticality to prioritise.
- You don’t have to patch everything immediately – but you do need a rationale.
- Automate where sensible
- Use central tools for OS and application patching on endpoints and servers.
- Still ensure major updates go through basic testing.
- Retire end-of-life software
- Plan removal of unsupported products – they’re difficult to defend and often non-compliant.
- Replace or isolate them if removal isn’t immediately possible.
- Verify after patching
- Spot-check: did systems update successfully, and are key applications still working?
- Watch for issues via monitoring and incident reports.
Patch management and software installation should feel like one joined-up process, not two separate worlds.
Step 8 – Monitor and Audit What’s Really Installed
Finally, ISO 27001 Control 8.19 expects you to check reality matches your paperwork.
I recommend:
- Automated inventory scans
- Use endpoint management or asset discovery tools to get an up-to-date list of installed software across your environment.
- Regular audits
- Compare actual installs with your approved software catalogue and baseline images.
- Investigate and clean up anything unexpected or unauthorised.
- Log installation events
- Capture software install/uninstall events on endpoints and servers where possible.
- Feed these into your SIEM or central logging for correlation with other security events.
- Detect and respond to drift
- Set alerts for the appearance of known-unauthorised software or unusual install patterns.
- Use that feedback to improve controls and awareness.
- Periodic risk reviews
- Review your software landscape periodically: are there products that no longer have a clear owner, purpose, or support?
- Reduce your attack surface by trimming what you don’t need.
This closes the loop: you don’t just declare control over software installations – you can demonstrate it.
Quick Implementation Checklist for ISO 27001 Control 8.19
You’re in good shape for ISO 27001 Control 8.19 – Installation of software on operational systems if:
- You have a documented policy/standard covering who can install software, where, and how.
- All installations, updates and removals on operational systems go through a change or approval process.
- New software and major updates are tested in non-production first, with rollback options.
- You maintain a software inventory (what is installed, where, and why) and track versions.
- Users do not have uncontrolled install rights; exceptions are justified and reviewed.
- You use tools (e.g. endpoint management, app control) to enforce and monitor installation rules.
- There is a structured patch management process, aligned with risk and business impact.
- Unauthorised or unexpected software installations are detected, investigated and removed where appropriate.
- Evidence (logs, tickets, approvals, inventories) shows that software installation is controlled in practice, not just in policy.
Bringing It All Together
ISO 27001 Control 8.19 – Installation of software on operational systems – is about turning your environment from:
“We’re not quite sure what’s running where”
into:
“We know what’s installed, why it’s there, who approved it – and we can change or remove it in a controlled way.”
By combining clear rules, proper approvals, sensible testing, tight user permissions, and continuous monitoring, you’ll reduce vulnerabilities, improve stability, and have solid evidence for your ISO 27001 audit – all while making life easier for your operations and security teams.
Explore the ISO 27001 Control Group Purposes