Implementing ISO 27001 Annex A 8.19 involves establishing strict governance over the installation of software on operational systems to maintain system integrity. This control mandates the use of approved software repositories, removal of local administrative rights, and immutable infrastructure patterns for updates. The primary business benefit is preventing unauthorized changes, malware introduction, and configuration drift in production environments.
ISO 27001 Annex A Installation of software on operational systems Implementation Checklist
Use this implementation checklist to achieve compliance with ISO 27001 Annex A 8.19. This control mandates that strict procedures are governed to control the installation of software on operational systems to prevent unauthorised changes and vulnerability introduction.
1. Establish a Formal ‘Approved Software’ Repository
Control Requirement: Only authorised and tested software must be installed on operational systems.
Required Implementation Step: Create an internal package repository (e.g., Artifactory, internal Apt/Yum mirror) containing only vetted versions of required libraries and binaries. Configure all production servers to pull updates exclusively from this internal source, blocking direct internet access to public repositories like Docker Hub or NPM.
Minimum Requirement: Production servers cannot reach public software repositories directly.
2. Remove Local Administrative Rights
Control Requirement: Users should not have the privileges to install arbitrary software.
Required Implementation Step: Audit all user accounts on operational systems and revoke `sudo` or Local Admin access for standard users and developers. Implement a Privileged Access Management (PAM) solution (or simple `sudoers` file restrictions) that strictly limits installation commands to specific system administrators.
Minimum Requirement: Developers cannot execute `apt-get install` or `msiexec` on production servers.
3. Enforce Application Whitelisting
Control Requirement: The execution of unauthorised software must be technically prevented.
Required Implementation Step: Configure Windows AppLocker, WDAC, or Linux fapolicyd to block the execution of any binary or script that does not originate from a trusted path or possess a valid corporate digital signature. Set the policy to “Audit” initially, then move to “Enforce”.
Minimum Requirement: An unknown `.exe` or binary copied to the server fails to launch.
4. Segregate Development and Production Libraries
Control Requirement: Operational systems must not contain compilers or development tools.
Required Implementation Step: Strip production images of all build tools (GCC, Make, Maven) and debugging utilities. Ensure that the software deployed is the compiled binary/artifact only, not the source code requiring local compilation.
Minimum Requirement: Typing `gcc –version` on a production server returns “Command not found”.
5. Implement Mandatory Staging Verification
Control Requirement: Software must be tested in a mirror environment before production installation.
Required Implementation Step: Enforce a strict release pipeline where software updates are automatically deployed to a Staging environment first. Require a “burn-in” period or automated regression test pass confirmation before the release pipeline permits promotion to Production.
Minimum Requirement: Evidence exists that the exact binary version running in Prod was first run in Staging.
6. Define Rollback Procedures
Control Requirement: Unsuccessful installations must be reversible to maintain availability.
Required Implementation Step: Script a rollback action for every deployment (e.g., `kubectl rollout undo` or swapping symbolic links to the previous build directory). Verify that the rollback mechanism works before approving the change ticket.
Minimum Requirement: A tested command or script to revert the installation exists before deployment starts.
7. Verify Package Integrity
Control Requirement: The authenticity of the software must be verified to prevent supply chain attacks.
Required Implementation Step: Configure installation scripts to verify GPG signatures or SHA-256 checksums of all packages against the vendor’s official publication before installation. Fail the pipeline immediately if a hash mismatch occurs.
Minimum Requirement: Installation aborts automatically if the package signature is invalid.
8. Retain Strict Change Logs
Control Requirement: Every software installation must be traceable to an authorised change request.
Required Implementation Step: Ensure your configuration management tool (Ansible, Chef, Puppet) logs every package installation event to a centralised logging server. Correlate these logs with Change Management tickets to identify “shadow IT” installations.
Minimum Requirement: You can identify exactly who authorised the installation of `htop` on Server A.
9. Prohibit ‘Live’ Patching
Control Requirement: Updates should be applied via image replacement, not live patching, where possible (Immutable Infrastructure).
Required Implementation Step: Adopt an immutable infrastructure pattern where software updates are achieved by deploying a new server image (AMI/Container) rather than running update commands on a live server. This ensures consistency and eliminates configuration drift.
Minimum Requirement: Uptime on servers is low (e.g., <30 days) because they are cycled for updates rather than patched live.
10. Conduct Post-Installation Audits
Control Requirement: Verify that the installation did not introduce unintended files or permissions.
Required Implementation Step: Run a File Integrity Monitoring (FIM) scan immediately after installation to verify that only the expected files were modified. Alert the security team if system binaries were altered during the application update.
Minimum Requirement: FIM alerts trigger if an update modifies `/etc/passwd` or system32.
ISO 27001 Annex A 8.19 SaaS / GRC Platform Implementation Failure Checklist
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Approved Software | SaaS tool asks “Do you have an approved software policy?” (Yes/No). | You have a PDF policy, but developers are curling scripts from random GitHub repos directly into production. |
| Access Control | SaaS tool checks “Are admin rights restricted?”. | Technically yes, but the `deploy` service account has root access and its SSH key is shared among 10 developers. |
| Whitelisting | SaaS tool checks for endpoint protection software. | The AV is installed but configured to “Alert Only,” so ransomware executables run freely while generating ignored emails. |
| Testing | SaaS tool verifies a “Staging” environment exists in the asset list. | Staging is just a folder on the Production server, meaning a bad install crashes both environments simultaneously. |
| Rollback | SaaS tool asks “Is there a rollback plan?”. | The plan is “restore from backup,” which takes 14 hours, during which the business is offline. |
| Compilers | SaaS tool ignores installed packages. | Production servers have `gcc` installed, allowing attackers to compile local privilege escalation exploits on the box. |
| Integrity Checks | SaaS tool assumes HTTPS guarantees security. | You download updates over HTTPS, but don’t verify the GPG signature, leaving you vulnerable to mirror compromises. |
DO IT YOURSELF ISO 27001
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
About the author
