What an Essential Eight compliance checklist must verify at Maturity Level 1
When a customer, contract or regulator asks for Essential Eight maturity, there is no certificate to hand over. Compliance means showing that each of the eight mitigation strategies is implemented at Maturity Level 1 against the ASD Information Security Manual Essential Eight ML1 profile, which contains 46 controls in ISM v2026.09.4. The checklist is the working list that maps those controls to your systems, owners and evidence. You own the controls and the checklist. An implementation partner can configure systems, collect logs and assemble evidence, but only an independent assessor issues the assessment outcome. The ASD Essential Eight maturity model explains what each level requires and is the right starting point before you build the list.
Start the checklist with the controls that produce the most recurring evidence. For patching, record the automated asset discovery frequency, the vulnerability scanning cadence for each asset class, and the patch deadline for each severity. The ML1 profile sets different cadences for online services, internet-facing systems, common user applications and workstation operating systems, so one general scanning schedule will not satisfy it. For application control, confirm that it is enforced on workstations and covers the user profiles and temporary folders used by operating systems, browsers and email clients. For MFA, list every online service that processes or stores your sensitive data and confirm that each one authenticates human users. For privileged access, confirm that each privileged human user has a dedicated account used only for privileged duties and that access requests are validated when first made.
Treat the remaining controls as checks you must be able to repeat on request. Confirm that Microsoft Office macros are disabled for users without a demonstrated business need and blocked when they originate from the internet. For backups, do not stop at proof that backups run: schedule a restoration test to a common point in time as part of a disaster recovery exercise and keep the results. Then record who owns each check, how often it runs and where the evidence is stored. Confirm with your assessor which artifacts they will accept, such as scanner exports, configuration screenshots or ticket records, before you collect them.
Scanning cadences and patch deadlines to check first
Patching is the part of Essential Eight Maturity Level 1 that assessors test most mechanically, because each scanning cadence and patch deadline leaves a dated record. The cards below cover asset discovery, the four scanning cadences and the four patch deadlines, with the ISM control IDs to check for each one.
Fortnightly automated asset discovery
Scanning only finds what the inventory contains, so discovery comes first. ML1 requires automated asset discovery at least fortnightly (ISM-1807). Check that discovery runs on a schedule, that its output is kept, and that the last two or three runs are dated within the fortnight. Compare the discovered list against your CMDB or device inventory and record the gaps. Assessors will ask for the scheduler configuration and the run history, not a summary written for the audit.
Daily scanning of internet-facing systems
Online services and internet-facing operating systems are the exposure that adversaries reach first, so ML1 sets the tightest scanning rhythm for them. Vulnerability scanning must run daily for these systems (ISM-1698). Verify it by pulling scan job logs for a sample of internet-facing hosts and confirming there is no gap longer than a day. Also confirm that the scanner's credentials cover those hosts, since an unauthenticated scan can miss findings that matter.
Weekly scanning of common user applications
Browsers, office suites, PDF readers and similar common user applications change often and are heavily targeted. ML1 requires vulnerability scanning of these applications weekly (ISM-1701). Check the scanner's application coverage list against the software your users actually run, because a scan that omits a common application produces a clean report that proves nothing. Keep the weekly job history and the finding tickets raised from it.
Fortnightly scanning of workstation operating systems
Workstation operating systems are scanned fortnightly under ISM-1699, a longer cadence than internet-facing systems because the exposure is different. Confirm that workstation scan policies are enabled for every device class, including laptops that connect only intermittently. Devices that are off-network during scheduled runs are a common gap, so check whether the scanner or agent reports on their next connection and how those late results are recorded.
48-hour deadline for critical online issues
Vulnerabilities that are vendor-critical or known to be exploited, in online services and internet-facing systems, must be patched within 48 hours (ISM-1876 and ISM-1877). This is the deadline most likely to be missed, because it depends on fast triage as well as fast deployment. Verify it by matching each qualifying finding's detection time against its patch completion time in the change record, and keep exception approvals for any finding that could not be closed in time.
Two-week deadlines for other issues
Other vulnerabilities in online services and internet-facing systems, and all vulnerabilities in common user applications, carry a two-week deadline (ISM-1690 and ISM-1694). Check that the deadline is set in the tracking system when a finding is raised, not reconstructed later from the patch date. Sample closed findings and confirm each was fixed within fourteen days or has a documented, approved exception.
One-month deadline for OS patches
Workstation and internal server operating systems have a one-month deadline (ISM-1691 and ISM-1695). This longer window suits the wider testing that operating system updates usually need. The evidence is the patch deployment report for each device class, showing the date a fix was released, the date it reached the device, and any devices still outstanding. Ask your team to name the owner of every device that falls past the deadline.
Maturity Level 1 checks for each of the eight strategies
Patching sets the clock at ML1. The organization must know what it runs, scan it on a cadence matched to exposure, and fix vulnerabilities within fixed deadlines. Online services and internet-facing systems get the tightest scanning and deadlines, while workstations and internal servers get longer windows. Assessors test both the cadence and whether deadlines were met, so the evidence is scan history and patch records, not the policy alone.
- Asset discovery: automated discovery of assets at least fortnightly (ISM-1807).
- Scanning cadence: daily for online services and internet-facing operating systems, weekly for common user applications, and fortnightly for workstation operating systems (ISM-1698, ISM-1701, ISM-1699, ISM-1702).
- Fast deadlines: 48 hours for vendor-critical or exploited vulnerabilities in online services and internet-facing systems (ISM-1876, ISM-1877).
- Standard deadlines: two weeks for other such vulnerabilities and for common user applications, and one month for workstation and internal server operating systems (ISM-1690, ISM-1694, ISM-1691, ISM-1695).
- Evidence: scan reports dated within each cadence, and a patch log that links each finding to a fix date.
Confirm that your scanner covers every asset class your discovery finds, since a scanner that misses assets can pass a cadence test on paper while leaving gaps.
MFA scope at ML1 is deliberately tied to data sensitivity. It applies to online services that hold sensitive data, not to every login. Privileged access sits alongside it: requests are validated when first made, and administrative work is kept in separate accounts. Both controls depend on an accurate register of which services hold which data, so classification is the starting point for the assessment.
- Sensitive data services: MFA authenticates human users to the organization's own online services and to third-party services that process, store or communicate its sensitive data (ISM-1504, ISM-1679).
- Third-party services with non-sensitive data: MFA is required where the service makes it available (ISM-1680). Confirm availability for each vendor.
- Validated privileged requests: requests for privileged access are validated when first requested (ISM-1507).
- Dedicated admin accounts: privileged users hold a dedicated privileged account used only for privileged duties (ISM-0445).
- Evidence: identity provider exports showing MFA enforced per application, a register of online services classified by data sensitivity, approved access requests, and an inventory of privileged accounts.
Check the service register first, because MFA scope follows data classification. An outdated classification leaves services outside the assessment without anyone noticing.
These two strategies limit what can run. Application control restricts execution on workstations to an organization-approved set, and macro restriction turns off Microsoft Office macros unless a business need is demonstrated. At ML1 the scope is workstation user profiles and the temporary folders that browsers, email clients and operating systems use, which is where many malicious payloads land.
- Workstation application control: application control is implemented on workstations (ISM-0843).
- Profiles and temporary folders: the control is applied to user profiles and temporary folders used by operating systems, web browsers and email clients (ISM-1870).
- Macros disabled by default: Office macros are disabled for human users without a demonstrated business requirement (ISM-1671).
- Internet macro blocking: macros in files originating from the internet are blocked (ISM-1488).
- Evidence: the application control policy and rule set, enforcement block logs, a list of macro exceptions with business justifications, and Group Policy or Intune settings showing the macro configuration.
Review the macro exception list closely. Each exception needs a documented business requirement, and an assessor will reasonably ask for that justification item by item.
User application hardening at ML1 removes common attack paths in web browsers, Microsoft Office, PDF software and PowerShell, beginning with blocking Java and advertisements. Regular backups must be made, protected and proven recoverable. At ML1, that proof is a restore test covering data, applications and settings to a common point in time, run as part of disaster recovery exercises.
- Hardening scope: browsers, Microsoft Office, PDF software and PowerShell, with Java and advertisements blocked at ML1.
- Control IDs: confirm the ML1 hardening control IDs in the ISM catalog before building the evidence set.
- Backup coverage: data, applications and settings are backed up, kept in sync and protected from modification.
- Restore testing: restoration to a common point in time is tested as part of disaster recovery exercises (ISM-1515).
- Evidence: configuration baselines for each application, backup job logs, and dated restore test records showing the point in time restored and the result.
Confirm that the restore test covers data, applications and settings together, since a test that restores only files will not show what ISM-1515 asks for.
Where MFA scope, privileged accounts and macro settings usually fail
The three checks that most often produce gaps at Maturity Level One are MFA scope, dedicated privileged accounts and Office macro settings. Each looks finished on a configuration screen, which is why assessors test them against the population of accounts, services and files rather than against a policy document. Start with MFA. ISM-1504 and ISM-1679 require MFA for human users of the organisation's own online services and of third-party online services that process, store or communicate sensitive data. The usual failure is an inventory problem: a SaaS tool bought by a business unit, a finance or HR portal outside the identity provider, or a vendor-hosted service that receives sensitive files but was never added to the register. Build the list from SSO logs, expense records and the data classification register, then confirm each sensitive-data service enforces MFA for every user, including administrators and contractors. Where a third-party service holds only non-sensitive data, ISM-1680 asks for MFA where it is available, so record that check too.
Privileged accounts fail in a different way. ISM-0445 requires privileged human users to hold a dedicated privileged account used only for privileged duties, and the common gap is an administrator who still browses the web, reads email or runs daily tasks from the same account. The check is to compare the list of accounts holding administrative rights with the list of accounts that show interactive administrative sign-ins, then ask whether any dual-purpose account exists. ISM-1507 adds that requests for privileged access must be validated when first requested. Evidence for this is a dated request record for each grant, showing who approved it, the business reason, the systems covered and the approver's independence from the requester. Ask your identity team for a sample of recent grants and confirm each one has all four elements.
Macro settings fail when the policy is correct but the exceptions are undocumented. ISM-1671 requires Office macros to be disabled for human users without a demonstrated business requirement, and ISM-1488 requires macros in files from the internet to be blocked. Check the effective setting on sampled workstations rather than the group policy definition, then confirm that every user or group with macros enabled has a recorded business justification and an owner who reviews it. Test the internet-origin block with a benign file that carries the mark of the web, and keep the result as evidence. Confirm the exact configuration keys and any Microsoft 365 or Intune setting names with your platform team and Microsoft's current documentation before you write them into the checklist.
How to test restores and set the recurring review calendar
This sequence makes the backup restore test a dated, repeatable exercise and sets the review calendar that keeps the Maturity Level 1 checklist accurate as the organization moves toward Maturity Level 2 and Maturity Level 3. Each step ends in a record an assessor can read.
Confirm the restore scope and common point in time
Start by listing the systems, data sets, applications and settings that the disaster recovery exercise must cover. The restore must bring these back to a common point in time, which is the requirement behind ISM-1515, so the owner of each backup job should confirm which snapshot or backup set represents that point. The backup administrator and the system owners sign off on the scope. The output is a short, dated scope statement that names each system and the recovery point it will be restored to.
Run the disaster recovery restore test
Execute the restore in a controlled environment that does not overwrite production data. Restore the in-scope data, applications and settings together, then check that the restored set is consistent with the chosen point in time. Record who ran the test, the start and end times, the backup set used, and any errors or manual steps. Where a restore fails, log the failure and the fix rather than quietly rerunning the job. The output is a test log with the outcome for each system.
Verify restored systems and data integrity
Confirm that the restored environment works as intended. System owners should check application function, data completeness and configuration settings against the expected baseline. Compare restored items with the recovery point scope from the first step. Any gap becomes a finding with an owner and a remediation action. The output is a signed verification record that links each restored system to its check results.
Close findings and update the backup procedure
Turn every failed step or verification gap into a tracked action with an owner and a target date set by the organization. Update the backup and restore runbook so the next exercise follows the corrected steps. Store the updated runbook version alongside the test record. The output is a closed or tracked findings register and a dated runbook revision.
Record the restore test as Essential Eight evidence
File the scope statement, test log, verification record, findings register and runbook revision together in the evidence repository, indexed to the backup strategy and ISM-1515. Use the same identifiers across records so an assessor can trace one test from scope to closure. Confirm with the independent assessor which evidence format they accept. The output is a complete, dated evidence package for the restore test.
Set the annual application control ruleset review
Add a recurring task to validate application control rulesets. ISM-1582 requires validation at least annually from Maturity Level 2, so Maturity Level 1 organizations should schedule the review now to build the habit and the evidence trail before they move up. The reviewer compares current rulesets against approved software and records any exceptions. The output is a dated review record for each ruleset, with approvals and changes.
Set the annual Office trusted publisher review
Add a second recurring task for the Microsoft Office trusted publisher list. ISM-1676 requires this list to be reviewed at least annually at Maturity Level 3. Maturity Level 1 and 2 organizations gain little from waiting, because a reviewed list makes the macro controls easier to defend. The reviewer checks each publisher entry against current business need and removes stale ones. The output is a dated review record listing entries kept, added and removed.
Publish the review calendar and assign owners
Combine the restore test, both annual reviews and the Maturity Level 1 checklist recurrences into one calendar with named owners and review dates. Confirm the calendar with the accountable executive and store it with the checklist. The output is a single dated calendar that shows what recurs, who owns it and where each record is filed, ready for the next assessment.
What the checklist costs and who gets paid
This table separates the cost components of meeting Maturity Level 1 across the eight strategies, showing who is paid for each, whether it is one-time or recurring, and what changes its size. Read it before requesting quotes so each proposal can be compared on the same components. No prices or durations are stated because none are supplied for this topic; confirm figures against a written scope.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Internal control owner time | Your own staff (no external payee, but a real cost) | Both: setup is one-time, reviews recur | Number of systems in scope, how many owners hold more than one strategy, and how much evidence is already collected |
| Vulnerability scanning and asset discovery tooling | Tool licensing or hosting, or the team running a self-hosted scanner | Recurring | Asset count, cadence required for online services versus workstations, and whether scanning output feeds patch deadlines automatically |
| Patch and deployment tooling | Software vendor license or internal platform team | Recurring, with a one-time setup for device management | Mix of operating systems and applications, and whether patch deadlines can be tracked against the 48 hour, two week and one month windows |
| Application control and macro configuration | Internal engineers or an implementation partner under a written scope | One-time build, then recurring ruleset reviews | Number of workstation profiles, legacy applications needing exceptions, and the annual validation of rulesets expected from ML2 |
| Backup and restore testing | Storage and backup software costs, plus staff time for restore exercises | Recurring storage, periodic restore testing | Data volume, retention period, and how often restores are exercised as part of disaster recovery |
| Implementation partner fees | External implementation partner, paid under a fixed written scope | One-time for build, optional retainer for upkeep | Scope boundaries, number of strategies covered, and whether evidence collection is included. Request deliverables, timelines and exclusions in writing |
| Independent assessor fees | Independent assessor or reviewer, not the implementation partner | Recurring if reassessed on a cycle your contract or regulator sets | Assessment scope, evidence readiness, and how many strategies and systems are sampled |
| Recurring compliance reviews | Internal governance staff or a retained partner | Recurring | Frequency of reviews, number of evidence artifacts to refresh, and whether GRC tracking is automated |
What must be in place before an Essential Eight assessment
An assessor tests evidence, not intent. Five conditions decide whether an Essential Eight assessment can start on time: named owners, a trustworthy asset inventory, current access registers, documented settings and dated restore records. Each one is checkable internally before anyone outside the organization is invited in.
Named control owners per strategy
Each of the eight strategies needs one accountable person who can explain the implementation, the settings in force and the last time they were reviewed. Assessors ask owners questions directly, and a strategy with no owner usually has no current evidence. Check that every owner can name the systems in scope for their strategy, the tool that enforces it and the date of their last review. Record the owner in your GRC register so the link survives staff changes.
Asset inventory behind the scan cadence
The ML1 patching cadences only mean something if the inventory they scan is complete. Automated discovery must run at least fortnightly, so the inventory should show when each asset was last seen and which group it belongs to, such as online service, internet-facing, workstation or internal server. Check for assets seen by one tool but not another, and for internet-facing systems that are missing from the list. Gaps here make every later patch deadline unprovable.
Current MFA and privileged account register
Keep one register listing every online service that processes sensitive data, the MFA method each uses and the human users enrolled. Alongside it, list every privileged account, its owner and confirmation that it is dedicated and used only for privileged duties. Check the register against the identity provider, not against memory: an account that exists in the directory but not in the register is the finding an assessor is most likely to raise. Note the date each privileged request was validated.
Documented macro and application control settings
Record the current Microsoft Office macro policy, including which users have a demonstrated business requirement, and the rule that blocks macros in files from the internet. Export the application control ruleset for workstations and confirm it covers user profiles and temporary folders used by operating systems, browsers and email clients. Compare the exported settings to the policy documents and note any exceptions with an approver and expiry. An assessor will test the live configuration, so the export should match it.
Dated restore test records
Restoring backups to a common point in time must be tested as part of disaster recovery exercises. Keep dated records showing what was restored, which systems and data were included, who ran the test and whether settings and applications came back consistent with the data. A backup job log shows that backups ran; it does not show that anything can be restored. Check that the most recent exercise is recent enough to be credible for the period under assessment and that failed steps have tracked fixes.
Who owns each checklist item and who only prepares evidence
The organization owns every item on the checklist. It decides which maturity level it is targeting, sets the patch and scanning cadences it will commit to, approves exceptions, and accepts residual risk where a control cannot be met. Those decisions belong to named individuals, and they should be recorded in a way that survives staff changes. Outsourcing work does not transfer accountability for whether a control operates day to day.
- Target level and scope: Choosing ML1, ML2 or ML3 per strategy, and naming the systems inside scope.
- Risk acceptance: Signing off any control that is not met, with a dated rationale and an expiry.
- Operating the control: Running patch cycles, reviewing scan results and approving privileged requests.
- Recurring reviews: Revalidating application control rulesets and other periodic tasks on schedule.
- Policy and ownership: Assigning owners for each strategy and keeping the register current.
Confirm that each checklist line has a named internal owner and a review date before any partner starts work.
An implementation partner such as DeployOpen prepares the systems, configurations and evidence that the organization relies on. In a fixed-scope engagement, this usually covers deploying scanning and logging tools inside the client's own environment, hardening configurations, documenting settings, and packaging the output so an assessor can trace each checklist item to a result. The partner does not issue reports, attestations or certificates, and does not decide whether a control passes.
- Systems and configuration: Building scanning, application control, backup and MFA configurations in the client's infrastructure.
- Evidence preparation: Exporting configuration records, scan outputs and restore test logs in a form the assessor can review.
- Documentation: Writing runbooks and procedures that the organization adopts and maintains.
- Knowledge transfer: Training internal staff so the controls keep working after the engagement ends.
- Ongoing support: Optional retainers for upgrades, retesting and periodic evidence refresh.
Check that the written scope names each deliverable, states who owns the outputs, and says plainly that the partner does not issue assessment outcomes.
An independent assessor tests whether each strategy is implemented and whether it is effective against the maturity model. The Essential Eight is a set of mitigations rather than a certification scheme, so there is no ASD certificate. The assessor's output is the assessment outcome, reached by independent testing rather than by accepting the partner's documentation at face value. Independence means the assessor is not the party that built the controls being tested.
- Testing: Sampling systems, examining configurations and re-performing scans or restore tests.
- Effectiveness: Judging whether controls work in practice, not only whether they exist on paper.
- Outcome: Issuing the assessment result that the organization reports against.
- Independence boundary: An assessor should not design or operate the controls it evaluates for the same engagement.
- Reporting: Documenting findings the organization must address or formally accept.
Confirm the assessor's independence arrangements in writing and ask how it will treat evidence produced by an implementation partner.
Most organizations outsource the build and the evidence, and keep the decisions and the operation. Work that is commonly outsourced includes tool deployment, configuration hardening, log and backup architecture, and evidence collection. Work that usually stays internal includes target-level decisions, exception approvals, privileged access requests, and the recurring reviews that keep a control current. Costs for outsourced work depend on scope, the number of systems and how many environments are involved.
- Typically outsourced: Deploying scanning, logging and backup tooling, and writing initial configurations.
- Typically internal: Approving privileged access, accepting risk and running daily operations.
- Shared: Writing procedures, where the partner drafts and the organization approves.
- One-time versus recurring: Build work is one-time, while reviews, patch cycles and restore tests recur.
- Quote inputs: Ask for the systems in scope, the target level and the deliverables listed by name.
Before signing, confirm which checklist items the quote covers and which remain with your own team.
The independence boundary separates the party that prepares evidence from the party that judges it. If one firm both configures a control and certifies that it works, the assessment loses credibility with regulators, customers and the organization's own board. A partner can make the evidence clear and complete, but it should not mark its own homework. Keeping roles separate also protects the organization when an assessor challenges a finding.
- Separate parties: The partner builds and documents, while the assessor tests and rates.
- No self-certification: Neither the partner nor the organization's own staff issues the outcome.
- Evidence trail: Each checklist item should link to its configuration, its test result and its owner.
- Re-testing: Remediation work should be verified by someone other than the person who fixed it.
- Conflicts: Ask the assessor whether it has previously built controls for the same organization.
Ask your assessor to confirm in writing which parts of the evidence it will rely on and which it will test independently.
Essential Eight checklist questions buyers ask before hiring help
Is there an Essential Eight certificate I can obtain?
No. The Essential Eight is a set of mitigation strategies rather than a certification scheme, so there is no ASD certificate to buy or display. Maturity is shown by assessing how each of the eight strategies is implemented and how well it works against the maturity model. Any firm offering an Essential Eight certificate is selling a report or attestation, so ask which independent assessor issues it, what criteria it tests against, and what the output document actually says. An implementation partner can prepare systems and evidence, but it does not issue the assessment result. You own the conclusion you present to your board, a regulator or a customer.
How long does a Maturity Level 1 checklist take to complete?
The supplied facts do not give a duration, so confirm the timeline in writing with your assessor and any implementation partner before work starts. The main drivers are how many systems and user profiles are in scope, how much of the environment already has automated asset discovery, vulnerability scanning and patch reporting, whether backups have ever been restore-tested, and how quickly your change process can approve application control rules and macro settings. Ask for a fixed-scope plan that lists each of the eight strategies, the evidence for each and the owner who signs off. Scope agreed in writing is the best predictor of a schedule you can hold.
Can our own team run the Essential Eight checklist without outside help?
Yes, many organizations work through the checklist internally, provided they have people who can administer identity, endpoints, backups and logging, and who can produce evidence on request. The work splits into configuration, which your engineers perform, and independent testing, which an assessor performs. Internal teams often struggle with the evidence side: showing scan results over time, restore test records and privileged account reviews in a form an outsider can follow. Decide early who owns each strategy, who prepares evidence and who checks it, and whether an independent party will review the result before it reaches leadership.
What do we need to provide to start the work?
Expect to supply a current asset inventory, your identity provider and MFA configuration, the list of privileged accounts and who may request them, endpoint management details, the current macro and browser settings, your patch reporting and vulnerability scan history, and backup job records with any previous restore tests. Access matters as much as documents: partners working in your environment need named accounts, change windows and a contact who can approve decisions. Without these inputs, the first weeks usually go to discovery rather than remediation. Ask the partner to list every input it needs in the written scope.
Which recurring reviews apply at Maturity Level 1?
At Maturity Level 1, the recurring work centers on operational cadences rather than annual governance cycles. Automated asset discovery runs at least fortnightly, and vulnerability scanning runs daily for online services and internet-facing operating systems, weekly for common user applications and fortnightly for workstation operating systems. Patch deadlines are tracked against 48 hours, two weeks and one month, depending on the asset and vulnerability type. Backups need restore tests as part of disaster recovery exercises. The annual validation of application control rulesets and of Microsoft Office's trusted publisher list begins at higher levels, so check which applies to the level you are targeting.
Which Essential Eight controls can an implementation partner handle, and which must stay with us?
A partner can configure scanning, patch reporting, application control policies, MFA enrollment, privileged account separation, macro and browser settings, and backup jobs, and it can document how each one was set up. The organization must keep decisions that carry business or legal weight: which accounts are privileged, which applications are approved, how long backups are retained and who approves exceptions. Accountability for each control stays with you. Ask the partner to name the control owner for each strategy in the written scope, so nothing sits unowned after handover.
What should a quote for this work include?
A useful quote lists the systems in scope, the eight strategies at the target maturity level, each deliverable with its evidence, the assumptions about your environment, and the responsibilities split between your team and the partner. Costs recur in some areas, such as scanning, patch reporting and backup operations, while configuration work is typically one-time, so ask which lines are which. Cost rises with the number of endpoints, the number of identity systems, the amount of legacy software and the state of your existing backups. DeployOpen does not publish a price list, and a quote follows from the written scope. Ask the assessor separately for its fees, since it must remain independent of the implementation work.
How DeployOpen prepares systems and evidence for your checklist
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so the Essential Eight checklist items are met on systems you control. We prepare the systems and evidence for an independent assessment, while your organization owns its controls and the assessor issues any conclusions.
How we scope
- Engagements are fixed-scope, with the checklist items, systems and deliverables agreed in writing before work starts.
- The written scope names which of the eight strategies and maturity level targets are covered, and which are left to your own teams.
- We confirm the environments in scope, including cloud accounts, endpoints, servers and online services that hold sensitive data.
How we build
- We configure scanning cadences, patch deadline tracking, application control, MFA scope and privileged account separation against the checklist.
- We set up backup jobs and restore test procedures so the restoration tests produce records an assessor can review.
- We document each configuration decision and map it to the ISM control identifiers that the checklist references.
How we hand over
- You receive configuration records, runbooks and evidence packs for each checklist item, organized by strategy.
- We define the recurring review tasks, such as application control ruleset validation, so your team knows who runs them and how often.
- Handover sessions walk your staff through running the controls and collecting evidence without us in the loop.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial scope is delivered.
- A retainer can cover re-running scans, reviewing patch deadline exceptions and refreshing evidence before an assessment.
- Confirm with us in writing which support items sit inside a retainer and which fall under a separate fixed-scope piece of work.
