Essential Eight Compliance Made Practical: A Step-by-Step Guide to Auditing, Hardening, and Securing Your Business

For many Australian organisations, the Essential Eight becomes difficult at the point where implementation has to be measured.

The framework itself is clear. The harder part is knowing whether each control is working across the environment and whether the organisation can prove its maturity level during an assessment. That challenge is widespread. In 2025, only 22% of participating Commonwealth entities reached overall Maturity Level 2 or higher.

This guide focuses on making essential 8 compliance easier to manage, assess, and strengthen without turning the process into a checklist exercise.

What Is Essential Eight Compliance?

Essential 8 compliance refers to implementing the requirements of the Essential Eight maturity model across a defined IT environment and being able to show that those controls operate effectively.

The Essential Eight forms part of ASD’s broader Strategies to Mitigate Cyber Security Incidents. Meeting a chosen maturity level generally requires you to:

• Implement the applicable requirements for that level
• Apply them across the agreed assessment scope
• Provide evidence that the controls are working as intended

ASD does not issue a universal Essential Eight certification. An organisation may still need an independent assessment where this is required by government policy, a regulator, a contract, procurement conditions, or another assurance arrangement.

Who Needs to Meet Essential Eight Requirements?

Essential Eight requirements do not apply to every Australian organisation in the same way.

1. Non-Corporate Commonwealth Entities

Non-Corporate Commonwealth Entities covered by the Protective Security Policy Framework must implement all eight strategies to at least Maturity Level 2. Higher level controls may also need consideration where the threat environment justifies them.

2. DISP Members and Defence Suppliers

Defence ended assessments based only on the former Top Four on 15 November 2025. DISP members must now achieve and maintain the full Essential Eight at Maturity Level 2.

3. Private Australian Businesses

There is no blanket requirement for every private business to achieve a specific maturity level. However, essential 8 cyber security requirements can arise through:

• government procurement
• Defence contracts
• customer security clauses
• cyber insurance conditions
• regulatory expectations
• internal cyber policies
• supply chain requirements

Essential Eight Maturity Levels Explained

The levels reflect increasing adversary tradecraft and targeting rather than simple beginner, intermediate, and advanced stages.

The ASD Essential Eight Controls: A Detailed Overview

The eight strategies support one another, so a weakness in one control can leave an attack path that affects the wider security posture.

1. Application Control

Application control limits which software, scripts, installers, libraries, and other executable content can run within your environment. ASD also expects coverage of user profiles and temporary folders, with broader coverage at higher maturity levels.

When reviewing this control, focus on:

• Testing whether unauthorised files can execute
• Checking broad allow rules and policy coverage
• Confirming central management and event logging
• Reviewing approved software and exceptions
• Keeping policy exports, blocked execution logs, approval records, and test results as evidence

Tools can support enforcement, but compliance depends on how effectively the rules are configured and maintained.

2. Patch Applications

Application patching reduces exposure to known flaws in browsers, office software, PDF readers, security products, and online services. ASD expects automated asset discovery and current vulnerability scanning, with daily scanning of online services and rapid remediation for critical or actively exploited vulnerabilities.

Focus on:

• Accurate application inventories and scan coverage
• Patch failures and missed remediation timeframes
• Unsupported software and approved exceptions
• Evidence such as scan reports, deployment records, tickets, and exception registers

A useful KPI is the percentage of applicable critical or exploited vulnerabilities fixed within the required timeframe.

3. Configure Microsoft Office Macro Settings

Malicious Office macros can execute code when a user opens a compromised document. ASD focuses on limiting macro use to genuine business needs rather than allowing unrestricted access.

Review whether:

• Macros are disabled for users without an approved requirement
• Internet-sourced macros are blocked
• Antivirus scanning covers macro execution
• Users cannot change macro security settings
• Relevant macros are prevented from making Win32 API calls at ML2

Keep GPO or Intune settings, approved user lists, business approvals, and test results as evidence.

4. User Application Hardening

Even fully patched applications can expose risky functions that attackers may abuse. User application hardening reduces these opportunities by tightening how browsers, Office software, PDF readers, PowerShell, and similar tools behave.

Key areas to verify include:

Apply these settings centrally through Group Policy, Intune, or equivalent management tools, then test whether standard users can weaken them. Retain policy exports, endpoint reports, logging configurations, and technical test results as evidence.

5. Restrict Administrative Privileges

Privileged accounts can let attackers change security settings, access sensitive systems, and move across an environment. ASD therefore requires tighter control than simply removing local administrator rights.

Review:

• Privileged account ownership and inactive access
• Separate administrator identities and environments
• Internet and email restrictions
• Periodic access revalidation
• Jump server use and central logging

Keep privileged group exports, access reviews, activity logs, workstation settings, and access removal records as evidence.

6. Patch Operating Systems

Operating system flaws can give attackers a route into critical systems or help them gain higher privileges. Your audit should identify unsupported systems and check whether internet facing vulnerabilities are being fixed within ASD timeframes. Legacy systems should have controlled exceptions and a clear replacement plan rather than simply being excluded from scope.

7. Multi-Factor Authentication

MFA limits the damage caused by stolen passwords, but coverage and method matter. Review cloud services, remote access, privileged accounts, alternate login paths, emergency accounts, and authentication logs. At ML2, ASD requires phishing resistant MFA for relevant services and systems. Keep conditional access policies, sign in logs, enrolment reports, and bypass test results as evidence.

8. Regular Backups

Backups should protect critical data, applications, and settings according to business continuity needs, not a fixed daily schedule. ASD also expects restoration testing and secure retention.

Check whether backups can restore systems to a usable point and whether ordinary or privileged accounts can alter or delete protected copies.

Business Impact: Why It Matters & Why Non-Compliance Is a Significant Risk

The Essential Eight addresses weaknesses attackers commonly use to gain access or increase the impact of a compromise. These include vulnerable software, stolen credentials, excessive administrative access, uncontrolled application execution, and weak recovery processes.

The current Australian threat environment makes these gaps difficult to ignore. In FY2024 to 2025, ASD received more than 84,700 cybercrime reports. The average self-reported cost for businesses reached about $80,850 per report, while publicly reported CVEs increased by 28%.

An assessment also tests whether controls work rather than simply checking whether they have been documented. ASD guidelines give the highest evidentiary value to simulated testing, followed by reviewing live system configurations. Reports and screenshots provide weaker assurance, while policies and verbal statements alone provide poor evidence.

A control can therefore appear correctly configured and still fail when tested. MFA may miss an alternative login route. Application control may allow execution from an unintended location. A successful backup job may still fail during restoration.

Why Non Compliance Creates Business Risk

Unresolved gaps can affect more than an assessment result. Depending on your organisation and contractual obligations, they may contribute to:

• Delays in government or Defence procurement
• Difficulty meeting customer security requirements
• Expensive remediation close to tender deadlines
• Greater exposure to ransomware or credential compromise
• Increased executive and board scrutiny
• Possible cyber insurance implications
• Disruption caused by urgent security changes

Essential Eight maturity should also not be treated as proof that every cyber risk has been addressed. 

Organisations may therefore need additional controls for areas such as detection, incident response, cloud security, third-party risk, broader vulnerability management, and governance. 

Unsure if your Essential Eight controls will pass an audit?

We test your live systems to find hidden security gaps and verify your evidence before formal assessment.

Book a Security Assessment →

Practical Implementation Steps

A reliable essential 8 cyber security program starts with clear assessment boundaries, ownership, evidence, and measurable remediation priorities.

Step 1: Determine Why You Need the Essential Eight Assessment

Start by recording what is driving the assessment. It could be an internal security goal, board request, government contract, DISP obligation, procurement requirement, customer condition, insurance request, or regulatory concern.

The reason influences the expected maturity target, reporting format, assurance level, completion date, and whether an independent assessment is required.

Step 2: Select the Target Maturity Level

Choose the required maturity before making technical changes. Base the decision on contractual obligations, regulatory expectations, threat exposure, information sensitivity, business criticality, and the consequences of compromise.

Document the selected level, approval, technical owner, and systems it applies to so remediation has a clear objective from the beginning.

Step 3: Define the Essential Eight Assessment Scope

Agree exactly what the assessment covers before testing begins. Include relevant endpoints, servers, remote users, internet facing systems, cloud services, Microsoft 365, identity systems, backup platforms, administration environments, and third-party managed assets.

Any excluded component should be named and justified. ASD specifically expects out-of-scope components to be documented rather than silently omitted.

Step 4: Build an Accurate Asset and Identity Inventory

Assessment results are unreliable when systems or privileged identities are missing from the inventory. Reconcile information from endpoint management, directory services, vulnerability scanners, cloud platforms, network discovery, and RMM tools.

Capture ownership, software and operating system versions, support status, exposure, scanner coverage, backup coverage, administrative access, service accounts, contractors, and dormant identities.

Step 5: Create an Essential Eight Evidence Register

Use one register to connect each requirement with its owner, enforcement method, evidence, test result, exception, and remediation date. This makes gaps easier to trace during remediation and prevents evidence from being scattered across screenshots, tickets, and spreadsheets.

Step 6: Test Controls Instead of Trusting the Checklist

ASD places the strongest weight on simulated testing and direct inspection of live configurations. Scripts, vulnerability scans, authentication logs, endpoint data, and restore tests can expose issues that documents may miss.

Policies, interviews, screenshots, approval tickets, and reports can support an assessment, but they should not replace technical verification where testing is reasonably possible.

Step 7: Choose Representative Samples Where Full Testing Is Not Possible

ASD does not prescribe one fixed percentage of devices to test. The sample should reasonably represent the environment and account for differences in endpoint builds, operating systems, user types, locations, and management arrangements.

Where tools can inspect the full population, broader technical testing gives better coverage. Record why any smaller sample was considered representative.

Step 8: Assess Every Requirement and Record the Result

Give each tested requirement a consistent outcome such as effective, alternate control, ineffective, no visibility, or not applicable. ASD uses standardised outcomes so assessors can clearly distinguish working controls from gaps or unverified areas.

For failures, record the affected systems, technical cause, security impact, owner, target date, dependencies, and required retest.

Step 9: Handle Exceptions and Compensating Controls Properly

Risk acceptance alone does not make a failed control effective. ASD expects an alternate control to provide equivalent protection if it is being relied upon for the assessment outcome.

For an unpatchable legacy server, this may involve isolation, tighter authentication, restricted administration, stronger monitoring, a controlled exception, and a firm replacement date.

Step 10: Prioritise the Remediation Roadmap

Once findings are confirmed, sequence remediation according to security impact and business exposure. Internet exposed unsupported systems, overdue critical fixes, authentication gaps, excessive privileges, and weak recovery capability will often demand earlier attention.

Every remediation item should have a technical owner, business owner, risk rating, dependencies, budget requirement, completion date, evidence requirement, and retest date.

Step 11: Retest Every Remediated Finding

A closed ticket does not confirm that a security weakness has disappeared. Repeat the test that originally exposed the problem.

If an executable previously ran from AppData, test the same path after the application control policy changes. Update the assessment result only when the retest shows that the intended control now works.

Step 12: Calculate and Report the Achieved Maturity

Turn the technical assessment into a concise executive scorecard. Show the target and achieved maturity, the result for each strategy, unresolved requirements, accepted alternate controls, open exceptions, remediation deadlines, and remaining risk.

Keep detailed technical evidence behind the summary so decision makers can see both the maturity result and what still requires action.

Step 13: Keep Essential Eight Effective Between Assessments

Security maturity can decline as systems, users, software, and access rights change. Ongoing monitoring should therefore continue after remediation.

A practical review cycle can include continuous monitoring for vulnerability, authentication, backup, endpoint, and application control events. Monthly reviews can cover overdue patches and access changes. Quarterly reviews can examine exceptions, inventories, control ownership, and remediation progress.

Full reassessment should also follow significant changes where the existing result may no longer represent the environment.

How Qualysec Supports Essential Eight Compliance

Qualysec can support businesses that need to check whether their Essential Eight controls hold up during technical testing. The work can begin with the systems most relevant to the assessment, such as cloud infrastructure, web applications, APIs, external networks, and internet-facing assets.

Qualysec uses automated scanning together with manual penetration testing. Automated tools help find common weaknesses, while manual testing can uncover problems that scanners may overlook. Qualysec’s published methodology specifically notes that manual assessment is used to validate findings and identify more complex security issues.

Testing covers:

• Authentication weaknesses
• MFA bypass routes
• Vulnerable software
• Privilege escalation
• Exposed services
• Insecure configurations
• Application and API flaws

This fits well with ASD guidance, which gives stronger weight to direct testing and live system checks than to screenshots or written policies alone.

Fix, Then Test Again

Findings are reported with their risk and practical remediation guidance. Qualysec also provides post-testing support and retesting after fixes are applied. 

For businesses preparing for an Essential Eight assessment, this can help uncover technical weaknesses before they delay remediation or affect the assessment outcome.

Achieve Essential Eight Compliance with Confidence

Streamline your audit, validate your security controls with expert manual testing, and reach your target maturity level faster with Qualysec.

Book a Free Consult→

Conclusion

Effective essential 8 compliance comes down to three things: choosing the right maturity target, defining the correct assessment scope, and proving that required controls work through reliable technical evidence. ASD guidance also makes clear that assessment should consider both implementation and control effectiveness.

Once gaps are found, they should be fixed and tested again before the achieved maturity is reported.

Essential Eight should also remain part of ongoing security management. New systems, users, software, vulnerabilities, and access changes can weaken controls over time, so maintaining the baseline matters as much as reaching it initially.

FAQS

Is the Essential Eight mandatory?

Not for every private Australian business. Non-corporate Commonwealth entities subject to the PSPF must implement at least ML2, while DISP members must maintain full Essential Eight ML2. Private organisations may still face requirements through contracts, procurement, customers, insurers, or Defence supply chains.

What are the Essential Eight maturity levels?

The model uses ML0 through ML3. ML0 means some ML1 requirements remain unmet. ML1, ML2, and ML3 are target levels built around increasingly capable adversaries and stronger attack techniques, rather than simple beginner, intermediate, and advanced stages.

Which maturity level should we target?

Your target should reflect contractual duties, regulatory expectations, threat exposure, data sensitivity, system criticality, and potential business impact. Some environments have prescribed requirements, including ML2 for relevant PSPF and DISP obligations. Others should choose based on risk rather than company size alone.

How often should we assess our maturity?

No universal schedule fits every private organisation. Reassessment should reflect risk, contractual obligations, and major technology changes. Ongoing monitoring matters between formal reviews, especially after cloud migrations, identity changes, acquisitions, network redesigns, or significant control failures.

Does the Essential Eight cover operational technology?

Not completely. ASD designed the Essential Eight primarily for internet-connected enterprise IT. Its principles may help inform OT security, but the model was not created specifically for operational technology. OT environments should use controls suited to their architecture and threats.

Can we achieve different maturity levels for different strategies?

Individual strategies can assess at different levels, but your overall result reflects the least mature strategy. Seven controls at ML2 and one at ML1 still produce an overall ML1. ASD recommends reaching the same target across all eight before progressing.

How does the Essential Eight relate to the ASD ISM?

The Essential Eight is a prioritised baseline within ASD’s broader guidance, while the Information Security Manual (ISM) includes a much wider set of controls. ASD provides direct mapping between them. Higher-risk organisations may need additional ISM controls beyond Essential Eight requirements.