# How should we run a proof of concept for a prevention tool?

**Short answer:** Deploy it alongside your existing stack in a real production environment and compare what each tool sees. The most informative result isn't a lab test — it's the gap between what your current tools alert on and what actually gets intercepted.

## Why deploying alongside works best

The financial services firm in our best-documented case did exactly this. They didn't remove anything. They added Cyber Crucible specifically to find out what their existing investment was missing, and had a definitive answer within 60 days.

## What to measure

- **Interceptions your current stack never alerted on.** This is the core signal.
- **Time to decision.** Prevention has to complete before damage, not before a ticket is closed.
- **Business disruption.** Count downtime, reboots, and false-positive-driven interruptions.
- **Analyst hours consumed.** Autonomous prevention should reduce workload, not add a queue.

## A caution about lab testing

Testing against samples pulled from malware databases often measures very little, because attackers design malware to stay dormant unless it receives a validation signal from a live command-and-control server they still operate. A sample that does nothing in your lab proves nothing about a live attack.