SysTools
Red Teaming

Red Teaming

A simulated attack against your organisation, working towards a goal that would genuinely hurt if a real attacker reached it. We use whatever route works — technology, people or the front door — within limits you set. The real question it answers is not just whether someone could get in, but whether your team would notice and how fast they would stop it.

Progress 0% 0 of 0 answered 0 mandatory pending

Before you start

  • A red team engagement simulates a real attacker going after a specific goal. Unlike a penetration test, we are not listing every weakness — we are finding out whether someone determined could reach what matters, and whether you would notice.
  • This needs written authorisation from someone senior enough to approve it. We will not begin without it.
  • Please do not type passwords or credentials into this form.
  • Fields marked * are needed before we can begin. Anything you are unsure of can be settled on the scoping call.

1 Engagement Details

Mandatory

This needs to be someone senior enough to accept the risk on the organisation's behalf — typically a CISO, CTO or equivalent. We ask because red team activity looks like a real attack, and without documented authorisation from the right person it can create serious problems for everyone involved.

Starting from outside is the most realistic. Assumed breach often gives better value, because getting in is rarely the hard part — what happens next is where organisations actually lose.

The question you want answered at the end. This shapes everything else.

2 Objectives

Mandatory

A red team works towards agreed goals rather than scanning everything. These are those goals.

Be specific. These become the targets we work towards, and reaching one is how the engagement is judged.

Agreeing this now avoids arguments later about whether an objective was really met.

If they do not know, you learn what genuinely gets noticed. Expect a real incident response to start — which is the point, but it needs the deconfliction contact below to be reachable.

3 What We Are Allowed to Do

Mandatory

Anything not permitted here will not be attempted, even if it is the easiest way in.

Anything not ticked will not be attempted, even if it is the easiest way in. We never test denial of service, never destroy or ransom data, and never use phishing themes that would genuinely distress staff — no fake redundancy, bonus or bereavement messages.

If our team is stopped by security or police during a physical test, this letter is what proves they are meant to be there. It is arranged before any physical activity begins.

4 Standards and Reporting

Mandatory

MITRE ATT&CK is the default and suits most organisations — every action we take is mapped to it, so your team can check their detection coverage technique by technique. Regulated financial institutions sometimes have to follow a scheme such as TIBER-EU, CBEST or an RBI requirement instead.

You get a narrative of how the attack unfolded, a timeline of what your team detected and when, and the technical detail needed to close each gap. Telling us the audience decides where the emphasis goes.

Usually the most valuable hour of the engagement. We replay each step next to your own logs, so your team can see exactly where they could have caught us and why they did not.

5 How We Run It

Nothing here needs an answer — it is what you are buying.

How the assessment runs

We agree the objectives, the boundaries and what we are allowed to do, and start only once written authorisation is signed. We then build a picture of you from public information, choose the routes a real attacker would most likely take, and work towards the agreed objective — getting a foothold, gaining rights, moving through the network. Throughout, we log every action and its exact time, so afterwards it can be compared against your own alerts to show what was seen and what was missed. Everything we created or changed is removed at the end, and the list is handed to you.

What we look for

Not a list of every weakness — once we find a route in, we take it. What you get is the answer to two questions: could someone reach what matters, and would you notice? Alongside the findings you get a detection timeline: every action we took, whether it raised an alert, whether anyone acted on it, and how long that took. For most organisations that is the more useful half of the report.

What we will not do

We never run denial-of-service attacks, never destroy, encrypt or ransom data, and never remove real customer data — test files are used to show that data could leave. We do not use phishing themes designed to distress staff, such as redundancies, bonuses or bereavement. Phishing results are reported as numbers, not names. If we find evidence that a real attacker is already inside your network, we stop and tell you immediately.

6 How We Rate Findings

Findings are rated by how far they moved a real attacker towards an objective, not in isolation.

SeverityWhat it means
CriticalDirectly enabled an objective to be reached, or gave control over the whole environment. Would have been a serious breach if we had been real.
HighA major step along the attack path — gaining administrative rights, harvesting credentials, or moving into a sensitive part of the network unchallenged.
MediumHelped the attack but was not decisive, or needed something else to go wrong first.
LowMade the attack slightly easier or gave away useful information, without contributing directly.
ObservationWorth improving, but it neither helped nor hindered the engagement.

Alongside the findings you get a detection timeline: every action we took, when we took it, whether your tooling generated an alert, whether anyone acted on it, and how long that took. For many organisations this is the most useful part of the report — the gaps in what your team can see are usually more actionable than the individual weaknesses we used.

7 Timeline

Agreed on the scoping call — not estimated here

Unlike our penetration testing services, a red team engagement cannot be estimated from a count of systems. The duration depends on the objectives, how mature your detection already is, how much time the team needs to stay quiet, and which techniques you have permitted — and a number generated from a form would be wrong often enough to be misleading.

As a rough guide, most red team engagements run between three and eight weeks of active testing, plus reporting. Once we have been through your answers above, we agree the exact duration and write it into the rules of engagement, along with the test window and the review points along the way.

Save and Export Response

Your answers stay in this browser until you export or clear them.