Engagements
Four shapes, and the question each one answers.
Most firms sell testing in good, better and best. We cannot, because the things that would have to get worse in the cheap tier — senior testers, evidence for every finding, a retest — are commitments we have already published. So these are not quality tiers. They differ by what the engagement is trying to prove.
Focused
What is actually wrong with this system?
One system, tested properly. The commonest shape of engagement and, for most teams, the right place to start.
Typically this shape
- A web application and the API behind it
- A mobile app, client and server side
- One external perimeter
- A single cloud account or environment
- A system that has changed enough to need re-proving
What moves the scope
- How many distinct kinds of user there are, and which pairs must not reach each other
- Whether the API is shared with a mobile app, a partner or a public client
- Whether tenants exist, and how strictly they are meant to be separated
- Whether we test authenticated, unauthenticated, or both
- Whether the environment holds enough data to make a finding provable
There is a floor. We do not take engagements below five days of testing, excluding reporting. Less than that and we would be handing you a scan with a cover page, which is not what we do and not worth your money.
Services that usually sit here
Estate
What can someone chain together across our environment?
Several systems, and the paths between them. The findings that matter here are rarely in one place — they are the route from a small weakness in one system to something serious in another.
Typically this shape
- An application, the infrastructure under it and the cloud account around it
- An internal network and the Active Directory domain that governs it
- An external face with an internal estate behind it
- An estate that has grown by acquisition or migration and nobody is sure what is exposed
What moves the scope
- How many applications, APIs and endpoints are in scope
- How many external hosts and internal subnets, and how many are live inside them
- How many cloud accounts hold production workloads
- Whether Active Directory is in scope, and how many domains
- Whether we work from an assumed breach or start at the perimeter
Services that usually sit here
Adversarial
Could someone reach the thing that matters — and would we notice?
Objective-driven rather than scope-driven. We agree what an attacker would be trying to reach, then find out whether they could get there and whether anyone would see it happening.
Typically this shape
- Red teaming against an agreed objective
- Threat-led testing under DORA, where the regulator sets the shape
- Purple teaming, run in the open alongside your defenders
- Social engineering, where people and process are in scope
What moves the scope
- What the objective actually is, stated plainly enough to be proved or disproved
- Whether detection and response are in scope, or only whether the objective is reachable
- Who on your side knows the test is happening
- Which techniques are excluded, and who can authorise the ones that are not
- Whether a regulatory framework governs the exercise
This is the wrong place to start if nobody has tested coverage yet. A red team measures whether you detect an attacker; it is not a sweep of your estate, and it will miss things a scoped test would have found in the first week. We will say so if we think you are here too early.
Services that usually sit here
Continuous
Is this still true since we shipped?
Testing on a cadence rather than once a year. For teams whose systems change faster than an annual engagement can keep up with.
Typically this shape
- Products shipping continuously, where last year's scope no longer describes the system
- Estates under active migration or growth
- Teams who want the same testers to retain context rather than re-explain the system each time
- Organisations with a standing requirement to re-test after significant change
What moves the scope
- How often the system changes in ways that affect its security model
- Which parts need re-proving on every change, and which only periodically
- Whether you need access to the same testers between engagements
- What triggers a re-test: a release, an architectural change, or the calendar
Services that usually sit here
Regardless of shape
What every engagement carries
- Senior testers, no junior hand-offsThe people who scope the engagement are the people who run it. No tier is staffed with trainees.
- In-house, never subcontractedYour engagement is delivered by PXLSec people. We do not pass work to a contractor pool or an offshore partner.
- Every finding evidencedSeverity, the evidence, the steps to reproduce it, the business impact and a specific fix. Written so an engineer can act on it and a non-specialist can understand what is at risk.
- A retest, and closure in writingWe retest what you remediate and confirm in writing what is closed. A fix we cannot verify is reported as unverified, not quietly marked done.
- Rules of engagement agreed firstScope, window, stop conditions and escalation, written down before anything is touched. Ours are published in full.
Not sure which?
Our scoping tool asks six questions and suggests a starting point — including the cases where the honest answer is that you do not need a penetration test at all. If you would rather just describe the system, tell us what you have and a senior tester will come back with questions rather than a brochure.
FAQ
Questions about shaping an engagement
Which one do we need?
Usually Focused, if you are asking the question for the first time about a particular system. If you are not sure, our scoping tool walks through six questions and gives you a starting point, including the cases where the honest answer is that a penetration test is not what you need.
Is a cheaper engagement a less thorough one?
No, and that is deliberate. These are not quality tiers. Senior testers, evidence for every finding, a retest and written closure apply to all four, because we have published those as commitments and they are not things we are willing to vary. What changes between them is the question being answered and the ground being covered, not how carefully the work is done.
Is there a minimum?
Yes. We do not take engagements below five days of testing, excluding reporting. It is not a commercial preference — below roughly that, a manual test cannot cover enough ground to tell you anything you could not get from a scanner, and we would rather say so than take the work. If your scope is genuinely smaller than that, a vulnerability assessment may be the honest answer, and we will say so.
Why are there no prices here?
Because an indicative figure that ignores your scope would be misleading, and we would rather say nothing than publish a number we would have to walk back. What genuinely moves the cost is listed under each shape above. Send us those answers and you will get a real figure rather than a range.
Can an engagement move between these?
Often. A Focused engagement that keeps reaching systems nobody mentioned is telling you the scope was wrong, and we will say so rather than quietly test past the boundary or ignore it. Scope changes are agreed in writing first — that is in our rules of engagement.
Do you work to our framework rather than yours?
Yes. Where a regulation or standard sets the shape of the test — DORA, NIS2, PCI DSS, ISO 27001, SOC 2 — we scope against the clause that applies and write the report so it can be handed to your assessor as it is.
Tell us what you need tested.
Tell us what you want to protect. A senior tester will help you agree the scope and next steps. We usually reply within one business day.
Confidential from the first conversation
We can sign your NDA before you share sensitive details. Your enquiry is covered by our privacy policy.
How we protect your information · Privacy policy