Security for B2B SaaS companies: multi-tenant isolation, secure SDLC, and incident response

Why B2B SaaS platforms are high-value targets

A B2B SaaS product is, by definition, a concentration of trust. Every customer company hands the platform its business data, user credentials, integrations with internal systems and, frequently, the personal data of its own end customers. When a single provider hosts dozens, hundreds, or thousands of these organizations in a shared multi-tenant architecture, compromising the provider means gaining access to all of them at once. For an attacker, this completely changes the economics of the attack: instead of breaking into a hundred companies individually, they only need to find one flaw in the SaaS that serves them.

This logic of attacking a single point to reach many is what is called vendor compromise, or a supply chain attack from the customers' point of view. The SaaS stops being merely a product and becomes part of the attack surface of every organization that uses it. That is why the security teams of buying companies treat your SaaS as a risk vendor, demanding formal evidence of controls — security questionnaires, SOC 2 reports, pentest proof, and contractual incident-notification clauses. Security maturity is no longer a marketing differentiator; it has become a prerequisite for selling in the enterprise segment.

There is also an aggravating factor in reputation and contracts. When a SaaS suffers an incident, it does not answer only to the ANPD or its regulators: it must simultaneously notify every affected customer, each with its own legal team, its own duty to inform data subjects and, often, its own sector-specific regulatory obligations. An incident in a B2B SaaS is, in practice, several chained incidents. The response must be fast, technically precise, and coordinated with multiple stakeholders at the same time.

The five threats that most often bring down B2B SaaS

1. Multi-tenant isolation flaws

Isolation can be implemented in several ways — a database per tenant, a schema per tenant, or a row per tenant with a tenant_id column in shared tables. The shared-row model is the most economical and the most dangerous, because isolation is no longer guaranteed by infrastructure and instead depends on each application query correctly including the tenant filter. It only takes one developer forgetting the clause in a report, a batch job, or a new endpoint for one customer's data to appear to another. In architectures with caching, the risk multiplies: a cache key without the tenant in its identifier serves one customer's response to another.

2. Cross-tenant data leakage

Cross-tenant leakage is the materialization of the isolation flaw. It usually appears through IDOR (Insecure Direct Object Reference) or BOLA (Broken Object Level Authorization), the categories that lead the OWASP API Security Top 10. The pattern is always the same: the system identifies the requested object by its ID but does not verify whether that object belongs to the authenticated user's tenant. Changing a number in the URL or request body starts returning another company's data. Because the user is legitimately authenticated, this access often triggers no alert — it looks like normal traffic.

3. API and SSO compromise

B2B SaaS is, in essence, API. API keys scoped too broadly, JWT tokens whose signature or tenant claim is not validated on the server, the absence of rate limiting, and exposed administrative endpoints are classic points of entry. In SSO, the risks concentrate on the validation of SAML assertions and OIDC tokens: unverified signatures, key confusion attacks, missing audience checks, and incorrect binding between federated identity and tenant. A mistake in this layer lets an attacker authenticate as a user — or administrator — of another customer.

4. Supply chain and dependencies

Modern SaaS applications are assembled on top of hundreds of third-party libraries, container images, and external integrations. A vulnerable dependency, a malicious package introduced via typosquatting, or a credential leaked in a CI/CD pipeline can compromise the entire build. Because third-party code runs with the application's privileges, it has the same access to every tenant's data. Vulnerability management here is not scanning once a quarter — it is maintaining an inventory (SBOM), monitoring continuously, and having a patching process with an SLA.

5. Administrator account takeover

In a B2B SaaS, a tenant's administrator user has power over all users and data of that company. Taking over that account — via phishing, password reuse, the absence of MFA, or a flaw in the password recovery flow — gives the attacker full control over that customer. Even worse is the compromise of an operator account belonging to the platform itself, which may have cross-tenant visibility for support purposes. These privileged accesses require strong MFA, separation of duties, and an immutable audit trail.

Anatomy of an isolation flaw (anonymized real-world example)

Imagine a relationship-management SaaS platform serving hundreds of companies in a shared-row architecture — all tenants in the same database, separated by a tenant_id column. The product team, under deadline pressure, launches a new report-export endpoint. The endpoint receives the report ID and returns the file. The code that builds the query filters by the report ID, but the developer who wrote the export function assumed the previous layer had already validated the tenant — and it had not, for that new path. The result: any authenticated user of any company, by changing the report ID in the request, receives reports belonging to other customers.

The flaw goes unnoticed for weeks. There is no error, no exception, no alert. The logs record authenticated requests and responses with a 200 code. Everything looks normal. Until, during a contracted pentest, a Decripte analyst tests exactly this vector — enumerating object IDs from a legitimate tenant account — and receives back data belonging to another company. From there, the anatomy of the incident unfolds along the timeline in the case study below.

What changes in incident response when the target is a SaaS

Responding to an incident in a B2B SaaS is more complex than in a traditional company for three reasons. First, the scale of notification: the provider must identify which tenants were affected and communicate with each of them, respecting distinct contractual and regulatory obligations. Second, business continuity: stopping the platform to contain a leak means stopping every customer's operation at the same time, so containment must be surgical — blocking the vulnerable endpoint, revoking tokens, isolating the vector — without bringing down the entire service when possible. Third, the evidence: enterprise customers and the ANPD will demand a detailed technical report on root cause, scope, and remediation.

This is why the containment SLA matters so much. The sooner Decripte detects the anomalous access in the SOC, the sooner the vector is blocked, the smaller the exfiltration window, and the smaller the universe of potentially affected tenants. Containing within one hour, rather than discovering weeks later, is the difference between a notifiable, controlled incident and a crisis that spreads across the entire customer base.

Compliance your enterprise customer will demand

In B2B SaaS, compliance is not just a regulatory obligation — it is a sales enabler. SOC 2, an attestation framework based on the AICPA's Trust Services Criteria, has become the de facto standard that enterprise buyers ask for before signing a contract. There are two types: SOC 2 Type I, which evaluates the design of controls at a point in time, and SOC 2 Type II, which evaluates the effective operation of those controls over a period (typically six months to a year). Type II is the one that carries real weight, because it proves that the controls not only exist on paper but function day to day.

Decripte structures this journey pragmatically: first a gap assessment against the target framework, then the implementation of the missing controls — many of them directly tied to the multi-tenant technical defenses described here — and finally preparation for the audit. The great advantage of handling compliance alongside pentesting, SOC, and vulnerability management is that the controls required by SOC 2 are exactly the ones that protect against real attacks. It is not duplicate work: it is the same work producing, on one side, security, and on the other, auditable evidence.

Secure SDLC: prevent before you test

Finding isolation flaws in a pentest is essential, but it is cheaper and safer not to introduce them in the first place. That is why Decripte works on the secure development life cycle (SDLC) alongside the customer's engineering team. This means establishing an architectural standard in which the tenant is bound at the lowest level possible — ideally a data access layer that automatically injects the tenant filter into every query, or row-level security policies in the database, so that forgetting the filter is no longer a human possibility.

In the development flow, this translates into code review focused on authorization, automated tests that verify one tenant cannot access another's data as part of the regression suite, static analysis (SAST) and dependency analysis (SCA) integrated into the pipeline, and security gates that prevent the deployment of code with known high-severity vulnerabilities. Security stops being a final step and becomes a continuous property of the delivery process.

How it all connects: discovery, defense, and evidence

The strength of a B2B SaaS security posture lies not in any single control, but in the cycle that connects them. The pentest discovers flaws that become remediation items and, at the same time, test cases that enter the SDLC so they do not return. Vulnerability management keeps the dependency chain and infrastructure under continuous watch, feeding the engineering team what needs to be fixed and at what priority. The 24x7 SOC observes the platform in production, with tenant-aware detection rules, ready to respond. And compliance turns this entire operation into auditable evidence that unlocks enterprise sales.

This chain is what separates a company that merely reacts to incidents from one that structures security as a continuous capability. For a B2B SaaS, where each new customer raises the value of the target and each incident multiplies across the base, this cycle is not a luxury: it is the condition for growing securely. Start with a free exposure assessment at decripte.com.br/intelligence-center and, when you want to structure the full cycle, talk to Decripte at decripte.io/start or via /contato.

Anatomy of a cross-tenant leak: from pentest discovery to SOC 2 structuring

How Decripte responds to a B2B SaaS incident

Incident response in multi-tenant environments demands speed in containment and precision in scope, because every hour lost widens the number of potentially affected customers and the complexity of notification. Decripte's method follows coordinated steps, with a containment SLA of up to one hour.

1. Engagement and triage: immediate activation of the response team, severity classification, and preliminary identification of the vector (isolation flaw, API/SSO compromise, account takeover, or supply chain).
2. Tenant-aware detection: the SOC activates and reviews rules that correlate which tenant each user should access versus what they actually accessed, to distinguish legitimate traffic from cross-tenant exploitation and estimate the real scope.
3. Surgical containment within 1h: blocking the vulnerable endpoint or vector, revoking compromised tokens and sessions, and applying edge rules, preserving platform continuity for unaffected customers whenever possible.
4. Evidence preservation and root cause analysis: forensic collection of logs and artifacts, reconstruction of the timeline, and precise identification of the flaw that caused the incident, ensuring chain of custody for the report.
5. Eradication and definitive fix: removal of the vector at its root cause (not just the symptom), reinforcement of isolation, rotation of exposed secrets, and the addition of regression tests to prevent recurrence.
6. Mapping affected tenants and cascading notification: precise definition of which customers were impacted and support in the technical communication to each controller, enabling compliance with LGPD obligations toward data subjects and the ANPD.
7. Monitored recovery: return to full operation with reinforced watch over the handled vector and validation that the fix is effective in production.
8. Post-incident and hardening: an executive and technical root cause report, structural recommendations, and the conversion of lessons into permanent controls in SDLC, vulnerability management, and compliance.

How Decripte structures the security of a B2B SaaS platform

Beyond responding to incidents, Decripte structures multi-tenant security as a continuous capability, organized into mutually reinforcing pillars — from prevention in the code to auditable evidence for enterprise customers.

Recommended plans for B2B SaaS

Frequently asked questions

Sector terms

Multi-tenancy

An architecture in which a single software instance serves multiple customer companies (tenants), with their data logically separated. Isolation between tenants is the most critical security control of this model.

IDOR / BOLA

Insecure Direct Object Reference / Broken Object Level Authorization. A flaw in which the system locates an object by its ID but does not verify whether the authenticated user has the right to access it. In multi-tenant SaaS, it is the typical cause of cross-tenant leakage and leads the OWASP API Security Top 10.

Cross-tenant leakage

Exposure of one customer's (tenant's) data to another within the same platform, usually resulting from an isolation or authorization flaw. It is the materialization of the central risk of a multi-tenant SaaS.

SOC 2

A control attestation framework based on the AICPA's Trust Services Criteria. Type I evaluates the design of controls at a point in time; Type II evaluates their effective operation over a period. The de facto standard demanded by enterprise SaaS buyers.

Row-Level Security (RLS)

A database mechanism that restricts, at the level of each row, which records a session can access. In multi-tenancy, it is used to enforce the tenant filter in the infrastructure itself, reducing dependence on the application remembering to apply it.

SBOM

Software Bill of Materials. An inventory of all third-party components and dependencies that make up an application. It is the foundation of supply chain vulnerability management, making it possible to quickly know which systems are affected when a vulnerability arises in a package.