What A.8.18 use of privileged utility programs asks for in plain terms
A.8.18 asks you to restrict and tightly control any utility program that can override your system and application controls. If an auditor or customer has asked for evidence on utility tools, they want to see that you know which programs on your estate can bypass normal protections, that only authorized people can run them, and that every use leaves a record. The control does not ask you to remove all administrative software. It asks you to decide which tools are powerful enough to matter, control who uses them, and prove that the controls hold.
The risk sits in tools such as disk and partition editors, registry editors, database consoles with superuser rights, hypervisor management utilities and backup or recovery tools with raw access to storage. These programs can read, change or delete data without going through the application's own permission checks or the operating system's normal audit trail. A user who can run a disk utility on a database server may not need the application's login at all. For that reason, the control also expects utilities to be kept apart from business applications and removed where no operational need exists.
It is hard to meet because these tools often arrive with the operating system or a vendor image, so nobody has consciously approved them. Administrators reach for them during incidents and maintenance, often from shared accounts, and the use is rarely logged in a way that links it to a person and a change ticket. A practical starting point is an inventory of utilities on each server class and endpoint image, a decision for each one (approved, restricted or removed), and a check that shows which hosts can run them. Confirm with your assessor how they expect that inventory to be kept current, because the evidence is only as good as the process that updates it.
Which utility programs and systems fall under A.8.18 scope
A.8.18 scope starts with a list of every tool that can bypass a system or application control, then follows each tool to the systems it reaches and the people and third parties who operate it. The cards below cover the decisions that turn that list into a defensible, auditable inventory.
Utilities that can override controls
Start with the question the control asks: which programs can override system or application controls? This includes OS-level tools that edit files, change permissions or reset credentials, database consoles that bypass application logic, and scripts that disable logging or security agents. Standard operating system commands are not automatically in scope, so record a rationale for each exclusion. Ask whether each candidate can change data or configuration without going through the normal application path. Document the list and its owner so the decision can be reviewed.
Production and operational systems
Every utility on the list needs a map of the systems it can reach. Production servers, hypervisors and appliances usually carry the highest impact, so confirm which hosts have these tools installed and which accounts can run them. Note whether the tool is present by default, installed by a build script or copied in by an administrator. Installed-but-unused tools are still in scope, and removal decisions belong in the same record.
Cloud consoles and management planes
Cloud provider consoles, command-line tools and infrastructure automation can override the controls applied inside workloads. An administrator with console access may change networking, storage or identity settings without touching a server. Inventory the management planes your organization uses, the roles that reach them and the audit logs they produce. Confirm with each provider which of these logs are retained and for how long, because your evidence depends on them.
Backup and recovery tools
Backup, restore and disaster recovery software often runs with broad read and write access to production data and can restore over live systems. These tools are frequently managed by a different team or a vendor, which makes them easy to miss. Include the backup agent, the restore console, the credentials stored in the backup platform and any scripts that trigger restores. Check whether restore operations are logged and who can approve them.
Teams and third parties who run them
Scope follows the people. Internal administrators, platform engineers, on-call staff and help desk roles may all hold these tools, and managed service providers or outsourced operators often do too. Build a list of who runs each utility, under which account and through which access path. For third parties, check contract terms and whether their staff use shared or vendor-owned credentials that the organization cannot see in its own logs.
Building and maintaining the inventory
The inventory is the evidence the auditor will sample first, so it needs a method and a refresh cycle. Combine a discovery scan of endpoints and servers with a review of software installation records, configuration baselines and cloud resource lists. Compare the result to the approved list each quarter or whenever a change is made. Osquery-based fleet tools can answer yes or no questions about installed software across devices, which helps confirm that the inventory matches reality.
How scope differs for operators, developers and vendors
An internal IT operations team usually owns the utilities that matter most for this control: disk and partition tools, registry editors, backup and restore utilities, directory administration consoles, and scripts that can reset passwords or stop security agents. The organization owns the control here, and the question an assessor asks is simple: which utilities can bypass the access rules and monitoring that apply to ordinary administrators, and who is allowed to run them?
- Utility inventory: Maintain a list of every utility that can override operating system or application controls, by host group, with its owner and approved users.
- Authorization: Tie each privileged utility to a named role and a documented approval, and remove utilities that no current role needs.
- Logging: Record each execution with user, host, time and arguments, and send those records to a store the operators cannot edit.
- Segregation: Keep utilities off general user desktops and out of application service accounts.
An assessor will typically start by asking for the inventory and then sample a few execution logs against it. A tool that appears in the inventory but never appears in the logs is worth checking, because it may be running under a path the logging does not cover.",
A development team that can reach both test and production faces a different risk. Developers often hold database clients, deployment tools, debugging utilities and data export scripts that can read or change production data without going through the normal application path. The control asks the organization to decide which of these tools may touch production at all, and to make that decision visible.
- Environment boundaries: Define which utilities are permitted in development and test, and which are permitted against production, with production use limited to named break-glass or change-approved cases.
- Approval for production use: Require a change or incident reference before a privileged utility runs against production systems.
- Session records: Capture command history and output for production utility sessions, not only the fact that a tool was opened.
- Removal from build images: Keep debugging and administration utilities out of production container images and server templates unless they are required.
The point to check is whether a developer can reach production data through a utility that bypasses the application's own access rules. Ask the team to demonstrate one such path and show the record it leaves.
A SaaS vendor's support engineers often reach customer environments or internal production systems through vendor-built utilities, such as tenant lookup tools, impersonation features, log extractors or remote diagnostic consoles. These utilities can override customer-facing controls by design, so the vendor must restrict and record them as part of its own ISMS. Customers will usually ask for this evidence in security questionnaires.
- Tool register: List each support utility, what it can override, and which support tiers may use it.
- Customer-linked access: Require a ticket reference and a time limit for any utility that reaches customer data, and record the customer identifier with each use.
- Review of usage: Review logs of support utility use on a set schedule and investigate use that has no matching ticket.
- Hardening of the utility itself: Restrict the utility's host, network path and credentials so it cannot be run from unmanaged laptops.
Ask the vendor to show how a support engineer's use of an impersonation or diagnostic tool is tied to a ticket, and how a reviewer would notice an unticketed session.
How an assessor tests A.8.18
This table compares what an assessor does for each part of A.8.18, what evidence they ask for, and the gaps they most often find. Read it as a checklist: prepare the record for each row before the audit, because most findings come from a utility being present without a documented reason, owner or log trail. Sampling is judgment-based, so the assessor will choose utilities and sessions to test rather than reviewing everything.
| Test area | Evidence requested | Common findings |
|---|---|---|
| Inventory of utilities | Current list of utility programs that can override OS, database, hypervisor or application controls, with owner and host scope; the method used to build it, such as a scan or configuration export | Inventory built once and never refreshed; tools such as disk imaging, registry editors, database admin consoles or scripting interpreters missing from the list |
| Authorization records | Approval for each utility and each user or group allowed to run it, tied to a documented business need and reviewed on a set cycle | Blanket access for administrators or whole build groups with no individual justification; approvals that predate current staff or systems |
| Restriction of use | Technical settings showing who can execute utilities, such as application allowlists, execution policies, file permissions or privileged session brokering; sample configuration exports | Utilities runnable by standard users; restrictions documented in policy but not enforced on hosts the assessor samples |
| Logging of utility sessions | Log records of utility execution with user, host, time and command or session context; evidence that logs are retained and reviewed | Execution not logged on some hosts; logs collected but no reviewer, alerting or follow-up on utility use |
| Removal of unneeded utilities | Removal or disablement records, decommissioning tickets, or hardening baselines that list utilities deliberately excluded from builds | Legacy or vendor utilities left on images after their purpose ended; unused tools still installed on golden images |
| Separation from application environments | Architecture or access diagrams showing which utilities run in which environments, and evidence that application administrators cannot use them on production data stores | Utilities installed on application servers or shared with developers who can reach production; no clear boundary between admin and application accounts |
| Sampling approach | Lists the assessor can select from: sample hosts, utilities and sessions drawn from the inventory and the log store, plus the approvals behind each | Organizations unable to produce a complete population to sample from, which weakens every other test in the set |
How to implement A.8.18 step by step
This sequence turns A.8.18 from a policy statement into a controlled, evidenced set of utility programs. Each step produces a record an assessor can sample, from the first inventory through to a recurring review that proves the restrictions still hold.
Inventory utility programs on every system
Start by listing every utility program that can run with elevated rights or bypass the controls of an operating system, database, hypervisor, backup tool or application. Include vendor tools, scripts and administrative consoles that ship with platforms, and check both production and non-production systems. The output is a utility register with the system, the program, its version, its owner and its installation source. The step is done when the register covers every in-scope system and the system owners have confirmed it in writing.
Classify which utilities can override controls
Review each entry in the register and mark the utilities that could alter access rights, disable logging, change configurations, read data outside application permissions or modify other applications. Assign each one a risk tier, and record the reason for the tier. The output is a classified register in which every override-capable utility has a named business reason for existing. Ask the security and system owners to sign off the classification, because an incomplete classification undermines every later step.
Define the authorization model
Decide who may use each classified utility, under what conditions and for which tasks. Tie permissions to roles already defined in the access control policy, and require a documented approval for any use outside routine administration. Write the approval workflow, including who grants it, how long it applies and how it is recorded. The output is an authorization matrix and an approval procedure that the people who run these tools can point to.
Restrict and separate utilities from applications
Remove general execution rights to override-capable utilities from ordinary users and from application service accounts, then limit access to the administrators named in the matrix. Keep utilities out of application runtime paths where practical, and do not let applications call them. Implement these restrictions through operating system permissions, privileged access management, or configuration tooling, and record the settings. The output is a configuration baseline showing each restriction, with evidence that a non-authorized account cannot run the utility.
Enable logging of every utility use
Turn on logging for each classified utility so that each execution is tied to an identity, a time, a system and the command or action taken. Forward these logs to a central store protected from modification and set retention in line with the logging policy. Test the logging by running an approved utility and confirming the event appears in the central store. The output is a logging configuration and a test record that an assessor can reproduce.
Remove utilities that are not needed
Uninstall or disable any override-capable utility that the classification shows has no current, approved purpose, and remove leftover copies, old versions and unused administrative scripts. Where a utility is needed only occasionally, keep it in a controlled location that is not installed by default. The output is a removal record for each system, listing what was removed, when, by whom and the verification that the program no longer runs. Repeat the software inventory afterward to confirm the register matches the systems.
Set a periodic review of utilities and access
Schedule a recurring review of the utility register, the authorization matrix and the usage logs. Check that new utilities have been classified, that removed items have not reappeared, and that logged use matches approved requests. Record findings and corrective actions, and feed them into the risk and change processes. The output is a dated review record with sign-off. Set the review frequency in the policy and confirm it with the organization's own risk owners, since the standard does not fix an interval.
How the utility inventory, authorization and logging fit together
The control works as a chain rather than a single tool: every privileged utility is known, every use of it is approved through the same process that governs privileged access, and every session leaves a record that someone reviews. Start with the inventory. List each utility that can bypass operating system, database, hypervisor or application controls, including vendor tools, scripts and recovery utilities. For each entry, record the owner, the systems it can touch, the roles allowed to run it and whether it is still needed. Unneeded utilities are removed or disabled, which is the simplest way to shrink the population you must later authorize and monitor.
Authorization then reuses the rules you already have for A.8.2 Privileged access rights. A request to run a utility should name the person, the system, the purpose and the time window, and be approved by the same owner who approves elevated accounts. Where practical, the utility should only be reachable through a separate administrative account or a time-limited elevation, so that a normal user session cannot invoke it. Logging belongs at this point too: each session should record who ran the utility, on which host, with which arguments, and what changed. Confirm with your logging platform that these events reach central storage with protected integrity, because an auditor will sample them against the approvals.
The periodic review closes the loop. Compare the approved list with what is actually installed, using endpoint configuration checks or software inventory, and sample logged sessions against approved requests. Installation is where the link to A.8.19 Installation of software on operational systems matters: a new utility appearing on a production host is both an unauthorized install and a new privileged capability, so it should trigger the same review. This model is an explanation of how the pieces relate, not a fixed architecture. Your tooling, team size and system types will change the details, and the scope and evidence should be agreed with your assessor before you rely on them.
Evidence that passes A.8.18 and how to keep it current
An assessor testing A.8.18 wants to see which utility programs exist, who approved their use, how access to them is restricted, and that use is recorded and reviewed. Each artifact below answers one of those questions, and each needs a routine so it stays accurate between audits rather than being rebuilt the month before fieldwork.
Utility register
A current list of every utility program on operational systems that can override system or application controls, such as disk, registry, database or privilege-elevation tools. For each entry, record the host or platform, the owner, the business purpose and whether it is needed day to day. Check that the register matches what is installed, using a scheduled inventory rather than the list written at the last audit. Review it whenever a system is built, retired or patched.
Approval records
Documented authorization for each utility, naming who approved its installation or use, the approver's role, the date and the conditions attached, such as limited accounts or specific hosts. Approvals should trace to a change request or access decision so an assessor can follow the chain. Keep the approval tied to the utility version, because a major upgrade may need fresh sign-off. Confirm your approval workflow matches the access control policy your organization has adopted.
Restriction configuration
Exported settings that show how use is limited: which groups may run each utility, whether execution requires elevation, which hosts block it and how it is segregated from application servers. Store these as versioned configuration, for example in a Git repository, so changes are visible. Compare the live state against the exported baseline on a schedule and record deviations. Ask your platform team which settings they can export without manual screenshots.
Session and execution logs
Records showing when a utility ran, which account ran it, from which host and with what arguments, forwarded to a central store the administrators cannot silently edit. These logs answer whether restrictions actually held in practice. Confirm that log collection covers every host in the register, that clocks are synchronized so entries correlate, and that retention meets what your policy promises. Sample entries regularly to confirm they contain usable detail.
Removal records
Evidence that unneeded utilities were uninstalled or disabled, with the date, the method, the host and the person who verified removal. Scan results before and after removal are strong support. Removal should follow the register: any entry marked unneeded that still appears on a host is a finding. Keep removal evidence for systems that were rebuilt or decommissioned, since assessors often ask about images as well as running hosts.
Periodic review minutes
Minutes or tickets from a recurring review where owners confirm each utility is still needed, its approval is current, its restrictions still work and its logs were checked. Record decisions, not just attendance, and carry open actions to closure. Set the review frequency in your policy and keep to it, because a missed review is easier to spot than a weak control. Assign a named owner for the review so it does not depend on one person's memory.
What meeting A.8.18 costs in money and effort
This table compares the main cost components of restricting privileged utility programs, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Read it as a checklist for building a quote, since no figures are given here. The main takeaway is that most of the recurring cost comes from evidence upkeep and periodic review, not from the tools themselves.
| Cost component | One-time or recurring | What drives it | How to keep it down |
|---|---|---|---|
| Tooling or licenses | Recurring where licensed, otherwise minimal | Number of endpoints and servers, and whether endpoint management or configuration assessment is commercial or open source | Use open-source options such as Wazuh (GPL-2.0-only) and Fleet (MIT) where they fit, which removes per-seat license spend. Confirm hosting and support costs instead. |
| Engineering time for restriction and logging | One-time, with ongoing changes | Inventory of utility programs, number of platforms, and how many tools can override system or application controls | Restrict only the utilities actually in use, document the inventory once, and reuse one baseline across similar systems. |
| Evidence upkeep | Recurring | How often authorizations, logs and removal records are reviewed, and whether evidence is collected automatically or by hand | Automate policy checks and log retention so that evidence is produced as a byproduct of normal operation. |
| External testing or review | Recurring, usually scheduled | Scope of privileged access paths, whether utilities are tested in application or infrastructure assessments, and the depth of review | Fix the scope in writing before work starts, and combine review with other planned security testing where the scope overlaps. |
| Auditor sampling | Recurring, at each audit | Number of systems and utility programs in scope, and how many authorization and log records the auditor selects | Keep a single current register of permitted utilities and a consistent authorization trail so samples can be produced quickly. |
| Removal of unneeded utilities | One-time, then recurring checks | Number of legacy or vendor-supplied tools installed by default on each system | Remove unneeded utilities during build hardening so later reviews only confirm the baseline. |
What your team, a partner and the auditor each do
Your organization owns control A.8.18 in full. Your leadership and control owners decide which utility programs can override system and application controls, who may use them, under what approval, and what happens when an exception is needed. These decisions belong in your information security policy, your access control rules and your Statement of Applicability, and they must be defensible when an assessor asks why a given tool is allowed or blocked.
- Inventory and classification: Your platform and security teams decide which tools count as privileged utilities on each system class, such as disk, network, database and hypervisor tools.
- Authorization rules: Your owners approve who may run each utility, for what purpose and for how long.
- Separation decisions: Your architects decide where utilities may run and which applications they must never touch.
- Removal and exceptions: Your teams decide which unneeded utilities are removed and who signs off on each exception.
- Review cadence: Your control owner sets how often the list and the logs are reviewed and retains the records.
Before engaging anyone, confirm that your named owner can explain each approved utility and its approver without referring to an outside document.
An implementation partner prepares the systems, configuration and evidence that support your decisions. A partner can build the technical side of the control, for example by hardening hosts, restricting execution of utilities to approved accounts, routing logs to a central store and configuring compliance checks that show whether the rules hold. The partner does not decide which utilities you accept or accept the residual risk. Under DeployOpen's approach, work on this control is scoped in writing before it starts, and the organization keeps approval of every decision the partner implements.
- Configuration baseline: Hardening of hosts so that utility binaries are restricted to approved groups.
- Logging pipeline: Forwarding of utility execution events to a log platform with retention you define.
- Compliance checks: Setting up open-source checks, such as Wazuh Security Configuration Assessment or Fleet policies, that report pass or fail status.
- Evidence packs: Collecting configuration exports, check results and change records in a form your auditor can sample.
- Documentation: Writing runbooks that match the decisions your team has approved.
Ask any partner to show which of these items it will deliver and which remain with your staff.
An independent auditor or certification body tests whether the control works as your organization says it does. The auditor samples evidence, interviews owners, observes the configuration and checks logs for unauthorized use. The auditor does not design controls, write your policies, configure your systems or prepare the evidence it tests, because doing so would remove the independence that makes the certification meaningful. The certification body issues the report or certificate, and only it can do so.
- Design review: Checking that the documented rules for utility use match the decisions your owners made.
- Operating evidence: Sampling approvals, logs and check results over the audit period.
- Interviews: Asking owners to explain exceptions and how they are reviewed.
- Technical observation: Confirming that restrictions are in place on sampled systems.
- Findings: Recording nonconformities that your team must address before certification.
If a consultant offers to write the policy and then also audit it, treat that as a conflict of interest and ask for the independence arrangement in writing.
Where organizations fall short on utility program control
Most A.8.18 gaps are not missing tools. They are missing inventories, approvals and records around utilities that already sit on administrator workstations and servers. The cards below pair each common gap with a check an assessor can test and a step that closes it.
No complete utility inventory
Many teams cannot list every utility that can override system or application controls, because disk images, jump boxes and vendor appliances each ship with their own tools. Without a list, no restriction or review can be shown to cover the whole estate. Build the inventory from endpoint and server scans, then tag each entry by owner, purpose and the systems where it runs. Confirm the inventory covers cloud images and appliances, not only the corporate laptop build.
Utilities used without tickets
Administrators often run disk, registry, or password tools directly during incidents and never record why. An assessor who samples a privileged session will expect a request, an approver and a time window that match the activity. Require a change or incident reference before a restricted utility is launched, and reconcile recorded sessions against tickets each month. Ask whether break-glass use is permitted and how it is reviewed afterward.
Logs not captured for admin tools
Operating system logs often capture logons but not the execution of a utility that changes configuration, edits a security database or bypasses an application control. When that activity is invisible, the organization cannot show who used a utility or what it changed. Enable process execution auditing on privileged hosts and forward those events to a central store with restricted write access. Test by running a restricted utility in a lab and confirming the event appears in the central log.
Unneeded utilities left installed
Utilities installed for a one-time migration or a vendor support visit frequently remain on production servers for years. Each leftover binary adds a way to override controls that nobody is accountable for reviewing. Remove utilities that have no current owner or use case, and require removal as a closing step in project and vendor offboarding. Confirm removal with a scheduled scan that flags restricted binaries not on the approved list.
Compliance drift on admin workstations
Administrator workstations are often built differently from servers, with extra diagnostic tools that drift from the approved baseline over time. A policy that is correct at build can fail silently after updates or manual installs. Express the baseline as machine-checkable policies that test for restricted utilities and their configuration, then review failing devices on a fixed cadence. Wazuh's Security Configuration Assessment can scan endpoints against YAML policies, and custom policies can be added for organization-specific utilities.
Segregation not enforced
Utilities are sometimes run from the same account and host used for application administration, which removes the separation between tool use and business systems. Assessors look for distinct administrative accounts, restricted execution paths and documented ownership of each utility. Separate utility use onto dedicated administrative hosts or accounts, and restrict which users can execute them. Confirm that application service accounts cannot launch utilities that override application controls.
Questions buyers ask about A.8.18 cost, effort and outside help
How much effort does A.8.18 take to meet?
The effort depends mostly on how many utility programs your environment contains and how many of them can override system or application controls. A small, mostly cloud-native estate with a few administrative tools can usually be scoped quickly. A large estate with many legacy servers, disk utilities, database tools and vendor appliances takes longer, because each utility needs an owner, an authorization rule and a log trail. The work is front-loaded: inventory, removal and access rules take the most time, and the recurring effort is the periodic review of who can still run what. When you request a quote, ask the provider to break the effort into inventory, removal, access configuration, logging setup and review cadence so you can see where the hours go.
Can we meet A.8.18 with our own team?
Yes, in most organizations the control is met by internal staff who own the systems. The organization owns its controls, so it must decide which utilities are permitted, who may use them and how use is reviewed. The skills needed are ordinary systems administration, identity management and log handling, plus enough security knowledge to judge which tools can bypass application controls. Teams often bring in outside help when they lack time, when the estate is spread across many accounts or sites, or when they want a second opinion on the rules before an audit. Whatever you choose, confirm with your certification body or customer how they expect the control to be documented, since expectations vary between assessors.
What does the team need to provide for A.8.18?
The work needs several roles to contribute, and each one produces evidence an assessor can check:
- System owners who confirm which utilities their platforms need and why.
- Identity or access administrators who define who may run each utility and how that permission is granted and removed.
- Platform or endpoint engineers who remove unneeded utilities and keep the approved list current.
- Security or compliance staff who define the review cycle and keep the records.
Budget time for these people to meet, because the control links to access control (A.8.2 and A.8.3) and to software installation (A.8.19), and their rules must agree with each other.
How long does A.8.18 take to implement?
No duration is given in the research supplied for this topic, so treat any timeline you hear with caution until it is tied to a written scope. The schedule depends on the number of systems, how many utilities must be inventoried and removed, whether change control approvals slow each step, and how much logging already exists. Ask a provider to show the phases and the dependencies on your change calendar, and ask which parts can run in parallel. Fixed-scope engagements usually agree a timeline in writing before work starts, which lets you compare offers on the same basis.
Can an implementation partner prepare the evidence for A.8.18?
An implementation partner can prepare the systems and evidence for A.8.18, such as the utility inventory, the access rules, the removal records, the log configuration and the review records. DeployOpen works this way: it prepares systems, controls and evidence inside your infrastructure, but it does not issue audit reports or certificates. The organization must still own the decisions, such as which utilities are authorized and who approves exceptions. Only an independent auditor or certification body can assess the control and issue a result. Keep the partner's role in the written scope so the boundary is clear to your assessor.
What will an auditor sample when checking A.8.18?
Auditors typically sample from the records that show the control operates, rather than reading the policy alone. Expect requests for the approved utility list, evidence that unneeded utilities were removed or restricted, the access rules that say who may run privileged utilities, and logs showing that use was recorded. They may also ask for a sample of recent uses and the approvals behind them, and proof of periodic review. Prepare a sample-ready folder for each area before the audit so you can answer quickly. The exact sample sizes are set by the auditor, so confirm them with your certification body.
What drives the cost of A.8.18 up or down?
Cost follows the same drivers as effort, plus the price of the tools you already run. Costs rise with the number of systems, the number of legacy or vendor-managed platforms where removal needs a change window, and the amount of logging you must add. Costs fall when identity controls already exist, when the utility estate is standardized, and when reviews can reuse existing reporting. Recurring costs include the periodic review and the upkeep of the approved list. Ask any quote to separate one-time work from recurring review, and to name who is paid for each part: internal staff, the external provider, your tooling vendors or the certification body.
How DeployOpen scopes and prepares A.8.18 evidence
DeployOpen helps organizations prepare the systems, restrictions and records that A.8.18 Use of privileged utility programs calls for. The organization keeps ownership of its controls and decides which utilities are permitted, while DeployOpen builds, documents and hands over the technical evidence for the auditor to review.
How we scope
- Engagements are fixed-scope, with the utilities, hosts and environments covered agreed in writing before work starts.
- The written scope lists which privileged utilities are in use, which systems they can reach and which will be removed.
- Scope also names the owner who approves each permitted utility and the access review cadence the organization will run.
How we build
- We inventory utility programs that can override system and application controls across the agreed endpoints and servers.
- We configure restricted use with authorization, logging and separation from application accounts, based on the organization's own policy.
- We set up Wazuh Security Configuration Assessment or Fleet policies to check that unneeded utilities stay removed and that failing devices are flagged.
How we hand over
- We deliver the utility inventory, approved-utility list, removal records and configuration documentation as versioned files.
- We document how each control is tested, which logs prove restricted use and how an assessor can reproduce the checks.
- We walk the organization's owners through the evidence so they can answer auditor questions about their own controls.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
- Retainers can cover periodic re-running of utility checks and updates to policy when new utilities appear on hosts.
- Confirm with the certification body which evidence format and sampling it expects before the engagement closes.
