Security Architecture Review for B2B SaaS
Enterprise B2B customers do not trust SaaS security posture by default — they verify it. A security architecture review is the internal process that prepares a SaaS company to answer enterprise security questionnaires, pass third-party penetration tests, and maintain the SOC 2 or ISO 27001 audit evidence that large customers require before signing contracts. Most SaaS companies discover they need a security architecture review when an enterprise prospect sends a 200-question security questionnaire. The time to do the review is before that questionnaire arrives.
🗺️ Step 1: Data Flow Mapping
A security architecture review begins with a complete data flow map — where data enters the system, where it is stored, who can access it, and how it exits. Without a data flow map, threat modeling is speculative. With one, threats can be traced to specific components.
Data flow map components:
- → Entry points: Every API endpoint, webhook receiver, file upload handler, and third-party integration that brings data into the system
- → Storage locations: Primary database, caches (Redis, Memcached), object storage (S3), search indexes (Elasticsearch), logging systems, analytics pipelines
- → Access control boundaries: Which services can read which data, which roles can access which records, what crosses a trust boundary
- → Exit points: Data exports, API responses, webhook payloads, email content, third-party service integrations that receive data
Draw this map in a tool your team can maintain (Lucidchart, draw.io, or even a structured Notion page). The map is both a security artifact and an onboarding document for new engineers.
⚠️ Step 2: Threat Modeling
Threat modeling identifies what could go wrong with your architecture before an attacker does. The STRIDE framework is the most practical threat modeling approach for SaaS teams without a dedicated security team:
| STRIDE Category | What It Covers | SaaS Examples |
|---|---|---|
| Spoofing | Impersonating another user or service | JWT token forgery, OAuth token hijacking, account takeover via credential stuffing |
| Tampering | Modifying data or code without authorization | SQL injection, mass assignment vulnerabilities, unvalidated file uploads |
| Repudiation | Performing actions without accountability | Missing audit logs, unsigned webhook payloads, actions without user attribution |
| Information Disclosure | Exposing data to unauthorized parties | IDOR vulnerabilities, verbose error messages leaking stack traces, unsecured S3 buckets |
| Denial of Service | Making the service unavailable | Missing rate limiting, no request size limits, algorithmic complexity attacks |
| Elevation of Privilege | Gaining unauthorized access levels | Broken access control, insecure direct object references, admin endpoints without auth checks |
🔐 Step 3: Authentication and Authorization Review
Authentication and authorization vulnerabilities are the most common source of enterprise security findings in SaaS products. Review each of these specifically:
- → Password storage: Passwords must be hashed with bcrypt, Argon2, or scrypt with appropriate work factors. MD5 and SHA-1 password hashing are unacceptable for enterprise customers.
- → Session management: Session tokens must be cryptographically random (128+ bits), stored in HttpOnly cookies, and invalidated on logout and password change. Server-side session revocation must be possible.
- → Multi-factor authentication: Enterprise customers will require MFA. TOTP (authenticator app) is the minimum; SAML/SSO integration is required for contracts above $10,000 ACV.
- → API authentication: API keys must have scoped permissions (read vs write vs admin), must be rotatable without service interruption, and must appear in audit logs on every use.
- → Authorization checks: Every API endpoint that returns or modifies data must verify that the authenticated user has permission to access that specific resource — not just that the user is authenticated. Missing authorization checks (IDOR vulnerabilities) are the most common security finding in enterprise SaaS reviews.
📦 Step 4: Third-Party Dependency Assessment
Modern SaaS products depend on dozens of third-party services and hundreds of open-source libraries. Each dependency is a potential security risk that enterprise customers will ask about.
- → Vendor security posture: For every third-party service that touches customer data (payment processors, email providers, analytics, support tools), document whether they have SOC 2 Type II, ISO 27001, or equivalent certification. Enterprise customers will ask.
- → Open-source dependency vulnerabilities: Run automated dependency scanning (GitHub Dependabot, Snyk, or npm audit) and maintain a process for applying security patches within 30 days of public disclosure. Critical vulnerabilities require a 7-day remediation SLA for enterprise contracts.
- → Sub-processor list: GDPR requires you to maintain and publish a list of sub-processors (third parties that process customer data on your behalf). Enterprise data privacy teams will request this list before signing.
What to Do Next
If you have no security review process: start with the data flow map — spend 4 hours drawing every place customer data goes in your system, then run STRIDE against your three highest-risk entry points. This will surface your most critical vulnerabilities without requiring an external security consultant. If you are preparing for SOC 2: the data flow map and threat model are required artifacts for SOC 2 Type I audit evidence. Complete them before engaging an auditor and you will reduce audit preparation time by 30–40%.