A security audit asks one question about your SaaS application: could someone get at data, accounts or money they should not? This guide walks a small team through a practical audit, from setting the scope to fixing what you find, and shows which standards matter for Indian businesses selling software online.
Define what you are auditing, then check it in layers: automated dependency and code scanning, a configuration review, and manual testing of login, access control and tenant isolation, which is where SaaS apps break most often. Write each finding with a severity, an owner and a deadline, fix and retest, then repeat on a schedule and after every major release. OWASP ASVS gives you the checklist; ISO 27001, SOC 2 and India's data-protection law tell you what customers and regulators will ask to see.
1. What a SaaS security audit covers
A SaaS app is not one program. It is the code, the libraries it pulls in, the servers and cloud accounts it runs on, the people with admin access, and the data of every customer sharing it. An audit that looks only at the code misses half of that.
2. Step 1: set the scope and the rules
Before anyone runs a tool, write down:
- What is in scope: the production app, the admin panel, public APIs, mobile apps, staging if it holds real data.
- What is out of scope: third-party services you do not control, such as your payment gateway or email provider. Review how you use them, not their servers.
- The rules of engagement: test accounts to use, testing hours, and who to call if something breaks.
- The benchmark: for most teams, OWASP ASVS (the Application Security Verification Standard) is the best checklist. Pick a level: Level 1 for most apps, Level 2 for apps handling personal or payment data.
Scanning or attacking systems you do not own is illegal in most countries, including India. If your app runs on hosting or cloud you rent, read the provider's acceptable-use terms before running intrusive scans, and never point tools at another company's servers.
3. Step 2: automated scanning
Automated tools find the known and the obvious quickly. Run them first so manual testing can focus on logic.
| Check | What it finds | Common free tools |
|---|---|---|
| Dependency scan | Libraries with published vulnerabilities | npm audit, pip-audit, Composer audit, GitHub Dependabot, OSV-Scanner |
| Static analysis (SAST) | Risky code patterns such as SQL built from strings | Semgrep, CodeQL |
| Secret scan | Passwords and API keys committed to Git | Gitleaks, TruffleHog |
| Container and server scan | Outdated packages in images and hosts | Trivy |
| Dynamic scan (DAST) | Missing headers, injection points, exposed files on the running app | ZAP |
| TLS check | Weak protocols and certificate problems | testssl.sh, SSL Labs |
Put the dependency, secret and static scans into your CI pipeline so every pull request is checked, not just the one before an audit. Treat tool output as leads: confirm each finding before you file it.
4. Step 3: manual testing where SaaS apps really break
Scanners cannot understand your business rules. These areas need a human with two test accounts in two different tenants.
- Tenant isolation. Sign in as tenant A, then request tenant B's records by changing IDs in URLs, API calls and file download links. Every query must be filtered by the signed-in user's tenant on the server. This broken-access-control class is the top risk in the OWASP Top 10.
- Authorisation on every route. Call admin APIs with a normal user's session. Hidden buttons protect nothing; the server must check the role.
- Authentication. Password hashing (Argon2id or bcrypt), rate limits on login and password reset, multi-factor authentication for admins, session expiry and logout that actually invalidates the session.
- Input and output. SQL and NoSQL injection, cross-site scripting, file uploads that accept scripts, server-side request forgery through URL-fetching features.
- Secrets and configuration. No keys in the front-end bundle, debug mode off in production, error pages that do not reveal stack traces.
- Business logic. Can a user skip a payment step, apply a coupon twice, or change a price in the request?
For code-level fixes, see OWASP Top 10: what actually breaks Indian web apps, preventing SQL injection, preventing XSS and JWT security best practices.
5. Step 4: review the infrastructure
- Access: who can reach production servers, databases and cloud consoles? Remove former staff, enforce MFA, and use SSH keys rather than passwords.
- Network: only the ports you need are open; databases are not reachable from the internet.
- Patching: operating system and runtime updates are applied on a schedule.
- Backups: they exist, are stored away from the server they protect, and a restore has actually been tested.
- Logging: logins, admin actions and permission changes are logged somewhere an attacker on the app server cannot erase.
- HTTP security headers: HSTS, a content security policy and the rest; see security headers explained.
If you run your own servers, the VPS security checklist and the SSH hardening checklist cover the basics.
6. Step 5: report, fix and retest
A useful audit report is short and actionable. For each finding record:
- What and where.The vulnerable endpoint, file or setting, and how to reproduce it.
- Severity.Critical, high, medium or low, based on how easy it is to exploit and what an attacker gains. CVSS scores help for library vulnerabilities.
- Fix and owner.The recommended change and the person responsible.
- Deadline.For example, critical within days, high within a couple of weeks, the rest in the next planned release.
- Retest.Mark it closed only after someone confirms the fix works.
Keep the executive summary to one page: the overall risk, the top findings and what is being done. Management needs that page; the engineers need the detail.
7. Standards and laws to know
| Framework | What it is | Who asks for it |
|---|---|---|
| OWASP ASVS and Top 10 | Technical checklists for web application security | Your own team; security-aware customers |
| ISO/IEC 27001:2022 | Certifiable information security management system | Enterprise and international customers |
| SOC 2 | Auditor's report on security and other trust criteria | US customers, especially in B2B SaaS |
| NIST Cybersecurity Framework 2.0 | Voluntary framework for organising a security programme | Teams wanting a structure to follow |
| DPDP Act, 2023 | India's Digital Personal Data Protection law and its rules | Anyone processing personal data of people in India |
| GDPR | EU data-protection regulation | Anyone serving people in the EU |
In India, CERT-In's 2022 directions also require specified cyber incidents to be reported to CERT-In within six hours of noticing them, so your incident plan should say who reports and how. Laws and certification rules change; confirm current requirements with a qualified adviser before you rely on them for compliance.
8. Make it a habit, not an event
- Run automated scans on every change and a full audit at least once a year, and after major features such as new payment flows or a new API.
- Consider an independent penetration test before you sign large customers; many will ask for the report.
- Keep a simple risk register and review it quarterly.
- Train everyone with admin access to spot phishing, because a stolen admin password bypasses every control above.
9. Running an audited SaaS app on Domain India
A Domain India VPS gives you full root access, so you control the operating system, firewall, SSH configuration and logging that an infrastructure review looks at. It is self-managed: patching, hardening and backups are your responsibility. The App Platform runs your app in its own container with free SSL and a PostgreSQL database, so there are fewer servers for you to audit. Node.js apps are detected automatically, and anything else runs from your own Dockerfile.
- 2 vCPU
- 4 GB DDR4 RAM
- 128 GB NVMe SSD Storage
- 3 TB Monthly Bandwidth
- 512 MB RAM per app
- 1.5 GB RAM total
- 2 vCPU
- 10 GB NVMe SSD
Prices on the cards are Domain India list prices and exclude 18% GST.
How often should a SaaS application be security audited?
Run automated dependency, secret and code scans on every change, and a full audit at least once a year. Audit again after major changes such as a new payment flow, a new public API or a move to new infrastructure.
What is the difference between a vulnerability scan and a penetration test?
A vulnerability scan is automated and finds known issues such as outdated libraries and missing headers. A penetration test is done by a person who tries to exploit the app, including business-logic and access-control flaws that tools cannot understand.
What is the most common security flaw in SaaS applications?
Broken access control, including one tenant being able to read another tenant's data by changing an ID. Every query must be filtered by the signed-in user's tenant on the server, and every admin route must check the role.
Which checklist should a small team use for an application audit?
OWASP ASVS. Level 1 covers the basics every app needs, and Level 2 suits apps that handle personal or payment data. The OWASP Top 10 is a good awareness list but not a full checklist.
Do Indian SaaS companies need to comply with a data-protection law?
Yes. The Digital Personal Data Protection Act, 2023 and its rules apply to digital personal data of people in India. CERT-In directions also require reporting specified cyber incidents within six hours. Take legal advice for your specific obligations.
Can I run security scans against my app hosted on a VPS?
Yes, against your own app and server, which you control. Do not scan systems you do not own, and check your provider's acceptable-use terms before running intrusive tests.
Ready to put your SaaS app on infrastructure you control? Compare VPS plans, look at the App Platform, or open a support ticket to ask which fits your app.
Full root access, so you decide how your servers are hardened, logged and audited.
See VPS plans