According to Demetrios Petropoulos, CC, security teams are often asked to perform a strange and contradictory magic trick: raise defenses continuously while keeping availability, customer experience and revenue flows untouched.
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
The hard part isn’t knowing what “good security” looks like, rather it is repeatedly implementing changes in production without turning a web application firewall (WAF) into a traffic blender or a cloud posture into a pile of exceptions. I’ve designed and use my own framework to try and solve this conundrum.
Most security programs don’t fail because teams lack dedication, but because changes arrive as scattered initiatives instead of controlled experiments. I’ve seen new WAF rules ship and accidentally break checkout processes. I’ve seen bot mitigation tweaks successfully boost protection but completely kill SEO rankings. I’ve witnessed API rate limits that successfully stopped abuse but unfortunately also blocked legitimate customers from accessing services. I’ve also encountered "temporary" allowlists that became permanent technical debt simply because nobody remembered why they were created in the first place.
To me, these are failures of change management rather than tool failures. I realized the missing ingredient was a repeatable lifecycle that treats security changes exactly like engineering changes: scoped, tested, observable, reversible, and continuously improved. That realization led me to develop my framework, which I call DAVE+R: Define, Architect, Validate, Execute, Refine.
The idea behind DAVE+R is that it is a practical, auditable lifecycle that helps to expand security controls safely and measurably – especially at the edge (CDN/WAF/API protection), in cloud environments and in abuse/fraud-heavy systems. I made it intentionally vendor-neutral: it’s just my way of thinking and operating (and this is not a product pitch). But I’d like to share how I apply my framework in my daily work, whether I’m tightening API security, rolling out bot controls, hardening authentication flows, or trying to accelerate security without accelerating outages, in case others should find it helpful.
How I Apply My DAVE+R Lifecycle
I structured DAVE+R into five distinct stages. Its success depends on the strict discipline of executing these stages in order, every single time.
Define
I always begin by clearly defining the exact problem to be solved. This is the stage when some teams feel they’re moving too slowly, but I find it’s where we stop being vague and start being precise. In the Define stage, I explicitly state the threat or risk we’re preventing, such as credential stuffing, API scraping, or data exfiltration. I then identify the strict business constraints by answering what absolutely must not break, like checkout conversions, partner integrations, or API latency. Next, I map out the exact scope, determining which applications, endpoints, or user populations are affected. Finally, I establish clear success metrics to show exactly what will move if the change succeeds.
I purposefully make a practical definition sound a bit boring. For instance: my goal might be to “Reduce automated login abuse on a specific authentication path by 60%, while maintaining a human login success rate above 98% and keeping median latency under 200 milliseconds”. That approach gives me something rare in security: a measurable ‘win condition’ anchored in business reality.
Architect
Next, I design the control like an engineer, rather than relying on guesswork. In the Architect phase, I decide on the specific mechanism, whether that is WAF rule logic, rate limiting, bot management, or API schema validation. I establish strict blast-radius controls to determine if the change can be safely deployed per path, per country, or in a report-only mode. I also map out a concrete reversibility plan, noting exactly how fast a rollback can be executed and who is responsible for initiating it. Finally, I set up observability by defining the logs, metrics, and dashboards that will prove the system is working – or failing – in real time.
I find that a solid architecture prevents "silent failures", i.e., situations in which the security team feels safer because they implemented a new rule, but actually the system is degrading in unmeasured ways.
Validate
In the Validate stage, I turn my architecture into concrete evidence before the customers are the ones testing it. I do this by establishing baselines so I know our current normal for error rates, bot traffic and false positives. Whenever possible, I rely on staging environments or shadow testing. I start with canary deployments, routing only a small slice of traffic through the new controls. I heavily utilize report-only modes to measure the real-world impact before actual enforcement, and I conduct adversarial testing by simulating the exact abuse I am trying to stop, rather than just verifying the happy paths.
For me, validation isn’t about achieving perfection; it is about gaining enough certainty to proceed without gambling with production stability.
Execute
When it is time to deploy, I handle execution as a strictly controlled operation, relying on governance instead of intuition. I document exactly what is changing, why it’s changing and who approved it. I bind deployments to specific time windows when monitoring coverage is high and response capacity is available. During deployment, I measure against the predefined success metrics, rather than just staring at security counters.
Crucially, I ensure the change is entirely reversible. In my process, a rollback is not a theoretical document hidden in a wiki; it is a literal button I can press immediately. I firmly believe one of the most underrated security skills is knowing when to abort. DAVE+R makes that decision objective: if my defined guardrails are exceeded, I instantly roll back or dial down enforcement without debate.
Refine
The final stage, Refine, is how I prevent yesterday’s quick fix from becoming tomorrow’s technical debt. Once a change is live and stable, I review the metrics against my original win condition. I actively classify false positives and negatives to update my rules accordingly. I systematically reduce exceptions and temporary allowlists by replacing them with precise logic. I also update my documentation so that any future changes start from a baseline of truth rather than organizational folklore.
These learnings feed directly into my next Define stage. Refining is how I make the overall system more resilient over time, leading to fewer manual interventions, cleaner policies, better automation, and clearer ownership.
Case Study: Rolling Out API Abuse Protection
Here is how I applied the framework recently. I supported a major global retailer during the migration of their massive infrastructure from one edge provider to another. Due to the scale of the migration, rolling out API abuse protection on their highly targeted public endpoints required extreme caution, as they were facing aggressive scraping and credential stuffing. Here is how I approached it using DAVE+R:
- During the Define stage, my specific goal was to reduce abusive scraping requests by 70%. My strict guardrails were to keep the legitimate API error rate under 0.5% and to completely avoid breaking essential partner integrations. I scoped this exclusively to a specific set of profile and search endpoints.
- Moving to Architect, I designed a solution using rate limiting based on token and IP reputation signals, and added schema validation to enforce the request shape. I planned a staged enforcement pipeline, moving from monitoring to soft blocks and finally to hard blocks.
- In the Validate stage, I established baseline metrics for request volume, latency and partner traffic. I ran the new rules in monitoring mode first, then executed a canary enforcement on a small slice of regional traffic. I also simulated scraper behavior to confirm my detection logic worked as intended before affecting real users.
- For the Execute phase, I deployed the rules during a fully staffed window. I watched my business guardrails closely, rather than just the security blocks. I had clear criteria established: if error rates spiked or partner traffic dropped, I would roll back instantly.
- Finally, in the Refine stage, I tuned my thresholds based on the partner traffic patterns I observed in production. I replaced broad allowlists with highly targeted conditions and I documented the final policy logic so future engineers wouldn't be flying blind.
This wasn't a hopeful tweak; DAVE+R enabled an engineered release that successfully protected the client without disrupting its business. I consider DAVE+R as ‘change management with teeth’. I designed it specifically for security controls that sit on production traffic.
Closing Thoughts
The universe is messy. Threats evolve, systems sprawl and traffic is full of strange edge cases. I consider that normal, so my goal has never been to build a perfect wall; my goal is to continuously improve defenses without breaking the systems that pay the bills. But the processes involved in doing so shouldn’t be messy. For me, DAVE+R is the simple loop that makes this possible: I can define clearly, design deliberately, validate honestly, execute safely, and refine relentlessly.
My framework also operates based on three realities I face daily. First, security controls are probabilistic. They reduce risk, but they don’t eliminate it, which means I rely on measurement and iteration rather than one-and-done deployments. Second, false positives are outages in disguise; I treat a blocked legitimate customer as a real incident, even if the SOC dashboard looks completely calm. Finally, attackers adapt. If I’m not continually refining, my controls age, sometimes faster than the patch cycle.
DAVE+R keeps my security improvements moving, without turning every change into a fire drill. If you find yourself facing similar challenges with scaling security safely in production, I invite you to consider it as a means of meeting those challenges.
Demetrios Petropoulos, CC, has over 10 years of experience in cloud security, compliance frameworks, and operational resilience. He has held technical and advisory roles, with responsibility for cloud security architecture, policy design and ZTNA implementations. His cybersecurity work spans cross-functional collaboration, zero trust principles, integrating security across development and operations.
