They should maintain end-to-end lineage from source system to disclosure, with intermediate transformations, ownership, and approval evidence preserved. That lets auditors reconstruct how SCR, MCR, and SFCR figures were produced and checked, rather than relying on narrative explanations after the fact.
How to evidence Solvency II reporting lineage
Prove the reporting path as a controlled data journey, not as a narrative after the fact. For regulated numbers like SCR, MCR, and SFCR outputs, the useful question is whether an auditor can reconstruct each figure from the source record, see every material transformation, and verify who owned and approved each step.
The strongest evidence is a chain that links source systems, extraction logic, transformation rules, reconciliations, and the final disclosure pack. If any material step is missing, the lineage is incomplete even if the final number is correct.
That means the evidence set should support reproducibility. A reviewer should be able to identify the originating dataset, the reporting date or cut-off, the calculation method, the rule version, and the approval state for the disclosed number.
What auditors expect to see in the lineage pack
Auditors usually look for four things: origin, movement, transformation, and sign-off. Origin shows where the number came from. Movement shows how it moved between systems or files. Transformation shows what changed in calculation or mapping. Sign-off shows who reviewed it and when.
- Source-to-report mapping that ties each disclosed metric back to named upstream systems or registers.
- Transformation evidence that records formulae, business rules, thresholds, exclusions, and overrides.
- Reconciliation evidence showing that intermediate totals were checked against source extracts or control totals.
- Ownership and approval records showing accountable reviewers for each reporting layer.
For many teams, the critical failure is not lack of data but lack of traceability. A spreadsheet can calculate correctly and still fail audit because the team cannot show which extract fed it, which rule changed it, or which person accepted the result.
Why lineage matters for control, not just compliance
Lineage is a control over integrity. It reduces the risk of unnoticed mapping errors, stale inputs, manual overrides, and inconsistent disclosure across reporting cycles. It also shortens audit response time because evidence is already assembled in the form the reviewer needs.
Regulated reporting becomes fragile when teams rely on tribal knowledge. If the only explanation for a reported figure lives in a meeting note or a developer’s memory, the process is not resilient enough for supervisory scrutiny.
Good lineage also supports change control. When a calculation rule, data source, or ownership model changes, the team can compare old and new paths and prove that the reporting output still follows an approved method.
Risk and Threat Considerations
Weak lineage creates audit and reporting exposure because errors can be introduced upstream, transformed silently, or corrected only after disclosure. In regulated reporting, the problem is often not deliberate fraud, but an inability to demonstrate that the number was derived consistently and reviewed under control.
Failure mechanism: Breaks in source-to-disclosure traceability, undocumented transformations, unmanaged spreadsheet logic, or missing approval evidence prevent independent reconstruction of the reported figure.
Impact: Teams may face audit findings, delayed filings, restatements, regulatory challenge, and loss of confidence in the reporting control environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.33 — Protection of records | Solvency II lineage evidence must be retained and protected for audit reconstruction. |
| A.8.15 — Logging | Traceability depends on logs that show data movement, transformation, and review activity. | |
| Recommendation — Protect reporting records so source, transformation, and approval evidence remain available for audit. Log reporting data movement and processing steps so figures can be reconstructed. | ||
| NIST SP 800-53 Rev 5 | AU-3 — Content of Audit Records | Audit records need enough detail to reconstruct how regulated figures were produced. |
| AU-12 — Audit Record Generation | Lineage evidence relies on generating audit records across the reporting workflow. | |
| CM-3 — Configuration Change Control | Reporting formulas and mappings must be controlled so lineage stays reproducible after changes. | |
| Recommendation — Record who changed what, when, and under which rule set for each reporting step. Generate audit records at extraction, transformation, reconciliation, and approval points. Control changes to reporting logic, mappings, and calculation rules before release. | ||
Practitioner Guidance
What to verify: Treat every material reporting number as needing three proofs: the source record, the transformation path, and the approval trail. If you cannot reproduce the number from retained evidence without oral explanation, the lineage is not yet defensible.
What good looks like: The reporting pack should let a reviewer move from disclosure back to source in a few steps, with timestamps, rule versions, reconciliation points, and accountable approvers visible at each handoff.
Common mistake: Teams often preserve final reports and approval emails but not the intermediate logic that explains how the figure was built. That is enough for a narrative, not enough for audit reconstruction.
Practitioner takeaway: For Solvency II, the goal is not just a correct number, but a retraceable one, if the control evidence cannot explain the path from source to disclosure, the reporting process is not fully proven.