Data Processing Schedule Template For SaaS Customers

Mia runs a Sydney SaaS company that helps retailers manage online orders. A larger customer is ready to sign, but their procurement team sends back one request: "Please attach your data processing schedule, including subprocessors, breach notice times and security controls."

If you're selling B2B SaaS, this kind of request can slow down a deal even when your product is ready and your commercial terms are agreed.

The good news is that a data processing schedule doesn't have to be a 40-page document. It just needs to clearly explain how you handle customer data, who does what, and what happens if something goes wrong.

Do You Need A Data Processing Schedule For SaaS Customers?

Yes, if your SaaS platform handles personal information for business customers, a data processing schedule is usually worth having.

In Australia, the Privacy Act 1988 and Australian Privacy Principles apply to many businesses that collect, use, store or disclose personal information. This includes businesses with annual turnover of more than $3 million, as well as some smaller businesses such as health service providers, businesses that trade in personal information and businesses that handle tax file numbers.

Even if your SaaS business isn't directly covered by the Privacy Act yet, your customers may be. If you're processing their end users' names, emails, addresses, billing details, staff records or usage data, they'll often need contractual comfort that you're handling that information properly.

A data processing schedule can sit behind your main SaaS agreement, master services agreement or customer terms as a data processing agreement. It usually covers:

• what personal information your platform processes
• which party decides the purpose of that processing
• what you're allowed to do with the data
• what security measures you maintain
• when you can use subcontractors or subprocessors
• how quickly you'll notify the customer about a suspected data breach
• what happens to the data when the contract ends

For procurement teams, this document can be the difference between "legal still needs to review" and "approved to sign". For you, it can stop every customer from negotiating privacy terms from scratch.

What Should A Data Processing Schedule Template Include?

A good data processing schedule template should include the operational details your customer needs to assess privacy and security risk.

Here is a practical outline you can use as a starting point. A lawyer should tailor it before you use it, because privacy obligations depend on your platform, customers, data flows and risk profile.

1. Parties And Agreement: Identify the customer, your SaaS business and the main contract the schedule attaches to.
2. Definitions: Define key terms such as personal information, customer data, security incident, subprocessors and applicable privacy laws.
3. Roles Of The Parties: Explain who decides why data is processed, who carries out processing activities and how records of processing activities are kept.
4. Processing Instructions: State that you'll process customer data only to provide the SaaS services, follow agreed instructions and meet legal obligations.
5. Types Of Data: List the data categories, such as user names, contact details, account activity, support tickets, IP addresses or uploaded documents.
6. Categories Of Individuals: Identify whose information may be involved, such as customer employees, contractors, clients, patients, students or end users.
7. Subprocessors: Set out when you can use hosting providers, analytics tools, support platforms and other suppliers.
8. Security Measures: Describe technical and organisational controls in plain English, without overpromising.
9. Data Breach Notification: Explain what you'll tell the customer, when you'll tell them and how you'll cooperate.
10. Assistance With Privacy Requests: Cover reasonable help with access, correction, deletion or complaint handling where the customer needs it.
11. International Transfers: Identify if data may be stored, accessed or shared outside Australia and what protections apply.
12. Return Or Deletion: State what happens to customer data at termination, including backups and export periods.
13. Audit Or Information Rights: Explain what evidence you'll provide, such as security summaries, policies, certifications or completed questionnaires.

Templates often miss the messy parts that matter in real procurement, especially subcontractors, breach timelines and security carve-outs. That's why tailoring the schedule is usually safer than copying another SaaS company's terms.

Are You A Controller Or A Processor Under Australian Law?

It depends, and Australian privacy law doesn't use the same controller and processor framework as the GDPR.

Under the Privacy Act, the focus is usually on whether your business is collecting, holding, using or disclosing personal information, and whether you're an APP entity. The Australian Privacy Principles don't create a neat "controller" and "processor" split in the same way European contracts do.

That said, B2B SaaS customers often use controller and processor language because their procurement templates are influenced by global privacy practices. You don't need to panic when you see those words. You just need to translate them into clear operational responsibilities.

A Common SaaS Setup

Say Mia's platform lets retailers upload customer order data. The retailer decides what information to collect from shoppers, why it's collected and how long it should be kept. Mia's SaaS company hosts the platform, processes the data to provide the service and helps with support tickets.

In the data processing schedule, Mia's company might agree that:

• the retailer is responsible for giving privacy notices to its shoppers
• Mia's company will use the data only to provide and support the platform
• Mia's team won't sell the data or use it for unrelated marketing
• Mia can use de-identified or aggregated data for product analytics, if the contract clearly allows it

This kind of drafting helps avoid confusion later. Without it, a customer may assume you accept responsibilities that actually sit with them, such as obtaining consents from their own end users.

How Should SaaS Data Processing Terms Deal With Subprocessors?

Your SaaS data processing terms should identify your key subprocessors and set clear rules for adding or changing them.

Most SaaS businesses rely on third-party providers. That can include cloud hosting, email delivery, CRM, customer support, analytics, error monitoring, payment processing and security tools. From your customer's perspective, those providers may be part of the data risk chain.

A strong subprocessor clause usually deals with four points:

• Permission: whether the customer gives general approval for listed subprocessors or must approve each one separately
• Notice: how you'll tell customers about new subprocessors or material changes
• Flow-down terms: your promise that subprocessors handling customer data must be bound by appropriate confidentiality, security and privacy obligations
• Responsibility: whether you remain responsible to the customer for your subprocessors' acts and omissions

For smaller SaaS teams, general approval plus notice is often more workable than asking every customer to approve every supplier change. Large enterprise customers may still ask for a right to object, especially where sensitive data is involved.

Be careful about promising "no overseas access" unless it's genuinely true. Many cloud, support and security tools involve overseas storage or offshore support access. Under the Australian Privacy Principles, overseas disclosure of personal information can create extra obligations, especially under APP 8.

A practical schedule should name countries or regions where data may be stored or accessed if you know them, or explain that locations are set out in your subprocessor list and updated from time to time.

What Security Controls Should You Promise Customers?

You should promise security controls that match what you actually do and what your customers reasonably need, without overstating your capability.

APP 11 requires APP entities to take reasonable steps to protect personal information from misuse, interference, loss, unauthorised access, modification and disclosure. What is reasonable depends on the nature of the data, your business, the harm that could result and the security measures available to you.

For a B2B SaaS schedule, customers will usually expect controls across people, systems and processes. You might cover:

• access controls, including unique user accounts and role-based permissions
• multi-factor authentication for admin accounts
• encryption in transit and, where used, encryption at rest
• secure development practices and vulnerability management
• logging and monitoring for suspicious access
• backup and disaster recovery processes
• staff confidentiality obligations and privacy training
• incident response procedures
• physical and environmental security where relevant
• supplier due diligence for tools that handle customer data

You don't need to hand over your full security playbook in the contract. In fact, sharing too much detail can create its own risk. A schedule can describe controls at a sensible level and reserve more detailed evidence for security questionnaires, certifications or customer due diligence.

Be especially careful with absolute promises such as "we guarantee no unauthorised access" or "we'll prevent all data breaches". No provider can honestly promise that. A better approach is to commit to reasonable and appropriate controls, prompt incident response and clear cooperation if something happens.

How Fast Do You Need To Notify Customers About A Data Breach?

You should set a specific customer notification timeframe that you can actually meet, while also allowing time to investigate properly.

Under the Notifiable Data Breaches scheme in the Privacy Act, an APP entity must notify affected individuals and the Office of the Australian Information Commissioner if there's an eligible data breach. An eligible data breach generally involves unauthorised access, unauthorised disclosure or loss of personal information that's likely to result in serious harm, and where remedial action hasn't removed that likely risk.

If you're not sure whether an eligible data breach has happened, you must carry out a reasonable and expeditious assessment. The Privacy Act expects this assessment to be completed within 30 days where practicable.

In a SaaS data processing schedule, customers often ask for notice within 24 hours or 48 hours of you becoming aware of a security incident. That may be workable for a suspected incident, but the wording matters.

A balanced clause might say you'll notify the customer without undue delay, and in any event within a set period after becoming aware of a security incident affecting customer data. It can also say the first notice may be preliminary and updated as more information becomes available.

Worked Example

Mia's team detects unusual access to one retailer's workspace at 9:00am on Monday. The logs show an admin account may have been compromised, but the team doesn't yet know whether customer names or order histories were viewed.

Her schedule requires notice within 48 hours of becoming aware of a security incident affecting customer data. Mia sends the retailer an initial notice by Tuesday afternoon with:

• what happened and when it was detected
• the systems and data types potentially affected
• the steps already taken, such as disabling the account and rotating credentials
• what Mia still needs to investigate
• when the next update will be provided

That notice doesn't decide whether the incident is an eligible data breach. It gives the customer enough information to manage its own obligations while the investigation continues.

How Do You Attach The Schedule To Your SaaS Contract?

You attach the schedule by making it part of your customer contract and lining it up with your main commercial terms.

The schedule shouldn't sit separately in a folder where no one is sure whether it's binding. It should be incorporated into your SaaS agreement, order form, master services agreement or terms and conditions.

Before you send it to customers, check that it doesn't clash with your other documents. Common conflicts include:

• your main agreement says data is deleted after 30 days, but the schedule says 90 days
• your privacy policy says data may be stored overseas, but the contract promises Australia-only hosting
• your security schedule says you use multi-factor authentication for all users, but it's only mandatory for admins
• your subprocessor list names old tools you no longer use
• your support terms promise response times that your incident clause can't meet

You'll also want a process for version control. If enterprise customers negotiate special privacy terms, track those changes carefully. Otherwise, your sales team may assume all customers are on the same position when they're not.

If you're using online clickwrap terms, the schedule can be included as an incorporated schedule, provided your acceptance flow makes the customer aware of the terms before they accept. For higher-value deals, it's common to attach the schedule to a signed order form or master agreement.

Once the schedule is live, keep a simple internal checklist for procurement responses:

• current data processing schedule
• current subprocessor list and subprocessor addendum
• plain-English security summary
• privacy policy
• incident response contact
• approved fallbacks for common customer mark-ups

This helps you move faster when a buyer's legal or security team asks the same questions again.

Key Takeaways

• A data processing schedule helps B2B SaaS customers understand how you handle their personal information and customer data.
• Australian law doesn't use the same controller and processor model as the GDPR, so your contract should explain the roles clearly.
• Your schedule should cover data types, processing instructions, subprocessors, security controls, breach notification and end-of-contract data handling.
• Don't overpromise on security or breach outcomes. Promise practical controls and a clear incident process you can meet.
• Procurement teams care about the details, so keep your schedule, subprocessor list and security summary consistent and up to date.

If you'd like help with your SaaS customer contracts, data processing schedule, privacy terms or subprocessor clauses, you can reach us at 1800 730 617 or team@sprintlaw.com.au for a free, no-obligations chat.