What is ISO 27001 Annex A 8.19 – Installation of Software on Operational Systems?
ISO 27001 Annex A 8.19 requires organizations to control the installation of software on operational systems.
The objective is to prevent unauthorized, malicious, vulnerable, or inappropriate software from being installed on systems that support business operations.
Operational systems may include:
- Production servers
- Employee laptops and desktops
- Cloud workloads
- Virtual machines
- Databases
- Application servers
- Network devices
- Security appliances
- Container environments
- Kubernetes clusters
- Production applications
- Mobile devices used for business
- Other systems supporting critical business processes
Software installation should be controlled so that only authorized, approved, and appropriate software is installed.
Simple explanation:
Employees and administrators should not be able to install whatever software they want on business systems. Software installation should be authorized, controlled, and traceable.
Why is Annex A 8.19 Important?
Unauthorized software can introduce significant security and operational risks.
For example, an employee may install:
- An unapproved remote-access tool
- A vulnerable application
- Pirated software
- Malware
- A browser extension that captures information
- An unauthorized VPN
- A cryptocurrency miner
- An outdated library
- A tool that creates an undocumented network connection
- Software that conflicts with security controls
For a startup, uncontrolled software installation can become particularly risky because employees often have broad administrative privileges.
Common risks
| Risk | Example |
|---|---|
| Malware | Employee installs malicious software |
| Vulnerabilities | Outdated software contains known vulnerabilities |
| Unauthorized access | Remote-access software creates a new access path |
| Data leakage | Unapproved application uploads company data |
| Shadow IT | Employees use applications without security review |
| Compliance issues | Software violates licensing requirements |
| Operational disruption | New software breaks an application |
| Configuration drift | Production systems no longer match approved configuration |
| Persistence | Malicious software remains after an incident |
| Supply-chain risk | Software contains compromised components |
Simple principle:
If software can change the security or behavior of a system, its installation should be controlled.
What Does ISO 27001 Annex A 8.19 Require?
The organization should establish controls for the installation of software on operational systems.
This does not necessarily mean that every software installation must require a long approval process.
The organization should determine an appropriate level of control based on:
- Information security risk
- System criticality
- Software type
- User privileges
- Production environment
- Business requirements
- Vulnerability risk
- Licensing requirements
- Regulatory requirements
- Supplier risk
- Change-management requirements
A startup with 15 employees may use a lightweight approval process.
A bank or highly regulated organization may require much stronger controls.
The objective is not bureaucracy.
The objective is preventing uncontrolled software from creating security or operational risk.
What Counts as Software?
Software is broader than traditional desktop applications.
Depending on the organization’s environment, it may include:
End-user software
- Microsoft Office
- Browsers
- PDF applications
- Collaboration tools
- VPN clients
- Messaging applications
- Remote-access software
Server software
- Web servers
- Database software
- Monitoring agents
- Security agents
- Backup agents
- Application runtimes
Cloud software
- Cloud agents
- Serverless packages
- Marketplace applications
- Cloud extensions
- Security tools
Development software
- IDEs
- SDKs
- Compilers
- Package managers
- Development frameworks
- Container images
- CI/CD tools
Scripts and utilities
- PowerShell scripts
- Shell scripts
- Administrative utilities
- Database tools
- Network utilities
- Automation tools
Browser extensions
Browser extensions are often overlooked but can:
- Read web pages
- Access cookies
- Capture information
- Modify websites
- Communicate with external services
Therefore, organizations should consider whether browser extensions need to be controlled.
What is an Operational System?
An operational system is a system used to support actual business operations.
Examples include:
- Production application servers
- Production databases
- Employee endpoints
- Cloud infrastructure
- Identity systems
- Security systems
- Network infrastructure
- Business applications
A development laptop may also be considered an operational asset if it processes company or customer information.
The organization should define its own scope based on its risk assessment and operating environment.
Activities Required to Implement Annex A 8.19
Step 1: Identify Operational Systems
First identify the systems where software installation needs to be controlled.
Create an inventory such as:
| System | Environment | Owner | Criticality |
|---|---|---|---|
| Customer Application | Production | CTO | Critical |
| PostgreSQL | Production | Engineering | Critical |
| Employee Laptop | Corporate | IT | Medium |
| CI/CD Server | Production | DevOps | High |
| Monitoring Platform | Production | Security | High |
This should connect with your asset inventory under Annex A 5.9.
Step 2: Define Approved Software
Create a list or mechanism for identifying approved software.
For example:
- Approved browsers
- Approved VPN
- Approved endpoint security software
- Approved remote-support tools
- Approved development tools
- Approved database clients
- Approved collaboration tools
- Approved monitoring agents
The approved software list should be maintained as the environment changes.
Step 3: Establish Software Installation Rules
Define who can install software and under what conditions.
For example:
Standard users
Employees cannot install software requiring administrator privileges.
IT administrators
IT personnel may install approved software following the organization’s process.
Developers
Developers may install approved development tools on development systems but cannot freely install software on production systems.
Production administrators
Production software installation requires authorization and change control.
Step 4: Restrict Administrative Privileges
One of the most effective controls is preventing unnecessary administrator access.
For example:
Weak model
Every developer has local administrator rights.
Stronger model
Developers use standard accounts for normal work and receive controlled administrative access when technically required.
This reduces the ability to install unauthorized software.
This control also works together with:
- A.8.2 Privileged Access Rights
- A.8.5 Secure Authentication
- A.8.18 Use of Privileged Utility Programs
Step 5: Use Software Installation Controls
Depending on the environment, organizations may use:
- Endpoint management
- Mobile device management
- Application allowlisting
- Software restriction policies
- Package repositories
- Configuration management
- Privileged access management
- Application control
- Cloud policies
- Container image controls
The technology should match the organization’s risk.
A small startup does not necessarily need an expensive application-control platform.
Step 6: Control Production Software Installation
Production systems should have stronger controls than ordinary employee systems.
A typical process could be:
Business/Technical Need
↓
Software identified
↓
Security review
↓
Compatibility review
↓
Approval
↓
Change request
↓
Testing
↓
Production installation
↓
Validation
↓
Documentation
This reduces the possibility of introducing an insecure or unstable application into production.
Step 7: Verify Software Source
Software should come from trusted sources.
Examples include:
- Official vendor websites
- Approved package repositories
- Enterprise software repositories
- Trusted cloud marketplaces
- Approved internal repositories
Avoid installing software obtained from:
- Unknown websites
- Unverified file-sharing sites
- Pirated sources
- Untrusted repositories
- Unknown USB devices
- Random internet downloads
Step 8: Check Software Security
Before installing software on important systems, consider:
- Vendor reputation
- Version
- Known vulnerabilities
- Security advisories
- Required permissions
- Network connections
- Data access
- Authentication requirements
- Privacy implications
- Licensing
- Compatibility
- Support lifecycle
For high-risk software, a security review may be appropriate.
Step 9: Test Before Production
Where practical, software should be tested before being installed on critical production systems.
For example:
Development
→
Test/Staging
→
Security/Technical validation
→
Production
This is especially important for:
- Operating system updates
- Database software
- Security agents
- Monitoring tools
- Application runtimes
- Network software
- Major application upgrades
Step 10: Maintain Installation Records
The organization should be able to determine:
- What software was installed
- Where it was installed
- Who installed it
- When it was installed
- Why it was installed
- Which version was installed
- Who approved it
Depending on the environment, these records may come from:
- Endpoint management
- Configuration management
- Change-management systems
- Cloud management tools
- Package-management systems
- Software inventory tools
- Ticketing systems
- CI/CD systems
Startup Example
Imagine a 50-person SaaS company.
The company has:
- AWS production infrastructure
- PostgreSQL
- GitHub
- CI/CD
- Employee laptops
- Customer support team
- Remote employees
Weak approach
Developers have administrator privileges.
Anyone can install:
- Remote-access tools
- Database clients
- Browser extensions
- VPN software
- Development utilities
- Unapproved applications
There is no software inventory.
There is no installation approval process.
Better approach
The company establishes:
- Standard employee accounts
- Controlled administrator privileges
- Approved software list
- Production change management
- Endpoint software inventory
- Developer software rules
- Security review for high-risk software
- Logging of privileged activity
- Removal process for unauthorized software
The flow becomes:
Need software
→
Check approved list
→
Request/authorize
→
Security review if required
→
Install
→
Verify
→
Record
Startup-Focused Quick Summary
For a startup, Annex A 8.19 can often be implemented without creating a complicated IT bureaucracy.
Minimum practical approach
- Maintain a software inventory.
- Define approved software.
- Restrict administrator privileges.
- Prevent unauthorized production changes.
- Use trusted software sources.
- Review high-risk software.
- Test important software before production.
- Record significant installations.
- Remove unauthorized or unnecessary software.
- Periodically review installed software.
Startup principle:
Control the software that can affect your security, production environment, or sensitive information.
Example Software Approval Register
| Software | System | Business Need | Risk | Approved By | Status |
|---|---|---|---|---|---|
| VS Code | Developer Laptop | Development | Low | Engineering | Approved |
| PostgreSQL Client | Developer Laptop | DB Administration | Medium | Engineering | Approved |
| Remote Admin Tool | Employee Laptop | IT Support | High | IT/Security | Approved |
| Browser Extension X | Employee Laptop | Productivity | Medium | Security | Review Required |
| New Monitoring Agent | Production | Monitoring | High | CTO/Security | Approved |
Software Installation Risk Assessment
Not every software package requires the same level of review.
| Software Type | Typical Risk | Control Level |
|---|---|---|
| Standard office application | Low | Basic approval |
| Developer tool | Low–Medium | Approved list |
| Browser extension | Medium | Review |
| Remote-access software | High | Security approval |
| Database administration tool | High | Restricted access |
| Production security agent | High | Change management |
| Unknown/untrusted software | Very High | Prohibit/reject |
The actual classification should be determined by the organization’s risk assessment.
Software Installation in Production
Production systems should generally have tighter controls than employee endpoints.
A production installation may require:
- Change ticket
- Business justification
- Technical owner
- Security assessment
- Version identification
- Testing evidence
- Rollback plan
- Approval
- Installation record
- Post-installation verification
For example:
Change: Install new endpoint security agent on production servers
Reason: Security monitoring requirement
Testing: Completed in staging
Approval: CTO / Security
Installation: DevOps
Validation: Security monitoring confirmed
Rollback: Previous agent configuration retained
Emergency Software Installation
Sometimes software needs to be installed urgently.
For example:
- Security vulnerability requires emergency remediation.
- Incident response requires forensic tooling.
- Critical production failure requires a vendor utility.
- Security agent needs emergency deployment.
Organizations should have an emergency process rather than allowing uncontrolled installation.
A practical emergency process:
Emergency identified
→
Authorized person approves
→
Software/source verified
→
Installation performed
→
Activity logged
→
Post-installation review
→
Remove software if temporary
Third-Party Software Installation
External vendors may sometimes need to install software or agents.
Examples:
- Remote-support agents
- Monitoring agents
- Backup agents
- Security tools
- Database tools
- Vendor-specific software
The organization should consider:
- Vendor authorization
- Business justification
- Security review
- Access scope
- Installation duration
- Privileged access
- Logging
- Removal requirements
A vendor should not be allowed to install persistent software simply because they have technical access.
Cloud Environment Considerations
Modern startups often do not install traditional software manually on servers.
Software may be introduced through:
- Infrastructure as Code
- Container images
- CI/CD pipelines
- Package managers
- Cloud marketplace applications
- Serverless packages
- Machine images
- Kubernetes manifests
- Automated deployment tools
Therefore, Annex A 8.19 should also be considered within the organization’s DevOps and cloud deployment process.
For example:
Developer commits dependency
→
CI pipeline scans dependency
→
Build created
→
Security checks
→
Staging deployment
→
Approval
→
Production deployment
This is often more effective than trying to manually control every individual package installation.
Container and Kubernetes Considerations
For organizations using containers, software installation may occur through container images and package dependencies.
Controls may include:
- Approved base images
- Trusted registries
- Dependency scanning
- Vulnerability scanning
- Image signing where appropriate
- Version control
- Pull-request review
- CI/CD security checks
- Restricted production deployment
- Removal of outdated images
A developer should not be able to introduce arbitrary production images without appropriate controls.
Software Installation and Change Management
Annex A 8.19 is closely connected with change management.
A significant software installation can represent a change to:
- Security configuration
- System functionality
- Network connectivity
- Data processing
- Authentication
- Monitoring
- Availability
- Compliance posture
Therefore:
Software installation
→ Potential change
→ Risk assessment
→ Testing
→ Authorization
→ Implementation
→ Verification
This is particularly important for production environments.
Unauthorized Software Detection
Organizations should periodically identify software that should not be present.
Possible methods include:
- Endpoint management
- Software inventory scans
- Configuration-management tools
- Cloud inventory
- Vulnerability scanners
- EDR platforms
- Manual reviews
- Configuration baselines
For example:
| Finding | Action |
|---|---|
| Approved software | Retain |
| Outdated software | Update |
| Unauthorized software | Investigate/remove |
| Unknown software | Investigate |
| Vulnerable software | Remediate |
| Unused software | Remove |
What Happens When Unauthorized Software Is Found?
A documented response should exist.
Example:
- Identify software.
- Identify system and user.
- Determine why it was installed.
- Assess security risk.
- Check whether software is required.
- Remove or approve as appropriate.
- Investigate potential compromise if necessary.
- Document the decision.
- Update controls if the issue reveals a weakness.
Unauthorized software does not automatically mean that an employee committed misconduct.
The organization should first determine the circumstances and security risk.
Audit Evidence for Annex A 8.19
An auditor may request evidence such as:
Policies
- Software Installation Policy
- Acceptable Use Policy
- Change Management Policy
- Endpoint Security Policy
Procedures
- Software installation procedure
- Production deployment procedure
- Emergency change procedure
- Unauthorized software handling procedure
Records
- Software inventory
- Approved software list
- Installation requests
- Change tickets
- Approval records
- Deployment records
- Endpoint reports
- Vulnerability scan results
Technical Evidence
- Endpoint management screenshots
- Application control configuration
- Software inventory reports
- EDR reports
- Configuration management reports
- CI/CD controls
- Cloud deployment records
Annex A 8.19 Audit Checklist
| Audit Question | Evidence |
|---|---|
| Is software installation controlled? | Policy/procedure |
| Is approved software defined? | Approved software list |
| Can users freely install software? | Endpoint configuration |
| Are administrator privileges restricted? | IAM/endpoint evidence |
| Is production software installation controlled? | Change tickets |
| Are software sources trusted? | Repository/configuration evidence |
| Are high-risk applications reviewed? | Security review |
| Is installed software inventoried? | Software inventory |
| Are unauthorized applications detected? | Endpoint/EDR reports |
| Are vulnerabilities considered? | Vulnerability reports |
| Are emergency installations controlled? | Emergency change records |
| Are temporary tools removed? | Removal evidence |
| Are software installations traceable? | Logs/tickets |
Common Mistakes
1. Allowing Everyone to Have Administrator Rights
This makes software installation difficult to control.
Better: Use standard accounts and controlled elevation.
2. Maintaining a Policy but No Technical Control
Having a statement saying:
“Employees must not install unauthorized software.”
is not enough if everyone has unrestricted administrator access.
Better: Combine policy with technical and operational controls.
3. Ignoring Developer Environments
Developers often install large numbers of packages and tools.
The organization should distinguish between:
- Development
- Testing
- Production
Different levels of control may be appropriate.
4. Ignoring Browser Extensions
Browser extensions can have significant access to browser data.
Treat high-risk extensions as software requiring appropriate review.
5. Ignoring Cloud and Containers
Modern software installation often happens through:
- Docker images
- Kubernetes
- CI/CD
- Infrastructure as Code
- Package managers
These should be included in the organization’s control model.
6. No Software Inventory
If you do not know what is installed, it is difficult to identify:
- Vulnerable software
- Unauthorized software
- Unsupported software
- Unnecessary software
7. No Emergency Process
Blocking all emergency changes can create operational problems.
Instead, define an emergency process with authorization and retrospective review.
8. Installing Temporary Tools and Forgetting Them
Incident-response or troubleshooting tools may be installed temporarily.
After the activity:
Use → Document → Remove if no longer required → Verify
Practical Startup Implementation Model
A startup can implement Annex A 8.19 using the following lifecycle:
1. Identify
What software exists?
2. Classify
Which software is low, medium, or high risk?
3. Approve
Which software is permitted?
4. Restrict
Who can install software?
5. Verify
Is the software from a trusted source?
6. Test
Does important software need testing before production?
7. Deploy
Install using controlled processes.
8. Record
Maintain appropriate installation and change records.
9. Monitor
Identify unauthorized or vulnerable software.
10. Remove
Remove unnecessary, unauthorized, or unsupported software.
Simple implementation formula:
Identify → Approve → Restrict → Verify → Test → Install → Record → Monitor → Remove
Minimum Viable Implementation for a Startup
A small startup does not need to purchase multiple expensive tools just to satisfy Annex A 8.19.
A practical starting point is:
Governance
- Software Installation Policy
- Approved Software List
- Production Change Management Procedure
Access
- Standard employee accounts
- Restricted administrator access
- Separate privileged accounts where appropriate
Technology
- Endpoint management
- Software inventory
- Vulnerability scanning
- Controlled production deployment
Development
- Approved package repositories
- Dependency scanning
- Code review
- CI/CD controls
Monitoring
- Unauthorized software detection
- Vulnerability management
- Periodic software review
Evidence
- Software inventory
- Change records
- Approval records
- Security review records
Policy vs. Process vs. Evidence
| Layer | Example |
|---|---|
| Policy | Unauthorized software installation is prohibited |
| Process | Software must be approved before installation |
| Technical Control | Users do not have unrestricted administrator rights |
| Evidence | Software inventory and installation records |
| Monitoring | Unauthorized software is periodically identified |
| Review | Software inventory and exceptions are reviewed |
A mature implementation uses all of these layers.
Relationship With Other ISO 27001 Controls
Annex A 8.19 should not be implemented in isolation.
| Control | Relationship |
|---|---|
| A.5.9 | Inventory of information and associated assets |
| A.5.10 | Acceptable use of assets |
| A.5.15 | Access control |
| A.5.18 | Access rights |
| A.8.1 | User endpoint devices |
| A.8.2 | Privileged access rights |
| A.8.5 | Secure authentication |
| A.8.8 | Management of technical vulnerabilities |
| A.8.9 | Configuration management |
| A.8.15 | Logging |
| A.8.16 | Monitoring activities |
| A.8.18 | Privileged utility programs |
| A.8.25 | Secure development life cycle |
| A.8.31 | Separation of development, test and production environments |
| A.8.32 | Change management |
Particularly important relationship
A.8.19 + A.8.8 + A.8.9 + A.8.32
Together these help an organization control:
What software is installed → how it is configured → whether it is vulnerable → how changes are authorized.
Useful Documents for Annex A 8.19
A startup can create the following supporting documents:
- Software Installation and Application Control Policy
[Insert Draft Document Link] - Approved Software Register
[Insert Draft Document Link] - Software Installation Request Form
[Insert Draft Document Link] - Production Software Installation Procedure
[Insert Draft Document Link] - Emergency Software Installation Procedure
[Insert Draft Document Link] - Software Inventory Register
[Insert Draft Document Link] - Unauthorized Software Investigation Form
[Insert Draft Document Link] - Software Security Review Checklist
[Insert Draft Document Link]
Questions an Auditor May Ask
An auditor may ask:
About policy
- Do you have rules governing software installation?
- Who is authorized to install software?
- How are production installations controlled?
About employees
- Can normal users install applications?
- Do employees have local administrator privileges?
- How are unauthorized applications detected?
About production
- How do you install software on production systems?
- Is a change request required?
- How do you test software before production?
About security
- How do you check software for vulnerabilities?
- How do you verify software sources?
- How do you handle unsupported software?
About developers
- How are third-party packages controlled?
- How are dependencies reviewed?
- How are container images controlled?
About exceptions
- What happens during an emergency?
- How are temporary tools removed?
- How are exceptions documented?
Example Auditor Walkthrough
A practical auditor test could look like this:
Auditor selects a production server
↓
Checks installed software
↓
Selects several applications
↓
Checks whether they are approved
↓
Checks software versions
↓
Checks vulnerabilities
↓
Checks installation/change record
↓
Checks who performed the installation
↓
Checks whether appropriate authorization existed
This provides much stronger evidence than simply showing a policy.
Startup-Focused Final Takeaway
ISO 27001 Annex A 8.19 is about controlling what software is allowed to enter your operational environment.
You do not necessarily need a complex enterprise application-control platform.
A startup can establish a strong foundation by answering seven simple questions:
- What software do we have?
- What software is approved?
- Who can install it?
- Where can it be installed?
- How do we check it before installation?
- How do we detect unauthorized or vulnerable software?
- How do we remove software that is no longer required?
The practical lifecycle is:
Identify → Approve → Restrict → Verify → Test → Install → Record → Monitor → Remove
For a startup, the objective is not to prevent employees and engineers from using useful software.
The objective is to ensure that software capable of affecting business systems, security, customer information, or production operations is introduced in a controlled and traceable manner.
In one sentence:
Annex A 8.19 ensures that software installed on operational systems is authorized, appropriate, secure, and controlled.
MAE Practical Guidance
For startups preparing for ISO 27001 or SOC 2, Annex A 8.19 should be connected to your broader:
- Asset Management
- Access Control
- Endpoint Security
- Vulnerability Management
- Configuration Management
- Secure SDLC
- Change Management
- Cloud Security
- DevOps Security
A well-designed process should make the control part of normal IT and engineering operations, rather than creating a separate compliance exercise.