Skip to content

Nextera Guard modules

Nextera Guard has six modules. The control library is the foundation; the other five all operate on what it holds.

If any term here is unfamiliar, read Internal control concepts first — this page assumes it.

Hold every financial-reporting control in one place, mapped to the risks and processes it covers.

Purpose. The risk-and-control matrix made durable. Every control, with its risk, its process, the assertion it addresses, its owner, its frequency, and its key/non-key, preventive/detective and manual/automated attributes.

Depends on. Nothing — it is the foundation. Scoping decisions are expressed here.

Watch for. Two things determine whether this module is useful or merely tidy. Precision — “the manager reviews the reconciliation” is not a control until you know what threshold triggers investigation. And key versus non-key — treating every control as key is how ICoFR programmes become unsustainable.

Assess the design and operating effectiveness of controls against the risks they address.

Purpose. Concluding, per control and per period, whether it is well designed and whether it actually operated.

Depends on. Control library for the population; Control testing for the evidence underlying operating effectiveness.

Watch for. Design and operating effectiveness are separate conclusions in that order. A control that is poorly designed cannot be rescued by diligent operation, so there is no point testing operation before design is concluded.

Plan and record control testing across the cycle, with results feeding the assessment.

Purpose. Planning what will be tested and when, recording the method, the sample and the results, and feeding those results into the assessment.

Depends on. Control library for what exists; Evidence management for what the tests produce.

Watch for. Sample size follows control frequency, because the population does. And method matters: inquiry alone is never sufficient evidence, while re-performance is the strongest. Planning testing across the cycle rather than compressing it into the final two weeks is the main operational benefit of having this module at all.

Capture and store the evidence for each control test, linked to the control and period.

Purpose. Holding the artefacts that demonstrate a control was performed — attached to the control and the period rather than to somebody’s inbox.

Depends on. Control library and Control testing.

Watch for. Evidence has to show five things: that the control was performed, when, by whom, what population was examined, and what happened to exceptions. A signature on a checklist covers the first three and neither of the last two — which is the most common evidence failure at year end.

Log deficiencies and track remediation to close, with owners and due dates.

Purpose. Turning a failed test into a fix: the deficiency, its severity, a named owner, a due date, and verification that it was actually closed.

Depends on. Risk & control assessment and Control testing.

Watch for. Severity is assessed on what could have happened, not on what did — a control that failed all year without producing an error can still be a material weakness. And individually minor deficiencies aggregate: they must be evaluated together across an account or assertion, not one at a time.

Monitor key controls continuously rather than only at period end, surfacing issues early.

Purpose. Watching control performance as it happens — reconciliations completed on time, exceptions cleared, access changes reviewed, thresholds breached — instead of sampling after the period closes.

Depends on. Control library for what to watch; source-system data for the signals.

Watch for. The benefit is not primarily efficiency. It is that an issue found in month two can still be remediated within the same reporting period, whereas the same issue found in the year-end test cannot. Ask specifically what this module connects to, because its value is bounded by the data it can reach.