audit-labs/audit-report

 1# Rulesets — provenance and control-mapping rationale
 2
 3An `audit-report` **ruleset** (`audit_report/rulesets/*.yaml`) turns collected
 4evidence into control-relevant findings: each rule names a table, a check, and the
 5control identifiers the signal is offered as evidence *for*. This document records
 6where those mappings come from and their limits.
 7
 8## What a mapping claims — and does not
 9
10- A rule's `controls` list says: "this signal is relevant to these controls."
11- A **fail** means a setting is in a state that does **not** support the control.
12  It is not a compliance verdict — the auditor still owns the conclusion.
13- The control identifiers (`SOC2:CC6.1`, `ISO:A.5.17`, `NIST:IA-2`, …) are
14  reproduced; the frameworks' normative control text is not. See the catalog
15  provenance in [control-coverage `MAPPING.md`](https://github.com/audit-labs/control-coverage/blob/main/MAPPING.md).
16- The mappings are the **maintainers' interpretation**, not reviewed or endorsed
17  by the AICPA, ISO/IEC, or NIST.
18
19## Framework revisions referenced
20
21- **SOC 2** — Trust Services Criteria 2017 (2022 revised points of focus).
22- **ISO/IEC 27001** — 27001:2022 Annex A.
23- **NIST SP 800-53** — Rev. 5.
24
25## Versioning and traceability
26
27- Each ruleset carries `name` and `version` fields.
28- Every report stamps the tool name + version and the ruleset `name`, `version`,
29  and a **SHA-256 of the ruleset file** into its output (`tool` / `ruleset` in
30  JSON; the header line in Markdown/HTML).
31- An auditor can therefore tie any finding back to the exact ruleset that produced
32  it, and re-perform against it. Bump `version` on any change to a rule's
33  controls, checks, or thresholds.
34
35## Authorship and review
36
37- **Author:** the audit-labs maintainer.
38- **Review status:** maintainer self-review; no independent professional review.
39  Validate a ruleset against your own control set before relying on it.
40- **Effective date:** 2026-08.