A.8.19 software installation on operational systems

What A.8.19 software installation on operational systems asks for

A.8.19 asks the organization to set up procedures and measures that manage how software gets installed on operational systems, so that only approved, tested code runs in production and users cannot add software on their own. If an auditor or a customer questionnaire asks how installs are controlled, the answer should name who may install, which software is approved, how new releases are tested and rolled back, and what stops an unauthorized install from happening. The control is owned by the organization. An implementation partner can help build the procedures and collect the records, but the organization must run them. The risk is unapproved or untested code reaching production, whether it arrives from a user downloading a tool, an administrator patching a server by hand, an automated deployment job, or a vendor update that changes a system without review. Installs come through many channels, which is why the control is hard to satisfy with a single policy. The 2013 edition split this topic into two controls, A.12.5.1 on installing software on operational systems and A.12.6.2 on restricting software installation. The 2022 edition merges them into A.8.19, so an organization mapping old evidence should check that both halves are still covered.

Two US crosswalks are useful reference points, but not proof of equivalence. NIST's crosswalk from SP 800-53 Rev. 5 relates A.8.19 to CM-5 (Access Restrictions for Change), CM-7 (Least Functionality) and CM-11 (User-installed Software). Non-NIST crosswalks to the CSF 2.0 map A.8.19 to PR.PS-05, which covers preventing unauthorized software from being installed and run. NIST cautions that mapped controls are not always equivalent, so treat these relationships as starting points for your own gap analysis. Confirm the current mapping versions in NIST's OLIR catalog before you cite them to a customer or assessor.

Which systems, installs and teams fall under A.8.19 software installation

Before writing procedures for A.8.19 Installation of software on operational systems, the organization has to decide which systems are operational, which install paths count, who may install, and whether non-production environments are included. Each decision changes how much work the control takes and how much evidence an assessor will ask to see.

Which systems count as operational

Start with production servers, cloud workloads, endpoints used for business processes, and any operational technology or appliances that run business-critical services. Each class needs its own installation rules and its own inventory. Cloud accounts are easy to overlook because workloads appear and change quickly. Check whether a system that only holds copies of production data is operational for this purpose. Your asset inventory should record the classification so the scope can be shown to an auditor from one list.

Which installation paths are covered

Installs reach a system through more routes than a technician typing a command: administrator installs, self-service app stores, configuration management tools, vendor update channels, and container image builds. A.8.19 expects control over each route that can place software on an operational system. Document every path, name the owner of each, and confirm that the approval rule applies to all of them. A path that bypasses approval is a finding even if the software itself is approved.

Which people and third parties may install

Decide which named roles can install software on operational systems, and whether managed service providers, vendors and contractors are included. Remote support sessions are a common gap: a vendor engineer who installs a patch through a remote tool is performing an installation. Limit rights to the smallest set of roles, record who holds them, and review the list on a schedule. Your access control records should match the installation authority you describe.

Whether self-service installs are permitted

Some organizations allow users to install approved applications from a catalog. Others block all user-initiated installs on operational endpoints. Either choice is defensible, but it must be written down and enforced. If self-service is allowed, the catalog becomes the approved software list and needs an owner, a review cycle and a removal process. Confirm that endpoint management can prevent installs outside the catalog and that attempts are logged.

How container images and code-driven installs are handled

Container images, infrastructure as code and configuration management playbooks install software without a person at the console. Treat the approved image or playbook as the installed software list, and control who can change the base images and the pipeline that builds them. Auditors often ask how a running image was approved, so keep build records and image digests tied to the change that promoted them. Confirm that production clusters can only pull from approved registries.

Whether development and test environments are in scope

Development and test environments are not operational systems by default, but they often hold production copies, credentials or code that reaches production. Decide explicitly whether they are in scope and document the reasoning. Many organizations place them out of scope for A.8.19 while requiring the same controls under related Annex A controls such as separation of environments and change management. Ask the assessor to confirm the boundary before you build evidence around it.

How to build a software installation control that auditors can follow

This sequence turns A.8.19 into a repeatable process: decide who may install, approve what may be installed, test and roll back before change, enforce the rule on devices, watch for drift, and review exceptions. Each step leaves a record an auditor can sample.

Assign installation authority in writing
Start by deciding who may install software on operational systems, which roles can approve requests, and which installs need a change record. Your own staff own this decision, typically the security or IT operations lead with a named deputy. Record the authority in a written installation procedure that states who requests, who approves, who installs and what evidence each action produces. The output is a signed procedure version with a review date, and an auditor should be able to match every installed package to a named role.
Build the approved software register
Compile a register listing each approved software product, its approved versions, the systems or groups it may run on, its business owner and its source. Populate it from the software already running on your operational systems, then remove or justify anything without an owner. Your team maintains the register, and each addition goes through the approval step from the procedure. The output is a versioned register that you can compare against live inventory, so an auditor can see what was permitted and when it was permitted.
Set up pre-install testing and rollback
Before any approved package reaches an operational system, test it in a non-production environment that resembles production, confirm it does not break security settings or required services, and write a rollback plan that says how to restore the previous state. Assign a named owner for this step, usually the change or release lead from your own team. The output is a test record with the version tested, the outcome, the tester and the rollback notes attached to the change ticket. Ask your implementation partner or internal engineers to confirm the test environment separation matches your A.8.31 approach.
Restrict installation rights on endpoints and servers
Enforce the rules technically so that ordinary users cannot install software on managed devices and server installs run only through the approved change path. This usually means removing local administrator rights from standard users, restricting package managers and software deployment tools to authorized administrators, and applying the same restriction to servers. Record the configuration as a baseline. The output is a configuration baseline and a screenshot or export showing the restriction applied, which is the evidence most assessors ask for first.
Monitor for unapproved software
Use inventory and policy tooling to detect software that is not on the register or that runs outside an approved version. Open-source options include Wazuh Security Configuration Assessment policies that check files, registry keys and running processes, Fleet policies that ask each device a yes or no question through osquery and show which devices pass or fail, GLPI assets populated by its agent, and Zabbix host inventory that stores installed package data. Confirm with each vendor which checks your version supports before relying on them. The output is a recurring report of failing devices and their remediation tickets.
Log exceptions and handle unapproved installs
When a business need requires software outside the register, route it through a formal exception request with an owner, a justification, a risk assessment and an end date set by your own policy. When monitoring finds an unapproved install, open an incident or change record, remove the software or approve it through the normal path, and note the root cause. The output is an exception log with approver, rationale and closure evidence, plus a record of each unapproved install and what was done about it.
Review the register and exceptions on a set cycle
Review the approved software register, the access restrictions and open exceptions on a cycle your organization sets and documents, with the review owner signing off. Remove software no longer needed, retire versions past support, and confirm the restriction baselines still match what is deployed. Feed the findings into your management review and corrective action process. The output is a dated review record showing what changed, which exceptions closed and which open items have owners, giving an auditor a clear trail from the procedure to the live system.

How an assessor tests software installation controls

This table sets out how an assessor typically tests A.8.19 across six areas, the evidence each test asks for, and the findings that most often lead to a nonconformity. Read each row as a question the organization should be able to answer with records, not recollection. The main takeaway is that an approval is only useful if it exists before the install and can be matched to the software actually found on the operational system.

Test approach	Evidence requested	Common findings
Review the installation procedure and who is authorized to install	Written procedure, list of roles or named groups allowed to install on operational systems, and records of who approved the list	Procedure exists but names no owner; installers are not listed; administrators install outside the documented route
Sample recent installs on operational systems and trace each one	For each sampled install: request, approval, test record and install timestamp, drawn from change or ticket records	Approvals recorded after installation; test records missing; samples cannot be traced because the install was never logged
Compare the approved software register with an inventory or endpoint export	Approved software register, an export from the inventory or endpoint tool, and the scope of systems covered	Inventory omits servers or virtual machines; software on the export has no register entry; register lists products by name with no version
Check that standard users cannot install software and that exceptions are approved and time-limited	Local rights configuration sample, policy settings, exception register with approver, end date and review record	Standard users hold local admin rights; exceptions have no expiry; expired exceptions remain active
Review rollback planning for sampled changes	Rollback or back-out steps in the change record, backup or snapshot reference, and evidence the rollback was tested or assessed	Rollback field left blank or says only restore from backup; no evidence the backup was usable
Review monitoring that shows unapproved software is detected	Scan or policy results showing installed software checked against the approved list, alert records and the response taken	Checks run on a sample of endpoints only; findings are not reviewed; alerts are closed without a recorded action

Evidence that passes A.8.19 and how to keep it current

An auditor testing A.8.19 looks for a chain: a documented procedure, an approved list of software, a record for each install, proof that installs were tested and reversible, technical restrictions that stop unapproved installs, and scans that match what is actually running. The cards below cover each link, with how often it must be refreshed between audits and who produces it. The organization owns every artifact; an implementation partner may prepare the tooling and templates.

Written installation procedure

The procedure states who may install software on operational systems, which channels are allowed, how requests are approved and what happens when an install fails. Each version needs a named owner and a review date, and the document should match what administrators actually do. Check that the procedure references the approved software register and the change process used under A.8.32. Owners are usually the head of IT operations or the platform team lead, with the security function reviewing it. Refresh it at least on the review date and after any change to tooling or the install channel.

Approved software register

The register lists each permitted product, its exact version, the business owner, the approved operating systems and the systems where it may run. Auditors compare it against inventory exports, so entries must use the same product names and version strings the endpoints report. Remove end-of-life versions and record the date each entry was approved. The IT asset or platform team typically maintains it, and the security team confirms additions. Refresh it with every approval or removal, and reconcile it against inventory at least once per review cycle.

Change and request records per install

Each installation on an operational system should trace to a ticket or change record that shows the requester, the business reason, the approver and the target systems. Records that link to a request ID let an auditor sample an install and follow it back to authorization. Confirm that emergency installs also leave a record, approved after the fact. The service desk or change board produces these records, and the platform team attaches deployment logs. Review a sample of records each month so gaps surface before an assessor finds them.

Pre-install test and rollback records

Before a software change reaches production, the test record should show what was installed in a non-production environment, which checks passed and who signed off. The rollback plan must name the previous version, the reversal steps and the data or configuration to restore. Keep records showing that rollback was tested for significant packages. Test and rollback evidence is usually produced by the engineer performing the install, with the approver reviewing it. Refresh these records for every package change, not on a calendar schedule.

Technical restriction settings

Procedures alone do not stop a user from installing software. Evidence should include the configured restriction: local administrator policy, application control or allowlisting rules, and package manager permissions on Linux servers. Export the settings and show who is in privileged groups, together with the date of the last review. Exceptions should be approved and time-limited. The platform or endpoint team produces these exports, often from configuration management or directory tooling. Refresh the exports after every policy change and at each periodic access review.

Inventory and scan exports

Inventory or scan exports show what is actually installed on each operational system, compared with the approved register. Wazuh can flag misconfigurations and check processes against policy, Fleet can run yes or no queries on devices, and GLPI or Zabbix can hold software inventory from agents. Any unapproved item should appear in an exception log with an owner and a disposition. Confirm that each tool's coverage matches the systems in scope, since gaps in agent deployment create blind spots. The security or operations team produces the export, and a recurring review should be scheduled and recorded.

What meeting software installation controls costs in money and effort

The table breaks down the cost components of running A.8.19 controls, showing who is paid for each, whether it is one-time or recurring, what drives it up, and how to keep it down. Use it to structure a written quote and to see where internal effort ends and outside help begins.

Cost component	One-time or recurring	What drives it	How to reduce it
Tooling or licenses for inventory, configuration and policy enforcement	Recurring if subscription or support is bought; one-time if only deployment is paid	Number of endpoints and servers, number of policy checks, and whether support contracts are needed. Open-source tools such as Wazuh (GPL-2.0-only), Fleet (MIT), GLPI (GPL-3.0-or-later) and Zabbix (AGPL-3.0-only) carry their own license terms, so confirm obligations before self-hosting	Choose tools that already cover inventory and policy checks, confirm license terms with counsel, and budget operating effort for self-hosting since removing subscription spend does not remove hosting and upkeep
Engineering time to define the allowlist and build installation restrictions	One-time, with later revisions	Number of operating system builds, number of approved software titles, and how many user groups need different rights	Start with a narrow approved list for the highest-risk systems, reuse configuration baselines, and record decisions in change tickets
Testing and rollback planning before installation	One-time per major change, recurring for each release	Complexity of operational systems, dependency chains, and whether test environments mirror production (see A.8.31)	Test packages in a representative environment, document rollback steps alongside each package, and reuse test scripts across releases
Approval and exception handling	Recurring	Volume of install requests, number of approvers, time to decision, and how often business units need software outside the list	Set clear criteria for routine approvals, pre-approve common requests, and time-limit exceptions so they expire and are reviewed
Evidence upkeep	Recurring	Frequency of inventory reports, policy compliance reviews, and the number of systems in scope for sampling	Automate exports of inventory and policy results, store them in a single evidence location, and tie each record to a ticket or approval
External testing or review, if used	Usually recurring or per engagement	Scope of the review, number of systems tested, and whether the reviewer checks restrictions or only documentation	Agree a written scope with the outside party, focus on high-risk systems first, and ask for the test method so results can be repeated internally
Auditor sampling effort	Recurring, once per audit cycle	Number of operational systems in the ISMS scope, number of installation events the auditor selects, and how quickly records can be produced	Keep a complete, indexed record of approvals and installs per system so samples can be answered without rebuilding history

Self-hosted open-source tools that enforce and evidence software installs

A.8.19 asks for software installation on operational systems to be managed securely, and no single tool does that alone. The four tools below each produce a different kind of evidence: configuration checks, device query results, asset records and host inventory. Together they help show what is installed, where it is installed, and whether it drifted from what was approved.

Wazuh configuration assessment

Wazuh's Security Configuration Assessment scans monitored endpoints against YAML policies, most of them based on CIS benchmarks and extendable with custom policies. The checks cover files, directories, registry keys and running processes, and each finding comes with remediation advice. For A.8.19, write a custom policy that flags binaries or registry entries for software the organization has not approved, then confirm in your own environment that the agents on operational systems actually run those policies. The product is licensed GPL-2.0-only, so check the license terms that apply to your deployment model.

Fleet policies for installed software

Fleet policies are yes or no questions asked of devices as osquery queries. A policy can ask whether a prohibited application is present or whether an approved application is at a required version. The policies page shows which devices pass or fail each policy, which gives a current view that can be exported as evidence. Fleet is MIT licensed. Confirm which software tables your osquery build exposes on each operating system, because coverage differs by platform and a policy that returns no rows on one platform does not prove absence.

GLPI software assets

GLPI's Assets module records computers and software, either entered manually or pushed automatically by the GLPI Agent through native inventory, which has been built into GLPI since version 10. The inventory gives the asset register that A.8.19 reviews depend on: which software sits on which machine, and when it was last seen. Manual entries drift quickly on busy operational systems, so decide which assets are maintained by the agent and which are kept by hand. Confirm agent coverage for each operating system before relying on the register as evidence.

Zabbix host inventory

Zabbix host inventory stores details such as device type, serial number, location and the responsible person for each host. It can populate these fields automatically from agent items that collect hardware, operating system and installed package data. For A.8.19, the named responsible person gives an accountable owner for each operational system, and the package data gives a second source to compare against approved software lists. Zabbix is licensed AGPL-3.0-only, so review the obligations that apply if you modify and distribute it. Confirm which package items your agent version collects on each host type.

Who does what: your team, a partner and the auditor

The organization owns A.8.19. Your team decides who may install software on operational systems, what the approved software list contains, and how exceptions are granted or refused. These are management decisions tied to your risk appetite, and an assessor will ask for the people who made them, not the partner who configured the tooling. Your team also reviews installation requests, approves or rejects them, and signs off the periodic review of the approved software register.

Procedure ownership: A named owner maintains the installation procedure, including who may request installs, who approves them and how emergency installs are handled.
Approved software register: Your staff decide which packages, versions and sources are permitted on each class of system, and record the decision date and owner.
Exception decisions: Any deviation from the register is approved by an accountable person, with a stated reason and an expiry date.
Testing and rollback acceptance: Your change or system owners confirm that installs were tested and that a rollback path exists before production.
Final review sign-off: Management reviews installation records and exceptions at a defined interval and signs the result.

Before engaging anyone, confirm that these decisions have named owners in your own documents.

Where software installation controls usually fall short

Most organizations have a software installation policy on paper. The gaps appear where the policy meets live operational systems: inventory, approval timing, admin rights, testing records, allowlist upkeep and automated installs. Each card below names one gap, the action that closes it and the evidence an assessor can check.

No inventory of operational systems

If the organization cannot list what is installed on each operational server and workstation, it cannot tell whether a piece of software is approved. Unapproved software then stays invisible until an incident or audit exposes it. Close the gap by running an automated software inventory agent on every in-scope host and reconciling its output against the approved software list each month. Evidence: dated inventory exports, the reconciliation log and the list of exceptions with owners. Ask the auditor which hosts count as operational for the scope.

Approvals recorded after installation

Some teams install first and file the request later, so the approval record confirms a decision that was already made. This defeats the purpose of A.8.19, which expects installation to be controlled before it happens. Require a ticket with the requester, business reason, security review and approver to exist before the install job or change window starts. Evidence: ticket timestamps that precede the installation time in the inventory or deployment logs.

Standard users keep local admin rights

When standard users hold local administrator rights, any approval process can be bypassed with a single click. Remove standing local admin from general users and provide a time-limited elevation path for documented exceptions, approved by the system owner. Review the exception register on a set schedule. Evidence: group membership exports showing no standing local admin, and a log of each elevation with its approval and expiry. Related controls include A.8.2 Privileged access rights.

Test and rollback steps leave no record

Teams often say they test updates in a staging environment and keep a rollback plan, yet nothing is written down that shows it happened. An assessor cannot accept a practice that exists only in conversation. Attach a short test record and a rollback step to each install request, and keep the outcome with the change ticket. This links to A.8.32 Change management. Evidence: completed test sign-off, the rollback procedure version used and any rollback performed.

Allowlists never reviewed

An allowlist approved two years ago may still permit applications the business no longer uses, or omit tools that were later adopted through proper channels. Set a review trigger that fires on major software changes, end-of-life notices and quarterly intervals, and assign an owner to each entry. Compare the allowlist to actual installed software from the inventory. Evidence: the review record, the list of removed or added entries and the approver for each change.

Vendor and automated installs bypass approval

Vendor remote support tools, endpoint management jobs, package managers and software that installs its own updates can all add software without passing through the approval path. Inventory these installers as sources, restrict which accounts and tools may run installs on operational systems, and route their changes through the same approval record. Ask each vendor to confirm in writing how it installs and updates software on your systems. Evidence: the list of authorized installers, their logged install events and the approval reference for each.

Questions buyers ask about A.8.19 cost, effort and outside help

How long does it take to get A.8.19 software installation controls in place?

The duration depends mostly on scope, meaning how many operational systems need a software installation procedure, how many teams install software on them, and how much tooling already exists. A single well-documented environment with existing endpoint management usually needs far less work than a mixed estate with unmanaged servers and no approved software list. No duration is fixed in advance. Ask any partner to split the timeline into discovery, procedure drafting, tool configuration, testing and evidence collection, and to name which of those depend on your staff being available.

What drives the cost of an A.8.19 engagement?

Cost follows the written scope. The main drivers are the number of operational systems in scope, the number of installation paths (agents, package managers, manual installers), whether a monitoring or inventory platform must be deployed or extended, and how many approval and rollback procedures must be written and tested. Costs fall into one-time items such as design, configuration and first evidence capture, and recurring items such as a support retainer, upgrades and periodic reviews. Ask the quote to separate those two groups and to state what each side must provide.

Can a small internal team implement A.8.19 without outside help?

Often yes, if the team already administers its endpoints and servers and has someone who owns change approval. The work is mostly procedural: deciding who may install software, keeping an approved list, testing before production installs, and proving that unauthorized installs are blocked or detected. The harder part is sustaining the evidence over time while the same people run operations. An outside partner is most useful when the team lacks experience with configuration assessment tooling or when the timeline for an audit is fixed.

What does the client's staff need to provide during the engagement?

The organization keeps ownership of its controls, so its people must make the decisions that a partner cannot make for it. Expect to name an owner for software approval, provide access to the systems and their current inventory, confirm which teams install software and how, and review the approved software list and rollback steps. Staff also need time to test changes on non-production systems and to attend review sessions. Ask the partner to list these inputs in writing before work starts so the schedule reflects them.

What does a fixed-scope engagement cover and how is it priced?

A fixed-scope engagement covers a defined set of systems, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list. A quote follows from the written scope, so the useful comparison is between scopes rather than between headline numbers. Ask for the systems included, the platforms to be deployed or configured, the documents produced, the tests performed, the handover items, and the exclusions. Exclusions matter as much as inclusions, especially audit fees, which are paid to the independent auditor and not to the implementation partner.

Does the same A.8.19 evidence support ISO 27001 surveillance audits?

It can, provided the evidence is kept current and tied to the approved software list, the installation procedure and the records of individual installs and blocks. Certification bodies audit on a recurring basis within the three-year certification cycle, with at least one audit in every calendar year, so the evidence must keep producing records after the first audit. Build the collection into routine operations rather than preparing it once. Confirm with your certification body which records it will sample.

Can our implementation partner also act as our ISO 27001 auditor?

No. An implementation partner prepares systems, controls and evidence, while only an independent auditor or certification body issues audit reports or certificates. Independence is required, so a firm that designed or configured your A.8.19 controls cannot also assess them for certification. Use the partner to build and document the control, then engage a separate accredited certification body for the audit. Check that the certification body is accredited and that its certificate can be verified in the IAF CertSearch database.

What should we check in an implementation partner's proposal?

Look for a written scope that names the systems, platforms, documents and tests, and a clear split of responsibilities between your organization and the partner. The proposal should state that the partner does not issue audit reports or certificates, list the evidence each control will produce, and describe how rollback and approval procedures will be tested before production use. Ask who will do the work, how changes to scope are priced, what support continues after handover, and which open-source platforms are proposed and why. Vague promises about passing an audit should be treated as a warning sign.

How DeployOpen scopes and prepares software installation evidence

DeployOpen plans, implements and documents the technical side of A.8.19 Installation of software on operational systems inside the client's own infrastructure. The organization keeps ownership of its controls, while DeployOpen prepares the systems, approval records and evidence that an independent auditor or certification body will review.

How we scope

Engagements are fixed-scope, with systems, deliverables and timelines agreed in writing before work starts.
The written scope names which operational systems, endpoints and software sources fall under the installation control.
Scope also records who approves installs, which roles are excluded, and which parts remain with the client's own staff.

How we build

Configure endpoint and server agents to report installed software and running processes to a central inventory.
Define a documented allowlist of approved software, with owners and review dates for each entry.
Set up policy checks that flag unapproved installs and test install and rollback steps in a non-production environment first.

How we hand over

Deliver written procedures covering install requests, testing, rollback planning and approval records for operational systems.
Provide exported inventory reports, policy results and change records that show how installs were authorized and checked.
Document the configuration of each open-source tool so the client's team can reproduce and maintain the evidence.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
Retainers can cover periodic review of the approved software list and tuning of inventory and policy checks.
Confirm with the auditor in advance which evidence formats and sampling periods they will accept for this control.