Part 3A of the Security Legislation Amendment (Critical Infrastructure) Bill 2020 (Bill) sets up a regime for the Australian government to respond to serious cyber security incidents, including broad powers of intervention in relation to critical infrastructure assets that could, per Section 35AC, enable the government to:

  • install, access, restore, copy, alter or delete software;
  • access, add, restore, copy, alter or delete data; and
  • alter the “functioning” of hardware or remove it entirely from the premises of a private company.

This raises the question of whether it is appropriate or realistic for the government to have such broad step-in rights, particularly in relation to cloud service providers that fall within the scope of the Bill.

Service providers have raised concerns that the government may step in and misunderstand how the regulated entity operates, or create new or more problematic security and systemic risks in the process. This is a legitimate issue considering the sophistication of many cloud service providers, particularly hyperscale international cloud providers with complex and interdependent cyber security systems and networks that take years for highly experienced and qualified security professionals to properly understand. 

It is also an issue that service providers and their customers commonly grapple with when negotiating step-in rights in outsourcing agreements: in the context of increasingly sophisticated systems and services, how realistic is it that a customer can ever effectively exercise step-in rights, and should the customer be empowered to do so?

Most suppliers are naturally resistant to step-in rights for complex services. Confronted with a customer that includes step-in rights in a services agreement, a supplier may:

1. Push back entirely, on the basis that step-in rights are simply not appropriate for the services (and the customer may acknowledge this is a reasonable position in the context of sophisticated service offerings that the customer is not practically equipped to step into);

2. Only agree to limited step-in rights after heavily negotiating the scope of those rights, including a series of checks and balances to carefully limit the ways in which such rights can be exercised (e.g. placing limitations on who is authorised to exercise step-in rights, in what circumstances, for how long, in relation to which systems / services, at whose risk, subject to whose oversight / consultation); or

3. Reluctantly accept the inclusion of relatively broad step-in rights by getting comfortable that in practice the customer could not realistically (and would not attempt to) exercise its contractual step-in rights in any event, for example due to the nature of the customer or the complexity or sophistication of the supplier's systems and services.

Perhaps more so than in relation to their customers under services agreements, service providers are concerned in the context of the Bill that broad government step-in rights, if legislated, will ultimately be exercised by the government, even if they perhaps should not be. While it may be appealing to think that the government could quickly step in and fix something bad that happens to a cloud service provider's complex systems, rapid government intervention to a complex and interconnected network seems more likely to have severe adverse consequences, and this is not a risk that major service providers will readily accept. The "Option 3" approach therefore seems untenable for service providers in the context of the Bill.

On the other hand, considering the strategic importance of these critical systems, the government is equally unlikely to accept the "Option 1" scenario in which it has no "step-in" rights whatsoever. 

One thing government and industry seem to agree on is that cooperation and collaboration are essential to address the growing cyber security threat to critical infrastructure. 

This sets the scene for extended "Option 2" negotiations (in the form of industry consultations), to ensure that any government "step-in" rights are realistic in scope, framed in the language of collaboration and subject to suitable checks and balances to effectively support the government's legitimate interest in helping providers of critical infrastructure to defend their networks and systems in appropriately exceptional circumstances, such as in response to serious cyber security incidents.