Is your SaaS secure? A 9-point checklist — run a self-assessment before it becomes a problem.

Checklist

9 warning signs for B2B SaaS

Make a mental note of which ones apply to you. Each one is a real risk point — not a generic checklist item.

1. 01

   You haven't had a documented pentest in the last 12 months

   Without a recent pentest, you don't know whether you're secure — you only know you haven't been attacked yet, which is a different thing. Every feature that reached production in that period is an untested risk.

2. 02

   Your data protection "compliance" is just a privacy policy

   A privacy policy covers the legal side. But data protection law also demands technical measures — Brazil's LGPD, for example, requires them in Art. 46 for companies serving Brazilian users. Without documented technical evidence, you're exposed in enterprise due diligence or in a regulator's inspection (the ANPD, in Brazil).

3. 03

   Your team has never tested "what if I change the ID in the URL?"

   BOLA (Broken Object Level Authorization) is #1 on the OWASP API Top 10. Almost every B2B SaaS in production has at least one vulnerable endpoint. If nobody has manually tested cross-tenant access, assume you're vulnerable until proven otherwise.

4. 04

   Your OAuth flow has never been tested for state confusion

   Social login (Google, Microsoft, Apple) has classic account takeover patterns: state confusion, redirect URI fuzzing, code injection. Bug bounty researchers earn thousands of dollars finding these in well-known SaaS products. If you've never tested yours, you're a candidate.

5. 05

   You let customers configure webhook URLs

   If so, you need to block private ranges (127.0.0.1, 169.254.169.254, 10.0.0.0/8) on outbound requests. Without that, an attacker points the webhook at the AWS metadata service and exfiltrates IAM credentials. A pivot into your entire infrastructure.

6. 06

   Your billing and coupon endpoints have never been tested for race conditions

   An HTTP/2 single-packet attack sends 30 requests in the same TCP packet. Without an atomic lock, they're all processed in parallel: a single-use coupon gets redeemed 30 times, a negative balance gets spent, MFA gets bypassed through a race on the OTP code. A classic bug in products with financial flows.

7. 07

   You run a scanner every month and come up "clean"

   Nessus, Acunetix and automated Burp Pro scans find trivial XSS and outdated versions. They don't find BOLA, OAuth ATO, race conditions, SSRF chains, JWT confusion or business logic abuse — the vectors behind most breaches in 2026.

8. 08

   Your engineering team has never been trained in "adversarial thinking"

   Developers are trained to build. Researchers are trained to break. They're opposite mindsets. In code review, a developer checks that a feature works as specified — not that it DOESN'T do what it shouldn't. The result: features ship to production with positive test coverage and zero adversarial testing.

9. 09

   You don't have a documented incident response plan

   When a breach happens (or worse, you discover one from 3 months ago), what do you do in the first 24 hours? You'll need to notify the data protection authority within the deadline of the applicable law (e.g., the ANPD in Brazil, under LGPD Art. 48). Without a pre-written playbook, you make the wrong calls under pressure — and the regulatory damage gets worse.

Frequently asked questions

• How do I know if my SaaS is secure?

  The only reliable way is a manual pentest by a human researcher. An automated scanner catches trivial XSS and outdated versions — but not the cross-tenant BOLA, OAuth ATO, race conditions and SSRF chains that dominate attacks in 2026. As an initial assessment, use the 9-point checklist on this page: if 3 or more signs apply, your platform probably has a critical vulnerability.

• What signs indicate a SaaS may be vulnerable?

  9 practical signs: (1) no documented pentest in the last 12 months; (2) data protection compliance that exists only in legal documents; (3) nobody has manually tested cross-tenant BOLA; (4) OAuth has never been tested for state confusion; (5) webhooks accept URLs without an allowlist; (6) billing endpoints have never been tested for race conditions; (7) exclusive reliance on automated scanners; (8) a team with no adversarial training; (9) no incident response plan.

• Can I run the assessment myself?

  For a SURFACE-level assessment, yes — the checklist on this page gives you an initial read. But to confirm whether real vulnerabilities exist, you need a manual pentest: a researcher attacking your application the way a real attacker would, with a reproducible PoC for every finding. A self-assessment points to RISK; a documented pentest points to specific VULNERABILITIES.

• How long does it take to detect a breach in a SaaS?

  On average, organizations take months to detect a breach without dedicated tooling. In a B2B SaaS without a SIEM or active log monitoring, a sophisticated attacker can stay invisible for quarters. That's why periodic pentesting matters: it finds vulnerabilities BEFORE an attacker exploits them, avoiding the damage of late discovery.

• Do websites, SaaS platforms and apps have the same risk profile?

  No. A simple brochure website (no login) has limited risk: defacement, XSS, form data leakage. A B2B SaaS carries multi-tenant risk — one customer being able to see another customer's data — which is catastrophic (it breaches contracts and data protection law, such as Brazil's LGPD, and kills renewals). A mobile app adds the risks of reverse engineering, hardcoded secrets and deep link hijacking. Each one needs specific coverage.

• Does Brazil's LGPD apply to B2B SaaS?

  Yes, in full, for B2B SaaS that serves Brazilian users. A B2B SaaS processes users' personal data (even if your customers are companies, the end users are individuals). Every article applies: Art. 7 (legal bases), Art. 9 (information to the data subject), Art. 18 (data subject rights), Art. 37 (record of processing), Art. 46 (technical security measures), Art. 48 (incident notification). A breach triggers notification obligations to the ANPD (Brazil's National Data Protection Authority).

• What should I do if I find a critical vulnerability?

  (1) Don't disclose it publicly on social media or to the press — attackers are watching. (2) Confirm whether it was exploited (logs, anomalous behavior). (3) Fix it immediately in an isolated environment. (4) Assess the impact (how many customers were affected, what data was exposed). (5) If there was a breach, prepare to notify the data protection authority within the deadline of the applicable law (e.g., the ANPD in Brazil, under LGPD Art. 48). (6) Commission a validation pentest to confirm the fix and identify related bugs.

• How do I tell a serious pentest from a scanner sold as a pentest?

  A serious pentest has: researchers with a public track record (international bug bounty programs, CVEs, conference talks), a reproducible PoC for every finding, calibrated severity (CVSS 4.0 + business impact), retest included, direct communication with the researcher and an auditor-ready report. A scanner sold as a pentest delivers a PDF of Nessus/Acunetix screenshots with no manual PoC.