generated from coulomb/repo-seed
153 lines
5.1 KiB
Markdown
153 lines
5.1 KiB
Markdown
# Compliance Evidence Pack Strategy
|
|
|
|
Status: draft
|
|
Created: 2026-05-07
|
|
|
|
## Purpose
|
|
|
|
Compliance evidence packs cover frameworks where guide-board cannot rely on an
|
|
official executable harness. They help prepare and perform assessments by
|
|
organizing evidence requests, expected artifacts, reviewer workflow, waivers,
|
|
challenges, authority exclusions, and run reports. They do not replace auditors,
|
|
accredited certification bodies, legal counsel, or official standard text.
|
|
|
|
Examples include GDPR, SOC 2, HIPAA, NF Z 42-013, NF 461, ISO 14641, ISO 15489,
|
|
and similar procedural or control-oriented frameworks.
|
|
|
|
## Core Boundary
|
|
|
|
Guide-board should keep four layers separate:
|
|
|
|
- Official source metadata: authority, framework version, source URL, access
|
|
constraints, and citation references.
|
|
- Internal interpretation: locally authored control themes, evidence request
|
|
wording, review roles, and acceptance criteria.
|
|
- Target evidence: artifacts, attestations, screenshots, logs, policy files,
|
|
architecture documents, operational records, and interview notes.
|
|
- Assessment result: normalized evidence, findings, waivers, trend summaries,
|
|
and quality gates.
|
|
|
|
The core may store references to official clauses, controls, or articles, but it
|
|
must not redistribute proprietary standard text. Extension authors are
|
|
responsible for confirming source licensing and citation posture.
|
|
|
|
## Extension Shape
|
|
|
|
Compliance packs are ordinary extensions with `extension_type` set to
|
|
`procedural_evidence` or `hybrid`.
|
|
|
|
Recommended extension layout:
|
|
|
|
```text
|
|
<extension-id>/
|
|
INTENT.md
|
|
extension.json
|
|
evidence-requests/
|
|
<request-set-id>.json
|
|
mappings/
|
|
<mapping-set-id>.json
|
|
profiles/
|
|
reports/
|
|
workplans/
|
|
```
|
|
|
|
The manifest should declare:
|
|
|
|
- framework IDs in `supported_frameworks`,
|
|
- authority IDs in `authorities`,
|
|
- manual or procedural `check_groups`,
|
|
- mapping sets that map request requirement refs to controls or assessment
|
|
themes,
|
|
- a certification boundary that states the pack is preparation support only.
|
|
|
|
## Evidence Request Sets
|
|
|
|
An evidence request set is a reviewable catalog of questions and artifacts. It
|
|
validates against:
|
|
|
|
```text
|
|
docs/schemas/evidence-request-set.schema.json
|
|
```
|
|
|
|
Each request should include:
|
|
|
|
- stable request ID,
|
|
- requirement refs or internal control refs,
|
|
- request type, such as document, interview, configuration sample, operational
|
|
record, attestation, system export, or mixed evidence,
|
|
- requested artifact classes,
|
|
- reviewer roles,
|
|
- acceptance criteria,
|
|
- confidentiality level,
|
|
- renewal or freshness expectations.
|
|
|
|
Requests should be phrased as collection guidance, not as legal conclusions.
|
|
|
|
## Review Policy Records
|
|
|
|
Evidence packs use the same expectation and waiver model as executable
|
|
extensions.
|
|
|
|
Use expectations for:
|
|
|
|
- not-applicable scope boundaries,
|
|
- unsupported-by-design target posture,
|
|
- evidence that is intentionally deferred until a later assessment phase.
|
|
|
|
Use waivers for:
|
|
|
|
- approved exceptions,
|
|
- compensating-control situations,
|
|
- temporary missing evidence,
|
|
- auditor-reviewed deviations.
|
|
|
|
Every waiver should include owner, reason, approval status, and expiry.
|
|
|
|
Use challenges for disputed checks, disputed mappings, imported native result
|
|
questions, or evidence that needs a reviewer decision before it can be treated
|
|
as a defect. Use authority exclusions only when a program, standard, or
|
|
authorized reviewer excludes a requirement or check from the assessment scope.
|
|
Both records should cite stable requirement refs, check refs, evidence refs, or
|
|
authority source refs rather than reproducing restricted standard text.
|
|
|
|
Challenges and exclusions make review state visible; they do not by themselves
|
|
claim compliance or remove default gate-visible unexpected findings.
|
|
|
|
## Framework Notes
|
|
|
|
GDPR packs should emphasize processing inventory, lawful basis records, data
|
|
subject rights, subprocessors, transfer posture, breach response, and privacy
|
|
governance without providing legal advice.
|
|
|
|
SOC 2 packs should organize evidence by trust-service criteria references,
|
|
control ownership, system boundaries, change management, security operations,
|
|
vendor management, and incident response.
|
|
|
|
HIPAA packs should separate administrative, physical, and technical safeguard
|
|
evidence from policy interpretation and should clearly mark protected-health
|
|
information handling constraints.
|
|
|
|
NF Z 42-013, NF 461, ISO 14641, and ISO 15489 packs should focus on records
|
|
management, archival integrity, traceability, retention, reversibility,
|
|
auditability, and governance evidence. Proprietary standard text should be
|
|
referenced only by stable IDs or user-provided licensed material.
|
|
|
|
## Output Model
|
|
|
|
Compliance packs should produce the same guide-board outputs as harness
|
|
extensions:
|
|
|
|
- normalized evidence,
|
|
- findings,
|
|
- review annotations for expectations, waivers, challenges, and exclusions,
|
|
- mapping records,
|
|
- assessment packages,
|
|
- retention summaries,
|
|
- trend summaries,
|
|
- gate summaries.
|
|
|
|
Manual requests can initially result in `manual`, `blocked`, `not_applicable`,
|
|
or `expected_gap` evidence. Later pack-specific runners may import spreadsheets,
|
|
document inventories, ticket exports, cloud configuration snapshots, or auditor
|
|
review files and normalize them into the same evidence model.
|