Can the Essential Eight at Maturity Level 1 satisfy the SOCI Act CIRMP?
Section 8(4) of the *Critical infrastructure risk management program (CIRMP) Rules 2023* lists the Essential Eight Maturity Model at maturity level one as one of five cyber frameworks a responsible entity can comply with under the *Security of Critical Infrastructure Act 2018*. The other four are AS ISO/IEC 27001:2015, the NIST Framework for Improving Critical Infrastructure Cybersecurity, C2M2 at Maturity Indicator Level 1, and the 2020-21 AESCSF Framework Core at Security Profile 1. Your organization owns its controls and its compliance position. An implementation partner can prepare systems and evidence, but the choice of framework, its scope and accountability for the program stay with your leadership team.
Which option fits depends on the entity: its asset types, existing certifications, what its regulator and customers already accept, and whether operational technology sits beside corporate IT. The same ML1 control can be evidenced very differently in a Microsoft estate than in a Linux and industrial environment, so the scope statement matters as much as the framework label. Before committing, confirm three things in the CIRMP Rules: the compliance window in section 8(3), which allows 12 months after the end of the applicable period in subsection 4(2), the start date that subsection sets for your entity, and the conditions attached to equivalence under section 8(5). If you already hold another framework, ask in writing whether it qualifies and which conditions apply.
At ML1, the ISM Essential Eight profile lists 46 controls. The focus is practical: application control on workstations, MFA for online services holding sensitive data, dedicated and separated privileged accounts, macro blocking, browser hardening, patch deadlines and vulnerability scanning cadences, and backups with restore testing. Map these to your asset register first, because gaps there are the most common reason an ML1 position cannot be shown. The Essential Eight is a set of mitigations and has no certification scheme, so there is no ASD certificate to obtain. The evidence you keep is your own record of implementation and testing, and an independent assessor is the party who tests it if you choose one.
Which five frameworks does section 8(4) accept?
Section 8(4) of the CIRMP Rules lets a responsible entity comply by meeting one of five listed frameworks. Each one asks for different evidence, so the choice depends on what the entity already runs and what it can show an assessor without building a new program.
AS ISO/IEC 27001:2015
An information security management system standard. Choosing it means showing a documented management system: a defined scope, a risk assessment, a statement of applicability and evidence that controls operate. Entities with an existing ISO 27001 program, or a plan to build one for other reasons, often pick it. Check whether your certification or assessment covers the critical infrastructure asset in scope, since a certificate for a different business unit may not transfer. Confirm the edition and scope wording with the Department of Home Affairs guidance before relying on it.
Essential Eight at ML1
The Essential Eight at Maturity Level One asks for implementation of the eight mitigation strategies at the first maturity level. It is the most direct route for entities that already follow ASD guidance. The evidence centers on patch cadences, MFA scope, privileged account separation, application control on workstations, macro settings, browser hardening and backup restore tests. Confirm with your assessor which ISM Essential Eight profile they will test against, since the ML1 profile defines the control set.
NIST Cybersecurity Framework
The NIST Cybersecurity Framework organizes security outcomes into functions and categories rather than prescribing specific technical settings. Entities that already report against it can map their existing program to the framework's outcomes and show how each is governed, identified, protected, detected, responded to and recovered. It suits organizations with a mature enterprise risk function that prefers outcome language. Confirm which framework version the Department accepts for your entity, because the listed option in the Rules is the NIST Framework for Improving Critical Infrastructure Cybersecurity, and later versions may need an explicit basis.
C2M2 at Maturity Indicator Level 1
The Cybersecurity Capability Maturity Model (C2M2) is assessed by domain, with Maturity Indicator Levels describing practice maturity. Selecting MIL1 means showing the entry-level practices are performed and documented across the model's domains. Energy and utilities entities that already run C2M2 self-assessments commonly choose it. The evidence is practice-based: documented procedures, owners and examples of execution. Confirm the model version and scope boundaries with your assessor before preparing the submission.
2020-21 AESCSF Framework Core at SP1
The Australian Energy Sector Cyber Security Framework (AESCSF) Framework Core is a sector-specific model used by energy market participants. Choosing Security Profile 1 of the 2020-21 Core means showing the profile's practices are in place for the entity's assets. It fits energy entities already assessed under AESCSF. Confirm that the 2020-21 version is the one the Rules name, because AEMO has moved to later AESCSF releases and the Rules reference this specific Core. Check whether your existing assessment still reflects that Core before choosing this path.
How the 12-month compliance window works
Section 8(3) of the CIRMP Rules, as made, gave responsible entities 12 months after the end of the applicable period in subsection 4(2) to comply with a listed framework. The clock does not start on a single date printed in the Rules. It runs from the end of a period that subsection 4(2) sets, and that period depends on the asset class the entity operates. Before you plan anything, confirm with your own counsel or the Department of Home Affairs which period applies to each of your assets, and write down the resulting deadline with the reasoning behind it. An entity that cannot show how it reached its date has no defensible starting point when a regulator asks.
Treat the window as a deadline to plan against, and do not count on it as spare time. The 12 months has to cover more than configuration. For the Essential Eight at Maturity Level One, it must absorb a gap assessment across all eight strategies, changes to patch deadlines and scanning cadences, MFA and privileged account remediation, and enough operating history to show that each control runs. Work backward from the date. Decide who owns the entity's compliance decision, who prepares the evidence, and whether an independent assessor will review it before the deadline. Set internal milestones early, because remediation often exposes vendor dependencies and change windows that take longer to clear than the technical fix.
Read the as-made text alongside the latest compilation of the CIRMP Rules. The current compilation adds section 8A on enhanced cyber and information security requirements, so a plan built only from the as-made text can miss obligations that apply today. Check whether section 8A applies to your asset, whether it changes the framework you must comply with, and whether it alters the timing in section 8(3). Record which version of the Rules you relied on and the date you checked it, because the compilation can change and your deadline calculation should show which text it was based on.
What ML1 asks across the eight strategies
Patching covers two Essential Eight strategies, patch applications and patch operating systems. At ML1 the ISM ML1 profile expects vulnerability scanning on a defined cadence and patches applied within set deadlines, with the deadline depending on the severity of the vulnerability and whether it is being actively exploited. The profile also expects unsupported software to be identified and dealt with rather than left in service.
- Scanning cadence: Scan internet-facing and internal systems on a schedule written into a procedure, and keep the scan schedule and coverage reports as evidence.
- Patch deadlines: Apply patches within the deadlines the ISM sets for each severity class, and retain the change records that show when each patch was deployed.
- Unsupported software: Maintain an inventory of applications and operating systems that have reached end of support, with a documented plan to remove or isolate them.
- Exceptions: Record every missed deadline with an approved risk acceptance, owner and expiry date.
Ask the assessor which scan exports and deployment logs they will sample, and confirm that your inventory matches what the scanner sees.
This family covers multi-factor authentication and restriction of administrative privileges. At ML1, the ISM ML1 profile expects MFA for online services that hold sensitive or privileged data, and for privileged access, including the use of separate, dedicated accounts for administration. Standard user accounts should not be used for administrative tasks, and admin accounts should not be used for ordinary browsing or email.
- MFA scope: Identify which online services hold sensitive data, enforce MFA on each, and keep the list of covered services current.
- Dedicated admin accounts: Issue separate privileged accounts, distinct from daily user accounts, and document who holds them.
- Account separation: Show that privileged accounts are not used for email, web browsing or other routine work.
- Privilege review: Keep a current list of privileged accounts and the approvals behind each one.
Ask the assessor how they will test MFA coverage, usually by comparing the identity provider configuration with your list of sensitive services.
This family covers application control and restriction of Microsoft Office macros, along with user application hardening. At ML1, application control is expected on workstations, so that only approved executables and scripts can run, and macros in Microsoft Office are blocked from the internet and disabled by default. User application hardening at ML1 includes blocking Java in browsers and blocking advertisements, along with other browser settings the ML1 profile sets.
- Application control: Enforce an allowlist of approved applications on workstations, with a documented process for adding new ones.
- Macro blocking: Disable macros from the internet and by default, and record the Group Policy or Intune settings that enforce this.
- Browser hardening: Configure web browsers to block Java and advertisements, and retain the policy export that shows the settings.
- Policy evidence: Keep configuration exports and test results, such as a sample workstation showing a blocked execution attempt.
Ask the assessor whether they will test settings on live endpoints, since configuration policy alone may not be enough for the control to be considered in place.
Regular backups is the final Essential Eight strategy. At ML1, the ISM ML1 profile expects backups to be taken, kept and tested by restoring them. A backup that has never been restored is not evidence that recovery will work, so restore tests and their results carry as much weight as the backup schedule itself.
- Backup coverage: Define which systems and data are backed up, and document the frequency and retention for each.
- Restore testing: Run restore tests on a schedule and keep the records of what was restored, when, and whether it worked.
- Access control: Limit who can access and delete backups, and record the accounts with those rights.
- Backup monitoring: Keep job logs that show failed and successful backups, and how failures were resolved.
Ask the assessor which restore test records and job logs they will sample, and confirm that restore tests cover the systems you have said are critical.
How to plan ML1 against the CIRMP deadline
This sequence takes an entity from confirming its obligation to a documented Maturity Level One position it can show a regulator, with each phase producing an artifact the next phase depends on. It keeps scope, baseline, remediation and evidence in order so gaps are found early rather than discovered during review.
Confirm the applicable period and compliance window
Start with legal counsel or the compliance lead reading section 8(4) and the timing provisions in section 8(3) of the CIRMP Rules against your entity's obligations. Confirm which applicable period in subsection 4(2) applies to your asset class and the date your 12-month window closes. Output: a written note stating the framework you have chosen, the deadline, and who signed off on the choice. Ask your regulator or advisor to confirm any entity-specific dates, because the note should rest on the current compilation of the Rules.
Define in-scope systems and owners
Identify the critical infrastructure assets and the supporting systems, identity services, endpoints, servers, backup platforms and online services that the CIRMP program covers. Assign a named owner to each system category and record the boundary in an asset register. Output: a scoping statement and an asset inventory that the board and assessor can read without asking follow-up questions. Systems left out of scope should have a stated reason, because reviewers test the boundary before they test controls.
Baseline current state against the ML1 profile
Map your current controls to the Essential Eight Maturity Level One requirements, using ASD's ISM Essential Eight ML1 baseline profile as the checklist. Your team or implementation partner records, for each control, whether it is met, partly met or not met, and what evidence exists today. Output: a gap register with one line per control, a current-state rating, and the evidence reference for each met control. Teams that already run an ISM or NIST mapping can reuse supporting evidence where the mapping collection indicates it applies.
Close patching and vulnerability scanning gaps
Address the patch applications and patch operating systems strategies first, because they usually carry the most gaps and depend on asset inventory from the earlier phases. Set scanning cadences and patch deadlines as defined at ML1, retire or isolate unsupported software, and record exceptions with an approver and an expiry date. Output: scan reports, a patch compliance report for a sample period, and a documented exception register. Confirm the exact cadences and deadlines against the ASD maturity model, not against internal policy alone.
Close identity, privilege and application control gaps
Work through multi-factor authentication for online services with sensitive data, dedicated and separated privileged accounts, and application control on workstations. Each change should go through change control with a rollback plan, and test accounts and allow-lists in a pilot group before wider rollout. Output: an MFA coverage report, a privileged account list showing separation from daily-use accounts, and application control policy exports with the test results. Confirm the MFA scope in the baseline profile before you report coverage as complete.
Harden macros, browsers and backups
Apply the macro blocking settings and user application hardening controls to Microsoft Office, browsers, PDF software and PowerShell, then configure backups for the ML1 requirements, including restore testing. Restore tests must be performed and recorded, because an untested backup does not satisfy the control in practice. Output: configuration baselines exported from management tools, a macro policy record, and dated restore test reports with the results and any failures remediated. Keep the restore test logs as evidence for the assessor.
Collect and organize evidence for each control
Assemble evidence in a single repository organized by control ID, with the date, the system covered, the person who produced it and where the original sits. Check that each piece of evidence shows implementation and that it is current, not a one-off screenshot taken for the review. Output: an evidence index with a status column that a reviewer can trace from each control to its artifact. Self-hosted GRC tooling can hold this index if the organization owns the data.
Arrange independent review where required
Confirm with the board, the regulator and your internal audit function whether an independent review is needed to support your position. If it is, scope the review in writing before work starts, stating the controls, systems, evidence and dates it covers, and agree who receives the report. Output: a written review scope, the reviewer's findings, and a remediation plan for anything open. Only the independent reviewer issues an assessment conclusion; the implementation partner prepares the systems and evidence the reviewer tests.
What must be in place before an assessor reviews ML1
An assessor reviewing Maturity Level One against the Essential Eight will expect a short set of records to exist before fieldwork begins. These six items show what the organization owns, what the assessor will sample, and where a gap would stall the review under a CIRMP obligation.
Scoped asset register
Every assessment starts with a defined boundary: which workstations, servers, cloud tenants, online services and backup systems fall inside the Essential Eight scope. Ask whether the register lists owners, operating systems and internet exposure for each asset, and whether the critical infrastructure asset in the CIRMP is traceable to it. An assessor who finds unlisted systems will question every patch and MFA claim that depends on them.
Named owner for each strategy
Each of the eight mitigation strategies needs one accountable owner with a written remit, a deputy and a review date. Check that the owner can state the current ML1 settings for their strategy without consulting a vendor. Shared ownership with no single name usually means the evidence for patch cadences or macro settings is scattered across teams and goes stale between reviews.
Current ISM ML1 mapping
Map each organizational control to the Essential Eight Maturity Level One baseline profile in ASD's Information Security Manual OSCAL release, which lists the ML1 controls by identifier. The mapping should record the control, the implementing system, the evidence location and the last test date. Confirm the profile version you map to, because the ISM is revised and a mapping against an outdated release can miss new requirements.
Evidence repositories with retention
Assessors sample evidence rather than accept statements, so each strategy needs a repository that holds scan exports, MFA enrollment reports, privileged account lists, application control policy, macro settings and backup logs. Check that each item has a timestamp, a source system, a named custodian and a retention period set in writing. Evidence collected once for an audit and never refreshed will not show that the control operated over time.
Restore test records
The regular backups strategy at ML1 requires backups to be tested by restoration, and an assessor will ask to see the results rather than the backup schedule. Keep dated records that show which systems were restored, who performed the test, what data was recovered and what failed. Confirm that restores were tested from the backup copy the organization would rely on in an incident, not only from a live replica.
Governance record of the chosen framework
Under the CIRMP Rules, the responsible entity must comply with one listed framework, so the board or accountable officer should have a minuted decision naming the Essential Eight at Maturity Level One as that framework. The record should show that the officer understands what ML1 covers, who approved the scope and when the compliance position is next reported. Check whether the decision also addresses any equivalent framework the entity relies on under section 8(5).
Who owns the program, who prepares evidence and who assesses it
The responsible entity is the organization that holds the critical infrastructure asset and carries the obligations under the Security of Critical Infrastructure Act 2018 and its CIRMP Rules. Choosing the Essential Eight at Maturity Level One as the framework to comply with does not transfer that obligation to anyone else. The entity decides its risk profile, selects the framework, sets the target maturity, accepts residual risk and answers to the Department of Home Affairs. Ownership also covers the day-to-day controls: someone inside the organization must approve privileged access, own the patch decisions and sign off backup restore tests.
- Accountable executive: A named person must own the CIRMP and the decision to comply with the Essential Eight, not only the technical team that runs it.
- Control ownership: Each of the eight strategies needs an internal owner who can explain the configuration and the exceptions.
- Risk acceptance: Any gap against ML1 must be recorded and accepted by the entity, with a dated plan to close it.
- Regulatory dialogue: Only the entity communicates with the regulator on its compliance position.
- Ongoing operation: Scanning, log review and restore testing recur, so the entity must fund and staff them after any partner has left.
Before signing any engagement, confirm in writing which of these decisions remains with your staff and which, if any, a partner is authorized to make on your behalf.
An implementation partner such as DeployOpen works inside the entity's own infrastructure to prepare the systems the Essential Eight depends on. Typical work includes configuring application control, hardening browsers and Office, setting MFA policies, separating privileged accounts, deploying scanning and logging tools, and building backup and restore procedures. The partner also prepares the evidence those controls produce, such as configuration exports, scan reports, restore test records and change logs. The partner does not decide whether the entity complies, does not sign a compliance statement for it and does not issue any report or certificate.
- Systems and configuration: The partner builds and hardens the environment against the ML1 profile and documents what was changed.
- Evidence preparation: The partner organizes configuration baselines, screenshots, exports and test records so the entity and its assessor can trace each claim.
- Gap analysis: The partner can map current state against ASD's ISM Essential Eight profiles and report the gaps, without judging the outcome.
- Handover: Runbooks, owner assignments and recurring task calendars should transfer to the entity at the end of the engagement.
- Scope limits: Confirm that the written scope names the systems, sites and cloud accounts covered, because an assessor will test only what the entity puts in scope.
Ask the partner to show which evidence it will hand over, in what format and to whom, before work begins.
An independent auditor or assessor tests whether the controls exist and operate as described, then records the result in a report or opinion that the entity can present to others. The Essential Eight is a set of mitigations rather than a certification scheme, so ASD issues no certificate and no body can award an official Essential Eight certificate. The assessor's role is therefore to examine implementation and effectiveness against the maturity model and the ISM baseline profiles, and to state its findings. Because the assessor must be independent, it should not have designed or configured the controls it tests.
- No certificate: Any document offered as an ASD Essential Eight certificate should be treated with suspicion.
- Independence: The assessor should be separate from the team that implemented the controls, so ask how conflicts are managed.
- Testing method: Expect sampling, configuration review, interviews and re-performance of restore tests, not only document reading.
- Reporting: Ask what the assessor's output will look like and which findings it will report if a control is only partly met.
- Engagement terms: Agree the scope, the deliverable and who receives the report before the assessor starts.
Confirm the assessor's qualifications and accreditation for your jurisdiction with the assessor itself and with the regulator, rather than relying on a marketing claim.
What usually delays ML1 or inflates its cost
Most delays in reaching Maturity Level One come from a few predictable gaps rather than from the technical work itself. Each card below names one gap, explains why it matters for a critical infrastructure risk management program, and gives a check to run before the work starts.
Treating ML1 as a one-off project
Teams often finish a sprint of configuration, call the job done, and then let scanning, patch cadences and access reviews drift. Under the CIRMP Rules, the framework is evidenced at a point in time, but the controls behind it must keep operating. Ask who owns each recurring task, how often it runs, and where the evidence is stored. Budget for those recurring tasks in the same quote as the initial build.
Unscoped asset inventories
Patch cadences, application control and MFA scope all depend on knowing which systems, applications and online services exist. An inventory that omits cloud tenants, shadow SaaS or operational technology leaves gaps an assessor will find. Define the scope boundary first, including which assets fall under the entity's critical infrastructure asset register, then reconcile discovery tools against that list.
Backup restores never tested
Many organizations can show that backups run but cannot show that a restore works. The Essential Eight backup strategy expects restores to be tested, and an assessor will ask for the most recent test record. A restore test that has never been performed usually surfaces missing credentials, undocumented dependencies or corrupt data at the worst moment. Schedule a documented restore of a representative system and keep the result as evidence.
MFA covering only some online services
MFA is often enabled for the flagship portal and the email platform while smaller online services, vendor portals and remote access paths remain on passwords alone. Assessors test the population of services, not the ones the team remembers. Export the identity provider's application list, compare it with the asset inventory, and record an exception with an owner and end date for anything that cannot yet support MFA.
Legacy applications blocking patch deadlines
A single unsupported line-of-business application can hold back operating system or browser updates, and the patch deadlines in the Essential Eight then fail for the whole estate. Costs rise when the team has to rebuild or isolate that application late in the program. Identify unsupported software early, decide between upgrade, replacement and isolation, and document the risk acceptance for any exception that remains.
Relying on a mapping list as proof
A crosswalk showing that an Essential Eight action appears alongside another framework does not establish equivalence under the CIRMP Rules. Equivalence depends on the conditions attached to the accepted framework, and the entity must still show its own implementation and effectiveness. Ask the regulator or legal counsel to confirm the equivalence position in writing, and keep evidence specific to the Essential Eight control set.
Questions buyers ask about Essential Eight and the CIRMP
Is Maturity Level 1 enough for every responsible entity under the CIRMP?
Not automatically. Section 8(4) of the CIRMP Rules lists ML1 as one of five accepted frameworks, so an entity that meets ML1 can satisfy that part of the Rules, but the choice of framework belongs to the responsible entity. Entities that already run ISO/IEC 27001, the NIST Cybersecurity Framework, C2M2 or the AESCSF may find one of those a better fit. Confirm with the Department of Home Affairs or your counsel how the Rules apply to your asset and your sector before you commit to a framework, because the obligations attach to the entity's own risk management program.
What does the CIRMP compliance window mean in practice?
Section 8(3) of the CIRMP Rules gave responsible entities 12 months after the end of the applicable period in subsection 4(2) to comply with a listed framework. Read the exact start and end dates in the as-made text and the current compilation, not in summaries, and confirm with the Department of Home Affairs how the period applies to your entity. In practice, plan backward from the deadline: assessment, gap remediation, evidence collection and sign-off all need time, and the window is not extended by starting late.
How is an equivalent framework confirmed as acceptable under the CIRMP?
Section 8(5) of the CIRMP Rules accepts a framework equivalent to a listed one, including its conditions, so equivalence is a legal question rather than a technical one. Do not assume a framework is equivalent because it covers similar controls. Ask the Department of Home Affairs for its position in writing and have counsel review the conditions attached to the listed framework. Keep the written response with your CIRMP records so an auditor or regulator can see how the decision was reached.
Can our own team implement ML1 without outside help?
Often yes, if you have staff who can administer the systems involved and the time to document the results. The work spans eight strategies, including application control, MFA scope, privileged account separation, macro settings, patch cadences and backup restore testing, so the effort usually sits across identity, endpoint, server and backup teams. Ask whether the people doing the work have authority to change production systems, and whether anyone independent will test the outcome. Your organization owns its controls. An implementation partner can prepare systems and evidence, but only an independent assessor or auditor issues an assessment result.
What drives the effort and cost of reaching ML1?
The main drivers are the size and age of the estate, the number of online services and workstations in scope, how much of the environment already has managed identity, endpoint and backup tooling, and how much documentation is missing. One-time costs include discovery, configuration, hardening and the first assessment. Recurring costs include scanning, patch management, access reviews, backup restore tests and evidence upkeep. No ASD source supplies a price for ML1, so ask any provider for a quote built from a written scope that lists systems, deliverables and who performs each task, and ask which costs recur each year.
How does the Essentials series relate to ML1 evidence?
ASD's Essentials series is a newer set of publications, and its first chapter, the Assessment evidence guide for enterprise IT (version 2026.10.15, published 15 October 2026), is published in OSCAL. Its mapping collection references the Essential Eight dated 02 Oct 2024 alongside the ISM, NIST CSF 2.0 and NIST SP 800-171r3, so evidence you collect for ML1 may already support parts of the Essentials guidance. Confirm with ASD's published material which evidence items carry over, and confirm with the Department of Home Affairs whether the Essentials series changes how a CIRMP framework is assessed.
What should we ask a partner before signing an engagement?
Ask for a written, fixed scope that names the systems in scope, the eight strategies and maturity level, each deliverable, the timeline and what the partner will not do. Confirm who issues any assessment result, since an implementation partner prepares systems and evidence but does not certify the entity. Ask how evidence will be handed over, who keeps the ML1 records after the engagement and what ongoing support costs. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, and provides quotes from a written scope rather than a published price list.
How DeployOpen works on this
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Essential Eight and the SOCI Act CIRMP, we prepare the systems and evidence that support Maturity Level One, while your organization owns its controls and an independent assessor or auditor issues any report.
How we scope
- Confirm which CIRMP framework your program relies on and that ML1 is the Essential Eight level in use.
- Map the eight strategies against your environment, listing in-scope systems, accounts, users and backup sources.
- Agree deliverables, exclusions and timelines in a written, fixed-scope document before any work starts.
How we build
- Configure patch scanning cadences, patch deadlines, application control, MFA scope and macro settings to the ML1 baseline profile.
- Separate dedicated privileged accounts and set up backups with restore testing in your own cloud accounts or data centers.
- Test each strategy's implementation and effectiveness, recording results against the ISM ML1 controls it supports.
How we hand over
- Deliver a control-by-control evidence pack showing configurations, scan outputs, access reviews and restore test records.
- Document the operating procedures and recurring tasks your staff need to keep ML1 current after handover.
- Confirm with your assessor which evidence format and scope they expect before the evidence pack is finalized.
How we support
- Offer ongoing support, upgrades and continuous testing through a retainer if you want help keeping ML1 current.
- Review changes to configurations, the ISM profiles and the CIRMP Rules as they affect your evidence and controls.
- Keep your organization in ownership of its controls, with DeployOpen providing preparation and technical support only.
