SaaS Security for Founders: What Customers Ask About Before They Sign
SaaS security explained for founders: the controls buyers check in a security questionnaire, a build order, and what SOC 2 or ISO 27001 really involve.

SaaS security is the set of controls that stop one customer seeing another's data, keep attackers out and let you recover when something goes wrong. Enterprise buyers check it before they sign, usually with a security questionnaire that arrives after the demo and before the contract.
You do not need a security department to pass it. You need a short list of controls that are built properly, written down and provable. This guide covers that list, the order to build it in and what certifications ask of you.
Key Takeaways
- Buyers ask about the same eight areas: tenant isolation, logins and MFA, encryption, backups, logging, patching, staff access and incident response.
- Multi-tenant data isolation is the control most likely to sink a deal, because a flaw there exposes every customer at once.
- Businesses covered by the Privacy Act must notify the OAIC and affected people about eligible data breaches, so a written response plan is a legal need.
- The ACSC's Essential Eight is a free government checklist that maps well onto buyers' questions, and it does not need independent certification.
- SOC 2 and ISO/IEC 27001 are worth pursuing when buyers ask for them, and they take sustained effort from your team, not just an auditor's fee.
Why Do Enterprise Buyers Send a Security Questionnaire?
A buyer who puts customer or staff data into your product is trusting you with a risk they cannot see. The questionnaire is how their security team measures it, and a vague answer slows the deal as much as a wrong one. Most questions reduce to the eight areas above. If you can answer each with a sentence and a piece of evidence, such as a policy, a screenshot or a test result, you are ahead of many early-stage vendors.
How Do You Keep One Customer's Data Away From Another's?
This is multi-tenant data isolation, and a careful buyer asks about it first. In a shared SaaS system, many customers use the same application and often the same database. The code must make sure every request only reads and writes the records belonging to the signed-in customer.
The common designs are a separate database per customer, a separate schema per customer, or shared tables with a tenant identifier on every row. Separate databases isolate hardest and cost more. Shared tables are cheapest and depend on the tenant check being right everywhere, so enforce it in one central place. Our guide to the SaaS tech stack covers the wider trade-offs. Whatever you choose, test it: sign in as customer A, request customer B's record and confirm the system refuses. Keep that test in your automated suite so a later change cannot quietly break isolation.
What Do Buyers Expect for Logins, Encryption and Backups?
Authentication and MFA
Buyers expect multi-factor authentication (MFA) for your staff and an MFA option for their users. The ACSC's Essential Eight maturity model lists MFA for customers of online services that handle sensitive customer data, and at higher levels asks for a phishing-resistant option. Support single sign-on too, because large organisations prefer to control their own accounts.
Encryption in transit and at rest
Data should be encrypted while it moves between the user, your application and your database, and while it sits in storage and backups. Your cloud provider and a correct TLS setup do most of this. The harder questions are who holds the encryption keys and how they are rotated, so decide that before a buyer asks.
Backups and recovery
A backup you have never restored is a hope, not a control. The ACSC model asks for backups kept securely, protected from changes by ordinary user accounts, with restoration tested as part of disaster recovery exercises. Write down how much data you could lose and how long recovery takes, then time a real restore.
How Do You Handle Logging, Patching and Staff Access?
- Logging. Record sign-ins, permission changes, administrative actions and access to customer data, and store logs where staff cannot edit them. The ACSC model asks for event logs to be protected from unauthorised modification and deletion.
- Patching. The same model sets 48 hours for fixes to online services when the vendor rates a vulnerability critical or a working exploit exists, and two weeks for others. Use that as a benchmark, noting it was written for organisational IT generally, not for SaaS products.
- Staff access. Give each person the least access their job needs, remove it the day they leave and keep production data off developer laptops. The model also asks for restricted administrative privileges.
Patching is where security meets running costs. Someone has to apply, test and release updates every month, which is part of the bill we describe in software maintenance costs.
What Must You Do After a Data Breach in Australia?
If your organisation is covered by the Privacy Act 1988, the Notifiable Data Breaches scheme applies. The OAIC says an eligible data breach is unauthorised access to or disclosure of personal information that is likely to cause serious harm, where remedial action has not prevented that harm. You must then tell the affected individuals and the OAIC.
The OAIC's quick reference guide sets out four steps: contain, assess, notify and review. If you only suspect an eligible breach, you must take all reasonable steps to finish your assessment within 30 calendar days. The notice must include your contact details, a description of the breach, the kinds of information involved and recommended steps for individuals.
For a SaaS company this means an incident plan that names who decides, who contacts customers and where the logs are. Customers will also expect a contract clause promising to tell them quickly.
What Order Should You Build SaaS Security In?
Do the cheap, high-impact controls first and the paperwork-heavy ones when a deal needs them. The order below is our judgement as a software team, not a standard.
- Before your first customer - Controls to have: Tenant isolation tests, staff MFA, TLS and encryption at rest, automated backups, least-privilege staff access, basic logging; Why it matters then: Hard to retrofit, and an early breach can end the business
- Before mid-size customers - Controls to have: Customer MFA option, a tested restore, a patching routine with named owners, a written incident plan, a questionnaire answer bank; Why it matters then: Buyers start asking for evidence, not assurances
- Before enterprise deals - Controls to have: Single sign-on, customer-visible audit logs, independent penetration testing, written policies, a SOC 2 or ISO/IEC 27001 decision; Why it matters then: Procurement wants third-party proof and written policy
Do You Need SOC 2 or ISO/IEC 27001, and What Do They Demand?
Neither is a legal requirement for selling SaaS in Australia. Both are independent proof that your controls exist and are managed, so ask your biggest prospects which one they accept before you pick.
SOC 2 sits in the System and Organization Controls suite run by the American Institute of CPAs. Licensed CPA firms deliver it, and it covers controls relevant to security, availability, processing integrity, confidentiality or privacy. The AICPA's page says SOC services should be thoroughly evaluated, so choose your auditor carefully and be wary of promises of fast and easy.
ISO/IEC 27001 is an international standard for an information security management system. ISO says it covers establishing, implementing, maintaining and continually improving that system through risk management, and that certification is optional.
We will not invent a price, because audit fees vary by firm and scope. The effort is more predictable: your team defines the scope, writes and follows policies, assesses risks, collects evidence on a schedule, fixes gaps and supports the auditor. Get written quotes and timelines before committing.
For many Australian customers, a clear Essential Eight position is a good first step. The ACSC notes certification of it is not required, though a contract may call for independent assessment.
Related Resources
- ACSC Essential Eight explained
- OAIC guide to the Notifiable Data Breaches scheme
- ISO/IEC 27001 overview
- AICPA SOC suite of services
- SaaS MVP development
- choosing a SaaS tech stack
Common Questions About SaaS Security
1. What is SaaS security?
SaaS security is the set of controls that protect customer data and keep a hosted product available. It covers how tenants are separated, how people log in, how data is encrypted and backed up, how activity is logged and how you respond to an incident.
2. Do I need SOC 2 to sell SaaS in Australia?
No law requires it. Some enterprise buyers ask for a SOC 2 report or an ISO/IEC 27001 certificate, but many accept a completed questionnaire and evidence of the basics. Ask your target buyers what they require before you commit to an audit.
3. What is multi-tenant data isolation?
It is how a shared SaaS system makes sure one customer can never read or change another customer's data. It is enforced in the application and database design, and it should be tested on purpose, not assumed.
4. Does the Notifiable Data Breaches scheme apply to my SaaS company?
It applies to organisations covered by the Privacy Act 1988, which the OAIC says includes businesses with annual turnover above $3 million AUD and some smaller operators. If you hold customers' personal information, confirm your status and plan as if it applies.
5. Can a small team meet enterprise security expectations?
Yes, for the basics. Strong logins with MFA, encryption, tested backups, patching, logging, staff access control and a written incident plan are within reach of a small team. You are usually asked to show these controls, not to run a security department.
Buyers Trust Evidence, Not Promises
The founders who clear security reviews fastest built the basics early and can show proof. Isolation tests, a restored backup, a patching log and a written incident plan answer most of a questionnaire before it is sent.
If you are planning a SaaS product or hardening one that is already live, send 9Byte a brief describing your customers and what they have asked for so far.


