ASD Essential Eight: What Each Control Actually Requires (and What Counts as Evidence)
The ASD Essential Eight Maturity Model is the most widely referenced baseline security framework in Australia. Most organisations that work toward Essential Eight compliance understand what the controls are. The difficulty is not understanding what the controls say. The difficulty is knowing what evidence satisfies an assessor at each maturity level, and why some organisations with apparently strong controls still fail assessments.
This article goes control by control through what each one actually requires at Maturity Level 2, the most common target for Australian government agencies and regulated entities, and describes what acceptable evidence looks like in practice.
Patch Applications and Patch Operating Systems
These two controls share a structure but assess different asset classes. At Maturity Level 2, the requirement is that internet-facing services are patched within 48 hours of a patch being released for a critical vulnerability, and all other assets are patched within two weeks. The critical word is "critical" as defined by the vendor, not by internal risk appetite.
Evidence that works includes automated patch scan reports showing CVE identifiers, patch dates, and asset scope, exported from your vulnerability management tooling. Manual screenshots do not meet the bar at Level 2. You need a dated scan, a defined asset register that matches the scan scope, and a process document describing your patch cadence and exception handling. Assessors will look at whether the asset register and the scan results align. Gaps between the two are findings.
Application Control and Restricting Microsoft Office Macros
Application control at Maturity Level 2 requires that only approved applications can execute from user profiles and temporary directories. The evidence challenge here is that many organisations implement application control on standard workstations but have undocumented exceptions for developer environments or legacy systems. Those exceptions must be logged and approved to survive assessment.
For macro controls, the requirement at Level 2 is that macros are disabled for users who do not need them and that only macros from trusted locations or with valid digital signatures can run. Evidence includes Group Policy Object exports, configuration baseline reports, and a list of documented exceptions. A statement that macros are disabled without supporting configuration export is not sufficient. Assessors expect to see the policy in a form that demonstrates it is enforced, not just documented.
User Application Hardening and Restricting Administrative Privileges
User application hardening at Level 2 requires that web browser settings block ads and web content from unblocked internet sources, that Flash is disabled across all endpoints, and that .NET is configured to prevent web content from executing. Evidence typically comes from endpoint configuration management exports and browser policy reports. The difficulty is consistency across a fleet. A finding in this area almost always traces to endpoints outside the main configuration management scope.
Restricting administrative privileges is the control where organisations most commonly have a larger gap than they expect. Level 2 requires that privileged accounts cannot access email and web browsing. Evidence must demonstrate the technical enforcement of this restriction, not just a policy that says it should be so. Privileged Access Workstation configurations, Group Policy exports showing browser and mail client restrictions, and access review logs are the expected evidence types.
Multi-Factor Authentication and Daily Backups
At Maturity Level 2, MFA is required for all users accessing internet-facing services and for all privileged account activity. Evidence must show which systems have MFA enabled, the enforcement method (conditional access policies, identity provider configurations), and that exceptions have a documented approval and timeline for remediation. A list of systems with MFA enabled is not enough if the list cannot be matched to the complete inventory of internet-facing services.
Daily backups at Level 2 require that backups are performed daily, stored in a separate location, and tested for restoration at least annually. Evidence includes backup job logs, retention policy documentation, and a restoration test record with outcome noted. The most common finding here is that organisations can show the backup job completed but cannot show a successful restoration test. Completed backup logs and restoration test reports must both be present. To discuss Essential Eight evidence requirements and how we assess control implementation, contact Cyberlinx at info@cyberlinx.com.au.
Related Articles







