Governance · Topic 7 of 7
Risk Frameworks and Legal, Regulatory and Contractual Requirements
CRISC risk frameworks and obligations: COBIT 2019, Risk IT, NIST 800-39 and 800-37, ISO 27005, plus laws, regulation and contracts mapped to controls.
- 5 min
- COBIT 2019: EDM for governance; APO, BAI, DSS, MEA for management; APO12 is managed risk.
- NIST SP 800-39: frame, assess, respond, monitor at three tiers.
- NIST SP 800-37 Rev 2 RMF steps start with Prepare and end with Monitor.
What it is
A risk framework gives the organization a structured, repeatable way to govern and manage risk. Legal, regulatory and contractual requirements are obligations the organization must meet, and failing to meet them is itself a source of risk.
The practitioner selects or tailors frameworks to fit the business, identifies which obligations apply, and evaluates whether business practices actually align with them.
How it works
Main risk frameworks and standards
| Framework | What it offers |
|---|---|
| COBIT 2019 | Governance and management objectives for enterprise IT. Governance domain EDM (Evaluate, Direct and Monitor); management domains APO, BAI, DSS and MEA. EDM03 covers ensured risk optimization; APO12 covers managed risk. |
| ISACA Risk IT Framework | IT risk governance, evaluation and response, aligned with COBIT 2019 |
| ISO 31000:2018 | Generic risk management principles, framework and process for any organization |
| ISO/IEC 27005:2022 | Information security risk management guidance supporting ISO/IEC 27001 |
| NIST SP 800-39 | Organization-wide risk management at three tiers (organization, mission and business process, information system), with four components: frame, assess, respond, monitor |
| NIST SP 800-37 Rev 2 | Risk Management Framework for systems: Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor |
| NIST SP 800-30 Rev 1 | Guide for conducting risk assessments |
| COSO ERM (2017) | Enterprise risk management integrated with strategy and performance |
No single framework is mandatory for every organization. The practitioner chooses based on industry, regulation, size and maturity, and tailors it rather than copying it whole.
Legal and regulatory requirements
| Type | Examples |
|---|---|
| Privacy and data protection | EU GDPR, national privacy laws |
| Financial reporting | US Sarbanes-Oxley Act section 404 on internal control over financial reporting |
| Sector rules | Health data laws such as HIPAA in the US, banking supervision rules |
| Operational resilience and cyber | EU DORA for financial entities, applying from 17 January 2025; EU NIS2 Directive for essential and important entities |
Legal counsel and compliance interpret the law. The practitioner makes sure each obligation is in the risk register or obligations register, mapped to controls with owners, and monitored. Non-compliance risk includes fines, sanctions, loss of licence and reputational damage.
Contractual requirements
Contracts create obligations too. Examples are service level agreements (SLAs), data protection clauses with customers, right to audit clauses, and industry schemes such as PCI DSS that card brands enforce through contracts with merchants and their banks. A breach of contract can lead to penalties, lost customers and litigation.
| Clause type | Risk relevance |
|---|---|
| Service levels | Penalties if availability or response targets are missed |
| Data handling | Liability if customer data is misused or exposed |
| Breach notification | Deadlines to tell customers about incidents |
| Audit rights | Customers or regulators can inspect controls |
Mapping and alignment
Many obligations overlap. Mapping requirements from several sources to one common control set lets the organization implement once and evidence many times. The practitioner also compares actual practice with the frameworks the organization claims to follow, because adopting a framework on paper is not the same as operating it.
A worked example
A payments company operating in the EU learns that it falls under DORA. The practitioner works with compliance to list DORA's requirements, such as ICT risk management, incident reporting, resilience testing and third-party risk management.
Each requirement is mapped to the existing ISO/IEC 27001 control set. Most are already met, but gaps appear in the register of ICT third-party arrangements and in resilience testing. These gaps go into the risk register with owners and dates, and the board receives a summary.
How the exam asks about this
- "What should the risk practitioner do FIRST when a new regulation is announced?" Determine with legal and compliance whether and how it applies to the organization.
- "What is the BEST reason to map requirements to a common control framework?" To meet overlapping obligations efficiently and avoid duplicate controls.
- "Which is the MOST important factor in choosing a risk framework?" That it fits the organization's business, regulatory environment and objectives.
What to remember for the exam
- COBIT 2019: EDM for governance; APO, BAI, DSS, MEA for management; APO12 is managed risk.
- NIST SP 800-39: frame, assess, respond, monitor at three tiers.
- NIST SP 800-37 Rev 2 RMF steps start with Prepare and end with Monitor.
- Legal counsel interprets laws; the practitioner maps obligations to controls and owners.
- Contracts such as SLAs and data clauses are risk sources just like laws.
Adopting a framework is not the same as complying with it. When asked what gives the BEST assurance of alignment, choose evidence that practices actually operate as the framework requires.
Common mistakes
Adopting a framework unchanged. Frameworks must be tailored to the organization's size, sector and risk.
Ignoring contracts. SLAs, customer data clauses and card scheme rules carry real penalties.
Letting the practitioner interpret law alone. Legal and compliance interpret; risk maps and monitors.
Check yourself
What are the four components of risk management in NIST SP 800-39?
Frame, assess, respond and monitor, applied across the organization, mission and business process, and system tiers.
Why map several regulations to one control framework?
Overlapping requirements can be met by the same controls, which reduces cost and gives one set of evidence for many obligations.
Give two examples of contractual requirements that create IT risk.
Service level agreements with penalties for downtime, and customer data protection clauses that create liability for breaches.
Topic 7 of 7 in Governance
Test yourself on Governance
The full ISACA CRISC question bank has 1,000 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by ISACA. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.