Application control maturity level 2 requirements

What application control at ML2 asks your organization to prove

To reach Maturity Level Two for application control, your organization must show an assessor that only approved executables run across the estate, and that this now includes internet-facing servers. The ISM Essential Eight baseline adds this requirement under ISM-1490, which extends application control to internet-facing servers, and ISM-1871, which extends it to every file system location except user profiles and temporary folders. In practice, the assessor will ask for the approved set, the enforcement scope and proof that enforcement works on the systems that are most exposed to attack.

The reason for the stricter bar is simple. A server that accepts traffic from the internet is the place an attacker most wants to run unapproved code, usually after exploiting a web application or a remote service. A workstation-only rule set leaves that path open. ML2 also adds ISM-1544, which requires Microsoft's recommended application blocklist to be implemented, and ISM-1582, which requires rulesets to be validated at least annually. Your team should confirm which blocklist version it applies, who signs off on each ruleset change, and where the validation record is kept.

What usually makes this hard is the estate itself. Legacy servers may run software that the vendor has not certified for enforcement, so you will need an exception process with named owners and expiry dates. Application data, build outputs and vendor tools often sit in file locations nobody has inventoried, which breaks the 'all locations' requirement. Finally, ISM-1660 requires allowed and blocked events to be centrally logged, and ISM-1815 requires those logs to be protected from modification and deletion. Before you enable enforcement, ask how many events per day you expect, where they will be stored and who reviews them, because ISM-1906 and ISM-1228 also expect timely analysis.

Which systems, locations and teams fall inside ML2 scope

Application control at ML2 widens the set of systems and file locations that must be controlled, and it adds ownership questions that ML1 workstation work never raised. The cards below cover the decisions that most change effort, from server exposure and file system locations to the teams that keep rulesets, logs and the Microsoft blocklist current.

Internet-facing servers

ML2 requires application control on internet-facing servers, so the first scoping task is an inventory of which servers accept traffic from outside the organization. Include reverse proxies, VPN concentrators that host services, public APIs and hosts in demilitarized zones. Confirm the list against external scan results and firewall rules, not only the configuration management database, because undocumented public endpoints are common.

Internal servers and their owners

Internal servers are not explicitly named in the ML2 addition for internet-facing hosts, but the requirement to cover all file system locations still applies to them. Decide whether internal servers join the ruleset at ML2 or wait for the ML3 expansion, document that decision, and record which business owner accepted the risk. Confirm the interpretation with your assessor before rollout.

File system locations beyond user profiles

ML2 extends control to every location except user profiles and temporary folders. In practice this means program directories, system folders, shared data volumes and application install paths. Map each location to the software it holds, then test whether vendor updaters, backup agents and monitoring tools write executables into those paths, since those writes will be blocked or create exceptions.

Workstations already covered at ML1

Workstations were scoped at ML1, so ML2 work on endpoints is mostly about extending the existing ruleset to new locations and validating it. Check that the ML1 policy still holds for user profiles and temporary folders, and that any ML1 exceptions were reviewed. Overlap is where ownership gaps appear, because the same policy engine often serves both levels.

Ruleset owners and change approval

Someone must own each ruleset, approve changes and run the annual validation that ML2 requires. In most organizations this is shared between endpoint engineering, server operations and the security team that reviews exceptions. Define who approves a new publisher rule, who signs off on the annual review and who can grant emergency exceptions, and keep that record for assessors.

Logging and blocklist ownership

Central logging of allowed and blocked events and the Microsoft recommended blocklist usually sit with different teams than the rulesets themselves. Assign a named owner to the log pipeline, its retention and its alerting, and a separate owner to track blocklist updates. Ask any managed service provider whether it operates these functions, who holds administrative access to the logs, and how changes are recorded.

Third-party and managed hosts

Confirm with each third-party or managed hosting provider whether it operates the servers in your ML2 scope, who can change their application control settings, and whether it will share allowed and blocked event data with you. Contract terms should state these responsibilities before scope is fixed, since you may still own the control while the provider controls the host.

How ML2 builds on the ML1 workstation baseline

Maturity Level Two keeps everything Maturity Level One asks for on workstations and adds five tagged controls to the application control baseline. The first two widen the scope: application control must extend to internet-facing servers (ISM-1490), and it must cover every file system location except user profiles and temporary folders (ISM-1871). The next two tighten what the ruleset contains and how long it stays valid: Microsoft's recommended application blocklist must be implemented (ISM-1544), and the rulesets must be validated at least annually (ISM-1582). The fifth control, central logging of allowed and blocked application control events (ISM-1660), is the one that turns a working ruleset into evidence an assessor can inspect.

The practical decision at ML2 is how far the ML1 ruleset stretches. Teams that wrote rules only for user workstations will need to inventory what runs on internet-facing servers and in program folders, system locations and other paths that ML1 excluded. Confirm the exact control wording and the tags against the ISM OSCAL catalog before you map your own evidence to it, since the tagging is what determines which controls a profile pulls in. Your assessor will also expect the allowed and blocked event records to be retained and protected, which connects this control to the logging controls ML2 requires elsewhere.

ML2 work carries forward. ML3 replaces the ML2 scope for non-internet-facing servers and adds driver control, so rules, inventories and logs built at ML2 are the starting point for that step, not something to discard. Plan the ML2 ruleset so that server and driver rules can be added without rewriting the workstation policy. The annual validation requirement also becomes a recurring task you should budget for from the start, because a ruleset that was accurate at the first assessment will drift as software and servers change.

How an assessor tests application control maturity level 2

This table walks through the ML2 application control requirements one at a time, showing how an assessor tests each, the evidence requested and the findings that appear most often. Read it as a test plan: each row is a question the assessor will try to answer with documents and sampled systems. The main takeaway is that ML2 testing is largely about proving coverage (every server, every location, every blocked event) rather than proving that a ruleset exists.

Control and title	Assessor test approach	Evidence requested	Common findings
ISM-1490: Application control on internet-facing servers	Identify all internet-facing servers from the asset inventory and firewall or load balancer records, then sample several and confirm the enforcement mode is active on each.	Asset inventory extract, application control policy assignment per server, enforcement status exports.	Internet-facing servers missing from the inventory, or servers in audit-only mode presented as enforced.
ISM-1871: Application control across all locations except user profiles and temporary folders	Review the rule scope, then check that rules cover program directories and other file system locations, and confirm that user profile and temporary folder exclusions are the only gaps.	Exported ruleset with path conditions, documented exclusion rationale, test results showing execution attempts from covered paths.	Broad path exceptions (such as writable directories) that quietly undermine coverage, or undocumented exclusions.
ISM-1544: Microsoft's recommended application blocklist implemented	Compare the deployed blocklist against the version Microsoft currently publishes, and test a sample of listed applications to confirm they cannot run.	Blocklist version or rule set identifier, deployment record, test execution showing a blocked listed application.	Blocklist imported once and never updated, or deployed to a subset of endpoints without explanation.
ISM-1582: Rulesets validated at least annually	Confirm the most recent validation date, read the validation record, and check that it covers current rules and the current fleet rather than the original baseline.	Dated validation records, sign-off by the control owner, change log linking validation to rule updates.	No validation record at all, or a validation dated more than a year before the assessment.
ISM-1660: Allowed and blocked events centrally logged	Select a block event on a sampled endpoint and trace it into the central log store. Repeat for an allowed event, then confirm both fields and timestamps are complete.	Log source configuration, sample events from the central store, retention settings for application control logs.	Events logged locally only, missing allowed events, or gaps in timestamps and hostnames that prevent tracing.
ISM-1815: Event logs protected from modification and deletion (ML2 and ML3 baseline)	Review access permissions on the log store and test whether a standard administrator can alter or delete recent entries.	Access control lists for log storage, integrity or immutability settings, administrator access reviews.	Logs stored on a writable share, or administrators holding delete rights they do not need.
ISM-1906 and ISM-1228: Event logs analyzed and detected events handled in a timely manner (ML2 and ML3 baseline)	Ask how application control blocks reach an analyst, then review a sample of recent blocks and the follow-up tickets or triage notes.	Alert rules or queries for blocked executions, triage records, escalation evidence.	Blocks collected but never reviewed, or review that exists only as an informal habit with no record.

Sequence for implementing ML2 application control

This sequence moves an organization from workstation-only application control to Maturity Level Two coverage across internet-facing servers and every file system location except user profiles and temporary folders. Each step ends with a named output, so the evidence pack builds up as the work progresses.

Inventory servers and file system locations
The platform or infrastructure team lists every server, separating internet-facing servers (ISM-1490) from other servers, and records the file system locations that application control must cover under ISM-1871. Exclusions are limited to user profiles and temporary folders, so the scope list should show each location and whether it is in or out. Done means a signed-off scope register that names each host, its exposure, its owner and the locations in scope. Confirm the approach with your ML2 assessor before you rely on the exclusions.
Run audit mode and collect execution data
Deploy the chosen application control technology in a mode that records what would be blocked without blocking it. Let it run across representative hosts for long enough to capture normal patching, batch jobs and administrative tasks. The security engineer exports the execution records and groups them by publisher, path and hash. Done means a dataset that shows every executable, library, script and installer observed in each in-scope location, which becomes the input for ruleset design.
Build and approve rulesets per location
Build separate rulesets for each in-scope location and for each server class, so that an internet-facing web server does not inherit rules written for a file server. The system owner approves each allowed item, and the approver records the business reason. Rules should prefer publisher or signed-hash conditions over bare paths where the platform supports it. Done means approved rulesets, each with a named owner and a recorded approval, and a list of exceptions with expiry review dates.
Apply Microsoft's recommended blocklist
Import Microsoft's recommended application blocklist as a base layer under the approved rulesets, as ISM-1544 requires. Test the combined policy in audit mode first so that the team can find legitimate business software that the blocklist catches. Resolve each conflict through the approval process, not by removing the blocklist entry silently. Done means a documented blocklist version applied to every in-scope host, and a record of each exception granted or refused.
Route allowed and blocked events to central logging
Forward allowed and blocked application control events from every in-scope host to a central log store, as ISM-1660 requires. Protect those logs from unauthorized change or deletion (ISM-1815), and confirm that the analysis process picks up events from internet-facing servers and detected cyber security events in a timely way (ISM-1906, ISM-1228). Test the pipeline by triggering a known block on a sample host and checking that it arrives centrally. Done means a dated test record and a log retention configuration that the assessor can inspect.
Set the annual ruleset validation cycle
Schedule a validation of every ruleset against current systems, approved software and the blocklist at least once a year, as ISM-1582 requires. The validation compares live rules with the approved register, removes rules for retired software and checks that exceptions are still within their review dates. Assign a named owner and record the outcome of each run. Done means a calendar entry, a validation procedure and the first completed validation record, filed in the evidence pack.
Close out the ML2 evidence pack
Assemble the outputs from each earlier step into a single evidence pack: the scope register, the execution dataset summary, the approved rulesets with approvals, the blocklist record, the logging test and the first validation record. Map each item to the ISM control IDs it supports, using ASD's ISM OSCAL profiles to check coverage. An independent assessor reviews the pack and issues any conclusions; DeployOpen and the internal team prepare the pack but do not certify it. Done means a complete, versioned pack that the organization owns and can present for assessment.

Evidence that passes application control maturity level 2

An assessor testing application control at ML2 looks for records that show the ruleset, its scope, its blocklist and its validation all match what the organization says it runs. The cards below cover the artifacts that tie those records together, and a note on keeping each one current between assessments.

Approved ruleset with version history

This is the list of executables, libraries, scripts and installers the organization permits, exported from the application control policy with a version number and change record for every edit. An assessor compares the ruleset against what is actually enforced on sampled servers and workstations. Check that each rule has an owner and a business reason, and that removed rules are kept in history so you can show when an application stopped being allowed. Confirm the export includes the enforcement mode for every scope.

Scope register for servers and locations

The scope register records every internet-facing server where application control is enforced, and every file system location covered outside user profiles and temporary folders. ML2 extends enforcement to internet-facing servers, so this register is the first thing an assessor checks against your asset inventory. Reconcile it against cloud account listings and configuration management data, since servers added after the last review are a common gap.

Proof the Microsoft blocklist is applied

ML2 requires Microsoft's recommended application blocklist to be implemented, so keep the policy file or configuration output that shows the blocklist rules are present and enforced on each in-scope host. Pair it with a sample of blocked-event entries that show the rules are firing. Record the blocklist version you imported and the date, because Microsoft updates it and an assessor will ask whether your copy is current.

Dated annual validation record with sign-off

ISM-1582 expects application control rulesets to be validated at least annually. The validation record should state the date, the ruleset version tested, the people who reviewed it, the rules removed or added, and the approver who signed off. Keep the record separate from the ruleset itself so an assessor can see that validation happened on a schedule rather than only when someone updated a rule. A validation record without a named approver is usually treated as incomplete.

Central logs of allowed and blocked events

ISM-1660 requires allowed and blocked application control events to be centrally logged. Export a dated sample of both event types from the central log store, showing host name, file path, publisher or hash and the rule that matched. ISM-1815 adds that these logs must be protected from unauthorized modification and deletion, so show the access controls and retention settings on the log store. Ask your implementation partner to confirm which logs the platform can capture before you promise them to an assessor.

What meeting ML2 application control costs in money and effort

This table lists each cost component of meeting ML2 application control, who is paid for it, whether it is one-time or recurring, and what drives it up. Read it as a checklist for a quote: ask the implementation partner to price each row separately, and note where self-hosted open-source tooling removes licence spend but not engineering or assessment effort. The main takeaway is that ongoing effort, not tooling, usually dominates the total cost.

Cost component	Who is paid	One-time or recurring	What drives it
Application control tooling or licences	Software vendor, or none if self-hosted open source is chosen	Recurring if commercial licences apply; none for open-source platforms	Number of endpoints and servers in scope, and whether vendor support is bought
Ruleset design and server onboarding engineering	Internal engineers or an implementation partner under a fixed-scope agreement	One-time for the initial build, then recurring for each new server or location	Server count, number of file system locations outside user profiles and temporary folders, and application diversity
Microsoft recommended blocklist and internet-facing server rules	Internal engineers or implementation partner	One-time to implement, recurring when Microsoft updates the blocklist	Number of internet-facing servers (ISM-1490) and the rate of blocklist changes
Central logging of allowed and blocked events	Log platform operator, internal team or managed service	Recurring for storage, retention and analysis	Log volume per host, retention period and whether events are protected from modification and deletion
Log storage, retention and protection	Infrastructure team or cloud provider	Recurring	Event volume, retention requirements set by the organization, and tamper-protection design
Annual ruleset validation (ISM-1582)	Internal security or engineering staff, or external reviewer	Recurring, at least once a year	Ruleset size, number of distinct rule sets, and how many exceptions have accumulated
Change handling for new applications and updates	Internal change board and engineers	Recurring	Frequency of software releases and the approval workflow for new allowed applications
External review and auditor sampling	Independent assessor or auditor, who issues any report	Recurring at each assessment cycle	Sample size the assessor selects, the number of evidence artifacts, and how well logs and rulesets are already organized

Self-hosted tools that support the ML2 evidence

Maturity Level Two asks for application control to be enforced, validated and logged, so the evidence must show what ran, what was blocked and whether the ruleset still matches the approved set. The four tools below can collect and check configuration, device state and forensic artifacts, but none is named in the supplied facts as an application control enforcement tool, so each needs to be confirmed against the application control design.

Wazuh configuration assessment

Wazuh Security Configuration Assessment scans monitored endpoints against YAML policies, most of them based on CIS benchmarks, and checks files, directories, registry keys and running processes. It can help show that hardening settings tied to application control are in place and drifting nowhere, and it recommends remediation for failed checks. Confirm whether any of its checks read the application control policy state itself, such as WDAC or AppLocker settings on Windows, or whether you must write custom policies to test that state. License: GPL-2.0-only.

Fleet policies for device checks

Fleet policies are yes or no questions asked of devices as osquery queries, and the policies page shows which devices in each fleet pass or fail. A policy can ask whether an application control agent is running or whether an approved-only rule is present, which gives the assessor a per-device pass rate. Confirm that the policy query you write returns the enforcement state rather than just the presence of the software. License: MIT.

osquery scheduled fleet queries

osquery exposes running processes, loaded kernel modules, file hashes and open network connections as SQL tables, and its osqueryd daemon runs scheduled queries across a fleet. Scheduled process and hash queries can record what executed on each host over time, which is the raw material for reviewing allowed and blocked activity. Confirm that your application control tool writes events to a location osquery can read, and how long results are retained in your logging pipeline. License: Apache-2.0 OR GPL-2.0-only.

Velociraptor hunts across systems

Velociraptor collects forensic artifacts defined in VQL from endpoints and runs hunts that gather one or more artifacts across a group of systems. Offline machines are scheduled to collect when they reconnect, and each hunt gets a notebook for combined analysis. This helps when an assessor asks for evidence that blocked executions across the fleet were reviewed, or when an incident needs a sweep for an unapproved binary. Confirm that your artifacts cover the application control event sources you use. License: AGPL-3.0-only.

Who owns, implements and audits ML2 application control

The organization owns Essential Eight maturity. Accountability for application control at ML2 sits with the people who run the environment and answer for it: the CISO or security lead, the IT and endpoint owners, and the business owners who approve software. The ASD maturity model is evidenced by how the organization operates the control, so no partner can take ownership of the outcome on its behalf.

Approval decisions: Someone accountable must decide which applications, publishers and installers are permitted, and record the basis for each decision.
Exception handling: The organization decides who may request an exception to the ruleset and how those requests are reviewed and closed.
Annual ruleset validation: The organization must validate application control rulesets at least annually (ISM-1582), and that review must be run and recorded by internal staff.
Incident response: Blocked-event alerts and incidents feed the organization's incident process, which must report to the CISO and to ASD where required (ISM-0123, ISM-0140).
Retained evidence: The organization keeps the logs, change records and validation outputs that an assessor will sample.

Confirm with your own assessor which of these records they expect in what format, and who must sign off each one.

Where ML2 application control usually falls short

Most Maturity Level Two application control programs fail at the edges: servers nobody remembered, rulesets that drift past their annual check, and logs that sit only on the machine that produced them. Each card below names one gap, what it looks like in practice, and how to close it before an assessor finds it.

Internet-facing servers left out

ML2 extends application control to internet-facing servers (ISM-1490), and these are often the first machines skipped because they are managed by a different team or built from older images. Build an inventory from DNS records, load balancer pools and firewall rules, then compare it against the devices your application control tool reports as enforcing. Any internet-facing host that is missing from the enforcing list is a finding. Confirm the rule set on each one, not just the agent install.

Locations outside user profiles

ISM-1871 requires application control across all file system locations except user profiles and temporary folders. Teams often enforce only Program Files and System32, leaving application data directories, custom install paths and network shares open to unapproved binaries. Walk the file system for executable content and document each path either as covered or as an explicit, approved exclusion. A path that nobody can explain is the one an assessor will test.

Microsoft blocklist applied to workstations only

ISM-1544 requires Microsoft's recommended application blocklist, and it is easy to deploy it to the workstation policy and forget the server policy. Compare the effective blocklist on a sample of workstations and servers, and confirm the policy version matches Microsoft's current list. Record which blocklist version is in force and when it was last updated, because the assessor will ask for both.

Rulesets past their annual date

ISM-1582 requires application control rulesets to be validated at least annually. In practice, rulesets change through emergency exceptions and software updates, and the validation record stops at the last scheduled review. Set a recurring calendar entry tied to a named owner, and keep a dated record of each validation showing who reviewed which rules and what changed. A ruleset with no validation record for the past twelve months fails this control regardless of how well it blocks.

Allowed and blocked events kept locally

ISM-1660 requires allowed and blocked application control events to be centrally logged, yet many deployments keep events in the local event log of each endpoint. Forward both allowed and blocked events to a central log platform, such as a self-hosted SIEM, and confirm that a test block on a sample host appears there within your normal ingestion window. Check that the forwarded events carry the host name and the file hash so an investigator can trace them.

Logs alterable by local administrators

Central forwarding alone does not satisfy the protection expectation in ISM-1815, which requires event logs to be protected from unauthorised modification and deletion. If local administrators can clear the endpoint log or stop the forwarder, the record can be lost during an incident. Restrict who can change the logging configuration, alert on forwarder stops and log clearing, and store copies in write-once or access-restricted storage. Test this by attempting to clear the log as a local administrator and confirming the central copy survives.

Common questions about application control maturity level 2

How much more effort does maturity level 2 add over level 1 for application control?

ML2 adds scope rather than a different control type. Level 1 covers workstation user profiles and temporary folders. Level 2 extends application control to internet-facing servers and to all file system locations other than user profiles and temporary folders, and it adds Microsoft's recommended application blocklist, an annual ruleset validation and central logging of allowed and blocked events. The added effort is driven by how many servers and locations you must cover, how many rules you must maintain, and how far your logging pipeline must reach. Ask any partner to size the work by asset count and rule volume in a written scope, and confirm your own inventory before accepting a quote.

Can an internal team implement application control at level 2 without outside help?

Often yes, if the team already runs endpoint management, change control and central logging. The work requires people who can build and maintain allowlist rules, test changes against business software, and read and act on blocked-event logs. Teams without those skills, or without spare capacity during rollout, usually bring in an implementation partner for part of the work. A partner prepares the configuration, logging and evidence; the organization still owns its controls and decides which applications are approved. Confirm your internal skills and staffing before deciding how much to outsource.

How long does application control at maturity level 2 take to implement?

No duration applies to every environment, so treat any single number with caution. The timeline depends mostly on the size and variety of your server estate, how much legacy or vendor software must be approved, how many change windows you have, and whether central logging already exists. Rollout usually moves faster when you start in audit or monitoring mode and tighten rules gradually. Ask for a phased plan in the written scope, with milestones tied to server groups, and confirm the blocklist and logging steps against your own change calendar.

What does the level 2 work require from our staff?

Your staff must own the decisions that an outside party cannot make for you: which applications are business-approved, who signs off rule exceptions, and how emergency changes are handled. Operationally, you need server administrators who can test updates, security staff who review blocked events, and an owner for the annual ruleset validation. Expect recurring effort for rule changes, exception reviews and log triage, not only a one-time build. Confirm named owners and a review cadence before work starts.

What will an auditor sample when testing application control at level 2?

An assessor typically samples evidence rather than reviewing everything. Expect requests for the defined application control scope, showing that internet-facing servers and non-excluded file locations are covered; the rulesets in force and records of their annual validation; evidence that Microsoft's recommended blocklist is applied; and samples of allowed and blocked events collected in your central log store. They may also ask how exceptions are approved and how log integrity is protected. Only an independent assessor decides whether the evidence is sufficient. Ask your assessor early which samples they expect so you can export them consistently.

Can we apply Microsoft's recommended application blocklist in our environment?

Usually, but confirm it before you commit to a rollout plan. The requirement is that Microsoft's recommended application blocklist is implemented, and the practical question is whether blocking the listed applications breaks anything you depend on. Check the blocklist against your inventory, test it in a non-production group, and document any exception with a business owner and review date. Confirm the current blocklist version and its deployment method with Microsoft's own guidance for your Windows and Intune or Group Policy setup, since those details are outside the scope of this page.

When is an implementation partner worth hiring for level 2?

A partner is worth considering when your team lacks application control experience, when the server estate is large or inconsistent, or when a regulator, customer or certification timeline makes internal capacity the bottleneck. Under a fixed-scope engagement, DeployOpen would plan, configure, document and test the controls and prepare evidence in your own cloud accounts, data centers or air-gapped networks. DeployOpen does not issue audit reports or certifications; an independent auditor does. Ask any firm for a written scope listing deliverables, responsibilities, and what stays with your staff, then compare that against your internal capacity.

How DeployOpen scopes and prepares ML2 application control evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so application control at Maturity Level Two is built where your systems run. We prepare the systems, controls and evidence for your assessor, while your organization keeps ownership of its controls and any report or decision on maturity.

How we scope

Confirm which internet-facing servers and file system locations fall under application control at ML2.
Record how the Microsoft recommended blocklist and annual ruleset validation will be applied and owned.
Agree in writing which logging sources feed central collection of allowed and blocked events.

How we build

Configure application control rulesets for internet-facing servers and all locations outside user profiles and temporary folders.
Deploy the recommended blocklist and test rule changes against representative hosts before rollout.
Set up central collection of allowed and blocked events, with protected log storage against unauthorized change or deletion.

How we hand over

Document each ruleset, its owner, its validation date and the process for annual revalidation.
Provide evidence packs mapping ML2 application control requirements to configurations, logs and test results.
Deliver runbooks so your team can review blocked events, handle exceptions and repeat validation without us.

How we support

Offer ongoing support and upgrades as a retainer after handover, if your organization wants it.
Re-run ruleset validation and log review on a schedule agreed in the written scope.
Confirm with your independent assessor which evidence they need before the assessment begins.