Every ITGC test answers one of two questions. They sound similar enough that people blur them together, and the blurring is where bad findings come from.
The two questions
Design effectiveness asks: if this control were performed exactly as intended, would it address the risk?
Operating effectiveness asks: was it actually performed that way, consistently, throughout the period?
A control has to pass both. Passing one tells you very little on its own.
Why design comes first
There is a practical reason design is assessed first, and it is not just convention.
If a control is badly designed, testing whether it operated is wasted effort. Suppose a company reviews privileged access annually, but privileged accounts are granted and removed weekly. You could confirm the annual review happened perfectly on schedule for three years running. It still would not address the risk, because the control’s frequency does not match the rate at which the risk changes.
Perfect execution of a control that cannot work is not mitigation. So you assess design first, and only test operation once you know the control is capable of doing its job.
What each test actually looks like
For design, you are reading, asking and reasoning:
- Obtain the policy or procedure and understand what is meant to happen
- Walk through one instance end to end with the person who performs it
- Ask whether the control addresses the risk, at the right frequency, by someone independent enough to be credible
- Look for the gap between the documented process and the described one
Design testing usually needs a single walkthrough. You are not gathering volume, you are gathering understanding.
For operating effectiveness, you are sampling and tracing:
- Establish the population for the period
- Select a sample sized to the control’s frequency
- Obtain evidence for each item that the control was performed
- Evaluate every exception, and do not explain any of them away
Sample sizes follow frequency
Sample size is driven by how often the control runs, not by how important it feels:
| Control frequency | Typical sample |
|---|---|
| Annual | 1 |
| Quarterly | 2 |
| Monthly | 2–5 |
| Weekly | 5–15 |
| Daily | 20–40 |
| Many times per day | 25–60 |
The logic is straightforward. A control that runs 250 times a year has far more opportunity to fail than one that runs once, so you need more evidence to conclude it ran reliably.
The failure mode to avoid
The most common mistake in ITGC work is accepting a document as evidence of operation.
A signed policy proves design intent. It does not prove that the quarterly review happened in Q3. When someone hands you a procedure document as evidence that a control operated, they have answered the wrong question, usually without realising it.
Ask for the artefact the control produces when it runs. The completed review with names and dates. The approval record on the change. The restoration test result. If a control genuinely operated, it left something behind. If it left nothing behind, you cannot conclude it operated, and that is a finding in itself.