Your controls worked last quarter. Do they work today? A continuous method to prove every control still blocks, detects and reports, with evidence.
Nov 2, 2026@Melly9 min read
TL;DR
01
A control that worked last quarter is a claim, not a fact. Policy pushes, agent updates and new exclusions break controls without raising an alert.
02
Write every control as a testable assertion, run it on a schedule and on every change, and score four outcomes: prevented, detected, logged only or missed.
03
Further down: control assertions written as code, plus what a drift event looks like when the loop catches one.
Security controls tend to get configured once and trusted for years. Meanwhile, policies change, agents update, rules get tuned and the infrastructure moves underneath them. In this note we treat every control as a set of testable assertions, then build a loop that tests them on a schedule and on every relevant change. What you get is a running measure of control effectiveness, with evidence, that shows drift within hours instead of at the next annual test.
Key findings
ADDRESSABLE BY PATCHING
~10%
Of privilege escalation and credential access techniques. Privilege management covers about 65%, configuration 33%, password policy 30%.
IAAS ADMIN WITHOUT MFA
37%
Of organizations. Only 23% of third parties fully fixed missing or weak MFA on cloud accounts.
SIEM RULES THAT NEVER FIRE
13%
Non-functional detection rules, mostly from misconfigured data sources and missing log fields.
ATT&CK RELEASES IN 2026
v19 + v20
v19 split Defense Evasion into Stealth and Defense Impairment. v20 added AI techniques on 13 Oct 2026.
Controls carry more of your defense than patches do, and they quietly decay. Even the reference model you map them to keeps moving.
A control is not a fact. It is a claim with an expiry date, and the only way to renew it is to test it.
Why point-in-time testing fails
Annual pentests and quarterly audits sample your controls at one moment. The trouble is, controls change far more often than that.
Silent drift
A policy push, an exclusion for a noisy app or an agent version change can disable a protection without any alert.
Coverage holes after change
New cloud accounts, SaaS tenants and subnets often launch before the controls that should cover them.
Configuration debt
Exceptions pile up. Each one is reasonable on its own. Together, they open a path.
Evidence gaps
When a board or regulator asks whether a control works today, most teams can only show that it was deployed.
The continuous control validation loop
Tests run on a cadence and again whenever something changes. That way drift shows up as a failed assertion within hours, not months.
ASSERT → TEST → SCORE → FIX → RETEST
01
Inventory controls by layer, with owners
02
Write assertions each control must hold
03
Map to safe tests and ATT&CK techniques
04
Run on a schedule and on every change event
05
Score one of four outcomes
06
Fix, retest, record, then back to 04
THE FOUR OUTCOMES
PreventedDetectedLogged onlyMissed
The method: six steps to continuous control validation
01
Inventory controls by layer
Email, web and WAF, endpoint, network segmentation, identity, cloud, data loss prevention and detection. Name an owner for each.
02
Write control assertions
Turn each control into testable statements, such as "the WAF blocks SQL injection on every public API route" or "EDR prevents credential dumping from LSASS on all servers."
03
Map assertions to safe tests
Pick non-destructive behaviors that exercise each assertion, mapped to ATT&CK techniques so results roll up into coverage.
04
Run on a schedule and on change
Run the full set on a fixed cadence. Also rerun the affected assertions whenever a change event fires: a policy push, an agent update, a rule change, a new environment or a new threat technique.
05
Score four outcomes
Prevented, detected, logged only or missed. Be strict here: logged only is a failure for a detective control, because nobody acts on a log line.
06
Fix, retest and record
Route each failure to the control owner with the evidence, rerun the same test after the fix and store the result.
Worked example: control assertions as code
Let's write three assertions the way an engineer would actually want to maintain them: in version control, with an owner, a test and the change events that should rerun it.
assertions/endpoint-and-identity.yaml
# assertions/endpoint-and-identity.yaml
- id: EDR-001
control: EDR prevention policy on servers
assertion: Credential dumping from LSASS is blocked on every server
attack_technique: T1003.001
test: safe LSASS handle-open behavior, no memory read
expected: prevented
owner: endpoint-team
rerun_on: [edr_agent_update, edr_policy_change, new_server_image]
- id: IAM-004
control: Conditional access for cloud admins
assertion: Every IaaS admin sign-in requires MFA
attack_technique: T1078.004
test: policy evaluation for each admin principal
expected: prevented
owner: identity-team
rerun_on: [ca_policy_change, new_admin_role]
- id: DET-012
control: SIEM rule for encoded PowerShell
assertion: Encoded PowerShell on a server alerts within 5 minutes
attack_technique: T1059.001
test: tagged, benign encoded command
expected: detected
max_alert_latency_s: 300
owner: detection-engineering
rerun_on: [parser_update, rule_change, log_source_change]
IAM-004 is not hypothetical. The 2026 DBIR found 37% of organizations had an IaaS admin account with MFA disabled. An assertion catches that account the day it appears.
What drift looks like
Here is a run result after an EDR policy push added a performance exclusion for a backup agent's folder.
EDR-001Prevented→Logged onlyDrifted14 of 212 servers
run-result.json
{
"assertion": "EDR-001",
"run": "2026-11-02T03:00:00Z",
"trigger": "edr_policy_change",
"result": "logged_only",
"previous_result": "prevented",
"scope": "14 of 212 servers",
"cause": "new folder exclusion applied to backup tier",
"drift": true
}
Nobody broke anything on purpose. A perfectly reasonable exclusion for a noisy backup agent quietly turned a prevention control into a log line on 14 servers. The change event triggered the rerun, the rerun caught the drift, and the owner had the evidence the same morning.
How to measure the outcome
Five numbers tell you whether the loop is earning its keep.
Assertion pass rate by layer
The share of assertions that pass, shown per layer so weak layers stand out.
Post-compromise prevention rate
Prevention measured only on behaviors that assume an attacker already has access.
Drift events per month
Assertions that passed before and fail now.
Time to detect drift
Hours from the change that broke a control to the failed test that reveals it.
Time to restore
Hours from a failed assertion to a passing retest.
How Hayrok approaches control validation
Hayrok calls this discipline governed continuous security validation (GCSV). Here is how the pieces fit.
Runs safe behaviors from the Scenario Library through a Private Runner inside your network, on schedule and on change, with scope, approval and a kill switch built in.
Stores each result under an Evidence Contract, so a pass means the same thing every time and can be shown to an auditor.
AGIE
Ranks control failures by the attack paths they open, so you fix the gap that exposes a crown jewel before the one that exposes a test server.
This note is the hub of the defense series. The deeper notes on EDR validation, SIEM detection validation and ATT&CK detection coverage go layer by layer.
FAQ
What is continuous security control validation?
It is the practice of testing security controls against safe attack behaviors on a schedule and after every relevant change, then recording whether each control prevented, detected, logged or missed the behavior.
How is control validation different from a penetration test?
A penetration test samples your defenses at one moment. Control validation tests the same assertions repeatedly, so it shows drift and proves fixes.
Which controls should be validated first?
Start with controls that sit on paths to crown jewels: endpoint protection on servers, identity controls on privileged accounts and egress controls on data stores.
How often should controls be validated?
Run a full baseline on a fixed cadence and targeted tests on every change event. Change-triggered tests catch most drift.
Is it safe to run attack behaviors in production?
Yes, with governance: non-destructive behaviors, approved scope, an isolated runner and a full action log.
Find out which controls drifted this month
We will run a baseline across your control layers and show which assertions pass, which drifted and which paths each gap opens.