Set up your first ICoFR cycle in Nextera Guard

An ICoFR programme succeeds or fails on decisions taken before a single tool is configured: what is in scope, which controls are key, who owns each one, and what counts as evidence. A system makes a good framework sustainable; it cannot make a bad one work.

This page is written for an internal control lead.

Before you start

Decisions your organisation must make

Scope. Which entities, which accounts and disclosures, and which processes. Work top-down: material accounts → relevant assertions → processes → the points where misstatement can enter → controls. Resist the temptation to start from the list of controls you already have.
What makes a control key. A key control is one whose failure alone could result in a material misstatement. Write the definition down, because treating every control as key is the most common reason an ICoFR programme becomes unsustainable — and it is a decision that quietly makes itself if nobody takes it consciously.
Control ownership. Every control needs a named person, not a department. This is harder than it sounds, and the argument is worth having: a control with no owner cannot be tested and cannot be remediated.
The testing approach. Sample sizes by control frequency, which methods are acceptable (remember, inquiry alone is never enough), who tests, and when in the cycle.
Deficiency evaluation criteria. How you tell a control deficiency from a significant deficiency and from a material weakness, and — the part usually forgotten — how you will aggregate the small deficiencies that hit the same account or assertion.
Evidence standards. What counts as sufficient evidence, and how long it is retained.
The ITGC boundary. Which systems are in scope for IT general controls, and who owns them. If ITGCs are ineffective, every automated control and every system-generated report that depends on them becomes unreliable — so this is not a footnote belonging to the IT department.

Data you must gather

Input	Usual owner	Why it is needed
The existing risk-and-control matrix	Internal control	The starting population, however imperfect
Process narratives and flowcharts	Process owners	Where the controls actually sit in the flow
The trial balance with materiality assessments	Finance	Top-down scoping
Prior-year deficiencies and their status	Internal control	You cannot close what you do not carry forward
Previous external audit findings and the controls they relied on	Finance / external auditors	What they tested and where they placed reliance
The system and application inventory	IT	ITGC scoping and identifying automated controls
The organisation chart with a named owner per control	HR / process owners	Ownership
The close calendar and the key reconciliations	Finance	The controls that actually produce the numbers

The prior-year deficiency row is worth fighting for. Moving a control library across without bringing the open deficiencies with it is how a problem quietly gets found again a year later.

People you need available

An internal control lead with the authority to conclude on scope and to decide what counts as key.
A process owner for each in-scope process, who will propose and own the controls.
An IT contact for the ITGC population and for the automated controls.
Finance leadership, because scoping is a materiality judgement that is theirs to make.
Your external auditors — not to run your programme, but because knowing where they will place reliance determines what you need to be able to demonstrate.

What “done” looks like

Your first cycle is finished when:

Scope is documented top-down, with visible reasoning from the material accounts through to the controls.
The control library carries every in-scope control complete with its risk, process, assertion, owner, frequency and key/non-key attribute — and the key population can be defended.
Every control has a design effectiveness conclusion, reached before any operating testing started.
Testing has been planned across the cycle, performed, and its results recorded complete with the method and the sample.
The evidence for each test is attached to the control and its period, and shows that the control was performed, when, by whom, over what population, and what happened to any exception.
Every exception has a root cause and a conclusion — “it only happened once” is demonstrated, not merely asserted.
Deficiencies have been rated for severity, aggregated where they hit the same account or assertion, and given an owner and a deadline.
You can produce, on request, the complete population of controls with their conclusions and evidence, without assembling it by hand.

Point 3 is the one most often skipped when time is short. Testing the operation of a control whose design was never concluded produces evidence that proves nothing.

Working through it in the product

The order below follows the order the product enforces. You cannot create an RCM before a Business Cycle exists, and you cannot test before an RCM exists — so skipping a step only stops you one step later.

After Sign in you land on Home. Home is not a wizard and not a guided setup: it is a personal workspace of widgets you can arrange yourself — My Tasks, Recent Tasks, Transaction Summary, Pending Items and the Control Assessment board.

On the left is a sidebar containing only the menus you are allowed to open. When a user reports that “the menu isn’t there”, it is almost always an access rights question, not a missing feature.

The menu order matches the work order: Dashboard · Business Cycle · IT Process · Materiality · Risk Control Matrix (RCM) · Control Assessment (Summary, CSA, TOD, TOE) · Deficiency · Remediation · Reporting · System.

2. Setting up master data

All the raw material sits under System › System Settings, in the ICOFR Tables group. What has to exist before anything can be built:

Master	What it holds	Why it comes first
Organization	A seven-level hierarchy, from Holding down to Unit	This is the primary dimension deciding who sees whose data
Chart of Account	The account structure	Used by Materiality
Process	Process, Sub Process, Activity	The skeleton of a Business Cycle
Objective	Control objectives, with the seven financial statement assertions as tick boxes	Connects a control to its assertions
Standard Risk	The risk library, with categories and root causes	Raw material for the RCM
Standard Control	The control library, with all its attributes	Raw material for the RCM
Document	The document types that can be requested as evidence	Defines the shape of evidence
Application	The system inventory with its criticality	ITGC scoping
Workflow	The sequence of Preparer, Reviewer and Approver	Without it nothing can be approved

Every master screen uses the Draft → Validated → Active cycle, and can be stopped through Terminated. Master data therefore goes through approval too — it is not simply typed in and used.

The control attributes available — and this is the taxonomy that ships with the product:

Attribute	Options
Control Type	Preventive · Detective
Control Mode	Manual · Semi-Automatic · Automatic
Control Frequency	Many Times per Day · Daily · Monthly · Quarterly · Yearly · Ad-hoc
Control Category	Access · Change · Financial · IT Operation · Operational
Control Domain	ICOFR · ITGC
Is Key Control	Yes or no, set at control level inside the cycle

You build the library contents yourself — Guard supplies the screens and the attribute taxonomy, not a ready-made list of controls. The option lists above are maintained through System Parameters, so some can be extended to suit your organisation; others are locked because product logic depends on them.

3. Materiality — setting what is in scope

Open the Materiality menu. A materiality document is not typed in by hand: a button on the list screen opens an upload flow for the Chart of Account and the trial balance, and validation reports failures per row, not per file — so you can fix three bad rows without re-uploading everything.

On the Overview tab you set the Materiality Base and Base Amount, then the Threshold (%) that produces Overall Materiality (OM), and the Performance (%) that produces Performance Materiality (PM).

On the Accounts tab, each account carries a Balance Amount, Materiality Type, seven qualitative flags, and a Scope Status — In Scope or Out of Scope. The rule is strict: an account only leaves scope if it is quantitatively immaterial and all seven of its flags are off. A single flag — Is Suspect Fraud or Is Related Party Involved, say — is enough to pull it in, however small the balance.

This is where the scoping decisions from the section above become concrete. If your top-down reasoning is unfinished, this is where you will feel it.

4. Business Cycle and IT Process — building the structure

In the Business Cycle menu, New creates a new cycle and New Version creates a new version of an existing one. You fill in Business Cycle No, Business Cycle Name, Description, Effective Date, Organization, Owner, and the Workflow that will approve it — plus TLC RCM Preparer and ELC RCM Preparer, which separate the transaction level control track from the entity level control track from the outset.

The structure is filled in after the record is saved, on the Processes tab: Add Process, then Add Sub Process, then Add Activity. It is at Activity level that Objective, Risk and Control attach, each of them referencing the master data you prepared.

What becomes a testing row later is the control–risk pair: one control can mitigate several risks, and one risk can be addressed by several controls. That mapping is done here, and its quality determines the quality of the whole cycle.

The RCM Baseline tab carries the inherent rating for each pair — likelihood × impact on a 1–5 scale, producing a score of 1–25 that maps to Low, Medium or High Risk. The Materiality tab links this cycle to the in-scope accounts.

Alongside it, the IT Process menu holds the IT general controls. The category is ITGC or ITAC, and the Controls tab carries the list of controls complete with the Is Key Control marker. This is not an accessory: controls flagged IT Dependency, IPE, EUC or MRC on the Standard Control rely on these IT processes, and if the ITGCs are ineffective the whole chain becomes unreliable too.

Business Cycle and IT Process end at Active, not Approved.

5. RCM — freezing the matrix for one period

The Risk Control Matrix (RCM) menu has two buttons: New for a single cycle, and Create All to generate the RCM for every cycle at once. The second is the normal way to open a period.

You pick a Period and a Business Cycle; Organization and Owner fill in from that cycle. The Matrix tab shows the result — Process, Sub Process, Activity, Objective, Risk and Control side by side.

From this point on, the RCM determines the testing population. A control that is not in this period’s RCM will not appear in CSA, TOD, TOE or CA Summary. If a control is missing from the testing list, check its RCM first.

6. CSA, TOD and TOE — three different angles

All three stand on the same RCM, and all three have New and Create All.

CSA (Control Assessment › CSA) is the control owner’s self-assessment. The work happens on a separate Assessment screen, one tab per control, with Control Evaluation and Justification as the main entries. The reviewer does not reject; the reviewer leaves a comment of type Inquiry or Confirmed that the preparer has to Resolve one by one. That is why CSA has two extra statuses, Submitted and Reviewed.

TOD (Control Assessment › TOD) tests the design. You enter a Test Approach — Inquiry, Document Review, Flowchart Review or Walkthrough — then Result, Finding, Severity and Recommendation.

TOE (Control Assessment › TOE) tests the operation. You enter a Test Method — Inquiry, Observation, Inspection, RePerform — and the testing scope: Full Scope, Key Control Only, Sample or Exception.

7. Sampling and evidence

Inside a TOD or TOE testing row, the Sampling section holds the samples you decide on: Sample No, Reference, Description, Period, Test Procedure, Expected Result, Actual Result and Sample Status. Guard does not calculate the sample size from the control frequency and does not draw a random sample from the population — the size reference is in Internal control concepts, and applying it is your decision.

Each sample has an Evidence list with Document Type, Document Link and Document Remark. The flow is more than attaching a file:

The tester prepares the sample and marks which document types are needed.
The Send & Request button sends the evidence request to whoever has to upload it, and the sample records a Request Date.
That request appears as a task on that person’s Home page.
Once all of the evidence is uploaded, the sample records an Upload Date.

While a request is outstanding, the sample cannot be changed or deleted — the trail is preserved.

In CSA, evidence works slightly differently and more strictly: the documents that are mandatory for a control are already set on that control in the Business Cycle, complete with an Is Mandatory marker. Attachments are uploaded against a specific requirement row, so the system knows not just that “there is an attachment” but “an attachment for which requirement”.

Beyond that, every record in Guard has a Documents tab for general attachments, with Document Date, Document Type, the file itself and Notes.

8. Deficiency and Remediation

Create a Deficiency document for one Business Cycle and one Period. The Details tab carries the finding rows, each bringing a Source — CSA, TOD or TOE — a Reference linking back to the document it came from, and the Assessment Result that triggered it. What you fill in per row: Deficiency Type (Control Deficiency, Significant Deficiency, Material Weakness), Description, Severity (Low, Medium, High), Root Cause, Impact Description and Target Remediation Date.

Note that Deficiency Type and Severity are two separate axes that do not calculate from each other.

Then create a Remediation, selecting the Source and Reference to that finding, and fill in the Action Plan, Root Cause, Owner, and three dates: Target Date (promised), Completion Date (declared complete) and Verified Date (demonstrated complete). A remediation with a Completion Date but no Verified Date cannot yet be treated as closed.

9. Seeing where you stand, and reporting it

Control Assessment › Summary gives you one row per control per period, with the status and result of RCM, CSA, TOD and TOE side by side, and every number linking to its source document. This is the screen that answers “how far along are we” without assembling it by hand. An empty column means that stage’s document has not been created, not that it failed.

Reporting › Reports produces list and detail reports for RCM, CSA, TOD and TOE, which can be viewed as a preview, downloaded as Excel, or converted to PDF. Reporting › Data Analytics offers pivots you can build yourself. Dashboard shows a graphical summary including a risk heatmap.

10. Roles and segregation of duties

Access is set under System › System Security, through two screens:

User — the account identity: Username, Full Name, User Title, User Type, User Group, User Location, Email Address. Its special actions are Reset Password, Lock and Unlock.
Access Control — the roles. There are two kinds, and the difference matters: a role of type Menu determines which features may be used, while a role of type Authorization determines whose data may be seen.

On a Menu-type role, the Access Detail tab shows a tree per module and you tick the permitted actions — Create, View, Modify, Validate, Send for Approval, Approve, Cancel, Reverse — for each module separately. So “may view TOE” and “may approve TOE” are two different rights.

Two behaviours to know when you design segregation of duties:

Access through a User Group is inherited. A user inherits all of the group’s rights. This is also what lets an approval step be assigned to a group rather than to one person — useful when the approver is on leave.
Organization access cascades downwards. Giving somebody access to a Division automatically gives them access to every Department, Section and Unit beneath it, and there is no way to exclude one branch.

Can a control owner assess their own control? In CSA, yes — that is the whole point; CSA is a self assessment, and the control over it is the preparer–reviewer cycle and the comments that have to be resolved. TOD and TOE are independent tests, and the product does not stop anyone from testing their own. You enforce that separation through Workflow design — put the Reviewer and Approver outside the control owner’s reporting line — and through per-action access rights. Treat it as a recorded design decision, not as something the system does by default.

Getting access

Nextera Guard normally runs at guard.nextera.id. Accounts are provided by the product administrator in your organisation. The address above is the production address; if your organisation uses a dedicated environment, use the address in your onboarding pack.