The package that arrived by hand.
A.8.19 is the ISO 27001:2022 control about how software arrives on operational systems: the servers, containers, and other live infrastructure that carry real traffic. The expectation is that software reaches those systems through the managed process: approved sources, builds that were tested and accepted before they landed in production, installers who are authorized, and a record of what is running where. Not an install typed onto a production host because someone needed a tool five minutes ago. The control is easy to trip because the direct install is usually the fastest way to debug or unblock, and it is almost always framed as temporary.
The shapes the same control failure takes.
A.8.19 rarely breaks with a change labelled 'install'. It breaks when software reaches an operational system through a channel that skips the managed process. The recurring shapes:
A package lands on a live host by hand
An ops script or runbook step installs a package directly on production servers over SSH, so the operational system ends up running software that never went through the image or package pipeline.
A deploy bypasses the reviewed pipeline
Code or binaries ship by rsync from a laptop or by editing files on the server, so the version running in production is one that no review, test, or approval record has seen.
A container installs at runtime
The package manager runs inside the live container (kubectl exec plus a package manager) instead of in the image build, so prod serves traffic with software the reviewed image never contained, and the same unreviewed install gets repeated on every new pod.
An emergency tool becomes standing software
The 'temporary' install ships with no removal path or owner, so unapproved packages accumulate on operational systems and host-to-host drift creeps in.
Install privilege goes standing
Root or sudo package rights on operational systems are handed out as a normal grant, so any install can happen on prod without producing a change record.
A debugging install typed onto every web host.
A scanner report flags an old TLS cipher, and the team wants real handshake data before touching any config. The quick route is a script that loops over the web hosts, installs tcpdump on each one on the spot, and captures a sample. It works, it merges as a one-off, and every host it touches ends the run with a package that arrived by hand: no image change, no approval, no record.
# grab handshake samples from the web hosts for the cipher hunt (OPS-3311)for host in $(cat deploy/webhosts); do- ssh "$host" 'journalctl -u api -n 5000 | grep -i handshake'+ ssh "$host" 'sudo apt-get install -y tcpdump && sudo tcpdump -i eth0 -c 2000 -w /tmp/tls.pcap port 443'doneThe script connects to every host in the web list and runs an install command on it before starting the capture: nothing in the change routes the package through the image build or the package pipeline, and nothing removes it afterward, so the hosts keep tcpdump after the script finishes. The diff cannot show whether the install was recorded as an approved change elsewhere, or whether the hosts' image already ships the tool; if it does, the line is dead weight, and if it does not, every host just gained software from an unmanaged channel. A.8.19 expects software on operational systems to arrive through the managed process: the same review, testing, and record as any other change to what runs in production. Capture from a bastion against a mirrored port instead, add the tool to a debug image built through the pipeline, or make the install a scoped, recorded, removable change.
Auditors ask how software gets onto production, and compare that with what is running.
In an ISO 27001 audit, A.8.19 comes up as a question about the channel: how does software reach your operational systems, who is authorized to install on them, and is what is actually running consistent with what the process approves? A common way to evidence it is sampling installed packages across production hosts and looking for tools that match no approved image or change record, and for versions that differ from host to host, the signature of hand-installs. The install itself usually enters the codebase as a small, reasonable, temporary-looking change, often during an incident, which is exactly when review is thinnest. Catching it at the diff is the cheap moment.
A review, not your hosts.
heygrc flags changes that install software on operational systems and cites A.8.19 so the install gets routed through the managed channel in the pull request. It does not manage your images, run your hosts, or keep your package inventory. It catches the moment a change ships a hand-install past the pipeline, at the diff.