Free Readiness Assessment
ASD Essential Eight Readiness Checklist
Score your Essential 8 (Essential Eight) maturity across all eight ASD mitigation strategies. Answer 24 questions, get an instant domain-by-domain score and download a branded PDF you can share with executives, boards or auditors.
24 questions across all eight Essential Eight strategies, plus a quick environment context block.
Questions calibrated to the evidence criteria the ACSC and auditors assess for each strategy.
Score breakdown, top gaps and a prioritised action plan — ready to share with leadership or auditors.
Tell us about your environment
A few details to tailor your Essential Eight roadmap. Required fields are marked *.
Application Control
Allow-lists for approved executables, libraries, scripts and installers.
Only approved applications and code should run — this prevents malware and unauthorised software execution.
View evidence examples ->
- Microsoft Defender Application Control (WDAC) or AppLocker policies enforcing allow-listing.
- Coverage includes executables, DLLs, scripts (PowerShell, JS, VBS) and installers (MSI).
- Policies applied to both workstations and servers where feasible.
New software should be approved through a controlled, auditable process rather than broad exceptions.
View evidence examples ->
- Rules allowing signed code from approved publishers only.
- Formal change or exception approval process for adding new applications.
- Testing and promotion workflow from audit mode to enforced mode.
Blocked executions should be logged, reviewed and used to tune allow-lists — not ignored.
View evidence examples ->
- Centralised collection of AppLocker or WDAC events in Sentinel or equivalent SIEM.
- Documented review cadence (e.g. weekly during rollout, monthly ongoing).
- Evidence of tuning actions taken based on blocked event logs.
Patch Applications
Timely patching of internet-facing and high-risk applications.
High-risk applications must be patched quickly to reduce exposure to known exploits.
View evidence examples ->
- Defined patch SLAs aligned to ACSC guidance (e.g. critical within 48 hours).
- Automated patching via Intune, Defender or equivalent tools.
- Compliance reports showing patch status for browsers, PDF readers and email clients.
You must know what applications exist and which ones present the highest risk before you can patch them consistently.
View evidence examples ->
- Application inventory including version, owner and business criticality.
- Risk classification highlighting internet-facing or privileged applications.
- Defined process for onboarding new and retiring old applications.
Patch compliance evidence must be repeatable, consistent and easy to produce for auditors.
View evidence examples ->
- Monthly exported patch compliance reports stored in SharePoint.
- Dashboards from Intune or Defender showing patch status by device group.
- Retention aligned to audit and regulatory requirements.
Configure Office Macros
Block or tightly control macros from the Internet.
Macros are a common attack vector — blocking Internet-sourced macros by default is a baseline control.
View evidence examples ->
- Office policy blocking macros from files downloaded from the Internet.
- Only digitally signed macros or files from trusted locations allowed.
- Configuration aligned to ACSC macro hardening guidance.
Controls that are not consistently deployed provide no protection for unmanaged or unpatched devices.
View evidence examples ->
- Intune or GPO policies enforcing macro settings across all device groups.
- Deployment evidence showing all applicable devices are covered.
- Testing results confirming expected macro blocking behaviour.
Exceptions to macro controls should be rare, formally approved and periodically reviewed.
View evidence examples ->
- A documented exception request and approval workflow.
- Time-bound exceptions with defined expiry and automatic review.
- Logs of active macro exceptions reviewed at least quarterly.
User App Hardening
Disable risky browser features and block executable downloads.
Reducing the browser attack surface limits options for drive-by and watering-hole attacks.
View evidence examples ->
- Policies disabling Flash, legacy ActiveX and Java browser plugins.
- Ad and tracker restrictions or enhanced browser security mode enabled.
- Configuration aligned to ACSC browser hardening guidance.
Blocking executable downloads for standard users removes a common malware delivery path.
View evidence examples ->
- Browser or OS controls blocking executable file downloads for standard user accounts.
- Microsoft SmartScreen or equivalent enforcement active.
- Exceptions limited to approved use cases with documented approval.
Hardening controls can drift — periodic verification ensures they remain effective.
View evidence examples ->
- Screenshots or exported reports showing active hardening settings.
- Verification checks performed quarterly or after major changes.
- Evidence stored alongside linked policy references for audit readiness.
Restrict Admin Privileges
Least privilege, JIT access and segmented admin accounts.
Limiting standing administrative access reduces the blast radius of credential compromise.
View evidence examples ->
- Azure AD Privileged Identity Management (PIM) or equivalent for just-in-time admin access.
- Permanent admin rights removed from standard accounts where feasible.
- Approval workflows and logging for all privileged access activations.
Regular access reviews ensure only authorised users retain administrative access over time.
View evidence examples ->
- Quarterly access review records for all privileged or admin groups.
- Evidence of removals or adjustments following each review.
- Sign-off by system or risk owners documented.
Separating admin from day-to-day activity reduces risk of credential theft through phishing or malware.
View evidence examples ->
- Dedicated admin accounts with email and web browsing disabled or not configured.
- Privileged Access Workstations (PAWs) or hardened admin devices in use.
- Policy prohibiting admin account use for standard day-to-day activities.
Patch Operating Systems
Meet SLAs for OS patches with centralised visibility.
Operating systems must be patched within defined timeframes to reduce exploit risk from known vulnerabilities.
View evidence examples ->
- Documented OS patch SLAs aligned to ACSC guidance (e.g. critical within 48 hours).
- Patch compliance reports showing SLA adherence by device group.
- Tracked and formally approved exceptions with risk acceptance.
Controlled rollout reduces operational risk from faulty patches affecting the entire fleet simultaneously.
View evidence examples ->
- Defined pilot, broad and critical update rings for OS patch deployment.
- Rollback procedures documented and tested for failed or problematic updates.
- Evidence of updates tested in pilot groups before broad deployment.
Audit-ready OS patching evidence should be easy to produce on demand.
View evidence examples ->
- Dashboards showing OS patch compliance by device group and operating system.
- Exported compliance reports stored monthly in SharePoint.
- Retention aligned to audit requirements.
Multi-Factor Authentication
MFA for remote, privileged and sensitive access.
MFA is mandatory for high-risk access paths — the ACSC considers this non-negotiable.
View evidence examples ->
- MFA enforced for VPN, remote desktop, cloud admin roles and sensitive business apps.
- Conditional Access or equivalent policies covering all in-scope applications.
- Remaining exceptions documented, risk-accepted and tracked for remediation.
Stronger MFA methods significantly reduce the risk of credential phishing and MFA fatigue attacks.
View evidence examples ->
- FIDO2 security keys or device-bound passkeys deployed for privileged roles.
- Number matching or app-based push enabled for Microsoft Authenticator.
- SMS-based MFA restricted or being phased out.
Emergency access must exist for resilience but be tightly controlled and alerted on.
View evidence examples ->
- Documented break-glass accounts with strong, securely stored passwords.
- Regular testing of break-glass access to verify it remains functional.
- Alerts and monitoring configured on any break-glass account usage.
Regular Backups
Tested, immutable backups with defined RTO and RPO.
Backups must cover critical services comprehensively to support timely recovery.
View evidence examples ->
- A documented list of critical systems and SaaS services included in backup scope.
- Defined and approved RTO and RPO for each critical service.
- Alignment with a current business impact analysis.
Immutable backups protect against ransomware and insider threats modifying or deleting backup data.
View evidence examples ->
- Immutable or object-locked backup copies configured in cloud or tape storage.
- Separation of duties between backup administrators and system administrators.
- Evidence of immutability configuration and access controls.
Backups that have never been tested cannot be relied upon for actual recovery.
View evidence examples ->
- Scheduled restore tests for all critical systems at least annually.
- Test results documented with timestamps, screenshots or logs.
- Issues identified in testing tracked and remediated before the next test.
Available once all questions are answered
Your report is ready
Your PDF has downloaded automatically. A copy of your responses has been sent to our team — we'll follow up if you'd like to discuss the results.