Before a software vendor handles your customer data, ask for proof

Before a software supplier can access customer or employee records, its security claims need to be tied to the specific product, plan and setup you will use. A questionnaire can surface gaps; the contract should say who will handle the data, what controls apply and what happens if the supplier fails. This article is general information, not legal advice.

Map the data and access before sending questions

A short vendor security questionnaire works best when you already know what you are buying and what risk you are creating.

• What personal information will the vendor store, process, back up or support?
• Will your business still hold that information because you keep the right or power to access, amend, retrieve or direct what happens to it?
• Will any part of the service involve overseas storage, support access or subprocessors?
• Who on the vendor side can access the data, and for what reason?
• What do you need the vendor to do if a suspected or eligible data breach arises?

These questions matter because APP 11 applies to personal information an APP entity holds. Under OAIC guidance, outsourcing storage does not necessarily change that. If your business retains the right or power to deal with the information, you may still hold it even when a third party hosts or handles it.

That does not mean every Australian business is automatically covered by APP 11. Whether the Privacy Act and the Australian Privacy Principles apply depends on your circumstances, and some sectors or state based frameworks may need separate review.

What evidence supports the supplier's claims?

The OAIC does not prescribe a fixed statutory questionnaire. Its guide to securing personal information does identify the third-party and cloud-service risks an APP entity should assess. Use that guidance to test the service you will actually buy, not to imply every business has identical legal obligations.

Ask for evidence that matches the actual service, not a generic yes or no answer. For example, a vendor may say it encrypts data, but you still need to know whether encryption applies in transit, at rest, in backups, and who controls decryption keys.

For most software and managed service purchases, ask for proof on these points:

• the scope of services involving personal information, including backups, logs, support access and test environments
• the security controls the vendor applies to that service and customer plan
• how user access is restricted, approved, monitored and removed
• how incidents are detected, escalated, investigated and communicated
• whether the vendor uses subcontractors or affiliated providers to deliver any part of the service
• whether personal information is stored or accessible overseas
• whether the vendor wants to use customer data for analytics, product improvement or other purposes beyond delivering your service
• how data can be retrieved, returned, deleted or destroyed at the end of the arrangement
• what reporting the vendor can provide during the contract term

Useful proof can include product specific security documentation, penetration testing summaries, architecture diagrams, role based access descriptions, an information security policy, incident response processes, subprocessor lists, deletion procedures and sample reporting. A certification or assurance report may still help, but it does not by itself prove that your chosen configuration, modules or support model meet your needs.

Do not accept a one-word yes

A long spreadsheet does not always produce better diligence. For many buys, a targeted questionnaire of high value questions is more useful if each answer requires evidence.

For example, instead of asking, "Do you have access controls?", ask who can access production customer data, how access is approved, whether access is logged, how privileged access is reviewed and how quickly access is removed when staff leave or change roles.

Instead of asking, "Do you have a breach process?", ask who your contact person will be, what information the vendor will give you during an incident, how suspected breaches are escalated, and what support they will provide so your business can assess notification obligations under the Notifiable Data Breaches scheme.

This approach creates a usable record. It also exposes when a vendor is answering at a policy level while the actual product team, support model or subprocessor chain tells a different story.

Keep a short decision log: record each claim, the evidence supplied, the product or plan it covers, its date, who reviewed it, any unresolved exception, and the contract term needed to close the gap. A dated assurance report covering another service is then marked incomplete rather than accepted as a blanket yes. Procurement and legal teams get a precise list to resolve before access is granted.

The contract is where important answers belong

A questionnaire is an evidence record, not the contract. If a point matters to your decision, carry it into enforceable terms.

Depending on the risk, that may sit in a supplier agreement, security schedule, privacy schedule or data processing agreement. The contract should describe the data scope, permitted handling, access limits, reporting expectations and any vendor commitments that influenced your selection. For broader supplier terms such as scope, pricing and liability, our vendor agreements guide is a useful companion; it does not replace this security evidence review.

For higher risk arrangements, businesses often negotiate terms covering:

• what categories of personal information the vendor may handle and for what purposes
• security obligations framed around reasonable measures and the agreed service model
• the split of responsibilities between customer and vendor
• incident escalation, investigation cooperation and breach related information sharing
• approval or notice mechanisms for new subprocessors or material hosting changes
• restrictions on the vendor using the data for its own purposes
• audit, evidence or reporting rights appropriate to the deal
• exit support, data return and deletion or destruction confirmation

Terms should be negotiated according to risk. There is no single mandatory clause set for every Australian software purchase, and no document can guarantee compliance or prevent disputes. Sensitive, health, financial, employment or other regulated data usually justifies a more detailed legal, privacy and cyber review before access is granted.

A customer-support platform: what to check before access

Imagine you are buying a customer support platform that will contain names, contact details, complaint history and staff notes. The vendor says it is certified and widely used.

Your first step is to confirm what data will enter the platform, whether support staff can see live records and whether backups or analytics copies are made. Next, test whether overseas engineers or subprocessors can access the environment. Then ask how suspected incidents are reported to you and what evidence the vendor can provide about access controls, logging and deletion.

Where ASD guidance fits, and where it does not

The Australian Signals Directorate's Information Security Manual procurement and outsourcing guidance contains useful advice about supplier transparency, risk assessment and shared responsibility. It can help private businesses ask sharper questions of software and managed service suppliers.

But it is not automatically a binding legal checklist for every private sector SaaS purchase. Treat it as security guidance that may inform your diligence, especially for higher risk environments, rather than assuming every ISM control applies as a matter of law to your deal.

If you are buying software that will handle customer or employee information, Sprintlaw can help with vendor security questionnaires, privacy and data processing terms, SaaS contract negotiation and breach cooperation clauses. Call 1800 730 617 or email team@sprintlaw.com.au to discuss your next supplier contract.