Application control maturity level 3: what the requirement asks for
If an assessor or board asks for proof that only approved code runs on your servers and drivers, Maturity Level Three is the level that answers it. At ML3, application control must extend to non-internet-facing servers, so workstations and all servers are covered (ISM-1656). It also adds two driver requirements: execution of drivers must be restricted to an organisation-approved set (ISM-1658), and Microsoft's vulnerable driver blocklist must be implemented (ISM-1659). Those three controls are the ML3 additions to the ML2 baseline, and they are the ones your evidence must show.
The risk behind these controls is privilege escalation. An attacker who already has a foothold on a server often looks for a way into kernel-level code. A signed but vulnerable driver can be loaded and abused to disable protections or gain system privileges, and an unapproved binary on a server can run without anyone noticing. Blocking execution on servers that are not exposed to the internet closes a path that internet-facing rules alone do not cover, and the driver controls address a class of abuse that normal executable rules can miss.
The hard part is usually inventory and dependencies, not the policy itself. Many organisations cannot yet list every server, its role and its installed software, so the ruleset is built on an incomplete picture. Legacy line-of-business applications often ship unsigned installers, self-updating components or drivers from vendors who no longer publish updates, and blocking them can break production. Confirm with your application owners which drivers and binaries each server needs before enforcement, and confirm with your Microsoft guidance and ASD's ISM which blocklist version and enforcement mode apply to your environment.
Which servers, drivers and teams fall inside ML3 application control
Maturity Level Three widens application control from workstations to every non-internet-facing server and to the drivers that load into them. The cards below cover the scoping decisions that determine how much work lands on each team and what evidence an assessor will ask to see.
Non-internet-facing servers
ISM-1656 extends application control to non-internet-facing servers, so at ML3 the rule set covers workstations and all servers. Build an inventory from your CMDB, directory and cloud accounts, then tag each host by role and exposure. Internet-facing servers already sit under ML2 rules, so the new work is the internal estate: file servers, application back ends, database hosts and build agents. Ask who owns each host's allowlist and how changes are approved.
Workstations carried over from ML1
Workstations are not new at ML3, but the ML1 and ML2 rules must remain in force and be evidenced alongside server rules. Confirm that workstation policies were not weakened when server policies were written, and that user profile and temporary folder restrictions still apply. An assessor will expect one consistent evidence trail across both populations rather than separate spreadsheets for each.
Domain controllers and management hosts
Domain controllers, privileged access workstations and management hosts carry the highest impact if compromised, so they need the strictest execution rules and the most restrictive exceptions. Keep their allowlists short, document every administrative tool that runs on them, and separate build pipelines from production execution paths. Ask whether any management agent runs with elevated rights and who signs off its inclusion.
Driver execution and the approved driver set
ISM-1658 requires that driver execution be restricted to an organisation-approved set, which means a driver inventory is a required artifact, not an optional one. List every kernel and filter driver on each host class, including storage, network, endpoint security and virtualization drivers. Record the vendor, version and signing certificate for each. Expect driver updates to trigger a new approval cycle.
Vulnerable driver blocklist
ISM-1659 requires that Microsoft's vulnerable driver blocklist be implemented, which is distinct from approving drivers you already run. Confirm how the blocklist is enforced on each Windows host class, and check whether any approved driver appears on it before it reaches production. Keep a record of exceptions, the business reason for each and the review date, because an assessor will test whether the blocklist is active rather than merely present.
Vendors whose agents must be approved
Endpoint protection, backup, monitoring and remote management agents all execute code on servers, so each vendor's binaries, drivers and updaters need approval before application control is enforced. Map every vendor to the teams that deploy and support its agent, and agree in writing who approves updates. Ask vendors for signed file publisher details and update channels, because unapproved auto-updates are a common cause of blocked security tooling.
How an assessor tests ML3 application control
This table sets out, for each of the three ML3 application control requirements, what the assessor samples, what evidence they request and where implementations usually fall short. Read it as a checklist for your own pre-assessment review, and confirm the exact control wording in ASD's ISM catalog before relying on any interpretation.
| Requirement | What the assessor tests | Evidence requested | Common findings |
|---|---|---|---|
| ISM-1656: server coverage | Selects a sample of non-internet-facing servers and workstations, then confirms application control is enforced on each rather than only on a template or pilot group | Current enforcement policy export, the asset inventory the policy is deployed against, and deployment reports showing enforcement mode per host | Servers missing from the policy scope, test or lab servers excluded without a documented decision, or policies deployed but never switched to enforce mode |
| ISM-1656: inventory reconciliation | Compares the enforced policy scope against the asset inventory to find hosts that appear in one but not the other | Asset register with server roles, the scope definition for each application control policy and the reconciliation output | Inventory drift after new servers are built, decommissioned hosts still listed, and no owner for servers added outside the standard build |
| ISM-1658: approved driver set | Checks that driver execution is restricted to a defined, approved list and that the list has an owner and review process | Approved driver list with version and publisher details, the rule set that enforces it, and records of approval for added drivers | Driver rules written as broad publisher allowances with no approval record, or drivers loaded on servers that are not on the approved set |
| ISM-1659: vulnerable driver blocklist | Confirms Microsoft's vulnerable driver blocklist is applied on the tested hosts and that blocking rules are active rather than audit-only | Policy configuration showing the blocklist is enabled, enforcement mode settings, and sample event records showing blocked driver loads | Blocklist present in the policy file but disabled in effect, audit mode left on after rollout, or blocklist updates not applied on older builds |
| ISM-1659: blocklist currency | Checks how the organization keeps the blocklist current and whether the update process is recorded | Update procedure, change records for blocklist updates and the date of the most recent applied version on each sampled host | No documented update cadence, updates applied to a reference image only, or hosts that have not received the latest blocklist |
| Logging of allowed and blocked events (ML3 event analysis) | Samples events from servers and workstations to confirm blocked executions and driver loads are logged and reviewed in a timely way | Event log exports for sampled hosts, review records and the alert or triage process for blocked events | Events collected only from internet-facing servers, no evidence of review, or logs retained for too short a period to show the sampled period |
| Exceptions and deviations | Reviews any approved exception to enforcement and tests whether it is time-limited and risk accepted by an owner | Exception register, risk acceptance records and the compensating controls applied to each exception | Open-ended exceptions with no expiry, exceptions granted to whole subnets, or exceptions that were never revisited after a change |
How to roll ML3 application control out across servers and drivers
This sequence moves an organization from partial application control to ML3 coverage of workstations, non-internet-facing servers and drivers. Each step produces a record that an assessor can test, so the rollout ends with evidence rather than only a configured policy.
Inventory servers and drivers in scope
Build a complete register of non-internet-facing servers, workstations and the drivers loaded on them. The asset owners confirm each entry and the platform team reconciles the list against the CMDB or endpoint inventory. Done means every server in scope has an owner, an operating system version and a named policy group, and the register is signed off by the system owner. Gaps found here usually point to unmanaged hosts that must be brought under management before any policy can cover them.
Build the approved driver set
Collect the driver files loaded on in-scope systems, record the hash, signer, version and the business reason each driver is needed, and then approve or remove each one. The security team and system owners agree the approved set, and the driver register becomes the input for the ISM-1658 rule. Osquery can help list loaded kernel modules and file hashes across hosts, so the register reflects what is actually running rather than what was installed. Done means every driver in the register has a recorded decision.
Deploy application control policy in audit mode
Apply the draft allow rules to servers and workstations in audit mode so that the platform logs what would have been blocked without stopping any process. Rules should cover executables, libraries, scripts and installers, and cover the non-internet-facing servers identified in step one, which is the ISM-1656 scope. Done means every in-scope host reports audit events to a central location and the team can query those events by host and policy group.
Resolve blocked legitimate software
Review the audit-mode exception log with application owners and decide, for each event, whether the software is legitimate, needs a new rule, or should not run. Record each decision with a justification, owner and date in the exception log, and update the allow rules only through change control. Done means the exception log has no unreviewed entries and every accepted exception traces to an approved change. Assessors typically look for this log as proof that the allow list was reasoned, not copied.
Enforce application control on servers and drivers
Move the policy from audit mode to enforcement in stages, starting with groups that have the fewest open exceptions and keeping a rollback plan for each group. The server operations team owns the change window and the platform team confirms that enforcement events match the approved register. Done means enforcement is active on every in-scope server and workstation, with driver execution limited to the approved set, and the change records show each group's cutover.
Apply the vulnerable driver blocklist
Implement Microsoft's vulnerable driver blocklist as required by ISM-1659, applying it through the same policy mechanism used for enforcement and recording the blocklist version in the configuration baseline. Confirm with the vendor how the blocklist is updated and who approves updates. Done means the blocklist is active on every in-scope Windows host and the version is recorded so that an assessor can see when it was applied.
Validate coverage and retain the evidence
Test a sample of servers and workstations to confirm that unapproved executables and drivers are blocked, that event logs reach central storage, and that the policy matches the register. Wazuh configuration assessment or Fleet policies can check that settings remain in place over time. Done means a validation report exists with test results, the evidence set is stored for the assessor, and the owner has accepted the residual exceptions in writing.
Why driver execution needs its own approved set
Driver execution needs its own approved set because a driver is not just another program. Drivers load into kernel context, where they run with the highest privilege on the operating system, so a single vulnerable driver can let an attacker disable security tooling or escalate to full control of a host. A driver can also carry a valid vendor signature and still be exploitable, because the signature proves who published the file, not that its code is safe. That is why ISM-1658 (restricting driver execution to an organisation-approved set) and ISM-1659 (implementing Microsoft's vulnerable driver blocklist) are separate concerns. One limits what the organisation trusts to load. The other blocks drivers already known to be abusable, even when they appear to be trusted.
The approved set differs from general executable allowlisting in what it is judged on. A general allowlist asks whether a file is an expected application for a user or role. A driver approval asks whether a specific build from a specific publisher should ever run in kernel context on your estate, and it usually needs a narrower rule than the application rule, often tied to hash or exact version rather than publisher alone. Confirm with your application control vendor and your platform team which rule types your enforcement tool supports for drivers before you commit to a design, since the available options differ by platform.
Maintain a driver register that records, for each approved driver, the vendor, the version, the file hash, a named owner and the business reason it runs. The owner is the person who will approve updates and retire the driver, and the business reason is what an assessor will ask you to defend. Review the register whenever a driver is updated, and check it against the vulnerable driver blocklist so that a newly listed driver is removed quickly. Ask your implementation partner to show how the register links to enforcement rules and to the evidence you will present at assessment.
Evidence that passes an ML3 application control assessment
An assessor testing application control at Maturity Level Three will look for proof that the enforced rules, the scope and the driver decisions match what the organization says it runs. The cards below cover the artifacts that show this, and the recurring checks that keep them accurate between assessments.
Enforced policy export
A current export of the policy actually enforced on each endpoint and server, not the draft policy in a change document. Assessors compare it against the approved rule set and check that enforcement mode is on rather than audit only. Ask the implementation team to export it from the enforcing host and record the date, the policy version and the hash of the file. Re-export after every policy change so the evidence never describes a ruleset that is no longer in force.
Server scope list reconciled to inventory
A list of every non-internet-facing server with application control enforced, matched against the asset inventory. ML3 extends coverage to these servers, so any server missing from the list is a gap an assessor will find by sampling the inventory. Reconcile the two sources on a schedule, record the differences and the owner who resolved each one, and treat a server built without enforcement as an open finding until it is covered.
Approved driver register
A register of every driver permitted to load, with its publisher, version, hash and the business reason for approval. ML3 requires driver execution to be limited to an approved set, so the register is the reference an assessor uses to test whether a loaded driver should be there. Review it when hardware, endpoint agents or firmware tools change, and keep retired drivers on record so historic events can be explained.
Vulnerable driver blocklist configuration
The configuration showing that Microsoft's vulnerable driver blocklist is applied, along with its version and the date it was last updated. Assessors check the setting itself and then test whether a known vulnerable driver is refused. Keep the configuration and its change history together, so each update to the blocklist has a ticket, a reviewer and a deployment date.
Exception approvals with expiry
Every exception to enforcement, including a temporary allowance for a vendor tool, with the risk owner who accepted it, the compensating control and an expiry date. Exceptions without an expiry are the most common reason an assessor treats the ruleset as unmanaged. Reconcile active exceptions at each review, and close any that have passed their date or whose underlying software has been removed.
Blocked execution event logs
Logs of blocked and audited executions collected centrally and retained for the period the assessment covers. ML3 extends timely event log analysis to workstations and non-internet-facing servers, so assessors look for evidence that blocked events are reviewed, not just stored. Keep a record of who reviewed each batch, what was found and which events became tickets, and confirm that the log source still reports from every host on the scope list.
What meeting ML3 application control costs in money and effort
This table breaks down the cost components of meeting Maturity Level Three application control, showing who is paid for each, whether it is one-time or recurring, and what pushes it up. No figures are given because none were supplied, so use the drivers column to scope a quote. The main takeaway is that server count, legacy software and driver diversity usually matter more than the tool choice.
| Cost component | One-time or recurring | What drives it up | What to ask for in a quote |
|---|---|---|---|
| Application control licensing or self-hosted build | Recurring if commercial, one-time setup if self-hosted | Number of endpoints and servers in scope, and whether the chosen platform charges per device | Itemized licence terms, renewal basis, and the labor included to deploy and maintain the self-hosted option |
| Policy design for non-internet-facing servers | One-time, with periodic revision | Number of distinct server roles, patch cycles, and how many applications each role runs | A per-role policy plan, the named engineers responsible, and the number of review rounds included |
| Exception handling and rule tuning | Recurring | Legacy software that cannot be signed, line-of-business applications with frequent updates, and vendor tooling that writes to unusual paths | How exception requests are logged, approved and expired, and the expected volume of rule changes per month |
| Driver inventory and approved driver set (ISM-1658) | One-time inventory, recurring review | Driver diversity across hardware generations, third-party storage and network drivers, and firmware-bundled drivers | Method used to inventory drivers on each host, the approval workflow, and who signs off each addition |
| Vulnerable driver blocklist implementation (ISM-1659) | One-time implementation, recurring updates | Number of hosts that depend on blocked drivers and the effort to replace or remove them | How the blocklist is applied and kept current, and how conflicts with approved drivers are resolved |
| Evidence upkeep for ML3 assessment | Recurring | Number of servers and workstations whose allow and block records must be retained and retrievable, and log retention settings | Evidence samples the provider will produce, the retention period proposed, and the format of exported records |
| Central event log analysis for servers and workstations (ISM-1907, ISM-0109) | Recurring | Log volume from newly covered workstations and non-internet-facing servers, and the alert triage workload | Expected log sources, storage sizing assumptions, and who reviews alerts and on what schedule |
| External review and independent assessor sampling | Recurring per assessment cycle | Number of sampled hosts, the depth of driver and policy testing, and the number of remediation rounds | Scope the reviewer will test, the sample basis, and whether remediation retesting is included |
Who does what: your team, a partner and the auditor
Your organization owns the application control decisions, because those decisions define what your business is allowed to run and who accepts the risk when something is blocked. Leadership and the security function should agree the approved set, the owners of each rule, and the rules for exceptions before any partner starts configuring anything. Ownership does not transfer to a partner, even when a partner does most of the hands-on work.
- Policy decisions: Approve which publishers, paths, drivers and file types are trusted, and document the reasoning.
- Exception approvals: Name who may approve a temporary exception, how long it lasts, and how it is reviewed and closed.
- Driver risk acceptance: Decide how drivers outside the approved set are handled, including business-critical hardware that the vendor has not yet signed.
- Asset and owner records: Keep the authoritative list of servers and workstations in scope and the team accountable for each.
- Ongoing review: Schedule the recurring ruleset validation and log review, and assign the people who sign off on them.
Before engaging anyone, confirm with your assessor which records they expect you to hold yourself, because those are the records they will not accept from a third party as your own decisions.
An implementation partner prepares the systems and evidence that the controls depend on. In practice this means turning your approved policy into enforceable rules, deploying them across the estate, testing them on representative systems, and assembling the records an assessor will ask for. DeployOpen works this way: it prepares systems, controls and evidence inside your environment, and it does not decide your policy or issue any assurance statement.
- Policy build: Draft the rule sets from your decisions, and show how each rule traces to the requirement it supports.
- Driver inventory: Collect and classify the drivers loaded across servers and workstations so the approved set can be drawn up from real data.
- Deployment and testing: Stage rules in audit mode, resolve legitimate blocks, then enforce, with a documented rollback path.
- Evidence packaging: Export configurations, deployment reports, blocked-event logs and change records in a form the assessor can sample.
- Handover: Train your staff to run the controls, so the partner's involvement can end without the evidence stopping.
Ask any partner to name the artifacts they will hand over at the end and who keeps administrative access after the engagement closes.
The independent assessor tests whether application control is implemented and working, then reports the result. The assessor must be separate from the people who built the controls, which is why a partner that prepared the evidence cannot also certify or attest to it. An assessor samples systems, reviews configuration and logs, and forms a view on whether the requirement is met. Only the assessor or the relevant certifying body issues any report or determination.
- Independence: The assessor should not design, configure or operate the controls they are testing.
- Sampling: Expect the assessor to pick servers and workstations, then check the rules applied to each one against your records.
- Driver testing: Expect questions on how the approved driver set was derived and how the vulnerable driver blocklist is kept current.
- Log review: Expect requests for allowed and blocked event records over a stated period.
- Reporting: The assessor writes the findings. Your partner does not write, edit or sign them.
Before engagement, confirm with the assessor what evidence format they accept and how they treat work performed by a partner they have not yet reviewed.
Where ML3 application control usually falls short
Application control at Maturity Level Three fails less often on the technology than on scope, governance and proof. The gaps below cluster around what is covered, what is left out, and whether the ruleset is still checked after go-live. Each card names the gap and the action that closes it.
Servers left out of scope
Many programs enforce application control on workstations and quietly exempt servers, often because a change window was missed or a legacy application broke. At ML3, ISM-1656 requires coverage of non-internet-facing servers as well as workstations. Check the enforcement scope against a current server inventory, and record each server that is not enforced along with a dated remediation plan and a named owner.
Drivers never inventoried
Driver execution is often treated as a Windows default rather than a managed set. ISM-1658 requires that driver execution be restricted to an organisation-approved set, which needs a list of the drivers actually loaded across the estate. Build that inventory from endpoints before writing rules, because drivers installed by hardware vendors, security agents and virtualization tools are the usual gaps.
Blocklist left in audit mode
ISM-1659 requires Microsoft's vulnerable driver blocklist to be implemented, and a blocklist that only logs provides no enforcement. Teams often leave it in audit mode after testing and never switch it to enforcement. Confirm the enforcement state on every device class, and retain the change record showing when audit mode ended and who approved it.
Exceptions that never expire
Temporary allow rules for a broken installer or a vendor tool tend to become permanent because nobody owns their removal. Every exception should have a business justification, an approver, and an expiry date that forces review. Ask for the exception register during assessment preparation and check for entries older than their stated review period.
No evidence of recurring validation
A ruleset that was correct at go-live drifts as software is installed, updated and retired. Without a scheduled review, the organisation cannot show that its allowed set still matches reality. Set a recurring validation task with a named owner, keep each review record, and compare the current allowed set against the blocked and allowed event logs that show what ran in practice.
Application control ML3: questions buyers ask before hiring help
How much more effort does application control at ML3 add over ML2?
ML3 adds effort mainly through scope and tighter rules, not through a new tool. The work grows in three places: application control must cover non-internet-facing servers (ISM-1656), driver execution must be restricted to an organisation-approved set (ISM-1658), and Microsoft's vulnerable driver blocklist must be implemented (ISM-1659). Each server class needs its own rule set, its own exception process and its own testing before enforcement, so the effort scales with the number of server builds rather than with the number of users. Driver inventory is often the longest task because drivers are easy to miss and are rarely documented per host. Ask any provider to break the ML3 effort down by server role, driver inventory and enforcement testing, and to show which of those they will do and which you will do.
Can our internal team implement ML3 application control without outside help?
Often yes, if the team already runs Windows application control on workstations at ML1 and ML2 and has someone who can read and write the policy rules. The gap is usually capacity and server knowledge, not tooling. Internal teams tend to struggle with three things: building an accurate inventory of every server and driver, running enforcement in audit mode long enough to catch legitimate software, and keeping the ruleset current after patches. Be honest about those three before deciding. An implementation partner can take on part of that work under a written scope, while your staff keep ownership of the policy, the exceptions and the decision to enforce.
How long does server inventory take for an estate of our size?
Inventory time depends on how many servers exist, how many distinct builds they run, and whether a configuration management database is current. A small estate with standard builds can be inventoried quickly because most servers share rules. A large estate with legacy builds, manual changes and unmanaged hosts takes longer because each outlier needs its own review. No duration is supplied for this work, so ask providers to estimate inventory against your server count, build families and CMDB quality, and to state what they assume about access to hosts. Request the inventory output format in the quote, since that artefact will be reused for rule design and for assessor review.
What does the client need to provide before a partner can start?
A partner needs read access to the server estate, the current application control policy for workstations, a list of approved software owners, and named people who can approve exceptions. It also needs a change window for enforcement and a way to roll back a blocked rule quickly. Driver and firmware details help, as does any existing endpoint or log platform that can report allowed and blocked events. Ask the partner to list these inputs in the written scope so that delays caused by missing access are visible early. Responsibilities for approving rules and accepting risk should stay with your organisation, not with the partner.
Can an implementation partner replace the independent assessor?
No. An implementation partner prepares the systems, rulesets and evidence, but only an independent assessor or auditor can test the control and report on it. The Essential Eight is a set of mitigations rather than a certification scheme, so there is no ASD certificate to issue, and maturity is judged through assessment of implementation and effectiveness. Your organisation owns the control and its evidence. A good partner will document how each ML3 requirement is met and will help you answer assessor questions, but the assessment conclusion belongs to the assessor you engage.
Which open-source tools can show that ML3 application control is working?
Open-source tools mainly produce the evidence that the control holds over time, not the enforcement itself. osquery can run scheduled queries across a fleet to report running processes, loaded kernel modules and file hashes, which helps confirm that drivers and executables match the approved set. Fleet policies can ask yes or no questions of devices and show which devices pass or fail each one, which suits recurring checks. Wazuh Security Configuration Assessment can check files, registry keys and processes against YAML policies and recommend remediation. Confirm each tool's coverage of the specific application control settings in your own environment before relying on it for evidence.
What should a quote for ML3 application control include?
A useful quote lists scope by server role, the driver inventory method, the enforcement plan including audit mode and rollback, the exception process, the handover of policy ownership, and the evidence pack delivered at the end. Separate one-time work, such as inventory and initial rule design, from recurring work, such as ruleset validation after patching and periodic review of exceptions. Ask what is excluded, for example vendor agreements, third-party driver testing or assessor fees. Fixed-scope engagements agree deliverables and timelines in writing before work starts, so ask for that written scope and check that each item maps to a named deliverable.
What causes ML3 application control rollouts to fail?
The most common failures come from enforcing rules before the inventory is complete, leaving drivers out of scope, and treating the first ruleset as permanent. Each of these produces outages or gaps that an assessor will notice. A second risk is weak exception handling, where temporary allowances become permanent and undocumented. Plan enforcement in stages, test each server role separately, and keep a tested rollback path. Ask any partner how they will detect a blocked legitimate process in production and how quickly the ruleset can be corrected under change control.
Using open-source tools to produce ML3 evidence
Open-source tools can generate much of the evidence an assessor will ask for against ML3 application control, but they produce evidence of state, not enforcement. The organization still needs its own application control mechanism blocking unapproved executables and drivers, and these tools show whether that mechanism is working across workstations and non-internet-facing servers. Treat each tool as a way to answer the question an assessor will ask, not as the control itself. For the driver requirements (ISM-1658 and ISM-1659), osquery is the most direct source. Its tables expose loaded kernel modules and file hashes, and the osqueryd daemon can schedule the same query across an entire fleet. A scheduled query that lists loaded drivers and compares their hashes with the approved set gives a dated, fleet-wide record. Fleet policies build on this: each policy is a yes or no question written as an osquery query, and the policies page shows which devices pass or fail. A policy such as "every loaded driver appears on the approved list" turns the query into a pass or fail result per host that an assessor can sample.
Wazuh Security Configuration Assessment covers a different kind of evidence. Its YAML policies, shipped mostly based on CIS benchmarks and extendable with custom policies, check files, directories, registry keys and running processes, and recommend remediation. That makes it useful for showing that the application control configuration on Windows endpoints and servers matches what the organization documented, including the paths and registry values the rules depend on. Velociraptor fills the remaining gap. Its hunts collect VQL artifacts across a group of systems, schedule offline machines to collect when they reconnect, and create a notebook per hunt. For ML3, a hunt can gather evidence from servers that were offline during the scheduled check, which matters when the assessor asks about the whole server population rather than the machines that happened to be online. Before relying on any of these tools, confirm three things in the client environment. First, confirm which component enforces execution and driver restrictions, because none of these tools blocks execution on its own. Second, confirm the licence position for each tool with legal counsel: osquery is offered under Apache-2.0 OR GPL-2.0-only, Wazuh under GPL-2.0-only, Velociraptor under AGPL-3.0-only and Fleet under MIT, and the obligations differ when the tool is modified or exposed to users over a network. Third, confirm with the assessor, before the assessment, which evidence format and retention period they will accept, so that query results and hunt outputs are kept in a form they can review.
How DeployOpen works on this
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, including the application control work needed for Maturity Level Three. We prepare the systems and evidence for your assessment, while your organization owns the controls and an independent assessor reaches the conclusion.
How we scope
- Agree in writing which workstations, non-internet-facing servers and driver execution points fall inside the ML3 application control boundary.
- Record which ISM controls for application control (ISM-1656, ISM-1658, ISM-1659) apply to each system group, and which owner is responsible.
- Confirm which vendor blocklists, driver sets and approved file types your environment already enforces, and where gaps remain before work starts.
How we build
- Extend the approved execution policy to non-internet-facing servers and workstations, with separate rules for drivers and their approved set.
- Deploy Microsoft's vulnerable driver blocklist through your existing management tooling, and test that blocked drivers fail to load on pilot hosts.
- Configure timely event log analysis for servers and workstations, the additional logging ML3 expects beyond the internet-facing servers covered at ML2.
How we hand over
- Deliver configuration records, rule documentation and test results that show each ML3 application control requirement operating as designed.
- Provide evidence packs mapped to ISM control IDs so your assessor can trace each requirement to a system, a setting and a log.
- Hand over runbooks for change approval, exception handling and rule updates, with named roles for your staff to operate the controls after engagement.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, if your team wants help keeping rules current.
- Review driver and blocklist updates on a schedule agreed in the written scope, so changes are tested before they reach production.
- Ask your assessor to confirm the evidence format and sampling approach early, so remediation work is directed at the gaps they will actually test.
