Who Assures the Assurer? Why Cyber Security Is Rediscovering Independent Testing

Policies, dashboards and self-assessments can tell an organisation what it believes about its security. Increasingly, effective assurance requires something more demanding: evidence that those beliefs can survive independent challenge.

Cyber security has always contained an uncomfortable tension. Organisations design their own controls, implement those controls, collect evidence about them and, in many cases, make the initial judgement about whether they are working. Even where formal external audits take place, much of the underlying assurance process still begins with the organisation describing its own environment and presenting evidence intended to demonstrate that its controls are effective.

There is nothing inherently wrong with that model. Nobody understands an organisation's systems, risks and business processes better than the people operating them, and self-assessment remains an essential part of any mature security programme. The difficulty arises when a description of how a control is supposed to work gradually becomes accepted as evidence that it actually does work.

Recent developments in both cyber security and artificial intelligence provide a useful reminder of that distinction. On 18 September 2026, Anthropic announced a partnership with Accenture to develop an embedded independent evaluation capability for frontier AI. Under the proposed model, evaluators will operate inside the AI company with access comparable to employees, conducting activities including model evaluation, red-teaming, alignment assessment and safeguard testing. Anthropic and Accenture each expect to invest at least $1 billion over five years in building the capability.

Meanwhile, the UK's National Cyber Security Centre is developing its Cyber Adversary Simulation scheme. The September 2026 CyAS standard describes a structured approach to testing whether organisations can prevent, detect and respond to realistic simulated cyber attacks, particularly where organisations operate complex, high-risk or nationally significant services. Rather than asking whether defensive controls exist, adversary simulation deliberately exercises them.

These initiatives address very different technologies and risks, but they reflect the same underlying principle: there comes a point where assurance cannot rely solely on what a system, supplier or organisation says about itself. The assertion has to be capable of being challenged.

The problem with controls that only exist on paper

Consider a relatively straightforward statement: all privileged access requires multi-factor authentication. It might appear in a security policy, be reflected in an architecture document and be confirmed by the identity team. A screenshot from an administration portal may show that an MFA policy exists. Taken together, that might be sufficient to satisfy a basic compliance assessment.

But several different questions have been collapsed into one.

Does the organisation have an MFA policy? Is the technical control configured? Does it apply to every privileged identity? Are emergency accounts excluded? Are service identities involved? Could the policy be bypassed through another authentication path? Was MFA actually invoked when the relevant account authenticated yesterday? Would the control continue to work if somebody deliberately attempted to circumvent it?

The first question concerns control design. The next few concern implementation and operation. The final question concerns resilience under challenge.

They are not the same level of assurance.

The same distinction appears almost everywhere in cyber security. A vulnerability management policy can require critical vulnerabilities to be remediated within 14 days without proving that every relevant asset is actually visible to the vulnerability scanner. An endpoint security standard can mandate malware protection without demonstrating that every device is enrolled, receiving current signatures and reporting correctly. A privileged-access procedure can require separate administrative accounts while an overlooked legacy system continues to accept ordinary user credentials.

None of these situations necessarily involves dishonesty or poor governance. More often, they emerge because organisations are complicated and because there is a natural tendency to substitute evidence of intention for evidence of operation.

Declared, evidenced and challenged assurance

It is useful to think about assurance in three broad levels.

The first is declared assurance: the organisation states that something happens. There may be a policy, standard, procedure, control description or questionnaire response. Declared assurance is valuable because it establishes intent and accountability, but by itself it tells us relatively little about what is actually happening within the technology environment.

The second is evidenced assurance. Here, the organisation can demonstrate implementation through technical configurations, system records, logs, inventories, tickets, access reviews, vulnerability data or other supporting material. The assessment is no longer based simply on an assertion; there is evidence that can be examined and related back to the requirement.

The third is challenged assurance. Rather than asking only whether evidence appears to show that the control works, somebody attempts to establish whether the assumption survives testing. That challenge might take the form of adversary simulation, penetration testing, configuration interrogation, independent technical verification, sampling, scenario exercises or deliberately searching for contradictory evidence.

This does not mean that every control needs to be attacked continuously or that every assessment needs to become a penetration test. It means that the strength of an assurance conclusion should reflect the quality of the evidence behind it. A policy statement, a configuration export and the result of a realistic technical test may all support the same control, but they provide very different levels of confidence.

The purpose of assurance should not be to prove ourselves right

This distinction matters because traditional compliance exercises can unintentionally encourage confirmation.

If the assessment asks whether endpoint protection is deployed, the organisation naturally looks for evidence showing endpoint protection. If it asks whether privileged access is controlled, the evidence-gathering process looks for the privileged-access policy and relevant configuration. The assessor may be completely independent and professionally sceptical, but the structure of the exercise still begins with a requirement and then searches for evidence supporting it.

A stronger assurance process also asks: what would show that this conclusion is wrong?

If the organisation believes every managed Windows device has endpoint protection, can the asset inventory be compared with the endpoint platform to identify devices that are absent? If all privileged accounts supposedly use MFA, can authentication telemetry identify exceptions? If vulnerabilities are expected to be fixed within a particular period, can remediation evidence be reconciled against the original vulnerability population rather than looking only at completed tickets?

This changes the role of evidence. Instead of being material assembled to support a predetermined answer, evidence becomes a mechanism for testing the answer.

The approach is closely aligned with the purpose of adversary simulation. NCSC describes CyAS as providing end-to-end assurance and evidence of real-world cyber resilience by testing an organisation's ability to prevent, detect and respond to simulated attacks. The scheme's technical standard includes activities such as attempts to evade detection, establish persistence, escalate privilege, move laterally and simulate data exfiltration.

The question is no longer simply whether the defensive capabilities exist. It is what happens when somebody tries to defeat them.

AI governance is exposing the same gap

Artificial intelligence provides an unusually clear contemporary example because adoption is moving faster than many organisations' governance mechanisms.

An EY survey published on 15 September found that 98% of the 202 senior US AI decision-makers surveyed reported having formal AI governance policies. Yet 47% said their organisation had previously not applied its governance process for an urgent AI deployment. Among respondents whose organisations use agentic AI, 26% said their organisation could not detect unauthorised AI agents operating internally. EY also reported that 36% of respondents had experienced an AI incident or failure that caused a materially negative organisational impact.

The interesting part is not simply that organisations sometimes bypass process. That is hardly unique to AI. The important point is the difference between having governance and being able to demonstrate that governance is actually operating.

A board could quite reasonably be told that the organisation has an AI governance policy, an approval process, human-oversight requirements and controls governing autonomous systems. All of those things could be true. They still would not answer whether every deployed agent is known, whether the approval process was followed, whether permissions have changed since approval, whether the agent is operating within its intended boundaries or whether somebody can detect an unauthorised deployment.

Anthropic's decision to pursue embedded independent evaluation illustrates the same principle from another direction. Its proposed evaluators are intended to have unusually deep access and to conduct activities including red-teaming and safeguard testing. The significance is less about the particular corporate arrangement and more about the acknowledgement that important assurance claims benefit from an evaluator capable of seeing enough, and challenging enough, to test them meaningfully.

Independence does not mean starting again

There is, however, a danger of interpreting independent assurance too narrowly. It does not necessarily mean bringing in another team every time a control needs to be assessed and asking them to repeat the entire exercise from the beginning.

A scalable assurance model should instead make conclusions independently testable.

Imagine an assessment concludes that a particular control is achieved with high confidence. Another assessor should be able to understand how that conclusion was reached without relying primarily on the judgement of the person who made it. They should be able to identify the requirement being assessed, determine which systems and assets were in scope, see the evidence that was considered, understand where that evidence originated and establish when it was collected.

They should also be able to see whether different evidence carried different weight. A policy stating that administrators must use MFA does not have the same evidential value as authentication records showing that MFA was actually enforced. A questionnaire answer saying systems are patched regularly does not carry the same weight as vulnerability and endpoint telemetry showing the patch state of the assets concerned.

Most importantly, the reviewer should be able to see the weaknesses in the conclusion. Was evidence missing? Was anything contradictory? Was the population incomplete? Did the assessment rely heavily on an organisation's own assertion? Was there an exception? Has the environment changed since the evidence was collected?

Once those relationships are preserved, independence becomes much more practical. The second assessor does not have to rediscover the entire environment. They can challenge the reasoning and evidence behind the conclusion.

Confidence should come from evidence, not presentation

Cyber security assurance often produces deceptively precise outputs. Controls are marked green, amber or red. Maturity levels are assigned. Percentages are calculated. Dashboards show compliance scores to one decimal place.

Those outputs are useful, but they can hide enormous differences in evidence quality. Two controls might both be labelled achieved, even though one conclusion is supported by current technical telemetry and independent testing while the other is supported primarily by a policy document and an interview.

A mature assurance process should make that distinction visible.

Confidence should increase when multiple independent evidence sources agree, when technical evidence confirms policy assertions, when evidence is current and when testing demonstrates that a control behaves as expected. Confidence should reduce when evidence is old, incomplete, self-declared, contradictory or disconnected from the assets supposedly in scope.

This is not about creating another mathematical score for its own sake. It is about being honest about what the evidence allows us to conclude.

There is an important difference between saying “the control is effective” and saying “the evidence currently available gives us strong grounds to believe the control is effective.” The second statement explicitly acknowledges that assurance is a conclusion drawn from evidence rather than an absolute property of the system.

Continuous assurance must include continuous challenge

This also changes how we should think about continuous assurance.

Connecting directly to platforms such as cloud services, endpoint management systems, vulnerability scanners and identity providers can provide much richer and more current evidence than periodic screenshots or manually assembled audit packs. It allows an organisation to understand changes in its environment much more quickly and reduces reliance on declarations that may have become outdated.

But automation alone does not solve the assurance problem. Continuously collecting information that confirms what we already believe simply allows us to confirm ourselves more frequently.

The more interesting opportunity is to use continuous evidence to search for exceptions and contradictions. Which assets expected to report into the security platform are missing? Which privileged accounts fall outside the expected authentication policy? Which endpoints have drifted from the approved configuration? Which control conclusions are based on evidence that has expired or changed? Where does technical evidence disagree with the recorded assessment?

That is where continuous assurance starts to resemble genuine challenge rather than continuous compliance monitoring.

Assurance should make it easier to discover that we are wrong

The purpose of good cyber security governance is not to create a perfectly green dashboard. Nor is the purpose of an assurance assessment simply to demonstrate that the organisation conforms to a framework.

Its purpose is to improve the quality of decisions made about risk.

That requires evidence, but it also requires the ability to question the conclusions drawn from that evidence. Policies need to be compared with implementation, implementation with operation, and operation — where appropriate — with realistic testing. Independent scrutiny becomes valuable not because an external party is automatically more knowledgeable, but because independence creates permission to challenge assumptions that can otherwise become embedded in the organisation.

The recent focus on independent AI evaluation and the NCSC's continuing development of adversary simulation are therefore part of a broader assurance story. Complex systems increasingly require more than declarations that safeguards exist. Organisations need evidence that safeguards operate, and mature organisations need mechanisms capable of testing whether their confidence in those safeguards is justified.

That leads to a deceptively simple principle.

A mature assurance process should not be designed primarily to prove that the organisation is right. It should be designed to make it possible to discover when the organisation is wrong.

Because the most valuable assurance finding is not always the green control that confirms what everybody already believed.

Sometimes it is the evidence that proves they shouldn't have believed it in the first place.