What Is Red Teaming? Red Teams in Cyber Security Explained

A red team is a group of authorised testers who play the part of a real attacker, and red teaming is the exercise they run: a covert, objective-led attack simulation that tests whether your organisation can prevent, detect and respond to a determined adversary. Instead of listing every weakness in one system, the red team picks a goal, such as reaching the payment environment or a director’s mailbox, and tries to get there by any route the rules allow while your defenders go about their normal work.

Cyber security borrowed the term from military war-gaming, where a red force played the opposing side: red attacks, blue defends, and the security industry later added purple for the two working together. The idea is older than cyber security, and the Ministry of Defence’s Red Teaming Handbook, published on GOV.UK, describes red teaming more broadly as challenging plans and assumptions by taking an adversary’s view. A red team assessment, red team exercise and red team engagement all describe the same activity.

What is red teaming in cyber security?

In cyber security, red teaming is an authorised exercise in which skilled testers emulate the tactics, techniques and procedures of real threat actors to achieve agreed objectives across technical, human and, where agreed, physical routes. It measures your whole defence at once: the controls that should stop an attack, the monitoring that should notice it, and the people and processes that should respond.

Three things set it apart from other security testing:

• It is goal-led. Success is measured against objectives, not against the number of vulnerabilities found.
• It is covert. Only a small control group knows the exercise is running, so the blue team’s response is genuine.
• It is multi-vector. The red team can combine phishing, exposed services, stolen credentials, weak internal configuration and, if in scope, physical entry, the way a real attacker would.

Because the target is the organisation rather than a single system, a red team often shows how several modest weaknesses, each rated low on its own, chain together into a serious attack path. Our red team assessments page explains how we scope and run an engagement.

What is red team testing?

Red team testing is the practical side of red teaming: an authorised test in which the red team attacks your organisation, covertly and against agreed objectives, to measure how well you prevent, detect and respond. It answers a different question from a penetration test. A pen test asks “what is wrong with this system?”; a red team test asks “would we notice, and stop, a real attacker?”

The phrase is used loosely. Some providers call any scenario-based penetration test a “red team test”, so check what a quote actually includes: a true red team test has business objectives rather than a target list, runs with only a small control group aware, combines several attack routes and reports on detection and response, not just on vulnerabilities.

What does a red team do?

A red team plays the attacker from start to finish. It researches your organisation, finds a way in, establishes a foothold, moves towards its objectives without being caught and records everything it does so the defenders can learn from it afterwards.

Objectives are written as outcomes a real attacker would want:

People are often the way in. Phishing, phone pretexting and, where agreed, physical access attempts test the human side of the defence; our social engineering testing page explains how those techniques run as a standalone assessment.

What are the rules of engagement for a red team?

Rules of engagement are the written agreement that makes a red team exercise safe and lawful. They are signed before any activity starts and set out what the red team may do, what is off limits and who to call if something goes wrong.

A sound set of rules of engagement covers:

• Objectives and scope: the goals, the in-scope sites, systems and people, and anything excluded, such as a fragile production system or a supplier’s infrastructure.
• Authorisation: written permission from someone with authority over every system in scope. Unauthorised access can be an offence under the Computer Misuse Act 1990, so this is not a formality.
• Prohibited actions: typically no denial of service, no destructive changes, no real data leaving the organisation and no targeting of staff’s personal accounts.
• The control group: sometimes called the white team, the few people who know the exercise is running. They confirm whether suspicious activity is the red team (deconfliction) and can pause or stop the work.
• Escalation and data handling: what happens if the red team finds a real attacker or a critical flaw, and how evidence and captured credentials are stored and destroyed.

What are the phases of a red team exercise?

A red team exercise follows the same broad path as a real intrusion: reconnaissance, initial access, persistence, escalation and movement, then action on the objectives, followed by reporting and a debrief. Many providers map each step to MITRE ATT&CK, a public knowledge base of adversary tactics and techniques, so defenders can see exactly which behaviour they did or did not detect.

The report is what turns the exercise into improvement. A useful one gives an attack narrative from first access to objective, a timeline the blue team can match against its own logs, the detection and response gaps found, and prioritised fixes.

Red team vs blue team: what is the difference?

The red team attacks and the blue team defends. Red teamers emulate a real adversary to reach objectives; the blue team, usually your security operations centre (SOC), IT security staff, incident responders or a managed detection provider, monitors, detects, investigates, contains and recovers. Neither side “wins”: the point is to find gaps before a real attacker does.

The blue team’s work does not stop when the exercise ends; detection and response are continuous, and the NCSC’s incident management guidance sets out what good preparation looks like. Purple is not a third standing team but a way of working in which red and blue sit together and tune detection technique by technique, as our guide to purple teaming explains.

How does red teaming apply to AI systems?

The same adversarial mindset can be turned on an AI model or an application built on a large language model (LLM): testers try to make it ignore its instructions, leak data or misuse the tools it has been given, using the OWASP Top 10 for LLM Applications as a reference. That is a different discipline from a red team exercise against your organisation, which is why a search for “red teaming” now returns results about both. Our AI red teaming page explains how it works and what it covers.

Who needs red teaming?

Red teaming suits organisations that already have the basics in place and want to know whether their defences hold against a capable, patient attacker. It is a poor first test: without monitoring and a response process, a red team will usually succeed and simply confirm that nobody could see it.

Organisations usually commission a red team for one of these reasons:

• They have invested in detection, such as a security operations centre, a managed detection and response service or a new SIEM, and want an independent check that it catches a realistic attack.
• They hold something a capable attacker would pursue patiently, such as payment systems, large volumes of personal data or privileged access to customers’ systems.
• Their penetration tests now find little that is new, so the more useful question is whether an attack would be seen and stopped.
• The board wants an honest measure of detection and response rather than a pass mark.

Before booking one, work through the readiness checklist in our guide to red teaming vs penetration testing, which also compares the two tests side by side.

For some financial firms red teaming is a regulatory expectation: EU financial entities selected under DORA must run threat-led penetration testing, a form of red teaming on live production systems, and the UK has its own schemes such as CBEST. Our guide to DORA TLPT explains them; Sovereign Secure is not a TLPT or CBEST provider.

If you are not ready yet, an internal penetration test shows how far an attacker could get from a single compromised account, and gives your team a list of fixes to make before a red team is worth running.

Why Sovereign Secure

• Independent, with approvals you can check. Sovereign Secure is a PCI SSC Qualified Security Assessor (QSA) company and is ISO 27001 certified.
• Written rules of engagement for every exercise, agreed with a small trusted group, and a debrief for your team.
• Follow-up testing in one place. We test web applications, APIs, networks, cloud, mobile apps, hardware and IoT, wireless, social engineering, source code and AI and LLM applications, and run vulnerability scanning.
• Fixed-price proposals that state the objectives, vectors and duration before work starts.

Next step

If you think you are ready for a red team, tell us what you most need to protect and what monitoring you have in place. We will suggest realistic objectives and tell you honestly whether a red team or a targeted penetration test is the better next step. Request a red team quote or call us on +44 161 523 5276.