How does a security schedule differ from the questionnaire that preceded it?
The questionnaire was an evaluation form that one reviewer scored before closing the file. The security schedule attached to the master services agreement is an operative term of the contract, live for the whole term and usually for a survival period after it, and the next people to read it closely are an auditor, an incident lawyer, or whoever is preparing a claim. Many schedules also annex the questionnaire and warrant those answers as true and continuing, which turns a form filled in under time pressure into enforceable promises.
Read the document stack before the clauses. The obligations sit across the agreement, the order form, the security schedule, a data processing schedule where personal information is involved, and frequently the buyer's own information security policy incorporated by reference. An order of precedence clause decides which wins when they conflict, and the definitions decide how far each one reaches. A schedule that reads mild becomes severe through a definition of Customer Data capturing everything you receive in connection with the agreement, or a definition of Security Incident wide enough to catch events that never touched the buyer.
The clause worth finding first is the one incorporating the buyer's security policy as amended from time to time. It hands the buyer a right to change your operating obligations after signature, without a variation, without notice, and without any mechanism to price the change. Fix the version at the signature date, annex the copy you have read, and ask for notice and a reasonable implementation period. The schedule is drafted by the buyer's security function, reviewed by its legal team and signed on your side by whoever owns the deal, so take each clause to the person who will perform it and ask what it costs in hours a year and who owns the artefact it produces.
The clause families that create real operational load
Most schedules run to a dozen headings and only a few of them change what your team does week to week. The load concentrates in three places: obligations that run continuously, obligations that need an artefact produced by somebody outside your business, and obligations that reach through you to a provider you do not control. The liability cap and the indemnities are a question for your own lawyer. What follows is the operational half, which is the part that gets signed without being costed.
The heaviest clause is usually the defined standard, and there is a real difference between a warranty that you hold a named certification and an obligation to maintain reasonable security measures consistent with good industry practice. A named standard is bounded and testable, and it fails hard, because a lapsed certificate or a scope statement that no longer covers the environment holding the buyer's data is a breach of contract on its face. An undefined standard cannot lapse, and it gets assessed in hindsight after an incident against what a competent supplier in your position should have done. Sub-processor flow-down is the family suppliers misjudge most, since it obliges you to know at any moment every provider that touches the buyer's data and every country it operates from, and if you cannot produce that register today the clause is already unperformable.
| Clause family | What it obliges you to do | Evidence that discharges it | A position buyers commonly accept |
|---|---|---|---|
| Named standard or maturity level | Hold the standard continuously for the term, across the environment holding the buyer's data | A current certificate carrying the accreditation mark and a scope statement naming that environment, or a dated assessment against every mitigation strategy in the maturity model | Warrant the standard you hold today with the scope written into the clause, and convert anything you do not hold into a dated uplift obligation with its own end date |
| Independent testing cadence | Commission testing at a stated frequency by a party independent of the build, and remediate findings inside stated windows | An attestation letter dated inside the window, a finding register with closure dates, and retest evidence for critical and high findings | Agree the cadence and the severity windows, and supply the summary letter and the finding register in place of the full report |
| Audit and access rights | Host an audit of your systems, records and premises, sometimes on short notice and sometimes by the buyer's regulator | Independent assessment reports offered in place of an audit, plus a documented process for handling a request | Reports first, one on-site audit a year on notice at the buyer's cost, no access to other customers' data, and an unrestricted right reviving after a Security Incident |
| Sub-processor flow-down | Bind every downstream provider to equivalent obligations, keep a current register, and give notice before adding one | A dated register naming each provider, its function, the data it touches and the country it operates from, plus the executed downstream terms | Notice with an objection window where the buyer has asked for consent to every provider, and a right to replace an objected provider before any termination right bites |
| Incident notification | Notify a named contact within a fixed number of hours of an event meeting the schedule's definition | The notice you sent with its timestamp, and an internal timeline showing when awareness arose and who held it | Settle the definition and the trigger before arguing the number of hours, and exclude unsuccessful attempts and events with no impact on the buyer's data |
| Data return and deletion on exit | Return the buyer's data in a usable format and destroy every remaining copy within a stated period, then certify it | A certificate of destruction enumerating systems, methods, dates and backup expiry, signed by someone with authority over all of them | A defined return format and window, deletion of live copies inside the stated period, and backups destroyed on the expiry of a stated retention cycle |
| Insurance warranty | Carry and maintain cover of a named type and limit for the term and produce evidence on request | A certificate of currency at each renewal, read against the cover the schedule promises | Match the cover to the risk the contract transfers, and check the policy's own notification and admission conditions against the contract clock |
| Carve-out from the liability cap | Nothing operationally, and it removes the ceiling from the event most likely to be severe | Nothing you can produce, because this clause is not discharged by evidence at all | A defined higher cap for data breach liability, sized against the cover you hold, so the exposure still has a ceiling |
Security schedule clause families, the evidence each one is discharged by, and where suppliers usually land
Why a 24 hour notification clock rewrites your incident response plan
Most of the negotiation goes into the number of hours, and the definition decides far more. The definition of Security Incident usually reaches actual or suspected unauthorised access to, use, disclosure, loss or alteration of the buyer's data, and it is often extended to cover any breach of the schedule itself. Under that second limb a lapsed certificate, a missed access review, or a laptop lost with cached credentials becomes a reportable event with a clock attached.
Two further drafting choices decide how often the clause fires. The trigger, whether the clock starts when you become aware, when you suspect, or when you confirm, is the difference between reporting alerts and reporting conclusions. Whose awareness counts is the second, because a clause keyed to any of your personnel imputes knowledge across the whole business, so an engineer's unease on a Saturday can start a clock nobody else knows is running. Key it to a named security contact against a defined trigger, then staff that contact, because the clause only works if somebody is reading that mailbox out of hours.
The contractual clock sits inside the statutory window and does not replace it. Under the Notifiable Data Breaches scheme in Part IIIC of the Privacy Act 1988, an entity with reasonable grounds to suspect an eligible data breach has to assess expeditiously and take all reasonable steps to finish inside 30 days, and once it has reasonable grounds to believe an eligible data breach has occurred it notifies the Office of the Australian Information Commissioner and the affected individuals as soon as practicable. A 24 hour contractual clock therefore requires you to tell a customer about something you have not yet assessed, which is a sequencing problem for your incident response plan and has to be solved before an incident. Five things need to exist before the first alert.
The clocks in the table below can all run at once after a single incident at a supplier, and three of them are obligations your customer owes to a regulator. A regulated buyer holds firm on a short notification window because your notice is the input to a deadline it cannot miss, and it has no way of meeting that deadline if it hears from you late.
- A contract register mapping each customer to its clock, its trigger, the named recipient and the channel the contract requires, updated as agreements are signed rather than reconstructed under pressure.
- A named person authorised to send a first notice out of hours without waiting for an executive who cannot be reached.
- A first notice template stating what is known, what is not yet known, what you are doing, when the next update arrives, and that you are giving contractual notice without admitting liability.
- A check of the notice provisions in the agreement, because a clause requiring notices to a registered office by post cannot carry a 24 hour security notification, and it is the agreement's clause that governs.
- A read of your insurance conditions in advance, since policies commonly require notification of a circumstance that may give rise to a claim and restrict admissions of liability.
| Clock | Runs to | Starts when | How long | What has to exist beforehand |
|---|---|---|---|---|
| Customer contract clause | The buyer's named security contact | An event meets the schedule's definition, on whichever trigger it states | Commonly 24 hours, sometimes 12 or 48 | The signed schedule to hand, since the clock, the trigger and the recipient differ for every customer |
| Notifiable Data Breaches scheme | The Office of the Australian Information Commissioner and the affected individuals | You have reasonable grounds to suspect an eligible data breach | Assessment expeditiously and inside 30 days, then notification as soon as practicable | Logs with enough history to scope who was actually affected |
| Ransomware payment under the Cyber Security Act 2024 | A designated Commonwealth body | A payment is made, or you become aware one was made on your behalf | 72 hours | A decision record, and a settled view on whether your turnover puts you in scope |
| Your buyer's obligation under CPS 234 | APRA, notified by the buyer | The regulated entity becomes aware of a material information security incident | 72 hours, and ten business days for a material control weakness it cannot remediate in time | A notice from you early enough for the buyer to make its own on time |
| Your buyer's obligation under the Security of Critical Infrastructure Act 2018 | The Australian Signals Directorate, reported by the buyer | The responsible entity becomes aware of an incident affecting the asset | 12 hours where the impact is significant, 72 hours where it is relevant | The same notice, compressed, which is why these buyers ask for the shortest clocks |
| Your cyber insurer | The insurer, under the policy conditions | Commonly when you become aware of a circumstance that may give rise to a claim | As the policy states | The policy read in advance, and a rule about who may admit anything |
The clocks that can run at the same time after one incident at a supplier
What evidence actually discharges each clause?
Every clause resolves to an artefact with three properties: a date, an author and a scope. Evidence fails on one of those three far more often than it fails on substance. The obligation is continuous while the artefact is point in time, so a test commissioned in January is still the current annual test the following December, and it reads as stale to a buyer asking then. Produce each artefact early in its window and put the date on its face, because the buyer reads the date before it reads the content.
Scope is the second failure and the more expensive one, because a certification can lawfully carry a scope statement that excludes the exact system holding the buyer's data, and a penetration test can be well executed against a marketing site while the multi-tenant application goes untested. Both satisfy a clause read literally and neither satisfies the person reading it after an incident, so write the environment into the clause and hold every artefact to those same words. The third failure is offering a document where a record is required. A policy stating that access is reviewed quarterly is a document and every supplier has one. The completed review listing accounts examined, decisions made, reviewer and date is a record, and the record is what an auditor and an incident lawyer ask for.
What does a certificate of destruction have to say, and who can sign it?
The deletion clause looks like a closing formality and it is the one most suppliers cannot perform. It obliges you to destroy every copy of the buyer's data within a stated period after the agreement ends and to certify that you have done so. Certifying is the hard part, because a certificate is worth exactly as much as the signer's authority over the systems it covers.
Almost no supplier has one person with authority over production, backups, the support tool, an offshore development environment and three sub-processors, so the certificate gets signed by whoever is available, producing a document that would not survive an assessor asking how the backups were handled. If you cannot name the person whose authority covers every system on the list, the obligation was never performable, and that is worth establishing while the clause can still be negotiated.
The fix starts before signature. Build the data map that enumerates every copy while the relationship is healthy and the systems are in front of you, keep it current as the architecture changes, and name the person who holds it. The same map lets you scope who was affected during an incident and keeps the sub-processor register accurate, so it earns its keep long before anyone asks for a certificate. A certificate that survives scrutiny states the following.
- The agreement and the categories of data covered, so the certificate covers identified data instead of offering a general assurance about your practices.
- Every system and copy included, meaning production stores and replicas, analytics and logging systems, support and ticketing tools, developer environments seeded from real records, exported files on staff devices, and anything sitting in a shared mailbox.
- The method used for each system, whether deletion of the underlying records, destruction of the keys where the data was encrypted at rest, or physical destruction of media, with the date each was completed.
- The treatment of backups, including the date the last backup containing the data expires, because a promise to purge backups on demand is one most backup arrangements cannot keep.
- Any copies retained under a legal or regulatory obligation, the obligation being relied on, and the date those copies will go.
- Written confirmation from each sub-processor that held the data, since your certificate covers their systems too whether or not you thought to ask them.
- The name, role and authority of the person signing, and the date they signed.
What is negotiable, and what a regulated buyer cannot move
Suppliers spend their negotiating credit in the wrong places, usually on the audit right and on the number of hours, both of which a buyer can defend on principle. The movable ground is mechanics, and the fourth column of the table above is where most of it sits. What will not move is anything the buyer's own regulator requires of it, and telling those two apart before the first mark-up is worth more than any single concession.
An APRA-regulated entity has to assess the information security capability of a third party that manages its information assets, under Prudential Standard CPS 234. Since 1 July 2025 it has also had to manage its material service provider arrangements under CPS 230, which requires the agreement itself to deal with ownership and control of data, audit and access rights and termination, and requires the entity to notify APRA when it enters an agreement for a service it relies on to run a critical operation. A responsible entity for a critical infrastructure asset has to address supply chain hazards in its risk management program. The Protective Security Policy Framework directs non-corporate Commonwealth entities to put proportionate security terms into their contracts and to keep them under review across the life of the contract, including where the work is subcontracted. Asking those buyers to delete the clause fails, and the attempt costs credit you need elsewhere.
The distinction that gets a deal moving is between the obligation and its mechanics. CPS 230 requires audit and access rights, and it does not prescribe an unlimited right to arrive at any hour with any number of people. A regulated buyer can accept an audit right exercised once a year on notice, at its cost, satisfied in the first instance by an independent report, with an unrestricted right reviving after an incident, because that is still audit access. Frame every counter as a way of delivering the buyer's own obligation and name the regulation you are delivering against.
The annual refresh calendar the schedule creates
Every clause carrying a cadence adds a dated artefact somebody has to produce inside a window that closes whether or not anyone is watching. Nothing in the contract reminds you that a certificate has lapsed or that the last restore test is now fourteen months old, and the buyer's request tends to arrive after the window has closed. The list below is the year a single schedule creates.
One schedule produces a calendar a small team can hold in its head, and by the fifth it is a role somebody has to be given, because each buyer adds obligations with different dates, definitions and cadences to exactly the same systems. No supplier is going to run two access review cadences because two contracts word them differently, so your real obligation is the high-water mark across every schedule you have signed: run one internal standard at that level and evidence against it once. Give the calendar an owner with a name and put the trigger events beside the dates, because a new sub-processor, a hosting region change, an architecture change or a lapsed certificate each invalidate a specific commitment, and triggers are the part no reminder catches.
- The independent test booked early in its window, since the letter is dated when the testing finishes and remediation of critical findings has to close inside the contractual window as well.
- Certification surveillance activity and the renewal date, with a scope review booked against every architecture change.
- Access reviews at the stated cadence, covering the accounts your own support and engineering staff hold into the buyer's environment as well as the buyer's own users.
- A restore test with a date and an outcome, since a continuity commitment is measured against a restoration that happened rather than against the plan describing one.
- Sub-processor register updates, with the notice obligation firing before you switch a provider, since the following quarter's review is too late to give notice.
- The insurance certificate at each renewal, read against the warranty in the schedule, since a renewal can quietly change the cover.
- Training completion records by name and date, and an incident response exercise where the schedule commits you to one.
How we handle this with clients
The common pattern is a supplier signing a schedule to close a deal, then discovering in month four that it has committed to an annual independent test, a certification it does not hold, a notification window nobody is rostered to meet, and a deletion obligation it cannot perform. The work is the same before signature or after: read every clause against what the business does, build the artefact that discharges each one, and put the recurring items on a calendar with an owner. Before signature is the version where you still hold leverage over the wording. That is much of what a vCISO engagement does for a supplier selling into regulated buyers, and penetration testing produces the recurring artefact the testing clause demands, delivered as an attestation letter with a finding register and a retest.
Most of the evidence question is settled in how the systems were built. The operations and compliance portal we built and run for GRM LAW, a Brisbane law firm, sits on an append-only audit ledger, and the staff portal we built for Stone Leaf Capital, an Australian capital-markets firm, keeps a compliance audit log capturing actor, action, and the before and after state of every change. Systems built that way answer an audit clause by opening a record instead of by quoting a policy. We sit on the supplier side of these schedules as well, since Aurii, our own clinical software venture, is Australian-hosted on Azure and holds tenant health data under tamper-evident audit trails. Our approach and trust pages set out how an engagement runs and what we are prepared to show.