Hayrok/Resources/Blog/Research Notes

HAYROK LABS RESEARCH NOTE · HL-RN-2026-12 Security assurance

How to prove security controls are actually working.

Deployed is not working. Here is how to prove the difference.

Turn control tests into evidence that holds up with a board, an auditor and a regulator. One evidence chain, packaged three ways.

Jump to the evidence pack ↓ Book an assurance walkthrough

Hayrok Labs Nov 4, 2026 @Melly 9 min read

ONE EVIDENCE CHAIN PROOF, NOT POSTURE

Safe behavior hits the control

test

Result stored and hashed

sha256

PACKAGED FOR

Board

trend + top gaps

Auditor

replayable records

Regulator

policy + proof it runs

RULE A setting can look right while an exclusion makes it useless. Only a test result shows what the control did.

TL;DR

A control that is deployed is not a control that works. In one 2026 study, 97% of organizations had a breach or near miss tied to a misconfigured security tool.

Regulators now ask for the second thing. NIS2 requires procedures to assess whether your measures are effective, and the management body must oversee them.

Further down: an evidence record, a tamper-evident manifest and a framework mapping you can adapt for your next audit.

Most security assurance still rests on attestation: a policy document, a configuration screenshot, a quarterly sign-off. None of these show that a control stops or detects anything today. So let's define proof properly. Proof is a stored result of a safe, repeatable test against a written assertion. Then we package it for the three people who will ask for it: the board wants a trend, the auditor wants a record they can replay, and the regulator wants a policy plus evidence that it runs.

Key findings

BREACH OR NEAR MISS FROM MISCONFIGURATION

97%

Reach Security found nearly every surveyed organization had one tied to a misconfigured security tool in the past year.

REVIEWS VS. TIME TO FIX

6.5× / 8.3d

Teams reviewed tool configurations about 6.5 times a month, yet took 8.3 days on average to fix what they found.

NIS2 EFFECTIVENESS DUTY

Art. 21(2)(f)

Requires procedures to assess whether cybersecurity measures are effective. Article 20 makes the management body oversee them.

DORA THREAT-LED TESTING

Every 3 yrs

Article 26 requires threat-led penetration testing at least every three years for financial entities authorities identify.

IAAS ADMINS WITHOUT MFA

37%

Of organizations had an admin account with MFA disabled on an IaaS service. Basic controls fail quietly.

The question has changed from "do you have the control?" to "show me it works." Only a test result answers it.

Why attestation is not proof

Attestation is not useless. It just answers what you meant to do, not what happened.

It describes intent

A policy says what should happen. It does not show what happened when an attacker behavior hit the control.

It describes configuration

A screenshot shows a setting at one moment. It misses exclusions, scope gaps and the policy push that changed it next week.

It cannot be replayed

An auditor cannot rerun a sign-off. They can rerun a test, or at least inspect its stored inputs and outputs.

It does not trend

A board needs to know whether the program is getting stronger. A yes or no from last quarter cannot tell them.

The method: six steps to provable controls

You do not need three assurance programs. You need one evidence chain, packaged three ways.

BOARD

A trend

Pass rates by layer over time, plus the top open gaps and how fast they closed.

AUDITOR

Raw records

What ran, where, when and the result, hashed so nothing can change unnoticed.

REGULATOR

Policy plus proof

A written procedure for assessing effectiveness, and evidence that it runs.

Define "working" in writing

For each control, write an assertion and the expected outcome, such as "credential dumping from LSASS is prevented on every server." See How to Validate Security Controls Continuously.

Output → assertion with an owner

Test behavior, not settings

Run a safe attack behavior against the control and record what it did. A setting can look right while an exclusion makes it useless.

Output → prevented · detected · logged · missed

Capture tamper-evident evidence

Store who ran the test, what ran, where, when, the control version and the result. Hash each record so any later change is detectable.

Output → hashed record

Trend the results

Effectiveness is a rate over time, not a single pass. Track it per control and per layer.

Output → pass rate by layer

Package by audience

Give the board a trend and the top gaps, the auditor the raw records and the regulator the policy plus proof that it runs.

Output → three views, one source

Close the loop

Every failure needs a fix and a retest record. The retest is the evidence that the gap is gone.

Output → retest record linked to the failure

Worked example: an evidence pack an auditor can replay

Let's build the evidence for one assertion from start to finish.

STEP 1

The evidence record

json · evidence/2026-11-04/iam-004.json

{
  "assertion": "IAM-004: every IaaS admin sign-in requires MFA",
  "test": "policy evaluation for all 41 admin principals",
  "run_id": "2026-11-04T06:00:00Z-iam-004",
  "runner": "private-runner-eu-1",
  "control_version": "ca-policy-rev-118",
  "result": "fail",
  "detail": "2 of 41 admin principals excluded via break-glass group",
  "retest_of": null
}

A failed record is still good evidence. It shows the control is tested and the gap was found. After the fix, a second record with retest_of set shows it closed.

STEP 2

Make it tamper-evident

bash · manifest

# Hash every record from the run and keep the manifest with the evidence
cd evidence/2026-11-04
sha256sum *.json > manifest.sha256

# Months later, the auditor checks nothing changed
sha256sum --check manifest.sha256

STEP 3

Map it to the frameworks you report against

yaml · mapping/iam-004.yaml

assertion: IAM-004
maps_to:
  nis2: "Art. 21(2)(f) effectiveness assessment; Art. 21(2)(j) MFA"
  dora: "Art. 24 digital operational resilience testing"
  iso27001: "Clause 9.1 monitoring, measurement, analysis and evaluation"
  soc2: "CC4.1 ongoing and separate evaluations"
cadence: daily, plus on every conditional access change
owner: identity-team

STEP 4

Write the board line

One control does not belong in a board deck, but its trend does:

BOARD REPORT · IDENTITY LAYER

Identity controls passed 96% of assertions this quarter, up from 88%. One gap, two break-glass admins without MFA, was found on November 4 and closed on November 5.

Every number in that sentence links back to a hashed record. That is the difference between posture and proof.

How to measure the outcome

Five numbers that show whether your assurance runs on evidence or on sign-offs.

Tested control coverage

The share of controls with at least one behavioral assertion running on a schedule.

Assertion pass rate

The share of assertions passing, by layer and over time.

Evidence freshness

Median age of the latest passing record per control. Old evidence is weak evidence.

Gap to retest time

Days from a failed record to a passing retest record.

Audit requests met from stored evidence

The share of evidence requests answered without a new manual exercise.

How Hayrok approaches control assurance

Hayrok produces proof as a by-product of testing, not as a separate exercise.

Genesis

Runs safe behaviors from the Scenario Library through a Private Runner, on a schedule and on change.

Evidence Fabric

Stores each result under an Evidence Contract, which fixes in advance what counts as a pass, so the evidence means the same thing every quarter.

AGIE

Adds context on what each failed control exposes.

Hay Assist

Lets a CISO ask plain questions of the evidence, such as which identity assertions failed this month and whether they were retested.

Sample evidence is available in the Proof Library.

FAQ

How do you prove a security control is working?

Write an assertion of what the control should do, test it with a safe attack behavior, store the result as a tamper-evident record and repeat the test on a schedule and after changes.

What evidence do auditors accept for control effectiveness?

Auditors look for records they can inspect or replay: what was tested, when, how and the result, plus proof that failures were fixed and retested.

Does NIS2 require proof that controls are effective?

NIS2 Article 21(2)(f) requires policies and procedures to assess the effectiveness of cybersecurity risk-management measures, and the management body must oversee them.

Is a penetration test enough to prove controls work?

A penetration test is strong evidence for one moment. Controls change weekly, so continuous behavioral tests are needed to show they still work between tests.

How should control effectiveness be reported to the board?

As a trend: pass rates by control layer over time, the top open gaps and how fast they were closed, each backed by stored evidence.

Show the board proof, not posture

We will test a sample of your controls and produce an evidence pack you can hand to an auditor.

Book an assurance walkthrough → What is governed exposure validation?

At Hayrok Labs we question everything and Validate what matters.