For Annex A control 8.19, "Installation of software on operational systems", show that only approved software reaches production and that changes pass a defined path. Deployment approvals, image registry rules, dependency policies and a record of what is running are the artifacts that tell that story.
Reading the title for modern stacks
The title of 8.19 comes from an era of servers installed by hand, but it fits container and serverless teams too. Production is an operational system, and what lands there, including libraries pulled in at build time, is software installed on it. The control carries the same number in the 2022 edition as the title shown in lists of Annex A. Check the standard for the requirement text.
The question to answer is simple: how do you know what runs in production, and how does new software get there?
Evidence by question
| Question | Artifact |
|---|---|
| Who may deploy? | Role list for the deploy tool and registry push rights |
| What may be deployed? | Image or package source rules, approved base image list |
| How is a deploy approved? | Pull request review, pipeline approval step, change record |
| What is running now? | Export of running image digests and versions per service |
| How are unwanted installs blocked? | Admission or policy rules that reject unapproved images |
Of these, the running version export is the one teams forget. Without it you can describe the process but not show the result.
A tight deployment path in six steps
- Build only from the main branch of a protected repository.
- Produce images or packages in a controlled pipeline, never from a laptop.
- Store them in one registry with push rights limited to the pipeline identity.
- Deploy by digest, not by a mutable tag, so what is approved is exactly what runs.
- Record each deploy with who approved it, the commit, and the result.
- Export what is running on a schedule and diff it against the approved list.
Teams that cannot yet do all six can begin with steps 3 and 6, which yield evidence quickly.
Dependencies count too
Production software includes the packages your build pulled in. A dependency policy, such as a minimum package age or an allowlist for new packages, shows control over this path. A dated list of components per release, from an SBOM, shows what was installed.
Where you allow exceptions, log them. An exception with a reason and an end date is evidence of control. An unrecorded exception is a gap.
Try it yourself
Try the pull request gate demo and note where a change is held until a check passes. A gate like this is the approval step in your install path.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard supports policies, gates and guardrails on pull requests, plus compliance and evidence automation, so gate outcomes can be kept as records. You can try the free scan at gold.safeguard.sh/scan. Treat any export as input to your own review, not as a finding of compliance.
Quick check
Does 8.19 apply to cloud and serverless?
The title says operational systems, which includes cloud platforms. Apply the same question: how does software reach production and who approved it.
Is a mutable image tag a problem?
It makes evidence weaker, because the tag can point to different content over time. Digests identify exact content and are easier to show.
Sources
- ISO 27001 Annex A controls list, Security Compliance Guide
- ISO 27001 Annex A controls explained, Glocert International
Last reviewed: 19 October 2026.
