Assigning an assumption to the function best placed to test it

The parallel testing organisation you do not want

An architecture team at a mid-sized financial services firm built a validation capability after shipping a cross-domain identity design. Within a year, they were running their own penetration tests, commissioning tabletop exercises, and reviewing audit samples — work that internal audit, the red team, and the control assurance function were already chartered to do. The duplication was not malicious; it was the natural result of nobody else owning the specific question the architects were asking.

When an architecture function cannot identify which existing function will test a given assumption, it tends to absorb the testing itself, which creates a shadow assurance organisation with no formal independence, no standing under professional assurance standards, and no authority to close findings.

The firm’s situation also illustrates a regulatory dimension financial services organisations cannot ignore. DORA’s Threat-Led Penetration Testing (TLPT) framework—and its European precursor, TIBER-EU—exists precisely because regulators concluded that self-assessed, cross-domain assumptions in critical financial infrastructure are insufficient. When an organisation absorbs testing into its own architecture function, it risks failing the external, independent testing mandates required for in-scope entities.

The solution is not to stop asking the question, but to assign each assumption to the function whose existing access, mandate, and methodology can definitively answer it—while remaining explicit about what that function requires from architecture to execute the work. Below, we examine how to establish these assignments in practice and what breaks when they are misallocated.

Which functions already test something adjacent

Most enterprise environments operate at least four assurance functions with standing test authority: internal audit, penetration testing or red team, business continuity and disaster recovery (BCDR), and control assurance. Threat modelling is also common, though its organisational placement varies. Automated continuous validation — chaos engineering, breach-and-attack simulation (BAS), and policy-as-code — is increasingly treated as a standing owner for assumptions about degraded-condition behaviour rather than a one-time exercise mode.

Each function has a natural domain. Internal audit examines whether processes comply with policy and whether controls were operating during a defined period. Penetration testing finds exploitable paths from a defined starting position. BCDR validates whether recovery objectives are achievable under failure conditions. Control assurance tests whether individual controls operated as designed within their own domain.

Automated continuous validation tests whether system behaviour under injected failure or simulated attack matches expected outcomes at a cadence no manual function can match. None of these functions, in their default charter, asks whether a design assumption that spans multiple domains holds under stress. That gap is where architectural assumptions accumulate untested.

Before creating any new test function, an architecture team should map every untested assumption against these domains and ask whether the assumption is truly cross-domain or whether it is actually a control question in disguise.

Matching the assumption to the function's access and mandate

The assignment criterion is not which function is convenient — it is which function has the access required to reach the failure condition, the mandate to act on what it finds, and the independence to make the finding credible.

On independence: NIST SP 800-53 Rev. 5 CA-2(1) defines an independent assessor as one that is not involved in the development, operation, management, or administration of the systems, system components, or services that are assessed (Source: NIST SP 800-53 Rev. 5, https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final).

The operative question is therefore not where a function sits in the organisation chart — red team, control assurance, and BCDR typically report to the CISO or CRO rather than to system owners, and that reporting line does not by itself compromise their independence. The question is whether the function built or currently operates what it is being asked to test. A red team that did not design the identity federation it is probing satisfies the NIST test; an architecture team reviewing its own design does not.

Independence and the ability to act on findings are related but distinct. The IIA Standards for Internal Audit require that internal audit's independence be established through its organisational position and objectivity, and that the function have direct access to report findings to the board or its delegate without management interference (Source: IIA International Standards for the Professional Practice of Internal Auditing).

Other assurance functions — red team, BCDR, control assurance — operate under mandates defined by their sponsors; their authority to escalate findings is bounded by those mandates, not by an equivalent professional standard. When matching an assumption to a function, check both the independence criterion and the escalation path. A function that can observe a failure but cannot escalate it produces evidence without consequence.

One further distinction matters: assurance functions do not remediate findings, and they do not close them. Management owns remediation. Assurance functions validate that remediation has occurred, or escalate when it has not. Describing a function as having "authority to close a finding" is a category error that obscures accountability; the correct framing is whether the function has the mandate to escalate an unremediated finding to a decision-maker who can compel action.

For each assumption on the register, answer two questions. First, which function can reach the failure condition without the assessors having built or operated the component under test? Second, which function has the mandate to escalate what it finds to a decision-maker with authority to compel remediation? If no function answers both, the assumption is unassigned, and the architecture team owns the gap inventory, not the test.

The assumption no existing function will own

This is where the real architectural risk concentrates. Some assumptions are genuinely cross-domain: they require simultaneous observation of identity, network, and application state; they depend on sequencing across trust boundaries; or they only become visible under degraded conditions that no single function routinely tests. These assumptions tend to be the ones that stay on a register for months without a test owner.

NIST SP 800-160 Vol. 1 frames assurance as the grounds for justified confidence that a claim about a system has been or will be achieved (Source: NIST SP 800-160 Vol. 1 Rev. 1, https://csrc.nist.gov/publications/detail/sp/800-160/vol-1-rev-1/final). An assumption that has never been tested provides no such grounds — it is confidence without evidence. The consequence is not abstract: when a cross-domain assumption fails in an incident, the gap in assurance coverage becomes a gap in the incident timeline, because nobody ran the test that would have surfaced the failure mode in advance.

For assumptions that no existing function will own, the architecture team has three options, each with a distinct tradeoff.

Coordinate a joint test. Bring two or more standing functions together under a defined scope. This produces better coverage than any single function can achieve, but requires negotiating authority across reporting lines and agreeing a shared escalation path before the test begins. The exercise mode, sometimes called a purple team engagement, falls into this category — red and blue working together, with control owners participating — but because control owners are involved, the result should be treated as a coordinated exercise rather than an independent assessment; findings carry weight proportional to how clearly the scope and independence constraints are documented.

Hold the assumption on a gap inventory with a defined re-validation trigger. This is honest about the gap but leaves it open. Every gap inventory entry must name a risk owner and carry an expiry date or trigger condition — a design change, a threat intelligence update, or a defined elapsed period — after which the entry is re-evaluated. An entry without a named risk owner and an expiry is not a gap inventory; it is a list of things nobody intends to do.

Commission a purpose-built or automated exercise. This includes chaos engineering scenarios, BAS platform runs, policy-as-code validation, or a tabletop with a temporary test owner holding defined authority for the duration. Automated continuous validation is particularly well suited to degraded-condition assumptions — scenarios where a manual exercise would be impractical to run at the frequency the threat environment demands. The test owner's authority and the mechanism for escalating findings must be agreed before the exercise begins.

The choice depends on the assumption's consequence if it fails, the blast radius it touches, and the realistic availability of test resources. For financial services firms in scope for DORA TLPT, a fourth constraint applies: some cross-domain assumptions about critical functions may require an externally led, regulator-notified test regardless of what internal options are available.

Assumptions about cross-domain trust — whether a policy decision point enforces per-request authorisation consistently across a segmented network under load, for example — often fall into the unassigned category (see NIST SP 800-207 for the relevant policy enforcement architecture; Source: NIST SP 800-207, https://csrc.nist.gov/publications/detail/sp/800-207/final). No standing function owns that question end-to-end. Assigning it to penetration testing alone may not surface it, because the test may succeed at the point of entry but never stress the downstream enforcement path.

A further category of assumption belongs here: those that only the provider can test. Where a design assumption depends on a cloud platform's internal behaviour — cross-availability-zone failover sequencing, for example, or hardware security module behaviour under key exhaustion — no internal function has the access to test it directly. The appropriate assignment is vendor attestation: a formal, time-bounded commitment from the provider, captured as a named artefact on the assumption register. The architecture function is responsible for requesting it, recording it, and flagging when it lapses or when the underlying design changes.

What the architecture function keeps

The architecture function does not run the test. It owns the assumption register, maintains the assignment mapping, defines the conditions under which a test is valid (what starting state, what failure trigger, what observable outcome constitutes a pass), and receives and interprets the result. It does not own the finding's remediation unless the finding is a design defect — in which case, the design authority is the correct owner.

Architecture should also maintain a gap inventory — assumptions with no current test owner — and surface it at the cadence that the validation programme defines. Every entry in that inventory must carry a named risk owner and an expiry or trigger condition. Assumptions without these fields are not documented gaps; they are undisclosed risks. The cadence at which the inventory is reviewed is an engineering and risk judgment, not a value any standard prescribes. What drives it: how fast the threat environment changes, how frequently the underlying design changes, and what the consequence of an untested failure would be.

VEM-VERIFY-002 takes the work only when the question is whether an open finding is reachable. That is a different question from whether a design assumption holds — do not route architectural assumption gaps through exposure verification.

Asking for a test without dictating the method

When architecture assigns an assumption to a test function, it specifies what needs to be true at the end of the test — the condition being validated — not how the function should structure its test. Dictating method to internal audit, red team, or BCDR undermines both the independence of the finding and the function's professional judgement about what will produce reliable evidence.

A useful assignment package contains four elements: the assumption stated as a falsifiable claim, the conditions under which it should hold, the observable evidence that would confirm or refute it, and the access or cooperation the function will need from architecture or system owners to run the test. It does not contain a test plan, a test script, or a preferred outcome. If the architecture team finds itself writing test scripts, it has crossed from assignment into execution — which collapses the independence that makes the finding credible.

Assumption assignment table

The assignment test

Run this against every assumption on the register before closing a validation cycle.

1. Is this a control question or a design question?
If the question is whether a control operated correctly within its own domain, route it to standard control testing. If the question is whether an assumption spanning multiple domains holds under stress, it remains on the architecture register.

2. Which function can reach the failure condition without having built or operated what it is testing?
Name the access required and confirm the function satisfies the NIST SP 800-53 Rev. 5 CA-2(1) independence criterion: not involved in development, operation, management, or administration of the system under assessment. If no standing function qualifies, the assumption is in the gap inventory until access is arranged or the test is commissioned as a purpose-built or automated exercise.

3. Does the assigned function have the mandate to escalate its finding to a decision-maker who can compel remediation?
A function that can observe a failure but cannot escalate it produces evidence without consequence. For internal audit, the IIA Standards define the required escalation path. For other functions, confirm the escalation chain before the test is assigned, not after. Remember that assurance functions validate remediation — they do not remediate and do not close findings unilaterally.

4. Has architecture provided a falsifiable claim, not a test plan?
If the assignment package contains a test script, rewrite it as a condition statement and let the function determine its method.

5. Is the gap inventory current, and does every entry have a named risk owner and an expiry?
Assumptions with no test owner are not failed assumptions — they are known gaps. Documenting them honestly, with a risk owner and a re-validation trigger, is the architecture function's accountability. An entry without these fields is an undisclosed risk.

Sources