In other articles on our blog, we talk about preparing for a red team engagement and avoiding wasting a red teaming exercise. But what do you do after a red teaming exercise ends?
“Fix whatever the red team recommends?”
It's never quite that simple.
Red teaming exercises can be fantastically valuable investments. Testing your environment and receiving risk-rated recommendations from an experienced team of hackers is one of the most effective methods for building genuine cyber resilience.
However, a report from a red team is still just that - a report. It's not the final goal of a security program. Or a total assessment of your organisation’s cybersecurity posture.
All red team exercises and reports reflect the point in time when the exercise was conducted.
This doesn't mean that red team recommendations are not valid (especially when you work with a red team consultancy that provides recommendations by default). However, red team reports, even with detailed risk ratings, need to be considered carefully in the context of your organisation’s:
- Level of understanding of the red team’s findings.
- Capabilities for remediation.
- Risk tolerance and context surrounding red team recommendations.
In this article, we look at some of the “what’s next” advice our cyber consultancy gives organisations after they receive a red team report.
Quiz the Red Team
Anyone responsible for remediation planning needs to make sure that they fully understand not only what the red team found during the exercise but also how they found it and how that information informed their findings.
After a red teaming exercise, we encourage our clients to:
- Ask clarifying questions. Our team highly recommends that you engage with your provider and don't stop until you fully understand the risks and remediation tasks you're facing.
- Challenge risk ratings. Question the risk ratings provided by the red team for different issues. They might have made assumptions that don’t fit your organisation (we cover this in the next section).
- Consider context and limitations. A red team report is the result of a certain exercise. It is not a complete assessment of your whole organisation. That’s why we always emphasise that a red team report is not exhaustive. A red team test conducted at a different time could yield different results.
Put Red Team Recommendations Into Context
Some red team findings may result in long-term work programs involving third-party vendors, consultants, and contractors, such as EDR/MDR rollouts, network segregation, access control reviews, Active Directory improvements, and incident response enhancements.
Others can be enacted in a few days with your in-house team.
Clearly, the highest risk-rated tasks are top priorities, but where does that risk rating come from?
All the red team's risk ratings need to be interpreted in the context of what an organisation actually does and the operational priorities of the individual business.
→ Risk ratings and recommendations in a red team report can contain some level of assumption or can overlook other compensating controls that they did not encounter.
For recommendations that are simple to enact, like configuration changes, thinking about red team assumptions or context isn’t so important. In these cases, we advise making the recommended changes quickly and then moving on to more complex tasks.
However, understanding the context of a risk rating is important when it comes to recommendations that involve major changes (things like changing organisational processes and/or deploying new controls).
It’s possible that the red team has assessed something to be a high or low risk that may not reflect your organisation’s true business priorities - either right now or as per your future plans.
Furthermore, some red team recommendations, while technically sound, may not align with the broader architecture or operational ecosystem of the organisation.
Red team exercises are inherently a ‘closed box’ assessment, meaning the team does not have full visibility into all systems, dependencies, or long-term architectural plans. As a result, remediation advice should be carefully reviewed in the context of the organisation’s overall design and operational priorities.
→ “Risk” means different things to different organisations or even within different departments/regional offices of the same organisation. And the definition of “risk” is never static, either. For example, when a new regulation covers your sector or your customers, your compliance risk will be different from what it was before that regulation.
Ultimately, you need to get insight into the red team's findings from outside the IT department. For example, compliance and legal teams should have the final say on how data exposure risks are considered in terms of your actual operational reality.
There can be certain non-negotiables within your organisation that the red team might not be explicitly aware of during an exercise.
5 Pieces of Advice for Red Team Remediation Planning
Once the red team's findings are clear, it's time to plan remediation work - a huge topic in itself. However, we wanted to provide you with five steps that we see leading companies take following a red team engagement.
1. Assess your own resources before hiring a consultancy firm
It’s very common for companies to use an external consultancy, such as SECFORCE, to plan or carry out remediation work after a red teaming exercise.
However, we do not recommend rushing to hire a consultancy firm.
Instead, take the time to first map out what your organisation can address internally. You might still end up hiring a consultant, but you can save significant resources by doing capacity and capability mapping beforehand.
2. Use time-based planning to tackle priorities
Use a structured timeline for remediation.
We see organisations typically plan remediation in phases - immediate, short-term, and long-term - often categorised into 0-50 days, 50-100 days, and beyond.
This approach can turn risk-rated recommendations into project plans.
3. Spread the workload with thematic groupings
A big batch of red team results might upend whatever system you currently have for implementing remediation work.
If you have 50 or more findings, you may need to restructure certain areas altogether.
In these cases, we recommend grouping the red team findings and recommendations by theme (e.g., account management, network infrastructure) and then delegating the work involved to the responsible teams.
This stops the whole process from becoming overwhelming and optimises the remediation activity.
4. Look for root cause fixes
In certain cases, reengineering the root cause is more efficient than tackling all the consequences of that root cause.
For example, deploying a new technical control may be the most efficient way to mitigate multiple issues at once, whereas addressing them individually could consume more resources and effort.
In the long run, it may be easier to use a red teaming exercise as a catalyst for major work, such as replacing internal systems vulnerable to lateral movement, rather than implementing new layers of controls or patches that risk becoming redundant or difficult to manage.
5. Plan for change management
Large-scale mitigation work after a red teaming exercise has a high potential to create disruption.
We recommend carefully planning and testing security changes before full implementation. Having rollback options and testing updates in controlled environments can prevent disruptions and unintended consequences.
Many organisations benefit here from using a consultancy like SECFORCE to help design their processes and control change.
One Key Recommendation for What To Do After a Red Teaming Exercise
Treat the report as a starting point for a comprehensive security program, not the end result of one.
SECFORCE’s cybersecurity consultancy team are experts in helping companies go beyond a red team test.
We help organisations assess red teaming results, plan mitigation, and use red teaming to build cyber resilience within their IT systems.
Contact us to learn more.
