ISO 27001 Annex A 8.18: controlling privileged utility programs

The auditor asks which tools in your estate can bypass application controls, and where the list is. Your engineers hold direct database clients on their laptops, nobody has written them down, and the approval workflow in your finance system can be sidestepped with one query. ISO 27001 Annex A 8.18 is the control that closes that gap.

This guide is for IT leaders, compliance managers and lead engineers at UK regulated service providers and B2B SaaS firms of 25 to 250 people. It covers what the control requires, how to run it with scans, allowlists and just-in-time grants, and what auditors sample.

What does ISO 27001:2022 Annex A 8.18 use of privileged utility programs require?

ISO 27001:2022 Annex A 8.18 use of privileged utility programs asks you to keep a closely watched list of the tools that can override system and application controls. It is a preventive control touching confidentiality, integrity and availability, carried over from ISO 27001:2013 A.9.4.4. In short: know the tools, name the holders, approve use, log it, remove what is idle.

Every estate holds tools that sidestep the application layer. Used properly, they are how systems get maintained. Used carelessly or with bad intent, they rewrite data without validation, read traffic without permission and switch off the defences everything else assumes.

In plain English, the control asks for six things:

• Known: every override-capable tool is on an inventory.
• Held by few: the minimum set of named people, each with a justification.
• Approved per use where practical, rather than granted for ever.
• Separated: kept apart from business applications and their approvers.
• Logged whenever the tool runs.
• Removed when nothing needs it any more.

The preventive label fits because the control denies tooling to anyone without an approved need before misuse can happen. All three of confidentiality, integrity and availability are touched: a sniffer exposes data, a raw database edit corrupts it, and a mis-aimed disk utility takes the system down.

Two mechanisms do the work. Approval is bound to identity, so the control knows who may run what. Allowlisting on endpoints and servers is where that rule is enforced.

The mountain is smaller than it looks, because most firms already own the pieces: an identity provider, an MDM and a log store. Annex A 5.3 supplies the duty-separation logic, and Annex A 8.15 receives the usage logs.

What are examples of privileged utility programs?

A privileged utility program is any tool that acts below or around an application's own controls. Typical examples are direct database clients, packet sniffers, disk and partition hex editors, debuggers, and backup or patching frameworks. If a tool can change data or configuration without the application's say-so, it falls in scope.

Use this list to recognise the tools in your own estate:

• Direct database clients edit production rows without the application's validation or approval.
• Packet sniffers and capture tools read traffic and harvest credentials.
• Disk, partition and hex editors change data beneath the file system's own protections.
• Debuggers inspect and alter running processes.
• Backup and patching frameworks read everything and push changes everywhere.
• Remote-execution frameworks run commands on many hosts at once.

Backup and patching frameworks surprise people. They are trusted, scheduled and everywhere, which is exactly why their credentials deserve the scrutiny of a database console. A tool that can read every host and write to every host is the strongest override in the estate.

Look across laptops, servers and cloud images, not only the data centre. Compilers, diagnostic frameworks and utilities bundled into server builds count too, and they are often the ones nobody remembers installing.

The test is capability, not product name. A database client pointed at a test database holding synthetic data is ordinary software, while the same client holding production credentials is a privileged utility. Scope follows what the tool can reach and override.

Why do attackers and insiders reach for privileged utilities first?

Privileged utilities let insiders rewrite data without validation and let attackers finish a compromise quietly. The NCSC and partners warn that threat actors exploit native, legitimate system tools, known as living off the land, to evade detection and persist. Leaving such tools installed hands attackers a ready-made toolkit and leaves administrative actions invisible to your audit trail.

The NCSC and partner advisory on Living off the Land tradecraft describes attackers using tools already built into systems, so their activity blends in with legitimate system and network behaviour. Switching off logging and covering movement after a compromise are jobs for exactly this class of utility.

Insiders need no such tradecraft. A back-end edit that bypasses the application's checks defeats every approval workflow the business relies on, and the application never sees it happen.

An approval workflow that a database client can bypass is decoration.

Removal sits beside restriction in this control for a simple reason: a utility that is not installed cannot be borrowed, by an insider or an intruder.

For a regulated firm the quieter cost is evidential. Admin actions done through unlogged low-level tools never reach the audit trail. Auditors and regulators read that as a gap in management control. Any dispute about who changed a record then becomes unwinnable.

An application log records what the application did, not what happened underneath it. Logging and restriction therefore have to sit below the application, at the endpoint and the operating system.

How does Annex A 8.18 differ from A.8.2 privileged access rights?

A.8.2 governs who holds elevated account rights; A.8.18 governs the specific software instruments and binaries those accounts can execute. An auditor tests the two separately, checking the tool inventory, execution restrictions and usage logs for A.8.18. Without A.8.2 foundations in place first, A.8.18 is unenforceable.

Think of A.8.2 as the key register and A.8.18 as the toolbox. The first asks who has administrator rights on the production database server, and why. The second asks what they can run once they are there, and whether anyone saw them do it.

Evidence follows the split:

• Privileged access rights: the accounts, their holders and the approval behind each elevation.
• Utility programs: the tool inventory, execution restrictions and usage logs.

Searches for ISO 27001 Annex A privileged access rights usually mean the first of these. The second is where firms with tidy account registers still collect findings, because a standard user running a downloaded disk editor never touches an account control.

Sequence matters. The restrictions in this control are tied to identity: they say who may run what. So they need reliable identities and a settled privileged-account model underneath them. Do the A.8.2 groundwork first and A.8.18 shrinks to a few days. Do it in the other order and the restrictions have nothing to bind to.

How do you control ISO 27001 Annex A use of privileged utility programs?

Control privileged utilities in four moves: allowlist them technically, grant access just-in-time against an approved ticket, keep application approvers away from the underlying tools, and log every run to a store the holders cannot edit. Standing permanent access is the habit this replaces, not the engineers' ability to work.

Each move closes a bypass that auditors and attackers both look for:

1. Allowlist technically. Application allowlisting or your MDM's execution controls stop a standard user running a downloaded binary, which is the failure that actually happens. Strip compilers, diagnostic frameworks and bundled utilities from production images, and keep sanctioned tools in a restricted location.
2. Elevate just-in-time. Ad-hoc use becomes an approval event: a ticket before the debugging session or data fix, and access that lapses when the change window closes. Your identity provider can do this without new tooling.
3. Separate duties. The person who approves payments in the application must not also hold the tool that edits payment records underneath it. Annex A 5.3 supplies the logic, and the inventory shows whether you honour it. Holders are named people, each with a written reason, and the set is the smallest that works: typically your infrastructure engineers and database administrators.
4. Log to a protected store. Record who, when, on what and ideally the commands issued, in a store the tool-holders cannot edit. Then give the log a reader, because a periodic skim of utility activity is cheap and sometimes very interesting.

The NCSC secure system administration guidance on privileged access management describes the just-in-time pattern. The credential is used to request access instead of reaching the administration interface, and an approved request earns a temporary credential. A stolen credential then works only for a short period, which shrinks the attacker's window.

Where the tools run matters as much as who runs them. Administer from separate management networks or dedicated workstations, not user segments. The NCSC guidance on gaining trust in management devices explains why: an attacker who compromises a less trusted device inherits its access, and can browse up to anything that device can reach.

Some teams will say they need these tools daily. For the truly dangerous subset, that is rarely true.

If the daily workflow runs through a bypass tool, the workflow needs fixing, not the tool blessing.

At 50 people this is a standing arrangement rather than a project. The engineers who need a tool request it, receive a time-boxed grant and carry on, while everyone else simply cannot run it.

Four pitfalls turn up repeatedly:

• No inventory, so the honest answer to "what can override your controls?" is a shrug.
• Self-approval, where the requester approves their own access and collapses the duty separation.
• Developer laptops treated as out of scope while each carries production database clients and capture tools under local admin.
• Orphaned incident utilities, installed in a hurry and never removed, each a standing capability nobody owns.

A scheduled sweep for tools that arrived during incidents or projects, and for holders whose justification has lapsed, catches the orphans before an auditor does.

Can you automate A.8.18 with scans, allowlists as code and SIEM telemetry?

Yes: every enforcement point is queryable. Agent scans diff installed software against the sanctioned list and open tickets on anything new. Allowlist rules live in version control and deploy through MDM. IdP time-boxed grants capture approval and expiry. Process-execution events stream to the SIEM, alerting on use outside an approved window.

Inventory comes first. Endpoint and server agents already report installed software, so a scheduled job can compare findings with the sanctioned list and raise a ticket on any new tool. Sprawl surfaces within days rather than at the next audit.

An inventory built from a survey is out of date the day it is signed.

Allowlist rules held in version control can be reviewed, compared and shown to match across every device. A reviewer sees a pull request where they used to see a screenshot.

Each grant record already holds the approver, the window and the expiry, so an auditor's sample of ad-hoc use is answered by a query, not a hunt through email and chat. The SIEM then closes the loop. An alert on use outside an approved window turns "tightly controlled" from an assertion into a detection rule.

Pair the telemetry with the management-network boundary from the previous section, so the only places these tools can start are places you already watch.

Two pitfalls survive automation if you ignore them. Sessions that leave no trace put a hole in the audit trail exactly where it matters, so confirm the sensitive tool set emits process events. A hand-kept spreadsheet fails the auditor's probe for a tool you never listed, so retire it in favour of the scan. This kind of automated check is what our GRC engineering service builds. The table maps each enforcement point to the evidence an auditor can query.

What will an auditor ask about ISO 27001 Annex A 8.18?

Auditors ask for the list of tools that bypass application controls, then trace one inventoried tool from approval to log entry and probe for a tool missing from the inventory. They also test what a standard build does with an unsanctioned binary and look for anyone holding both an approval role and bypass tooling.

Questions to expect in the room:

• "What tools in your estate can bypass application controls, and where is the list?"
• "Who can run a query directly against the production database, and who approved that?"
• "If I handed a standard user a downloaded disk editor, what stops them running it?"
• "Show me the last time someone used one of these tools, and who reviewed the log."

Sampling starts from your own inventory. The auditor picks a tool, then follows a recent use to its approval ticket and its log entry. The ticket must show approval by someone other than the requester.

Bring this evidence set:

• The inventory of sanctioned tools with named holders and justifications.
• The operating-procedure section covering authorisation levels and rules of use.
• Approval tickets for sampled ad-hoc use.
• Allowlisting or MDM policy exports.
• Usage logs from sampled sessions, held in a protected store.
• A recent review record showing stale tools removed and lapsed access revoked.
• Training records for the technical staff who hold the tools.

Grading follows certification-body practice. Standard users free to run override-capable tools, or production database access with no logging at all, is the total-breakdown case and grades major. A stale inventory, one lapsed justification or a gap in session logging grades minor, and minors aggregate to major when they form a pattern.

How much work is ISO 27001 Annex A 8.18 for a 25–250-person firm?

Once A.8.2 foundations exist, A.8.18 is a few days' work: an inventory, a section in your existing IT operating procedures, allowlisting rules and a logging wire-up. A standalone policy document is enterprise theatre at this scale. The payoff is a control that runs itself and answers auditors with queries rather than spreadsheets.

The sequence is short:

1. Confirm the A.8.2 foundations are settled.
2. Run the scan and turn the result into an inventory with named holders and justifications.
3. Add a utilities section to your IT operating procedures covering who may hold which tools, how use is approved and what is logged.
4. Deploy allowlisting rules through your MDM.
5. Wire process-execution logs to the SIEM and schedule the sweep for tools that arrived and never left.

Where engineers need safer paths, such as break-glass tooling, management-plane separation or access patterns that avoid production, that is cloud security architecture work. It pays back by taking routine work off the bypass tools.

At this scale, the same setup serves auditors and enterprise customers alike. The next security questionnaire that asks about privileged tooling gets a query result, not a week of chasing spreadsheets.

Frequently asked questions