Compliance once a year, or always on?
Most CIRMP compliance is a once-a-year scramble. A consultancy parachutes in around June, builds the annual report by hand, the board signs it, and it goes quiet until next year. But the obligation was never the report. It was the program underneath it. Here's what the report actually has to say, and why continuous beats the scramble.
Based on the last few weeks talking to Cyber and GRC folks, a lot of Responsible Entities, and a lot of the consulting firms advising them, still haven't built an AI-enhanced specialist tool or engine for SOCI's CIRMP compliance. (I'm happy to be proven wrong. And, if you know about it, please reach out.) And because it's compliance, nobody really likes it. It's not attractive. It's a forced thing, the kind of work that sits at the bottom of everyone's list until the regulator asks for it.
So it gets outsourced. The work goes to the Big 4 or a tier 2 firm, who turn up around June, gather the information, and build the annual report by hand inside the window. The board approves it. The Responsible Entity submits it to the Cyber and Infrastructure Security Centre at the Department of Home Affairs by 28 September. Done for another year. (Again, I'm happy to be proven wrong, and if your shop runs it differently, I'd genuinely like to hear how.)
I've been studying this Act for a while now. In an earlier post I wrote about how the program attaches to the asset by class, so one entity can carry more than one CIRMP. This post is about a different misread: treating the program as a once-a-year report when the Act asks for a living thing.
What the annual report actually has to say
Most people I talk to have never seen the inside of an annual report. They know it's due and they know the board signs it. They don't know what it has to contain.
Under section 30AG of the Act, the report has five parts. A declaration that the program was up to date at the end of the financial year. A statement of whether any hazard had a significant relevant impact on the asset during the year, with the details if it did. Any variations made to the program over the year. An evaluation of whether the program was effective at mitigating the relevant impacts. And approval by the board or governing body.
Read that list again. Four of the five things are a look back over twelve months. You can't write "up to date at the end of the year" honestly if you only started looking in June. You can't list the variations you made if nobody was tracking them. The report is a summary of a year of work. It was never meant to be the work itself.
Why "once a year" misreads the obligation
The report is section 30AG. The actual obligation sits earlier, at section 30AC. That section says the entity has to adopt and maintain a program across four hazard vectors: cyber and information security, personnel, supply chain, and physical and natural hazards. (I wrote about how wide the supply chain one really goes in a separate post.)
Adopt and maintain. Not adopt and report. The program is meant to be a living thing that runs all year, and the annual report is a snapshot of it. The June scramble flips that on its head. It builds the snapshot first and treats the program as something you reconstruct backwards to justify the photo. That's a lot of effort to describe a year you didn't actually run.
You can outsource the work, not the accountability
Here's the part that doesn't move. Section 30AG requires the board or governing body to approve the report. That approval is the entity's, and so is the obligation behind it. You can hand the preparation to a consultancy. You cannot hand over the ownership.
So you end up with the worst of both. The entity carries the accountability all year, but the knowledge of the program lives with a firm that turns up for ninety days and leaves. When something does have a significant relevant impact in March, the people who have to declare it in September weren't watching in March.
Same obligation, two operating models. The scramble and the living program both end at the board's signature and a submission to the CISC. Only one of them is honest about the year it describes. Generated by Author using Claude.
What continuous actually changes
So I've been thinking - what if compliance wasn't boring? What if it didn't cost the same six-figure bill year after year?
Continuous doesn't mean more reporting. It means the evidence is gathered as the year happens, not reconstructed at the end of it. A variation gets logged when you make it, not remembered in September. An impact gets recorded when it lands. The effectiveness evaluation writes itself out of a year of real entries instead of a fortnight of interviews.
Then the annual report stops being a build. It becomes an export. The board still approves it, because that part is statutory and shouldn't change. But they're approving a true picture of a year they actually watched, not a version assembled after the fact to fit the deadline. And the regulator-ready pack is signable any day, not just in the ninety-day window.
That's part of what I'm building toward at cirmpai.au. The point of it is to make the living program the easy path, so the report is just the moment you press export.
Questions worth asking your own shop
If you carry a CIRMP, or you advise someone who does, three questions sort the living program from the June artifact.
Is ours a program that runs all year, or a report we rebuild every June? Is the evidence gathered as we go, or gathered all at once when the deadline lands? And who actually owns it when the consultancy leaves in October?
. . .
How do you run yours?
If you've been through a CIRMP submission, inside a Responsible Entity or advising one, I'd love to hear how you handle it. Is it a once-a-year scramble for you too, or have you found a way to make it continuous? Thanks.