From contractual appendix to practical resilience tool 6 min read
AI, quantum computing and overlapping regulatory reforms are forcing organisations to rethink how they design and negotiate security schedules
Cyber threats and regulatory expectations are changing rapidly, particularly as AI capabilities develop. A security schedule drafted 18 months ago may today reference superseded standards, overlook AI and quantum-computing risks, or never have been tested against current incident scenarios.
The pace of regulatory reforms that must flow through to supplier arrangements is compounding the challenge.
- On 1 July 2026, organisations completed their multi-year push to comply with the Australian Prudential Regulation Authority's (APRA) CPS 230 (Operational Risk Management).
- Two days later, the Government proposed sweeping reforms to the Security of Critical Infrastructure Act 2018 (Cth) (SOCI Act), which would expand the definition of 'cyber security incident', directly regulate 'relevant operators' and require responsible entities to manage cyber risks from major suppliers through contractual or equivalent measures.1
- On 31 August 2026, the Government released draft proposed reforms to the Privacy Act that would introduce a controller/processor concept and new requirements for data breach notifications and mitigation (read more about the proposed reforms at A new era for privacy: What the proposed Privacy Act reforms mean in practice).
In practice, this means all organisations need to start treating their security schedules as ongoing frameworks rather than static documents settled at signing. Doing so will help both customers and suppliers prevent incidents and respond effectively when they occur. Framing schedules around that shared outcome can support constructive negotiations and produce obligations that are clearer, more workable and suited to evolving threats and regulations, without introducing undue friction, and that will strengthen resilience in practice.
Where the traditional approach falls short
- Prescriptive control catalogues can date quickly. Vulnerability disclosure expectations, patching timeframes, log retention periods, encryption standards and incident notification requirements that were acceptable one or two years ago may no longer reflect current threats or regulatory expectations. A schedule that hard-codes controls at signing locks them in for the life of the contract.
- Security schedules can create disproportionate contracting Security provisions are often heavily negotiated, which extends timelines and ties up the organisation's cyber specialists in detailed mark-ups and recurring questions, even for routine issues.
- Schedules can look robust on paper but fail in practice. Obligations don't always reflect the service model or risk profile, and suppliers can find them hard to interpret or evidence. Assurance is often obtained at signing and not revisited, and response and recovery processes may be thinly specified and never tested. The result can be a schedule that gives little confidence it will work when needed.
Moving from static terms to a flexible fit-for-purpose framework
The table below highlights how to shift from a static security schedule to a practical framework for managing risk throughout the service relationship.
| Area of focus | Traditional approach | Better approach |
|---|---|---|
| Resourcing approach | Cyber specialists review every supplier arrangement, regardless of risk. | Set risk-based escalation thresholds and involve cyber specialists where technical judgment or material risk warrants it. |
| Proportionality | Boilerplate schedules for every supplier and service. | Use a flexible, modular, risk-based schedule, with stronger requirements for higher-risk suppliers, services and activities. |
| Emerging technology risk | Long, prescriptive and largely static control catalogues that rapidly date. | Set outcome-focused controls, and where prescriptive controls are required, include a mechanism to reassess them periodically and after incidents, near misses or material changes to the threat or regulatory environment. See further information on emerging technology risk in the breakout box below. |
| Risk allocation | Negotiate primarily to transfer risk and protect each party's position. | Use the schedule as a shared protocol, with complementary responsibilities directed to secure, continuous and resilient services. |
| Assurance | Rely on assurance at signing, or seek evidence only after an incident. | Require ongoing reporting, testing and validation, backed by meaningful audit and assurance rights. |
| Incident response | Focus on prevention, with limited detail on response and recovery. | Set clear obligations for notification, cooperation, response and recovery, and test that they work. |
AI threats, quantum computing and other emerging technology risks
A schedule drafted two years ago is unlikely to address the risk that:
- AI now enables attackers to identify, chain and exploit existing vulnerabilities at far greater speed and scale than before;
- autonomous AI agents could act outside their intended scope, bypass controls or take unauthorised actions within connected systems; and
- quantum computing could soon break the encryption algorithms protecting data in transit and at rest today, rendering current cryptographic protections obsolete.
These risks call for obligations that may not appear in a traditional control catalogue. These could include accelerated patching and remediation timeframes calibrated to the speed at which AI-enabled threats can weaponise known vulnerabilities (and with flexibility for that to evolve over time), requirements for human oversight, approval and the ability to override or disable autonomous AI agents acting on customer systems or data, and requirements to maintain a cryptographic asset inventory and transition plans for post-quantum encryption algorithms.
For more on managing AI threats, see Board and management briefing: preparing for Mythos-class threats and AI models broke out of a testing environment and attacked a third party. On quantum computing risk, see Preparing for the post-quantum era of security.
Questions to guide the review
When reviewing an existing security schedule or developing a new one, organisations should think beyond which clauses to include and instead ask:
- What needs to be protected?
- What are the key existing and emerging risks?
- How those risks will be managed in practice (both contractually and via compensating controls)?
Key questions and considerations
- What dependencies will the arrangement create and how replaceable is it?
- What are the consequences of disruption?
- Who will have what access to networks, systems, production environments, privileged accounts, customer or employee data and other sensitive data?
- What is the supplier's reliance on subcontractors and other downstream providers?
- Consider reporting, data residency, subcontracting and incident response requirements.
- Identify the certifications, independent reports, control testing and penetration testing relevant to the risk.
- Watch out for the limitations of SOC 2 Type II and other reports, including differing observation periods, scope exclusions, and the gap between the assessment period and when the report is finalised and shared with customers – higher risk engagements should address these issues directly.
- Identify any assurance the organisation must provide to regulators or third parties (eg, downstream customers) and how the supplier will support this.
- Consider notification triggers and timeframes, investigation responsibilities, cooperation and stakeholder communications, access to evidence, preservation of records and recovery expectations.
- Distinguish mandatory controls from preferred positions.
- Agree acceptable alternatives and identify threshold for escalation and risk acceptance where a requirement cannot be met.
- Benchmark against regulatory requirements and expectations (having regard to recent enforcement action and guidance) and recognised standards – not just the last negotiated position or historic market practice.
- Confirm the controls remain appropriate to prevent, detect, respond to and recover from incidents.
- How do implementation, assurance and oversight costs compare to the risk and potential consequences of an incident?
- Agree responsibility for uplift, testing, certification, remediation and ongoing compliance costs.
- Do the parties have suitably skilled people, tools and processes to monitor compliance, address gaps and trigger reassessment when circumstances change?
A shared framework benefits both parties
The case for review is equally important for suppliers. The aim is to create transparency about the security and resilience measures already in place, what the service and risk profile require, and what each party can reasonably deliver.
A constructive process allows the parties to test whether the agreed controls work in practice, close any gap between contractual expectations and operational reality, and agree responsibilities where needed. That shared approach benefits both sides: customers gain greater confidence in continuity and resilience, while suppliers are better placed to maintain reliable service delivery, strengthen customer relationships and support longer-term opportunities.