The single most useful thing to understand before an Essential Eight assessment is that assertions do not count. ASD's guidance for assessors is explicit that they should test controls and corroborate across multiple sources of evidence rather than accept that a control is in place because someone says so.
Organisations that prepare a document pack and expect an interview are consistently surprised. Here is how it actually runs.
How an assessment is conducted
Assessments typically combine four techniques, and a finding usually needs more than one:
- Interviews to understand what is supposed to happen.
- Documentation review — policy, standards, procedures, and the records they produce.
- System configuration inspection — actually looking at group policy, endpoint configuration, tenancy settings.
- Technical testing — attempting to execute an unapproved binary, checking whether an MFA prompt appears, confirming a macro is blocked.
The technical testing is what separates an Essential Eight assessment from a questionnaire. If the assessor cannot execute an unapproved file on a sampled workstation, application control is working. If they can, no amount of documentation changes the finding.
Sampling, and why partial coverage gets caught
Assessors sample rather than inspect every system, and they choose the sample to be representative — different business units, different device types, servers as well as workstations, and the awkward corners like contractor laptops and legacy segments.
This is precisely how partial implementations are found. A control deployed to 80% of the estate has a high probability of appearing in a sample of ten devices as at least one failure, and one failure means the requirement is not met.
The evidence that satisfies each strategy
- Patching: not a screenshot of a patch console today, but a report showing patch age against the required timeframe over a period. Assessors want to see the timeframe met repeatedly, not once.
- Asset discovery and scanning: the schedule, the scanner configuration showing an up-to-date vulnerability database, and the asset inventory the scanning covers.
- MFA: the enforcement policy plus evidence of which services are in scope — including third-party services holding your data, which is the part most often incomplete.
- Privileged access: the account inventory, evidence of the privileged and unprivileged environment separation, and the internet restriction actually enforced rather than stated.
- Application control: ruleset export, proof of enforcement mode, coverage against inventory, and the exception register.
- Macros and hardening: configuration exports showing settings are enforced and not user-changeable.
- Backups: the schedule, the retention configuration, access control on the backup system, and a dated restoration test record.
Keep the evidence attached to the requirement
GRC Copilot ships all four maturity levels as assessments with evidence upload against each individual requirement, so an assessor request is a report rather than a scramble.
Try GRC Copilot free Generate an AI-powered assessment Download checklist Book a demo
The findings that come up most
- Coverage gaps. The control is real but does not reach every in-scope system. Almost always the top finding.
- Point-in-time evidence. Correct configuration today with no ability to show the preceding months.
- Settings users can change. Several requirements specifically demand that users cannot alter security settings; configuring a default is not the same as enforcing it.
- Untested restoration. Backups exist, restoration has never been exercised and recorded.
- Third-party services outside MFA scope. Own tenancy covered, the SaaS platform holding customer data not.
- Audit mode mistaken for enforcement. Application control deployed and logging, but not blocking.
How to prepare
- Self-assess honestly first, against the specific requirements rather than the strategy names. Most of the value of an external assessment is lost if you have not done this.
- Fix coverage before depth. Reaching 100% of the estate on a Level One requirement is worth more than a Level Two feature on 70%.
- Assemble evidence by requirement, not by system. The assessor works requirement by requirement, and a folder organised by server wastes everyone's time.
- Have the awkward systems ready. The legacy segment, the acquired subsidiary, the OT network. Volunteering them reads far better than having them found.
- Do not inflate. A claimed level that collapses under testing damages credibility across every other strategy, including the ones you had right.
Frequently asked questions
Can we self-assess?
Yes, and you should as preparation. Whether self-assessment is sufficient depends on who is asking — an increasing number of tenders and contracts specify independent assessment, and some Commonwealth reporting has its own expectations.
How long does an assessment take?
For a mid-sized organisation, typically one to three weeks of assessor effort depending on estate complexity and how well evidence is organised. Poorly organised evidence is the main driver of a longer, more expensive engagement.
What if we disagree with a finding?
Ask what evidence would change it. Findings usually turn on coverage or on evidence over time, both of which are objective. If the gap is real, a dated remediation plan attached to the finding is far more useful than a dispute.
How often should we be assessed?
At least annually, and after major change — an acquisition, a cloud migration, or a significant platform replacement. Maturity slips quietly, and the drop is usually discovered by an assessor rather than internally.
Key takeaways
- Assessors test controls; assertions and documentation alone do not establish a finding.
- Sampling is designed to find partial coverage, and usually does.
- Patching evidence must show the timeframe met over a period, not on the day.
- Organise evidence by requirement, and volunteer the awkward systems.