A real intruder does not care which of your systems is in scope. They phish one employee, land on a laptop, find a credential in a script, move to a server nobody patched, and leave with the database — and the first anyone knows is a ransom note or a journalist. Whether you survive that sequence depends on two things: how many of those steps were possible, and whether anyone noticed while they were happening. Penetration testing measures the first. Red teaming measures the second. Buying one when you need the other is the most common procurement mistake we see.

Vendors use the terms loosely and both involve people attacking your systems, but the engagements differ in goal, scope, duration, cost, deliverable and the maturity they assume. A red team against an organisation with no detection capability produces a short report saying "we got in, nobody noticed", which the CISO already knew. A pentest against a hardened organisation says nothing about whether it would catch the attacker who finds the next flaw.

This article is for the person who has to choose. It defines each service, explains what drives cost, describes what you receive and how to read it, covers the compliance drivers, and offers a decision guide by maturity.

Penetration testing: what is broken?

A penetration test is a time-boxed, scoped attempt to find and exploit vulnerabilities in a defined set of systems, enumerating as many meaningful weaknesses as possible so they can be fixed. The tester is not trying to avoid detection; often they are allowed through the firewall so the time goes on depth rather than access. Coverage is the objective: a good tester has touched every endpoint and every role by the end.

Scope and rules of engagement

Scope is explicit and bounded: these hostnames, this IP range, this application and these roles, this cloud account. The rules of engagement set testing hours, whether denial-of-service is permitted, production or staging, how far an exploit may be taken before stopping to report, and who to call when something breaks. Anything outside scope is untouched even if clearly vulnerable; a tester who stumbles on it reports it without exploiting it.

Tests are described by the knowledge given to the tester: black-box starts with nothing but the target, grey-box with credentials and documentation, white-box with source code. Grey-box is the right default for almost everyone: it spends the budget on finding bugs rather than on reconnaissance a motivated attacker would complete over months anyway.

Vulnerability scanning is not a penetration test

A scanner matches versions and signatures against known issues and produces a list. It is fast, cheap, worth running continuously, and not a pentest. It cannot chain findings or understand business logic, and cannot tell you that a low-severity information leak plus a weak password-reset flow equals account takeover. A proposal offering "automated and manual testing" with a day of effort and a report full of plugin output is a scan with a signature on it. A real pentest is mostly manual work by someone who has done it many times, with tools used to save time, not to replace judgement.

Duration and cost drivers

Cost scales with the size and complexity of the scope. A single web application takes days; a platform with many microservices, a mobile app and an API takes weeks; an internal network assessment scales with hosts and trust boundaries. Other drivers: source code availability, number of environments, whether re-testing is included, and whether the report must meet a compliance format. The answer to "how much" is a scoping call, and a firm quoting a fixed price without one is guessing.

Deliverables

A pentest report lists findings, each with a severity, a reproduction, evidence, affected components, an impact statement and a remediation, plus the scope, methodology, what was and was not tested, and an executive summary. The useful metric is how many findings a scanner could not have found.

Red teaming: can you detect and respond?

A red team engagement is a goal-oriented simulation of a real adversary against the whole organisation, carried out covertly over weeks or months, to test whether your people, processes and technology detect and respond to an attack in progress. The objective is not a list of vulnerabilities but a set of goals — read the board's email, reach the production database, move funds from a treasury wallet — and a record of what the defenders saw at each step.

Scope and rules of engagement

Scope is broad by design: the organisation, with an exclusion list rather than an inclusion list. Rules of engagement cover what is off-limits (specific production systems, physical access, certain social-engineering targets), permitted techniques, deconfliction with real incidents, and who knows. The knowledge group is small, usually the CISO and one or two others, because the point is to test the blue team without warning them. A trusted contact, the white cell, can halt the exercise and confirm that a detected event is the red team.

Adversary emulation and threat intelligence

A mature red team does not run generic attacks. It emulates the adversaries most likely to target you, using threat intelligence about which groups attack your sector and how: initial access methods, tooling, lateral-movement habits, the data they go after. Tactics are mapped to a common framework so detection gaps can be described in a shared language. The result is not "we got in" but "we got in using a technique your sector's most active adversary uses, and nothing fired".

Assumed breach and purple teaming

An assumed-breach engagement skips initial access: the red team starts from a standard user laptop or a low-privilege account, on the premise that phishing eventually succeeds somewhere. This spends the budget on the post-compromise phases where most detection opportunities exist, and it is often the right first red team.

Purple teaming is collaborative. Red and blue work in the open, running specific techniques and checking in real time whether the detection fired, where the log went, and what the analyst saw. It is less realistic as a test but far more efficient at improving coverage, because every gap is discussed the same hour. We often recommend a purple cycle between a first and second red team.

Duration and cost drivers

Red teams are longer and more expensive than pentests, because realism requires time: reconnaissance, infrastructure that looks like the adversary's, slow movement to avoid detection, and waiting. Drivers include organisation size, whether initial access is in scope or assumed, whether physical or social engineering is included, emulation fidelity, and whether a regulatory framework prescribes the methodology.

Deliverables

The red team report is a narrative: the attack path end to end, with a timeline placing every red team action alongside what the blue team detected and did. It identifies where the attack could have been stopped and was not, the controls that worked, and the detection and response gaps. Vulnerabilities exploited along the way are evidence, not the product. The product is an assessment of the organisation's ability to operate under attack.

Reading a report

  • Can you reproduce the findings? Every exploitable issue should have steps and evidence. A finding without them is an opinion.
  • Does severity reflect your context? A critical on a staging host nobody uses, or a medium on a flaw exposing customer data, means the tester did not understand the system. Severity should be argued, not copied from a scanner.
  • Is the "not found" section meaningful? A good report says what was tested and found clean. Otherwise you cannot tell what coverage you paid for.
  • For red teams, is the timeline candid? It should include the actions that failed and the moments the blue team nearly caught them. A flawless victory is marketing.
  • Are recommendations specific? "Implement network segmentation" is from a textbook. "This flat VLAN let a workstation reach the database listener directly; restrict it to the application subnet" is from an engagement.

Compliance drivers

  • PCI DSS requires penetration testing of the cardholder data environment at least annually and after significant change, at network and application layers, with segmentation testing. It wants a pentest, not a red team.
  • ISO 27001 does not prescribe a test type; it requires that technical vulnerabilities are identified and managed, which in practice means regular penetration testing proportionate to risk.
  • SOC 2 similarly expects penetration testing as evidence that controls are evaluated; auditors look for the report, remediation tracking and the re-test.
  • DORA, the EU's Digital Operational Resilience Act, requires financial entities to test their ICT systems regularly, and larger or more critical entities to run threat-led penetration testing (TLPT) at least every three years under a framework based on the European TIBER model. Despite the name, TLPT is a red team: intelligence-led, covert, goal-oriented, against live production, with a defined control group. It is the clearest regulatory requirement for red teaming.

If the driver is an audit checkbox, a well-scoped pentest satisfies it. If it is a resilience regulation, read what it prescribes before scoping, and expect a red team.

Maturity decides the order

The choice depends less on budget than on where the organisation is.

  • No regular testing yet. Start with vulnerability scanning you run yourself, then a penetration test of the systems that matter most. A red team now would confirm what you already know and consume money that should go into fixing basics.
  • Regular pentests, findings being fixed, little visibility. Build logging and a detection capability — in house or outsourced — and run a purple team exercise to calibrate it. Pentests continue on a cadence tied to change.
  • A functioning security operations capability. Now a red team is worth the cost, because there is a blue team to test. Start with assumed breach; graduate to full-chain engagements once the post-compromise phases are covered.
  • Mature, regulated, or a high-value target. Alternate red and purple cycles, pentest every major release, and treat threat-led testing as a programme rather than an event.

A useful self-test: if the red team succeeded completely tonight, would anyone in your organisation know by tomorrow morning? If the answer is no, the engagement you need is the one that changes that answer, and it is probably not a red team yet.

Related but distinct

The two services share people, tools and techniques, and a good firm offers both. But they answer different questions. A pentest answers "what could an attacker who reached this system do?" A red team answers "would we notice, and what would we do?" You need both answers eventually, and the order matters: fix what is broken first, then test whether you can see the attacker who finds what you missed.

A programme of only pentests has clean reports and no idea how long an intruder could persist. One of only red teams has exciting narratives and a backlog of unfixed basics the red team walked through. Neither is a security programme on its own.

Web3-specific variants

A smart contract audit is the Web3 equivalent of a white-box pentest: a scoped, exhaustive review of the contracts for exploitable flaws, with proofs of concept; its coverage is listed in our audit checklist. It does not say whether your multisig signers would notice a malicious transaction, whether your deployment pipeline can be compromised, or whether an attacker could take over the front-end your users sign through.

An infrastructure red team for a protocol targets the organisation around the contracts: developer machines, key custody, the CI pipeline, DNS and hosting accounts, oracle and keeper operators, the channels where a forged message could trigger an upgrade. Its goals read like "obtain a quorum of signatures on an attacker-chosen transaction" or "publish a modified front-end". Some of the largest losses in this industry came through exactly these paths with the contracts intact. Protocols holding significant value need both an audit and an operational red team; most have only had the first.

What an engagement with us looks like

Every engagement starts with a scoping call: what you are worried about, what has been tested before, the compliance driver if any, and where you sit on the maturity ladder above. Then we recommend a service, and sometimes it is cheaper than the one you asked for.

For a penetration test: scope, access and rules of engagement agreed in writing; a team of at least two; immediate notification of anything critical; findings with reproductions, severities argued for your context, and specific remediation. Re-testing of fixes is included, because that is where regressions are caught.

For a red team: goals, exclusion list, knowledge group and deconfliction process agreed up front; intelligence on your likely adversaries and an emulation plan; the operation run over an agreed window with a white-cell contact available throughout; then a timeline, detection analysis and a debrief with the blue team in the room. For regulated engagements we follow the prescribed framework and produce the documentation the regulator expects.

For Web3 clients, the audit and the operational red team are separate workstreams with a shared threat model, so the paths through people and infrastructure are tested alongside those through the code.

Practical next steps

Place yourself on the maturity ladder. No recent pentest of your most important systems: book that. Pentests but no idea how you would detect an intruder: build detection and run a purple team. Both: scope an assumed-breach red team with goals that matter to your business. Whichever you choose, read the proposal for scope, rules of engagement and deliverable before you read the price.

Our pentesting, red teaming and audit services are on the services page; reach us on Telegram.