Readers often confuse three things: a red team writeup, a penetration test report, and a training-room walkthrough. Lab tasks, such as those in TryHackMe's Red Team Engagements room, teach the planning vocabulary. Real engagements adapt that vocabulary to business risk.
This guide connects the two. It moves from objectives and scope through rules of engagement, campaign documents, attack simulation, reporting, remediation, and retesting.
Key Takeaways
- Start every engagement with a business objective, authorized scope, and agreed success criteria.
- Rules of engagement protect the client and the testers by defining actions, limits, and stop conditions.
- CONOPS, resource, operations, and mission plans serve different audiences.
- Value comes from better detection, response, and risk decisions, not from a long vulnerability list.
What Is a Red Team Engagement?
What red teaming tests
NIST defines a red team as a group authorized to emulate a potential adversary's attack or exploitation capabilities against an enterprise's security posture. Ethical professionals pursue a specific objective using realistic but controlled tactics, techniques, and procedures.
Objectives vary:
- Reaching a specific data set
- Controlling a critical system
- Reaching an industrial environment through the IT network
- Validating segmentation or detection coverage
The target is the whole defensive system: security tools, alert triage, incident response, executive communication, third-party coordination, and recovery decisions.
DeepSeas frames it as an assessment of the security operation rather than only the attack surface. That means recording which actions were detected or missed, how long detection took, whether alerts were investigated, and whether response interrupted the operation.
Red teaming compared with related assessments
| Assessment | Objective | Notification | Typical outcome |
|---|---|---|---|
| Vulnerability assessment | Identify weaknesses in assessed assets | Set by the assessment | Vulnerability and mitigation list |
| Penetration test | Circumvent controls within a technical scope | Overt or covert | Evidence of exploitable weaknesses |
| Red team | Pursue an adversary objective across multiple paths | Often limited to a control group | Attack path and defensive-capability findings |
| Purple team | Collaborate on red and blue actions | Defenders participate | Detection and control improvements |
Notification is a design choice, not a hard dividing line. Even covert tests need upper-management permission.
A penetration test asks whether controls can be bypassed. A red team asks whether detection and response will notice and stop a capable adversary.
A purple team follow-up uses red team evidence to tune detection logic and response procedures directly with defenders, trading some realism for faster improvement.
When to consider one
Common triggers include:
- A major technology change
- A merger or acquisition
- Repeated incidents
- A new sector threat
- A need to validate a mature detection and response program
Regulation rarely names red teaming outright. PCI DSS 4.0.1 requires penetration testing at least every 12 months and after significant changes. DORA requires threat-led penetration testing for selected EU financial entities. Neither is a universal US red team mandate.
Readiness matters more than any trigger. Red teaming suits organizations whose obvious gaps are already closed and that have internal monitoring and the ability to act on findings. A team still fixing basic exposures gets more value from a penetration test.
DeepSeas offers offensive security, including controlled attack simulations, for organizations that reach that point.
Defining Objectives, Scope, and Rules of Engagement
Establishing clear objectives
The client, security leadership, legal stakeholders, and testing team translate business concerns into objectives that can be tested and reported. Examples:
- Testing external exposure
- Validating endpoint and SIEM detections
- Assessing lateral movement controls
- Evaluating incident response
- Measuring the impact of a simulated data-access scenario
"Test our security" is the weak version. It produces unclear findings, inconsistent decisions, and reports nobody can prioritize.
Building a precise scope
List what is in and out of bounds: domains, applications, IP ranges, cloud accounts, facilities, personnel groups, third parties, operational technology, and production systems. Then address prohibited actions:
- Denial-of-service activity
- Destructive malware
- Unapproved data access
- Unsafe social engineering
- Interaction with protected systems
Scope also has to respect business-critical processes, maintenance windows, regulatory boundaries, data sensitivity, and dependencies that could cause unintended disruption.
Documenting the rules of engagement
NIST SP 800-115 supports a written assessment plan covering authorized and excluded systems, logistics, data handling, and incident handling. A solid ROE records:
- Written authorization and signatures
- Testing dates and hours
- Permitted techniques
- Communication channels and emergency contacts
- Evidence-handling rules and data-exfiltration limits
- The process for approving scope changes
Add stopping conditions: service instability, suspected real-world compromise, unexpected access to sensitive data, safety concerns, or an instruction from the designated client authority. Legal review, client sign-off, and deconfliction all belong here. Defenders must be able to tell a simulation from an actual incident.
Success criteria and communication
Define evidence of success in advance. That could be reaching an agreed objective, testing a detection, validating a response procedure, or finding a control gap without operational harm. Recurring status updates, escalation paths, and a decision log keep the client informed without exposing sensitive operator detail.
One note for training writeups: label every sample IP address, date, threat group, tool, and platform as fictional or lab-specific. Never reuse them without authorization.
Campaign Planning and Engagement Documentation
Mapping lab tasks to engagement documents
Training rooms typically progress from scope and objectives to ROE, campaign planning, and documentation, then four plans: CONOPS, resource plan, operations plan, and mission plan. Treat any lab question-and-answer material as a walkthrough, not evidence from a real customer engagement.
These are not universal templates. The DoD cyber test guidebook and the ECB's TIBER plan guidance each use their own structures. Adapt yours to your risk, industry, governance, and goals.
What each document contains
- CONOPS: a high-level, semi-technical overview for business stakeholders and operators covering client, provider, timeframe, objectives, major phases, threat emulation approach, and tooling categories.
- Resource plan: a concise inventory of dates, personnel, technical knowledge, infrastructure, cloud resources, and hardware.
- Operations plan: execution constraints, planned activity categories, communications, responsibilities, and halting conditions.
- Mission plan: operator-specific tasks and targets that translate those decisions into action.
Writing a useful and responsible writeup
Organize each phase around:
- Purpose and authorized actions
- Evidence collected and decision points
- Results and next steps
A bare list of answers teaches nothing. Strip credentials, personal data, customer identifiers, live infrastructure details, and anything that could enable unauthorized access.
A strong writeup also shows how planning decisions shaped the exercise and what defenders can do differently afterward.
In a sanitized DeepSeas client exercise, EDR detected or blocked credential-dumping tools, automatically terminated an LSASS memory-dump attempt, and caused a later attempt to fail. DeepSeas then notified the client that the activity was a red team exercise.
That single timeline answers what was tried, what the defenses did, and when.
The Five Phases of a Red Team Engagement
No universal five-phase model exists. TIBER-EU uses preparation, testing, and closure. CBEST uses initiation, threat intelligence, penetration testing, and closure. The five phases below group that same work in practical terms.
Planning and preparation
Before testing begins, the team confirms:
- Objectives, scope, and ROE
- Stakeholders and resources
- Threat assumptions
- Communications and safety controls
- Success criteria
Align the exercise with risk appetite. Healthcare, education, government, financial, and manufacturing environments need extra care.
NIST SP 800-82r3 cautions against adverse effects in operational technology and suggests replicated or simulated systems. It is not blanket permission to test production.
Reconnaissance and attack-surface analysis
Recon covers passive and authorized active work at a high level: asset discovery, public information review, identity and access pathways, cloud exposure, application dependencies, and likely defensive controls. It stays inside the approved scope. Collected information follows the engagement's privacy and evidence rules.
Attack simulation and objective pursuit
Operators use permitted tactics to test initial access, privilege boundaries, lateral movement, persistence, data access, social engineering, or physical controls. For every step, record:
- Timestamps and affected assets
- Technique category
- Observed defensive response
- Operator decisions
- Any stopping condition reached
Reporting and executive debrief
A strong report includes:
- Executive summary
- Objective and scope
- Timeline and attack path
- Evidence and affected controls
- Business impact and limitations
- Prioritized findings and recommended actions
European Central Bank (ECB) report guidance also asks for objectives reached or missed, so the report is not only a list of weaknesses.
Map findings to MITRE ATT&CK or a relevant control framework, but keep the language readable for executives. ATT&CK is a shared vocabulary, not a chronological lifecycle.
Hold a debrief with the red team, blue team, system owners, legal stakeholders, and leadership. Confirm facts, resolve discrepancies, and agree on immediate actions.
Remediation, validation, and continuous improvement
Prioritize fixes by business impact, exploitability, exposure, detectability, and effort. Typical follow-up:
- Tune alerts and update playbooks
- Improve identity controls and segmentation
- Train personnel and revise ROE assumptions
- Retest
A purple team workshop shows whether defenders can now prevent, detect, investigate, and contain the demonstrated path. Collaborative replay is not proof of a fix, though. NIST notes that retesting validates completed mitigation, and that is a separate step.
Conclusion: Turning Findings Into Better Defense
A red team engagement succeeds when it produces authorized, credible evidence that improves security decisions. A dramatic attack narrative is not the measure.
Tie every finding to:
- An owner
- A risk decision
- A remediation action
- A detection improvement
- A validation date
Without those, the report becomes shelfware.
Organizations that need controlled offensive testing can evaluate an expert-led provider. DeepSeas pairs offensive security with advisory, threat intelligence, managed detection and response, a SOC, and GRC capabilities, so findings can feed directly into detection tuning.
Frequently Asked Questions
How much does a red team engagement cost?
Pricing depends on scope, objectives, number of environments, attack types, duration, operational risk, reporting depth, and follow-up needs. Request a scoped proposal rather than relying on a generic price.
What is red teaming and what is its purpose?
Red teaming is an authorized adversarial simulation. Its purpose is to test prevention, detection, response, and resilience against a realistic objective.
Can you give me an example of red teaming?
A team is authorized to reach a protected business data set through approved pathways. Afterward, the analysis asks whether defenders detected, investigated, and contained the activity.
How is a red team engagement different from a penetration test?
A penetration test generally finds vulnerabilities within a defined technical scope. A red team evaluates whether the organization can stop an adversary from achieving a broader objective.
What should rules of engagement include?
Include authorization, scope, permitted and prohibited activity, timing, communication, data handling, emergency contacts, stopping conditions, and approval for scope changes.
