Quick answerIn a risk framework, controls are the things you do to mitigate a risk. Criteria are the conditions a control must satisfy to be considered effective. A control without criteria is an aspiration; criteria without controls is a checklist with no implementation. Together, they are the operational backbone of any compliance or risk programme.
Controls vs. criteria
A control is an activity, configuration or practice that mitigates a risk – ‘All processors have a signed Data Processing Agreement’, ‘Multi-factor authentication is enforced on all administrative accounts’, ‘Employee privacy training is delivered annually’. Criteria define what evidence proves the control is operating – signed contract on file, review date within 12 months, sub-processor list current, MFA log shows 100% admin coverage, training records retained with completion timestamps.
How they fit together
Every meaningful control has criteria. Every meaningful criterion belongs to a control. The framework links them: one control with one criterion is a simple case; one control with several criteria is common (a ‘Processor DPA’ control might have criteria for contract presence, scope coverage, sub-processor list and renewal date). Auditors check criteria; teams operate controls.
Anatomy of a well-formed control
- Statement – what is to be done, in active voice
- Owner – named accountable person
- Frequency – how often the control runs
- Criteria – what evidence proves the control is operating
- Evidence location – where the evidence is retained
- Linked risks – what this control mitigates
- Review date – when the control is reassessed
Configurable framework engines
Modern risk platforms ship configurable engines where controls, criteria, policies and assessments can be defined and adjusted without requiring the vendor to make changes. This matters because real organisations rarely fit a vendor’s pre-shipped framework exactly: sector specifics, internal methodology, regulator nuance and historical decisions all require local adaptation. Configurable engines reduce the risk of being locked into someone else’s interpretation of the standard.
Control effectiveness
Design effectiveness
The control, as designed, would mitigate the risk if operated correctly. Audited through walkthroughs and design reviews.
Operating effectiveness
The control, as actually operated, is mitigating the risk in practice. Audited through evidence inspection – samples, logs, signoffs.
Both matter
A well-designed control that is not operating effectively does not reduce residual risk. A well-operated control whose design has gaps misses the risk it was meant to mitigate.
Common pitfalls
- Controls written as aspirations (‘We aim to…’) rather than concrete activities
- Criteria that test for documentation rather than operation
- Controls without owners – no one runs them
- Controls without review dates – no one notices when they decay
- Pre-shipped frameworks adopted without adaptation, then misaligned to actual practice
- Sample-based criteria with no replication strategy when samples expire
How PrivIQ supports controls and criteria
PrivIQ ships configurable control sections, sub-sections and criteria. Each has owner, review date, evidence location, recurring tasks and linked risks. Frameworks for GDPR, POPIA, NIST AI RMF and similar are pre-configured; tailored frameworks can be built from scratch. AI assistance helps generate controls, criteria and remediation tasks; humans approve.
- Controls are activities. Criteria are the evidence that proves the activities are operating.
- Every meaningful control has criteria. Every meaningful criterion belongs to a control.
- Design effectiveness and operating effectiveness are both required – neither is sufficient alone.
- Configurable engines beat off-the-shelf frameworks for sector- or regulator-specific work.
PrivIQ helps organisations and consultants put this into practice — with policies, controls, evidence, tasks, registers and reporting that survive audit.
More on GRC & Operational.
What’s the difference between a control and a policy?
A policy states what the organisation does. A control is the mechanism that operationalises the policy. ‘Personal data is encrypted at rest’ is a policy statement; ‘Database storage uses AES-256 encryption configured for all customer-data tables’ is the control.
How many controls should a framework have?
Depends on the scope. A privacy compliance framework typically has 40-120 controls; an information-security framework like ISO 27001 has 93 in Annex A; a tailored sector framework might have several hundred.
Can controls be automated?
Yes – and increasingly are. Automated controls (continuous monitoring, configuration checks, log-based evidence) produce more reliable evidence than manual ones. Many platforms support evidence ingestion from monitoring tools.
How often should criteria be reassessed?
At least as often as the underlying control’s review cycle. For continuously-monitored controls, criteria are checked continuously. For periodic controls, criteria are tested at each review.
What happens when a criterion fails?
It becomes a remediation task linked to the control owner. Treatment depends on the failure mode: design issue, operating issue, or evidence-collection issue.