Requirements vs. Controls: Clarifying the 'What' and the 'How' in GRC

Understanding the Core Difference

The article highlights a common point of confusion for GRC professionals: the difference between a 'requirement' and a 'control.' A requirement, as defined by ISO, is a 'need or expectation that is stated, generally implied or obligatory.' These are the 'what' – the desired state or objective, often found in frameworks like NIST CSF, ISO 27001, or regulations like GDPR. They are descriptive, allowing organizations of varying sizes to achieve compliance in ways suitable for their unique environments. Controls, on the other hand, are the 'how' – the specific safeguards, policies, procedures, or technical measures put in place to meet a requirement and modify risk. They are the practical implementation steps.

Historical Context and Categorization of Controls

To further illustrate the concept, the author provides a brief history of controls, tracing their origin from medieval accounting practices (the 'contrarotulus' or duplicate ledger) to modern financial regulations like Sarbanes-Oxley (SOX). This historical perspective underscores that controls have always been about providing assurance that objectives are met and records are accurate, a principle directly inherited by information and cybersecurity. In GRC, controls can be categorized by their function and type:

• Preventive: Aims to stop incidents (e.g., firewalls).
• Detective: Identifies incidents after they occur (e.g., log reviews).
• Corrective: Recovers from incidents (e.g., backups).
• Administrative: Policies, procedures, and training (e.g., security awareness).
• Technical: Software or hardware safeguards (e.g., encryption).
• Physical: Protects physical access (e.g., locks, security guards).

Practical Application: From Requirement to Controls

The article uses a concrete example from SOC 2's Trust Services Criteria (CC6.1) to demonstrate how a single high-level requirement translates into a system of interconnected controls. The requirement to 'implement logical access security' and 'identify and authenticate users' doesn't prescribe specific tools. Instead, organizations must develop a suite of controls, such as:

• An Access Control Policy (Administrative - Preventive)
• MFA with Hardware Keys (Technical - Preventive)
• Hardware Key Lifecycle Management (Administrative - Preventive)
• Quarterly User Access Reviews (Administrative - Detective)

This example clearly shows how administrative and technical controls work in concert to achieve the objective set by the requirement. A mature GRC program relies on this clear understanding, translating broad objectives into actionable policies, processes, and technologies to ensure security and compliance.