Cloud / SaaS
Your product runs on someone else’s infrastructure and holds your customers’ data. We test what you control — the application, the tenant boundaries, the identities and the cloud configuration behind them — and show which paths reach that data.
Book a ConsultationIn the cloud, identity is the perimeter
No network boundary stops a valid credential, so the web of identities, roles and trust relationships is your real attack surface. Most cloud and SaaS breaches start there — a leaked key, an over-trusted pipeline role, an integration that kept its access after the person who granted it had left.
Security evidence is now part of the sale. Enterprise customers ask for SOC 2 or ISO 27001 and a recent penetration test; payment, financial and public-sector buyers bring PCI DSS, DORA and FedRAMP with them; and in the EU, NIS2 puts medium-sized and larger cloud providers under regulatory supervision directly.
A posture tool will give you thousands of alerts. What we add is which of them chain together to reach customer data, where the chain breaks, and whether the fix holds — traced back to the infrastructure-as-code that would otherwise put the problem back on the next deploy.
Three services, tuned to the platform
Artificial Intelligence Security (AI-BOM)
AI features in your product — assistants, retrieval over customer data, and agents and tool integrations that act inside customers’ accounts. We test whether one customer’s input can reach another customer’s data, and what an agent’s credentials can do when someone steers it.
Learn more →Post-Quantum Cryptography Readiness (CBOM)
A cryptographic inventory across the platform: TLS at the edge and between services, key management, customer-data encryption, and the certificates and signing keys in your pipeline. Customer data you keep for years is a harvest-now, decrypt-later target — and enterprise and public-sector buyers are starting to ask for your roadmap.
Learn more →Product Penetration Testing
Your application and APIs — authentication, authorization and tenant isolation — and the cloud platform underneath: identities and privilege paths, cross-account trust, containers and Kubernetes, and the pipeline that deploys it all. Reported as attack paths from realistic starting points — a leaked key, a compromised workload, a CI runner — to your customers’ data.
Learn more →Built for cloud platforms, not adapted from on-premises testing
Read-only first
A read-only review of configuration and identity delivers the most value for the least risk, with no production impact — and is usually the right place to start. Active testing follows only where it adds information.
The unit is the path
Findings are reported as paths from a starting position to your crown jewels, with the break point marked — including the question few teams ask: could one compromised identity delete production and the backups?
Traced to where it came from
Every finding is traced to its origin — console, template and line, shared module, or pipeline. A fix made in the console comes back on the next deploy; a fix in a shared module can close dozens of findings at once.
Revocation tested, not assumed
Disabling a user does not revoke the access third-party apps were granted. We revoke, retry with the old token, and measure how long access actually survives — behaviour under change, not just configuration.
What your customers, auditors and regulators expect
For SaaS companies, security evidence is mostly demanded by customers and auditors — and increasingly by regulators. Current as of October 2026.
| Framework | Instrument | What it means for you |
|---|---|---|
| Audit | SOC 2 — AICPA Trust Services Criteria | Penetration testing is not a required control, but the criteria’s guidance names it among the ways to evaluate whether controls work — and customers reading your report often ask for one. |
| Certification | ISO/IEC 27001:2022 | Annex A covers technical vulnerability management (8.8) and security testing in development and acceptance (8.29). Certificates to the 2013 edition expired on 31 October 2025. |
| Payments | PCI DSS v4.0.1 | Penetration testing at least once every 12 months and after significant change (11.4); segmentation testing every six months for service providers that rely on segmentation (11.4.6); and, for multi-tenant service providers, penetration testing of the separation between customers every six months (A1.1.4, required since 31 March 2025). |
| US public sector | FedRAMP — 2026 consolidated rules | Rebuilt in 2026: authorizations are now certifications, the 20x process is open for Class B and C (low and moderate impact), and proposed pilot rules for Class D (high) are out for comment until 19 November 2026. Penetration testing is folded into the vulnerability detection and response rules, mandatory from 7 December 2026 with a grace period to 7 March 2027; the consolidated rules as a whole are mandatory from January 2027, and new Rev5 applications close in June 2027. |
| US federal | Executive Order 14412 (June 2026) | Binding on federal agencies. High-value assets and high-impact systems outside national security systems move to post-quantum key establishment by the end of 2030 and signatures by the end of 2031. A proposed rule, due around December 2026 and not yet published, would hold covered federal contractors to NIST standards — post-quantum included — by the end of 2030. |
| EU financial sector | DORA — Reg (EU) 2022/2554 | Applies since 17 January 2025. Designated financial entities run threat-led penetration tests at least every three years, and 19 critical ICT third-party providers — AWS, Google Cloud and Microsoft among them — were designated in November 2025. Financial customers carry DORA’s contract and testing expectations down to their suppliers. |
| European Union | NIS2 — Directive (EU) 2022/2555 Implementing Reg (EU) 2024/2690 | Medium-sized and larger cloud computing, data centre and managed service providers are in scope — smaller ones only if a member state identifies them — with detailed technical requirements set by the 2024 implementing regulation, in force since 7 November 2024. EU law treats SaaS, PaaS and IaaS alike as cloud computing services. Member states were to apply NIS2 from 18 October 2024; in July 2026 the Commission decided to refer Ireland, Spain, France and the Netherlands to the EU Court of Justice for not notifying full transposition; the Dutch law took effect on 15 August 2026, and that case was closed in October 2026. |
| European Union | Cyber Resilience Act — Reg (EU) 2024/2847 | SaaS is generally outside the CRA — unless it is remote data processing that a connected product needs in order to work, in which case it is treated as part of that product. In force since 10 December 2024; manufacturers’ reporting of actively exploited vulnerabilities and severe incidents has applied since 11 September 2026, and full application follows on 11 December 2027. |
| European Union | AI Act — Reg (EU) 2024/1689, as amended by Reg (EU) 2026/1744 | General-purpose AI model obligations since 2 August 2025, and transparency obligations for AI systems since 2 August 2026 — with a grace period to 2 December 2026 for marking AI-generated content in systems already on the market. |
| Cloud provider rules | AWS, Microsoft, Google Cloud | AWS allows testing of listed services without approval, but red-team, command-and-control and phishing simulations need a request at least two weeks ahead, and DDoS simulation has its own policy. Microsoft and Google need no notification for your own resources. We check each provider’s current rules at kickoff. |
| Cloud standard | CSA Cloud Controls Matrix v4.1 | Released January 2026. STAR Level 1 is a self-assessment; Level 2 is third-party certification or attestation built on ISO 27001 or SOC 2. |
What you get
- Starting-position table — if an attacker obtains a leaked key, a phished user, a compromised workload, a CI runner or non-production access: what they reach, the shortest path, the break point, and whether you would see it
- Findings traced to origin — with account, region, resource and timestamp on every finding, so each one can be retested
- Tenant-isolation results — for multi-tenant products, whether one customer can reach another’s data, and how you would know
- Evidence for audits and customer reviews — a report your auditors and enterprise customers’ security teams can review
- Cryptographic and AI bills of materials — platform cryptography and the AI in your product, in CycloneDX format
- Retest of fixes — evidence that remediation landed and stays landed after the next deploy
Know which path reaches your customers’ data.
A cloud and SaaS engagement starts with your architecture, your tenancy model, and the evidence your customers ask for.
Get in Touch