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

06.04 Installing and Managing Frameworks

Compliance frameworks (NIST CSF, ISO 27001, SOC 2, PCI DSS, etc.) live in the frameworks table; the Import-Export Extra adds GitHub-based bulk install of community-maintained framework definitions. Manage frameworks at Governance → Frameworks; install pre-built ones from GitHub via the Import-Export Extra; build custom frameworks manually.

Why this matters

A framework in SimpleRisk is a set of compliance controls organized into a hierarchy. NIST CSF v2.0 has six functions and dozens of categories and subcategories; ISO/IEC 27001 has Annex A controls grouped into 14 control objectives; PCI DSS has its 12 requirements broken into testing procedures. The framework structure is what gives the program a control map — a place to assert "we have a control for X," "we test it on Y cadence," "the test pass-rate is Z."

Without frameworks, SimpleRisk's compliance side is unfilled. With them, you can map your operational controls (firewall configurations, access policies, training programs) to specific framework requirements and produce framework-based readouts ("our NIST CSF maturity is at 3.2 average," "our ISO 27001 audit is 87% pass-rate").

The honest scope to know up front: Core has framework management; bulk installation of pre-built frameworks lives in the Import-Export Extra. Core lets you manually create frameworks and add controls one at a time — fine for a custom internal framework, painful for installing all of NIST CSF v2.0. The Import-Export Extra adds the GitHub-based installer that pulls pre-built framework definitions from SimpleRisk's simplerisk-frameworks GitHub repository. For most programs, the Extra is the operational path.

The other thing worth knowing: frameworks support hierarchy via parent IDs. Each frameworks row has a parent column referencing another framework (or 0 for top-level). This lets you model nested structures like NIST CSF's Function → Category → Subcategory hierarchy. Custom frameworks can use the same hierarchy if it fits their structure.

The third thing: framework names and descriptions are encrypted at rest. The frameworks table's name and description columns are stored encrypted (when the Encryption Extra is active). This protects framework metadata if the database is exfiltrated; it also means database-level queries against framework names produce encrypted blobs, not the human-readable values.

Before you start

Have these in hand:

  • Admin access to Governance → Frameworks (or equivalent path that opens the framework management page). For GitHub-based bulk install, the Import-Export Extra must be active.
  • A list of the frameworks your program needs. Don't install everything; start with the 1–3 frameworks the program actually maps controls to. Each framework is a maintenance burden (controls need to stay current as the framework evolves); fewer is better.
  • Awareness of the Import-Export Extra licensing. Most pre-built framework definitions in the SimpleRisk GitHub repo are community-maintained; some have licensing constraints (NIST publications are public domain; ISO 27001's full text is copyrighted by ISO and is not redistributed). The repository contains control mappings and structures, not the proprietary text of the frameworks; if your auditor needs the actual ISO text, you still need an ISO subscription.
  • Awareness of the Customization Extra interaction. Custom frameworks built manually via the Core surface live in the same frameworks table as installed ones; the management UI doesn't distinguish. The Customization Extra adds form-customization for risk and mitigation, not for frameworks themselves; framework customization is via the standard governance UI.

Step-by-step

1. Identify your framework needs

Common starting points:

  • NIST CSF v2.0 — broad cybersecurity framework; works for most security-focused programs.
  • NIST SP 800-53 — federal control catalog; appropriate for federal contractors and high-security programs.
  • ISO/IEC 27001 — international information-security management standard; common for international and certified programs.
  • SOC 2 Trust Services Criteria — for SaaS providers and B2B software companies handling customer data.
  • PCI DSS — required for any organization processing payment card data.
  • HIPAA Security Rule — for healthcare and business associates.
  • CIS Critical Controls — pragmatic, prioritized control set; good first framework for less-mature programs.

Pick what your auditors and customers ask for; don't install everything.

2. Install the Import-Export Extra (recommended)

Sidebar: Configure → Extras → Import-Export Extra → Activate. Activation enables:

  • The GitHub-based framework installer.
  • Bulk import/export of frameworks, controls, risks, and other entities (covered in Configuring Risk and Compliance and related articles).
  • The import_export_github_frameworks table for tracking installed framework metadata.

Without the Extra, frameworks must be created manually one at a time.

3. Browse and install GitHub frameworks

With the Import-Export Extra active:

  1. Sidebar: Governance → Frameworks (or the Import-Export Extra's framework-installer page).
  2. Click Install Framework from GitHub (or equivalent).
  3. The page lists pre-built frameworks from the SimpleRisk frameworks repository.
  4. Pick the framework; click Install.
  5. The Extra downloads the framework definition (typically a JSON or CSV file) and creates the frameworks row plus all the framework_controls rows.

Installation can take a moment for large frameworks (NIST CSF v2.0 has 100+ controls). The page typically shows a progress indicator.

After installation, the framework appears in the framework list; controls are visible via the framework's detail view; they can be mapped to risks via the standard control-mapping flow.

4. Create a custom framework manually

For a framework not in the GitHub repo (an internal framework, a framework with proprietary structure):

  1. Governance → Frameworks → Add Framework.
  2. Enter the framework name and description.
  3. Pick a parent framework if hierarchical (or leave at top-level).
  4. Save.

Then add controls:

  1. Open the framework.
  2. Add Control.
  3. Enter the control's short name (the identifier, e.g., "AC-2") and long name (the full description).
  4. Save; repeat for each control.

For frameworks with many controls, manual entry is tedious. The Import-Export Extra also supports bulk import via CSV — prepare a CSV with the framework structure, upload, and the controls populate.

5. Manage framework status

Each framework has a status (active, inactive, archived, etc.). Status controls visibility:

  • Active — the framework appears in dropdowns, control-mapping UI, and reports.
  • Inactive — the framework is hidden from active use but its data is preserved.
  • Archived — the framework is fully retired; preserved for historical reference but not surfaced in operational UIs.

Use status (rather than deletion) to retire a framework. Deletion is destructive; status changes are reversible.

6. Map controls to operational entities

Once frameworks are installed, the value comes from mapping framework controls to your operational controls, risks, and tests:

  • Control to operational control: the framework control "NIST 800-53 AC-2: Account Management" maps to your operational control "Quarterly user-access review process." See the relevant compliance articles in this guide.
  • Control to risk: a risk in the register can reference the framework controls that mitigate or relate to it.
  • Control to test: the test definition (in the Compliance Management workflow) references which control(s) it tests.

The mapping work is where the value of installing the framework comes from. Installing without mapping produces a framework that's just a control list; mapping turns it into an active compliance posture.

7. Update frameworks when the standard updates

Frameworks evolve. NIST CSF v2.0 superseded v1.1 with significant changes; ISO 27001:2022 reorganized Annex A from 27001:2013. When the source standard updates:

  • The SimpleRisk frameworks repo eventually publishes the updated definition.
  • Re-install the framework via the Import-Export Extra (this typically creates a new framework rather than overwriting; the old framework stays as archived or inactive).
  • Re-map your operational controls to the new framework's controls (some mappings carry forward; others need re-thinking).

This is meaningful work. Don't update frameworks in flight without a plan; coordinate with audit cycles and re-mapping capacity.

8. Plan for framework-related backups

Frameworks live in frameworks and framework_controls; mappings live in additional tables. Backups should cover all of these. The standard database backup (see Database Backup and Restore) does. After major framework changes, take a backup before going live so the rollback path is one operation.

Common pitfalls

A handful of patterns recur with framework management.

  • Installing every framework "in case we need it." Each installed framework is a maintenance commitment; if not actively mapped, it's just clutter. Install what you actively use.

  • Trying to install proprietary framework text via the GitHub installer. The repo has structures and control IDs/names; it doesn't redistribute the full proprietary text of frameworks like ISO 27001. If your auditor wants you to demonstrate operational adherence to "ISO 27001 Annex A 5.18," they'll have the ISO text; SimpleRisk holds the structure.

  • Renaming installed framework controls without thinking. Renaming "NIST 800-53 AC-2" to "Account Management" loses the ID linkage to the standard. If you need both the standard ID and a friendly name, use the short-name field for the ID and the long-name for the description.

  • Deleting a framework that's referenced by mapped controls or risks. The mappings become orphaned; reports referencing the framework break. Use archived status instead.

  • Confusing manually-created frameworks with installed ones. Both live in frameworks; the management UI doesn't distinguish. Add a naming convention (e.g., prefix internal frameworks with "[Internal]") if the distinction matters operationally.

  • Not updating frameworks when the standard updates. A SimpleRisk install showing "NIST CSF v1.1 controls" five years after v2.0 shipped is operating against an outdated framework. Schedule periodic framework reviews.

  • Installing a framework before the Import-Export Extra. Without the Extra, the GitHub installer isn't available; you'd have to create the framework manually one control at a time. Activate the Extra first.

  • Mass-deleting controls "to clean up." Each deleted control breaks any mapping that referenced it. Verify no mappings exist before deleting; reassign first if they do.

  • Treating frameworks as policy documents. The framework structure isn't a policy. It's a reference for control structure. Your program's policies are separate documents (managed via the Managing Policies and Documents workflow); the framework is the control map.

  • Forgetting that framework names are encrypted at rest. Database queries against framework names won't match plaintext strings. Use the application's API or UI to query frameworks; don't try to grep the encrypted database.

Related

Reference

  • Permission required: governance for framework management; admin for installing the Import-Export Extra.
  • API endpoint(s): GET /api/v2/governance/frameworks; POST /api/v2/governance/frameworks (create); PATCH /api/v2/governance/frameworks/{id} (update); DELETE /api/v2/governance/frameworks/{id} (delete); GET /api/v2/governance/framework-controls.
  • Implementing files: simplerisk/governance/index.php (the framework management UI); simplerisk/includes/governance.php (add_framework($name, $description, $parent, $status), the framework CRUD); simplerisk/extras/import-export/index.php (the GitHub-based installer including show_github_frameworks(), the import/export functions).
  • Database tables: frameworks (value PK, name encrypted, description encrypted, parent self-FK, status, order); framework_controls (id, framework_id, short_name, long_name, plus control-specific metadata); import_export_github_frameworks (added by the Import-Export Extra to track installed framework metadata).
  • config_settings keys: import_export (the Import-Export Extra activation flag).
  • External dependencies: The Import-Export Extra for GitHub-based installation; the SimpleRisk frameworks GitHub repository (https://github.com/simplerisk/simplerisk-frameworks or similar) for the framework definitions.