Control, evidence, test, finding, exception: five GRC terms and how they differ
Working definitions of the terms used in audits and reviews, the difference between design and operating effectiveness, and why a policy alone does not show that a control works. With three examples: MFA, backup restore, vendor assessment.
Six different objects
In compliance programmes these terms are often used as synonyms. Keeping them apart makes it clear what is missing when an auditor asks for "the proof".
| Term | What it is | Example |
|---|---|---|
| Requirement | What a framework or contract asks for | NIS2 Art. 21(2)(j): multi-factor authentication, where appropriate |
| Control | The activity or configuration through which the organisation meets the requirement, with an owner | Mandatory MFA for all accounts with access to company systems, enforced by the identity provider |
| Evidence | Data or a document showing the state of the control at a point in time or over a period | Dated export of identity provider users with MFA status |
| Test | A planned check that compares the control with its criterion and produces a result | Comparison of the active user list with users who have MFA enrolled |
| Finding | The confirmed gap between the expected and the observed control | Three active accounts without MFA and without authorisation |
| Exception | A term with two uses: a deviation found in a test sample, or an approved and justified waiver from a rule | A service account without MFA, with an approved waiver, compensating measures and an expiry date |
A policy is not proof of operation
A policy states a rule and who must apply it. It shows that the control has been designed and approved, not that it has been performed. An auditor reviewing a period asks for records produced during that period: approved access requests, backup logs, review minutes.
The same principle appears in the frameworks: ISO/IEC 27001 requires performance to be monitored and measured (clause 9.1) and internal audits to be conducted (clause 9.2); NIS2 requires policies and procedures to assess the effectiveness of measures (Art. 21(2)(f)).
Design effectiveness and operating effectiveness
- Design effectiveness: the control, if performed as described, is capable of treating the risk it exists for. It is assessed by reading the procedure, inspecting the configuration and walking one case through from start to finish.
- Operating effectiveness: the control worked consistently throughout the period under review. It is assessed on a sample of cases spread across the period.
- A control can be well designed and not operate (a quarterly access review is planned but not performed) or operate with a weak design (the review is performed but excludes privileged accounts).
- SOC 2 reports make the distinction visible: a Type 1 report covers the design of controls at a date, a Type 2 report also covers operating effectiveness over a period.
What makes evidence usable
- Relevant: it concerns the stated control and scope, not a similar system.
- Complete: it covers the whole population (all users, all in-scope servers), or states how the sample was drawn.
- Dated: it shows which point in time or period it refers to.
- Attributable: it identifies the source and who produced it.
- Intact: a system-generated export is stronger than an undated screenshot or a manually edited file.
Example 1: MFA coverage
- Control: mandatory MFA for all interactive accounts, enforced by an identity provider policy.
- Evidence: policy configuration; dated export of users with MFA status; list of approved waivers.
- Test: comparison of active users with the MFA list; calculation of coverage (for example 97%); check that every uncovered account has a valid waiver.
- Possible outcome: a finding for uncovered accounts without a waiver; a documented exception for a service account with compensating measures.
Example 2: backup restore test
- Control: daily backup of critical systems and periodic restore testing according to plan.
- Evidence: backup job logs; test record with system, date, measured restore time and data integrity check.
- Test: check that restore was tested during the period for critical systems and that the measured time is within the recovery objective.
- Key point: a completed backup log does not show that data can be restored. Only a performed restore shows that.
Example 3: vendor assessment
- Control: critical vendors are assessed before contracting and reassessed at the planned frequency.
- Evidence: vendor list with criticality; completed questionnaires; certifications or reports received with validity dates; assessment outcome and approval.
- Test: for a sample of critical vendors, check that a current assessment exists and that each issue raised has an action or a risk acceptance.
- Frequent finding: an assessment performed at onboarding and never repeated, with a certification that has since expired.
From finding to corrective action
ISO/IEC 27001 (clause 10.2) requires, for each nonconformity, reacting to it, evaluating the need to eliminate its causes, implementing the necessary action, reviewing its effectiveness and retaining documented information. A finding is closed when a new test confirms the correction, not when the action is declared complete.
In EVIDEVO
In Controls and compliance, controls, tests and evidence are separate, linked objects: each evidence item records author, date and expiry, each test has a frequency and an outcome, and a failed test raises a corrective action. Integrations and automation collects technical evidence from connected systems; Audits and reviews gathers samples and findings for the auditor.
Official sources
Informational summary. Not legal advice: obligations and applicability should be checked against the official texts and the specific case.