Moving business software to the cloud does not hand every security decision to the provider. A company that uses software as a service (SaaS) still controls its users, data, integrations, and account settings. A team that builds SaaS also has to secure its application, deployment process, and boundaries between customers.
The practical risks depend on which side you operate. This checklist separates actions for SaaS customers from the controls a SaaS provider must build, so a small team can prioritize the work it actually owns.
Start with your security boundary
Write down the sensitive data you collect, where it flows, which people and services can access it, and which vendors store or process it. Include email, source control, cloud accounts, payment tools, support systems, analytics, backups, and connected SaaS services—not only your production database.
Then confirm what your provider secures and what you must configure or operate. A vendor’s security page or compliance report can inform that review, but it does not prove that your tenant settings, integrations, or application code are safe. The NIST Cybersecurity Framework is one way to organize a small program around governing, identifying, protecting, detecting, responding, and recovering.
SaaS security risks and practical controls
1. Compromised accounts and excessive access
An attacker who takes over an administrator’s email, source-control, cloud, or SaaS account may be able to reset other credentials or reach customer data. Shared logins and forgotten contractor accounts make it harder to see who did what.
- Turn on multifactor authentication for email, domain registration, source control, cloud consoles, billing, and SaaS administrators. Prefer stronger phishing-resistant options when a service supports them.
- Give each person a separate account. Keep administrator access limited, use a separate admin identity for sensitive work, and remove access promptly when a role changes or someone leaves.
- Review service accounts and integration tokens too. Restrict them to the resources and actions they need, and set an owner and a way to revoke each credential.
For SaaS teams, check authorization on every request rather than relying on a hidden button or client-side check. The OWASP Authorization Cheat Sheet recommends deny-by-default decisions and permission checks for each requested action.
2. A customer accessing another customer’s data
For a multi-tenant product, a missing object-level authorization check can let one customer read or change another customer’s records. The risk can extend beyond ordinary API requests to background jobs, file downloads, search results, caches, exports, and support tools.
Derive the tenant context from the authenticated session on the server; do not trust a tenant ID supplied by the browser as proof of access. Check both the user’s permission and the resource’s tenant ownership at each boundary. Add negative tests that try to read, update, and export another test tenant’s data, and rerun them when authorization or data-access code changes.
The OWASP API Security Top 10 covers broken object-level authorization, while the AWS SaaS Lens discusses tenant isolation as an architectural concern. AWS examples describe its platform, but the isolation questions apply to SaaS design generally.
3. Exposed secrets, unsafe changes, and vulnerable dependencies
API keys, signing keys, database passwords, and deployment tokens can leak through source code, build logs, support tickets, or overly broad CI credentials. Removing a leaked value from the latest commit is not enough if it may already have been copied.
Store secrets outside code and logs, grant each workload only the access it needs, and revoke or rotate credentials after exposure. Protect deployment credentials and production changes with narrowly scoped permissions. Keep runtimes and dependencies on supported versions, review security updates, and make the release process reproducible enough to identify what changed.
The OWASP Secrets Management Cheat Sheet provides implementation guidance; NIST’s Secure Software Development Framework helps teams build security practices into development and release work.
4. Excessive data collection and unsafe integrations
Every extra copy of customer data creates another place to secure, retain, and eventually delete it. A broadly scoped integration token or production data copied into a developer account can turn a minor account compromise into a larger incident.
Collect only what the product needs, separate production from test data, and restrict connected apps to the minimum permissions. Document retention and deletion behavior, including what happens to data in backups and vendor systems. Encrypt data in transit and use the protection offered by your storage and database services, while remembering that encryption does not replace access controls or careful key handling.
5. Backups that cannot restore the service
A provider’s uptime promise, recycle bin, or snapshot feature may not give you an independent, usable recovery copy. Check what is backed up, how long it is retained, who can delete it, and whether you can export the data in a usable format if you change providers.
Back up critical customer data and configuration according to your recovery needs, protect backup access separately from day-to-day accounts, and test a restore. Include the steps needed to rebuild the application and its integrations—not just a database file. NIST’s contingency planning guidance can help teams think through recovery priorities and procedures.
6. Missing logs and an unprepared response
Without useful audit records, it can be difficult to tell whether an account was misused, which data was accessed, or what changed before an outage. Record important authentication events, administrator and permission changes, sensitive exports, and security-relevant application failures.
Avoid putting passwords, tokens, session identifiers, or unnecessary personal data in logs. Set alerts for a small number of meaningful events and decide who will investigate them. Keep an incident contact list, know how to revoke sessions and keys, and confirm how to contact providers if an account or service is compromised. The OWASP Logging Cheat Sheet explains useful logging practices and sensitive data to exclude.
7. Unclear provider and vendor responsibilities
Security duties vary by service and plan. A SaaS customer may manage user access and data exports while the provider manages the application and infrastructure; a SaaS builder may depend on separate cloud, email, payment, and monitoring providers. Do not assume that a cloud provider’s controls cover your application or that a vendor’s certification covers your configuration.
For important vendors, record what data they handle, the security settings you control, how incidents are reported, how data is exported or deleted, and what happens if the service is unavailable. Keep an alternative way to reach critical business records and customers when a service is down.
A first-week security plan for a small team
Start with work that reduces the chance or impact of a common account or data incident:
- Enable MFA on the accounts that can reset passwords, change DNS, deploy code, or access customer data. Remove old users and rotate any credentials you cannot account for.
- Map your sensitive data, integrations, administrators, and vendors. Assign an owner to each critical system.
- If you operate a multi-tenant product, test that one tenant cannot access another tenant’s records through APIs, exports, and background workflows.
- Confirm what is backed up, restore a copy in a safe environment, and write down the recovery steps.
- Decide which security events you will log and alert on, who responds, and how you will contact affected providers.
Revisit the list when you add a new integration, change how customer data is stored, or make a significant access-control change. A short, owned checklist that is tested is more useful than a long policy no one follows.
