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

02.02 Control Frameworks and Control Families

A control framework is a named catalog of controls; a control family is a functional grouping inside a framework. Here's how the abstractions work and how SimpleRisk's data model represents them.

Why this matters

Compliance frameworks are catalogs. Each one ships hundreds of named line items the program is supposed to operate, and the line items are organized into groups so a human can find them. Knowing the structure is what makes the framework navigable: "implement AC-2" is opaque if you don't know that AC is the access-control family in NIST SP 800-53; once you know the convention, AC-2 is a specific named control about account management.

The other thing knowing the structure does: it makes mapping across frameworks tractable. ISO 27001's A.5.15 is about access control. NIST CSF's PR.AC-1 is about access control. NIST SP 800-53's AC-2 is about account management. They're not identical, but they're related — and the relationship is what makes one piece of test work generate evidence for several frameworks at once. Understanding the family-and-control vocabulary is the prerequisite for the cross-framework mapping work that ends up being most of the payoff in a multi-framework program.

The third reason: SimpleRisk's compliance module is built on a data model that mirrors this structure directly. A framework is a row in the frameworks table. A control is a row in the framework_controls table linked to its framework. Hierarchical controls (parent-child) and cross-framework mappings live in additional tables that wrap the basics. Knowing the abstractions means knowing what the UI is showing you and where to look when something doesn't render the way you expect.

How frameworks describe this

The major frameworks each organize their catalogs differently, but the basic shape (a few dozen functional families, each containing several controls) recurs across most of them.

  • NIST SP 800-53 uses two-letter family codes: AC (Access Control), AU (Audit and Accountability), AT (Awareness and Training), CM (Configuration Management), IR (Incident Response), PE (Physical and Environmental Protection), RA (Risk Assessment), SC (System and Communications Protection), SI (System and Information Integrity), and roughly two dozen more. Each family contains numbered controls (AC-1, AC-2, AC-3...) with control enhancements as additional numbered variants (AC-2(1), AC-2(2)). The family code is the breadcrumb that tells you what kind of control you're looking at before you read the title.
  • ISO/IEC 27001 Annex A uses themed clauses: A.5 Organizational controls, A.6 People controls, A.7 Physical controls, A.8 Technological controls (in the 2022 update, which consolidated the prior 14-clause structure). Each clause contains numbered controls (A.5.1, A.5.2, ...). The 2013 edition had a different organization (14 clauses including A.6 Organization of information security, A.7 Human resource security, A.9 Access control, etc.); the 2022 reorganization is what most fresh installs adopt.
  • NIST Cybersecurity Framework (CSF) v2.0 uses six functions (Govern, Identify, Protect, Detect, Respond, Recover) split into categories (Govern.OC, Identify.AM, Protect.AC...) split into subcategories (PR.AC-1, PR.AC-2...). Three levels of nesting; the function is the broadest grouping, the category is the functional area, the subcategory is the specific outcome.
  • SOC 2 uses a different structure entirely: the Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, Privacy) act as the top-level grouping, with points of focus below them as the operational requirements. It's flatter than the NIST and ISO catalogs, which is partly why SOC 2 audits are more about narrative and evidence than ticking off control implementations.

For practitioner purposes, the structures are interchangeable: each framework gives you a name (the family or category code) and a definition (the control objective and implementation guidance), and the program implements the controls and evidences that they're operating. The vocabulary varies; the mechanics don't.

How SimpleRisk implements this

SimpleRisk's data model maps to the framework-and-control structure directly. The relevant tables:

  • frameworks — one row per framework. Each row carries a name, description, status (active/inactive), an optional parent (for nested frameworks; ComplianceForge SCF Extra uses this heavily), and an order for sort order in the UI.
  • framework_controls — one row per control. Each row carries a framework (the parent framework's ID), a control_number (the framework-native identifier like "AC-2" or "A.5.15"), a name, a description, an owner (the user accountable for the control), a family (the functional grouping the control belongs to), and a parent (for parent-child control relationships within a framework).
  • framework_control_mappings — one row per cross-framework mapping. Each row links a control_id to a framework, with optional reference_name and reference_text for narrative annotation. This is the table that powers cross-framework reporting.
  • framework_control_test_audits — one row per scheduled or completed audit instance against a control. Audits hold the test result, evidence links, and tester information; they're the substrate the test workflow operates on.

The UI surfaces these abstractions through three tabs in the Governance module at /governance/index.php:

  • Frameworks tab — the list of installed frameworks, with add / edit / delete controls (gated by Able to Add New Frameworks and Able to Delete Existing Frameworks). Each framework is editable through a modal that exposes the basic metadata.
  • Controls tab — the list of controls across all frameworks, filterable by framework, family, and owner. Each control opens an edit modal showing the metadata, the family assignment, the parent control (if any), and the cross-framework mappings (see Mapping Controls Across Frameworks). Adding new controls requires the Able to Add New Controls permission; editing requires Able to Modify Existing Controls.
  • Documents tab — the policy documents that justify the controls. Documents can be attached to controls and are part of the audit-trail story when an assessor asks to see the policy that the control implements.

A few SimpleRisk-specific abstractions worth knowing:

  • Parent and child controls. A control can be a parent of one or more child controls (framework_controls.parent references the parent's id). This is how SimpleRisk represents hierarchical frameworks like NIST SP 800-53's control enhancements or ISO 27001's sub-clauses. The UI shows them indented; reporting can roll child results up to the parent.
  • Maturity assessment. Each control carries a maturity score (typically Initial / Managed / Defined / Quantitatively Managed / Optimizing — the CMMI levels) recording the program's current implementation state. The maturity is configurable in admin settings; default is the CMMI scale.
  • Owner. Every control should have an owner — a named human responsible for the control's day-to-day operation. Controls without owners produce ambiguous accountability when a test fails.

Common pitfalls

A handful of patterns recur when teams use the framework-and-control vocabulary.

  • Treating the family code as the control. "We implemented AC" is a sentence customers say sometimes, and it's a category error: AC is a family containing twenty-plus controls, not one of them. Implementing the family means implementing the controls it contains; saying "we implemented AC" without a control-by-control evidence trail produces a SOC 2 report that doesn't survive its first auditor question.

  • Skipping the family/owner assignment when adding controls by hand. Custom controls created in SimpleRisk's UI default to no family and no owner; the program then can't roll up family-level reporting and can't route review reminders to the right person. Set both at creation time; the form supports it because it's load-bearing.

  • Not using parent-child to express hierarchy. Programs sometimes flatten a hierarchical framework into a list of controls with redundant prefixes ("Section 5.1 — XYZ" / "Section 5.1.1 — ABC" / "Section 5.1.2 — DEF") instead of using SimpleRisk's parent field to model the actual tree. The flat representation works but loses the rollup behavior — child results don't naturally aggregate to the parent for reporting. If the framework has a tree, use the tree.

  • Confusing framework version with framework instance. ISO 27001:2013 and ISO 27001:2022 are different versions of the same framework with substantially different control organizations. Customers sometimes install both and treat them as separate, then discover they're double-counting controls in their reporting. Pick the version your audit conversation expects, install that one, and retire the other (or at minimum mark it inactive).

  • Owner-by-team rather than owner-by-person. SimpleRisk's control owner field is a user picker, not a team picker, for the same reason risk ownership is per-person: a team doesn't take a Slack message about an overdue test, a human does. Use Additional Stakeholders for the team or other people who should be notified; reserve Owner for the one accountable human.

  • Ignoring the maturity field. The CMMI-style maturity score is one of the most useful program-progress metrics SimpleRisk produces, and many programs leave it set to the default forever. Updating it as part of the test-cycle review (when a test passes consistently, bump the maturity; when it fails, drop it) is what turns the field into a leading indicator. Static maturity is decoration; updated maturity is signal.

  • Mapping controls to families instead of to other controls. Cross-framework mapping is one-control-to-another-control, not one-control-to-a-family. "AC-2 maps to ISO A.5" doesn't generate testable evidence; "AC-2 maps to ISO A.5.15" does. The mapping UI enforces control-level granularity for this reason; respect it when building mappings by hand.

Related