SaaS penetration testing for startups and established teams
SaaS penetration testing examines the multi-tenant web application, public APIs and, where there is one, the mobile app for weaknesses in tenant isolation, role boundaries, SSO, authentication, session handling and billing logic.
An enterprise customer’s security review, your SOC 2 or ISO 27001 audit, or an authentication or billing rewrite may prompt SaaS application security testing. We agree the scope of penetration testing for SaaS with you.
We test web applications, mobile apps and APIs. We do not audit or certify compliance with any regulation or standard.
What a SaaS test covers
Beyond the web app, a SaaS penetration test can include the public APIs your customers and integrations call, and a mobile app where there is one.
Systems we test
- Multi-tenant web application
- Public APIs, including system integration interfaces
- Mobile application, where your product has one
Risks we test for
- Tenant isolation: whether a user in one tenant can access another tenant’s records
- SSO and role boundaries: whether sign-in grants the intended tenant access and permissions
- Authentication and session handling: whether a session still grants access after logout
- Business logic and billing: whether a changed billing request can alter a charge or grant an unintended entitlement
- Input validation, encryption and data integrity
- Rate limiting and throttling on public APIs
- Error handling and logging
- Server configuration and database security in the web application
- Chained vulnerabilities
We test how your system uses its integrations — KYC, payment, bank and eID services.
Enterprise security reviews
An enterprise customer’s security questionnaire may ask for a penetration test report for your SaaS product.
The report is evidence you can give your auditors, supervisors and customers. What they accept is their decision.
Our reports include an executive summary, the scope of work, the test type and methods, the methodology, how risk is calculated, a summary of findings, detailed results for each finding, and a conclusion.
You can request our sample web application penetration test report through the contact form or by email.
SOC 2 and ISO 27001
The two cards below cover penetration testing, evidence for reviewers and the limits of our role.
SOC 2
SOC 2 does not require a penetration test. The Trust Services Criteria name it as one way to evaluate whether controls work (CC4.1), and auditors and enterprise customers often ask for one. Our report is evidence you can give them. Whether it is sufficient is the auditor’s decision.
ISO 27001
ISO/IEC 27001 does not make a penetration test mandatory. Organisations often use one as evidence for their technical vulnerability management, and auditors and customers often ask for it. We are not a certification body and do not certify against ISO/IEC 27001.
Read what an information security management system requires.
We provide testing evidence. We do not audit or certify compliance with any regulation or standard.
Security testing for startups
Startup web app security testing can provide a report for your first enterprise customer’s security review. The price follows what is in scope.
Plan your first test before important business events or launches.
Testing takes from a few days to a few weeks, depending on the project. The average testing period is 1–2 weeks.
When testing can start depends on our current schedule. If you need it sooner, contact us and we will do our best to accommodate you.
Testing alongside releases
- Agree the scope and testing type
Every test starts with planning: we agree the scope, the systems to test and the rules that avoid disruption.
We scope each test with you, either through our scoping questionnaire or in a scoping meeting where we ask the same questions.
The testing options are black-box, grey-box or white-box, agreed at scoping. - Schedule around your releases
Testing is conducted under controlled conditions with agreed rules of engagement. We schedule around your business needs. - Live systems or staging
We test on live systems and on staging environments. Roughly 70% of our tests run on live systems and 30% on staging. - Plan the next test
Plan repeat testing 2–4 times a year, and after major changes. For a SaaS release, examples include a new role or permission model and new public API endpoints.
Report and retest
Every report lists the vulnerabilities found, rates each by risk, and gives remediation steps. A penetration test report also sets out the exploitation methods demonstrated during testing, and a priority-based action plan.
In the report, each finding is rated by severity. Reports are 20–100+ pages long.
After you fix the findings, we re-test them.
A retest covers the findings only, not the full application. It is usually quoted in the same offer as the test. The retest window is about 4 weeks, or sooner if you have fixed the findings earlier and our schedule has an opening.
Experience and method
With over 7 years of experience in testing, we have built extensive expertise in web applications and websites, e-commerce platforms, mobile applications, APIs and SaaS solutions.
Our penetration tests can follow OWASP, ISSAF, PTES or OSSTMM at your request or on our recommendation. What we follow and how much of it we cover are agreed at scoping.
Testing uses Burp Suite, manual testing and our own tools.
Our pentesters hold certificates including PNPT, eCPPTv2, CAP, CompTIA PenTest+ and CompTIA Security+, and their published research includes five CVEs.
Questions
Does SOC 2 require a penetration test?
SOC 2 does not require a penetration test. The Trust Services Criteria name it as one way to evaluate whether controls work (CC4.1), and auditors and enterprise customers often ask for one. Our report is evidence you can give them. Whether it is sufficient is the auditor’s decision.
Does ISO 27001 require a penetration test?
ISO/IEC 27001 does not make a penetration test mandatory. Organisations often use one as evidence for their technical vulnerability management, and auditors and customers often ask for it. We are not a certification body and do not certify against ISO/IEC 27001.
What can we send when a customer’s security questionnaire asks for a penetration test report?
The report is evidence you can give your auditors, supervisors and customers. What they accept is their decision.
Every report lists the vulnerabilities found, rates each by risk, and gives remediation steps. A penetration test report also sets out the exploitation methods demonstrated during testing, and a priority-based action plan.
How do you test tenant isolation, SSO and role boundaries?
We test tenant isolation, SSO and role boundaries by checking access between tenants and the permissions granted through sign-in. For example, we test whether changing an API request lets an ordinary tenant user carry out an administrator-only action.
Will testing slow our release cadence?
We agree with you at scoping how a penetration test fits your releases.
Testing is conducted under controlled conditions with agreed rules of engagement. We schedule around your business needs.
When should we test again?
We recommend SaaS penetration testing 2–4 times a year, and after major changes.
What does a SaaS penetration test cost?
A SaaS penetration test is priced per project, using the number of systems or applications in scope, the testing type, the complexity of the environment and the timeline.
What is the difference between a penetration test and a vulnerability assessment?
A vulnerability assessment scans your systems with Burp Suite, and an expert verifies and prioritises what the scan finds. A penetration test goes further: testers try to exploit what they find and show you the impact.
Explore the penetration testing service and the vulnerability assessment service.
Are we too small for a penetration test?
Company size alone does not decide whether a penetration test is a fit: the price follows what is in scope.
Does cyber insurance require a penetration test?
Insurers set their own requirements. Where one asks for a penetration test, our report shows the findings and the recommended fixes. Whether it meets a given insurer’s requirement is the insurer’s decision.
Discuss your testing needs
You can request our sample web application penetration test report through the contact form or by email.
Or email us at info@c-yber.com
What to include
Describe what needs testing (web app, mobile app or API), the approximate scope, why and when you need the test, and whether you want the sample report.
What to leave out
Do not send passwords, API keys, tokens or other access details, source code, details of unfixed vulnerabilities, or your customers’ personal data.