--- title: "ISO 27001 A.8.19: installation of software on operational systems" canonical: https://www.grcmana.io/vault/iso-27001/annex-a-8-19-installation-of-software-on-operational-systems published: 2023-07-17 updated: 2026-10-07 author: "Harry West" framework: "ISO 27001" control: "A.8.19 Installation of software on operational systems" journeyStage: implementation --- # ISO 27001 A.8.19: installation of software on operational systems ## Key takeaways Annex A 8.19 is one control run as two lanes: endpoints, controlled by removing local admin and deploying through MDM, and production, controlled by CI/CD gates with a rollback plan. Most of the work formalises what engineering already does. Both lanes leave machine-readable evidence, so the control can reconcile itself. - **Two lanes** — Endpoints are controlled by removing local admin and deploying through MDM from an approved list. Production is controlled by CI/CD gates, tested releases and a rollback plan. - **Enforcement point** — Removing local administrator rights from standard accounts is the single change the endpoint lane depends on, because users without admin rights cannot run system-wide installers. - **Soft edges** — Browser extensions, portable executables and self-served SaaS apps with OAuth consent count as installations, so they follow the same request route, allow list and inventory review. - **Audit grading** — Auditors sample one recent production deployment and one laptop. Local admin held by standard users across the fleet grades major, while isolated gaps such as a stale approved list grade minor. The due-diligence questionnaire asks whether your staff hold local admin rights and how you test production changes. The honest answers are "some of them" and "it depends who deploys". This guide shows how to meet installation of software on operational systems under ISO 27001:2022 Annex A 8.19 without slowing releases. It is written for security and engineering leads facing a Stage 2 or surveillance audit. We treat the control as two lanes, endpoints and production, and most of it formalises what your engineers already do. You will leave with the controls to run, the evidence an auditor samples and the checks that collect that evidence for you. ## What does ISO 27001 Annex A 8.19 require for installation of software on operational systems? ISO 27001 installation of software on operational systems means one thing under Annex A 8.19: software reaches live systems only through a controlled route. Authorised people install it, testing precedes rollout with a way back, every change is logged, and least privilege decides who can install anything at all. Read the control as two lanes and a provenance check: - **Endpoints.** Laptops and workstations receive software from a managed route, and standard users cannot install their own. - **Production.** Servers, containers and cloud workloads change only through an authorised, tested, reversible and logged release. - **Provenance.** Vendor products stay within support, open-source dependencies stay maintained and supplier installs stay supervised. Annex A 8.19 is a preventive control that serves confidentiality, integrity and availability together. Rogue software leaks data, tampered packages corrupt it, and a rollout with no way back is a self-inflicted outage. Two failure stories start here. An employee with local admin installs a helpful-looking extension or cracked utility, and it becomes the breach. At 25–250 people that is rarely malice, just friction. The second story is the self-inflicted outage: an untested update pushed to production on a Friday with no back-out plan. Enterprise questionnaires turn each story into commercial damage, because they ask whether staff hold admin rights and how production changes are tested. Unsupported or unlicensed software also reads to auditors and insurers as a firm not in control of its own systems. Supply-chain incidents add a third cost. Clients send a "were you exposed?" email after every headline incident. If you cannot say what software you run and where it came from, you cannot answer it. The control sits beside change management (A.8.32), leans on technical vulnerability management (A.8.8) for patching, and borrows supplier supervision when a vendor does the installing. If you already run a CI/CD pipeline and an MDM platform, you are closer than the wording suggests. ## How do you stop standard users installing software on laptops? Remove local administrator rights from standard user accounts. That single change is the enforcement point the endpoint lane depends on, because without admin rights a user cannot run a system-wide installer. The NCSC Windows guidance advises provisioning non-administrative accounts during setup, removing the need for local admin accounts on enterprise endpoints. Enrol new laptops with a standard daily account from the first login, so nobody has to claw privileges back later. People can still install what is sanctioned: the [NCSC Windows device security guidance](https://www.ncsc.gov.uk/collection/device-security-guidance/platform-guides/windows) publishes approved apps through the Intune Company Portal for self-service. Admin removal does not stop everything, because portable binaries still run without an installer. The allow list and the soft-edge controls in the next two sections close that gap. Do endpoints early. This lane covers admin-rights removal, MDM deployment and the approved list. It takes one to two weeks including the grumbling, and it is the highest risk-reduction-per-effort move in the technological controls. The usual objection is that engineers need admin. Leave it in place and one phished developer installs the attacker's tooling for them. A local-admin exception with no expiry is the rule wearing a disguise. Genuine elevation needs are a separate question, answered in the FAQ below. Handled well, they leave the fleet clean without blocking anyone's day. ## How do approved-software lists, MDM deployment and automatic updates work in practice? Use your device management platform, such as Intune or Jamf, to deploy sanctioned software and enforce updates. Keep a living approved-software list of what is allowed and in which versions. The NCSC calls allow lists a much better strategy than deny lists, and advises enforcing automatic updates through MDM. Three moves make the path work: - **Deploy from the platform.** Sanctioned software arrives through device management, not through users double-clicking installers. - **Give every request a real decision.** A business case, a quick security look and a yes or no within days. A slow route is what breeds shadow IT. - **Enforce updates centrally.** Users can often defer or decline updates, so the [NCSC enterprise software patching guidance](https://www.ncsc.gov.uk/collection/device-security-guidance/managing-deployed-devices/keeping-devices-and-software-up-to-date) also suggests checking update compliance through MDM. Patching then never depends on a user clicking "remind me tomorrow". The [NCSC third-party application management guidance](https://www.ncsc.gov.uk/collection/device-security-guidance/policies-and-settings/using-third-party-applications-on-devices) adds that allow lists can be joined up with licensing and procurement in a lightweight approvals process. Your approved list can therefore double as the licence record an auditor asks for. Keep the list as a living page: what is sanctioned, in which versions, who owns each entry and when it was last reviewed. A couple of reviews a year is enough at this size. An approved-software list written for the audit is a historical document, not a control. Over-engineering the approval route fails too. A heavyweight CAB-style approval board for every endpoint app at 40 people guarantees the workaround culture the control exists to prevent. One accountable person deciding within a few days beats a committee that meets monthly. ## How do you control browser extensions, portable executables and OAuth app consent? Treat them as installations. Browser extensions, portable binaries that run without installing, and self-served SaaS sign-ups that grant OAuth consent all bring in new code or new data processors. They do it outside the classic installer controls. Govern them through the same request route, an allow list, and a regular inventory review. Each soft edge needs a slightly different handle: - **Browser extensions.** Hold an approved set and compare what is installed against it at each review. One extension with broad page permissions can see everything an employee types into a client portal. - **Portable executables.** A binary that runs without installing never trips an installer control. The NCSC Windows guidance closes this gap by stopping users running programs from any location they can write to. An allow list goes further, limiting what runs and not only what installs. - **SaaS and OAuth consent.** A self-served app processing client data outside your vetting is the modern shadow IT. Treat each consent grant as adding a new data processor, and send the request through the same decision route. Expect auditors to ask about it directly. The pitfall is policing installers while ignoring everything that does not install. A SaaS tool that onboards with a credit card never touches the endpoint. The inventory review therefore lists authorised SaaS apps and their consent grants as well as installed software. A twice-yearly review, the same cadence as the approved list, is enough at this scale. Automation can take over the comparison later, as the final section shows. ## What does a compliant production deployment pipeline look like under A.8.19? A compliant production deployment has an authorised deployer, evidence of testing away from live, a written back-out plan and a log entry. In a cloud estate, a CI/CD pipeline is this control: peer review, automated tests, staged deploys and one-command rollback. Package signatures or checksums are verified where the platform supports it. The work is usually formalising what engineering already does, not adding ceremony. Write the pipeline down as the procedure and name who may trigger a production deploy. Three habits close the gaps most pipelines leave: - **Clean production images.** Keep development tooling and compilers off production images, so a compromised host has no ready-made build tools to run attacker code. - **Verified packages.** Make the signature or checksum check a pipeline step, not a manual one, so a tampered package fails before it runs. - **Retained versions.** Archive superseded versions with their configuration for as long as old data might need them. Estates without a pipeline can still comply with a change ticket template that forces the same fields. Every manual step is a place for evidence to go missing, which is the best argument for automating the route. A pipeline with a hotfix path around it isn't a pipeline. Shipping to production first and testing there second is the classic failure. There is no staging pass and no rollback plan, and the incident review writes itself. Send emergency fixes through the pipeline with an expedited approval instead of around it. ## How do you manage end-of-life software, open-source dependencies and supplier installs? Stay on vendor-supported versions and treat end-of-life software as a risk decision a senior person signs, never a default. Watch open-source dependencies for abandonment, and when a supplier installs or updates something for you, scope their access to the task and record what they changed. Four habits keep provenance defensible: - **Track support dates.** Record support status and licence details for key products beside their entries on the approved list. - **Sign end-of-life acceptances.** A named senior person records the risk, the reason the software stays and a date to revisit it. - **Watch open source.** Unmaintained-but-still-downloadable is the trap. A package can sit in your build long after its maintainer has gone. - **Supervise suppliers.** Scope the vendor's access to the task, watch the session and keep a note of what changed. An end-of-life system the risk register already explains is a routine answer at audit. The same system found first by the auditor is a finding. A vendor engineer who remotes in and installs things unsupervised leaves no record of what changed. Supervision is what turns that session into evidence. ## What will an auditor sample, and what evidence proves A.8.19? An auditor picks a recent production deployment and walks it end to end, then checks what a standard account can actually install on a laptop. Evidence is change tickets, test logs predating deployment, MDM configuration profiles and the approved-software inventory. Standard users with local admin across the fleet grades major; isolated gaps grade minor. The walk-through follows ticket, test evidence, approver and rollback plan. The auditor may ask for the MDM console live. Software inventories are compared against the approved list, and anything unexplained is traced back to a request. Developer laptops and long-serving servers are the favourite corners, because local admin and forgotten tooling survive there. Expect these questions in the room: - "Can your staff install software on their laptops? Show me what stops them." - "Walk me through your last production release. Where are the testing, the approval and the rollback plan?" - "How do I get a new tool approved here, and how long does it take?" - "What is your oldest piece of software, and who accepted the risk of running it?" - "How would you know if something was installed outside the process?" The evidence set that answers them: - The procedure covering both lanes, plus the approved-software list with versions and review dates. - MDM or group-policy configuration showing standard users lack install rights, and the platform doing the installing. - Change records for production deployments: request, test evidence, approval, back-out plan and outcome. - Staging or UAT results for a sampled release, dated before its production date. - Installation and file-integrity logs, with alerts on unexpected installs where wired in. - Licence records and support status for key products, and a risk acceptance for anything end-of-life. - The request trail for a recent software exception: asked, assessed, decided. Certification bodies grade by pattern. Production deployments with no testing gate and no change records are the total-breakdown case and also grade major. A stale approved list, one deployment missing its back-out plan, an untracked browser-extension estate or unaccepted end-of-life software each grade minor. A run of minors adds up to a major. ## How can GRC engineering automate A.8.19 evidence? Endpoints and production both already generate machine-readable state, so the control can reconcile itself. The checks are a scheduled diff of MDM inventory against the approved list, pipeline history as deployment evidence, recurring local-admin queries, and dependency or end-of-life feeds. Together they turn A.8.19 from an annual audit scramble into daily tickets. Four reconciliations do the work: - **Fleet inventory against the approved list.** MDM and endpoint agents already report installed software. The diff turns shadow IT discovery into a daily ticket rather than an annual surprise. - **Pipeline as evidence.** The test run, the approver, the deploy time and the rollback capability are captured as build metadata. The auditor's deployment sample becomes a link to pipeline history. - **Admin-rights drift detection.** A recurring query for local-admin membership catches the exceptions that build up after every incident and VIP request. - **Provenance watchlists.** Dependency scanning and end-of-life feeds flag abandoned open source and expiring vendor support before renewal deadlines do, and feed the risk register. This is the work our GRC engineering service wires up first on the endpoint estate, because the inventory diff and the admin query pay back fastest. On the production lane, the matching work is deployment architecture that makes the control frictionless: CI/CD gates, image pipelines free of development tooling, and artefact signing and verification. The commercial upside is speed. A questionnaire asking about admin rights and production testing is answered from live data. The "were you exposed?" email is answered from your inventory, not a week of spreadsheet archaeology. | Signal | Source | Automated check | Question it answers | | --- | --- | --- | --- | | Installed software | MDM and endpoint agents | Scheduled diff against the approved list, raising a ticket for each unexplained item | How would you know if something was installed outside the process? | | Local admin membership | Fleet directory and MDM | Recurring query across all devices, flagging any standing admin | Can your staff install software on their laptops? | | Production deployments | CI/CD pipeline history | Build metadata linking tests, approver, deploy time and rollback | Walk me through your last production release. | | Dependencies and support dates | Dependency scanning and end-of-life feeds | Alerts ahead of abandonment or expiry, feeding the risk register | What is your oldest software, and who accepted the risk? | ## Frequently asked questions ### Do developers need standing local admin rights under Annex A 8.19? No. Engineers who genuinely need elevation should get it through a separate admin identity or an on-demand grant. It should never be a standing right on the account they use every day. Time-box each grant and log it, and the exception trail doubles as audit evidence. Check open grants alongside the local-admin query, so a temporary grant cannot quietly become permanent. ### How does Annex A 8.19 differ from Annex A 8.32 change management? Annex A 8.32 governs changes of every kind, while A.8.19 applies that discipline to software and adds the endpoint question of what users may install. Run one workflow and evidence it twice. A single change ticket template with deployer, test evidence, back-out plan and outcome serves both, and one sampled release can support each control. ### Does A.8.19 stop teams deploying ten times a day? No. A decent CI/CD pipeline already satisfies the control, and the audit tests each sampled deployment rather than your frequency. What matters is that every release carries its automated tests, an approver and a rollback route. The approval can be the peer review on the merge, so frequent releases need no separate sign-off step. ### Who should own Annex A 8.19 in a 50-person company? Whoever runs IT owns the endpoint lane and the approved list, and engineering leadership owns the production lane. Name both owners in the procedure. The test at audit is whether each can produce their records without hunting. ### Which ISO 27001:2013 controls were merged into Annex A 8.19? The 2022 revision folded A.12.5.1 and A.12.6.2 from the 2013 edition into this single control. If your statement of applicability or policy set still cites both, update the mapping to one entry. Then check that the old restrictions on software installation carry over into the new procedure.