CYBOK 3,1 Regulatory frameworks
Relevant learning outcomes and example products
- Analysing & Advising
- Designing & Realising
- Managing & Collaborating
Depending on your project, possible products include:
- a scoped regulatory applicability analysis;
- a regulatory landscape showing relevant laws, regulations, standards, contracts and internal policies;
- a requirements traceability matrix linking external requirements to design decisions, controls and evidence;
- a short regulatory impact advice for a Product Owner or other stakeholder;
- a gap analysis comparing the current situation with selected requirements;
- a set of security or privacy requirements derived from an applicable regulatory framework;
- a responsibility map showing relevant roles, owners, regulators and other stakeholders.
1. Why regulatory frameworks matter
Cyber security work is influenced by more than technical requirements. Organisations may need to follow:
- laws and regulations;
- sector-specific rules;
- contracts;
- standards;
- regulator guidance;
- internal policies.
These frameworks can influence decisions about:
- access control;
- logging;
- incident reporting;
- vulnerability handling;
- data storage and retention;
- supplier security;
- secure product development;
- governance and accountability.
Your task is not to memorise every framework. Your task is to determine:
- what may apply;
- why it may apply;
- what the relevant requirement means for the case;
- what should be changed, designed or implemented;
- how your conclusion can be traced back to a source.
2. Core concepts
Do not treat every external framework as the same type of source.
| Concept | Basic meaning | Example |
|---|---|---|
| Law / legislation | Legally binding rules created through a legislative process. | National law |
| EU regulation | EU legal act that is directly applicable in Member States. | GDPR, CRA |
| EU directive | EU legal act that normally requires implementation in national law. | NIS2 |
| Standard | Agreed requirements or good practices. Not automatically law. | ISO/IEC 27001 |
| Contract | Binding agreement between parties. | SLA, supplier agreement |
| Guidance | Explanation or recommended practice from an authority or expert body. | Regulator guidance |
| Internal policy | Rules created by an organisation for its own operation. | Access control policy |
A common mistake is to write:
“ISO 27001 is legally required.”
That is incomplete unless you can show the legal, contractual, sector-specific or organisational basis for that claim.
3. Start with applicability
Do not begin with:
“How do we comply with NIS2?”
First ask:
“Does NIS2 apply to this organisation and this situation?”
Applicability can depend on factors such as:
- type of organisation;
- sector;
- role of the organisation;
- product or service;
- processing of personal data;
- geographic location;
- users or customers served;
- organisation size;
- thresholds;
- exclusions;
- national implementation.
Useful starting questions
Ask:
- What organisation or system am I analysing?
- What does the organisation actually do?
- What data is processed?
- Which products or services are involved?
- Which countries or jurisdictions are relevant?
- Which external parties are involved?
- Which role does the organisation have?
- Which facts are still unknown?
Do not claim that a framework applies until you can explain the trigger.
4. Important examples to investigate
The following frameworks are common starting points in European cyber security projects. They do not automatically apply to every case.
GDPR
Investigate the GDPR when personal data is processed.
Possible topics:
- controller and processor roles;
- processing principles;
- security of processing;
- personal data breaches;
- accountability;
- retention;
- access to personal data.
Do not reduce GDPR to consent. Determine what data is processed, why it is processed and which role each organisation has.
NIS2
Investigate NIS2 when an organisation may fall within the relevant entity and sector scope.
Possible topics:
- cyber security risk-management measures;
- management responsibility;
- incident reporting;
- supply-chain security;
- business continuity;
- governance.
Because NIS2 is a directive, investigate the relevant national implementation.
Cyber Resilience Act
Investigate the Cyber Resilience Act when a product with digital elements may be in scope.
Possible topics:
- product security requirements;
- vulnerability handling;
- manufacturer responsibilities;
- conformity assessment;
- reporting duties;
- security support during the product lifecycle.
Do not assume that every software project is automatically in scope.
ISO/IEC 27001
ISO/IEC 27001 is a standard for information security management systems.
Investigate why it is relevant in the case. For example:
- certification objective;
- customer requirement;
- contractual obligation;
- procurement requirement;
- internal governance framework.
5. Source quality
Use strong sources for important conclusions.
Start with:
- official legal text;
- official national legislation;
- competent regulators and supervisory authorities;
- official standards where available;
- authoritative guidance;
- secondary sources for orientation.
Useful starting points include:
Blogs, vendor pages and summaries can help you find terminology, but they should not be the only basis for an important conclusion.
6. Expectations at Level 3
At Level 3, you are expected to go beyond identifying and describing a regulatory framework. You should independently investigate applicability, interpret relevant requirements in context and translate them into justified recommendations, requirements or design decisions.
You are expected to answer questions such as:
- Why is this framework relevant to this specific case?
- What exact fact triggers its possible applicability?
- Which role does the organisation have?
- How can your conclusion be verified?