Use of privileged utility programs

Plain-language summary

Restricting and controlling the tools that can bypass normal system and application controls — PowerShell, remote administration kits, registry and disk editors, database consoles, PLC programming software — so only authorised people can run them and every use leaves a trace.

What the clause is really asking

Some programs can do what the operating system or application would normally stop a user from doing: change permissions directly, edit the database underneath the ERP, read memory, reset passwords, push commands to every machine at once. Attackers favour them because using tools already on the machine ('living off the land') raises fewer alarms than bringing in malware. The control asks you to identify which utilities in your environment can override controls, limit who may use them, and keep them away from ordinary users. In practice that means an inventory of such tools; use only by named administrators through separate admin accounts with strong authentication; removal or blocking of utilities nobody needs (application allow-listing does this well); logging of their use; and authorisation for occasional use. The common misunderstanding is treating this as a repeat of 8.2 on privileged access rights: 8.2 is about accounts, this control is about tools. On a plant, the engineering laptop with PLC and HMI programming software is the most powerful utility on site and rarely appears on anyone's list.

What auditors look for

Auditors ask for your list of privileged utilities and then test it against reality: they sit with an administrator and look at what is installed on a standard user laptop, a server and an engineering workstation. They ask whether a standard user can open PowerShell, the registry editor or an elevated command prompt, and whether that is blocked or merely discouraged. They pick one utility — the remote management agent, the database console — and ask who can use it, through which account, and where its use is logged. The hard question: show me the last time someone ran this tool on a production system, who approved it and what they did.

Typical evidence

Inventory of privileged utility programs with authorised users; application allow-listing or blocking policy and its configuration; separate administrator accounts and MFA settings; logs of utility use (script logging, remote-tool session logs, database audit logs); approval records for one-off use; removal records for unneeded tools; access list for engineering workstations and PLC programming software.

How to comply — recommendations

Start with a one-page list of the utilities that can bypass controls in your environment: scripting shells, remote management and remote-desktop tools, system-internals toolkits, database management consoles, password-recovery tools and, on the plant floor, PLC and HMI programming packages. For each, name who may use it and from which account. Remove what nobody needs and block the rest for standard users with the application control built into your endpoint platform. Turn on PowerShell logging and keep remote-tool session logs. Keep engineering laptops assigned, locked away and off the general network when not in use. Review the list and the authorised group twice a year alongside the privileged access review.

Common nonconformities

No list of privileged utilities; standard users able to run administrative tools and scripting shells unrestricted; remote-access tools installed by vendors and never removed; utility use not logged; administrators using everyday accounts for utility work; PLC programming software on unassigned laptops with no access control; utilities left on servers after a one-off job.

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.