SaaS Security Assessment
A scoped penetration test of the product you actually ship — web application, API, authorization, tenant isolation, and the cloud configuration underneath it.
Who this is for
This assessment suits a B2B SaaS product that has real customers and is now being asked harder questions about its security. Typically that means an enterprise prospect has made a penetration test a condition of signature, a renewal has surfaced a security questionnaire, or the product has changed enough — new tenants, new integrations, new permission model, a first AI feature — that nobody has examined the whole surface deliberately for some time.
It is a single, time-boxed engagement with a defined start and end. If what you need is continuous coverage as you ship, the Continuous Security Retainer is the better fit, and if the pressing question is specifically about an AI feature, the AI Application Security Review goes deeper on that surface.
How we test
Testing is manual and led by evidence. Automated tooling is used where it genuinely helps — mapping an attack surface, enumerating endpoints, checking for known vulnerable dependencies — but a scanner cannot reason about your authorization model, and the findings that matter most in SaaS products are almost always logic and access-control failures that require understanding what the application is for.
We test the layers together rather than in isolation, because that is how they fail together. An API endpoint missing an object-level check is a moderate problem on its own; combined with a cloud role that can read every tenant’s storage, it becomes a breach path. Findings are reported with the chain intact.
Every finding we report has been demonstrated. If we cannot reproduce it, it does not go in the report as a vulnerability — at most it appears as an observation, clearly labelled as such.
What we examine
The final scope is written down before testing begins. This is the surface we normally cover for a SaaS product, adjusted to your architecture.
- Authentication and session management
- Login, registration, password reset, multi-factor enrolment and bypass, session lifetime, token invalidation on logout and password change, and account recovery paths.
- Authorization and tenant isolation
- Object-level and function-level access control, horizontal and vertical privilege escalation, role and permission boundaries, and whether one tenant can read, modify, or infer another tenant’s data.
- API surface
- Documented and undocumented endpoints, mass assignment, input validation, error handling and information disclosure, rate limiting on sensitive operations, and inconsistencies between API and interface enforcement.
- Business logic
- Workflow sequencing, state manipulation, quota and limit enforcement, subscription and entitlement checks, and the abuse cases specific to what your product does.
- Data handling and exposure
- Injection classes, insecure direct object references, file upload and download handling, export and reporting functions, and sensitive data in responses, logs, or caches.
- Cloud configuration
- Identity and permission design, storage bucket and object exposure, network reachability, secret handling, and the blast radius of a compromised application component.
- Integrations and third-party surface
- Webhook authenticity, OAuth flows and redirect handling, single sign-on configuration, and trust assumptions between your product and the services it connects to.
What you receive
- A technical report listing every finding with reproduction steps, evidence, affected components, business impact, and specific remediation guidance.
- A severity rating for each finding, with the reasoning stated rather than a bare label.
- A summary suitable for sharing with non-technical stakeholders, prospects, or your board.
- A live debrief with your engineers, so findings are understood rather than just received.
- A retest of remediated findings, with the resulting status recorded against each original item.
What is out of scope
These are excluded by default. Some can be added only where a specialist process, legal review, and your explicit written approval are all in place.
- Social engineering, phishing, or any testing directed at your employees.
- Physical intrusion or access to premises.
- Denial-of-service and load or stress testing.
- Destructive techniques, data deletion, or ransomware simulation.
- Establishing persistence or maintaining access beyond what a finding requires to evidence.
- Testing any asset you do not own or cannot lawfully authorize us to test.
Common questions
Do you test against production or a staging environment?
Either, and the choice is made deliberately during scoping rather than by default. A staging environment that genuinely mirrors production is usually preferable, because it allows more thorough testing without customer impact.
Where staging differs materially from production — different identity provider, different cloud permissions, seeded rather than real data — we will say so, because a finding that only exists in staging, or only in production, matters to how you read the report.
What access do you need from us?
At minimum, test accounts covering each distinct role and at least two separate tenants, so isolation can actually be tested rather than assumed. API documentation, if it exists, and an architecture overview make the work considerably more efficient.
Source code access is not required. Where you are willing to provide it, we will use it to reason about root cause and to reduce guesswork, but findings are still evidenced by demonstrating the behaviour.
Will testing disrupt our service or affect our customers?
Disruption is not the objective and we take deliberate steps to avoid it. Denial-of-service and load testing are excluded by default, destructive actions are excluded, and rate-sensitive operations are approached carefully.
Any residual risk is identified during scoping, and the rules of engagement include stop conditions and a contact route so testing can be paused immediately if something unexpected happens.
How do you rate severity?
Each finding is rated on exploitability and realistic business impact in your specific environment, and the reasoning is written out. A theoretically serious issue that is unreachable in your deployment is rated accordingly, and a modest-looking flaw that leads to cross-tenant data access is escalated accordingly.
Our methodology page sets out the criteria in full, so your engineers can disagree with a rating on stated grounds rather than negotiating a number.
Can you produce a report we can share with prospects?
Yes. The deliverable includes a summary written for a reader who is not going to read the technical detail, which is normally what a prospect’s security reviewer or procurement team needs.
We do not issue certificates, seals, badges, or any artefact implying accreditation we do not hold. What we provide is a clear, honest account of what was tested, what was found, and what was subsequently fixed and verified.
What happens after we fix the findings?
The engagement includes a retest of remediated findings. We verify each fix and record the resulting status against the original finding, so the report reflects the position after remediation and not only the position on the day testing started.
Where a fix is partial or introduces a new issue, we say so plainly rather than closing the item.
Get a written scope for your product
Tell us what you are building, what environment it runs in, and what is driving the timeline. We will come back with a scope, an approach, and a price.