ISO 27001 A.8.18: Control powerful utility programs

What A.8.18 requires in practice

A.8.18 requires the use of utility tools that can override system and application controls to be restricted and tightly controlled. These are tools that go beneath the normal safeguards of an application, such as direct database editors, disk and recovery tools, and maintenance or diagnostic software.

In practice the organisation identifies which tools on its systems have that power, which is a question of capability and not of product label. It decides who may use each, for what purpose and under what approval, and removes or disables those with no current need. It also decides how use is recorded and reviewed. Because the control speaks of tight control, urgent or emergency use needs a defined route so that speed does not become an unrecorded shortcut.

Outputs include an identified set of powerful tools, restricted availability, authorised use and records of that use. The control prescribes no product and no approval format. Sterling's teams often compare what is installed with what is authorised as a method for finding forgotten tools.

Identify capability rather than relying on a product label

Review tools that can access or alter protected information, change system behaviour or bypass an application's normal checks. Diagnostic, recovery and administrative tools may have legitimate value while still creating significant exposure. The same tool can present different risks depending on its permissions, target system and available functions.

Distinguish the right to perform ordinary administration from the right to use a particularly powerful utility for a specific purpose. Privileged access management establishes relevant access governance, but a broadly approved role should not automatically make every tool and action appropriate.

Define an authorised use

Establish who may use the utility, on which systems and for which tasks. Consider whether access should be limited to an approved maintenance period or supplied only when needed. Remove or disable unnecessary capabilities where appropriate, rather than leaving them available because they were useful during installation.

Retain individual accountability. Shared use without a reliable link to the operator makes it difficult to explain an action later. Authorisation should describe the task clearly enough for a reviewer to distinguish expected work from an unexplained change. It should also respect any necessary separation of duties.

Why controlling powerful utility tools matters to the business

A utility tool that can bypass application safeguards also bypasses the audit trails, approvals and restrictions the business relies on. In the wrong hands, or if an attacker obtains access to it, such a tool can change records, extract data or disable protections without leaving the usual trace. Many incidents and fraud cases involve a maintenance tool left available long after its purpose ended. Controlling these tools protects the integrity of business data, supports accurate accountability for technical staff and gives clients confidence that nobody can alter their records quietly. Auditors look at this control because it reveals whether stated restrictions can be sidestepped, which affects confidence in the wider access arrangements.

How to implement A.8.18

Begin by finding what can override your controls, because teams usually underestimate how many such tools exist on their systems. Then narrow availability to match real, authorised needs.

1. Survey operational systems for tools that can bypass application or system controls, judging by what they can do rather than what they are called.
2. Remove or disable those with no current purpose, and record the reasons for keeping the rest.
3. Define who may use each remaining tool, for what kinds of task and with whose approval.
4. Restrict access technically, so that availability matches authorisation and not only a policy statement.
5. Plan urgent use in advance: who can authorise it, how it is recorded and how it is reviewed afterwards.
6. Record use of these tools and decide who reviews that record.
7. Compare installed tools with the authorised list from time to time, act on differences and repeat the survey when systems are rebuilt or replaced.

Evidence an auditor expects for A.8.18

An auditor will look for proof that powerful tools are known, restricted and accounted for. Useful evidence includes:

• a list of utility tools that can override controls, with reasons for those retained;
• records of who is authorised to use each one and how that authorisation was given;
• observation that an unauthorised account cannot run or reach the tool;
• records of recent use, linked to a task or approval;
• an interview with a system administrator about how an urgent task would be handled.

Observing availability on a live system is more convincing than reading the policy. A match between the authorised list and what is actually installed is the key test.

Common nonconformities with A.8.18

Findings usually show tools left in place after the need has passed.

• A recovery or maintenance tool still available on a production system long after the project that needed it.
• All administrators able to run any powerful tool, whatever their role.
• No list of which tools can override controls, so nothing is controlled by design.
• Use of the tools recorded nowhere, so changes made through them cannot be traced.
• Emergency use treated as exempt from approval, with no review afterwards.

Illustrative software example: direct database maintenance

Illustrative manufacturing example: a recovery utility left available

A hypothetical manufacturer installs a recovery tool during an outage affecting a planning workstation. After service returns, the utility remains accessible to ordinary users even though its functions can alter protected system settings. The team's incident record says the system is restored, but it does not address the temporary capability.

The organisation reviews the remaining tool, restricts or removes it as appropriate and verifies the resulting access. It adds a check for temporary utilities to the completion of relevant recovery work. This links the exceptional intervention with the final operating state, rather than allowing emergency access to become an unexamined permanent arrangement.

Keep control during urgent work

An urgent incident may require faster authorisation, but it still needs an accountable route. Define who can approve exceptional use, how the operator's actions are recorded and what review follows. A process that relies on finding an unavailable manager during an outage may drive staff towards an improvised workaround.

Where the utility can affect live information, assess the need for appropriate recovery preparation and a controlled change plan. Connect the work with change management. Do not assume that a technically reversible command guarantees that the wider business effect can be undone.

Demonstrate that availability matches authorisation

Useful evidence includes the identified capability, permitted users, task authorisation, relevant usage records and confirmation that temporary access ended. These are practical methods rather than prescribed form names. Documentation should explain the control without publishing sensitive operational instructions to a wider audience than necessary.

An authorised test can use representative accounts to establish whether the utility is available only as intended. Trace a completed maintenance task through approval, use and review. Check the actual environment after the task, because a ticket marked closed does not prove that access was withdrawn or a temporary tool removed.

Protect usage records through logging controls. Common weaknesses include unrestricted utility folders, shared operator identities and unexplained retention of tools after troubleshooting. Review these findings through operational control, keeping the technical decision connected to the information owner and relevant business needs.