Control to Proof

Purpose

Regulators, auditors, and customers do not accept intent. They require provable implementation.

This document explains how Thinkwerke establishes a traceable path from:

  • Control requirement

  • Technical implementation

  • Verifiable proof

This model applies across audits, tenders, and customer assurance.

—

Why Control Statements Fail Without Proof

Common failures include:

  • Controls described only in policy documents

  • Manual evidence assembled during audits

  • Screenshots without context or ownership

  • Proof that cannot be reproduced later

  • Engineering and compliance working in isolation

These gaps increase risk and reduce credibility.

—

Thinkwerke Control Model

Thinkwerke implements a three-layer model:

  1. Control Definition

  2. Control Implementation

  3. Control Proof

Each layer is explicit and linked.

—

1. Control Definition

Controls are defined using:

  • ISO/IEC 27001 Annex A

  • NIS2 obligations

  • CRA security requirements

  • GDPR principles

  • Customer contractual controls

Each control definition includes:

  • Control objective

  • Scope and applicability

  • Responsible owner

  • Associated systems and services

Controls are technology-agnostic at this layer.

—

2. Control Implementation

Implementation translates control intent into:

  • Cloud configurations

  • CI/CD pipeline stages

  • Security tooling

  • Operational workflows

Examples include:

  • IAM policies enforcing least privilege

  • Pipeline checks enforcing artifact integrity

  • Vulnerability SLAs enforced via workflow automation

  • Logging pipelines producing immutable records

Implementations are owned by engineering teams.

—

3. Control Proof

Proof is machine-generated wherever possible.

Valid proof includes:

  • Pipeline execution logs

  • Tool outputs (SAST, SCA, CSPM, SIEM)

  • Configuration snapshots

  • Workflow records with timestamps

  • Audit trails from ticketing systems

Screenshots are used only as a last resort.

—

Traceability Model

Each control maintains traceability across:

  • Policy reference

  • Implementation location

  • Evidence source

  • Responsible owner

  • Review cadence

This allows rapid validation during audits.

—

Evidence Lifecycle

Evidence is:

  • Generated continuously

  • Collected automatically

  • Versioned and time-bound

  • Reviewed periodically

  • Archived with retention rules

This avoids last-minute evidence creation.

—

Example: Vulnerability Management

Control Vulnerabilities must be identified, assessed, and remediated within defined SLAs.

Implementation - Continuous scanning in CI/CD - Triage workflow in ticketing system - SLA enforcement via automation

Proof - Scan reports - Workflow tickets with timestamps - SLA compliance metrics

—

Applicability to Regulations

The Control-to-Proof model supports:

  • ISO/IEC 27001 audits

  • NIS2 supervisory reviews

  • CRA conformity assessments

  • Customer security reviews

  • Internal governance reporting

The same evidence set is reused across contexts.

—

Engineering Ownership

Engineering teams:

  • Own implementations

  • Do not manually assemble evidence

  • Improve controls through normal delivery work

Compliance teams:

  • Validate mappings

  • Review evidence completeness

  • Interface with auditors

—

Relationship to Other Documents

This document is foundational to:

All evidence artefacts are derived from this model.

—

Key Takeaway

Controls are only credible when proof is continuous, traceable, and owned.

Thinkwerke ensures that proof exists before it is requested.