Cloud and SaaS companies face a security model where the highest-impact findings are architectural — tenant-isolation breaks, identity-model gaps, authorization-boundary violations, supply-chain compromises — rather than the application-layer findings that classic web application testing produces. Melina works with cloud and SaaS companies primarily through architecture review and threat-model-led engagement scoping, with point-in-time penetration testing as a follow-on rather than the primary engagement form. ## Where Melina engages on cloud and SaaS security ### Cloud architecture review [Cloud security architecture review](/services/architecture-cloud-review/) is the entry point for most cloud-native SaaS engagements. The scope covers: - Identity model — who can authenticate, with what credentials, against what control plane; service-to-service identity and authority delegation - Tenant isolation — how multi-tenant data and compute are separated, what shared infrastructure crosses tenant boundaries, where the isolation can break - Data flow and authorization boundaries — what data crosses what trust boundary, what authority is required for each transition - Encryption at rest and in transit — key management, key rotation, customer-managed key support - Network segmentation and east-west traffic — internal service-to-service paths and the assumptions about lateral-movement difficulty - Audit logging and incident-response readiness — what's logged, where it's stored, how it would support an investigation ### Kubernetes and container security For cloud-native SaaS running on Kubernetes (managed or self-hosted), we run [kubernetes security audit](/services/architecture-cloud-review/) scoped engagements: - Cluster configuration review against CIS benchmarks - Pod-security-standard and RBAC posture - Network-policy coverage - Service-mesh configuration (Istio, Linkerd, Cilium) - Secret management and external-secret integration - Supply-chain security in the build-and-deploy pipeline (image signing, SBOM tracking, admission control) ### Supply-chain security The software supply chain — third-party dependencies, build infrastructure, container base images, CI/CD pipelines — has become a primary attack surface for SaaS companies. We assess: - Dependency posture and [SBOM](/knowledge/glossary/sbom/) tracking - Build infrastructure security — CI runner isolation, signing-key handling, release artifact integrity - Vendor and third-party-service risk inventory ### ISO 27001 and SOC 2 readiness For SaaS companies entering enterprise sales motions, ISO 27001 and SOC 2 audit readiness is typically a sales prerequisite. We support pre-audit readiness assessment, control-design gap remediation, and engagement-cadence retainer arrangements through audit cycles. We do not issue the audit attestation itself — that is provided by the accredited auditor — but our work is structured to feed cleanly into the auditor's evidence requirements. ## Service mapping Cloud and SaaS engagements typically draw across: - [Architecture & Cloud Review](/services/architecture-cloud-review/) — primary service - [Mobile & App Security](/services/mobile-app-security/) — for client-side and mobile-app integration - [AI/ML Security](/services/ai-ml-security/) — where the SaaS product integrates LLM features - [GRC services](/services/grc/) — for ISO 27001 and SOC 2 readiness work ## Compliance and standards frame Cloud and SaaS engagements typically operate within: - ISO/IEC 27001 and SOC 2 (the most common enterprise-sales prerequisites) - ISO/IEC 27017 (cloud security) - ISO/IEC 27018 (cloud personal-information processing) - CSA STAR (cloud security alliance certification) - China-market: [MLPS](/knowledge/glossary/mlps/), [PIPL](/knowledge/glossary/pipl/), [DSL](/knowledge/glossary/dsl/), and [CII](/knowledge/glossary/cii/) where the SaaS serves mainland-China users - Regional data-residency requirements (GDPR, PIPL cross-border) ## Engagement model Cloud architecture review is typically [Scoped Assessment](/engagement-models/scoped-assessment/). Multi-product, multi-region, or compliance-program readiness is typically [Custom Engagement](/engagement-models/custom-engagement/). Continuous engagement through release cadence is typically [Retainer](/engagement-models/retainer/). > "The highest-leverage cloud findings are almost always architectural — tenant-isolation breaks, identity-model gaps, authorization-boundary violations. They're rarely caught by point-in-time penetration testing because the test surface lives at the application layer while the finding lives in the architecture. Engagement scope that starts at the architecture layer produces structurally different findings than scope that starts at the application layer." — Gleb Z., CTO, Melina Security ## What buyers ask us first Three questions surface in nearly every initial conversation with a cloud or SaaS company: **"How does architecture review differ from penetration testing in practice?"** Architecture review surfaces issues in the trust model and authorization boundary structure; penetration testing surfaces exploitable conditions in the deployed application code. Both have value, but in cloud-native SaaS the highest-impact findings (tenant-isolation breaks, identity-model gaps, supply-chain compromises) are architectural and rarely surface in code-focused testing alone. Most mature SaaS programs run architecture review first and use penetration testing for follow-on validation. **"What level of access do you need to do meaningful work?"** For cloud architecture review, read-only access to architecture documentation, IAM policies, network topology, and a sample of code review covering authentication/authorization paths is typically sufficient for a substantive engagement. Production-system access is required only for findings validation rather than for initial assessment. For Kubernetes posture review, read-only cluster access (RBAC-restricted) plus access to manifests, helm charts, and admission-control configuration. For penetration testing, the access model depends on whether the engagement is grey-box or black-box. **"Can the engagement coordinate with our ongoing SOC 2 / ISO 27001 audit cycle?"** Yes — most enterprise SaaS engagements we run are structured around the audit cadence rather than against it. Technical findings from our assessment feed directly into the auditor's evidence requirements; remediation work can satisfy both the auditor's expectations and the architectural improvements the engagement identifies. Coordinated scoping with the audit firm produces meaningfully better outcomes than parallel-track work. ## Frequently asked questions ### Do you provide penetration testing as a stand-alone offering, separate from architecture review? We do, but with a preference: when architectural posture is unknown, a stand-alone penetration test produces lower-leverage findings (we end up reporting application-layer issues that an architecture-review-first engagement would have identified as symptoms of a deeper architectural decision). For clients with mature architecture-review work already in place, stand-alone penetration testing slots in cleanly. ### Will you sign SOC 2 or ISO 27001 attestations? No — those attestations require accredited auditor signature. We provide pre-audit readiness assessment, control-design review, and technical-finding remediation, and we structure our work to integrate with the accredited auditor's evidence requirements. ### How do you handle multi-tenant testing — could one test impact other tenants? Multi-tenant testing is conducted in isolated test tenants where possible. Where testing must happen in shared infrastructure (some tenant-isolation tests can only be exercised against the real isolation mechanism), we coordinate test execution timing and post-test verification to avoid cross-tenant impact. See our [Rules of Engagement](/trust/rules-of-engagement/) for the operational frame. ### How does supply-chain risk fit into a cloud or SaaS engagement? The software supply chain has become a primary attack surface for SaaS — third-party dependencies, build infrastructure, container base images, CI/CD pipelines. We assess SBOM tracking, build infrastructure security, and vendor-risk inventory as part of the architecture review where the engagement scope supports it. The procurement-side evaluation of vendor responsiveness uses the same three-dimension framework we publish for IoT supply chain: [Procurement Responsiveness Profile](/research/iot-supply-chain-2026/). ### What does engagement scope look like for a multi-region SaaS deployment? Multi-region engagements typically run as [Custom Engagement](/engagement-models/custom-engagement/) because the regulatory overlay shifts per region (GDPR in EU, PIPL in mainland China, regional data-residency requirements in various jurisdictions). The technical architecture is usually shared across regions; the compliance-evidence framing differs. We typically scope multi-region work as one cohesive technical assessment with region-specific compliance overlays rather than as separate engagements per region. ### Related - [What is SBOM?](/knowledge/glossary/sbom/) - [Architecture & Cloud Review service](/services/architecture-cloud-review/) - [Solutions — ISO 27001 & SOC 2 readiness](/solutions/iso-27001-soc-2/) - Companion research: [IoT Supply-Chain Vulnerabilities — Procurement Responsiveness Profile](/research/iot-supply-chain-2026/) (applies to cloud/SaaS supply-chain evaluation)