The Jurisdiction Gap

For accountability, signing, and correction process, see the Accountability Statement.

Correction, 20 July 2026. The file published at this address until 20 July 2026 was a superseded draft. The document now published is the submission as lodged with the committee, byte identical to the file the committee holds. Both were labelled v1.1; the superseded draft is withdrawn.

Correction, 10 September 2026. Until this date this page said the submission and the first, second and fifth supplements carry no receipt. That was true when written and false from 26 August 2026, when a receipt for each of the four was stamped and served beside it. The sentence stood fifteen days after it stopped being true. All four are now listed under Timestamp receipts; read what each covers with ots info.

Note, 18 September 2026. The submission says no framework requires anyone to assess jurisdictional exposure. That was true when written. On 31 August 2026 the Digital Transformation Agency published principles under which, for its coordinated contracting arrangements, it will consider whether a seller, including any parent company, may be subject to laws that could override Australian contractual protections. The statement is superseded for procurements through those arrangements. Outside them, it stands for every instrument this practice has read. The principles state no method. The lodged submission is not amended. The committee secretariat was told on 18 September 2026.

Correction, 5 October 2026, now corrected in v1.1. The fifth supplement states, at page 3: “Each of the eight names or asserts foreign legal reach.” One of the eight is the Commonwealth Procurement Rules, and the supplement’s own page 5 says: “The Commonwealth Procurement Rules do not name the question.” The sentence was false as written for the Commonwealth Procurement Rules when the supplement was published and lodged on 19 August 2026. This note does not say that the sentence holds for each of the other seven. A corrected version, v1.1, will be published by 12 October 2026, restating the sentence against the supplement’s own breakdown of all eight. No recommendation changes. The same statement in this practice’s assessment AOS-ASR-2026-001 was corrected at version 1.5, published 23 September 2026, and is recorded on that assessment’s verification page. From its lodgement on 19 August 2026 until 6 October 2026, when v1.1 replaced it, the supplement served on this page was byte identical to the copy lodged with the committee. That copy is not amended, has not been re-lodged, and is preserved at its own address as v1.0. The committee secretariat was told on 23 September 2026. The detail is recorded in the practice’s corrections register.

This supplement to AOS-AIDC-2026-001 was lodged with the committee after the main submission. It addresses the two objections most likely to be raised against the submission's finding, the sufficiency of the Australia United States CLOUD Act Agreement, and the absence of a known compelled disclosure. It introduces no new recommendation and should be read with the main submission above. The file below is byte identical to the supplement as lodged.

This second supplement to AOS-AIDC-2026-001 narrows Recommendation D of the main submission on further primary-source work: a rule made on 10 June 2026 already asks the jurisdictional question of nine critical infrastructure asset classes, the annual report it feeds is board approved and attested, and the asset classes that store and carry government data sit outside both. It is published here ahead of lodgement so that the file lodged with the committee is byte identical to the file published. The file below is the published document.

This third supplement corrects the second. The second supplement stated that the exclusion of critical data storage or processing assets from the enhanced risk management tier is unexplained. It is explained, in the instrument that supplement itself cited: the reason appears at three places in the explanatory statement to F2026L00701, and a departmental response to the question of asset class scope appears at a fourth. None names the excluded class, which is why a search for the class name did not find them. The supplement also states a limit on Recommendation D1 that this practice found on testing it: an asset covered by section 30AB(4) sits outside Part 2A, so a rule made under section 30AH does not reach it. No recommendation is withdrawn or qualified. It is published here ahead of lodgement so that the file lodged with the committee is byte identical to the file published. The file below is the published document.

The published copy and the lodged copy differ, and only in presentation. The copy lodged with the committee is bf7c67ca43672896b9bed524698e91bd8f15c6a71c6c63a3450a91efcb10cf11 and has not been changed or re-lodged.

The v1.1 to v1.2 change. The copy above was rebuilt on 19 August 2026 to fix two rendering defects, and the two did not arise together. Three SHA 256 values in Appendix A ran off the page and were cut at 61, 63 and 62 of 64 characters. That defect entered at v1.1, with the correction that replaced sixteen character prefixes with the full values; v1.0 printed those hashes as sixteen character prefixes and does not carry it. And the end marker rule struck through a legislative instrument identifier in the last line of Appendix A. That one was present from first publication, striking item 6’s C2018A00029 at v1.0 and item 7’s F2025L00325 at v1.1, the appendix having gained a seventh item. Both were read from the rendered ninth page of all three copies at 400 dpi on 19 August 2026. No claim, quotation, footnote or figure changed - the body before Appendix A is character for character identical, and the appendix differs only in the hashes now rendering complete and a two sentence closing line. Both defects are recoverable from the lodged copy without this practice: each clipped hash is published in full on its own verification record, and the struck identifier appears uncorrupted one line above in the same citation.

Versions of the third supplement. This supplement has three states and all three are listed. v1.2, the published copy, rebuilt 19 August 2026, SHA 256 812b846e88a639480edd0c83eaf09fdecfc72fe66fc51173e166d838f0919acf - the file above. v1.1, published 13 August 2026, SHA 256 bf7c67ca43672896b9bed524698e91bd8f15c6a71c6c63a3450a91efcb10cf11 - this is the copy lodged with the committee. It is unchanged, it was not re-lodged, and it is not the file above. v1.0, published 13 August 2026, SHA 256 13c8115383956c27940b35d47b6eb26c58758925ae29ac5a05cdb17f8673324f, preserved at its own address; its bytes are unchanged and its hash still resolves.

The v1.0 to v1.1 change, made on 13 August 2026. Five citation defects, found by a reader. One footnote cited Recommendation D1 on a sentence quoting Recommendation D2. The appendix listed only section 04 and Recommendation D1 of the second supplement, while the document also quotes D2. One appendix entry gave the Security of Critical Infrastructure Act at its latest-text address, which serves whatever compilation is current when a reader opens it, rather than at a version pinned address for Compilation No. 9. One footnote sourced a claim about instruments - that critical telecommunications assets enter the risk management regime through a different instrument - to this practice’s own earlier submission rather than to the Telecommunications Security and Risk Management Program Rules 2025, which are now cited and pinned. And every hash in the appendix was truncated to sixteen characters; a prefix identifies a file and does not verify one, so all three are now given in full. No finding moved. No recommendation changed. No quotation of any instrument changed.

This fourth supplement is substantive and has three parts. It establishes what the hosting certification exemption at section 30AB(4) of the Security of Critical Infrastructure Act 2018 removes, through the deeming power at section 30AH(8) that section 6 of the risk management program rules is made for: two specified material risks cease to be material risks anyone is required to address, one of them the storage, transmission or processing of sensitive operational information outside Australia. It sets out five documents the Committee can obtain and this practice cannot, each with the provision that creates it, what was sought, when, and what came back. And it offers the author as a witness, naming what he could not give evidence about. No new policy recommendation is made. It is published here ahead of lodgement so that the file lodged with the committee is byte identical to the file published.

Correction at v1.2, 24 August 2026. Three statements in v1.1 were wrong. v1.1 said the Deed of Certification is not public, that what it requires is not public, and listed its contents among what cannot be established. The standard form of the Deed is published on the Hosting Certification Framework’s own website, and has been since November 2021, held by the Internet Archive since 7 March 2022. It is linked from no page on that site, which explains the error and does not excuse it. The statements were wrong when the supplement was lodged, not overtaken afterwards. What remains not public is which providers executed a Deed, any variation to the standard form, any condition imposed under its clause 13.2, and any confirmation under clause 13.7 — and the supplement’s request to the Committee is narrowed to those. No finding moves and no recommendation changes. The copy lodged with the committee is c13d93f470393246ec427f6bfa4408b89e9e201e5cfc54a0142317c432b8755c. It is unchanged, it was not re-lodged, and it remains downloadable at its own address. The committee was notified of this correction separately, by a letter sent on 24 August 2026 at 18:06:37 AEST to the committee secretariat, pinned in this case’s archive register as AIDC-SENT-6 and hashing to b54387f483cfd6b6efe06877c78b416ac422f353216c75a0bea9ac55515b7f8c. This page and the supplement both said the committee had been notified before it was. The sentence published at 17:43:49 AEST and the letter was sent at 18:06:37, so for 22 minutes and 48 seconds both asserted a completed act that had not occurred. The statement is true from 18:06:37 and the supplement is not reissued, because the sentence a reader downloads today is accurate; the window is recorded in the corpus corrections register rather than left to correct itself unremarked.

Versions of the fourth supplement. This supplement has three states and all three are listed. v1.2, the published copy, published 24 August 2026, is the file above; its hash is printed above. v1.1, published 14 August 2026, is preserved at its own address, SHA 256 c13d93f470393246ec427f6bfa4408b89e9e201e5cfc54a0142317c432b8755c - this is the copy lodged with the committee. It is unchanged, it was not re-lodged, and it is not the file above. v1.0, published 14 August 2026, is preserved at its own address, SHA 256 7ad0a309fd644a32d1d89116bea88d9ba4184f98807aeb03d5d317fdd1e781c9; its bytes are unchanged and its hash still resolves.

What changed, and why. Three defects, found by a reader. The quotation of paragraph 6(d) of the risk management program rules rendered its sixth sub item as the third: the source text was correct and the instrument numbers the sub items (i) to (vi), but the markdown line break caused the typesetter to read the marker as a list and renumber it. A misnumbered sub item in a quotation from a legislative instrument, in the paragraph the argument rests on, is a misquotation whatever its cause. A footnote cited the Freedom of Information Act as appendix item 10 while the appendix rendered it as item 9, because the entry had been inserted out of order and the typesetter renumbered by position. And one footnote broke across a line before its item number. No finding moved. No recommendation changed. No quoted words changed.

This fifth supplement corrects the premise of a recommendation in the original submission. Recommendation F asked the committee to establish a methodology standard for jurisdictional exposure assessment, “modelled on the existing IRAP and PSPF assurance pathways”. Examination of those pathways establishes that on this question they are not a model: the Information Security Manual and the Protective Security Policy Framework each name or assert that a foreign government may reach a provider’s data by law, the Infosec Registered Assessors Program’s one requirement on the subject asks where data, equipment and staff are, and none of them specifies, in its own text, a method for assessing that reach. Recommendation F stands. Its stated model does not. No recommendation is added, withdrawn or qualified.

Correction at v1.1, 6 October 2026. Five statements in v1.0 claimed more than the supplement’s own pages support. Part of the first was wrong when the supplement was lodged, the third was wrong for PSPF Release 2025, and the fifth was a miscount. v1.0 said that each of the eight instruments names or asserts foreign legal reach, and that four do so in terms. For the Commonwealth Procurement Rules, the first part was wrong when the supplement was lodged: page 5 of v1.0 says they do not name the question. v1.0’s pages do not support the first part for the Hosting Certification Framework, for either IRAP document, or for PSPF Direction 001-2024, whose words as quoted there name neither a foreign government’s access to a provider’s data nor a foreign entity compelling a provider to disclose it; read with the four instruments v1.0 then quotes, its count of four in terms included that Direction. v1.0 also said, at pages 3 and 7, that the Infosec Registered Assessors Program names or asserts that reach; page 5 of v1.0 says IRAP’s one requirement on the subject asks where things are. It said each instrument was read at the passage where a method would sit; PSPF Release 2025 has a second such passage, §6.1.3, which was not read. It said the ISM, the PSPF and IRAP supply or specify no method for assessing that reach, without saying it meant their own text; §6.1.3 refers to Home Affairs guidance that asks whether a foreign government could compel a vendor, and to an ASIO tool this practice has not obtained. And it miscounted its referrals. Version 1.1 restates all five from the supplement’s own pages and the instruments’ own words, and says that its statements about what an instrument supplies or specifies speak of the instrument’s own text. No recommendation changes.

Versions of the fifth supplement. This supplement has had three states, and all three are listed. The file above is v1.1, the published copy, published 6 October 2026; its hash is printed above. v1.0, published 19 August 2026, is preserved at its own address, SHA 256 1b75815703188e8901952ff7d98a2604b550becd0c2e6342b8bee5aa3e5534d1 - this is the copy lodged with the committee. It is unchanged, it was not re-lodged, and it is not the file above. Its bytes are unchanged and its hash still resolves. A first build, SHA 256 1bb63f92f7707f7e3005953e6c1707304d557c77add0cdbfec0d628d42d15f26, was served at this address from 18:59 to 19:29 on 19 August 2026 and replaced by v1.0 before lodgement. It differs from v1.0 in one sentence of section 01 and in the three sentences that close the appendix, and it is not served.

Eleven OpenTimestamps receipts are served with these documents, and this is where to find them. A receipt is a proof that the bytes it covers existed no later than the moment it was stamped. It establishes nothing about whether a document is correct, and it is not a signature. Each receipt below is named for the document it covers; verify one with ots verify against that document, or read what it covers with ots info.

No stamping date is claimed here. A receipt carries its own proof and a reader does not need this page to date it. A date asserted here would be one more thing to take on trust, and this record exists to reduce those.

One of the eleven has no file beside it, and that is deliberate. The receipt named for v1.1 of the third supplement covers bf7c67ca43672896b9bed524698e91bd8f15c6a71c6c63a3450a91efcb10cf11, the copy lodged with the committee, which this practice does not publish and which is described above. Nothing is missing. The receipt proves the bytes the committee holds, and a reader with that copy can verify it; a reader without it can still see that the proof exists and what it covers.