Sources
Every control carries its source. Every source carries its limits.
The control library is derived from governed source material through a recorded, repeatable path. Provenance is held on the record itself: which source, which version, which review state, and how recently it was verified.
Provenance
Why provenance matters
An assessment is only as defensible as the record behind it. When one is challenged, the argument is rarely about the conclusion. It is about where the requirement came from, whether that version is still current, and who agreed the mapping. A control library that cannot answer those questions turns every review into archaeology.
So the answers are stored, not reconstructed. Each control keeps its source, its version, its mapping status and its verification date, and the product reports those separately from whether the control is implemented or how mature it is.
- Which source said this?
- Each control record carries the source it came from, not just the wording that survived the import.
- Which version of it?
- Sources are held with an explicit version and an official reference. A superseded edition stays visible as a superseded edition.
- What state is that mapping in?
- Mapping status is a first-class field. Unreviewed, partial, gap and approved are different answers and are reported differently.
- Who approved it, and when?
- Approval and verification dates sit on the record, so a reviewer can see how old the assurance behind a control actually is.
Derivation
Building the library
The library is not typed up by hand. It is derived from governed workbooks into a versioned library by a repeatable process, which is what makes the result re-derivable and the provenance honest.
- 01
Governed source workbooks
The control register and the applicability matrix are the controlled inputs. Both are read as-is; neither is edited in place to make reconciliation easier.
- 02
Reconciliation with recorded precedence
The two inputs are compared record by record. Where a control exists in both, the register is the primary wording source and the matrix supplies ownership and legacy framework references.
- 03
Sanitized control library
The reconciled result becomes the versioned library the product assesses against. It is re-derivable from its inputs, and the snapshot date is shown rather than implied.
Precedence Where the register and the matrix disagree on wording, the register wins and the disagreement is kept as a review flag. A conflict is never resolved by silently overwriting one source with the other, and records that still need editorial review are marked as such rather than presented as settled.
Each source record holds
- Publisher and official reference
- Version state: draft, preview, effective or historical
- Authority layer and applicability
- Mapping status and verification date
Content packs
Registered by hash
Licensed source packages are registered rather than copied. The product records what the package is and proves which one was inspected, without redistributing the substantive content a licence protects.
Registered
- Artifact name and publisher
- Explicit version and edition
- Page count and structural coverage
- SHA-256 integrity hash per artifact
- Identifier inventories and applicability metadata
- Retrieval and verification date
Excluded by design
- Licensed questionnaire text
- Implementation guidance text
- Auditing guidance text
- Metric descriptions and narrative content
The consequence is deliberate: a reviewer can prove exactly which source package an assessment was built against, down to the integrity hash, while the licensed text stays with its publisher. Structural metadata proves which package was inspected. It does not demonstrate that an internal control satisfies that package objective, that a questionnaire response is adequate, or that a metric has been implemented.
Authority order
The source hierarchy
Not all sources carry the same weight. They are used in a fixed order of authority, and treating a helpful implementation note as if it were a binding requirement is a common way for an assessment to fail review.
CSA Cloud Controls Matrix 4.1 is the primary cloud-completeness crosswalk at the second layer. The complete source inventory, with publisher, official reference, version state, authority layer, mapping status and verification date, is reviewed with you during evaluation rather than summarized as a coverage claim here.
- 01
Applicable law and regulation
Determines the mandatory obligations for the intended use, the data, the geography and the regulated record. Nothing below this layer can override it.
- 02
Independent cloud and security standards
Establishes the reusable management and technical-control baseline. This layer is where the primary completeness crosswalk sits.
- 03
Provider implementation guidance
Translates responsibilities and expected configurations for a specific platform. Useful, and specific, but not independent.
- 04
Provider assurance evidence
Supports supplier qualification for a defined service, region, report period and responsibility boundary. It qualifies a supplier, not your solution.
Review boundaries
Limits of a source
Registering a source proves which material an assessment was built against. These are the things it does not mean.
-
A named source is a reference, not a certification
Registering a source means the product knows which document, which version and which integrity hash it is working from. It does not mean an internal control satisfies that source, and it never constitutes a certification or an audit opinion.
-
Draft, preview, historical and effective sources stay distinct
A source under consultation is recorded as a watch item, not as an effective requirement. A superseded edition remains visible as superseded so that legacy references can be found and remapped rather than quietly carried forward.
-
Unreviewed is a workflow state, not a failure
A mapping disposition is reported as approved coverage only when its review status is approved. The default unreviewed state records that no approved current mapping exists yet; it is not a finding that the control design or its implementation is inadequate.
-
Legacy references are never reported as current coverage
Imported references from earlier framework editions are held separately from approved current-version mappings, and the analytical views keep those two figures apart. Conflicts between sources are retained as review flags rather than silently overwritten.
-
Sources are re-verified on a schedule and on change
Every source link, version and status is reviewed at least annually, and whenever a watched source becomes effective. The verification date travels with the record so nobody has to guess how current it is.
Supplier assurance evidence is recorded, not assumed
A public announcement that an audit took place is not audit evidence. For every certificate, attestation, report or service statement an assessment relies on, the record has to carry the detail that makes it usable.
- Exact provider service and deployment model
- In-scope region and data location
- Report type, auditor, scope, control period and bridge-letter need
- Qualifications, exceptions, subservice organizations and carve-outs
- Complementary customer controls and the shared-responsibility owner
- Tenant configuration evidence that the control is actually enabled
- Version, retrieval date, approval status and reassessment trigger
Taken together these boundaries support governance and validation planning. They are not legal advice, a certification, or a substitute for qualified regulatory and quality review of a specific intended use.
Next step
Review the source inventory
Hold the inventory against your own assurance requirements. The full catalog, including version state and verification dates, is walked through during evaluation.