Nextera Guard module map
Nextera Guard has eleven modules, and their order is not the menu order but the working order of one ICoFR cycle: decide what is material, document the processes and their controls, freeze the matrix for one period, test it from three angles, then follow up on the findings.
If a term here is unfamiliar, read Internal control concepts first — this page assumes it.
The order of one cycle
Section titled “The order of one cycle”flowchart TD
M[Materiality] --> BC[Business Cycle]
IT[IT Process] --> RCM[Risk Control Matrix]
BC --> RCM
RCM --> CSA[CSA]
RCM --> TOD[TOD]
RCM --> TOE[TOE]
CSA --> CAS[CA Summary]
TOD --> CAS
TOE --> CAS
CSA --> DEF[Deficiency]
TOD --> DEF
TOE --> DEF
DEF --> REM[Remediation]
| Order | Module | The question it answers | Menu |
|---|---|---|---|
| 1 | Materiality | Which accounts are material enough to be in scope? | Materiality |
| 2 | Business Cycle | Which processes produce those numbers, and what controls sit inside them? | Business Cycle |
| 2b | IT Process | Which IT general controls hold them up? | IT Process |
| 3 | RCM | Which risk–control pairs apply for this period? | Risk Control Matrix (RCM) |
| 4a | CSA | In the control owner’s own words, is the control working? | Control Assessment › CSA |
| 4b | TOD | If performed as designed, would this control prevent a misstatement? | Control Assessment › TOD |
| 4c | TOE | Was this control actually performed throughout the period? | Control Assessment › TOE |
| 5 | CA Summary | Where does each control stand across the four stages above? | Control Assessment › Summary |
| 6 | Deficiency | What findings came up, and how serious are they? | Deficiency |
| 7 | Remediation | Who fixes what, by when, and who verifies it? | Remediation |
| — | Dashboard & Reporting | What does the summary look like, and what can be printed? | Dashboard · Reporting |
The same shape in every module
Section titled “The same shape in every module”All eleven modules use the same screens, so learning one means learning them all.
The List page. A grid of that module’s records, with Search, a + New button and Filter. Columns can be dragged into the Drag a column header here to group by that column area to group them, and paging is 50 / 200 / 1000 rows.
The Details page. Opened by clicking a record number — RCM No, CSA No, Deficiency No and so on. The top of the screen shows the record identity and its Status; the rest is grouped into tabs.
Three tabs that are always there. Workflow shows where the record stands in the approval flow, Documents holds the supporting attachments, and Activities records the change history. Only the fourth tab differs between modules.
The Action button. The Action menu on the Details page runs the actions available for the current Status: Modify, Validate, Send for Approval, Approval, Cancel and Reverse.
The same statuses across the product:
Draft → Validated → Review and Approval → Approvedwith Cancelled as the exit path and Reverse to return a Validated record to Draft. The structural documents — Business Cycle and IT Process — end at Active instead of Approved, and are stopped through Terminated. CSA adds two stages no other module has, Submitted and Reviewed, because an assessment goes through a preparer–reviewer cycle before it reaches approval.
Who may run each step is determined by the Workflow selected on that record. One workflow holds a sequence of Preparer, Reviewer and Approver levels, and each level is assigned to a user or to a user group.
Materiality
Section titled “Materiality”Sets the materiality thresholds from the financial data, then flags which accounts fall inside ICoFR scope.
What it is for. Turns scoping from an argument into a decision recorded per account.
Where. The Materiality menu.
What you do. Materiality is not typed in by hand — its list screen uses a button that uploads the Chart of Account and the trial balance, and failures are reported per row so you know which row was rejected. The Overview tab carries Materiality Date, the Materiality Base with its Base Amount, the Threshold (%) that produces Overall Materiality (OM), and the Performance (%) that produces Performance Materiality (PM). The Accounts tab carries one row per account with Balance Amount, Materiality Type, seven qualitative flags and a Scope Status — In Scope or Out of Scope.
Things to watch for. Those seven qualitative flags — Is Suspect Fraud, Is High Activity Volume, Is High Activity Complexity, Is High Accounting Complexity, Is Contingency Risk, Is Related Party Involved, Is Policy Changed Recently — a single one is enough to pull an account into scope, however small the balance. An account only leaves scope if it is quantitatively immaterial and all seven of its flags are off.
Business Cycle
Section titled “Business Cycle”Documents a business cycle together with its processes, activities, and the Objectives, Risks and Controls inside them.
What it is for. This is where your control library actually lives. Not one flat list but a four-level structure — Cycle → Process → Sub Process → Activity — with Objective, Risk and Control attached at Activity level.
Where. The Business Cycle menu.
What you do. The Processes tab shows that structure as a tree, with Add Process, Add Sub Process, Add Activity, Modify and Remove actions on every row. The RCM Baseline tab carries that cycle’s risk–control matrix complete with its inherent ratings. The Materiality tab shows the in-scope accounts related to this cycle.
The raw material comes from master data: a Control inside a cycle references a Standard Control, a Risk references a Standard Risk, and an Objective references an Objective — all maintained in System Settings.
Things to watch for. Three things decide whether this module is useful or merely tidy:
- One control can mitigate several risks, and it is the control–risk pair that later becomes an RCM row. Map it carelessly and you will feel it at the testing stage.
- Versioning. The list screen has New and New Version. A new version copies the whole structure beneath it, so an approved cycle does not change when its structure is revised. Changing a Standard Control in the master also does not change the cycles already built — that is deliberate.
- TLC and ELC are separated from the outset, through the TLC RCM Preparer and ELC RCM Preparer fields. Transaction level controls sit inside the transaction flow; entity level controls are entity-wide controls such as tone at the top. The two run through different approval tracks.
IT Process
Section titled “IT Process”Documents the IT general controls and application controls, alongside the Business Cycle.
What it is for. ITGCs hold up every automated control and every system-generated report. This module runs alongside the Business Cycle rather than beneath it, and its output feeds the RCM too.
Where. The IT Process menu.
What you do. The Controls tab carries the list of controls on that IT process, each one with an Is Key Control marker. There are two categories: ITGC for IT General Controls and ITAC for IT Application Controls. Like Business Cycle, this module has New Version and ends at Active.
Things to watch for. The connection to the business world happens through attributes on the Standard Control: IT Dependency and its type — Interface, Automatic Calculation, Restricted SOD, or Information Process by Entity — then IPE, EUC and MRC. A control flagged with IT Dependency gets an IT Application tab where you link it to the application that supports it. If the ITGCs are ineffective, that whole chain becomes unreliable too.
RCM — Risk Control Matrix
Section titled “RCM — Risk Control Matrix”Freezes a Business Cycle’s risk–control pairs for one period. All the testing hangs off it.
What it is for. The RCM is Guard’s centre of gravity. Until an RCM exists for a period, there is nothing to test.
Where. The Risk Control Matrix (RCM) menu.
What you do. The list screen has two buttons: New for a single cycle, and Create All to generate the RCM for every cycle at once — this is the normal way to open a period. The form asks for RCM Date, the Period, and the Business Cycle, picked from a list showing Cycle No, Cycle Name and Version No; Organization and Owner fill in automatically from that cycle. The Matrix tab shows the result: Process, Sub Process, Activity, Objective, Risk and Control side by side in one row.
Things to watch for. RCM types are split into TLC and ELC, following the separation already set in the Business Cycle. Inherent rating uses a likelihood × impact model with a 1–5 scale on both axes, so the score runs 1–25, and is then mapped to Low, Medium or High Risk.
CSA — Control Self Assessment
Section titled “CSA — Control Self Assessment”The control owner’s own assessment of the controls they are responsible for.
What it is for. Captures the first line’s view: in the words of the person who performs it, is this control operating effectively, and on what basis.
Where. The Control Assessment › CSA menu.
What you do. The list screen has New and Create All. The assessment work itself does not happen on the usual detail screen but on a separate Assessment screen, with one tab per Control. Each tab shows Control No, Control Name, its description, Related Objectives, Related Risks, then the two entries you fill in: Control Evaluation and Justification. Below them is the list of documents requested for that control, complete with an Is Mandatory marker.
That screen has three modes — Assess for the preparer, Review for the reviewer, and View — and its buttons change with the mode: Send for Review, Pushback, Approve.
Things to watch for. The reviewer does not reject an assessment outright. The reviewer leaves a comment of type Inquiry or Confirmed, and the preparer has to Resolve each comment before the assessment can move on. That is why CSA has Submitted and Reviewed statuses that no other module has. The assessment results are Effective, In-Effective, or Not Assessed.
TOD — Test of Design
Section titled “TOD — Test of Design”Tests whether a control, if it were performed exactly as designed, would prevent or detect a misstatement.
What it is for. Concluding on a control’s design before anyone tests its operation. That order is not a formality: a badly designed control cannot be rescued by diligent performance.
Where. The Control Assessment › TOD menu.
What you do. New for a single RCM, or Create All to generate the testing for every RCM row at once. The Testing tab carries one row per control, with Control No, Control Name, Is Key Control, Test Approach and Test Result visible directly in the grid. Opening a row gives you the full set of entries: Test Approach — Inquiry, Document Review, Flowchart Review or Walkthrough — then Result, Result Notes, Finding, Severity, Recommendation and Recommendation Notes.
Things to watch for. The Finding list is characteristic of design testing: Design Gap, Incomplete Design, Misaligned Design, No Control Exists, Management Override Risk. And remember that inquiry is the weakest form of evidence — the product will not stop you resting a whole test on it, so that is your own methodological discipline, not a guard rail in the system.
TOE — Test of Effectiveness
Section titled “TOE — Test of Effectiveness”Tests whether a control was actually performed, consistently, throughout the period.
What it is for. Operating testing. It only makes sense once the design has been concluded effective in TOD.
Where. The Control Assessment › TOE menu.
What you do. The screen mirrors TOD — New, Create All, a Testing tab, the same sampling and evidence. Two things differ:
- Instead of Test Approach, the entry is Test Method, with four options ordered from the weakest to the strongest: Inquiry, Observation, Inspection, RePerform.
- The testing scope has real options: Full Scope, Key Control Only, Sample and Exception. TOD has no such choice, because testing a design does not demand a “how many” decision.
Things to watch for. Key Control Only works directly off the Is Key Control marker on each control. If every control of yours is flagged key, that option saves nothing — which comes back to the definition of key you set yourself.
Sampling and evidence in TOD and TOE
Section titled “Sampling and evidence in TOD and TOE”This section is the same for both, and this is where the evidence is really collected.
Inside a testing row, the Sampling section holds the list of samples you add yourself: Sample No, Reference, Description, Period, Test Procedure, Expected Result, Actual Result and Sample Status. Each sample has an Evidence list with Document Type, Document Link and Document Remark.
What makes it work as a process rather than merely a place to keep files is the Send & Request button: the tester ticks the samples that are ready and sends the evidence request to whoever has to upload it. That sample records a Request Date, appears as a task on that person’s Home page, and records an Upload Date once all of its evidence has been uploaded. While the request is outstanding, the sample cannot be changed or deleted.
CA Summary
Section titled “CA Summary”One row per control per period, showing where it stands in RCM, CSA, TOD and TOE at once.
What it is for. This is the answer to “how far along are we?” without having to assemble it by hand. The only screen in Guard that creates nothing — it only displays and links.
Where. The Control Assessment › Summary menu.
What you do. Read and drill down. The columns come in groups: the period — Year, Semester, Quarter, Month — then the Control, Cycle, Activity, Organization and Owner context, then four status groups: RCM No and RCM Status; CSA No, CSA Status and CSA Result; TOD No, TOD Status and TOD Result; TOE No, TOE Status and TOE Result. Every number is a direct link to its source document.
Things to watch for. An empty column means that stage’s document has not been created, not that it failed. And the rows appear on the basis of the RCM: a control that is not yet in this period’s RCM simply will not show up here. This screen has no actions at all — if something needs changing, change it in the module it came from.
Deficiency
Section titled “Deficiency”Records the findings from CSA, TOD and TOE, and gives them a classification and a severity.
What it is for. Collecting the controls that are not working as they should into one defensible list, with their root causes and their impacts.
Where. The Deficiency menu.
What you do. Create a Deficiency document for one Business Cycle and one Period. The Details tab then carries the finding rows, each bringing Control No, Control Name, a Source — CSA, TOD or TOE — a Reference linking back to the document it came from, and the Assessment Result that triggered it. Rows are not added one at a time; what you do is open each row and fill in its assessment: Deficiency Type, Description, Severity, Root Cause, Impact Description and Target Remediation Date.
Things to watch for. There are two axes, not one. Deficiency Type is the ICoFR classification — Control Deficiency, Significant Deficiency, Material Weakness — while Severity is the internal rating of Low, Medium, High. The two are filled in separately and do not calculate from each other. Severity is judged on what could happen, not on what already has; the product simply stores what you choose.
Remediation
Section titled “Remediation”Turns a finding into a fix with an owner, a deadline, and separate verification.
What it is for. Closing the loop. This is the simplest module in Guard — it has no dedicated tab at all, only Overview plus Workflow, Documents and Activities.
Where. The Remediation menu.
What you do. Create a record with a Remediation Date, the Business Cycle, the Source — CSA, TOD or TOE — and the Reference to the finding being followed up. On Overview you fill in the Action Plan, Root Cause, Organization, Owner, Workflow, and three dates.
Things to watch for. The three dates mean different things, and the difference is exactly what an auditor asks about:
| Field | What it means |
|---|---|
| Target Date | When the fix was promised to be complete |
| Completion Date | When whoever did it declared it complete |
| Verified Date | When somebody else demonstrated that it really was |
A remediation that has a Completion Date but not yet a Verified Date cannot be treated as closed. The Reference No column on the list screen links back to the source document, so the finding → fix chain can be traced in both directions.
Dashboard, Reports and Data Analytics
Section titled “Dashboard, Reports and Data Analytics”Three different ways of looking at the results — a graphical summary, formal documents, and pivot analysis.
Dashboard (the Dashboard menu) presents a graphical summary in three panels: Control Assessment, Risk Management and Audit. It shows, among other things, control results summarised by organisation, assessment progress by division, and a likelihood × impact risk heatmap.
Reports (the Reporting › Reports menu) produces the formal documents. Reports are available in list and detail form for RCM, CSA, TOD and TOE, plus User and Access reports. The output can be viewed as an interactive preview, downloaded as Excel, or converted to PDF; the file name can carry an automatic date-time token.
Data Analytics (the Reporting › Data Analytics menu) offers pivots and charts you can build yourself, with two built-in viewpoints: Control Design Deficiency and Business Cycle Summary.
Home — the first page after you sign in — is not a module but a personal workspace of widgets you can arrange: My Tasks, Recent Tasks, Transaction Summary, Pending Items and the Control Assessment board. This is where evidence requests and the documents awaiting your decision appear.