Security posture is what your system can prove

The question regulators are now asking

For most of the last decade, an Australian business could satisfy nearly every security obligation it had with a document. A policy. A register. A statement in a privacy policy that personal information is held securely. The obligations were written in the language of governance, and governance is a thing you can write down.

That has quietly stopped being true. Three separate obligations now sit on the calendar, and each one asks for something a document cannot produce: a fact about your system, available inside a fixed window, that somebody has to be able to state accurately.

This is a different kind of requirement, and it fails in a different way. You do not fail it by having the wrong policy. You fail it by not knowing something about your own operation in time.

We are not lawyers and this is not legal advice — where your specific obligations start and stop is a question for someone qualified to answer it. What we can speak to is the engineering consequence, because that is the part that lands on the people who have to run the system afterwards.

Seventy-two hours after a payment nobody wants to discuss

The Cyber Security Act 2024 introduced Australia's first standalone cyber security legislation, and with it a mandatory ransomware payment reporting obligation that commenced on 30 May 2025.

The mechanics are narrow and worth stating precisely. If your business has an annual turnover above $3 million, or you are responsible for a critical infrastructure asset, and a ransomware or cyber extortion payment is made — by you, or by anyone acting on your behalf — you have 72 hours from the payment to report it to the Australian Signals Directorate. Civil penalties apply for not doing so.

Read that phrase again: or by anyone acting on your behalf. The clock does not start when your executive team decides to pay. It starts when a payment happens. Which means the reporting obligation is downstream of a question most organisations have never had to answer: would you know?

Consider the realistic version of this. A managed service provider contains an incident over a weekend. An insurer's incident response panel engages a negotiator. A regional office resolves something locally because the alternative was being down on Monday. In each case a payment can occur several steps away from the person who carries the obligation, and the 72 hours are running the whole time.

The compliance artefact here is a report. The system property underneath it is internal visibility — knowing what your own suppliers, insurers and sites did on your behalf, fast enough to matter. That is not a security control. It is an operating requirement, and it is the same requirement whether or not the law asks for it.

A device with no default password and a published end date

The second obligation is the one that touches our work most directly, because a meaningful share of what we build has hardware at the edge of it.

The Cyber Security (Security Standards for Smart Devices) Rules 2025 were made in March 2025 with a twelve-month transition, and the obligations took effect for relevant connectable products manufactured or supplied on or after 4 March 2026. Devices made before that date are not caught, but a supplier cannot supply a non-compliant product that was required to comply.

Three requirements sit at the centre of it, and they are strikingly modest:

• No universal default passwords. Credentials must be unique per device, or set by the user.
• A published channel for reporting security issues, so a researcher who finds something has somewhere to send it.
• Transparency about the minimum period of security update support, including an end date.

Manufacturers must prepare a statement of compliance, suppliers must ensure products are supplied with it, and both must retain the records for five years.

Notice what the third one really asks. To publish a support period with an end date, somebody has to have decided how long the device will be patched — and then to have built whatever makes patching possible for that long. In our experience that decision is almost never made during a build. It is discovered years later by whoever inherits the fleet, usually at the moment a vulnerability is announced and the answer turns out to be that there is no update path at all.

The word doing the most work in this regime is supply. Plenty of organisations that would never describe themselves as device manufacturers nonetheless specify, integrate and hand over connectable products as part of a delivered system. If that describes a project you have commissioned, the question of who holds the statement of compliance is worth asking before it becomes interesting.

Being able to say which decisions your software makes

The third date is the closest, and it is the one we expect to catch the most people off guard.

From 10 December 2026, new transparency obligations under the Privacy Act require APP entities to state in their privacy policy what kinds of personal information are used in automated decision-making, and what kinds of decisions are made that way, where those decisions could affect an individual's rights or interests. The obligation arrived with the Privacy and Other Legislation Amendment Act 2024 and came with a two-year grace period, which expires in December. The OAIC has been consulting on guidance for it through 2026.

The drafting task sounds administrative. It is not, because you cannot write that paragraph without an inventory, and an inventory of automated decisions is a thing very few organisations possess.

Most operations have accumulated automated decisions rather than designed them. A rule in a workflow tool that routes an application. A scoring formula in a spreadsheet that has quietly become the eligibility test. A threshold in a system nobody has revisited since it was set, which now decides who gets contacted first. A model call added to a form last year to triage submissions. Individually each was a small, sensible change. Collectively they are a set of decisions the organisation is making about people, and no single person can currently list them.

This is the compliance version of a problem we have written about before in a different register. An agent taking actions in your operation is a governance question rather than a speed question, and the reason is that decisions need owners. December's obligation is narrower than that — it asks only for disclosure, not for justification — but it forces the inventory. And the inventory is where the interesting findings are.

What the three have in common

Put them side by side and the pattern is hard to miss. One requires you to know what happened in your own operation within 72 hours. One requires you to know how long you have committed to maintaining a device. One requires you to know which decisions your software makes without a person in the loop.

None of these obligations asks whether your system is secure. Each one asks whether it can account for itself.

That is a legibility requirement, and legibility is exactly what operational decay erodes first. A system that cannot account for itself is not merely non-compliant on a technicality. It is a system where nobody can tell the difference between working and quietly broken, which is the condition under which security incidents get discovered late rather than early.

Which is also why we are wary of the framing these obligations usually arrive in. Compliance is a floor with a date on it. Posture is a property of a system that holds on a random Tuesday, and the two are not the same exercise. An organisation can pass the first while failing the second, and the failure is invisible until it isn't.

Where the defaults are missing

Here is the uncomfortable part, and it is the part we see most often when we go and look.

Very little of what we find is the result of an attack, or even of a bad decision. It is the accumulated residue of decisions nobody made. A storage bucket is public because that was the fastest way to make an image load in week two, and nothing has broken since. Permissions are broad because they were copied from a tutorial that needed them broad to demonstrate the point. Credentials live in an environment file that was committed once, rotated never. An admin account belongs to someone who left in 2024 and is still the only account that can perform one particular operation, which is why nobody has disabled it.

None of that appears in a risk register, because a risk register records what somebody thought of. Absent decisions leave no trace — they are not on any list precisely because nobody made them.

This is the same mechanism as the debt nobody believes is there, arriving in a place where the consequences are other people's personal information. And it has become considerably more common in the last two years, for a reason worth naming plainly: it is now possible to produce a working, customer-facing system without anyone in the chain being able to read what was produced. The features get asked for. The defaults do not, because a default is by definition the thing nobody specified.

The Australian Signals Directorate's Annual Cyber Threat Report 2024–25 recorded more than 84,700 cybercrime reports — roughly one every six minutes — with the average self-reported cost per report for a small business rising 14 per cent to about $56,600. That figure is not really a statement about sophisticated adversaries. At that volume it is a statement about how much of the attack surface in this country consists of settings nobody chose.

The parts that are not settled

There is a genre of article about this subject that lists every proposed reform as though it were law, and we think it does real damage — because a business that plans against a date which does not exist will get the sequencing wrong on the obligations that do.

So, plainly: the second tranche of Privacy Act reform remains a government commitment under consultation. As at the time of writing, no second-tranche Bill has passed and no commencement date is settled. That includes the widely discussed removal of the small business exemption, which is a proposal the government supports in principle rather than an obligation with a date. The Attorney-General confirmed in February 2026 that the tranche is being progressed, without committing to a timeline.

Worth knowing, worth watching, not worth building a project plan around. There are narrower exceptions moving faster — small businesses providing certain designated services under the AML/CTF regime lost the benefit of the exemption for that personal information handling from 1 July 2026 — which is a reminder that "small business is exempt" has already stopped being a reliable general statement, even though the general reform has not landed.

If you operate a critical infrastructure asset, your position is different again and considerably more advanced: the risk management program obligations under the SOCI Act have been in force for some time, the program must be reviewed at least annually, and a board-approved annual report is due within 90 days of the end of the financial year. That one is not a horizon item. It is a recurring September.

What is worth checking this quarter

None of the following requires a budget, a vendor, or a project. All of them convert a belief into a measurement, which is the only exchange that helps here.

Ask who could make a payment on your behalf. Not whether you would pay — whether a payment could occur without your knowledge, through an MSP, an insurer's panel, or a site with its own supplier relationships. Then ask how you would learn about it, and how quickly. If the answer is that someone would probably mention it, you have a 72-hour obligation resting on a courtesy.

List the automated decisions. One sitting, one page, no tooling. Every place where software decides something about a person without a human reviewing it: routing, scoring, prioritising, approving, declining, flagging. You need this list for December regardless. You will almost certainly find something on it that nobody realised was still running.

Find out when your devices stop being patched. For every connectable device in a system you own, the vendor's security update support period and its end date. Where a device has no answer, that is the answer, and it belongs in the risk conversation rather than in the category of things assumed to be fine.

Name the accounts belonging to people who left. Not the offboarding policy — the actual accounts, in the actual systems, including the service accounts and API keys created for a one-off integration and never revoked. Compare the list against your HR records rather than against memory.

Check one restore, not one backup. Confirming that a backup job reported success is a check on the job. Restoring something and looking at it is a check on the system. Only one of those tells you anything about the day you need it.

The interval that matters

Every one of these obligations is, underneath the drafting, a requirement to shorten the interval between when something becomes true in your operation and when someone in your organisation knows it.

Seventy-two hours is that interval, written into law. December's transparency obligation is the same idea applied to your own architecture: you are being asked to know, and publish, what your software decides. The smart device rules apply it to time, asking you to commit to a support period in advance rather than discovering it retrospectively.

An operation that has closed those intervals is compliant almost as a side effect. One that has not will meet each date with a drafting exercise, and will keep meeting the next one the same way, because the document was never the thing that was missing.

If you are not sure which of these applies to your operation, that uncertainty is itself worth resolving before December. It is a short conversation, and it is the sort of thing a Fit Call is for.

Referenced: the Cyber Security Act 2024 and the Cyber Security (Security Standards for Smart Devices) Rules 2025; the OAIC's consultation on guidance for transparency in automated decision-making; the Department of Home Affairs guidance on security standards for smart devices; and the ASD Annual Cyber Threat Report 2024–25. Current as at August 2026 — obligations change, and this is not legal advice.