Preparing your first ICoFR cycle in Nextera Guard
Konten ini belum tersedia dalam bahasa Anda.
An ICoFR programme fails or succeeds on decisions made before any 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
Section titled “Before you start”Decisions your organisation must make
Section titled “Decisions your organisation must make”- Scope. Which entities, which accounts and disclosures, and which processes. Work top-down: material accounts → relevant assertions → processes → points where a misstatement could arise → 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 everything as key is the most common reason ICoFR programmes become unsustainable — and it is a decision that quietly gets made by default if nobody makes it deliberately.
- Control ownership. Every control needs a named person, not a department. This is harder than it sounds and it is worth the argument: an unowned control is untestable and unremediable.
- Testing approach. Sample sizes by control frequency, acceptable methods (remembering inquiry alone is never sufficient), who tests, and when in the cycle.
- Deficiency evaluation criteria. How you distinguish a control deficiency from a significant deficiency from a material weakness, and — the part usually forgotten — how you will aggregate individually minor deficiencies affecting the same account or assertion.
- Evidence standards. What constitutes 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 system-generated report depending on them is unreliable — so this is not an IT-department footnote.
Data you must gather
Section titled “Data you must gather”| Input | Typical owner | Why it is needed |
|---|---|---|
| Existing risk-and-control matrices | Internal control | The starting population, however imperfect |
| Process narratives and flowcharts | Process owners | Where controls actually sit in the flow |
| Trial balance with materiality assessment | Finance | Top-down scoping |
| Prior-year deficiencies and their status | Internal control | You cannot close what you have not carried forward |
| External audit’s prior findings and control reliance | Finance / external audit | What they tested and where they placed reliance |
| System and application inventory | IT | ITGC scoping and automated control identification |
| Organisation chart with named control owners | HR / process owners | Ownership |
| Close calendar and key reconciliations | Finance | The controls that actually produce the numbers |
The prior-year deficiency row is worth insisting on. Migrating a control library without carrying open deficiencies forward is how issues get quietly rediscovered a year later.
People you need available
Section titled “People you need available”- An internal control lead with authority to conclude on scope and on what is key.
- Process owners for each in-scope process, who will nominate and own controls.
- An IT contact for the ITGC population and for automated controls.
- Finance leadership, because scoping is a materiality judgement they own.
- Your external auditor — not to run your programme, but because knowing where they intend to place reliance shapes what you need to evidence.
What “done” looks like
Section titled “What “done” looks like”Your first cycle is complete when:
- Scope is documented top-down, with the reasoning from material account to control visible.
- The control library holds every in-scope control with risk, process, assertion, owner, frequency and key/non-key attributes — and the key population is defensible.
- Each control has a design effectiveness conclusion, reached before any operating testing began.
- Testing has been planned across the cycle, executed, and results recorded with method and sample.
- Evidence for each test is attached to the control and the period, and demonstrates that, when, by whom, what population, and what happened to exceptions.
- Every exception has a root cause and a conclusion — “one-off” is evidenced, not asserted.
- Deficiencies are rated, aggregated where they affect the same account or assertion, owned and dated.
- You can produce, on request, the complete population of controls, their conclusions and their evidence, without assembling it by hand.
Point 3 is the one most often skipped under time pressure. Testing the operation of a control whose design was never concluded produces evidence that proves nothing.
Working through it in the product
Section titled “Working through it in the product”Getting access
Section titled “Getting access”See Getting access to Nextera products. Nextera Guard normally runs
at guard.nextera.id.