Acceptance evidence: Implementation and evidence

Defines traceable acceptance evidence for privacy and compliance requirements, linking each claim to an applicable rule, implemented control, test result, configuration, reviewer, and residual limitation.

Package status: reference context ready for human review. The contract and test scenarios are complete, but no claim is made that an adopting implementation has passed them.

Decision

Accept a requirement only from a versioned evidence bundle that maps its exact scope to implementation and observed results. Separate technical pass, expert review, exception, and production observation; none alone becomes a blanket compliance claim.

Scope

• Requirement identity, applicability, control mapping, implementation references, tests, configuration snapshots, results, exceptions, approvals, and expiry.
• Release and periodic evidence for privacy/security-adjacent product behavior.
• Machine-checkable traceability plus human review.

Outside this block

• Legal certification or proof that no unknown issue exists.
• Screenshots without reproducible state, identity, date, and expected result.

Contract

• Every acceptance claim identifies requirement version, applicability decision, system/release scope, owner, and acceptance criteria.
• Evidence distinguishes design document, code/config reference, automated result, manual observation, and production monitor.
• Test evidence includes fixture, environment, command or procedure, time, result, artifact digest, and relevant redactions.
• Exceptions state affected criteria, compensating control, risk owner, expiry, and remediation link.
• A later release cannot reuse evidence when mapped code, configuration, dependency, policy, or test semantics changed materially.
• Status vocabulary separates not-applicable, not-tested, failed, exception-approved, and passed.

Implementation guidance

• Store a lightweight manifest pointing to protected evidence rather than copying secrets or personal data.
• Generate candidate mappings from repository ownership and CI, then require the responsible reviewer to confirm applicability.
• Sign or protect evidence records from alteration by the same role that implements the control when separation is required.
• Create an impact rule that invalidates evidence on mapped changes.

Failure handling and safeguards

• Missing evidence produces not-tested, never passed.
• A broken or unauthorized evidence link fails verification and triggers renewal.
• Expired exceptions revert the requirement to failed or blocked according to the release policy.

Verification and operations

• Measure requirement coverage, stale/broken evidence, failed criteria, exception count/age, review latency, and escaped control failures.
• Sample evidence for reproducibility and least-sensitive retention.
• Require qualified legal/privacy interpretation for jurisdictional conclusions.

The executable-looking examples in this package are fixtures and acceptance contracts. Run python tools/validate.py from the collection root to check package structure and metadata; then implement and execute the scenarios in the target repository.

Adoption assumptions

• Names and numeric values in example.yaml are an adoption profile, not universal defaults.
• The adopting team must map actors, data classes, error vocabulary, and ownership to its system.

References

• gdpr