GRCLibrary.ai

Outcome Map

How leadership can know, with evidence, whether the controls it relies on are operating

A leadership page from the library's executive layer: it explains the position in plain language, and the corpus documents it cites remain the governing texts.

Read the source on GitHub (opens in a new tab)

Authority disclaimer. This page is an executive narrative. It does not establish requirements; the linked corpus governs. It is provided to support understanding, discussion, and decision-making by the governing body and accountable executive leadership (board, ELT, or senior management, as applicable). It creates no obligation, control, or assurance by itself. Its publication approval is an editorial act only and confers no authority over any corpus document. Where it differs from a corpus document, the corpus document prevails.

§01

Outcome statement

The corpus defines the path that evidence about controls travels. Its document architecture framework sets out a five-step evidence flow running upward from operational execution to governance reporting (its Evidence flow section owns the ordered steps and their contents). This page maps the corpus documents along that flow to a single outcome:

Leadership can state, with evidence, whether the controls it relies on are operating, and can see where assurance itself has gaps.

The first half of the outcome concerns the controls. The second half concerns the assurance over them, which the corpus records separately: the assurance map register records, for each material risk, what assurance is in place and where the gaps are, on a defined rating scale (its Purpose and Section 5). The assembly of the corpus documents below into one chain, and the reading order, are a composite synthesis across the sources this page lists; the limitations say so.

§02

Contribution map

Each row relates one corpus control to the outcome using exactly one of the narrative layer's four relationship words. A contribution materially advances the outcome without being sufficient for it; a dependency is a condition the outcome requires; a prevention reduces the opportunity for a named failure mode; evidence demonstrates that a control exists or operates. No stronger relationship word appears on this page, by design. Where a row's justification is the cited document's own stated purpose or objective, the row paraphrases it closely; the assignment of exactly one word per row is a composite reading, and the limitations carry that caveat.

Corpus controlRelationshipWhat it does for the outcome
Operating records, per the corpus evidence flowdependencyThe framework-owned evidence flow begins with records: procedures and templates create them, and its later steps work with what is already produced (see its Evidence flow section for the ordered steps). The framework's own evidence examples include control assessment results, access reviews, incident records, exception approvals, and deletion attestations.
Control testing, per the control testing procedureevidenceThe procedure's stated purpose is that control testing provides objective evidence that controls are functioning as intended. It tests design effectiveness (its section 2.1: whether the control, if operating as designed, would prevent or detect the associated risk) separately from operating effectiveness (its section 2.2: whether the control has operated consistently during the test period), places testing with a tester who is never the owner or operator of the control, so that the conclusion does not rest on a self-assessment (its roles section), and records each test with its tester and its independent reviewer in the Control Testing Register (its section 7).
The per-control effectiveness metric, defined in the assurance metrics registerpreventionThe metric assigns each in-scope control an effectiveness band from a defined set of inputs, reported at the control's residual-risk testing frequency; use the register's Per-control effectiveness metric section for the calculation inputs, band, and frequency. The register's stated objective names the failure mode it exists to prevent: a control read as effective on the strength of a single point-in-time result while other tracked signals point the other way.
Consumption of the metric across the lines of defence, per the continuous assurance frameworkcontributionThe framework tracks the metric as a performance-evaluation input so that sustained control effectiveness, not only point-in-time test outcomes, feeds the continuous-assurance cycle (its section 4.4), on the lines-of-defence model the assurance map register defines (its Section 1); use the framework's section 4.4 for how each line of defence consumes the metric. The contribution is that sustained control effectiveness enters the continuous-assurance cycle rather than resting on a single test.
The assurance map registercontributionThe register's stated purpose is to record, for each material risk, what assurance is in place and where the gaps are. Each risk area carries a rating on the register's defined scale (its Section 5), and material gaps are reported to the board risk committee in the board risk report (its Section 6).
Reporting to oversight, per the board risk report template and the key risk indicator catalogueevidenceThe board risk report carries the assurance picture in its Section 11 and the board's decisions and noting items in its Section 13; use those sections of the template for their required contents. The KRI catalogue's stated purpose is to provide early warning signals that a risk is increasing or that an existing control is degrading, with defined actions and reporting when a threshold is breached (its KRI reporting and escalation section). The completed report and the escalation records are evidence that the reporting control operates.
A completed audit evidence package assembled using the audit evidence package templateevidenceFor an external audit, a regulator examination, or a customer review (the audit types its cover page names), the package assembles, per control, the documentation that demonstrates the control was implemented and operated as designed during the period: implementation evidence (point-in-time) and operating evidence (over the period), each with a stated verification basis; use the template's per-control section for the evidence axes and the verification-basis values.
The exception and risk-acceptance route, per the exception and risk acceptance management policyevidenceThe policy's stated purpose is to ensure that all deviations from policy, control, or standard requirements are risk assessed, time bound, approved at the appropriate authority level, and tracked to closure (its section 1), and it requires every exception to be documented in the enterprise exception register before the deviation occurs (its section 4.1). Approval escalates by risk level (its section 4.2), duration and renewal carry hard ceilings (its sections 4.3.4 and 4.3.5, where the values live), and every active exception is tracked centrally (its section 4.5); use sections 4.1 to 4.5 for the register fields, approval route, duration, and renewal controls. A documented exception is evidence that a known deviation is under management, risk assessed, time bound, approved, and centrally tracked, rather than unrecorded.
§03

Gaps and dependencies

  • The corpus states the chain's couplings document by document: the continuous assurance framework describes the per-control effectiveness metric as populated from the Control Testing Register (its section 4.4); the assurance metrics register names the metric's data sources (its Per-control effectiveness metric section); and the board risk report template summarizes audit coverage per the assurance map and links the assurance map and the KRI dashboard as appendices (its Sections 11 and 14). The reading of all eight rows as one ordered chain is this page's synthesis, not any single document's statement; the limitations flag it as composite.
  • The corpus separates a control's design from its operation: the control testing procedure tests the two separately (its sections 2.1 and 2.2), and the audit evidence package template records implementation status and operating effectiveness as separate axes of its control inventory index.
  • The assurance map register operates at the risk-area level: its scope states that it does not cover every individual control and that it is supported by the control register. Its linked-controls field expects control identifiers from the adopter's own control register, which the library deliberately does not ship (its Section 2); an adopting organization supplies its own control register for that linkage to operate.
§04

Evidence to request

Each item below is an evidence class leadership can ask management for, for a sampled control. Each is evidence for a named layer of the map operating.

  • A period's operating records for the sampled control, as evidence for the record-producing layer the evidence flow describes.
  • The control's latest operating-effectiveness test result, with its tester and independent reviewer, from the Control Testing Register, as evidence for the testing layer in the control testing procedure.
  • The control's current effectiveness band and its inputs, as evidence for the metric layer in the assurance metrics register.
  • Evidence of how the second and third lines consume the effectiveness bands, as evidence for the lines-of-defence layer in the continuous assurance framework.
  • The current assurance-map rating for the relevant risk area, with its last and next assurance events, as evidence for the assurance-visibility layer in the assurance map register.
  • The assurance section of the latest board risk report, and any threshold-breach escalations in the period, as evidence for the reporting layer in the board risk report template and the key risk indicator catalogue.
  • The latest assembled evidence package for an in-scope framework, with its internal sign-off, as evidence for the external-assurance layer in the audit evidence package template.
  • Any open exception touching the sampled control, with its register fields per the policy's section 4.5, as evidence for the accepted-deviation route in the exception and risk acceptance management policy.
§05

Limitations

  • This page creates no compliance and imposes no requirement. The linked corpus documents govern; where this page differs from a corpus document, the corpus document prevails.
  • This page carries composite claims. The assembly of the listed corpus documents into a single chain, the reading order, the two-part outcome framing, and the assignment of exactly one relationship word per row are synthesized across the sources named above; a control can serve the outcome in more than one way, and the map records the primary relationship. The adopting organization validates that reading against its own control framework and assurance model.
  • The corpus documents this page points to carry the specific values: the result classifications and sampling rules of control testing, the metric's band definitions and escalation triggers, the assurance rating scale, the reporting cadences, and the exception duration and renewal ceilings. This page routes to them and does not reproduce them.
  • Adoption is not presented as effectiveness. Holding the documents this page links, or requesting the artefacts it names, is not evidence that any control operates in an adopting organization; the corpus itself separates design effectiveness from operating effectiveness in the control testing procedure, and only the organization's own records and test results speak to the operating half.
  • The body names on this page (governing body, board risk committee, enterprise risk committee, internal audit, second-line functions) are the corpus's reference vocabulary. The minimum viable governance structure guideline describes how a smaller organization consolidates forums into a leaner structure without losing the underlying accountability.
  • This page makes no claim about the likelihood, occurrence frequency, or magnitude of a control failure, an assurance gap, or an outcome, and none of its statements should be read as a probability; the review and testing cadences it points to are the cited sources' own, routed and not reproduced.

Source

The source

This page is rendered from the version-controlled Markdown file in the corpus repository, with the site's navigation and framing added around it. The Markdown, where its metadata, review record and full history live, is the source. If the two ever differ, the source governs.

Domains

The domains behind it