A real attempt, against an agreed scope, with a fixed end date
Penetration Testing Services
A vulnerability scanner tells you what a tool noticed. A penetration test tells you what a motivated person, with time and intent, could actually do to a system you named in advance. This is a bounded engagement with a start date, an end date and an agreed scope. It runs against exactly what you point it at, whether that is a launch, a contractual obligation or a workflow nobody has tried to break on purpose.
How a penetration test actually gets scoped and run
Reconnaissance, exploitation attempts and the report a launch decision depends on.
90 secSample frame · video pending01Before agreeing on visibility
Black box or grey box changes what gets found.
How much a tester knows going in shapes the test more than most buyers expect. Four questions settle which approach fits your actual goal.
Are you testing the system or your detection capability?
Black box testing, with no internal knowledge, mimics an outside attacker and also tests whether your team notices the attempt.
Is time or depth the more important constraint?
Grey box testing, with some internal access, finds more in the same window because time is not spent rediscovering what documentation already states.
Has the system been tested before?
A first-time test often benefits from black box realism. A recurring test on a known system usually gets more value from grey box depth.
Does the report need to satisfy a specific external party?
Some contracts or insurers specify the testing approach explicitly, which settles the question before the internal debate needs to happen.
| Black box | Grey box | |
|---|---|---|
| Tester's starting knowledge | None, external only | Partial, some internal access |
| Realism | Closer to an outside attacker | Closer to an insider or leaked-access scenario |
| Depth per time spent | Lower | Higher |
| Best fit | First test, detection also in question | Recurring test, known system |
02Agreed before testing starts
The ledger that keeps an offensive test honest
Penetration tests drift when scope is assumed rather than signed off in writing before an exploit gets attempted. This keeps the line explicit: what you name as in scope, what gets attacked, what comes back as a finding, and every decision that remains yours to make afterward.
- Your side
You bring
- The system and its scope for the launch
- The fixed launch date the test needs to fit around
- Any known weak points the team already suspects
- Our side
We build
- Reconnaissance and exploitation attempts against the agreed scope
- Testing for business-logic flaws specific to the launch feature
- A severity-ranked list of every finding, exploited or attempted
- Your side
You receive
- A written report with reproduction steps for every finding
- A go or no-go read on launch-blocking issues specifically
- A retest window before or shortly after go-live
Never leaves you
- The launch date and the final go or no-go call
- The system and its codebase throughout the test
- The decision on which finding gets fixed before shipping
Where the line sitsA launch test names what would break under attack; the decision to launch anyway, fully informed, stays entirely yours.
03From scope to confirmed fix
Four stages, each closing on evidence
A test that leaves a buyer unsure what to fix first usually skipped one of these stages. This system closes each one with something the engineering team can act on directly.
Agree scope and rules of engagement
Systems in scope, exclusions, testing windows and an emergency contact all get written down and signed before reconnaissance begins.
Signed off before any exploit is attemptedConduct reconnaissance
Publicly available information and the visible attack surface get mapped first, exactly as an actual attacker would begin.
Mapping the target the way an attacker wouldAttempt exploitation
Testers actively attempt to exploit discovered weaknesses, including chaining smaller issues into a more serious outcome where possible.
Real attempts, not a theoretical listReport and retest
Findings ship with severity and reproduction detail, and a retest confirms each fixed issue is actually closed before the engagement ends.
Confirmation once a fix ships
04What actually moves the number
Four drivers, priced from the agreed scope
Penetration testing is priced against the defined scope, because these four factors change tester-days by multiples of a base estimate.
Size and complexity of the scope
A single application tests faster than a scope spanning web, mobile and internal network systems together.
Black box or grey box approach
Black box reconnaissance from zero knowledge takes longer than a grey box test with documentation and limited access provided upfront.
Depth of business-logic testing required
Testing complex workflows for chained logic flaws takes meaningfully longer than a standard technical vulnerability sweep.
Retest scope after remediation
Confirming a handful of fixes costs less than a full retest across every finding from a larger remediation pass.
05Evidence and proof
Findings a real attacker would actually have used.
Penetration testing proof is a reproducible exploit chain and a retest that confirms the fix held. Every record here waits for written client approval before production.
Explore case studiesA launch-blocking flaw found four days before go-live.
Nexa Foundry had a fixed launch date for a new equipment portal with no prior offensive test. A pre-launch test found a privilege escalation path that shipped fixed on schedule.
- Launch-blocking findings
- 1
- Days to fix before go-live
- 4
A logistics workflow chain broken before an attacker found it.
Tern's carrier portal combined several legitimate actions into an unintended discount-abuse path no scanner would ever catch. Manual business-logic testing found and reproduced the chain in full.
- Chained logic flaws found
- 1
- Steps in the exploited chain
- 3
The report read like something our own engineers wrote. Every step to reproduce it was exactly right.
Sample · pending client approval
06Read this first
When a single test is the wrong answer
Commissioning one test as a substitute for an ongoing security practice leaves every release after it untested. The exits are marked plainly below.
- Application Security
You need coverage on every release, not one date
A single test only covers the system as it existed on the test date. Continuous scanning fits an active release schedule better.
- Compliance Consulting
The actual requirement is governance evidence
If a customer or regulator needs policy documentation rather than an exploitation attempt, that is advisory work, not a technical test.
- Security Audits
You need a broader review of policy and configuration
A comprehensive health check spanning process and configuration, not adversarial exploitation, is a different engagement entirely.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Single scoped test | One launch or one deadline | The scope and testing window | Testing, report and retest |
| Recurring annual test | A contract requires it yearly | Scheduling around your calendar | Consistent method across cycles |
| Ongoing programme | Multiple systems, frequent releases | Which system gets tested next | Standing testing capacity |
07Straight answers
Asked before the testing window opens.
01How is this different from an automated vulnerability scan?
A scan reports known patterns automatically. A penetration test involves a person actively attempting exploitation, including logic flaws no scanner can evaluate.
02Will testing affect our production environment?
Rules of engagement are agreed in advance, including which environment gets tested and what activity is off-limits. Production testing is possible but only with explicit safeguards agreed first.
03Do you test web, mobile and network systems?
Yes, and scope is defined explicitly during scoping rather than assumed. A test can cover one system or several, priced against whatever is agreed.
04What happens if you find a critical issue mid-test?
It gets reported immediately through the agreed emergency contact rather than held for the final report. A critical, actively exploitable finding does not wait for a deliverable.
05How long does a penetration test take?
A single application with a defined scope typically runs one to three weeks. A larger scope or deeper business-logic testing extends that.
06Do you retest after we fix the findings?
Yes, a retest is standard practice and confirms every fixed issue is actually closed. A report without a retest only proves what was found, not what got resolved.
07Is this required for compliance, or is that a separate service?
Some frameworks require penetration test evidence as part of certification. The governance and documentation side of that requirement runs as a separate compliance engagement.
08What does a penetration test cost?
Pricing follows scope size, black box versus grey box approach, and retest depth, set during scoping. A recurring annual test is usually priced against a known baseline from the prior cycle.