Skip to content
PracticalHandbooksSoftware Handbooks
Library

Cybersecurity Engineering Handbook / Chapter 67

Control-to-Evidence Matrix Template

Connect a scoped security requirement to its implementation, verification, operating evidence, ownership, exceptions, and defensible assurance answer.

The preceding appendix repaired a detection that confused API admission with final worker authorization. The corrected rule is useful evidence, but it does not by itself prove the larger control: a duplicate export job must be rejected before it reads customer data or creates an archive.

That claim crosses code, policy, tests, release identity, production events, and response records. A control-to-evidence matrix keeps those links visible. It should let an engineer find the enforcement point, let a reviewer challenge the check, and let an assurance owner answer only for the system, version, and period the evidence actually covers.

Control-to-evidence matrix pipeline showing control requirement, implementation artifact, automated check, evidence record, and audit or customer answer, with example rows for authorization, secrets, and recovery.
Evidence is easiest to trust when normal engineering work produces it as controls are implemented, checked, and reviewed.

Keep two views of the same record

Use the matrix as an index when reviewers need to compare many controls across the same attributes. Keep the supporting detail in one record per control-system relationship. A ten-column spreadsheet filled with sentences is hard to review, hard to read on a small screen, and easy to keep superficially complete while its links decay.

Create a separate row when the same requirement has a different enforcement point, owner, verification method, evidence lifetime, or exception rule in another system. Combine systems only when the shared evidence really supports the same claim for all of them.

The compact index is deliberately a matrix:

Control and scope Implementation Verification and evidence Cadence and owner Exception and assurance
<ID>
<system, environment, boundary>		 <versioned enforcement artifact> <repeatable check>
<durable evidence record>		 <trigger or interval>
<accountable role>		 <rule and authority>
<approved answer or status>

Each cell should link to a stable record or exact artifact version, not a tool home page. The row is a retrieval path, not the evidence itself.

The control evidence record

Use this record behind each matrix row. Delete fields that truly do not apply; do not leave ambiguity hidden behind blanks.

# Control Evidence Record: <stable ID and short name>

## Claim and scope
- Requirement: <one behavior that can be challenged>
- System, component, environment, and trust boundary:
- Protected asset or action:
- In scope:
- Explicitly out of scope:
- Related requirement, threat, decision, detection, and runbook:

## Implementation
- Authoritative enforcement point:
- Versioned code, policy, configuration, infrastructure, or procedure:
- Release identity binding: <commit, artifact digest, policy/config version>
- Dependencies and safe behavior when they fail:

## Verification
### <check ID and name>
- Method and frequency or trigger:
- Positive, negative, boundary, and failure cases:
- Candidate, environment, and configuration tested:
- Expected result and acceptance condition:
- Latest result and durable record:
- Coverage proved:
- Coverage not proved:

## Operating evidence
- Events, reviews, drills, or observations:
- Required system, version, time, actor, result, and correlation fields:
- Source health, sampling, delay, and known gaps:
- Evidence location, index entry, and integrity protection:
- Sensitivity, access, retention, retrieval test, and deletion rule:

## Ownership and freshness
- Control owner:
- Evidence-source and index owners:
- Review cadence:
- Refresh triggers:
- Stale-evidence behavior and escalation:

## Exceptions and residual risk
- Exception rule: No | Time-bound | Named authority required | Not applicable
- Required approver, scope, reason, start, expiry, and remediation:
- Compensating prevention, detection, containment, and evidence:
- Residual risk and prohibited conditions:

## Assurance answer
- Question and requested scope:
- Answer supported by this record:
- Evidence version and review date:
- Qualification or excluded scope:
- Disclosure level and approved supporting material:
- Response owner, recipient, agreement, and refresh trigger:

## Change history
- <date, change, reviewer, evidence impact, next action>

The requirement should name a behavior, not a security category. “The platform uses authorization” cannot be disproved. “A worker rejects a duplicate export job before source-data read or archive creation” gives reviewers a state transition, enforcement boundary, and observable failure.

Implementation and evidence are different. Code and policy say what should happen. A test says what happened for a named candidate under stated conditions. A deployment record connects that candidate to an environment. Production events show particular decisions over time. None should borrow the authority of the others.

A worked record for duplicate export rejection

The following record is illustrative. Its identifiers, versions, dates, and results show how the template works; they are not claims about a real service.

# Control Evidence Record: JOB-REPLAY-003 — reject duplicate export execution

## Claim and scope
- Requirement: The Customer Export Service must reject a duplicate job before
  source-data read or archive creation.
- Scope: production worker evaluation for all regions and tenants; API
  admission is in scope only as the start of the decision chain.
- Protected action: customer-data read and export-archive creation.
- Out of scope: misuse of a distinct valid job by an already authorized actor.
- Related records: ADR-EXP-012, DET-JOB-REPLAY-004, RB-EXPORT-REPLAY-002.

## Implementation
- Enforcement point: the worker's final replay and tenant-authorization gate,
  before either source-data access or archive allocation.
- Artifacts: worker replay policy version 19 and its versioned state-machine
  implementation; API admission is not an enforcement artifact for this claim.
- Release binding: source commit, immutable worker image digest, replay policy
  version, event schema 12, and deployment record RELEASE-EXP-2026-07-18.
- Failure behavior: unavailable or conflicting replay state denies execution
  and opens a coverage-degraded case; it does not fall back to API admission.

## Verification
### FX-004 — replay state and boundary fixtures
- Trigger: every change to the worker, replay store, policy, event schema, or
  archive path; required for each release candidate.
- Cases: first execution, duplicate admission then rejection, final duplicate
  authorization, read after duplicate, archive after duplicate, replay-store
  timeout, late and reordered decisions, and tenant mismatch.
- Candidate: the exact image and policy versions named by the release record.
- Acceptance: every duplicate is rejected before read or archive; every unsafe
  execution and evidence-source failure produces its specified case.
- Latest result: passed for the illustrative release; retained as FX-004-R19.
- Proves: expected behavior for the named candidate and fixture boundaries.
- Does not prove: exhaustive resistance to unknown bypasses or continued
  production behavior after release.

### E2E-019 — production canary
- Cadence: quarterly and after a material replay or queue-path change.
- Method: a dedicated canary tenant submits a duplicate with no customer
  source; an observer stops the exercise on any unexpected read.
- Acceptance: worker rejection precedes read, no archive exists, preserved
  events contain the expected identities and versions, and the deliberately
  injected unsafe-decision fixture reaches both response owners within two
  minutes.
- Latest result: 2026-07-18; record E2E-019-R19.
- Limit: proves the canary and response paths at that time, not every tenant,
  region, replay bypass, or future telemetry state.

## Operating evidence
- Events: final worker decision, replay-record write, source-data read, archive
  creation, deployment, and source-health status joined by tenant, export, job,
  envelope digest, worker revision, and event and ingestion times.
- Detection: DET-JOB-REPLAY-004 distinguishes final authorization from API
  admission and routes missing final decisions as degraded coverage.
- Location: the release evidence index links immutable test exports,
  deployment identity, production canary result, and detection version.
- Health: no sampling for this control scope; source delay and required-field
  completeness travel with each record. A source gap invalidates an
  unqualified operating claim for the affected period.
- Handling: access is restricted because records contain tenant and system
  identifiers. Retention follows the approved assurance and incident period;
  retrieval and expiry are tested by the evidence-index owner.

## Ownership and freshness
- Control owner: Export Security owner.
- Sources: Export SRE owns worker and canary records; Detection Engineering
  owns rule and source-health evidence; Release Engineering owns deployment
  identity; Security Assurance owns the index and disclosure record.
- Review: monthly, at each release, and after changes to replay semantics,
  authorization, queues, event schemas, evidence retention, or response routes.
- Stale behavior: mark the matrix row `evidence stale`, withdraw the reusable
  assurance answer, and route remediation to the control and source owners.

## Exceptions and residual risk
- Rule: no exception may permit duplicate execution for customer data.
- A time-bound telemetry or evidence-retention gap requires the risk owner,
  expiry, compensating source-health monitoring, containment authority,
  remediation, and a qualified assurance answer. It does not change the
  enforcement requirement.
- Residual risk: an unknown replay bypass or missing object instrumentation may
  escape this evidence chain. Tenant authorization, export-volume limits, and
  archive-publication authorization remain independent controls.

## Assurance answer
- Question: Can a duplicate export job read customer data or create a second
  archive in the production service?
- Answer: The worker enforces replay rejection before source-data read or
  archive creation. The named release candidate passed negative and failure
  fixtures, and the production canary verified the rejection and response path
  on 2026-07-18. This record supports that release and test period; it is not a
  claim that every future bypass is impossible.
- Disclosure: a dated assurance summary and sanitized canary result may be
  shared under the applicable agreement. Source code, tenant identifiers,
  detection queries, and incident records remain restricted.
- Refresh: Security Assurance rechecks the answer after each material change,
  evidence gap, failed canary, or control exception.

Begin with the claim and try to break the chain. Can the implementation artifact be tied to the deployed version? Does the check exercise the forbidden state, or merely report nearby activity? Does the operating record carry enough identity and time to support the stated period? Can the source report its own failure, and is that failure visible through an independent route when needed?

Then retrieve the evidence. A durable-looking identifier that resolves to an expired CI page is not durable evidence. A screenshot without system, version, time, scope, and provenance cannot be repaired by a confident assurance answer. If the chain is incomplete, mark the row accordingly, narrow the answer, and repair the generating system.

Review exception language with the same care. Not applicable needs a reason, scope, and reviewer. A time-bound exception needs an owner, authority, expiry, compensating controls, detection, and remediation. A blank cell grants no exception; it records that the team has not decided.

Finally, read the assurance answer against the evidence rather than against the team’s intent. It should name the behavior supported, the system and period in scope, any material qualification, and the disclosure boundary. When one of those changes, the reusable answer becomes stale even if its prose still sounds true.

The matrix is ready when a reviewer can move from claim to enforcement, from enforcement to a repeatable challenge, and from the result to a bounded answer without asking the team to reconstruct the story from memory.