Your Controls or Your Threats: Where Should Continuous Purple Teaming Begin?

In our previous post we wrote about why security controls drift, why point-in-time testing leaves gaps, and why continuous purple teaming exists as a response to that problem. But where do you start?

"Continuous purple teaming" can sound abstract until you see what it looks like in your own environment. At Offensys we identify two natural entry points, depending on what your organization is trying to solve. One may feel more pressing at the moment. A mature program ultimately uses both, but you have to start somewhere.

Starting from your controls

The first approach is control-driven validation. The starting point is the technical controls your organization already has in place: detection rules, preventive tooling, endpoint protections, hardened configurations. The question it answers is: are those controls working the way they should be?

Controls degrade in ways that are easy to miss. A detection rule gets written for a specific attack pattern, tested once, and then left to run. But environments do not stand still. New tooling gets introduced, configurations change, and the underlying behavior of a system shifts gradually over time. Meanwhile, attackers refine how they execute the same techniques: using different implementations, different in-memory methods, different execution chains. In ways that were not part of the original test scope. A rule that was effective when it was written may be partially blind to the same threat six months later, and nobody noticed because nothing visibly broke.

This is control drift. It is quiet, gradual, and surprisingly common. The only reliable way to catch it is to continuously test your security posture.

The validation loop looks something like this:

1. Select and prioritize the controls you want to validate, based on the business questions you are trying to answer: which controls are most critical, which cover the highest-risk areas, which have not been tested in a while.
2. Design test scenarios that map directly to the logic of those controls, including realistic evasion paths.
3. Execute scenarios in a repeatable, automated way to test how controls actually behave under realistic conditions.
4. Evaluate the outcome: did the control fire as expected, and if not, where exactly did it fall short.
5. Improve the control or configuration, then re-run to confirm the fix holds.
6. Schedule the test scenarios to monitor for regressions over time.

What makes this valuable is steps five and six together. A one-off test tells you where you are today. Rerunning the same scenario after a fix, and continuing to run it on a schedule, gives you regression assurance: confidence that improvements are sustained as the environment keeps changing.

This also matters across different environments. A control that works well in your primary datacenter may behave differently on a cloud workload, a remote endpoint, or a segmented OT network. Validating across those environments gives you a realistic picture of coverage rather than a best-case one.

Control-driven validation is relevant for any team that relies on technical controls, regardless of program maturity. One of the benefits is that it forces you to move past assumptions. Many organizations trust that a well-configured, reputable security product is doing its job, but never actually verify what it blocks, what it misses, and under which conditions. Running controlled simulations gives you that visibility. It turns the security stack from a black box into something measurable.

Starting from the threat

The second approach is threat-driven simulation. The starting point here is not your controls, but the threat landscape relevant to your organization: which adversaries are active in your sector, what their objectives are, and how they typically operate.

This approach tells you how resilient your organization is against the threats that are actually targeting it.

Rather than asking "does this control work," you are asking "if this adversary came after us, what would happen?". The simulation starts from the threat actor and works inward, mapping realistic attack paths across your environment and measuring how your defenses hold up end to end.

The workflow follows a similar structure:

1. Identify and prioritize relevant threats based on your industry, geography, and available threat intelligence.
2. Translate those threats into attack scenarios that reflect real adversary tactics, techniques, and procedures.
3. Execute the scenarios across your environment, emulating adversary behavior while maintaining operational safety.
4. Measure your organization's ability to prevent and detect these attacks, including gaps in visibility and control breakdowns across the kill chain.
5. Feed insights back into your defenses and re-run iteratively to track how resilience improves over time.

Another benefit of continuous simulations is their ability to keep your defenses aligned with changing adversary tradecraft. Threat actors do not stand still: they adjust their techniques, adopt new tooling, and find ways around defenses that worked last quarter. Point-in-time testing gives you a snapshot against a fixed scenario. Continuous simulation, driven by a constantly updated library of adversary behaviors, keeps your testing current as threat actors evolve.

Threat-driven simulation is particularly valuable for organizations that have a developed view of their threat landscape. That said, you do not need mature in-house threat intelligence to get started. Public frameworks like MITRE ATT&CK and continuously updated adversary behavior libraries provide a practical foundation that covers most sectors. The picture becomes more representative as your own threat intelligence matures, while still offering actionable results from the beginning.

Two lenses, one loop

These are not two competing approaches. They are two ways of framing the same underlying capability, each looking at your defenses from a different angle.

Both have their place, and a mature security program should eventually be doing both. Control-driven validation keeps your existing investments sharp. Threat-driven simulation tells you whether those investments add up to meaningful resilience against the people actually trying to get in. The question is not which one is better, it is which one makes sense as your starting point given where you are right now.

What ties them together is the continuous loop: simulate, measure, improve, repeat. That loop is what turns purple teaming from an occasional exercise into an operational capability.

---

If you are trying to determine which option makes the most sense as a starting point for your organization, and how Offensys can simplify the process, we are happy to think it through with you. Request a demo or reach out to me directly on LinkedIn.

Follow Offensys on LinkedIn for our latest thinking on continuous purple teaming and security control validation.