In December 2025, this principle did not exist.
Compare ASD’s December 2025 control set with its June 2026 control set — both published as spreadsheets, both listing every principle — and the Govern function goes from 7 principles to 14. It doubled. No other function gained more than two.
One of the seven additions was created from nothing:
This is not an inference from the numbering. It is a diff. GOV-10 has no predecessor, no renamed equivalent, and no entry in the December release. And it did not arrive alone — ASD used the same release to promote two principles out of the Protect function and into Govern: supplier assurance (formerly PRO-03, now GOV-11, and now requiring that a supplier’s practices be regularly independently verified) and personnel suitability (formerly PRO-11, now GOV-12, and now requiring ongoing assurance).
ASD has, quietly, elevated what you leak about yourself to the status of a governance principle. Not a control. A principle, sitting alongside executive accountability and risk management assurance, in the function that describes what a board is answerable for.
The problem with GOV-10 is that it is unauditable from the inside
Read the wording again. It asks three things: that disclosure be minimised, that it be controlled, and that it be logged.
Every one of those verbs presupposes that you know what you are currently disclosing.
You cannot minimise an unknown quantity. You cannot control a channel you have not identified. And you certainly cannot log a disclosure you were unaware of making — a contractor’s repository, a job advertisement naming your internal stack, a subdomain nobody decommissioned, a certificate transparency log entry, a misconfigured storage bucket, an error page returning a framework version.
None of that is visible from inside your network. All of it is visible from outside. GOV-10 is a principle you cannot evidence with an internal audit, and ASD has not offered you an internal way to satisfy it.
The rest of the ISM tightens the loop
GOV-10 does not stand alone. The June 2026 ISM has, across several functions, converged on the same demand.
- IDE-04 — Security risk identification. Security risks are identified including by using current strategic and sector-specific cyber threat intelligence and threat modelling. Sector-specific. Not a generic vendor threat report; intelligence about what is happening to organisations like yours.
- GOV-07 — Continuous cyber security improvement. Cyber security activities are continually measured and reviewed using cyber threat intelligence and assurance activities, including exercises informed by real-world cyber threats.
- DET-05 — Detection capability efficacy. Detection capabilities are refined including by using current strategic and sector-specific cyber threat intelligence.
- PRO-04 — Secure configuration management. Systems are configured to baselines including by reducing attack surfaces and attack paths.
- ISM-2116 (new, June 2026): Cyber threat intelligence services are used to support the detection of cyber security events. A control, not a principle.
Threat intelligence appears in the Govern, Identify and Detect functions. It is no longer a nice-to-have for a mature SOC. It is a stated input to risk identification, to improvement, and to detection efficacy.
What a board is now expected to know
The most consequential change may be a single control, revised in June 2026, in the Guidelines for cyber security roles:
ISM-2005 (Revision 2, June 2026)
- The board of directors or executive committee understands the business criticality of their organisation’s systems, including at least a basic understanding of what systems exist, their value, where they reside, who has access, who might seek access, how they are protected, and how that protection is verified.
Who might seek access. That is a threat-intelligence question, and it is now asked of the board, not the SOC.
How that protection is verified. That is an assurance question — and note that it asks how protection is verified, not whether it is implemented. Those are different questions, and only one of them can be answered by pointing at a control register.
Why this matters more than the Essential Eight announcement
On 24 June 2026 ASD confirmed the Essential Eight will be retired and replaced by the Essentials series, with consultation on the first chapter closing on 12 July. Coverage focused on the timeline and on reassurance that existing controls carry over.
But ASD has said the Essentials guidance will be grounded in the ISM. Which means the ISM is not commentary on the transition — it is the substrate. And the substrate now contains a governance principle requiring you to minimise, control and log what you publicly disclose about your systems.
The Essential Eight never asked that question. It asked whether you patched, whether MFA was on, whether macros were restricted — all answerable from a configuration export. You could reach Maturity Level Two without ever establishing what your organisation was broadcasting to the internet.
Its successor is being built on a document that makes exposure a first-order governance concern.
Where this lands under Australian obligations
- PSPF-bound entities operate against the ISM directly. GOV-10 applies to them now, not in two years.
- CPS 234 requires information assets to be classified by criticality and sensitivity, with controls commensurate with the threat. “Commensurate with the threat” has always implied external knowledge; IDE-04’s sector-specific language makes explicit what APRA left implied.
- CPS 230, in force since 1 July 2026, turns on understanding dependencies. IDE-05 (asset interdependencies) says the same thing in ASD’s language: interdependencies are identified and documented, including how the compromise of one system could affect the security or business operations of other dependent systems.
- SOCI responsible entities operate risk-management programs premised on knowing what they run and how it fails. That is the Identify function, restated.
Three questions for a board, in ASD’s own words
- What do we currently disclose publicly about the design, configuration and operation of our systems — and is any of it unnecessary? (GOV-10)
- Who might seek access to our systems, and how do we know? (ISM-2005)
- How is our protection verified — by whom, from where, and how recently? (ISM-2005)
If the answer to the first is “we have never looked,” then the organisation is not partially compliant with GOV-10. It is unable to form a view on whether it complies at all — which is a different and more difficult thing to explain.
Three disclosure surfaces — your systems, your people, your procurement — all tightened in one release, none of them visible in any Essential Eight maturity score. Of the ISM’s 1,101 controls, only 126 map to the Essential Eight, and none of the twenty added in June 2026 do. The arithmetic is here.
Sources & references
- ASD — Information security manual, June 2026 (GOV-10, GOV-07, IDE-01, IDE-04, IDE-05, PRO-04, DET-05, ISM-2005, ISM-2116)
- ASD / ACSC — Consultation on the evolution of the Essential Eight; Essentials guidance grounded in the ISM (closed 12 July 2026)
- iTnews — Chris Horlyck, ACSC, on the 12- and 24-month transition
- APRA — Prudential Standard CPS 230 Operational Risk Management
- ASIC — Cyber risk: Be prepared; ongoing reassessment based on threat intelligence and vulnerability identification