Standards, Frameworks and Regulatory Obligations

Introduction

Cyber risk management is not governed by a single universal standard. Organisations typically combine risk-management frameworks, information-security standards, control catalogues, governance models, privacy laws, sector regulations and audit requirements. The professional challenge is therefore not merely to “implement a framework,” but to determine which obligations apply, interpret their different purposes, map them coherently, and produce evidence that is proportionate to risk.

A framework normally provides an organised way of thinking and acting. A standard may specify requirements against which conformity can be assessed. A control catalogue provides safeguards or practices. A law creates enforceable obligations. An audit requirement defines how evidence, assurance and accountability are examined. These categories overlap, but they should not be treated as interchangeable.

This chapter examines the NIST Cybersecurity Framework (CSF), NIST Risk Management Framework (RMF), ISO/IEC 27001, ISO/IEC 27005, COBIT and the CIS Controls. It then places them within privacy, cybersecurity, sectoral and audit obligations. The central theme is interoperability: a mature cyber-risk programme uses one integrated risk logic while translating it into multiple forms of compliance evidence.

Learning Objectives

By the end of this chapter, students should be able to:

1. Distinguish standards, frameworks, control catalogues, laws and audit criteria.
2. Explain and compare NIST CSF, NIST RMF, ISO/IEC 27001, ISO/IEC 27005, COBIT and CIS Controls.
3. Select frameworks according to organisational context, risk profile and assurance needs.
4. Construct a cross-framework mapping without assuming that similarly named controls are identical.
5. Analyse privacy, cybersecurity, sectoral and audit obligations.
6. Design a compliance strategy based on risk, accountability, evidence and continuous improvement.
7. Evaluate limitations, conflicts and emerging issues, including cloud services and artificial intelligence.

1. The Architecture of Cyber Governance

1.1 Five kinds of instrument

Law and regulation establish duties imposed by a jurisdiction or regulator. Examples include data-protection legislation, breach-notification rules, critical-infrastructure regulation and financial-sector requirements. Laws often use principles such as security, accountability, necessity and proportionality rather than prescribing one technical configuration.

Standards define agreed requirements or practices. ISO/IEC 27001, for example, specifies requirements for an information security management system (ISMS). Certification is possible when an accredited conformity-assessment process is used, although certification does not prove that an organisation is risk-free.

Frameworks organise activities, outcomes or decision processes. NIST CSF helps organisations communicate and manage cybersecurity risk; NIST RMF provides a structured lifecycle for selecting, implementing and authorising controls, particularly in systems subject to federal information-security governance.

Control catalogues describe safeguards. CIS Controls provide prioritised practices, while NIST SP 800-53 provides a broad catalogue of security and privacy controls. A catalogue is not automatically a complete management system.

Audit and assurance criteria determine whether claims are supported by sufficient, appropriate evidence. Financial reporting controls, service-organisation assurance reports and regulatory examinations may require different evidence even where the underlying technical control is similar.

1.2 Risk, compliance and assurance

Risk management asks: “What could happen, how severe would it be, and what should we do?” Compliance asks: “What obligations apply, and can we demonstrate that they are met?” Assurance asks: “Can an independent and competent party rely on the evidence?”

These questions are related but not equivalent. Compliance can reduce risk, but a compliant organisation may still be vulnerable because a regulation may be outdated, narrowly scoped or satisfied through ineffective implementation. Conversely, a risk-based safeguard may be valuable even when no law explicitly requires it.

A useful governance model has three lines:

• First line: operational and technology owners manage risks and operate controls.
• Second line: risk, compliance and security functions establish policy, advise and monitor.
• Third line: internal audit provides independent assurance to the governing body.

External auditors, regulators and certification bodies provide additional forms of assurance, but they do not replace management responsibility.

2. NIST Cybersecurity Framework

The NIST Cybersecurity Framework 2.0 is a flexible, outcome-oriented framework for managing cybersecurity risk. It is not a prescriptive checklist and does not require a particular technology. Its Core is organised around six Functions:

The addition of Govern in CSF 2.0 makes explicit what earlier versions often treated as contextual: cybersecurity is a governance and enterprise-risk issue, not only an operational security issue.

CSF outcomes are organised into Categories and Subcategories. Organisations may use Organisational Profiles to describe current and target outcomes and identify gaps. Tiers—Partial, Risk-Informed, Repeatable and Adaptive—characterise the maturity and sophistication of risk-management practices; they are not a simple compliance score.

Strengths and limitations

CSF is accessible, technology-neutral and effective for executive communication. It supports prioritisation and can be used by small and large organisations. However, it does not itself provide a detailed audit-ready control set, certification scheme or complete risk methodology. Organisations normally supplement it with NIST SP 800-53, CIS Controls, ISO/IEC 27001 controls or sector-specific requirements.

3. NIST Risk Management Framework

The NIST RMF is a structured process for managing security and privacy risk throughout the system life cycle. Its principal steps are:

1. Prepare: establish organisational and system-level context, priorities, common controls and risk assumptions.
2. Categorize: determine the potential impact of loss of confidentiality, integrity and availability.
3. Select: choose and tailor controls based on risk, mission, system type and environment.
4. Implement: implement controls and document how they operate.
5. Assess: test control design and effectiveness using defined assessment procedures.
6. Authorize: a responsible official accepts or rejects residual risk and permits operation.
7. Monitor: continuously monitor controls, threats, changes and system risk.

Categorization is commonly expressed through low, moderate or high impact levels for confidentiality, integrity and availability. The impact level is not a probability estimate; it represents the magnitude of harm if an adverse event occurs. A system can, for example, have high confidentiality impact but moderate availability impact.

The RMF emphasises explicit accountability. The authorizing official accepts residual risk; the system owner manages the system; security and privacy personnel advise and assess; and control owners provide evidence. This separation prevents a technical team from silently accepting enterprise risk without delegated authority.

RMF is especially useful where systems must be authorised, continuously monitored and integrated with formal government or high-assurance processes. It can be demanding for smaller organisations unless proportionately tailored.

4. ISO/IEC 27001 and ISO/IEC 27005

4.1 ISO/IEC 27001: the management system

ISO/IEC 27001 specifies requirements for an ISMS. Its logic is based on organisational context, leadership, planning, support, operation, performance evaluation and improvement. The standard requires an organisation to:

• define the ISMS scope;
• understand internal and external issues and interested parties;
• establish information-security policy and leadership responsibility;
• perform a repeatable risk assessment and risk treatment process;
• select controls and document applicability;
• monitor, measure, audit and review performance; and
• correct nonconformities and continually improve.

The Statement of Applicability records which controls are included or excluded, the justification for decisions and the implementation status. It is not merely an administrative list: it should demonstrate how risk assessment, legal obligations, business requirements and control selection are connected.

ISO/IEC 27001 is compatible with certification, but certification has boundaries. It applies to the defined ISMS scope, not automatically to every group company, product or supplier. It also provides reasonable assurance of conformity with requirements, not a guarantee against compromise.

4.2 ISO/IEC 27005: information-security risk management

ISO/IEC 27005 provides guidance for information-security risk management and supports ISO/IEC 27001 implementation. Its practical logic includes establishing context, identifying risk, analysing or evaluating risk, treating risk, communicating and consulting, monitoring and reviewing, and recording results.

Risk treatment options include avoiding, modifying, sharing or retaining risk. Risk acceptance should be explicit, time-bounded where appropriate and assigned to an accountable authority. ISO/IEC 27005 is guidance rather than a certification standard; it does not replace the organisation’s own risk criteria.

A simple conceptual model is:

Here, likelihood expresses the chance or frequency of an event under stated assumptions, and impact expresses consequences such as financial loss, safety harm, legal exposure or service disruption. This multiplicative expression is a decision aid, not a universal measurement law. Many organisations use ordinal scales, qualitative matrices or more detailed quantitative models. Scores must not be compared across departments unless scales, definitions and assumptions are consistent.

5. COBIT: Governance and Management of Enterprise Information and Technology

COBIT, published by ISACA, is an enterprise governance and management framework for information and technology. It distinguishes governance from management:

• Governance evaluates stakeholder needs, sets direction and monitors performance and conformance.
• Management plans, builds, runs and monitors activities in accordance with that direction.

COBIT 2019 uses governance and management objectives grouped into domains:

• EDM: Evaluate, Direct and Monitor;
• APO: Align, Plan and Organize;
• BAI: Build, Acquire and Implement;
• DSS: Deliver, Service and Support;
• MEA: Monitor, Evaluate and Assess.

COBIT is valuable for boards, audit committees and senior management because it connects technology objectives with enterprise goals, risk optimisation, resource optimisation and benefits realisation. Its design factors allow tailoring according to enterprise strategy, risk profile, threat landscape, compliance requirements, sourcing model and technology adoption.

COBIT is not primarily a technical hardening guide. A COBIT governance objective may require managed security services, risk optimisation or performance monitoring, but detailed technical practices must be obtained from more specialised standards and control catalogues.

6. CIS Controls

The CIS Critical Security Controls are prioritised, actionable safeguards intended to reduce common cyberattack risks. They are particularly useful for organisations seeking a practical implementation sequence. The Controls address areas such as asset inventory, software inventory, data protection, secure configuration, account management, vulnerability management, audit logging, malware defence, email and browser protections, incident response and penetration testing.

Implementation Groups help organisations select safeguards according to resources, risk and exposure. A smaller organisation should not interpret prioritisation as permission to ignore governance, privacy or legal duties; rather, it should use the Groups to stage implementation.

CIS Controls are operationally concrete, but they do not by themselves establish an ISMS, enterprise governance model or complete legal compliance programme. Their strongest use is often as an implementation layer beneath CSF, ISO/IEC 27001 or COBIT.

7. Comparative Analysis

No single framework is “best” in every situation. Selection should consider regulatory jurisdiction, customer expectations, assurance needs, organisational size, system criticality, supply-chain dependence, existing capability and cost of implementation.

8. Cross-Framework Mapping

A crosswalk is a structured relationship between requirements, outcomes, controls, procedures and evidence from different instruments. It reduces duplicate work but must not imply equivalence without analysis.

A robust mapping process is:

1. Define scope: identify entities, systems, data, services, locations and suppliers.
2. Collect authoritative sources: use the applicable versions of standards, laws, contracts and regulator guidance.
3. Normalise concepts: distinguish requirements, outcomes, controls, procedures and evidence.
4. Map at the right granularity: relate one requirement to one or more controls and identify partial coverage.
5. Record gaps and overlaps: note controls that are broader, narrower or differently worded.
6. Assign ownership: identify control owners, evidence owners and accountable risk owners.
7. Validate implementation: confirm that documented controls operate in practice.
8. Maintain change control: update mappings when frameworks, systems, laws or threats change.

A mapping register can contain the following fields:

For example, an access-control policy may support a CSF Protect outcome, an ISO/IEC 27001 control, a COBIT management objective and a CIS safeguard. Yet one policy document does not prove that access is reviewed, privileged accounts are monitored, leavers are removed promptly and exceptions are approved. Mapping must therefore be evidence-based.

9. Privacy, Cybersecurity and Sectoral Obligations

9.1 Privacy obligations

Privacy laws commonly require lawful processing, purpose limitation, data minimisation, accuracy, retention control, data-subject rights, processor governance, breach response and appropriate technical and organisational measures. Exact duties depend on jurisdiction and the organisation’s role as controller, processor, public body or service provider.

Privacy risk is not identical to cybersecurity risk. A system may be secure yet process excessive data unlawfully. Conversely, a lawful processing activity may suffer a security breach. Privacy impact assessments, records of processing, retention schedules, data-protection agreements and rights-handling procedures should therefore be integrated with security risk management rather than treated as separate paperwork.

9.2 Cybersecurity and critical-infrastructure obligations

Cybersecurity laws may impose incident reporting deadlines, baseline safeguards, resilience requirements, vulnerability disclosure duties, supply-chain controls or executive accountability. Critical infrastructure, telecommunications, health, energy and public-sector organisations may face heightened obligations because disruption can affect safety, national security or essential services.

9.3 Sectoral and contractual requirements

Financial services may be subject to prudential, operational-resilience, outsourcing and payment-security requirements. Healthcare organisations may face confidentiality, integrity and availability obligations for clinical information. Payment environments may require cardholder-data safeguards. Cloud contracts may require audit rights, data-location commitments, incident notification and subcontractor transparency.

The applicable obligation is often determined by a combination of jurisdiction, sector, data type, service role, customer contract and materiality. A legal and regulatory inventory should record applicability decisions and their rationale.

10. Audit and Assurance Strategy

An audit-ready programme begins with assertions. Management may assert that access is authorised, backups are recoverable, incidents are reported and suppliers are monitored. Each assertion requires criteria, controls and evidence.

Evidence should be:

• relevant to the control and period tested;
• reliable and protected from unauthorised alteration;
• complete enough to support the conclusion;
• traceable to an owner, system and time period; and
• repeatable, so that another competent reviewer can reproduce the test.

A useful distinction is between design effectiveness and operating effectiveness. A quarterly access-review procedure may be well designed but ineffective if reviews are not performed, are performed late or do not result in remediation. Audit teams should also test exceptions, not only successful samples.

Internal audit should preserve independence from control operation. Management remains responsible for correcting deficiencies and accepting residual risk. A certification audit, regulatory examination, customer audit and internal audit may use different scopes and materiality judgments; one report should not automatically be presented as proof of all other obligations.

11. Compliance Strategy and Operating Model

A mature compliance strategy has six connected components.

First, establish governance. The board or governing body defines risk appetite and receives meaningful reporting. Executives assign authority, budget and accountability.

Second, build an obligation register. Record laws, regulations, contractual clauses, standards, customer requirements, reporting deadlines and responsible owners. Include applicability and interpretation notes.

Third, adopt a common control framework. Define internal control objectives in organisational language, then map them to external requirements. This is usually more efficient than creating a separate programme for every framework.

Fourth, integrate risk assessment. Assess business processes, information assets, suppliers, applications and services. Prioritise treatment according to impact, likelihood, legal duties, exploitability and cost. Do not allow a low numerical score to override a mandatory legal requirement.

Fifth, manage evidence continuously. Automate collection where appropriate, but retain human review for judgmental controls such as risk acceptance, privacy assessments and supplier criticality.

Sixth, measure and improve. Metrics may include overdue high-risk findings, patch timeliness, privileged-account review completion, recovery-test success, supplier-assessment coverage and incident-reporting timeliness. Metrics should support decisions rather than reward superficial compliance.

12. Illustrative Case: Meridian Health Cloud

Background

Meridian Health Cloud is a fictional regional healthcare provider moving patient scheduling and diagnostic-report services to a cloud platform. It processes sensitive personal and clinical information and relies on two critical software suppliers. Its board wants an ISO/IEC 27001 certification pathway, while the security team prefers NIST CSF and CIS Controls. The regulator requires incident notification and evidence of risk-based safeguards.

Problem

The organisation has many policies but cannot show which controls satisfy which obligations. Access reviews are inconsistent, supplier evidence is collected only during procurement, and incident records do not reliably identify whether a privacy breach has occurred.

Analysis

The organisation first defines the ISMS scope around the cloud-hosted services, supporting identity systems, clinical interfaces and relevant suppliers. It uses CSF Functions to create an executive profile, ISO/IEC 27005 principles for risk assessment and treatment, CIS Controls to prioritise asset inventory, identity, logging and vulnerability management, and COBIT objectives to clarify board oversight and performance reporting.

Because the services are high impact for confidentiality and availability, the organisation adopts RMF-style discipline even though formal NIST authorisation is not legally required. It documents system categorization, control owners, assessment results and an explicit residual-risk decision.

Approach and solution

Meridian creates a common control register. One internal control requires that workforce and supplier accounts be uniquely identified, approved, reviewed quarterly and disabled promptly when no longer needed. The register maps that control to relevant ISO requirements, CSF Protect outcomes, CIS account-management safeguards, privacy security obligations and contractual clauses.

The organisation implements central identity management, privileged-access monitoring, automated leaver notifications and quarterly review evidence. Supplier contracts require incident notification, subcontractor disclosure, appropriate security measures and cooperation with investigations. A privacy incident playbook is linked to the cybersecurity incident-response process.

Outcome

The organisation reduces duplicate questionnaires, identifies two previously unmapped suppliers and improves evidence retrieval. Its certification audit finds a minor documentation deficiency rather than a systemic control failure. The board receives a dashboard showing open high-risk findings, recovery-test results, supplier exposure and overdue access reviews.

Learning points

The case demonstrates that frameworks are complementary. CSF communicates outcomes, ISO/IEC 27001 structures the management system, ISO/IEC 27005 supports risk decisions, CIS Controls guides implementation, COBIT supports governance, and RMF-style authorization clarifies accountability. The result is not compliance by paperwork; it is a traceable relationship between obligations, risks, controls, evidence and decisions.

13. Challenges and Limitations

Framework proliferation can create duplicated assessments, inconsistent terminology and fatigue among control owners. Crosswalks may become obsolete when standards or laws change. A mapped requirement may appear covered even though the underlying control is poorly implemented. Certification can encourage scope minimisation or document-oriented behaviour. Quantitative risk scores can create false precision, particularly when data is scarce or impacts are difficult to monetise.

Global organisations also face conflicting data-localisation rules, different breach-reporting deadlines and divergent definitions of personal data. Cloud shared-responsibility models can produce gaps when customers assume that provider certification transfers all responsibility. Artificial-intelligence systems introduce further issues: training-data governance, model supply chains, prompt or data leakage, automated decision impacts, monitoring drift and unclear accountability. Existing frameworks remain useful, but AI-specific risk assessments and human oversight may be required.

14. Best Practices

• Use one enterprise control language and map outward to multiple requirements.
• Treat legal interpretation as a documented professional judgment, not an informal assumption.
• Keep scope, asset inventories and supplier inventories current.
• Separate control ownership, risk acceptance and independent assurance.
• Link each important control to evidence, frequency, exceptions and remediation.
• Use risk-based prioritisation while preserving non-negotiable legal duties.
• Test whether controls operate effectively, not merely whether policies exist.
• Review mappings after regulatory, technological, organisational or threat changes.
• Report residual risk and uncertainty honestly to decision-makers.
• Integrate privacy, resilience, cloud and AI considerations into the main risk programme.

Chapter Summary

Cyber risk governance requires coordinated use of different instruments. NIST CSF organises cybersecurity outcomes and communication; NIST RMF provides a lifecycle for categorization, control selection, assessment, authorization and monitoring. ISO/IEC 27001 establishes an auditable ISMS, while ISO/IEC 27005 guides information-security risk management. COBIT connects information and technology governance with enterprise objectives, and CIS Controls provide prioritised operational safeguards.

Laws and regulations create binding obligations, whereas standards and frameworks generally provide structured methods or evidence expectations. Privacy, sectoral, contractual and audit requirements must be identified through an obligation register and translated into internal controls. Effective cross-framework mapping requires scope discipline, control-level analysis, ownership, evidence and continuous maintenance. The objective is not to accumulate certificates or checklists, but to make defensible risk decisions and demonstrate that safeguards operate effectively.

Key Terms

Authorizing official: Person empowered to accept residual system risk and permit operation.

CIS Controls: Prioritised safeguards for reducing common cybersecurity risks.

COBIT: Governance and management framework for enterprise information and technology.

Control catalogue: Structured collection of safeguards or control statements.

Cross-framework mapping: Relating requirements or outcomes from different instruments to common internal controls.

Cybersecurity Framework (CSF): NIST framework for communicating and managing cybersecurity risk.

Evidence: Information supporting the design or operation of a control.

ISMS: Information security management system defined by ISO/IEC 27001.

ISO/IEC 27001: Requirements standard for an information security management system.

ISO/IEC 27005: Guidance for information-security risk management.

NIST RMF: Lifecycle process for managing security and privacy risk in systems.

Obligation register: Maintained inventory of applicable legal, regulatory, contractual and voluntary requirements.

Residual risk: Risk remaining after safeguards and treatments are applied.

Risk appetite: Amount and type of risk an organisation is willing to pursue or retain.

Statement of Applicability: ISO/IEC 27001 record explaining selected, excluded and implemented controls.

Three lines model: Separation of operational ownership, oversight and independent assurance.

Tier: NIST CSF description of the sophistication and repeatability of cybersecurity risk management.

Control owner: Person responsible for operating or maintaining a control.

Review Questions

5 Short Answer Questions

1. Distinguish a law, a framework, a standard and a control catalogue.
2. What are the six Functions of NIST CSF 2.0?
3. What is the purpose of the ISO/IEC 27001 Statement of Applicability?
4. Why is residual-risk acceptance an accountability decision?
5. State two characteristics of reliable audit evidence.

5 Long Answer Questions

1. Compare NIST CSF and NIST RMF in terms of purpose, lifecycle, outputs and suitable organisational contexts.
2. Explain how ISO/IEC 27001 and ISO/IEC 27005 work together in an ISMS.
3. Analyse the differences between COBIT and CIS Controls and explain why an organisation may need both.
4. Describe a complete process for constructing and maintaining a cross-framework control mapping.
5. Discuss why legal compliance does not necessarily demonstrate effective cybersecurity risk management.

3 Analytical / Application Questions

1. A multinational cloud provider operates in healthcare and financial services. Design a framework architecture using at least four instruments from this chapter and justify the role of each.
2. An organisation has a documented access-control policy but repeated failures in quarterly reviews and leaver deprovisioning. Analyse the likely audit conclusion and propose corrective actions.
3. Develop an obligation-to-control mapping approach for a new AI service processing personal data. Identify governance, privacy, security, supplier and assurance issues that should be addressed.

Multiple Choice Questions with Answers

Question 1

Which NIST CSF 2.0 Function explicitly addresses cybersecurity strategy, roles, policy and oversight?

A. Govern

B. Protect

C. Detect

D. Recover

Correct Answer: A. Govern

Question 2

Which NIST RMF step includes formal permission for a system to operate based on accepted residual risk?

A. Categorize

B. Authorize

C. Implement

D. Monitor

Correct Answer: B. Authorize

Question 3

What is the principal purpose of ISO/IEC 27001?

A. To provide a vulnerability-scanning tool

B. To specify requirements for an information security management system

C. To define only privacy rights

D. To replace all sectoral regulations

Correct Answer: B. To specify requirements for an information security management system

Question 4

Which instrument is primarily focused on governance and management of enterprise information and technology?

A. COBIT

B. CIS Controls

C. ISO/IEC 27005

D. NIST CSF Profiles

Correct Answer: A. COBIT

Question 5

What does a Statement of Applicability primarily document?

A. All employee training attendance

B. Selected and excluded ISO controls and the reasons for those decisions

C. A list of criminal investigations

D. Only the organisation’s hardware inventory

Correct Answer: B. Selected and excluded ISO controls and the reasons for those decisions

Question 6

Which statement best describes CIS Controls?

A. They are prioritised, actionable cybersecurity safeguards

B. They are a privacy law with breach penalties

C. They are an accreditation body for auditors

D. They are a replacement for organisational governance

Correct Answer: A. They are prioritised, actionable cybersecurity safeguards

Question 7

Why should a cross-framework mapping identify partial coverage?

A. Because similarly worded requirements may differ in scope or evidence

B. Because all frameworks prohibit common controls

C. Because mappings are valid only for technical controls

D. Because laws never apply to suppliers

Correct Answer: A. Because similarly worded requirements may differ in scope or evidence

Question 8

Which distinction is central to audit testing?

A. Confidentiality versus availability only

B. Design effectiveness versus operating effectiveness

C. Internal audit versus encryption

D. Policy length versus policy colour

Correct Answer: B. Design effectiveness versus operating effectiveness

Question 9

Which statement about privacy risk is most accurate?

A. Privacy risk and cybersecurity risk are identical

B. Privacy risk exists only after a security breach

C. A system may be secure yet process excessive data unlawfully

D. Privacy obligations apply only to public-sector organisations

Correct Answer: C. A system may be secure yet process excessive data unlawfully

Question 10

In the illustrative case, why was RMF-style discipline adopted even without a formal RMF mandate?

A. To eliminate the need for privacy controls

B. To clarify system impact, control accountability and residual-risk decisions

C. To obtain automatic ISO certification

D. To avoid maintaining supplier records

Correct Answer: B. To clarify system impact, control accountability and residual-risk decisions