A programme is usually not ready when it lacks a baseline vulnerability picture, a functioning SIEM, or a responsive incident team. In that state, a red team will mostly confirm poor hygiene and weak visibility. The right next step is to stabilise preventive controls and monitoring before trying to measure sophisticated attacker handling.
How to tell the programme is still in hygiene mode, not red-team mode
The clearest sign is that the programme still cannot answer basic questions about current exposure. If you do not have a recent vulnerability baseline, reliable asset coverage, and a stable monitoring stack, a red team exercise will mostly prove that gaps already exist rather than test how well the organisation handles an informed adversary.
That readiness problem usually shows up as uncertainty about what is in scope, what is patched, what is internet-facing, and what the security tools can actually see. When those fundamentals are missing, the exercise becomes a discovery event instead of a resilience test, which is a poor use of effort and a misleading success criterion.
A programme can be superficially busy and still not be ready if it has not yet operationalised detection and response. A functioning SIEM is not just a reporting platform, it is the control point that lets a red team validate whether telemetry exists, whether alerts are tuned, and whether responders can interpret signal in time to act. That monitoring question is part of the same control chain that underpins NIST Cybersecurity Framework 2.0 and ISO/IEC 27002:2022 Information Security Controls.
Why weak incident response makes the test unfair
Readiness is also about whether the organisation can absorb and investigate an attack path once it is observed. If the incident team is slow to triage, unclear on ownership, or unable to preserve evidence, the exercise stops measuring real defensive maturity and starts measuring organisational confusion. In that situation, the team may miss whether the red team was detected, contained, or attributed correctly.
The practical marker is not whether an incident plan exists on paper, but whether the response loop is exercised enough to handle an intrusion-like event under time pressure. If your responders still need ad hoc interpretation from the red team to understand what happened, they are not yet ready to use the exercise as a meaningful control test. For programme design, that is the point at which you should stabilise NIST SP 800-53 Rev 5 Security and Privacy Controls around audit, incident handling, and configuration management before expanding scope.
A mature programme can explain what it expects to detect, who will investigate, and what evidence will support the result. An immature programme cannot yet do that consistently, so the red team result becomes too easy to dismiss as a tooling problem or a process problem after the fact.
What to fix before you spend on adversary emulation
The right order is to strengthen preventive controls, visibility, and response readiness before attempting sophisticated emulation. If baseline scanning, log collection, alert routing, and ownership are still unstable, the exercise should be deferred or reduced in scope. That is not a failure of ambition, it is a sign that the programme has not yet earned a realistic test of attack handling.
The fastest way to judge readiness is to ask whether the programme can produce three things on demand: a current exposure view, a live detection path, and a staffed response path. If any one of those is missing, the red team will mainly validate the absence of control rather than the quality of control operation. For programmes that need a clearer operational benchmark, a control-led assessment path such as an ISO/IEC 27002:2022 Information Security Controls review can be a better precursor than an adversary exercise.
Practitioners often underestimate how often red teaming exposes governance gaps rather than technical gaps. The exercise can only test resilience when the organisation already knows its assets, can see meaningful events, and can respond without improvisation.
Risk and Threat Considerations
When a programme is not ready, the main risk is not that the red team will “fail” in an abstract sense, it is that the exercise will generate false confidence or misleading noise. Weak visibility can make a real attack path look trivial to simulate, while weak response capability can make the organisation appear more mature than it is because nobody notices or escalates what happened.
Failure mechanism: Incomplete vulnerability coverage, immature monitoring, and underdeveloped incident handling break the chain between exposure, detection, and containment. The red team then exercises gaps in housekeeping rather than the organisation’s ability to detect, investigate, and respond to hostile activity.
Impact: Leadership may overestimate defensive readiness, while real adversary activity can still move through the environment with little resistance. The organisation also risks wasting specialist effort on a test that cannot produce a reliable maturity signal.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | Continuous monitoring is central to knowing whether red-team activity is visible. |
| RS.CO-01 — Personnel Know Their Roles and Order of Operations When a Response Is Needed | Readiness depends on a response team that can act without confusion. | |
| Recommendation — Validate that telemetry and alerting can detect meaningful security events before running an exercise. Define and rehearse who triages, escalates, and coordinates during an attack simulation. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Red teaming needs logs that are reviewed and usable for investigation. |
| IR-4 — Incident Handling | A responsive incident team is a direct readiness prerequisite for red-team testing. | |
| Recommendation — Ensure logs are reviewed and actionable before using adversary emulation to test detection. Exercise incident handling processes until the team can contain and document events predictably. | ||
| ISO/IEC 27001:2022 | A.8.16 — Monitoring activities | Monitoring maturity determines whether the programme can observe adversary behaviour. |
| Recommendation — Confirm monitoring coverage and escalation paths are operating before expanding to red teaming. | ||
Practitioner Guidance
What to verify: Before approving a red team engagement, verify that the organisation can name the current exposure baseline, show live telemetry that reaches the SIEM, and demonstrate a response path with clear ownership. If any of those cannot be shown in a tabletop or dry run, postpone the exercise or narrow it to a limited validation scope.
Decision rule: If the goal is to measure attacker handling, the programme must first be able to detect and triage ordinary security events; if it cannot, treat the current phase as control stabilisation rather than red-team readiness. That keeps the exercise from becoming a test of organisational confusion instead of a test of resilience.
Practitioner takeaway: A red team is most useful only after the basics are reliable, because the value comes from measuring response quality against realistic pressure, not from rediscovering that the organisation still lacks visibility.
Related resources from NHI Mgmt Group
- What are the signs that a data security programme is not ready for agentic AI?
- What are the signs that a product security programme is not ready for CRA compliance?
- How should security teams combine model scanning and AI red teaming in an AI security programme?
- What are the signs that a security programme is not ready for adversary pressure?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org