An independent adversary your team can’t mark for itself.

A red team assessment begins with a single decision: what are we trying to reach, and what counts as proof we reached it? The objective is a concrete business outcome — access to a specific data store, control of a payment system, a foothold in production — not a vulnerability count. Everything else follows from it. We agree the systems and identities in and out of bounds, the techniques authorized, which detection teams are and aren’t in the know, and the rules that keep a controlled test from becoming an incident. A red team assessment scoped to a real objective tells you something a vulnerability scan never can: whether the path exists, and whether anyone would notice it being walked.

Scope is also where a red team assessment differs from a penetration test. A penetration test is breadth-first — find and prove the vulnerabilities across an agreed surface. A red team is depth-first and objective-led: it may ignore ten findings to chain the three that actually reach the goal, because the question is about your detection and response, not your bug count. Most teams arrive here after a pen test has already cleared the obvious ground. The maturity ladder is deliberate: assessment and penetration testing first, red teaming once there is detection and response worth challenging.

Most engagements start as an objective-based adversary simulation — a blind test of whether the path exists and whether your team sees it. Where the goal is improvement rather than a verdict, a purple team exercise runs the same techniques alongside your defenders, so detections get built and tuned as we go rather than written up after the fact. The two are not rivals; many programmes run a simulation first to find the gaps, then a purple team exercise to close them.

For regulated entities, the engagement becomes threat-led penetration testing — intelligence-driven scenarios aligned to TIBER-EU, CBEST, or DORA’s TLPT regime, executed under control and reported in the form your supervisor expects. Threat-led penetration testing shares the red team method but adds a threat-intelligence stage up front and an evidence trail built for regulatory submission. Where that requirement comes from DORA, our DORA compliance work and the testing run as one programme. We will tell you honestly which variant fits during scoping — there is no value in a blind simulation against a team that has nothing to detect with yet.

Within the agreed scope, an engagement draws on the techniques real-world attackers would use — chained toward the objective, not catalogued for their own sake:

Before anything starts, we agree the rules in writing. They are not boilerplate — they are what keeps the engagement safe and useful:

Written scope. The objective, the systems and identities in and out of bounds, and the techniques approved — all signed before execution.

Safety limits. Explicit constraints to protect production, data, and people, so a test never becomes an incident.

Approved techniques. The methods authorized for this engagement, and the ones deliberately excluded.

Notification and escalation. A named contact and an escalation path, so anything sensitive reaches the right person immediately.

Stop conditions. The triggers that pause or end the engagement, and a stop button your side can press at any time.

Timing. Business-hours or out-of-hours execution agreed up front, depending on what makes the test realistic without creating undue risk.

We keep red teaming deliberately unglamorous. There is no hacker cosplay, no uncontrolled disruption, and no social engineering that wasn’t explicitly authorized in the rules of engagement. The point is to find where process, awareness, and detection break so you can close the gap — not to catch individuals out or generate a dramatic story.

We are also careful not to overclaim. A red team is a controlled simulation under agreed constraints; it’s strong evidence of how your detection and response would hold, but it is not the same as an unconstrained real attacker, and we won’t pretend it is. Where a regulator requires threat-intelligence-led testing — TIBER-EU, CBEST, or DORA’s threat-led testing regime — we align the engagement to that framework and report it in a form your supervisor expects.

We price engagements fixed and banded by the objective and the size of the environment, and give you the band during scoping before you commit — no day-rate surprises and no incentive to pad hours. The scoping call is free; everything past it is a defined, paid engagement.

We sell no tooling and take no vendor commissions, so the engagement carries no agenda beyond answering your actual question. If you’re working to a budget, tell us during scoping and we’ll be straight about what objective it covers.