Services / Testing
Penetration Testing
A manual test with a real attack narrative, and a report a customer will accept.
The problem
An enterprise customer demands an annual penetration test report before signing. The last one you commissioned was a scanner output with a cover page, and their security team rejected it. You need a test that finds real issues and a report that survives someone else's review.
The method.
Scope against the threat that matters
Define targets, environments, roles and rules of engagement. For a SaaS product the critical question is almost always tenant isolation and authorisation, so the test is scoped with multiple accounts across multiple tenants and multiple privilege levels, not a single unauthenticated crawl of the login page.
Map the application before attacking it
Enumerate the real attack surface: every API endpoint including the undocumented ones, authentication and session mechanics, token issuance and lifetime, role and permission model, file upload paths, webhooks, integrations and admin functionality. Most serious findings are in code paths that no automated crawler ever reaches.
Test authorisation manually, object by object
Broken access control is the top category in the OWASP Top 10 and remains the most common critical finding in SaaS. It is found by hand: replay a request from tenant A with an identifier belonging to tenant B; call an admin endpoint with a viewer token; manipulate the tenant claim in the JWT. Scanners cannot do this because they cannot know what should be forbidden.
Chain findings into a demonstrable impact
A reflected XSS is a medium. A reflected XSS that steals a session, escalates to admin and exports the customer table is a critical, and it is the one that gets fixed. We report the chain and the business impact, with the exact requests to reproduce it.
Report so an engineer can fix it and a customer can accept it
Each finding: reproduction steps, request and response, impact, CVSS, a specific remediation, and the OWASP and framework references. Plus an executive summary written for the customer's security reviewer, because the report itself is the artifact that unblocks the deal.
Retest and issue the clean letter
Retesting after remediation, and an attestation letter you can send to customers, stating scope, dates, methodology and confirmation that findings were remediated. The letter, not the raw report, is what most enterprise customers want to see.
How often should a penetration test be performed?
Annually at minimum, and after any significant change to the application or infrastructure. ISO 27001 and SOC 2 both expect regular technical testing, most enterprise customers require an annual test as a contractual condition, and the Israeli Privacy Protection Regulations require periodic penetration testing for medium- and high-tier databases.
What is the difference between a penetration test and a vulnerability scan?
A vulnerability scan is automated and identifies known vulnerabilities by signature and version. A penetration test is performed by a human who understands the application's logic and chains findings into demonstrated impact. Scanners cannot find broken access control, tenant isolation failures or business-logic flaws, because they do not know what the application is supposed to forbid, and those are precisely the findings that matter most in SaaS.
What do enterprise customers want to see from a penetration test?
Usually an attestation letter rather than the full technical report: scope, dates, testing methodology, the fact that findings were remediated, and confirmation that the test was performed by an independent party. Sharing the raw report is uncommon and often unwise; the letter is the artifact that actually unblocks a procurement review.