SAAS Security

Module B includes Module A. A Module B engagement evaluates the underlying web application (Module A scope) plus the tenant-aware evaluation areas. If your product is a multi-tenant SaaS platform, you do not need a separate Module A engagement — Module B alone covers both layers and produces a single certificate.

Combine Module B and Module C on a single certificate. Module B covers the multi-tenant platform and customer-facing UI; Module C separately addresses the API surface anchored in the OWASP API Security Top 10. Both modules evaluated together produce a unified certificate covering the full product surface, scoped explicitly in the Scope Statement.

SOC 2 is a Trust Services Criteria-based attestation issued by a CPA firm, addressing the controls of a service organisation. Module B is an ISO/IEC 17065-accredited product certification, evaluating a specific multi-tenant SaaS product against OWASP ASVS plus tenant-aware criteria. SOC 2 is broader in operational scope; Module B is deeper on tenant isolation and is publicly verifiable in a directory. Mature buyers commonly ask for both.

Guardian’s evaluator pool has experience across all common multi-tenant patterns: database-per-tenant, schema-per-tenant, shared-schema-with-row-level-security, container-per-tenant and namespace-per-tenant Kubernetes architectures, sidecar-pattern and shared-service architectures, serverless-with-tenant-context architectures. Module B is architecturally agnostic — what matters is that the chosen strategy is correctly and consistently enforced.

Source code review is sample-based at Level 2 (focused on tenant-context propagation, authorisation enforcement, key management) and comprehensive at Level 3 (covering the in-scope codebase). Level 1 does not require source code access. Code review is conducted via secure remote access in your environment wherever feasible; source code is not retained by Guardian.

No. Cloud provider controls are out of scope under Module B and are governed by the cloud provider’s own attestations (e.g., AWS / Azure / GCP SOC 2 reports). What is in scope is your application’s controls and your configuration of the cloud platform: identity, access control, network configuration of your tenant boundary, data segregation, key management, secrets handling, build and deployment hygiene.

Where the platform claims BYOK, Module B specifically evaluates: the actual integration with the customer’s KMS (not just the documentation); the key-revocation pathway (and what happens to encrypted data when revocation occurs); key-rotation discipline; isolation between BYOK keys of different customers; and behaviour under failure modes (KMS unavailable, key rotation in flight). At Level 3, this includes targeted testing of edge cases that buyer due diligence often probes.

Shared-schema with row-level security (RLS) is one of the harder architectures to enforce correctly, because every query must consistently apply the tenant filter and any escape (raw SQL, ORM bypass, reporting view) is a potential cross-tenant leakage path. We evaluate the discipline directly — code review for query patterns, runtime testing for filter consistency, edge-case testing for corner queries. We do not refuse to certify shared-schema architectures; we do raise the bar on enforcement evidence.

Typical timelines: Level 1 — 4–7 weeks; Level 2 — 8–12 weeks; Level 3 — 12–18 weeks. The largest variable is applicant responsiveness during findings closure. Engagements with prepared documentation, well-architected tenant boundaries and rapid remediation cycles complete faster.

Single-tenant deployments are technically a different product surface — there is no tenant-isolation question to evaluate. They fall more naturally under Module A. If you operate both a multi-tenant SaaS and a single-tenant on-premises / private-cloud edition of the same product, the multi-tenant edition is certified under Module B and the single-tenant edition under Module A — separate certificates with separate Scope Statements.

Yes — within the tenant-aware evaluation. Subscription-lifecycle security (Area 5) covers onboarding, suspension, downgrade, offboarding and data deletion. Billing integrity itself (the correctness of invoicing) is not an application security question and is outside the technical security scope; what we do evaluate is how subscription-state changes propagate through the platform’s authorisation model.

Module B is engineered to address the questions enterprise buyers actually ask in vendor due diligence — particularly around tenant isolation, identity federation and operator access. A publicly-verifiable certificate that maps to those questions reduces back-and-forth in security reviews. Whether it reduces overall procurement cycle time depends on the buyer’s process; in our experience, presenting a Module B certificate at the start of a security review materially shortens the review.

Material changes to tenant-isolation strategy (a re-architecture from shared-schema to schema-per-tenant, for example) require notification to Guardian and may trigger re-evaluation activities outside the routine surveillance cycle. The Certification Agreement requires this notification. Recertification re-evaluates the platform against the current scheme criteria and, where the architecture has changed, the new strategy is re-tested in full.

Yes. Module B engagements are typically conducted remotely under IAF MD 4:2025, particularly at Levels 1 and 2. Some Level 3 engagements may benefit from limited on-site presence (for example, observation of operator workflows in a controlled environment), but the default is remote. The decision is risk-based and is made at scoping.

Where AI / ML features are part of the certified product surface, the evaluation addresses: tenant-isolation of training data and inference data; prevention of cross-tenant model contamination; prompt-injection and data-leakage paths through model inference; access controls on model training and update pipelines. AI / ML evaluation under Module B is part of the broader tenant-aware evaluation; we do not currently issue a separate AI-specific certification, though scheme evolution in this area is on our roadmap.

Critical findings on the tenant boundary must be addressed for certification to be granted. Guardian issues the finding with technical detail and the relevant GSA-PR-01 / OWASP ASVS reference. Remediation is the applicant’s responsibility — Guardian does not provide consulting or fix-support. Guardian re-verifies corrective actions; one round of re-verification is included in the engagement, additional rounds are billed separately. If the platform cannot meet the criteria, the certification is not issued, and there is no record of the failed application in the public directory.