Installation of software on operational systems

Plain-language summary

Controlling what software gets installed on live systems — servers, laptops, shop-floor PCs — so that only approved, licensed and supported software from trusted sources goes on, installed by authorised people in a way you can trace and roll back.

What the clause is really asking

Every program on an operational system adds attack surface, licence exposure and a patching obligation, and unmanaged installs are a classic route for malware. The control asks for procedures and technical measures that keep installation under control: who may install software (normally administrators through a managed deployment tool, not users with local admin rights); what may be installed (an approved software list, or an approval route for new requests); where it may come from (vendor sources and verified downloads, not a USB stick a contractor brought); and how installs are tested, recorded and reversed if they go wrong. It covers updates and patches as well as new software, and browser extensions count as software too. The common misunderstanding is that removing local admin rights is the whole answer — it is the biggest single step, but you still need the approval, the record and the rollback. Plant floors matter here: vendor engineers loading software onto HMI and SCADA PCs must follow the same route as IT, and those PCs often run the oldest, least patchable software in the building.

What auditors look for

Auditors ask who has local administrator rights and expect the answer to be a short, justified list. They pull the software inventory from your endpoint management tool for a sample of laptops and servers and compare it with the approved software list, looking for games, personal cloud-sync clients, unapproved remote-access tools and unsupported versions. They pick an installation from the last quarter and trace it: request, approval, who installed it, testing, record. They ask how a vendor engineer installs software on a production line PC and what stops someone running an installer from a USB stick. The hard question: how would you know if unapproved software appeared on a server tonight?

Typical evidence

Software installation procedure; approved software list or catalogue; list of users with local administrator rights and the justification for each; endpoint management deployment records; software inventory reports and exception follow-up; change records for server and production-PC installs; vendor engineer access and installation records; restore points or backups taken before major installs; software licence records.

How to comply — recommendations

Remove local administrator rights from standard users first — it closes most of the gap in one move — and give the few exceptions a recorded reason and a separate admin account. Publish an approved software list and a simple request form; route new software through IT for a quick security and licence check. Deploy through your endpoint management tool (Intune, Configuration Manager or similar) so every install is logged. Run a monthly inventory report and chase anything not on the list. Put server and production-PC installs through change management (8.32), with a backup or restore point first. Write a one-paragraph rule for vendor engineers: no installs without an escort and a change record.

Common nonconformities

Most users still local administrators; no approved software list; unapproved or unlicensed software found in the inventory sample; software inventory never reviewed; vendor engineers installing on production PCs without approval or record; unsupported software versions on servers; server installs made outside change management; browser extensions uncontrolled; no rollback plan for major installations.

Resources for this clause

• ArticleISO/IEC 27001:2022 Annex A explained: the 93 controls in plain English, theme by theme, with the 114-to-93 map and the attribute tags
• ArticleThe Statement of Applicability, explained — what ISO/IEC 27001 clause 6.1.3 requires, the four ways an SoA fails Stage 1, and how to build one from the risk register
• ArticleISO/IEC 27001:2022 explained for people who already run ISO 9001: what is the same, what is new, and how to get certified
• Toolkit · $39Risk & SoA ToolkitScore your information security risks on a documented method, pick the Annex A controls that treat them, and the Statement of Applicability writes its own first draft — every justification citing the risks behind it.
• Toolkit · $29ISMS Metrics & Evidence TrackerThe three things an ISMS has to show after certification, in one workbook: measures with a live Green / Amber / Red status, management review minutes that cover every required input, and an evidence register that gives every control an owner, a rhythm and a due date.
• Free downloadAnnex A 93 Controls Quick ReferenceOne A3 page: all 93 Annex A controls in their four themes, the eleven new in 2022 flagged, and the ISO/IEC 27002:2022 attribute legend — the poster for the wall beside the Statement of Applicability.
• Free downloadISO 27001 Gap Analysis ChecklistWhere you stand against ISO/IEC 27001:2022 in one afternoon — the 30 management-system requirements and all 93 Annex A controls, scored, with owners, dates and a readiness figure that calculates itself.
• Free masterclass · ~27 minISO 27001 MasterclassYou already know four fifths of ISO 27001. Here is the other fifth — the risk method, the SoA, the 93 controls, the evidence rhythm, POPIA, and a 44-week path.
• Free appAudit ManagerPlan the programme, anchor each finding to its clause and drive the NC to closure.