Start with an objective. Test the control chain standing in the way.
A Red Team assessment is not a larger vulnerability scan. It begins with an agreed objective and starting condition, then evaluates whether a realistic chain can progress through identity, endpoints, applications, cloud or infrastructure while security controls observe and respond. Every technique, target and safety boundary is governed by the Rules of Engagement.
REQUEST → SCOPE → AUTHORIZE → KICKOFF → EXECUTE
ASSESSMENT BOUNDARY
What is being assessed?
The engagement boundary is defined by systems, identities, workflows and restrictions—not only a list of URLs or assets.
- External-attacker, assumed-breach and insider-threat scenarios
- Active Directory, cloud and identity attack paths
- Endpoint execution, persistence and EDR-evasion controls where authorized
- Privilege escalation, segmentation and lateral movement
- Controlled data-access and exfiltration simulation
- Prevention, detection and response effectiveness
- Phishing, spear phishing or credential-harvesting simulations when explicitly included
What Botnet tests.
Coverage follows reachable trust decisions and agreed risk, with destructive or disruptive actions excluded unless explicitly authorized.
Initial condition
External exposure, an assumed internal foothold or another explicitly agreed starting point.
Identity
Trust, authentication and privilege paths that could move the scenario toward its objective.
Execution and evasion
Endpoint and execution controls within agreed techniques and safety restrictions.
Movement
Network, administrative and service boundaries between the starting point and target systems.
Objective
Controlled evidence that the agreed business objective was reached—or the control system held.
Detection
Available telemetry, alerts and response observations coordinated according to the engagement model.
How the work progresses.
- 01
Define
Agree objective, threat framing, starting position, crown-jewel boundaries and success conditions.
- 02
Authorize
Document scope, techniques, exclusions, deconfliction, emergency contacts and stop conditions.
- 03
Construct
Develop a scenario-led attack path from current evidence rather than a fixed checklist.
- 04
Execute
Progress through authorized stages with controlled evidence and operational safeguards.
- 05
Observe
Record prevention, telemetry, detection and response outcomes without exposing internal-only notes.
- 06
Reconcile
Deliver executive and technical narratives, then align remediation and validation priorities.
EVIDENCE + ACTION
What the customer receives.
- Executive report tied to the agreed objective
- Technical report and timeline of material actions
- Attack-path diagram, supporting evidence and MITRE ATT&CK mapping where useful
- Control, detection and response observations
- Prioritized remediation recommendations
- Final debrief and presentation for leadership and technical teams
Evidence over assumption.
01Objective-led rather than volume-led execution
02Control-chain evidence across multiple security domains
03Scenario choices grounded in scope and business relevance
04Clear separation of successful actions, blocked actions and untested assumptions
Before scoping.
Can social engineering be included?
Only when explicitly scoped and authorized in the SOW and Rules of Engagement. Channels, targets, payloads and prohibited actions must be agreed.
Can the assessment begin from an assumed breach?
Yes. An assumed-breach start can focus time on internal identity, privilege, movement and detection controls.
Will the SOC know the exercise is happening?
The awareness model is an engagement decision. It must be agreed with authorized stakeholders and supported by a deconfliction process.
Define the target, constraints and required evidence.
An assessment request starts a scoping conversation. It does not authorize testing. Work proceeds only after scope acceptance, executed authorization/SOW and kickoff.