Tracking Essential Eight in a GRC tool with OSCAL profiles

Can you track Essential Eight maturity in a GRC tool using ASD's OSCAL profiles?

When a customer, contract or internal target requires the Essential Eight at a named level, the first question is what to track and where. ASD publishes Essential Eight ML1, ML2 and ML3 baseline profiles of the Information Security Manual in OSCAL, a machine-readable format, and in ISM v2026.09.4 these profiles contain 46, 87 and 123 ISM controls respectively. ASD states that the profiles can be loaded into GRC tooling to track implementation, but whether a specific tool imports them cleanly is a separate question. Test the import with the exact profile version you plan to use and confirm the control count after loading. The organization owns its controls and decides how each one is implemented. A partner such as DeployOpen can prepare the tracking setup, the control records and the evidence references, but only an independent assessor issues a report.

The setup depends on the organization. Scope determines which workstations, servers, cloud tenants and business units each control record covers, so an organization with one Microsoft tenant and a small server estate needs a much shorter boundary statement than one with several domains, operational technology or subsidiaries. The systems involved also matter, because patch evidence, privileged access logs and backup records may sit in different tools that the GRC record must reference. Existing evidence changes the effort most. An organization that already exports scanner results, privileged access logs and backup restore test reports can attach them to controls quickly. One that does not will need to define collection first. Ask any partner for a written scope that lists each control by ID, the systems it covers, the named owner and the evidence source for each.

How to load the profiles into a GRC tool, by starting point

A new program has no legacy register to reconcile, so the first decision is scope. Load the ML1 profile first, because every ML1 control also appears in ML2, and then decide which maturity level you are working toward before importing the higher profiles. Record each control once against the strategy it supports, then attach evidence to that single record rather than creating a separate entry per level.

Import the level you target: Confirm whether your tool imports the ISM OSCAL profiles directly or whether you must build the catalog from the ISM_catalog.json file in ASD's mirror.
Assign an owner and status per control: Use a status field such as not started, in progress, implemented or assessed, and name one accountable person for each strategy.
Link evidence to the control: Store configuration exports, scan reports and backup restore test records against the control ID, with dates and the system they cover.
Keep one record for shared controls: Where a control appears in ML1, ML2 and ML3, track one entry and note the level at which it becomes required.

Before you start, confirm your tool's OSCAL import support with the vendor, since ASD states the format can be loaded into GRC tooling but does not describe any specific product's behavior.

Self-hosted GRC options and their edition limits

A self-hosted GRC tool holds the Essential Eight profile, the owner for each control, the evidence and the remediation trail in one place. The cards below cover one open-core option, the licensing boundary that decides what you can deploy, and the checks to run before you load ASD's OSCAL profiles.

CISO Assistant as an open-core example

CISO Assistant is a self-hosted GRC platform whose core is licensed under AGPL-3.0-only. Its license file splits the repository in two: files outside the top-level enterprise directory are AGPL-3.0, while files inside it fall under the proprietary intuitem Commercial Software License. Confirm which features you need before you deploy, because the enterprise directory is where some functions may sit and using them requires a contract with intuitem.

Framework library and automatic mapping

The platform ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2, DORA and GDPR, and maps controls between them automatically. For Essential Eight work, this matters only if the ISM-based ML1 to ML3 controls load as a framework of their own. Ask whether the ISM OSCAL profiles can be imported directly, or whether you must enter the 46, 87 and 123 controls by hand.

Risk registers and applied controls

The platform keeps risk assessments, risk registers and applied controls, so each Essential Eight control can be tied to the risk it reduces and to the measure that implements it. Map each ML2 and ML3 control to a named owner and a current state, not just a pass or fail. Confirm that applied controls can be linked to multiple profile levels, so ML1 work is not recorded twice when ML2 nests it.

Evidence and remediation action plans

Evidence records and remediation action plans are the parts an assessor will ask to see. Attach scan exports, log extracts and restore-test records to the control they support, and track each gap in an action plan with an owner and a due date. Confirm whether evidence can be versioned and whether the export format matches what your assessor requests.

Third-party risk module

The third-party risk module covers suppliers that host or administer systems in scope for Essential Eight, such as managed backup or log service providers. Record each supplier's assurance evidence and link it to the controls it affects. Confirm whether this module is in the community edition or in the enterprise scope that needs a contract, since a supplier register often matters most to the buyer at audit time.

Licensing and edition checks before rollout

Before committing, get a written answer from the vendor on three points: whether ASD OSCAL profiles import without custom work, which features sit under the enterprise license, and what support and upgrade terms apply. Hosting the AGPL-licensed code yourself carries source-availability obligations if you modify and offer it to others, so have counsel review your use. Tracking the Essential Eight is the goal; the license decides how much of the tooling you can rely on.

Keeping Essential Eight tracking current after the assessment

Once the GRC tool holds the ML1, ML2 or ML3 profile and its evidence, the work shifts from building the record to keeping it true. Microsoft describes Essential Eight assessment and remediation with its guides as a point-in-time activity, and recommends monitoring for compliance and configuration drift. Its Microsoft Learn overview of the ACSC Essential Eight is the natural starting point for understanding that position. Microsoft Purview Compliance Manager offers Essential Eight premium templates for all three maturity levels, so a Microsoft-centric estate can compare its configuration state against the same level the GRC tool tracks. Confirm with your own tenant whether those templates cover the controls you have mapped, because the GRC record and the Purview view are separate systems and will drift apart unless someone reconciles them.

Set a recurring review cycle with named owners for four tasks. First, review evidence attached to each implemented ISM control in the profile, checking that artifacts such as scan exports, log samples, MFA policy screenshots and restore test records are still current and still show what the control states. Second, re-run configuration checks against the systems in scope and record the results against the control, not just the date. Third, update the tool when ASD publishes a new ISM release: the profiles are versioned, and the ML1, ML2 and ML3 control sets in the current release (46, 87 and 123 controls) are the baseline your mappings were built on. Check the ISM OSCAL repository for the version your GRC tool imports, and confirm how the tool handles a changed or removed control ID before you accept an update.

Record every exception in the GRC tool as a risk or action item with a named owner, a documented compensating measure and a review date. An exception is a control that is not met at the target level, or a control met by a different method than the profile describes. Without an owner and a date, exceptions quietly become the permanent state. Keep the risk assessment, applied control and action plan linked, so an assessor can trace a deviation from the requirement to the decision that accepted it. Before the next assessment, ask your auditor or assessor which evidence format and retention period they expect, since the tool can hold records but the acceptance criteria belong to the assessor.

How a tracking setup moves from profile import to monitored evidence

The sequence turns a published ASD baseline into a GRC register where each Essential Eight control has an owner, linked evidence and a scheduled review. Each phase closes with a record the compliance lead can hand to an assessor.

Choose the target maturity level and scope
The compliance lead, with the CISO, selects the Essential Eight maturity level to track (ML1, ML2 or ML3) and defines which systems, business units and environments fall inside it. Because the ML2 and ML3 profiles each include the controls of the level below, the choice sets the size of the register before any import. The output is a short scope statement naming the target level, the in-scope asset groups and the people who approved both. The step is done when the scope statement is signed off and stored with the register.
Import the profile and catalog
Load the ASD ISM OSCAL catalog and the Essential Eight baseline profile for the chosen level into the GRC tool, using the machine-readable files ASD publishes for ISM v2026.09.4. Confirm the import created one record per profile control, with the control IDs and titles intact. Check the count against the figure ASD gives for that profile, which is 46 controls at ML1, 87 at ML2 and 123 at ML3. The output is an imported register with its source version recorded. Confirm with your GRC vendor how that tool handles OSCAL import, since support varies by product.
Assign an owner to each control
The compliance lead assigns each control to a named person who is accountable for its implementation, usually an engineering or operations owner for technical controls and a policy owner for procedural ones. Owners should be people who can answer an assessor's questions, not only the individuals who file tickets. Record the assignments in the tool so that every control shows an owner and a backup contact. The output is a complete ownership table, and the step is closed when no control in scope lacks an accountable person.
Attach evidence and link it to systems
Owners attach evidence to each control and link it to the systems it describes, such as configuration exports, scan reports, MFA enrolment reports, backup restore logs or privileged account reviews. Evidence should show the control operating over time, not only a single screenshot, and each item should carry a date and a source. Linking evidence to assets lets the register show which systems support which controls. The output is an evidence library mapped to controls and assets. The step is done when every control has at least one item the owner can defend, and gaps are logged as open items rather than left blank.
Run the gap review against the baseline
The compliance lead and control owners review each control's status, marking it implemented, partially implemented or not implemented, and record the reason for any status that is not implemented. For ML2 and ML3 scopes, reviewers check the controls that carry over from the level below, since ML3 replaces three ML2 controls (ISM-1691, ISM-1695 and ISM-1873) with stricter versions, and those replacements need their own evidence. The output is a gap register with a remediation action, an owner and a status for each open item. The step closes when every control has a recorded status and every gap has an action.
Set the review cadence and monitoring checks
The compliance lead sets how often each control's evidence is refreshed and which checks run automatically, such as scan results or configuration exports loaded into the tool, and which are manual, such as attestations by owners. Microsoft describes Essential Eight assessment as a point-in-time activity and recommends ongoing monitoring for configuration drift, so the cadence should cover that gap. The output is a review calendar and a monitoring plan tied to each control. Ask your GRC vendor and your assessor which evidence they expect to see refreshed and at what frequency before fixing the schedule.

Who owns the controls, the tracking setup and the assessment

This table compares what the organization, the implementation partner and the independent assessor each do when Essential Eight controls are tracked in a GRC tool using ASD's OSCAL profiles. Read each row as a handoff: the organization decides and signs off, the partner prepares the tracking setup, and only the assessor tests and reports outcomes.

Area	The organization	Implementation partner (such as DeployOpen)	Independent assessor
Control ownership	Names an owner for each ML1, ML2 or ML3 control in the profile and accepts the implementation as its own	Documents suggested owner mappings for the organization to confirm, without assigning accountability	Tests whether the named owner's implementation matches the control and the maturity level
Profile loading	Chooses the target maturity level and approves which ISM v2026.09.4 profile is loaded	Loads the ML1, ML2 or ML3 OSCAL profile into a self-hosted GRC tool inside the client's environment and checks control counts	Reviews which profile version was used and whether it matches the level claimed
Evidence mapping	Decides which evidence is acceptable and confirms each artifact is current	Maps evidence sources, such as scanner exports and log records, to individual controls and records the mapping	Samples evidence and checks it is complete, dated and traceable to the control
Integrations	Owns the systems that feed the tracker and approves access for the integration accounts	Configures connectors and scheduled exports inside the client's own infrastructure and documents them	Checks that the data path is reliable and that records are not edited after collection
Gaps and action plans	Decides on remediation, risk acceptance and deadlines, and records the approval	Tracks open items and reminders in the tool, but does not decide whether a gap is accepted	Records findings and reports the maturity outcome based on the evidence reviewed
Reports and outcomes	Receives assessment results and decides how they are shared with boards, regulators or customers	Prepares dashboards and exports for the organization's use. Does not issue reports, attestations or certificates	Issues the assessment outcome. Only the independent assessor's report carries that weight
Continuous monitoring	Funds and staffs recurring reviews, and re-checks controls when systems change	Sets up review schedules and drift checks if contracted, under a written scope	Usually not involved between assessments unless re-engaged
Vendor licensing	Confirms the GRC tool's license and edition meet its needs, and reviews CISO Assistant's license terms before deployment	Advises on license and edition limits and deploys the approved tool	Does not assess the tool itself, only the controls and evidence it supports

What usually breaks Essential Eight tracking and how to avoid it

Most Essential Eight tracking problems come from treating the framework as a one-time project instead of a set of controls with evidence that ages. The cards below cover the failures we see most often when teams load the ASD OSCAL profiles into a GRC tool, with a control step for each.

Treating the Essential Eight as a certificate

The Essential Eight is a set of mitigation strategies, not a certification scheme, and ASD issues no certificate. Teams that record a level as achieved and stop reviewing it lose the ability to show current state. Record each strategy's maturity as an assessed position with a date, the assessor or reviewer, and the scope it covered. Ask any consultant or auditor to state in writing what their report covers and what it does not.

Mapping only at strategy level

Loading the eight strategies as top-level items hides the ISM controls underneath them, so an assessor asking for control-level proof finds nothing linked. The ISM OSCAL profiles name individual controls, and each one needs its own owner, implementation statement and evidence reference. Import the ML1, ML2 and ML3 profiles at control granularity and check that every control in the imported profile has a status field populated before anyone reports a level.

Ignoring the ML3 replacements

ML3 does not simply add controls. ISM-1691, ISM-1695 and ISM-1873 are replaced by stricter versions at that level, so a tracker built from the ML2 list will show these items as complete while the ML3 requirement remains open. Confirm that your GRC import keeps the ML3 control identifiers distinct from the ML2 ones, and create separate applied controls for the stricter versions rather than reusing the older records.

Letting evidence go stale

Evidence captured during an assessment describes a configuration on one day. Patch scan results, privileged account reviews and restore test logs all age, and a GRC tool will keep showing green until someone sets an expiry. Assign each evidence item a collection date, a review interval set by the control owner, and a named reviewer. Microsoft recommends monitoring for configuration drift between assessments, which is the same discipline applied to any self-hosted stack.

Assuming a GRC edition includes features

Open-core GRC products often split capabilities between community and commercial editions, and licensing terms differ by directory within the source tree. A team may plan around audit workflows, third-party risk or framework mapping that sit behind a commercial contract. Before choosing a platform, confirm in writing which modules, OSCAL import features and mapping functions the edition you will run includes, and read the license for every component you deploy.

Losing the link to operating systems

A GRC record that says a control is implemented does not prove the endpoint still matches it. Tracking breaks when the tool holds no reference to the configuration source, such as the Intune policy, the WDAC policy or the backup job that delivers the control. Store the configuration identifier and the export or screenshot location on each applied control, so an assessor can trace a claim from the register to the system that enforces it.

Questions buyers ask about tracking Essential Eight in a GRC tool

Does ASD issue an Essential Eight certificate?

No. The Essential Eight is a set of mitigation strategies, not a certification scheme, so ASD does not issue a certificate for it. Maturity is shown by assessing how each of the eight strategies is implemented and how well it works against the Essential Eight Maturity Model, which defines Maturity Levels Zero to Three. A GRC tool can record that assessment, the evidence behind it and the remediation actions, but the record is an internal or independently produced assessment result, not a certificate. When a customer or regulator asks for proof, ask which assessment was performed, who performed it, and what evidence supports each strategy at the level claimed. The Essential Eight maturity model on cyber.gov.au sets out what each level requires.

Does ML3 include all the ML1 and ML2 controls?

Yes, with three exceptions. In ASD's ISM v2026.09.4 Essential Eight profiles, every ML1 control is also in ML2, and all but three ML2 controls are also in ML3. The three ML2 controls not carried into ML3 are ISM-1691, ISM-1695 and ISM-1873, which ML3 replaces with stricter versions. The profiles contain 46 controls at ML1, 87 at ML2 and 123 at ML3, so ML2 roughly doubles the ML1 set. In practice, this means a GRC tool loaded with the ML3 profile tracks the ML1 and ML2 controls as well, but the three replaced controls need their ML3 versions tracked and their evidence checked against the stricter wording. Confirm the nesting in the profile files themselves before building your assessment plan.

How much effort does setting up Essential Eight tracking take?

The effort depends on the target level, the size of the estate and how much of the evidence already exists. The main work is mapping your existing controls, owners and evidence to the ISM controls in the profile, deciding which controls apply to which systems, and agreeing who uploads evidence and how often. Loading the OSCAL profile is the smaller task; the cost lies in the mapping and in keeping it current. Ask any provider for a written list of deliverables, the systems in scope, the number of control owners involved and the evidence sources to be connected. Those four items determine most of the effort, and the quote should follow from them. Your own team will carry the recurring work after handover.

Is a self-hosted GRC tool enough for Essential Eight tracking?

A self-hosted tool can hold the profile, controls, evidence, risk register and action plans, which covers the tracking function. It does not, on its own, make your controls effective or produce an independent assessment. CISO Assistant, for example, is AGPL-3.0-only and ships more than 200 frameworks, with risk assessments, applied controls, evidence, remediation action plans and a third-party risk module. Its open-core model matters: files inside the top-level enterprise directory fall under the proprietary intuitem Commercial Software License and need a contract with intuitem. Confirm which features and files your deployment uses, and whether the OSCAL import path you need is covered by the community edition. Microsoft Purview Compliance Manager is an alternative for Microsoft environments and offers Essential Eight templates for all three levels.

How often should the Essential Eight GRC records be reviewed?

Review cadence should follow the recurring tasks of each strategy rather than a single annual date. Microsoft describes Essential Eight assessment and remediation as a point-in-time activity and recommends continuous monitoring for compliance and configuration drift, which is the reason to keep evidence feeds connected to the GRC tool. Scanning, patching, log review and backup restore tests all produce evidence on their own schedules, so the GRC tool should show the date of the last evidence for each control and flag gaps. Agree the review cycle for risk acceptances, control owner attestations and the ASD profile version in use. Check the ASD publication dates for new profile releases so the tracked control set stays current.

What does an implementation partner do compared with an assessor?

An implementation partner prepares the systems, controls, evidence and tracking records, and the organization keeps ownership of its controls. The partner may load the ASD profiles, configure the GRC tool, connect evidence sources, document procedures and support remediation. An assessor, which is an independent party qualified to assess against the maturity model, tests whether each strategy is implemented and effective, and issues the assessment result. DeployOpen plans, implements, integrates and documents self-hosted platforms in the client's own environment and runs security testing, but it does not issue audit reports, attestations or certifications. Agree in writing which party produces each artifact before work starts, and confirm the assessor's independence and scope with the assessor directly.

Can the ASD OSCAL files be used with any GRC tool?

ASD says the OSCAL profiles can be loaded into GRC tooling to track implementation, so the format is designed for machine import. Whether a particular tool imports a given profile, how it handles the nested control sets, and whether it keeps the control identifiers intact are product questions you need to test. Load the ISM catalog and the Essential Eight profile into a test instance, then check the control count against the 46, 87 and 123 controls in the v2026.09.4 profiles. The ISM catalog and profile sources are on the ASD ISM OSCAL repository. Record any differences before relying on the import for evidence.

How DeployOpen sets up Essential Eight tracking and evidence

DeployOpen plans and builds Essential Eight tracking inside your own infrastructure, loading the ASD OSCAL baseline profiles into a self-hosted GRC tool so that each ML1, ML2 or ML3 control has an owner, an implementation record and linked evidence. Your organization owns its controls and its maturity decisions, and an independent assessor issues any assessment outcome.

How we scope

Confirm the target maturity level for each strategy before loading any profile.
Agree in writing which systems, business units and tools the GRC tracking covers.
Define control owners, review cadence and the evidence sources each control draws on.
Engagements are fixed-scope, with deliverables and timelines agreed before work starts.

How we build

Load the ASD ISM Essential Eight profiles in OSCAL into the selected self-hosted GRC platform.
Map each in-scope control to its implementing system, configuration and evidence source.
Test that records, owners and evidence links resolve correctly before handover.
Confirm the chosen tool's licensing and edition limits against your intended use first.

How we hand over

Document the tracking model, control ownership and evidence procedures in writing.
Deliver a register showing each control's status, supporting evidence and open actions.
Walk your team through updating records so the tracker stays accurate after go-live.
Provide a written summary of the assessor-facing evidence location for each control.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer.
Retainers can cover profile updates when ASD publishes a new ISM or E4EIT release.
Periodic reviews can check for configuration drift and stale evidence between assessments.
Ask for the retainer scope in writing, separate from the initial fixed-scope build.

Tracking the Essential Eight in a GRC tool with ASD's OSCAL profiles