A SOCI entity's board-approved annual CIRMP report must say whether its critical infrastructure risk management program was up to date and what impact any hazards had during the financial year. It is due within 90 days after 30 June, which is 28 September [1]. The FY2026-27 report is due 28 September 2027 [1].
The annual report is where a board puts its name to the state of the critical infrastructure risk management program (CIRMP). This article explains what the report needs to cover, what evidence supports it, and where information security classification fits in.
The short version: two questions and one deadline
The report comes down to two questions the board has to answer. Was the CIRMP current? And what was the impact of any hazards that occurred? [1]
The report is board-approved and is due within 90 days after 30 June, which is 28 September [1]. The FY2025-26 report was due on 28 September 2026 [1]. The next one, for FY2026-27, is due on 28 September 2027 [1]. If your entity has just lodged its FY2025-26 report, this is the quiet period to fix whatever the last cycle exposed, rather than start from scratch in August 2027.
This article explains what entities typically do. It is not legal advice. The exact content, form and lodgement requirements depend on your asset class, your regulator and the current rules, so confirm them against the Security of Critical Infrastructure Act and your sector regulator, and get advice for your situation. The Cyber and Infrastructure Security Centre publishes guidance on the critical infrastructure risk management program, which is worth reading alongside this article [1].
What the report has to cover
Based on the published guidance, the report has two core parts [1].
The first is currency. The report states whether the CIRMP was up to date over the reporting year [1]. In practice, that means the board is asked to confirm that the program still reflects the entity's critical infrastructure assets, its risks and its mitigations, and that any changes made during the year were captured.
The second is hazard impact. The report states the impact of any hazards on the asset during the year [1]. Hazards are the events the CIRMP is built around. A CIRMP typically addresses cyber and information security hazards, personnel hazards, supply chain hazards, and physical security and natural hazards. If a hazard materially affected the asset, the report is the place the board says so, and says how the program responded.
The report is approved by the board or equivalent governing body, not just prepared by management [1]. That changes how the document should be written. It needs to be clear enough for non-specialist directors to understand what they are approving.
Showing the CIRMP was current
A board cannot sensibly attest that a program is current without evidence. The question is what a director could point to if asked how they know.
Entities usually assemble a short evidence pack through the year, not in the weeks before 28 September. Useful items include:
- the date the CIRMP was last reviewed and who approved the review
- a list of changes to critical assets, systems, suppliers or ownership during the year, and whether the CIRMP was updated for each
- the register of material risks and the controls assigned to them
- results of testing, exercises or assurance reviews
- open actions from previous reviews and their status
If the program was not up to date at some point in the year, the report should say so plainly and explain what has been done about it. A candid report that records a gap and a fix is easier to defend than a clean report that cannot be backed up. If you are unsure how to describe a gap, take advice on how your regulator expects it to be reported.
Reporting the impact of hazards
The second half of the report asks about hazards and their impact [1]. The common mistake is to treat this as a list of incidents only. A board is better served by a short, structured account.
For each hazard category in the CIRMP, it helps to record whether anything occurred that affected the asset, what the impact was, how it was detected and handled, and whether the CIRMP or its controls changed as a result. Near misses are worth noting internally even where they do not meet a reporting threshold, because they show whether the controls behave as designed.
The cyber and information security category is often the hardest to evidence. It depends on knowing what information the entity holds, which of it is critical or sensitive, who can reach it and how it moves. Where that picture is incomplete, the entity may struggle to say with confidence what a hazard actually put at risk. That is where information classification matters.
Where information classification fits
The annual report does not ask for a classification scheme by name. But a board that is asked whether the program is current, and what a hazard affected, is relying on the entity's ability to describe its information and protect it in proportion to its importance.
A classification scheme gives the entity a shared language for that. Staff, suppliers and systems use the same levels, and each level has handling rules for storage, sharing, email, printing, transfer and disposal. When something goes wrong, the entity can say which level of information was involved and whether the handling rules were followed. When the board reviews the program, it can see that controls scale with business impact instead of applying one blunt standard everywhere.
TFIQ's Information security classification framework delivers this as a fixed-scope piece of work over 4 to 6 weeks. It produces a classification scheme of three to five plain-English levels based on business impact, handling rules for each level, labelling guidance for documents, email and systems, and an adoption plan with roles, communications and a phased rollout. The scheme is designed to align with ISO/IEC 27001:2022 Annex A controls 5.12, 5.13 and 5.14, and with the PSPF or a state framework where one applies. The labelling guidance is structured so it can later be configured as sensitivity labels, but configuring labels or DLP tooling is not part of this service. Nor does it include classifying or relabelling existing information, or delivering staff training.
Questions that tend to surface in the weeks before sign-off
Most entities hit the same friction points. Framed as questions a risk lead or CIO can ask internally:
- Do we have a current inventory of the information and systems the CIRMP depends on, or is it spread across teams?
- Are our policies and processes written down and used, or do some controls live in people's heads?
- Is there a data governance or information governance framework that the CIRMP can point to for information handling?
- Is our technology and security stack fragmented, so evidence has to be pulled from several tools by hand?
- Is the person coordinating the CIRMP doing it on the side of another job, and is there enough capacity to keep the evidence current all year?
None of these is a failing. They are the normal state for many mid-market and regulated organisations. They are worth asking early because each one makes the board attestation harder to give with confidence.
What the board needs to see
Board members do not need the technical detail, but they do need to be able to answer for the report. For a CEO, COO, General Counsel or Company Secretary, the useful summary is short.
First, a plain statement of whether the CIRMP was current, with the evidence behind it. Second, a short account of hazards that affected the asset and how the entity responded. Third, the open risks and actions that carry into next year, with owners and dates. Fourth, any assurance the entity has obtained, such as an independent review or exercise, so the board is not relying on management's own view alone.
If the report reaches the board only a few days before the deadline, directors have little room to question it. Many entities build in a draft to the risk committee ahead of the board meeting, so there is time to ask questions and fix gaps.
A practical timeline to 28 September 2027
The FY2026-27 report is due on 28 September 2027 [1]. A workable rhythm, which you should adjust to your own board calendar, looks like this.
In the months after the last report, close the actions it identified and decide who owns the evidence pack. Through the year, log changes to assets, suppliers and systems as they happen, and record hazard events and near misses at the time. Around the end of the financial year on 30 June, run the review of the CIRMP and draft the report. In July and August, circulate the draft to the risk committee and test the evidence. In early September, take the final version to the board for approval, leaving a margin before 28 September.
If information classification is a weak point, the 4 to 6 week scope of a classification framework fits comfortably into the first half of the year. That leaves time to adopt it before the review, instead of describing it as a future intention in the report.
A sensible first step
If you are not sure how mature your information handling is, start with a read of the current state rather than a large program. TFIQ's Data maturity snapshot is a short, fixed-fee read on how well the organisation manages its data and information today, scored across governance, quality, security, records and use, with the five things to fix first. It takes 1 to 2 weeks.
If the snapshot shows there is no classification scheme, or one that staff do not use, the Information security classification framework is the natural next step. It gives the board a defined scheme and handling rules to point to, and it prepares the ground for labelling and DLP tooling later. Larger critical infrastructure organisations with a fragmented data estate may need a broader program, and that is worth discussing once the snapshot is complete.
Because your obligations depend on your asset class and regulator, confirm the final content of your report with your legal adviser, the regulator and the CISC guidance [1].
Frequently asked questions
When is the CIRMP annual report due?
Within 90 days after 30 June, which is 28 September [1]. The FY2025-26 report was due on 28 September 2026, and the FY2026-27 report is due on 28 September 2027 [1].
Who has to approve the report?
The report is board-approved [1]. Management usually drafts it, but the board or equivalent governing body approves it, so directors should be given time and evidence to question it before sign-off.
What if our CIRMP was not up to date?
The report should say so plainly and explain what has been done to fix it. Take advice on how your regulator expects gaps to be reported. A documented gap with a remediation plan is generally easier to defend than an unsupported clean report.
Does the report have to list every incident?
It must cover the impact of hazards on the asset [1]. The exact threshold and detail depend on your sector and the current rules, so confirm with your adviser and the CISC guidance [1]. Many entities also keep near misses internally to show how controls performed.
Do we need a classification scheme to complete the report?
The report does not name one. But it is hard to show proportionate protection of critical information without levels and handling rules. A scheme gives the board a clear basis for what was affected and how it should have been handled.
How long does a classification framework take?
TFIQ's Information security classification framework runs 4 to 6 weeks. It covers the scheme, handling rules, labelling guidance and an adoption plan. It does not include configuring labels or DLP tooling, or classifying existing information.
Start with a Data maturity snapshot (1 to 2 weeks), then move to the Information security classification framework if the gaps are there.
Related: Classification, Labelling and DLP · Information Governance Frameworks · Board and Executive Assurance Reporting · Information Asset Register Services · Data Risk and Security
Sources
- Guidance for the Critical Infrastructure Risk Management Program (Cyber and Infrastructure Security Centre (Department of Home Affairs))
