For SaaS products, security is not an add-on but a precondition for every business customer. The first security questionnaire at the latest shows whether the basics are in place. This baseline describes the measures a SaaS product in the German-speaking region should have from the start. It comes from operating our own product portfolio.
Identity and access
Multi-factor authentication for all accounts with administrative rights and as an option for all users, single sign-on via SAML or OIDC for business customers, and a role model based on least privilege. Administrative access to infrastructure is personal, not shared, and is revoked immediately when someone leaves.
Tenant isolation in the database
In multi-tenant applications, customer separation belongs in the database, for example through row-level security in PostgreSQL. Separation in application code alone is not enough, because a single faulty filter exposes another customer’s data. Tests that deliberately try to read another tenant’s data belong in the automated test suite.
Secrets and dependencies
API keys and credentials are not in code but in a secrets store and are rotated regularly. Dependencies are scanned automatically for known vulnerabilities, and a bill of materials of the components used makes it easier to respond when a new vulnerability becomes known.
Protect and restore data
Encryption in transit and at rest is standard. Backups follow the 3-2-1 rule and, crucially, are restored regularly. A backup whose restoration has never been tested is an assumption, not protection. Recovery time and tolerable data loss should be defined before a customer asks.
Logging and abuse protection
Security-relevant events such as logins, permission changes and data exports are logged in an audit trail that cannot be altered afterwards. Rate limiting protects login and API against automated attacks. Security headers such as a content security policy reduce the attack surface in the browser.
When something happens
A short incident response plan defines who decides, how customers are informed and which notification duties apply, under the FADP, the GDPR and, for customers in regulated sectors, contractually. A public route for reporting vulnerabilities shows professionalism and prevents reports from getting lost in the support inbox.
Evidence for customers
This baseline is also the basis for answering security questionnaires; how to structure them is described in our article on security questionnaires. Individual building blocks are explained in the glossary entries on row-level security, secrets management and 3-2-1 backups; an independent review is offered by our SaaS security audit.