Skip to content
English
Customer portal
Contact us
  • There are no suggestions because the search field is empty.

00.05 A Practitioner's Tour of GRC Frameworks

A working orientation to the major GRC frameworks SimpleRisk customers run — NIST RMF, NIST CSF, ISO 27001/27005, COSO ERM, FAIR, SOC 2, SCF, and UCF — what each is for, who uses it, and where it shows up in SimpleRisk.

Why this matters

Most working GRC programs run more than one framework, and most of those frameworks were written for slightly different audiences than the program is using them for. A startup chasing a SOC 2 report ends up reading control objectives that were drafted for service organizations of any kind, not specifically for software companies. A federal contractor running NIST RMF reads control families designed for federal information systems, not for the contractor's commercial division. The framework was built once; the program adopts it forever; the gap between the two has to be bridged by the people actually doing the work.

This article is a working orientation to the frameworks SimpleRisk customers see most often. It isn't a reference (the official documents do that better) and it isn't a how-to (the chapters on compliance and risk management cover the SimpleRisk operations). The point is to make the framework landscape navigable: what's each one for, what's its style, who's the typical reader, and where does it show up in SimpleRisk. Once you've placed the frameworks against each other, picking the one (or three) that fits a given audit conversation gets considerably easier.

The other reason for the tour: every framework is opinionated, and the opinions show. NIST publications read like federal procurement documents because they are. ISO standards read like ISO standards. COSO reads like the boardroom. FAIR reads like an engineering paper. The voice of the framework shapes what its readers expect from a program. If you're translating a NIST-shaped program into ISO language for an auditor, knowing the difference saves you from defending the wrong thing.

How frameworks describe this

A useful first cut is by category. The frameworks below fall into four buckets, and the bucket usually tells you what the framework is good for before you read a word of it.

  • Lifecycle frameworks describe the steps of running a security or risk program end-to-end. NIST RMF and NIST CSF are the dominant ones; ISO 27005 fits here too in its risk-specific scope.
  • Control catalogs enumerate specific controls a program can adopt. NIST SP 800-53 is the foundational catalog; the SCF and UCF are meta-catalogs that cross-map many control libraries to a single backbone.
  • Reporting and assurance frameworks describe what an external party will look at to evaluate the program. SOC 2 is the prevalent one in commercial SaaS; ISO 27001 is its international counterpart and the certifiable form of an ISMS.
  • Methodologies describe how to do a specific GRC activity. NIST SP 800-30 covers the risk-assessment activity; FAIR covers quantitative loss-exposure analysis. They aren't whole-program frameworks; they're tools you apply within whichever lifecycle you're using.

Most working programs use a mix: a lifecycle framework as the spine, a control catalog as the population, and an assurance framework as the audit target. SimpleRisk is built to make the combination tractable.

How SimpleRisk implements this

What follows is the working orientation to each framework, in roughly the order SimpleRisk customers ask about them.

  • NIST Risk Management Framework (RMF) — The federal information-security lifecycle, organized as seven steps (Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor). RMF is the governing framework for almost every federal information system and a frequent reference point for federal contractors. SimpleRisk supports RMF through the underlying control catalog (NIST SP 800-53) and through the lifecycle-shaped flow of risk submission, review, treatment, and monitoring (see The GRC Program Lifecycle). RMF is the right starting point if your audit audience is federal or your contracts cite FedRAMP.

  • NIST SP 800-53 Security and Privacy Controls for Information Systems and Organizations — The control catalog RMF selects from. Hundreds of controls organized into roughly two dozen families (AC for access control, AU for audit, IR for incident response, and so on). SimpleRisk's control model was originally built around 800-53 and the default control catalog is 800-53-shaped. If you're running RMF or any framework that cites 800-53 by reference (a long list, including SOC 2's mapping documents), the SimpleRisk control catalog is already organized in a way you'll recognize.

  • NIST Cybersecurity Framework (CSF) v2.0 — The voluntary commercial counterpart to RMF. CSF v2.0 (Feb 2024) organizes cybersecurity activities into six functions: Govern, Identify, Protect, Detect, Respond, and Recover. The Govern function was added in v2.0 on top of the original five-function v1.1, which is why older blog posts and customer documents may describe the five-function version; cite v2.0 explicitly when the distinction matters. CSF is widely used by US commercial companies that don't have a federal reason to use RMF and don't have an international reason to use ISO 27001. SimpleRisk supports CSF as an installable framework with the categories and subcategories prepopulated; you map your existing controls to the subcategories and SimpleRisk tracks coverage.

  • NIST SP 800-30 Guide for Conducting Risk Assessments — The methodology document for the risk-assessment activity in the federal context. Threat sources, vulnerabilities, likelihood, and impact analysis. SimpleRisk's Classic risk-scoring methodology is 800-30-aligned; if your assessment process cites 800-30 you'll find the SimpleRisk scoring conventions familiar.

  • ISO/IEC 27001 Information Security Management Systems — Requirements — The international standard for an information security management system (ISMS), and the closest thing to a unified GRC framework in a single document. Certifiable: an organization can pursue and earn ISO 27001 certification through an accredited certification body, and that certification is the international equivalent of a SOC 2 report in many contexts. SimpleRisk supports ISO 27001 as an installable framework; the Annex A controls are prepopulated and the requirement clauses (5 through 10) are tracked through the policy and exception modules.

  • ISO/IEC 27005 Information Security Risk Management — The methodology document for the risk-management activity inside an ISMS. ISO 27005 is to ISO 27001 what 800-30 is to RMF: the how-to layer for risk assessment and treatment. SimpleRisk's Custom scoring methodology is the most ISO-27005-friendly because it lets you parametrize the assessment to whichever risk taxonomy your ISMS specifies.

  • COSO Enterprise Risk Management — The Committee of Sponsoring Organizations of the Treadway Commission's framework for enterprise risk management. COSO is more strategic and less technology-centric than the NIST or ISO families: its risk taxonomy spans strategic, operational, financial, compliance, and reporting risks under one tent. The audience is the board and the audit committee, not the security team specifically. SimpleRisk's risk register can hold COSO-style risks alongside cyber risks because the register is risk-type-neutral; the Custom scoring methodology lets you score strategic risks against the same scale as technical ones if you want a single board view.

  • Factor Analysis of Information Risk (FAIR) — A quantitative risk-analysis methodology that expresses risk in dollars (loss exposure) using probability distributions for loss event frequency and loss magnitude. FAIR is the right tool when leadership wants risk reported in monetary terms and when the cost of doing the analysis (FAIR is more analytically expensive than ordinal scoring) is justified by the decisions that follow from it. SimpleRisk doesn't ship a native FAIR scoring methodology, but the Custom methodology can be configured to capture FAIR's loss-event-frequency and loss-magnitude inputs, and many customers use SimpleRisk as the register of record while doing the FAIR math in a separate Monte Carlo tool.

  • SOC 2 — System and Organization Controls 2: the AICPA reporting framework for service organizations, evaluated against the Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, Privacy). SOC 2 reports come in two types: Type 1 is a point-in-time snapshot of controls; Type 2 is an evaluation of operating effectiveness over a period (typically six to twelve months). SOC 2 is the dominant audit currency in commercial SaaS due-diligence; if you're a SaaS company, your customers will ask for the report. SimpleRisk supports SOC 2 as an installable framework with the Trust Services Criteria prepopulated; the control evidence collection and test-cycle features are designed to produce the artifacts a SOC 2 auditor will request.

  • Secure Controls Framework (SCF) — A meta-framework that maps a single set of common controls to many regulatory and contractual frameworks. The value of the SCF is the cross-mapping: if you implement an SCF control and the SCF maps it to ISO 27001 A.5.1, NIST CSF PR.AC-1, and SOC 2 CC6.1, you've effectively addressed three frameworks with one piece of work. SimpleRisk supports the SCF through the ComplianceForge SCF Extra, which installs the SCF control library and the cross-mappings (see The ComplianceForge SCF Extra). The Extra is the right answer when you're running multiple frameworks and want to avoid duplicating control-test work across them.

  • Unified Compliance Framework (UCF) — Another cross-framework mapping database, larger in scope than the SCF and built around regulatory citations rather than control objectives. The UCF tracks compliance obligations from regulations, standards, contracts, and frameworks, and maps them to a unified set of common controls. The UCF is a commercial product; SimpleRisk customers access it through the UCF Extra (see The UCF Extra). The UCF is the right answer for organizations whose compliance burden is heavily regulatory (financial services, healthcare, multi-jurisdiction privacy) rather than purely framework-driven.

  • CIS Critical Controls — The Center for Internet Security's prioritized list of cybersecurity actions, organized into Implementation Groups (IG1, IG2, IG3) by organization size and risk. CIS is unusual in this list because it's explicitly prioritized — IG1 controls are the ones every organization should implement first, IG3 controls are the ones mature organizations layer on. CIS is excellent for early-stage programs that need a defensible "where to start" list rather than a complete framework. SimpleRisk supports CIS as an installable framework alongside the others.

A few patterns are worth flagging across the list. Most programs run one lifecycle framework (RMF or CSF most often), one or two control catalogs (800-53, ISO 27001 Annex A, or the SCF mapping), and one or two assurance targets (SOC 2, ISO 27001 certification, or both). The combinations aren't infinite; a typical SaaS company runs CSF as the spine, ISO 27001 controls as the catalog, and SOC 2 as the audit target. A federal contractor runs RMF, 800-53, and FedRAMP. The SCF and UCF Extras exist to make the cross-framework bookkeeping tractable when the count of frameworks gets larger than two.

Common pitfalls

Framework selection and use cluster a few recurring failure modes.

  • Picking the framework before knowing the audience. A team picks NIST CSF "because Google uses it" and discovers six months later that the audit conversation actually wants ISO 27001. The framework is for the audience, not for the team's preferences; pick the one that satisfies the people who will read the report.

  • Running too many frameworks without cross-mapping. Three frameworks managed independently means three control test cycles, three evidence repositories, and three quarterly reviews — for a control population that probably overlaps 80% across them. The SCF or UCF Extra, or a homegrown mapping in the SimpleRisk control catalog, pays for itself the first quarter the team isn't doing the same work three times.

  • Treating the framework as the program. A framework is a description of what good looks like; it isn't the program itself. A program with the framework's controls implemented but no operating cadence (no review, no testing, no evidence collection) has compliance documentation, not a compliance program. The framework tells you what; the program is how often and by whom.

  • Treating the framework as gospel. The opposite failure: every control in 800-53 gets implemented as written, including the ones designed for federal information systems handling classified data, in a five-person SaaS startup. Frameworks are catalogs; the program selects the subset that applies. NIST itself publishes tailoring guidance (RMF Step 3) for exactly this reason. Most frameworks expect you to scope them.

  • Confusing a framework with a methodology. "We use NIST" is a sentence customers say a lot, and it usually doesn't pin down whether they mean RMF (lifecycle), CSF (capability functions), 800-53 (control catalog), 800-30 (risk-assessment methodology), or 800-61 (incident-response methodology). The answers are different programs. When the audit conversation gets stuck, a useful clarifying question is "which NIST publication?"

  • Picking SOC 2 as the program rather than as the audit. SOC 2 is what your customers will see, not what your security program is. A program designed to pass a SOC 2 audit but not designed to actually reduce risk produces a clean report and an organization that gets compromised anyway. SOC 2 is downstream of a working program; build the program first.

  • Underestimating the SCF and UCF Extras. Cross-framework mapping looks like overhead until the second framework arrives. Customers running one framework often skip the Extras and end up duplicating control work the moment they add a second framework. If the roadmap has more than one framework on it, get the mapping in place from the start.

Related