Essential Eight Evidence Guide — What Your Insurer Actually Needs

What the Essential Eight is and why your insurer is asking about it

The Essential Eight is a set of baseline cybersecurity mitigation strategies published by the Australian Cyber Security Centre (ACSC), which is part of the Australian Signals Directorate (ASD). It was originally published in 2017 as a prioritised list of strategies that organisations should implement to protect themselves against cyber threats. It has since been updated multiple times, most recently with the adoption of a maturity model that defines three levels, Level 1, Level 2, and Level 3, for each mitigation strategy.

The Essential Eight is not a law. No Australian legislation requires organisations to implement it (with some exceptions in the government sector). But it has become the de facto cybersecurity baseline for a growing number of contexts.

The most significant of these, for most private-sector organisations, is cyber insurance. Australian cyber insurers have increasingly adopted the Essential Eight as their primary framework for assessing an applicant's security posture. If you have renewed a cyber insurance policy in the past two years, you have almost certainly been asked questions that map directly to the Essential Eight questions about MFA, patching, backups, application control, and administrative privileges.

The problem is that most insurers assess the Essential Eight through self-assessment questionnaires. The organisation ticks boxes. The insurer takes the answers at face value. Nobody independently verifies whether the controls are actually in place.

This guide is designed to close that gap. For each of the eight mitigation strategies, it explains what the strategy requires at each maturity level, what evidence would actually prove the control is working, and what that evidence looks like in practice, both in the manual approach and in an automated evidence-led approach.

The goal is practical: after reading this guide, you should understand exactly what your insurer is looking for, exactly what evidence you would need to provide, and exactly where your current approach might have gaps.

Understanding maturity levels

Before walking through each strategy, it is important to understand what the three maturity levels mean. This is where many organisations and even some IT providers get confused.

Level 1 (L1) is described by the ACSC as partly aligned with the intent of the mitigation strategy. L1 represents a baseline level of implementation. The controls are present but may not cover all systems, all users, or all scenarios. L1 is the minimum level that most cyber insurers currently expect.

Level 2 (L2) is described as mostly aligned with the intent of the mitigation strategy. L2 represents a more comprehensive implementation. Controls cover most systems and users, with tighter configuration and fewer exceptions. L2 is increasingly expected by insurers for organisations with higher risk profiles or larger environments.

Level 3 (L3) is described as fully aligned with the intent of the mitigation strategy. L3 represents the most rigorous implementation. Controls are comprehensive, actively managed, and cover the full scope of the organisation's environment. L3 is typically expected for government agencies and organisations with the highest security requirements.

A critical point that many organisations miss: maturity levels apply per strategy, not globally. An organisation can be at L2 for patching and L1 for application control. The insurer may require different levels for different strategies based on the organisation's risk profile. When your insurer asks "what Essential Eight maturity level are you at?" the honest answer is often "it depends which strategy."

Strategy 1: Application control

What it requires:

Application control prevents unapproved applications, including malicious code, from executing on systems. At its core, it means only approved software can run.

At L1, application control is implemented on workstations to restrict execution of executables in user profiles and temporary folders. The focus is on preventing common malware execution paths.

At L2, application control extends to cover all workstation executables, software libraries (DLLs), scripts, and installers. The approved application list is actively managed. Microsoft's recommended block rules are implemented.

At L3, application control covers all workstations and servers. The approved list is strictly managed. All application control events allowed and blocked are logged and monitored.

What evidence your insurer needs:

Your insurer needs to know not just that application control is "enabled" but that it is actively enforced, covers the required scope, and has not been bypassed or weakened. The evidence that proves this includes:

Configuration evidence showing that application control policies are deployed, active, and targeting the correct systems. This means showing the actual policy configuration which applications are allowed, which are blocked, and which systems the policy applies to.

Coverage evidence showing that the policy applies to the correct scope of systems. At L1, all workstations. At L2, all workstations with extended coverage. At L3, all workstations and servers. The evidence needs to show that no systems are accidentally excluded.

Enforcement evidence showing that blocked execution events are occurring, which proves the policy is actually preventing unapproved applications from running. If an application control policy has zero blocked events over an extended period, it may not be functioning correctly.

Manual approach vs automated evidence:

In the manual approach, someone exports a screenshot of the application control policy configuration, writes a statement that it covers all workstations, and attaches it to the questionnaire response. This is a snapshot that proves the configuration at one point in time. It says nothing about whether the policy was active yesterday, whether it covers systems added since the screenshot was taken, or whether enforcement is actually working.

In an automated evidence-led approach, evidence of the application control configuration, the systems it covers, and the enforcement events is collected directly from the endpoint management system on a recurring schedule. Each evidence collection is timestamped, hashed, and chained. The insurer can see not just the current state but the history when the policy was active, when it covered specific systems, and whether enforcement has been continuous.

Strategy 2: Patch applications

What it requires:

Application patching addresses vulnerabilities in software that attackers exploit to gain access to systems. The core requirement is that known vulnerabilities in applications are remediated within defined timeframes.

At L1, security vulnerabilities in internet-facing services and office productivity suites are patched or mitigated within one month of a patch being released. Applications that are no longer supported by vendors are removed.

At L2, the patching timeframe tightens to two weeks for internet-facing services and office productivity suites when a vulnerability is assessed as critical or a working exploit exists. Automated vulnerability scanning occurs at least fortnightly.

At L3, the timeframe tightens to 48 hours for internet-facing services when a critical exploit exists. Automated scanning occurs at least weekly. All patches for all applications are applied within one month.

What evidence your insurer needs:

Patching evidence is one of the areas where the gap between claimed and actual compliance is largest. Your insurer needs to know: what is your current patch status across your environment, not what your patching policy says?

The evidence includes: a list of applications in scope, the current patch version of each, the latest available patch version, the date the latest patch was released, whether any critical vulnerabilities remain unpatched, and how long any unpatched critical vulnerabilities have been outstanding.

For L2 and L3, the insurer also needs evidence of vulnerability scanning frequency and results showing that scanning is happening on the required schedule and that the results are being acted upon.

Manual approach vs automated evidence:

Manually, someone runs a vulnerability scan, exports the results, formats them into a readable report, and submits them. This might take hours. The results are accurate only at the moment the scan ran. By the time the insurer reviews the report, the patch status may have changed.

In an automated approach, vulnerability scan results (from tools like CIS-CAT Pro, Tenable, Nessus, or Qualys) are ingested directly into the evidence platform on a recurring schedule. Each scan result is timestamped, hashed, and committed to the evidence ledger. The evidence platform can show the patching trend over time not just a snapshot, but a continuous record of whether patching is improving, degrading, or stable.

Strategy 3: Configure Microsoft Office macro settings

What it requires:

Office macros are a common attack vector. This strategy restricts macro execution to prevent malicious macros from running on user systems.

At L1, Microsoft Office macros are disabled for users who do not have a demonstrated business requirement. Macros in files from the internet are blocked. Macro antivirus scanning is enabled.

At L2, macros are only allowed to execute in documents from trusted locations. Macro execution is logged. Users cannot change macro security settings.

At L3, only signed macros from trusted publishers are allowed. All other macros are blocked. Macro execution events are centrally logged and monitored.

What evidence your insurer needs:

Evidence that macro policies are configured at the required level across all managed systems. This means showing: the Group Policy or Intune configuration for macro settings, the scope of systems the policy applies to, and whether any exceptions exist.

The insurer also needs evidence that the policy is enforced that users cannot override the macro settings and at L2/L3, evidence that macro execution events are being logged.

Manual approach vs automated evidence:

The manual approach involves exporting Group Policy settings or Intune configuration screenshots. This shows the configuration at one point in time but does not show whether the configuration is applied to all systems, whether any systems have drifted from the policy, or whether new systems have been added without the policy.

Automated evidence collection can pull macro policy configuration from Active Directory or Intune, verify the scope of application, identify any systems that are not receiving the policy, and Attest changes over time.

Strategy 4: User application hardening

What it requires:

This strategy reduces the attack surface of common user applications web browsers, PDF readers, and office applications, by disabling unnecessary features and blocking risky functionality.

At L1, web browsers are configured to block web advertisements, Java from the internet, and Flash. Web browsers do not process Java from the Internet. Internet Explorer 11 is disabled or removed.

At L2, web browsers are hardened beyond the L1 requirements. Users cannot install browser extensions without approval. OLE packages in Office documents are blocked.

At L3, .NET Framework 3.5 (including .NET 2.0) is disabled or removed. PowerShell is configured to Constrained Language Mode. Child processes from Office applications are blocked.

What evidence your insurer needs:

Configuration evidence showing that the required hardening settings are applied across all managed workstations. This includes browser configuration policies, Office configuration policies, and any relevant Group Policy or Intune settings.

Coverage evidence showing which systems have the hardening policies applied and whether any systems are missing.

Manual approach vs automated evidence:

Manually, this involves documenting each hardening configuration across potentially multiple policy management tools, such as Group Policy, Intune, browser management, Office configuration. The effort to compile this evidence manually can take several hours and the result is a snapshot that may not reflect recent changes.

CIS Benchmark scan results (from tools like CIS-CAT Pro) provide a structured assessment of application hardening against defined profiles. These scan results, when ingested automatically into an evidence platform, provide a continuous record of hardening compliance across the environment.

Strategy 5: Restrict administrative privileges

What it requires:

This strategy limits who has administrative (privileged) access and how that access is used. Privileged accounts are the most valuable target for attackers because they provide the broadest access.

At L1, requests for privileged access are validated. Privileged accounts are not used for reading email and browsing the web. Privileged accounts are separated from standard accounts.

At L2, privileged accounts are limited to specific administrative activities. Just-in-time administration or time-limited privileged access is implemented where feasible. Privileged account usage is logged.

At L3, privileged accounts are strictly managed with just-in-time access. All privileged access is logged and monitored. Privileged access is re-validated at regular intervals.

What evidence your insurer needs:

This is one of the most important strategies for insurers because compromised administrative credentials are involved in a large proportion of significant cyber incidents.

The evidence includes: a list of all privileged accounts and their assigned roles, evidence that privileged accounts are separate from standard user accounts, evidence that privileged accounts are not used for standard activities (email, web browsing), evidence of how privileged access is granted and revoked, and evidence of privileged access logging.

At L2 and L3, the insurer may also want to see evidence of the just-in-time access mechanism, the time limits applied, and the frequency of privileged access re-validation.

Manual approach vs automated evidence:

Manually, someone exports a list of admin accounts from Active Directory, writes a statement about how privileged access is managed, and provides screenshots of relevant policy configurations. This is time-consuming and the results are immediately stale any changes to privileged accounts after the export are not reflected.

Automated evidence collection can pull the current list of privileged accounts, privileged group memberships, last logon times, password policy compliance, and any changes to privileged access directly from Active Directory and identity management systems on a recurring schedule. The evidence shows the current state and the history including when privileged accounts were added, removed, or modified.

Strategy 6: Patch operating systems

What it requires:

This strategy is similar to Strategy 2 (patch applications) but focused specifically on operating system patching. The timeframes and scope mirror the application patching requirements but apply to the operating system layer.

At L1, security vulnerabilities in operating systems of internet-facing services and workstations are patched or mitigated within one month. Operating systems that are no longer supported are replaced.

At L2, the timeframe is two weeks for critical vulnerabilities with known exploits. Automated scanning is at least fortnightly.

At L3, the timeframe is 48 hours for internet-facing services with critical exploits. Scanning is at least weekly.

What evidence your insurer needs:

The same evidence as application patching: current patch levels across all systems, time since last patch, any outstanding critical vulnerabilities, and evidence of scanning frequency.

Additionally, the insurer needs evidence that no end-of-life operating systems are in use. A single Windows Server 2012 or Windows 7 machine still running in the environment can be a policy exclusion trigger.

Manual approach vs automated evidence:

The same dynamics as application patching apply here. Manual evidence is a snapshot. Automated evidence is a continuous record. The key advantage of automated evidence is the ability to show that patching is consistent over time — not just compliant at the moment someone checked.

Strategy 7: Multi-factor authentication

What it requires:

MFA is arguably the single most impactful security control an organisation can implement. It requires users to provide two or more authentication factors when accessing systems, making stolen passwords alone insufficient for an attacker.

At L1, MFA is used to authenticate users of internet-facing services, including cloud-based services, web-based email, and VPN connections. MFA is used to authenticate privileged users of systems.

At L2, MFA is used to authenticate all users of important data repositories, including cloud services, web-based email, collaboration platforms, and VPN. MFA solutions use either a physical token (hardware key) or a software certificate, or are phishing-resistant.

At L3, MFA is used for all users accessing all services. MFA is phishing-resistant (e.g., FIDO2 hardware security keys). Legacy authentication protocols that do not support MFA are disabled.

What evidence your insurer needs:

MFA is the strategy where the gap between "we have it enabled" and "it is actually protecting all the right accounts" is the largest. Your insurer needs to know:

Which systems have MFA enabled, not just "Microsoft 365" but specifically which services within Microsoft 365 (email, SharePoint, Teams, admin portal, etc.).

Which accounts are protected by MFA? Are all user accounts covered, or only some? Are privileged accounts covered? Are service accounts excluded?

What type of MFA is used — SMS-based (weakest), app-based (stronger), or hardware key / phishing-resistant (strongest)? Many insurers at L2+ will specifically ask whether phishing-resistant MFA is deployed.

Whether Conditional Access or equivalent policies enforce MFA consistently — are there any bypass rules, legacy authentication exceptions, or trusted-location exemptions that weaken the MFA coverage?

Manual approach vs automated evidence:

Manually, someone exports the MFA status for all users from Microsoft 365 (or whatever identity platform), exports the Conditional Access policies, and writes a summary. This takes time, the export is immediately stale, and it requires someone who understands Conditional Access policy logic to interpret whether the configuration actually achieves what the organisation claims.

Automated evidence collection can pull MFA enrollment status per user, Conditional Access policy configuration, authentication method types, and any legacy authentication activity directly from the identity platform on a recurring schedule. The evidence shows not just "MFA is enabled" but specifically which users are enrolled, which method they use, which policies apply, and whether any legacy authentication bypasses exist. This level of specificity is exactly what an insurer needs to assess MFA coverage accurately.

Strategy 8: Regular backups

What it requires:

Backups are the last line of defence. When everything else fails, when an attacker gains access, encrypts data, and demands a ransom, backups are what allow the organisation to recover without paying.

At L1, backups of important data, software, and configuration settings are performed and retained in accordance with business continuity requirements. Backups are stored in a location not accessible through the network using the same credentials as the systems being backed up.

At L2, backups are tested at regular intervals to confirm that backed-up data can be restored. Unprivileged accounts cannot access, modify, or delete backups. Privileged accounts (excluding backup administrator accounts) cannot access, modify, or delete backups.

At L3, backups are tested when significant changes occur. Unprivileged accounts and privileged accounts (excluding backup break-glass accounts) cannot access, modify, or delete backups. Backup protection is enforced at the storage platform level.

What evidence your insurer needs:

Backup evidence is another area where the gap between claimed and actual compliance is routinely large. Your insurer needs:

Evidence that backups are running, specifically, the status of recent backup jobs. When did the last successful backup run? Are there any failed backup jobs? Are there any systems that are supposed to be backed up but are not included in the backup scope?

Evidence of backup retention: how many recovery points exist, how far back do they go, and does the retention meet the organisation's stated requirements?

Evidence of backup isolation is that backups are stored in a way that an attacker who compromises the production environment cannot also compromise the backups? This is the critical question for ransomware resilience.

Evidence of backup testing has the organisation actually tested restoring from backups? When? What was the result? Many organisations discover that their backups are unusable only when they try to restore during an actual incident.

Manual approach vs automated evidence:

Manually, someone logs into the backup console, exports the job history, screenshots the retention settings, and writes a statement about backup isolation and testing. This is tedious, immediately stale, and often incomplete because the person compiling the evidence may not have access to all backup systems across the environment.

Automated evidence collection can pull backup job status, retention configuration, successful and failed job history, and protected backup posture directly from backup software (Veeam, Datto, Acronis, and others) on a recurring schedule. Each collection is timestamped and committed to the evidence ledger. The insurer can see not just "backups ran last night" but the backup trend over weeks and months including any gaps, failures, or configuration changes.

The gap between questionnaire answers and evidence

Having walked through all eight strategies, a pattern should be clear. For each strategy, there is a significant difference between what a questionnaire can capture and what evidence can prove.

A questionnaire captures intent and belief: "We have MFA enabled." "We patch within 30 days." "We have application control."

Evidence captures reality: "MFA is enabled on 94% of user accounts as of 14:32 AEST today. Six accounts in the finance team are not enrolled. Conditional Access policy CA-003 exempts legacy authentication for the boardroom conference system."

The questionnaire answer says "yes." The evidence says "mostly, with specific gaps that are identified and can be addressed." An insurer receiving the evidence-based answer has a fundamentally different basis for assessing risk than an insurer receiving the questionnaire answer.

This is the core argument for evidence-led compliance. Not that the questionnaire model is dishonest it usually isn't. But that it is structurally incapable of providing the specificity, timeliness, and verifiability that accurate risk assessment requires.

What "good" Essential Eight evidence looks like

If you wanted to compile a best-practice Essential Eight evidence pack for your insurer today, here is what it would contain:

For each strategy:

A current-state assessment showing whether the control is in place, what maturity level it achieves, and what evidence supports the assessment.

A coverage map showing which systems are covered by the control, which are not, and why any systems are excluded.

An evidence trail showing when the evidence was collected, from which source system, and whether it has been altered since collection.

A gap list showing any areas where the control does not meet the target maturity level, with specific detail about what is missing.

A trend view showing how the control has performed over time is it improving, stable, or degrading?

For the overall assessment:

A summary scorecard showing the maturity level achieved for each strategy.

A confidence statement for each strategy is the assessment based on comprehensive evidence, partial evidence, or insufficient evidence?

A framework version reference showing which version of the Essential Eight the assessment is based on.

An assertion statement describing what the assessment covers and what it does not cover.

A verification mechanism allowing the insurer to independently confirm the report is genuine and the underlying evidence exists.

This is a significant amount of evidence. Compiling it manually for all eight strategies across an entire environment can take days. Compiling it with automated evidence collection takes minutes because the evidence is already collected, already locked, already mapped, and already available for report generation.

A practical approach: where to start

If your organisation is not currently assessed against the Essential Eight or is assessed only through questionnaire-based self-assessment here is a practical starting sequence.

Start with visibility. Before trying to improve your maturity level, understand where you actually stand today. An honest, evidence-based assessment of your current state is more valuable than an optimistic self- assessment. You may find that some strategies are stronger than you thought and others weaker. The evidence reveals both.

Focus on the highest-impact strategies first. For most organisations, MFA (Strategy 7), patching (Strategies 2 and 6), and backups (Strategy 8) are the strategies where improvement has the greatest impact on both security posture and insurance positioning. These are also the strategies where insurers focus most of their attention.

Target L1 across all eight before pursuing L2 on any. It is more valuable to have consistent L1 coverage across all strategies than to have L3 on one strategy and nothing on three others. Insurers assess the overall posture, not individual peaks.

Collect evidence from the start. Even before you reach your target maturity level, start collecting evidence of the controls you do have in place. This creates a baseline, shows progress over time, and means that when your insurer asks for evidence, you have something to provide beyond a questionnaire.

Make evidence collection automated. If you are collecting evidence manually, you will eventually stop. Manual processes are sustainable for one assessment cycle. They are not sustainable continuously. Automated evidence collection runs without human effort, which means the evidence is always current and always available. Platforms like APEXLyn Attest are designed to automate this evidence collection across all eight strategies, connecting to the systems you already use and mapping the evidence to Essential Eight maturity levels automatically.

What your insurer will see differently

When your organisation provides evidence-backed Essential Eight compliance instead of questionnaire-based compliance, the insurer sees three things differently.

First, they see specificity. Instead of "MFA is enabled," they see exactly which accounts are protected, which method is used, and which policies are enforced. This level of detail allows the insurer to assess risk more accurately and more favourably for well-configured organisations.

Second, they see continuity. Instead of a point-in-time snapshot, they see an evidence trail showing that controls have been consistently in place over weeks and months. This is a fundamentally different risk profile from a snapshot that might not reflect the state last week or next week.

Third, they see verifiability. Instead of trusting the organisation's assertion, they can independently verify that the evidence exists and that the report has not been altered. This removes the trust problem entirely and replaces it with mathematical proof.

Not every insurer is currently set up to receive and evaluate this kind of evidence. But the direction is clear. Insurers that can differentiate between organisations with verified evidence and organisations with questionnaire answers will be able to price risk more accurately and the organisations with evidence will benefit from that accuracy.