How to Prepare an Essential Eight ML2 Evidence Pack for Australian Auditors

An Essential Eight Maturity Level 2 evidence pack is a structured collection of artefacts — policies, configuration exports, scan reports, logs, and exception registers — that proves to an auditor your organisation consistently applies all eight mitigation strategies, not just has them documented somewhere.

Australian government agencies assessed under the PSPF and non-government entities seeking to demonstrate ML2 compliance to clients or regulators all face the same challenge: knowing what evidence to collect, how to organise it, and what auditors actually look for when they review it.

This guide walks you through the complete process, from scoping the pack to handing it over.

Why Evidence Quality Matters More Than Quantity

Auditors assessing against the ACSC's Essential Eight Maturity Model are not looking for a large folder of PDFs. They are looking for evidence that demonstrates consistent and repeatable control application. A ten-page policy with no corresponding configuration export or automated scan output will not satisfy ML2 requirements.

The ACSC assessment guide for each strategy lists specific evidence types expected at each maturity level. At ML2, the emphasis shifts from "we have a process" (ML1) to "we enforce this process consistently across the environment and have objective proof." That distinction drives the entire evidence collection effort.

Before you start assembling artefacts, take our free Essential Eight assessment — it identifies which controls are genuinely at ML2 and which are still ML1 or below, saving you from discovering gaps during the audit itself.

Step 1: Map Your Evidence Requirements to Each Strategy

Open the ACSC's Essential Eight Maturity Model and the corresponding Assessment Process Guide. For each of the eight strategies, note what the guide specifically requires at ML2. Create a spreadsheet with columns:

• Strategy
• Control requirement (verbatim from the guide)
• Evidence type expected
• Evidence owner (team or individual responsible)
• Collection method (manual export, automated report, screenshot)
• Status (collected / in progress / gap)

This becomes your master evidence tracker. Without it, evidence collection becomes ad hoc and you will miss requirements.

Step 2: Collect Policy and Procedure Documents

Every strategy requires an underpinning policy or procedure document. At ML2, these must be:

• Approved by management — dated signature or approval record in your document management system
• Current — reviewed within the past twelve months (or whatever period your review cycle specifies)
• Specific — naming the technologies in scope, not generic statements

For each of the eight strategies, collect:

1. The relevant policy document
2. The procedure or standard operating procedure (SOP) that operationalises the policy
3. Any exception process documentation

Common gaps here include undated policies, policies that name technologies no longer in use, and procedures that describe a manual process the organisation has since automated without updating the document.

Step 3: Export Configuration Evidence

Configuration evidence is the most technically demanding part of the pack. For each strategy, you need objective proof that controls are configured as the policy states. Common evidence types by strategy:

Application Control (Strategy 1)

• Application control solution configuration export (AppLocker XML export, Intune policy configuration, or equivalent)
• Scope documentation confirming which devices are covered
• Event log samples showing blocked execution attempts (demonstrates the control is active, not just configured)

Patch Applications (Strategy 2)

• Vulnerability scan report dated within the audit window showing patch currency across all in-scope applications
• Third-party patching tool dashboard export with patch age metrics
• Evidence that patches are applied within 48 hours for internet-facing services (ML2 requirement)

Configure Microsoft Office Macro Settings (Strategy 3)

• Group Policy or Intune policy export showing macro settings
• Confirmation that the policy applies to all workstations in scope

User Application Hardening (Strategy 4)

• Browser configuration exports disabling Flash, Java, and web advertisements
• Evidence of PowerShell Constrained Language Mode or equivalent

Restrict Administrative Privileges (Strategy 5)

• Privileged account inventory report from Active Directory or your identity management system
• Evidence that privileged accounts do not have internet and email access
• Evidence that admin activities are performed via separate privileged accounts

Patch Operating Systems (Strategy 6)

• Vulnerability scan report showing OS patch currency
• WSUS, Intune, or SCCM compliance reports confirming patch deployment timelines

Multi-Factor Authentication (Strategy 7)

• MFA policy configuration export from your identity provider
• Coverage report showing percentage of users enrolled (must be 100 percent of internet-facing services at ML2)
• Privileged account MFA coverage evidence

Regular Backups (Strategy 8)

• Backup solution configuration export
• Backup completion log for the past 90 days minimum
• Evidence of at least one successful restore test within the past twelve months

For a deeper treatment of what each of these artefacts must contain, the Essential Eight ML2 evidence pack pillar guide covers each strategy in detail.

Step 4: Gather Automated Scan and Log Outputs

At ML2, auditors expect evidence from automated tooling, not just manual screenshots. Priority scan outputs to collect:

1. Vulnerability scanner reports (Tenable, Qualys, Rapid7, or Defender Vulnerability Management) — export in PDF or CSV, labelled with scan date, scope, and environment
2. Endpoint compliance reports from your MDM solution (Intune, Jamf, or equivalent) — showing policy compliance percentage
3. Identity and access management reports — privileged account reviews, stale account reports, MFA enrolment status
4. SIEM or log aggregation exports — showing application control events, authentication events, and backup job completions

Label every scan output with:

• The date and time of the scan
• The system or environment scope
• The name of the person who ran it (or confirm it was automated)

Step 5: Build Your Exception Register

ML2 does not require zero exceptions — it requires that exceptions are formally approved, time-limited, and managed. Your exception register should include:

• System or asset name
• The control requirement it is excepted from
• Business justification
• Risk owner who approved the exception
• Approval date and expiry date
• Compensating controls in place

An exception register with no expiry dates or no named risk owner is a finding in itself.

Step 6: Organise the Pack for Auditor Review

Structure the evidence pack folder as follows:

Evidence Pack - [Organisation] - Essential Eight ML2 - [Date]
├── 00 - Index and Scope
│   ├── Evidence Index.xlsx
│   ├── Environment Scope Statement.pdf
│   └── Asset Inventory (summary).xlsx
├── 01 - Application Control
│   ├── Policy document
│   ├── AppLocker or Intune configuration export
│   └── Event log sample
├── 02 - Patch Applications
│   ├── Vulnerability scan report
│   └── Patching tool compliance report
├── 03 - Office Macro Settings
│   ├── Policy document
│   └── GPO or Intune configuration export
... [repeat for each strategy]
└── 08 - Regular Backups
    ├── Backup configuration
    ├── Backup completion logs
    └── Restore test record

Include a cover sheet in each strategy folder that maps each contained artefact to the specific ACSC guide criterion it satisfies. This reduces auditor back-and-forth significantly.

Step 7: Conduct an Internal Pre-Audit Review

Before submitting to an external auditor, assign someone who was not involved in collecting the evidence to review it against the ACSC assessment guide criteria. Common findings at this stage:

• Dated evidence outside the audit window — confirm your audit engagement letter specifies the acceptable evidence age (typically 90 days for scan outputs)
• Scope gaps — evidence covers headquarters but not branch offices or cloud workloads
• Missing artefacts — a strategy folder contains policy but no configuration export
• Inconsistent naming — artefacts labelled with generic names that do not identify the system or date

Address every gap before the audit date. A finding your internal reviewer catches costs you an afternoon. A finding an external auditor catches costs you a formal non-conformance and a follow-up audit.

Common Mistakes That Derail ML2 Audits

Confusing documentation of intent with evidence of implementation. A policy saying "we patch within 48 hours" is not evidence of ML2 compliance. A Defender Vulnerability Management report showing all critical patches applied within 48 hours over the past 90 days is.

Treating MFA as binary. Auditors will check whether MFA applies to all authentication paths, including legacy authentication protocols. Evidence of MFA policy is insufficient if legacy auth is still enabled for any subset of users.

Underscoping application control. ML2 requires application control on all workstations and servers. Evidence that covers only the Standard Operating Environment (SOE) image but not unmanaged devices or servers is a scope gap.

No backup restore evidence. Backup completion logs without a restore test record satisfy ML1, not ML2. Include dated restore test records showing what was restored and confirmation that data was intact.

Timeline Recommendation

Starting the process any later than six weeks out creates pressure that leads to missing artefacts, scope shortcuts, and poor labelling — all of which cost you during the audit.

Next Steps

If you are not yet certain which strategies your organisation genuinely meets at ML2 versus which ones only appear compliant, start with the free Essential Eight assessment to get an honest baseline before you invest in evidence collection.

The evidence pack process surfaces gaps. The earlier you find them, the more time you have to close them before they become audit findings.