Read on grclab.com | Read time: 3 minutes
Welcome to GRC Lab, a weekly newsletter where we provide actionable advice to help you launch, grow and accelerate your career in Governance, Risk and Compliance.
P.S. Have you already checked out our new DOCS section?
Inside this Edition
Here’s what we got for you today:
Many professionals mistake requirements for controls when referring to the mandates found within compliance frameworks. Learn about the real difference between them.
Our partner Kertos has secured an impressive series of 14 million Euros for redefining AI-native compliance in Europe.
GRC Spotlight
Kertos raised a €14 Million Series A!
Last year, shortly after leaving my 9 to 5, and launching my own business, I entered a strategic partnership with Kertos. Fast forward to today, Kertos has not only become my favourite client, but also an all-in-one compliance suite built for European SMEs and scaleups.
I am very proud to tell you that we have raised €14 million in a Series A funding round. The investment was spearheaded by global fintech investor Portage, with continued support from existing backers Pi Labs, Redstone, 10x Founders, and Seed + Speed Ventures.
Earlier this week, I posted on LinkedIn about a topic that seems to trip up even seasoned GRC professionals: the difference between a "requirement" and a "control." The post went unexpectedly viral, flooded with comments and questions that highlighted just how much confusion surrounds these fundamental terms. It’s clear this is a conversation we need to have.
LinkedIn Post
So, let's do a deep dive. Understanding this distinction isn't just academic—it's the foundation of building an effective, efficient, and auditable compliance program.
Requirements: The "What"
Let's start with the basics. As per ISO 27000 a requirement is a "need or expectation that is stated, generally implied or obligatory." Frameworks like NIST CSF, ISO 27001, SOC 2, C5, and regulations like GDPR are collections of requirements. They tell you what you need to do and why it's important, but they rarely tell you how to do it.
A key concept here is that these frameworks are descriptive, not prescriptive. They describe a desired outcome (e.g., "protect data from unauthorized access") rather than prescribing the exact tool or process every organization must use. This is on purpose and by design. Descriptive frameworks, allow a five-person startup and a 50,000-person enterprise to comply with the same requirements in ways that fit their unique environments.
Controls: The "How"
If a requirement is the "what," a control is the "how." A control is the specific policy, procedure, technical safeguard, or action you implement to meet a requirement and modify risk. Controls are the concrete steps you take to get to the destination defined by the requirement.
control
“Any action taken by management, the board, and other parties to manage risk and increase the likelihood that established objectives and goals will be achieved”
A Quick History: From Accounting to Cybersecurity
To understand controls, it helps to know where the term came from. It didn't originate in IT or cybersecurity, but in finance and accounting. The word "control" comes from the Medieval Latin ‘contrarotulus’, which means "counter-roll." This was a duplicate ledger used in the Middle Ages to check the accuracy of the primary financial records—a literal act of checking one roll against another.
For centuries, this was the essence of control: a manual, detective action to verify financial accuracy. The concept evolved with the Industrial Revolution, as owners became separated from the day-to-day management of their companies and needed systems to ensure operations were running correctly. The modern era of control was forged after the massive accounting scandals of the early 2000s, like Enron and WorldCom. These events led to legislation like the Sarbanes-Oxley Act (SOX), which legally mandated that corporate management be held personally responsible for the effectiveness of their internal controls over financial reporting.
This history is important because it shows that controls have always been about providing assurance that objectives are being met and that records are accurate—a principle that has been directly inherited by the world of information- and cybersecurity.
Defining Controls in GRC
In GRC, controls are the specific safeguards implemented to meet requirements. They can be categorized in several ways:
Preventive: To prevent an incident from happening (e.g., a firewall).
Detective: To identify an incident after it has occurred (e.g., log reviews).
Corrective: To recover from an incident after it has occured (e.g. backups).
Administrative: Policies, procedures, and training (e.g., a security awareness program).
Technical: Safeguards implemented in software or hardware (e.g., encryption).
Physical: Mechanisms that protect physical access (e.g., locks, security guards).
The Real Difference between Requirements and Controls
Let's make this concrete. Consider a common requirement from SOC 2's Trust Services Criteria.
The Requirement (The "What"): SOC 2 Common Criteria 6.1 states that the entity must implement logical access security measures to protect information assets from security events.
This is the high-level objective. It doesn't mention passwords, MFA, or hardware keys. It just says, "protect against unauthorized access."
The Controls (The "How"): An organization can't just "do" CC6.1. It must implement a system of controls to meet this requirement. Here’s how that breaks down, using hardware security keys as an example:
Control 1: Access Control Policy (Administrative - Preventive)
What it is: A high-level document approved by management.
What it does: It formally states the rules. For example: "Access to sensitive systems must be granted based on the principle of least privilege and authenticated using multi-factor authentication (MFA)." This policy is the foundation.
Control 2: MFA with Hardware Keys (Technical - Preventive)
What it is: The technology chosen to enforce the policy.
What it does: The organization configures its identity provider (like Okta or Azure AD) to require a FIDO2-compliant hardware security key (e.g., a YubiKey) in addition to a password for every login to a critical system. This is a powerful technical control. But the technology alone is not enough.
Control 3: Hardware Key Lifecycle Management (Administrative - Preventive)
What it is: The documented processes for managing the physical keys. This is where many companies fall short.
What it does: This control is actually a set of procedures:
Issuance Process: When a new employee starts, HR triggers a ticket. IT meets with the employee, verifies their identity against government ID, issues them a new key from a secure inventory, and records the key's serial number in an asset management system tied to that employee's identity.
Revocation Process: When an employee leaves, the offboarding checklist includes a step for IT to immediately de-register their key from all systems. The physical key is collected and securely destroyed.
Loss/Theft Process: A procedure for an employee to report a lost key, for IT to immediately revoke it, and for a new one to be issued after identity verification.
Control 4: Quarterly User Access Reviews (Administrative - Detective)
What it is: A periodic check to catch errors or unauthorized access.
What it does: Every three months, an automated report is generated showing every user and their access levels to critical systems. This report is sent to the user's manager, who must review and formally approve that the access is still required for their job role. This detective control verifies that the preventive controls are working correctly over time.
As you can see, one high-level requirement spawned a whole ecosystem of interconnected controls—administrative and technological—that work together to achieve the objective of the requirement.
The Bottom Line
The bottom line is simple: Requirements set the objectives; controls are the specific actions you take to get there. A mature GRC program is built on a clear understanding of this dynamic, translating high-level objectives into the real-world policies, processes, and technologies that keep an organization secure and compliant.
Join our next Bootcamp
Human interaction cannot be replaced by AI. That’s why we are hosting our first ever ISO 27001 Bootcamp starting Nov 1st, 2025!
Sign up by Oct 15th for a 15% early bird discount.
Test your Knowledge
Today’s question is from the CISM curriculum:
What is the MAIN reason for implementing multi-factor authentication?
A) To increase user convenience
B) To meet compliance requirements
C) To enhance security
D) To reduce costs
👉 Think you know the answer? Scroll down for the solution!
Share the Lab
Give yourself a free “MBA” in GRC with our library of must-have resources for every GRC professional.
👉 Refer just 1 friend and we’ll send over the database.
Your current referral count: {{ rp_num_referrals }}
Or share your personal link with others: {{ rp_refer_url }}
Your Feedback Matters
How helpful was today's Email?
Answer: The correct answer is C.
A) Multi-factor authentication may actually reduce user convenience.
B) Compliance may require it, but the main reason is to enhance security.
C) Multi-factor authentication provides multiple layers of security.
D) It may actually increase costs due to the need for additional hardware or software.