Anyone can promise a penetration test. This page shows how a ClarenSec engagement actually runs, and exactly what lands on your desk at the end, so you can judge the work before you commission it.
Every ClarenSec engagement follows the Penetration Testing Execution Standard (PTES), cross-referenced against NIST SP 800-115. For web applications we test to the OWASP Web Security Testing Guide (WSTG) and verify controls against the Application Security Verification Standard (ASVS); where a mobile app is in scope, the OWASP MASVS applies.
The same discipline holds whether the scope is a single web application, an internal network, or a full vulnerability assessment and penetration testing engagement. The phases on the right are the steps we take to earn the findings in your report, and they are the steps you can check against the report to verify the work was done.
If you want the wider picture of the assessment types we run and how they differ, our penetration testing services hub walks through each one. This page answers a single question: how the work is done, and how you can tell it was.
Here, we agree on scope, rules of engagement, test windows, emergency contacts, and get written authorization. We agree on exactly what will be tested, when, and who to call if anything looks off.
We map out what an attacker can learn about you from the outside: exposed services, forgotten subdomains, leaked credentials, staff details. We help you see your organization as an attacker sees it.
We work out which services matter to your business and what attackers would go after, so testing effort is focused on where your risk lies.
Tools and manual review expose candidate weaknesses. At this stage every item is a lead to be tested, verified or discarded.
We attempt each lead under the agreed rules of engagement. What we can demonstrate goes in the report with evidence of exploitation.
Once in, how far does it go? We measure what data is reachable and what lateral movement is possible, so severity reflects the real consequence of a vulnerability rather than a generic score.
Everything is written up with evidence, severity, and remediation guidance, then your team is walked through everything on a call. The report is the product; the phases above exist to earn it.
Two audiences read a penetration test report and they need different things. The board or executive team needs to know what the risk is, and your engineers need enough details to fix it without calling us. The report serves both.
A page or two in plain language for directors and management: what we tested, what we found, what it could cost the business in money, operations, or regulatory fines, and what to fix first.
Each finding follows this structure: affected asset, captured evidence, reproduction steps, business impact, and remediation. Your engineers can reproduce every issue from the report alone.
CVSS v3.1 is the benchmark.
An ordered list of fixes to prioritize.
A penetration test that ends at the report leaves you with a list of open problems and no guarantee they have been fixed. So the retest after a penetration test is part of every ClarenSec engagement, and it is written into the proposal rather than offered verbally.
After your team remediates, we retest each fixed finding and issue a retest report recording what was actually fixed and what remains open, as at the retest date.
The penetration testers named in the proposal are the testers who run the engagement and they author the report. There is no bait-and-switch where a senior face wins the contract and a junior tester runs the tooling. Our engagements are delivered by senior penetration testers holding certifications including OSCP+, OSEP, CPTS, CBBH and CRTP.
That experience spans banking and finance, capital markets, fintech, healthcare, government, and telecom, so the person testing your platform has usually broken something like it before. When the report names its authors, you know exactly whose judgement you are paying for, and who to put on the call when your engineers have questions.
Yes. Every engagement follows the Penetration Testing Execution Standard (PTES), mapped to the OWASP Web Security Testing Guide and ASVS for web applications, the OWASP MASVS for mobile, and NIST SP 800-115.
It means every finding in the report was demonstrated in practice by a tester. Each finding carries the captured evidence: requests and responses, screenshots, or command output showing the issue being exploited against in-scope systems under the agreed rules of engagement.
Yes. One round of retesting of fixed findings is part of every engagement and is written into the proposal. After your team remediates, we verify each fix and issue a retest report recording the status of every finding as at the retest date.
Yes. A redacted sample report is available on request, so you can judge the depth of evidence and the quality of the writing before you commission anything. Ask for it through our contact page and we will send it over.
Request a callback.