Red teaming: when you need an objective-based test of detection and response
Red teaming is a covert, objective-based test that emulates a realistic adversary across people, process and technology to find out whether your organization can detect and respond to an attack. If a framework, a customer security review, a product launch, an insurer or a due diligence process has asked you to show that your defenses work in practice, a red team exercise answers a different question from a standard penetration test. It does not try to list every weakness. It asks whether a determined attacker could reach a defined goal, such as access to customer records or disruption of a payment service, and whether your staff and tooling notice and stop them before they do. NIST SP 800-115 describes covert testing as work performed without the IT staff's knowledge but with upper management's permission. That permission is the foundation of the exercise. It tests technical controls, the response of staff to perceived incidents and their knowledge of policy, and it usually stops at defined boundaries such as a maximum level of access. Because the blue team is not warned, the result shows real detection capability rather than how well people perform when they expect a test. Before you commission one, confirm that a named executive has signed the authorization and that the boundaries and the list of people who know about the test are written down. Organizations usually commission red teaming for three reasons: to validate that monitoring and incident response work against realistic techniques, to meet a requirement that asks for adversary-led testing, or to give leadership evidence of where investment should go. The risks it addresses are the gap between controls on paper and controls that alert in practice, and the gap between documented response procedures and what teams do under pressure. Ask your provider how the objectives will be set from threat intelligence about your sector, and which tactics from the MITRE ATT&CK Enterprise matrix the engagement will plan against and report on.
What a red team scope covers and the decisions behind it
A red team scope is a set of deliberate choices, not a list of hosts. Each card below is a decision the client and provider must agree in writing before any testing starts, and each one changes what the exercise can prove.
Objectives and crown-jewel systems
The objective is the outcome the adversary is trying to reach, such as moving money, reading customer records or disrupting a service. Crown-jewel systems are the platforms that make that outcome possible. Agree on a small number of objectives that map to business impact, then name the systems and data behind each one. Ask the provider how they will show progress toward each objective in the weekly reporting, and who on the client side can accept or reject a proposed target before it is touched.
Environments in scope
Decide which environments are live production, which are staging or copies, and which are owned by third parties such as SaaS providers, managed service providers or cloud hosts. Production testing carries the most value and the most operational risk, so the scope should state which systems may be affected, how availability is protected, and who can halt activity. Confirm that every third-party asset in scope has its own permission path, because the client cannot authorize testing of systems it does not control.
Accounts and roles to be emulated
Red teams usually emulate a realistic attacker's starting position, which may be an external party with no credentials, a contractor, or an employee with a standard account. The scope should list which identities, roles and privilege levels the team may use, and whether any administrative accounts are provided for objective testing. Ask how credentials are issued, stored and revoked, and how the team records which account was used for each action so the report and the blue team can reconstruct the path.
Social engineering and physical elements
Phishing, vishing, pretexting and on-site access attempts are optional elements of a red team. Each one needs its own consent, its own named individuals or roles who may be targeted, and data handling rules for any personal information gathered. Under NIST SP 800-115, posing as a help desk agent to request passwords is a recognized validation technique, so the scope should say whether such pretexts are allowed and which teams must be told in advance. Leave out elements the client cannot support legally or operationally.
Stop boundaries and escalation rules
NIST SP 800-115 describes covert testing as usually stopping at defined boundaries, such as a certain level of access. Write these boundaries down: which access levels end the activity, which actions are never permitted (for example, destructive changes or data exfiltration of real records), and who is notified when a boundary is reached. Agree how the team escalates a finding that exposes real customer harm during the exercise, and confirm the contact path works at night and at weekends.
Cloud provider testing rules
AWS and Microsoft each publish their own penetration testing rules, and some activities need advance approval. AWS requires a simulated events request at least 2 weeks in advance for red, blue or purple team testing, simulated phishing and malware testing against AWS-hosted assets. Microsoft's rules of engagement prohibit phishing or social engineering of Microsoft employees. Check these rules before fixing the timeline, and confirm which activities the provider's terms allow in your tenant.
How a red team engagement runs from scoping to retest
The sequence turns a business objective into a covert, intelligence-led test, then into detection improvements and a retest that shows whether those changes held. Each phase produces a written artifact that the client can check before the next phase starts.
Agree objectives, scope and rules of engagement
The client's security lead, the DeployOpen red team lead and, where the client uses one, the executive sponsor agree the business objective, the systems in scope, the boundaries such as the maximum level of access or the systems that must not be touched, and the escalation contacts. NIST SP 800-115 describes covert testing as performed without the IT staff's knowledge but with upper management's permission, and it usually stops at defined boundaries. The output is signed rules of engagement and a written scope. Ask whether the rules name who may stop the test and how deconfliction works if the test is mistaken for a real incident. Duration is set in the written scope, which also states any provider-specific notice requirements, such as the simulated events request that AWS requires for red team testing against AWS-hosted assets.
Build the threat intelligence and adversary profile
The red team researches which threat actors are likely to target the client's sector, technology and business processes, then selects tactics, techniques and procedures that fit that profile. The adversary profile is mapped to MITRE ATT&CK techniques so the plan and later report use a shared vocabulary. The Enterprise matrix lists 15 tactics, from Reconnaissance to Impact, and the team uses them to show which parts of the kill chain the test covers. The output is an approved scenario document, reviewed by the client, that states the objective, the assumed attacker goals and the techniques in play. Where a regulator sets the method, such as TIBER-EU or DORA threat-led testing, the scenarios must follow that framework's requirements.
Set up the control team and covert execution
A small control team, usually drawn from people the client trusts and who know the test is running, holds the deconfliction records, monitors the test's safety and can stop it. The red team then runs the campaign covertly against live production systems, moving through the attack path toward the agreed objective while staying within the agreed boundaries. The blue team and the general IT staff are not told in advance, so the exercise measures technical controls, the staff's response to perceived incidents and policy knowledge. The control team logs each action with timestamps so later analysis can match activity to what the defenders saw. Social engineering or phishing components run only if they were included in the written scope and approved for the target staff.
Deliver the red team report and debrief
After execution ends, the red team writes a report that describes the attack path, each objective reached or not, the techniques used mapped to ATT&CK, the timeline of activity, the controls that worked, and the gaps that let the team progress. The report separates findings the client can fix from observations about how the defenders responded. The team then runs a debrief with the client's security operations and leadership. The output is the written report and a debrief record. Ask for a report that names the ATT&CK techniques and ties each finding to a remediation owner, since auditors and customer security reviewers will look for that traceability.
Validate detections in a purple team session
The red and blue teams replay selected techniques together, with the red team running each action in a controlled way and the defenders checking what was logged, what was detected and what raised an alert. Where a detection was missing, the blue team tunes the rule, correlation or logging source, and the red team reruns the technique to confirm the change. CIS Controls v8.1 Safeguard 18.4 asks organizations to validate security measures after each penetration test and to modify rulesets and capabilities to detect the techniques used. The output is a list of confirmed or improved detections, each linked to an ATT&CK technique. Purple teaming is a required step in TIBER-EU closure, and it is a common addition to commercial red team work.
Prepare the remediation plan and closure record
The client and DeployOpen agree a remediation plan that assigns each finding and detection gap to an owner, with a target for each fix set by the client. The team confirms which findings are closed, which are accepted as risk, and which need verification. Where the test is part of a regulated programme, the closure record may include the test summary, the replay outcome and any attestation the framework requires. DeployOpen prepares this evidence, but independent auditors and regulators decide whether it is sufficient. Confirm with the assessor which artifacts they expect before the report is finalized.
Retest the fixes and confirm they hold
Once the client reports that remediation is complete, the team retests the specific attack paths and detections that were changed. The retest checks whether a fix blocks the technique, whether the detection now fires, and whether the fix introduced a new weakness. The output is a retest report that states, for each item, whether it is resolved, partially resolved or still open, with evidence. The retest is scoped in writing like the original test, and its cost and timing depend on how many findings need checking and how much of the environment changed. Ask for the retest to be included in the original quote if the regulator or customer expects proof of closure.
How threat-led frameworks change the red team test
Regulation (EU) 2022/2554, Article 3(17), defines threat-led penetration testing (TLPT) as a framework that mimics the tactics, techniques and procedures of real-life threat actors. It delivers a controlled, bespoke, intelligence-led red team test of a financial entity's critical live production systems. Delegated Regulation (EU) 2025/1190 turns that definition into operating rules that a buyer must plan around.
- Scenarios: The delegated regulation requires at least three TLPT scenarios, and at most one may be non-threat-led.
- Duration: Active red team testing must run for at least 12 weeks, with progress reports at least weekly.
- Team expertise: TLPT testers must have specific expertise in threat intelligence, penetration testing and red team testing.
- Red team manager: Article 7 requires a red team manager with at least 5 years' experience and at least two testers with 2 years each.
- Production scope: The test runs against live production systems, so rules of engagement and safety controls carry more weight than in a lab exercise.
Confirm with your competent authority and your own risk function which entities and systems fall within the regime before scoping.
The TIBER-EU framework, updated in January 2025 to align with the DORA TLPT standards, sets out how European authorities run intelligence-led tests. Each test moves through preparation, testing and closure phases. The framework is designed to improve resilience, so it does not produce a pass or fail result.
- Preparation: The entity, the authority and its providers agree scope, threat intelligence and rules of engagement.
- Testing: The red team runs the scenarios while the blue team operates normally, without prior knowledge of the attack.
- Closure: Closure includes red and blue team reports, a replay, purple teaming, a test summary report, a remediation plan and an attestation.
- Control Team: The former White Team is now called the Control Team, which manages the test and protects its secrecy.
- Mandatory purple teaming: Purple teaming is now a required part of closure, so detections are tuned against the techniques actually used.
Confirm which TIBER-EU implementing body applies to your jurisdiction, since national authorities run the process.
CBEST is a targeted, threat intelligence-led assessment used in UK financial services. It has been part of the Bank of England, PRA and FCA supervisory toolkit since 2014. The current CBEST Implementation Guide is the 2024 edition. Like TIBER-EU, it tests people, process and technology together against credible threat actor behavior.
- Threat intelligence first: A threat intelligence provider builds the scenarios that the red team then executes.
- Supervisory role: The regulators oversee the test and receive its outcomes, so the entity should involve them early.
- Scope and safety: Testers and the entity agree scope, live system boundaries and safeguards before any activity begins.
- Reporting: Outputs feed the entity's remediation work and its supervisory discussions, not a public score.
- Accredited providers: Buyers should check that providers and testers meet the scheme's current requirements in the 2024 guide.
Confirm the current requirements and your supervisory expectations directly with the Bank of England, PRA or FCA contact for your firm.
Organizations outside regulated financial services, including SaaS providers, healthcare groups and public bodies, often borrow the threat-led methodology. A voluntary exercise keeps the intelligence-led approach but drops the regulatory obligations. The framework is optional, so the organization sets its own scope, duration and governance.
- Chosen objectives: The organization names the crown-jewel assets and the scenarios it wants tested.
- Own governance: A control team and rules of engagement are still useful, even without a regulator requiring them.
- Flexible duration: Duration is negotiated against objectives, not fixed by a regulation.
- Credentials: Testers should show the expertise the regulated frameworks require, even when the frameworks do not apply.
- Evidence: Reports can support customer security reviews and insurer questionnaires, but they do not satisfy a DORA or TIBER-EU obligation.
Confirm with your customers, insurers or auditors whether they will accept a voluntary exercise as evidence before you commission it.
Weakness categories a red team exposes and why they matter
This table groups the weakness categories a red team commonly surfaces, describing what each looks like in practice and why it matters to the organization. Read it as a map of where objective-based testing tends to find gaps that a vulnerability scan would not, and use it to decide which categories your own exercise should measure. The main takeaway is that most findings concern detection and response, identity and process, not only unpatched systems.
| Category | What it looks like | Why it matters |
|---|---|---|
| Detection gaps and unalerted techniques | Adversary actions run for an extended period without generating an alert, or generate logs that nobody reviews against the relevant ATT&CK technique. | Controls that are present on paper do not protect the business if the activity is invisible to the security operations team. Validating detections against the techniques used is the core purpose of purple teaming follow-up. |
| Slow or unclear incident response | Suspicious activity is noticed but escalation is delayed, ownership is disputed, or containment steps are unclear or require approvals no one can give quickly. | Response time determines how far an intrusion spreads. Assessors and regulators expect evidence of how the organization responded, not only that it detected something. |
| Help-desk and process weaknesses | Support staff reset credentials or grant access after a convincing but unverified request, or approval steps can be bypassed by a plausible pretext. | Process controls are often outside the technical stack and rarely tested. Findings here point to verification procedures and training, which are usually cheaper to fix than technical changes. |
| Lateral movement paths across identity and network | Permissions granted for convenience allow a compromised standard account to reach systems far outside its role, through shared administrator credentials, trust relationships or flat network segments. | Identity sprawl turns one foothold into broad access. Mapping these paths shows which segmentation and privilege reductions will limit the impact of a single compromise. |
| Unmonitored cloud and SaaS control planes | Administrative actions in cloud consoles, identity providers or SaaS admin panels are not logged centrally, or alerts do not cover changes to permissions, keys or logging settings. | Attackers who gain control-plane access can disable protections quietly. Gaps here often sit between the cloud team and the security team, so the exercise should confirm ownership and log coverage. |
Which compliance programs expect red teaming and what they ask for
Does DORA require red teaming for financial entities?
DORA requires threat-led penetration testing (TLPT) for certain financial entities, and it defines TLPT as a framework that mimics the tactics, techniques and procedures of real-life threat actors. It delivers a controlled, bespoke, intelligence-led red team test of critical live production systems (Regulation (EU) 2022/2554, Article 3(17)). Delegated Regulation (EU) 2025/1190 sets the operating rules. It requires at least three TLPT scenarios, of which at most one may be non-threat-led, and active red team testing of at least 12 weeks with at least weekly progress reports (Articles 10 and 11). It also requires testers with specific expertise in threat intelligence, penetration testing and red team testing. A red team manager with at least 5 years of experience and at least two testers with 2 years each are required (Article 7). Confirm with your competent authority whether your entity is in scope and which testing body applies, since those rules come from your national regime and the regulation's own criteria.
How does TIBER-EU differ from a standard red team test?
TIBER-EU is the European Central Bank's framework for intelligence-led red team testing, and its January 2025 version was aligned with the DORA TLPT standards. Three changes matter most to buyers. Purple teaming is now mandatory, the White Team has been renamed the Control Team, and tests run in preparation, testing and closure phases. Closure includes red and blue team reports, a replay, purple teaming, a test summary report, a remediation plan and an attestation. TIBER-EU tests produce no pass or fail result, so the value lies in what the organization detects, responds to and fixes. Participation runs through the national authorities that implement the framework, so confirm the local arrangements with your authority before scoping. Testers must also meet the expertise and staffing expectations set out for TLPT.
What does CBEST require for UK financial firms?
CBEST is a targeted, threat intelligence-led assessment that has been part of the Bank of England, PRA and FCA supervisory toolkit since 2014. The current CBEST Implementation Guide is the 2024 edition, and it sets out how firms plan, scope and run intelligence-led tests of their most important services. Firms should expect a threat intelligence provider to build scenarios, a testing provider to execute them, and a Control Team or equivalent to manage risk and keep the exercise contained. Ask your supervisor and provider which parts of the 2024 guide apply to your firm and how results are shared with the regulator, because those expectations come from the guide and supervisory dialogue, not from this page.
What does NIST SP 800-53 CA-8 require for red team exercises?
NIST SP 800-53 Rev. 5 control CA-8, Penetration Testing, has three enhancements: an independent penetration testing agent or team, red team exercises, and facility penetration testing. Enhancement CA-8(1) covers red team exercises, and SP 800-53B selects CA-8 and CA-8(1) for the high baseline. For a federal system or a contractor handling one, this means the assessment plan should state whether a red team exercise is included, who performs it and how independence is maintained. Your authorizing official or assessor decides whether the exercise satisfies the control, so agree the scope, rules of engagement and reporting format with them before testing starts. DeployOpen prepares the evidence package, and the assessor or authorizing official draws the conclusion.
What does CIS Controls Safeguard 18.4 ask after a penetration test?
Safeguard 18.4 of CIS Controls v8.1 asks organizations to validate security measures after each penetration test. Where needed, they modify rulesets and capabilities so the techniques used during testing are detected. In practice, this makes the post-test work part of the requirement. A finding is closed only when logging, detection and alerting have been checked against the techniques the testers used. A purple team exercise is the usual way to meet this, because testers and the blue team replay techniques together and tune detections. Ask your provider to map findings to the techniques used and to record which detection changes were verified, so you can show the work to an assessor.
Does PCI DSS penetration testing guidance cover social engineering?
Yes. The PCI Security Standards Council's Information Supplement, Penetration Testing Guidance (v1.1, September 2017), covers social engineering as a component of penetration testing. For payment environments, this means any social engineering in scope should be agreed in writing, tied to the cardholder data environment, and reported with the rest of the test. The guidance itself is the authority here, so read the current version and confirm with your Qualified Security Assessor how it applies to your scope. Social engineering also needs consent limits, data handling rules and clear escalation paths. Those rules should be documented before the first pretext is used.
Who issues the compliance opinion after a red team test?
Independent auditors, assessors and certification bodies issue audit reports, attestations and certifications. DeployOpen prepares systems, controls and evidence for those assessments, including test plans, rules of engagement, reports, remediation records and retest results. It does not issue audit reports, attestations or certifications. Before testing, ask the auditor, regulator or customer what evidence they need, in what format and at what level of detail. Those answers shape the scope and the report structure more than any generic template.
What should I ask for in a red team quote for a compliance test?
Ask for a written scope that names the frameworks, the systems and the objectives, and that states what is out of bounds. The quote should list each deliverable, including the report, the remediation plan, retest and any replay or purple team session the framework expects. Confirm who is paid for threat intelligence, testing, control team support and reporting, and whether those costs are one-time or recurring. Duration should follow the framework's minimum active testing period, so ask how that minimum is built into the timeline. Also ask how the provider handles staff qualifications, independence and data handling. DeployOpen does not publish a price list, and a quote follows from the written scope.
What you receive and whether it satisfies your auditor or customer
A red team engagement produces more than a findings list. The deliverables below connect the attack story, the detection gaps, the tuning changes and the fixes, so each can be checked against your auditor's or customer's expectations. Confirm acceptance criteria in writing before testing starts, because the format a regulator or assessor expects depends on the framework.
Red team report
The main written output covers the objective, the scope actually tested, the threat intelligence that shaped the scenario, the access the team achieved and the business impact of each path. Ask whether the report separates facts observed during the test from the assessor's judgment. Check that it states the rules of engagement and any boundaries the team stayed within, since a reader outside the engagement needs those to interpret the results.
Attack narrative mapped to ATT&CK
The narrative walks through each phase of the campaign and tags every technique to a MITRE ATT&CK technique ID, so your detection engineers can match each step against their logs. Confirm which ATT&CK version the mapping uses before you accept it. MITRE ATT&CK v20 was released on 13 October 2026, and an older mapping may need reconciling with current technique names.
Detection and response findings
This section records what the blue team saw, what it missed, how long it took to respond and whether the response followed the playbook. It measures people and process as well as tooling, so it can show a gap that a technical scan would never surface. Ask for timestamps for each detection event, because they let you compare response performance across phases and against your own incident response targets.
Purple-team tuning record
Where the team ran techniques alongside your defenders, the record lists each technique, the logging and alerting result, and the detection rule or configuration changed in response. This is the evidence that supports CIS Controls v8.1 Safeguard 18.4, which asks for security measures to be validated after penetration testing and adjusted to detect the techniques used. Ask for the before and after state of each change so an assessor can verify it.
Remediation plan and retest results
The remediation plan assigns an owner, a priority and a target date to each finding, and the retest results show which fixes were verified. Under TIBER-EU, closure includes a remediation plan and a test summary report, and tests do not produce a pass or fail result, so judge the plan by its completeness and its follow-through. Ask whether retesting is included in the fixed scope or quoted separately.
Assessor or customer letter
A letter summarizes that the test took place, its scope and dates, and the methodology used, without disclosing technical detail that would expose your environment. Confirm with your auditor or customer exactly what wording they accept and whether they require a named tester or accreditation, because DeployOpen does not issue audit reports or attestations. Where a TIBER-EU engagement applies, its attestation is issued under that framework, so align the letter with that structure.
What your team must prepare before a red team starts
Before testing begins, the most important step is a written authorization signed by an executive sponsor with the power to approve covert activity against production systems. NIST SP 800-115 describes covert testing as performed without the IT staff's knowledge but with upper management's permission, so the sponsor must be named, the authorization must state the permitted boundaries (for example, the highest level of access the team may reach), and the document must be stored where the team can produce it if a responder or a cloud provider asks. Ask your provider to draft the authorization against the agreed rules of engagement, and confirm who in your organization can revoke it.
Next, form a small control team, sometimes called the white team, that knows the exercise exists and can act on it. Keep it to a few people with named deputies, and give each one a working contact path that does not depend on the systems under test, such as a mobile number and an out-of-band chat channel. Agree an emergency stop procedure in advance: who can halt activity, the exact words or ticket used to trigger the halt, how quickly the testers must stop, and how the team confirms that no residual access or changes remain. Rehearse this once with a tabletop before testing starts.
Cloud and hosting providers have their own rules. AWS requires a simulated events request at least 2 weeks in advance for red, blue or purple team testing against AWS-hosted assets, so confirm your account path and the request timing before the planned window. Check the equivalent published rules for any other provider you use. Also agree a change freeze for the test window so operational teams do not deploy over the exercise, and decide how personal data the testers may encounter will be handled. Confirm with your privacy office what counts as personal data in scope, how incidental data is recorded, minimized and destroyed, and who keeps the evidence. Remember that the authorization, control team membership, notification decisions, data handling and remediation ownership all remain with your organization, even when a provider runs the operation.
How red teaming differs across on-premises, cloud and hybrid estates
In an on-premises estate, the red team usually builds its objectives around identity and lateral movement, because Active Directory is often the control plane for workstations, servers, file shares and privileged access. Objectives typically describe a business outcome, such as reaching a domain administrator equivalent or access to a named data store, rather than a list of hosts. Stop boundaries are set in advance and commonly cover domain controllers, backup infrastructure, safety-relevant systems and any production service whose outage would breach the rules of engagement. Detection sources usually include endpoint telemetry, domain controller event logs, the SIEM and any identity threat detection tooling the client already runs.
- Objective framing: Define the end state in terms of assets and privileges, for example control of a tier-zero system, rather than a count of findings.
- Stop boundaries: Agree which domain controllers, backup systems and maintenance windows are off limits, and how the control team halts activity.
- Detection sources: Confirm which event sources, EDR coverage and alert routes the blue team is measured against.
- Fit for purple teaming: Where detection content is immature, a purple team exercise often yields faster tuning than a covert run.
- Fit for assumed breach: When initial access is not the question, starting from a supplied standard user account keeps budget on privilege escalation and detection.
Before commissioning, confirm with the client which Active Directory tiers are in scope and whether the test may modify group policy or accounts.
In cloud and SaaS estates, much of the attack surface sits in control planes: identity providers, cloud administration APIs, infrastructure as code pipelines and tenant configuration. Red team objectives often centre on abusing identity and permissions to reach data stores or production workloads, and the boundaries are shaped by each provider's published testing rules and the shared responsibility model. Some activity, including simulated phishing or malware testing against hosted assets, may require advance notice to the provider. Detection sources are usually provider audit logs, cloud-native threat detection and the client's security information pipeline, so log completeness is a core test variable.
- Provider rules: AWS asks for a simulated events request at least 2 weeks in advance for red, blue or purple team testing and related simulated phishing or malware activity, and Microsoft's rules of engagement prohibit phishing or social engineering of Microsoft employees.
- Shared responsibility: Separate what the client controls, such as tenant configuration, from what the provider controls, such as the underlying platform, before setting objectives.
- Log coverage: Confirm which audit logs are enabled, retained and forwarded, since missing telemetry is a finding in its own right.
- SaaS tenants: Check whether the vendor permits testing of the tenant at all and what the contract or terms require.
- Stop boundaries: Limit actions that could affect shared services, other tenants or third-party data.
Confirm the provider's current published rules and the notice period before fixing the schedule.
Hybrid estates link on-premises directories to cloud identity services through synchronization, federation or pass-through authentication. A red team in this model tests the seams: whether a compromise in one domain grants reach into the other, and whether the synchronization and federation trust are monitored. Objectives often combine on-premises and cloud outcomes, so the rules of engagement must describe which trust relationships, service accounts and sync components are fair game. Detection is split across both sides, which means the blue team may have visibility on one side and gaps on the other, and the exercise often reveals that gap clearly.
- Trust paths: Map the synchronization and federation components so the team knows which paths count as in scope.
- Split telemetry: Confirm which signals reach the central SIEM from each side and whose team reviews them.
- Coordinated stop rules: Agree how activity against identity services is paused if it affects sign-in for real users.
- Shared accounts: Identify service accounts that bridge both sides and decide whether they can be used or only observed.
- Purple teaming: A collaborative run that replays techniques across both domains is often the most direct way to close telemetry gaps before a full covert test.
Confirm who owns each identity system and whether both owners will sign the rules of engagement.
What to check when choosing a red team provider
A red team engagement depends on people, authority and paperwork as much as on technical skill. The cards below set out what to verify before signing, from tester credentials to the written scope that governs the work. DeployOpen does not publish a price list, and quotes follow from the written scope.
Tester qualifications against DORA
If you are a financial entity in scope for threat-led testing, check whether the team meets the expertise the framework expects: threat intelligence, penetration testing and red team testing. Delegated Regulation (EU) 2025/1190 also sets experience requirements for the red team manager and testers. Ask for named individuals, their experience on comparable exercises and how their roles map to those requirements. A firm that cannot name people before the contract is signed is asking you to accept a risk you cannot assess.
CREST accreditation status
CREST describes itself as a UK not-for-profit company that accredits and certifies across security testing, red teaming, threat intelligence and incident management. Ask whether the firm holds CREST accreditation for the specific discipline you are buying, and whether the individuals on the engagement hold current CREST certifications. Verify these claims on the CREST register yourself rather than relying on a logo in a proposal. Accreditation does not replace scoping or tester quality, but it gives you an independent reference point.
Threat intelligence sources
A red team is only as realistic as the adversary it emulates. Ask how the provider builds the threat profile, which sources it uses, whether it relies on your sector's intelligence and how it maps the adversary's behavior to MITRE ATT&CK techniques. Request the intelligence summary and the objectives it supports before testing starts. Also confirm how that intelligence is handled, because a profile built on your own sensitive data needs the same controls as any other engagement material.
Rules of engagement and legal authorization
The rules of engagement set what testers may do, which systems and people are off limits, when testing runs and what triggers a stop. Written authorization from a senior executive protects both parties if a covert action is mistaken for a real attack. Check that the document names the target systems, including any hosted by cloud providers, and confirms whether those providers' published testing rules apply. Ask who can halt the exercise and how quickly they can reach the testers.
Control team and deconfliction process
The control team is the small group inside your organization that knows the exercise is running. It deconflicts real incidents from simulated activity, approves changes to the scope and records what happened for the final report. Ask who sits on the control team, how they are briefed, how they confirm a live alert is the red team and how the provider handles a genuine incident that overlaps with testing. Weak deconfliction can turn a test into an unplanned incident response.
Written fixed scope
Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask any provider to put the objectives, target boundaries, permitted techniques, duration, reporting cadence and exit criteria in one document. Confirm what the quote includes, such as the closing report and any retest, and what would trigger a change order. The written scope is also the document your auditor or regulator will ask to see.
Red teaming questions buyers ask before commissioning a test
How long does a red team engagement take and what sets the duration?
Duration depends on the objectives, the size of the target estate and how much preparation and closure work the programme needs. For threat-led tests under the EU framework, the supplied regulatory facts are specific: Delegated Regulation (EU) 2025/1190 requires active red team testing of at least 12 weeks, with at least weekly progress reports, in Articles 10 and 11. Outside that regime, ask for a written timeline that separates preparation, active testing, detection review and reporting, because each phase has different effort. Scope size, the number of scenarios, the level of threat intelligence required and how many purple teaming sessions follow will move the schedule most.
What does a red team test cost and what drives the quote?
A quote follows from the written scope, and DeployOpen does not publish a price list. The main cost components are the testers' time, threat intelligence research, engagement management, the control team's effort, and reporting and closure work. Costs rise with the number of objectives, the number of in-scope systems and locations, the need for social engineering or physical testing, the depth of the threat profile, and any regulatory reporting requirements. Costs fall when objectives are narrow, rules of engagement are settled early and the client's systems are documented. Ask for each component priced separately, the assumptions behind it and what would trigger a change order.
Can our own security team run a red team exercise without outside help?
Some organizations build internal capability, but a red team needs covert operations, a neutral control team and an independent view of detection gaps, which is hard to keep objective in-house. Where a regulator sets requirements, the tester profile matters: DORA TLPT testers must have specific expertise in threat intelligence, penetration testing and red team testing, and Delegated Regulation (EU) 2025/1190 Article 7 requires a red team manager with at least 5 years' experience plus at least two testers with 2 years each. A common middle path is an external exercise to benchmark the team, followed by internal exercises. Confirm with your regulator or customer whether they accept internal testers.
What must our organization provide before a red team test starts?
The most important inputs are a named sponsor with senior management approval, a small control team that knows the test is running, and written rules of engagement. Covert testing under NIST SP 800-115 is performed without the IT staff's knowledge but with upper management's permission, and it usually stops at defined boundaries such as a level of access. You will also need a list of systems and third parties in scope, emergency contacts, safe-stop criteria, data handling terms, and any provider rules that apply to your cloud accounts. AWS requires a simulated events request at least 2 weeks in advance for red, blue or purple team testing, so check each provider's testing policy early.
How does a red team test differ from a penetration test and a purple team exercise?
A penetration test aims to find and validate as many weaknesses as possible within a defined scope, while a red team test is objective-based and covert, and it measures whether an emulated adversary can reach a goal and whether the organization detects and responds. A purple team exercise is collaborative: testers run ATT&CK techniques alongside the blue team to confirm what is logged, detected and alerted, then tune detections. In practice, many programmes sequence them, using purple teaming to fix detections before or after a red team. The MITRE ATT&CK Enterprise matrix, with its 15 tactics, is a common way to plan and report all three.
How does retesting work after a red team engagement?
Retesting checks whether the remediations you agreed actually changed the outcome. CIS Controls v8.1 Safeguard 18.4 asks for security measures to be validated after each penetration test, with rulesets and capabilities modified where needed to detect the techniques used. For a threat-led test, the TIBER-EU closure includes red and blue team reports, a replay, purple teaming, a test summary report and a remediation plan, and tests produce no pass or fail result. Ask in advance whether retesting is included, which techniques will be replayed, and how the outcome will be documented for your auditor or customer.
Does a red team report serve our auditor or regulator?
A red team report documents the objectives, the techniques used, what was detected and what was not, and the remediation plan. It supports compliance evidence but does not replace an independent assessment. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that. Ask your assessor early which report sections they need and whether the threat-led framework you follow requires a specific attestation.
How DeployOpen scopes, tests, reports and retests red team engagements
Every DeployOpen red team engagement starts with a written scope agreed before any testing begins. The scope document names the objectives, the systems and people in play, the start and end dates, the access level at which the team must stop, and the actions that are off limits. For a red team, the stop conditions and the list of excluded systems matter as much as the objectives, because they define what the exercise may touch in your live production environment. Ask for the rules of engagement to be signed by a senior sponsor and to name a single point of contact who can halt the work. Where a third-party platform hosts your assets, confirm the provider's testing policy applies, since AWS and Microsoft each publish rules that require advance notice or prohibit certain activity. DeployOpen plans and fixes the scope in writing, and quotes follow from that scope rather than from a standard price list.
During the exercise, a control team of a small number of your staff holds the knowledge needed to keep the test safe and interpretable. This group, which TIBER-EU now calls the Control Team, approves the threat intelligence scenarios, tracks what the red team has done, and can stop activity that threatens service availability. Agree in advance who sits on it, how they are reached out of hours, and how they will record each action so the blue team's detections can be matched to the red team's activity afterwards. DeployOpen's testers work to these agreed boundaries and report progress to the control team on a schedule set in the scope. Where a regulator or framework requires specific testing standards, such as those under DORA, confirm the required tester qualifications and the minimum duration with the regulator or the auditor before signing.
Reporting and retesting are where the value of the exercise is realized. Expect a report that explains each attack path in terms of the tactics and techniques used, mapped to the MITRE ATT&CK Enterprise matrix, with the detection and response outcome for each step. Ask whether the report includes a remediation plan with owners and dates, and whether a purple teaming session is included to tune detections against the techniques used, as CIS Control 18.4 expects. DeployOpen prepares this evidence for your internal review and for compliance assessments, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work. Where you need to confirm that fixes work, retesting can be scoped as a separate engagement or as part of a retainer for continuous testing, which DeployOpen offers as ongoing support. As a Chainscore Labs company, DeployOpen also runs application, cloud, infrastructure and AI and agent security testing, so a red team can be combined with those tests when your scope calls for it.
