OSCP+ CPTS CRTP PNPT

Manual, evidence-led testing

Penetration testing services that prove the risks exist

A penetration test should tell you what an attacker can actually do to your systems, with the evidence to back it up. We test by hand, report what we exploited and how, then retest your fixes.

Scope a Test What We Test

The Service

What a penetration test actually is

A penetration test is a controlled attack on your systems, carried out by people who break into systems for a living, under written authorization and agreed rules of engagement. The tester probes the target the way a real attacker would: finding weaknesses, exploiting them, chaining one foothold into the next, and recording exactly how far each path goes. The output is a report that says, with evidence, "here is what we got into, here is how, and here is what to fix first."

That is a different product from a scanner run. Plenty of firms sell automated scan output with a penetration test cover page, and the difference only becomes visible when a real attacker, or an experienced tester, looks closely. If you need a combined assessment, our page on VAPT services for organizations in Nigeria explains how the vulnerability assessment and the penetration test fit together in one engagement.

90%+

Assessments uncovering critical findings

100%

senior-led testing

Tier 1

Banking & capital markets experience

200+

Penetration tests delivered

Scope Types

What we test

Each scope type has its own dedicated page with the full approach. Most engagements will combine two or three.

Web applications

Portals, dashboards and customer-facing platforms, tested for authentication flaws, access control failures and the business logic flaws scanners will fail to see. Our web application penetration testing page covers the whole approach.

APIs

REST and GraphQL endpoints carry the money in most modern platforms, and object-level authorization flaws are where they fail. Read how we test APIs for broken authorization and abuse, including the endpoints your API documentation fails to list.

Mobile apps

Android and iOS apps store tokens, talk to APIs and run on devices you do not control. Our mobile app security testing follows the OWASP MASVS and covers local storage, transport security and the backend the app talks to.

Network & infrastructure

The perimeter an internet attacker sees, and the internal network a phished computer opens up. See what internal and external network penetration testing covers, from exposed services to Active Directory attack paths.

Cloud environments

One permissive IAM role or public storage bucket can undo everything else. Our cloud penetration testing across AWS, Azure and GCP examines identity, network paths and the misconfigurations attackers actually use.

Red team

A goal-driven exercise against the whole organization, defenders unaware, measuring detection and response rather than listing vulnerabilities. If you have tested before and want the harder question answered, consider a full red team assessment.

Compliance-driven testing

When the test exists to satisfy CBN expectations, NDPA 2023 obligations, PCI DSS or ISO 27001, the report has to hold up in front of the examiner. Our security advisory and compliance support scopes the assessment to the framework and shapes the evidence for submission.

Manual vs Automated

What scanners find, and what only a tester finds

We use scanners, and so does every serious testing firm. They are good at breadth: known CVEs, missing patches, weak TLS configurations, default credentials on forgotten services. Running one across a large estate in hours is work no human should do by hand, and we would be negligent not to.

But a scanner has no idea what your application is for. It cannot notice that the transfer endpoint accepts a negative amount, that a customer service role can approve its own requests, or that a low-severity information leak on one host hands over exactly the token needed to exploit a flaw on another. Business logic abuse and chained attack paths are found by a person who understands what the system is supposed to do and goes looking for the gap between that and what it actually does. That is the part of the engagement you are paying for, and it is the part that cheap testing leaves out.

What a scanner does well

Known CVEs and missing patches across a large estate
Weak TLS, expired certificates, insecure headers
Default credentials and exposed admin panels
Coverage: every host, every port, on a schedule

What only a tester finds

Business logic abuse: negative amounts, race conditions, workflow bypasses
Authorization flaws between roles, tenants and accounts
Chained attack paths, where three minor issues become one breach
Proof: confirmed exploitation, not a probability score

Evidence

What a finding with proof of concept looks like

Every finding in a ClarenSec report has the same anatomy. A title and severity you can triage from. The evidence: request and response captures, screenshots, the account we used. Numbered reproduction steps your own engineer can follow to see the issue live. An impact statement in plain language, tied to what the system actually does. And a fix that names the component and the change.

The proof matters because it removes the argument. When the report shows the exact request that moved money between two test accounts, nobody spends a week debating whether the finding is "really exploitable". The conversation moves straight to the fix.

Magnifying glass over source code, representing manual penetration testing findings verified with proof of exploit

After the Report

The retest is part of the engagement

A report that lists problems and walks away is half a service. Once your team has applied the fixes, we retest every finding at no additional cost within the agreed window, confirm which issues are closed, and flag any fix that did not hold. You then receive a retest report recording what was verified to be fixed, and what is not. That report is the document your board, your auditor or your regulator actually wants to see, because it shows the loop was closed rather than the report filed.

The Team

Who does the work

The people who scope your engagement are the people who test it: senior penetration testers holding certifications including OSCP+, OSEP, CBBH, CPTS, CRTP and PNPT, with experience across banking and finance, capital markets, fintech, healthcare, government and telecom. There is no bait-and-switch where a principal wins the contract and a junior runs the tools. It is a common enough practice in this market that we wrote about who actually tests your network after the contract is signed, and the questions that expose it before you commit.

Certifications Held by Members of Our Team

OSCP+ OSCP CPTS CRTP PNPT GWAPT CEH Practical CompTIA PenTest+ CompTIA Security+ CBBH CCRTA API Security Architect OSCP+ OSEP OSCP CPTS CRTP PNPT GWAPT CEH Practical CompTIA PenTest+ CompTIA Security+ CBBH CCRTA API Security Architect

FAQ

Penetration testing questions, answered

How long does a penetration test take?

Most engagements run between one and three weeks of active testing, depending on scope. A single web application typically takes about a week; a combined web, API and internal network scope takes longer. Reporting adds a few working days after testing closes, and we confirm the exact timeline in writing at scoping.

Will testing disrupt production?

The rules of engagement are agreed before any traffic is sent: which systems are in scope, which actions are excluded, which hours we test in, and who to call if anything looks wrong. Denial-of-service and destructive techniques are excluded by default. Where a system is especially sensitive, we test a staging copy or work in off-peak hours.

What do we need to provide before testing starts?

A confirmed scope (URLs, IP ranges, app builds), written authorization, a technical contact for the testing window, and test accounts at each privilege level for authenticated testing. We send a short checklist during scoping so nothing holds up the start date.

Do we need internal or external testing?

External testing models an attacker on the internet facing your perimeter. Internal testing models an attacker who is already inside, a malicious insider or a compromised vendor connection. They answer different questions, and organizations with anything of value behind the perimeter usually need both, often alternated across the year.

How is a penetration test different from a vulnerability scan?

A vulnerability scan is software listing potential weaknesses, many of which turn out to be unexploitable in context. A penetration test is a person exploiting those weaknesses, chaining them together and proving what an attacker could actually reach. We wrote a fuller comparison to help you decide whether you need a penetration test or a vulnerability scan this cycle.

Ready to scope a penetration test?

Tell us what you need tested and by when. We will come back with a scoped proposal, and a timeline.

Request a Scoping Call