Offensive security
Within a fixed number of testing days and under written authorisation, we try to turn small weaknesses into access to your data, such as a reused password on a VPN gateway and a service account with rights across the whole domain. Each finding comes with the steps that reproduce it, a CVSS 4.0 score adjusted for your business and the change that fixes it.
Each line has its own scope, deliverables and coverage, and one engagement can cover several, such as a web application and the cloud account it runs in.
Authenticated, role-aware testing of your application and its API surface, with an account for every role. We chain small findings into the access they lead to, such as a sequential invoice ID and a missing tenant check that together let one customer read another's invoices.
Duration: 5 to 10 working days
iOS and Android testing of the binary, on-device storage and transport, and of the backend API the app calls, replaying the app's own tokens to check whether one user can read another's data. On the device we check what the keychain or keystore stores, whether certificate pinning survives a bypass attempt and what deep links can trigger.
Duration: 6 to 10 working days
An IAM-first review of AWS, Azure or GCP. We map what an attacker reaches after compromising one workload or one developer laptop, then rank those paths by the data at the end of each and write the Terraform or policy change that cuts it.
Duration: 4 to 8 working days
Internal and external network testing, including Active Directory. Where scope allows we go from an unauthenticated foothold to domain-wide impact and document the whole chain: the exposed service or sprayed credential that got us in, each privilege escalation on the way, and the accounts and hosts it reached.
Duration: 5 to 12 working days
Adversarial testing of features built on large language models: chat assistants, retrieval-augmented search, agents with tool access, and generated output that reaches users or other systems. We test whether the model can be steered into leaking data, taking actions it should not, or passing untrusted output into the rest of your stack.
Duration: 4 to 10 working days
Kinds of test differ in where the attacker starts and how much they know. Each is explained, with when to choose it, on the scoping call page.
Scoping call to retest, with a written update at the end of every testing day and an immediate call if we find something critical.
45 minutes
We walk your architecture, agree what matters most and identify what must stay off-limits. There is no discovery invoice and no open-ended estimate.
Fixed quoteProposed datesWritten scope by email
1 to 2 days
Signed authorisation, escalation contacts, testing windows and traffic identifiers. If a critical issue appears mid-test we page you immediately rather than saving it for the report.
Signed RoEEscalation pathTest account provisioning
The testing days in your quote
Testing runs inside the agreed windows and carries the agreed traffic identifiers. At the end of each testing day you get a short written note of what was covered and anything found.
Daily written updatesImmediate critical escalation
2 to 3 days
An executive summary for the board, then one entry per finding with its evidence, how to reproduce it, its severity and the fix.
Full reportExecutive summaryPrioritised fix backlog
Included
A working session with your engineers to walk the findings, plus a shared channel for questions while the fixes are being built. Most disputes about severity get settled here, in front of the evidence.
Walkthrough sessionShared support channel
Within 30 days of report delivery
We retest every finding you have fixed against its original reproduction steps and reissue the report and attestation letter with each finding's current status. The retest is included in the original price.
Updated reportAttestation letter
When someone will ask for a current report, and when your attack surface has moved since the last one.
Enterprise security reviews often ask for a recent independent test and evidence that findings were fixed. A report plus a retest attestation letter answers both questions at once.
Technical due diligence moves faster when you can hand over a current report and show what has already been fixed.
Test the release candidate while fixes are still cheap: before real customer data arrives and before the launch date makes every finding urgent.
Code, cloud configuration, staff and suppliers all change within a year. For cardholder data environments, PCI DSS requirement 11.4 makes a yearly test the minimum.
A new authentication flow, a cloud migration, a partner API, a re-architecture or an acquisition changes the attack surface enough to justify a targeted test.
Once recovery is complete, a test confirms the way in is closed and checks the neighbouring systems the attacker could have used instead.
Most web application tests take 5 to 10 working days of testing, network tests 5 to 12 and cloud reviews 4 to 8, followed by two to three days of reporting. The number of days is fixed on the scoping call, before anything starts, from what drives the effort: the roles, endpoints and integrations in scope, the environments and the depth you choose. It is also the main driver of the quote.
How much we know at the start. Black-box testers get only what the public can see; grey-box testers get accounts for each role and an architecture briefing; white-box testers also get source code. More knowledge buys more depth per testing day, which is why grey-box is our default for applications.
A scanner matches known signatures and misconfigurations, so it cannot tell whether a coupon can be applied twice or a read-only member can change billing details. A penetration test can, because people log in as each role, chain weaknesses together and show what they lead to.
No. The report lists what was tested, what was not and why, for example an endpoint that needed a role you could not provision, so you can see exactly what a clean result covers.
Yes, for coverage: enumerating endpoints, checking known vulnerabilities and fuzzing inputs. Every finding in the report is confirmed by hand, and the most serious ones, such as broken access control, business-logic abuse and chained attacks, come from people rather than scanners.
Test accounts for every role, a contact who can answer questions during testing, an agreed testing window and, for grey-box tests, a short architecture briefing. Seed the test accounts with test data rather than real customer records wherever you can.
That is your decision. Our traffic carries the agreed identifiers, such as fixed source IP addresses or a custom request header, so your team can filter it out of alerting or deliberately leave it in to see what your detection catches.
Only where you own the account and the provider's policy allows it. Anything else, such as a payment provider's hosted checkout page, is written into the rules of engagement as out of scope before testing starts.
Yes, if we know on the scoping call. PCI DSS requirement 11.4 asks for internal and external penetration testing at least once every 12 months and after significant change, with exploitable findings corrected and retested; we scope and report to that. For SOC 2 and ISO/IEC 27001 programmes, or a customer's security schedule, we scope to the systems your auditor or customer will ask about.
Bring a rough diagram and the reason for the test. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.