A customer is asking for proof.
A security review or questionnaire has arrived and the contract is waiting on it. They want evidence of independent testing, which a policy document does not provide.
Penetration testing
Assessment and testing
Find out what an attacker could actually do.
Most organisations know roughly where their risks are. Harder to establish is which of them are exploitable, which systems an attacker reaches first, and what to fix before anything else.
Risk-driven testing across applications, infrastructure and cloud, run by engineers with automation doing the breadth.
- Applications
- Infrastructure
- Cloud
Difference
How fast findings reach you, and what it costs to confirm the fix
Breadth to the machine, the chain to an engineer. The same check against every endpoint, role and parameter is wide rather than hard, so coverage does not shrink when the scope grows. What does not automate is holding an objective across many steps: that one weak permission plus that predictable identifier add up to a way in. The chain is reasoned by a person; the evidence under it is gathered by machine.
The report is not a second project. Critical findings reach you the day they are found, and the full report follows without a second mobilisation, because the record of what was tested is written as the work runs rather than reconstructed afterwards.
The retest is in the engagement, which changes what the answer costs. Bought separately it is usually capped: a window of a month or three after delivery, priced per finding, billed in minimum blocks. Here each finding is checked again about a week after your fixes, and you get a summary of what is resolved and what remains.
ApproachWhat it gives youWhat it misses
Vulnerability scanningWhat it gives youBroad signature coverage, fast and repeatableWhat it missesBroken object-level authorisation, business logic, chains of low-severity issues that combine into access
A low-cost one-off testWhat it gives youFindings, at a priceWhat it missesReproduction a developer can follow, a summary a board can read, a retest that is not a separate purchase
Compliance-driven testingWhat it gives youEvidence for the auditWhat it missesWhatever the framework does not ask about
Goal-based red teamWhat it gives youOne objective, by whichever route works, with the path documentedWhat it missesBreadth: it reports the route taken, not everything present
Control
Your rules hold for the whole test
Your rules are written down before testing starts.
Permission to test, ownership of every asset in scope, exclusions, testing windows, communication rules and emergency contacts, agreed in writing, along with the hours exploitation is allowed, the systems that must not be touched and the actions needing your sign-off. Each becomes a rule the test cannot break, and automated work runs inside a hard scope limit.
A person checks every stage, and new methods are proven first.
Results are reviewed by an engineer before anything moves on or into the report. New testing workflows run on training ranges before they touch a client system.
Where your test data goes.
Processing stays within the EU, identifying fields are stripped before anything reaches a model (including anything an engineer passes to one by hand) and nothing is used to train or improve a model. Full detail is in the data processing agreement, available on request.
The record of checks
Every check is logged as the work runs: what was tested, how, and what came back; a check that fails is rerun. That record is why the report does not need a second mobilisation to write, and why coverage can be shown alongside findings: a report says what was found, the record says where we looked.
Who does the testing
The people, and what they work to
Certifications held between them
OSCP · OSWE · eCPPT · eWPTX · CISA · CISM · CEH · AWS Security Specialist
Methodologies
OWASP · NIST CSF · CIS Controls · PCI DSS · HIPAA Security Rule · CSA guidance