We’ve all been there. You need a quick tool to convert a file or a little plugin to make a task easier, so you just download it and install it. It seems harmless enough, right? But in the world of information security, that casual “click-and-install” culture is a massive vulnerability waiting to happen.
This is exactly where ISO 27001:2022 Annex A 8.19 steps in. It’s the control dedicated to the installation of software on operational systems. Put simply, it’s about making sure that nothing gets onto your live business systems unless it’s supposed to be there, it’s safe, and it’s been approved.
If you are scratching your head about how to implement this without bringing your company’s operations to a grinding halt, you are in the right place. Let’s break down exactly what this control is and how to get it working in the real world.
Table of contents
What is Annex A 8.19?
In the 2022 update of ISO 27001, Control 8.19 sits under the “Technological Controls” category. The standard defines it pretty clearly: procedures and measures need to be implemented to securely manage software installation on operational systems.
Think of it as the gatekeeper for your production environment. Whether it’s a server, a staff laptop, or a cloud instance, you need strict rules about who can install software, what they can install, and how they do it.
The goal isn’t just to stop people from installing games on work computers (though that’s part of it). It’s about preventing:
- Malware infections: Random downloads are a prime vector for viruses.
- Operational disruptions: Incompatible software crashing your critical systems.
- Licensing issues: Accidentally using pirate software or exceeding licence limits.
- Shadow IT: Departments running their own unapproved tech stacks that IT knows nothing about.
Step 1: Define Your Rules (The Policy)
You can’t enforce rules if nobody knows what they are. Your first step is to establish a clear policy or standard regarding software installation. This doesn’t need to be War and Peace, but it must cover the essentials:
- Who is authorised? Typically, this should be restricted to IT administrators or specific roles. Regular users shouldn’t have local admin rights unless absolutely necessary.
- What is allowed? Create an “approved software list” (allow-list). If it’s not on the list, it doesn’t get installed without a new approval.
- Where can it go? Distinguish between your test environments and your live operational systems. What flies in a sandbox might be a disaster in production.
Step 2: The Approval Process
One of the biggest red flags for an auditor is a lack of segregation of duties. If the same person who requests a piece of software can also approve it and install it, you have a gap in your armour.
You need a formal request process. When a user wants a new tool:
- They submit a request with a business justification.
- A designated authority (like the Head of IT or Security Manager) reviews the request.
- They check for security risks, licensing costs, and compatibility.
- Only once approved does the installation proceed.
For smaller organisations, this might feel bureaucratic, but it’s essential. If you need templates or a structured way to document these procedures, resources like Hightable.io offer comprehensive toolkits that can save you reinventing the wheel.
Step 3: Test Before You Deploy
Never, ever install new software directly onto a live operational system without testing it first. This is a golden rule of IT operations.
You should have a staging or test environment that mirrors your production setup. Install the software there first to ensure:
- It works as advertised.
- It doesn’t conflict with existing applications.
- It doesn’t introduce obvious security vulnerabilities.
Only after it passes these checks should it be promoted to your live environment. If an update breaks your test server, you’ll be very glad it didn’t happen on the system your customers are using.
Step 4: Restrict Access (Least Privilege)
This is the technical side of the implementation. You need to ensure that your operating systems are configured to prevent unauthorised installations.
In a Windows environment, for example, this usually means ensuring standard users do not have “Local Administrator” privileges. If a user tries to run an installer file, the system should prompt for admin credentials that they don’t have.
For servers, access should be even tighter. Only a handful of trusted administrators should have the ability to change the software configuration of your production servers.
Step 5: Log and Monitor
Compliance is about evidence. If you installed a piece of software six months ago, can you prove who authorised it and when it was done?
You should maintain an inventory of authorized software and keep logs of installation events. Modern endpoint management tools can help automate this by scanning your network and flagging any “rogue” software that appears on devices but isn’t on your approved list.
DO IT YOURSELF
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
What Will the Auditor Look For?
When the audit day comes, the auditor is going to want to see proof that you are actually doing what you say you are. Be prepared to show:
- Your Policy: A document outlining the rules for software installation.
- The Approved List: A current inventory of software that is authorised for use.
- Change Records: specific examples of software requests, approvals, and subsequent installation logs.
- Evidence of Testing: Records showing that updates or new apps were tested before going live.
Common Pitfalls to Avoid
- The “Emergency” Loophole: Don’t let “urgent business needs” become a constant excuse to bypass the approval process.
- Ignoring Third-Party Libraries: Remember that “software” also includes libraries and dependencies used by your developers, not just exe files.
- Lack of Version Control: It’s not enough to say “Java is allowed”. You need to manage which versions are allowed to avoid older, vulnerable versions remaining in use.
Final Thoughts
Implementing Annex A 8.19 isn’t just about ticking a box for ISO 27001 certification. It’s about stabilising your environment. By controlling what gets installed, you reduce downtime, minimise security risks, and take control of your IT estate.
If you are finding the documentation side of things heavy going, don’t hesitate to look for help. Platforms like Hightable.io provide excellent guidance and templates that can speed up the process significantly, ensuring you have the right policies in place without writing everything from scratch.
About the author
Stuart Barker is a veteran practitioner with over 30 years of experience in systems security and risk management.
Holding an MSc in Software and Systems Security, Stuart combines academic rigor with extensive operational experience. His background includes over a decade leading Data Governance for General Electric (GE) across Europe, as well as founding and exiting a successful cyber security consultancy.
As a qualified ISO 27001 Lead Auditor and Lead Implementer, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. He has successfully guided hundreds of organizations – from high-growth technology startups to enterprise financial institutions – through the audit lifecycle.
His toolkits represents the distillation of that field experience into a standardised framework. They move beyond theoretical compliance, providing a pragmatic, auditor-verified methodology designed to satisfy ISO/IEC 27001:2022 while minimising operational friction.
