Introduction

Australian boards are no longer spectators in cyber. Between regulators, litigators and the media, directors are now expected to understand cyber risk, oversee it as a core part of the risk framework, and be able to show that they have done so with care and diligence.

In recent years we’ve seen that expectation harden into law and practice. APRA’s CPS 234[1] makes boards “ultimately responsible” for information security in regulated entities. The Security of Critical Infrastructure Act (SOCI)[2] requires boards of critical infrastructure entities to approve annual reports on their critical infrastructure risk management programs. The Privacy Act’s Notifiable Data Breaches[3] scheme and high-profile actions such as those following the Medibank breach have pushed “reasonable steps” to secure personal information into the mainstream governance conversation. ASIC’s successful action in ASIC v RI Advice[4] confirmed that failing to maintain adequate cyber risk management can breach core licence obligations. And the ASX Corporate Governance Principles[5] now explicitly call out cyber security and privacy as contemporary risks boards must ensure are addressed in their risk frameworks.

The question we hear most from directors and CISOs alike is simple: how do we turn all of our reporting obligations and security programs into something we can govern coherently?

That is exactly where the Ionize GRC Maturity Model can help.

The Evolving Cyber Obligation for Australian Boards

Under the Corporations Act, directors must exercise care and diligence, act in good faith in the best interests of the company, and ensure the company has adequate systems to manage its risks. Regulators and the courts have now made it clear that cyber is part of that core risk set, not a side issue.

APRA’s CPS 234 is blunt: the board of an APRA-regulated entity is ultimately responsible for information security and must ensure that the entity’s information security capability and controls are commensurate with threats to its information assets. Its companion guide CPG 234[6] goes further, setting out the sort of information boards should receive including – roles and responsibilities, capability sufficiency, strategy execution, and assurance over controls so they can oversee and challenge management effectively.

ASIC has used the outcome of ASIC v RI Advice to send a message that inadequate cyber risk management can breach Australian Financial Services License (AFSL) obligations to act efficiently and fairly and to maintain adequate risk management systems. The Federal Court accepted that cyber risk is a “significant risk” tied to the conduct of financial services, and that while risk cannot be reduced to zero, it can be materially reduced through adequate documentation and controls. ASIC has been explicit that it expects boards to treat cyber as part of mainstream governance and is willing to take enforcement action where failures are egregious.

For listed entities, the ASX Corporate Governance Principles require boards to establish a sound risk management framework and periodically review its effectiveness (Principle 7). The associated guidance now makes it explicit that this includes contemporary and emerging risks such as cyber security, privacy and data breaches.

Owners and operators of critical infrastructure face additional “positive security obligations” under the SOCI Act, including mandatory incident reporting and the requirement to adopt and maintain a Critical Infrastructure Risk Management Program (CIRMP). The legislation requires an annual report on the CIRMP to be submitted within 90 days prior to year end, and if the entity has a board or governing body, that report must be approved by the board. Guidance from the Cyber and Infrastructure Security Centre[7] (CISC) emphasises that this is not a box ticking exercise but genuine board level assurance over how material cyber, physical, personnel and supply chain hazards are being managed.

On the privacy side, entities subject to the Privacy Act are required to take reasonable steps to secure personal information and, under the Notifiable Data Breaches scheme, to notify affected individuals and the OAIC when a breach is likely to cause serious harm. OAIC guidance on data breaches stresses the need for tested response plans, clear roles, rapid assessment and post-incident remediation all squarely in the territory boards are expected to oversee.

Overlaying this, the Australian Institute of Company Directors[8] (AICD), together with the Cyber Security CRC[9], has published Cyber Security Governance Principles[10] and detailed guidance on “Governing Through a Cyber Crisis”[11]. These documents frame cyber as a core board responsibility and organise board thinking around readiness, response, recovery and remediation.

In short: Australian boards are expected to own cyber as a governance issue, not just a technology one, and to be able to demonstrate that ownership.

The Ionize GRC Maturity Model in brief

The Ionize GRC Maturity Model is designed to give that increasingly complex obligation a simple, layered structure.

It describes the maturity of an organisation’s security and GRC capability across five layers:

1. Governance and policy foundation – scope, roles, committees, policy suite, obligations register.
2. Control implementation and documentation – System Security Plans, incident and recovery plans, Essential Eight and other baseline controls, operating procedures.
3. Risk management and gap remediation – cyber risk methodology, integration with enterprise risk, treatment of ISM/Essential Eight gaps, tracking of findings.
4. Monitoring, audit and performance evaluation – logging and detection, incident handling, internal audit, control testing, metrics and governance reporting.
5. Integrated GRC platform and continuous control monitoring – a system of record for risks, controls, obligations and incidents, with data feeds and dashboarding that enable continuous oversight.

Unlike many abstract models, each layer is defined in terms of concrete artefacts, roles and behaviours. That is what makes it useful to a board i.e. it bridges the gap between regulatory language and the day-to-day machinery of cyber governance.

Figure 1 Ionize GRC Maturity Model

Turning fragmented obligations into a single, board-level narrative

One practical value of the Ionize model is that it lets you translate a messy list of statutory and regulatory obligations into a single picture the board can understand and interrogate.

Obligations around roles, accountability, policy and tone from the top e.g. directors’ duties under the Corporations Act, CPS 234’s requirement to define information-security roles and responsibilities, SOCI’s expectation of effective governance over critical assets, and AICD’s cyber principles, these all sit naturally in Layer 1. This is where the board can see whether it has set clear expectations for cyber, approved an appropriate policy and governance framework, and ensured there is a consolidated, current view of obligations.

Requirements to implement appropriate controls, maintain incident response and recovery capability, and notifiable data breach response plans fall into Layer 2. CPS 234’s focus on implementing controls commensurate with threat and systematically testing them is a classic Layer 2 concern, as are the expectations in OAIC guidance that organisations prepare and rehearse data breach response plans.

The heart of the directors’ obligation to manage foreseeable risk, including under SOCI’s risk management program requirements all reside within Layer 3. The CIRMP obligation to identify material hazards, minimise or eliminate them where reasonably practicable and mitigate their impacts is a risk-management statement. The requirement for an annual, board approved report on the program simply formalises the oversight expected at this layer.

Layer 4 is where CPS 234’s emphasis on ongoing testing and assurance, and ASIC’s expectations flowing from RI Advice, come into focus. Boards need evidence that the risk management framework and controls are working via logging and monitoring, incident statistics, internal audits, control tests and trend reports. This layer is also where ASX Principle 7’s call to ensure the risk framework deals adequately with cyber and data risks becomes concrete. The evidence is either there in the assurance program and metrics, or it is not.

Finally, Layer 5 deals with sustainability and repeatability. With a credible, integrated GRC platform and continuous control monitoring, boards can receive consistent, reporting including a single view of risks, incidents, findings and obligations, automated feeds from vulnerability management, identity systems and logging, and dashboards that support both regulatory reporting and public disclosure when necessary. This is increasingly important for regulated entities that must provide regular reports to APRA, CISC, OAIC and ASX investors from a coherent data set rather than manual collation.

By mapping each obligation into one or more of these layers, the CISO and risk team can give the board a structured, comprehensible spine for all the moving parts.

Giving boards a maturity-based view they can stand behind

Boards ultimately need to answer three questions: where are we now, is that adequate given our risk profile and obligations, and what is our plan to close the gap?

The Ionize model has been purposefully designed to describe a simple maturity scale for each layer. For example, from “not in place” through “ad hoc” and “defined” to “embedded and measured”. Against that scale, the CISO can work with management to build an evidence-based view of current maturity.

The board might be told, in plain language, that governance and policy (Layer 1) are at a defined stage i.e. policies exist; roles are written down; obligations are catalogued however risk integration and assurance (Layers 3 and 4) are still largely ad hoc, with inconsistent risk assessments, patchy audit coverage and limited cyber metrics. That picture can be anchored directly to the external expectations already described. An example would be highlighting that a Layer-1/2 strength, but a Layer-3/4 weakness is misaligned with CPS 234, SOCI, or ASX governance guidance for an organisation of that particular size and sector.

Because the model is layered, boards also see dependencies. If the foundations of governance and control documentation are weak, it is far easier for a director to understand why management is arguing against a premature investment in complex tooling and can recognise that such an investment might not satisfy regulatory expectations if the basics are not in place. Conversely, if governance and controls are strong but assurance and monitoring are not, directors can see that the immediate priority is independent testing, metrics and reporting, not more policy.

When minutes of board and committee meetings reflect this structured discussion and when the board can show it receives regular reporting against the layers it becomes far easier to demonstrate that directors have exercised the care and diligence regulators expect in relation to their cybersecurity obligations.

Helping cyber teams turn obligations into a roadmap the board can fund

From the perspective of the CISO and their team, the Ionize model is equally valuable. It provides a disciplined way to turn regulatory language into a portfolio of work the board can understand, prioritise and fund.

A sensible approach is to begin with a structured assessment, using the layers as lenses and the organisation’s obligations as reference points. Evidence from audits, incidents, IRAP assessments, Essential Eight reviews, SOCI preparations and privacy investigations is sorted into the relevant layer. Workshops with technology, risk, operations and business leads fill in the gaps.

The result is a concise diagnostic identifying which layers are strong, which are fragile, and where the organisation is attempting to operate at a higher layer than its foundations support. That diagnostic is then converted into a multi-year roadmap that deliberately builds upward:

• strengthening governance, policy and obligations management
• standardising and documenting controls and response playbooks
• integrating cyber risk into enterprise risk and CIRMP-style frameworks
• building an assurance program and metrics that align with CPS 234, ASX and AICD guidance
• and finally, implementing or extending GRC platforms and continuous control monitoring to make all this sustainable.

Because initiatives are explicitly tied to layers and obligations, board papers can explain not just what needs to be done, but why it matters in regulatory terms. For example, a request to uplift monitoring, testing and reporting (Layer 4) can be directly connected to CPS 234’s requirement for systematic testing and APRA’s guidance on the information boards should receive, as well as the lessons from RI Advice about adequate risk management systems.

That kind of traceability makes budget discussions more grounded and easier to either approve or discount.

Structuring board reporting and cyber crisis governance

The Ionize model also gives a straightforward structure for board and committee reporting.

Rather than receiving a scatter of technical metrics and incident anecdotes, boards see regular reports organised by layer. This could include a short commentary and a small set of indicators for governance, controls, risk, assurance and platform. This aligns well with both CPS 234’s guidance on board information needs and the AICD’s cyber governance principles, which emphasise the importance of clear, decision relevant reporting and the ability to challenge management.

In a cyber crisis, the same structure can underpin governance. AICD’s “Governing Through a Cyber Crisis” highlights the board’s role across readiness, response, recovery and remediation. The Ionize layers map neatly over that arc:

• readiness grounded in governance and controls (Layers 1 and 2)
• response and recovery driven by risk understanding and monitoring (Layers 3 and 4)
• remediation tracked and sustained via integrated platforms and continuous monitoring (Layer 5).

Directors can use that structure to frame their questions in the heat of an incident and to oversee the quality of post-incident reviews and longer-term remediation.

Conclusion: a backbone for board-level cyber governance

The reality for Australian company boards is that cyber obligations are only going in one direction. Regulators now expect directors to be able to show that they have taken cyber seriously as an enterprise risk, that they have ensured appropriate capabilities, controls and assurance are in place, and that they have overseen incident response and recovery in a way that is consistent with their duties.

The Ionize GRC Maturity Model does not remove those obligations. What it does is provide a clear framework that connects them to the real work of security and risk teams. It turns a patchwork of CPS 234 clauses, SOCI rules, Privacy Act expectations, ASX principles, ASIC enforcement signals and AICD guidance into a single, layered view of how cyber is governed, controlled, tested and reported in your organisation.

For boards, that means a way to engage with cyber that is structured, comprehensible and evidence based. For CISOs and their teams, it means a way to express their reality in governance language and to build uplift roadmaps the board can own and fund.

In a landscape where “we thought IT had it covered” is no longer an acceptable answer, having that framework matters.

[1] cps_234_july_2019_for_public_release.pdf

[2] Security of Critical Infrastructure Act 2018 (SOCI)

[3] PRIVACY AMENDMENT (NOTIFIABLE DATA BREACHES) ACT 2017 (NO. 12, 2017) – SCHEDULE 1

[4] Australian Securities and Investments Commission v RI Advice Group Pty

[5] Corporate governance principles and recommendations

[6] cpg_234_information_security_june_2019_1.pdf

[7] Critical Infrastructure Security Centre

[8] Australian Institute of Company Directors (AICD)

[9] Cyber Security Cooperative Research Centre | Cyber Security Cooperative Research Centre

[10]  cyber-security-governance-principles-web3

[11] Governing Through a Cyber Crisis – Cyber Incident Response and Recovery for Australian Directors

A short read by CEO and Managing Director of Ionize Cyber Security, Andrew Muller

In my experience of securing organisations against cyber security threats, inside and out, I’ve often heard people argue that security compliance and certifications are pointless.

“They do not make an organisation good at security.” That may be true, but it only answers half the question.

What do they do? What is their true nature?

In the business world, security compliance and certifications are not really about security. Peel back the platitudes and doublespeak, and what they actually represent is an important avenue for market access.

That might sound cynical — but it is largely true.

Frameworks and certifications like ISO/IEC 27001, IRAP, SOC 2, and the Essential Eight among others, rarely mean an organisation is “secure.” What they prove is that an organisation can document, evidence, and audit its controls.

To be fair, that’s a good start. But on their own, they do not prevent, detect, respond, or recover from cyber-attacks.

And that is the point.

Certifications reduce risk for the buyer. They create a common language between vendors and customers. They allow procurement teams to shortlist suppliers. They enable entry into government panels, enterprise ecosystems, and regulated industries.

In other words: they unlock markets.

Real security is cultural. It is an operational discipline. It is how incidents are handled at 2am, not how policies read at 2pm.

Certifications matter — but we should be honest about their true nature. They are:

✔️ A trust signal
✔️ A procurement enabler
✔️ A competitive differentiator
❌ Not a guarantee of security.

The strongest companies understand and leverage both sides. They pursue certification for commercial access and for continued existence. At the same time, they invest in real security, because cyber resilience supports long-term viability.

While this thesis holds true in the business world, the inverse applies to regulators and governments. What compels them to achieve compliance or certification? Is the public going to start “shopping” at another Department of Health?

In these cases, we might observe waning compliance with standards (ASD reported a decline in E8 ML2 compliance from 25% to 15% between 2023 and 2024). There are several possible explanations for this decline, but the key question remains: does it matter? What are the consequences? Individual careers may be affected, but an organisation’s existence is unlikely to be threatened.

What is threatened are the Ministers responsible for those government functions. If government departments consistently fail to meet these benchmarks and breaches occur (as they do now), then constituents may vote accordingly.

This is much slower and less direct than in the business world where CEOs are held to account quickly by shareholders and boards. But it can still occur.

In short, understanding the true nature of both business and government allows us to encourage and support their security certification and compliance objectives. However, this must be done in the context that resonates with them, one that motivates the right decisions.

Security compliance and certifications are not for everyone. Investment should only be committed if it helps the organisation achieve its goals.

Introduction

As Principal of the Ionize GRC team and CISO, I spend a lot of time with colleagues across government who are simultaneously managing PSPF, ISM, Essential Eight, IRAP, DISP, portfolio-specific directions and an ever-growing backlog of projects. The Ionize GRC Maturity Model is designed to bring structure and coherence to that complexity.

In this paper, I outline how I would apply the model to assess your current position and shape a cybersecurity program that is coherent, defensible and genuinely fundable.

A Single Framework for a Very Noisy Environment

The Ionize GRC Maturity Model is structured as five levels that describe how a security and GRC capability matures over time:

• Level 1 – Governance and policy foundation
• Level 2 – Control implementation and documentation (including SSPs, IRPs, DR/BCP and procedures)
• Level 3 – Risk management and gap remediation
• Level 4 – Monitoring, audit and performance evaluation
• Level 5 – Integrated GRC platform and continuous control monitoring.

Each Level is deliberately concrete. It is defined in terms of artefacts, roles, decision rights and behaviours, not abstract labels like “ad hoc” or “optimised”. It aligns to ISO 27001 and the reality of PSPF, ISM, Essential Eight and IRAP in the Australian Government context.

You can think of Levels 1–3 as building how you run security, Level 4 as proving it works overtime, and Level 5 as using platforms and automation to make it sustainable and visible.

Evaluating your current state with the model

To evaluate your current state, you treat those five levels as five lenses on the same security program – governance and policy, control implementation and documentation, risk management, assurance and monitoring, and integrated GRC and automation.

I recommend that you define a simple, consistent scale for each level. For example, from zero to three, where zero means not in place, one means ad hoc or inconsistent, two means defined and repeatable, and three means embedded and measured. You then run a structured assessment workshop with your direct reports and key stakeholders from governance, risk, architecture, SOC, operations, GRC and privacy, and work your way through the levels in turn. A detailed evaluation matrix is included at the end of this document.

Figure 2 Recommended Scale for Assessment

In the governance and policy level, you are evaluating the strength of your foundations. You examine whether there is a clearly defined ISMS and GRC scope aligned to PSPF and ISM obligations, whether roles and accountabilities are genuinely clear, whether security committees operate with meaningful charters, and whether your policy suite is consolidated, current and explicitly mapped to PSPF and ISM requirements. You also look for a single, maintained obligations register covering legislation, PSPF, ISM, Essential Eight, DISP and portfolio-specific directions, rather than tacit knowledge scattered across teams. The picture that emerges tells you how firm the ground floor really is.

Figure 3 Measuring your Foundations

In the control implementation and documentation level, the focus shifts from intent to practice. For your major systems, you assess the existence and quality of System Security Plans, incident response plans, disaster recovery and business continuity plans, and system operating procedures. You check whether these documents align with ISM expectations and the way systems are actually run, not just the way they were meant to be run when someone filled in a template three years ago. You review Essential Eight implementation against your stated target maturity levels and ask a simple question: how easily could we demonstrate control implementation and configuration to an IRAP assessor or an internal audit? This tells you whether your control environment is robust and evidence ready, or whether it relies on heroics and tribal knowledge.

In the risk management level, you look at how cyber risk is identified, analysed and tracked across the department. You examine whether there is a single, ISM aligned methodology that is used for projects, changes and enterprise risks; whether cyber risks appear coherently in the departmental risk register; and whether risk appetite and tolerance are articulated in a way that guides decisions, rather than just appearing in an annual report. You also check that Essential Eight and broader ISM gaps are captured as risks with explicit treatments, owners and timelines, rather than living only in technical reports. This shows you whether “risk-based” is a reality or a distant aspiration.

In the assurance and performance level, you evaluate your feedback loops. You examine how logging, detection and incident response line up with ACSC guidance and your own risk scenarios; how internal audits, control tests and Essential Eight spot checks are planned and executed; and how findings from IRAP, ACSC engagements and internal reviews are captured, prioritised and driven through to closure. You are looking for evidence that issues and weaknesses are managed within a disciplined assurance program, rather than treated as isolated fires.

Finally, in the integrated GRC and automation level, you look at how all of this is stitched together in systems and data. You determine whether there is a single system of record for risks, controls, obligations, incidents and audits; whether PSPF, ISM and Essential Eight reporting can be generated reliably from a common data set; and to what extent continuous control monitoring is in place for vulnerability management, logging coverage and Essential Eight telemetry. You also assess whether dashboards and reports based on that data are actively used by your executive and governance committees or produced solely for compliance.

When you pull this together ideally in a simple heatmap or narrative summary, you end up with a very clear picture level by level, where you are strong, where you are fragile, and where you are trying to operate at a higher level than your foundations support. That picture is far more useful than a standalone E8 score or PSPF rating.

Reconciling PSPF, ISM, Essential Eight and IRAP

Every Federal Government department is living with multiple forms of maturity reporting, PSPF self-assessments, Essential Eight maturity reporting to ACSC, ISM adoption expectations, IRAP reports on critical systems, and often portfolio specific requirements as well.

Figure 4- Level Assessment Heatmap

The Ionize model lets you do is put those reporting obligations into context.

If your Essential Eight maturity for patching and MFA is in stasis, you can ask whether that is truly a tooling problem, or whether it is hamstrung by weak standard baselines (Level 2), inconsistent risk prioritisation (Level 3) or the absence of meaningful metrics and ownership (Level 4). If your PSPF governance outcome is only “partially effective”, you can explicitly identify that as a Level 1 and 3 issue, rather than blaming tools or SOC processes in Level 4.

In other words, instead of having separate, sometimes contradictory scorecards, you have a single language for explaining why those scores look the way they do and what you intend to do to address the issues.

Turning diagnosis into a three-year roadmap

Once you have that level-by-level picture, the next step is to convert it into a roadmap.

I suggest that CISOs set realistic target levels by domain. You might decide that enterprise governance should reach Level 4 within three years, that high-risk or PROTECTED systems should target Levels 4–5, and that lower-risk business applications only need to solidify at Level 3. That immediately makes your program risk based and aligned with both ISM and Essential Eight guidance about tailoring controls to business criticality, rather than trying to do everything at once.

You then sequence initiatives according to dependency following a simple rule. Do not invest ahead of your level. If your governance is weak, fix that before rolling out a large GRC platform. If your controls are undocumented and inconsistent, address that before you invest into continuous monitoring. If you keep getting hammered in audits on the same themes, fix the underlying Level 2 and 3 issues rather than running more spot checks in Level 4.

From there, you group initiatives into a small number of streams within each level i.e. governance and policy consolidation, control and SSP standardisation, unified cyber risk framework and integration with enterprise risk, integrated assurance and Essential Eight validation, and then platform and automation once the foundations are in place. Each stream gets clear objectives, ownership, indicative timing and explicit links to your external obligations and internal pain points.

The result is a roadmap that reads logically upward through the levels, instead of a disconnected list of projects.

Figure 5 – Example High Level Roadmap

Embedding the levels in governance and reporting

The model really comes to the fore when you use it to reshape the way you report to the Secretary, the Executive Committee and the Audit and Risk Committee.

Rather than structuring your papers around technology silos (“network security”, “end-user computing”, “identity”, “projects”), you can frame them around the five levels. You provide a short narrative and a small set of indicators for each i.e. the health of your governance and policy baseline, the coverage and quality of your control documentation, the state of your cyber risk profile, the performance of assurance and monitoring, and the maturity of your integrated GRC and automation.

A set of carefully chosen measures under each level is usually enough. Examples could be the percentage of systems with current SSPs and IRPs, the proportion of high cyber risks with active treatment plans, the age and status of audit and IRAP findings, the spread of Essential Eight levels across key environments, the coverage of systems and controls in any GRC or monitoring platform.

Figure 6- Reporting on Capability Maturity

Presented this way, your program stops looking like a collection of technical initiatives and starts reflecting what it should be, the progressive construction of a resilient, auditable and transparent security capability.

Using the model with IRAP and ACSC

For systems heading toward IRAP assessment or increased ACSC scrutiny, the model helps you avoid wasting effort.

You can insist that any system be brought to at least a credible Level 3 with a clear governance context, documented controls and a coherent risk picture well before you send an IRAP assessor anywhere near it. Above that, you can aim to bring critical systems to Level 4 so that IRAP findings are naturally absorbed into your normal assurance and remediation machinery, instead of becoming separate, ad hoc workstreams every couple of years.

Similarly, you can take the inevitable shifts in Essential Eight guidance and maturity expectations and explain them through the levels. Which changes you must incorporate into Level 2 baselines, how they will be reflected in Level 3 risks and treatment plans, and how you will adjust Level 4 monitoring and validation to prevent regressions. That turns external assessments from surprises into inputs to your roadmap.

The value of the Ionize GRC Maturity Model for you as a CISO is that it gives you one coherent story that runs from where you are today to where you need to be. It lets you evaluate your current state in a structured, evidence-based way, to reconcile PSPF, ISM, Essential Eight and IRAP into a single picture, and then translate that picture into a practical, three-year roadmap that builds upwards through the levels. It gives you a clear, repeatable frame for how you talk about security with your Executive, and a disciplined way to turn IRAP and ACSC demands into planned work rather than constant disruption. Rather than a diagram on a slide the model becomes the organising logic for a security program that is risk-based, auditable and sustainable within the Federal Government context.

GRC Maturity Model Assessment

How to use the Matrix

1. Pick the scope – whole department, or a specific environment (e.g. PROTECTED systems).
2. For each row, ask your stakeholders which description (0–3) best matches reality today.
3. Capture evidence or examples as you go (systems, documents, reports, incidents).
4. Roll up scores per level (average or median) to see where you’re strongest and weakest.

Use the result to:

• Build a heatmap (levels vs criteria).
• Prioritise initiatives (e.g. fix Level 1/2 gaps before chasing Level 5 tooling).
• Explain to your Secretary and ARC why PSPF / ISM / E8 / IRAP outcomes look the way they do.

The Scoring Scale

Use the same scale for every row:

• 0 – Not in place
  No consistent approach; nothing formal, or only in pockets.
• 1 – Ad hoc / Fragmented
  Some practices exist but are inconsistent, person-dependent, or undocumented.
• 2 – Defined / Repeatable
  Documented, approved and used in most relevant areas; not yet fully measured or optimised.
• 3 – Embedded / Measured
  Widely adopted, routinely measured, continually improved; survives staff turnover and audit scrutiny.

Level 1 – Governance and Policy Foundation

Typical deliverables for a government security program at Level 1

• ISMS Scope Statement / System Boundary Diagram (text + architecture diagram).
• Information Security Policy (approved by executive) and associated policy register.
• Compliance Obligations Register (PSPF, ISM, Privacy Act, DISP mapping).
• Roles and Responsibilities Matrix (RACI) for security functions.
• Security Governance Charter / Terms of Reference for governance committees.
• Risk Management Framework & Risk Appetite Statement (methodology, scales, treatment options).
• Policy Review Schedule and Policy Owner Registry.
• Executive Briefing Pack (initial) outlining current posture, top risks, and required decisions/resourcing.

Level 2 – Control Implementation and Documentation

Typical deliverables for a government security program at Level 2

• ISM Annex A — control list with implementation status and rationale.
• System Security Plan (SSP) — full system-level control descriptions and implementation evidence.
• Control Implementation Matrix — mapping controls → procedures → evidence → owners.
• Operational SOPs and Runbooks — patching, backups, access provisioning, change control.
• Configuration Baselines & Hardening Guides — standard images and hardening scripts.
• Logging & Monitoring Implementation Document — SIEM data sources, retention, alerting rules.
• Supplier / Third-Party Control Evidence Pack — cloud provider attestations, vendor SOC reports, contractual security clauses.
• Statement of Residual Risk / Exceptions Register — documented, approved exceptions with compensating controls.

Level 3 – Security Risk Management and Gap Remediation

Typical deliverables for a government security program at Level 3

• Security Risk Management Plan (SRMP) — governance, methodology, roles.
• System-level Risk Register — scored risks, residual risk after controls.
• Enterprise Risk Register — aggregated strategic risks and trends.
• POA&M / Remediation Backlog — prioritised actions, owners, timelines.
• Risk Treatment Worksheets — decision records & executive approvals for accepted risks.
• Remediation Project Charters — for major uplift efforts (e.g., patching sprint, privileged access overhaul).
• Supplier Risk Assessments — for critical vendors with remediation plans.
• Evidence of Risk Reduction — after remediation: test results, configuration snapshots, updated control attestations

Level 4 – Monitoring, Audit and Performance Evaluation

Typical deliverables for a government security program at Level 4

• Security monitoring and incidents
  • Security monitoring / SOC plan (scope, log sources, retention, responsibilities)
  • SOC runbooks and incident playbooks
  • Evidence of centralised logging and monitoring coverage
  • Security incident register and significant incident PIRs / lessons learned
  • Regular vulnerability and patch management reports and exceptions register
• Audit, review and control testing
  • Annual cyber / internal audit and assurance plan (ISM / PSPF aligned)
  • Completed internal audit and IRAP reports with agreed actions
  • Control testing evidence (access reviews, config checks, E8 validation, etc.)
  • Consolidated register of findings / non-conformities with owners and due dates
• Performance, risk and governance reporting
  • Routine security governance packs for the Exec Committee / ARC (ISM, PSPF, E8, IRAP status)
  • Cyber risk dashboard linked to enterprise risk register
  • Defined and tracked KPIs/KRIs (incidents, vuln SLAs, findings age, etc.)
  • Governance minutes showing decisions, risk acceptance and reprioritisation
• Continuous improvement
  • Corrective action / continuous improvement register
  • Exercise plans and post-exercise reports (cyber, BCP/DR)
  • Updated policies, standards and procedures driven by findings and lessons learned

Level 5 – Integrated GRC Platform and Continuous Control Monitoring

Typical deliverables for a government security program at Level 1

• GRC platform as system of record
  • Configured GRC platform with agreed data model for risks, controls, obligations, incidents, audits
  • On-boarded systems, registers and workflows (risk, issue, findings, exceptions, approvals)
  • Data quality rules and ownership defined (stewards, reconciliations, completeness checks)
• Integrations and data feeds
  • Automated feeds from vulnerability scanners, asset inventories, identity systems, ticketing tools, SIEM/SOC
  • Integration with enterprise risk, project/portfolio and HR systems where relevant
• Continuous control monitoring (CCM)
  • Defined CCM use cases and mapped controls (e.g. E8, privileged access, patch SLAs, logging coverage)
  • Automated control checks with thresholds, alerts and exception workflows
  • CCM result dashboards showing pass/fail trends and coverage across systems
• Executive dashboards and decision support
  • Role-based dashboards for CISO, Executive Committee and ARC (PSPF/ISM/E8 posture, risks, incidents, findings, trends)
  • Regular use of these dashboards in governance forums, with decisions and actions recorded
• Reporting and external alignment
  • Standardised, repeatable reports for PSPF, ACSC / Essential Eight, IRAP remediation tracking and portfolio bodies
• Automation and workflow
  • Automated routing of incidents, findings, exceptions and approvals to the right owners
  • Reminder and escalation workflows for overdue risks, actions and attestations
  • Periodic policy / control attestations executed and recorded through the platform

For further information or a (no obligation) briefing on our GRC service offering and capability, please contact Ionize at sales@ionize.com.au  

END