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

00.03 Introducing SimpleRisk

Where SimpleRisk came from (NIST 800-53), what it is today (a multi-framework, open-source GRC platform with a Core + Extras model), and how the rest of this guide is organized around its capabilities.

Why this matters

SimpleRisk has been around since 2013, which in security-tooling years is an unusually long run. The platform exists because its founder, working as a CISO, kept buying GRC products that asked seven figures up front to do work that, for most programs at most maturity levels, can be done by a tool that costs nothing to download. So he wrote one. The decision to open-source it was a bet that the GRC space had room for a tool whose pricing didn't gate the discipline behind a procurement cycle, and a decade-plus later, with thousands of installations across small teams and Fortune-100 companies, the bet has held.

That history matters for how you read this guide. SimpleRisk is opinionated about what a working GRC program looks like — opinions that come from watching a lot of programs succeed and fail at customers running it. When the documentation says "we recommend reviewing the register monthly" or "don't enable encryption without a database backup," that isn't generic advice; it's the lesson from the support ticket we got the third time the same thing went wrong. The voice in this guide is the voice from those years.

The other reason to read this article first: SimpleRisk is structured as Core plus Extras, not as a single monolithic product, and the structure is load-bearing for everything that follows. Knowing the difference saves time when an article in this guide describes a feature you don't see in your installation. The answer is almost always "that feature lives in an Extra you don't have installed."

How frameworks describe this

SimpleRisk was originally built around NIST Special Publication 800-53 Security and Privacy Controls for Information Systems and Organizations — the federal control catalog that was, in 2013, the most concrete and actionable framework available for an internal CISO trying to operationalize a security program without a federal mandate to point at. The 800-53 origin still shapes how SimpleRisk thinks about controls: control families, parent and child controls, control implementations, and the assessment cadence are 800-53-shaped at the data-model level, even when a customer is running an entirely different framework on top.

Over the years the platform has grown to support most of the frameworks a working GRC team encounters. The list isn't exhaustive (and isn't meant to be; the framework tour is in A Practitioner's Tour of GRC Frameworks), but the recurring ones are: NIST Risk Management Framework (RMF) for the federal lifecycle; NIST Cybersecurity Framework (CSF) for the voluntary commercial frame; ISO/IEC 27001 and ISO/IEC 27005 for the international ISMS standard and its risk-management methodology; COSO Enterprise Risk Management for the strategic, board-level lens; Factor Analysis of Information Risk (FAIR) for quantitative dollar-denominated risk analysis; SOC 2 for SaaS service-organization reporting; and the Secure Controls Framework (SCF) and the Unified Compliance Framework (UCF) for cross-framework mapping (both available through their respective Extras).

The 800-53 origin doesn't mean SimpleRisk is a 800-53-only tool. It means the tool's instincts about what a control is, how it should be tested, and how it should be tracked over time were formed in a 800-53-shaped problem space. Those instincts generalize well to other framework families because most security frameworks are control catalogs at heart; they just disagree about how the catalog is organized and what the controls are called.

How SimpleRisk implements this

What you actually get when you install SimpleRisk is a self-hosted PHP web application backed by MySQL, deployable as a Docker container or a traditional LAMP stack. There is no SaaS version run by SimpleRisk (the company); customers run the application themselves, on infrastructure they control, with data they never have to send to a third party. For customers who want managed hosting, partner deployments are available, but the default mode is self-hosted.

The application splits into Core and Extras.

Core is the open-source, free GRC platform. It includes risk submission, scoring, mitigation, and tracking; the compliance module with framework installation and control test scheduling; the governance module for policies, exceptions, and projects; the asset inventory; the standard report library; the dashboards; the v2 REST API; multi-language UI in 39+ locales (via Crowdin); local username-and-password authentication; and a permissions-teams-roles model fine enough for most organizations to use as-is. Core is what most articles in this guide describe. If a feature isn't called out as Extra-gated, it ships in Core.

Extras are paid add-ons that bolt onto Core to cover specialized capabilities most installations don't need. Each Extra is a separately-purchased, separately-installed module, and articles in this guide that document Extra-gated features open with a Requires: callout naming the Extra. The Extra catalog grows over time, but the recurring ones are: Authentication Extra (SAML 2.0 SSO and other enterprise identity flows; see Configuring SAML SSO), Workflows Extra (custom workflow automation), Vulnerability Management Extra (vulnerability ingestion and tracking; see The Vulnerability Management Extra), Assessments Extra (templated assessment questionnaires; see Running a Self-Assessment), Encryption Extra (database-level field encryption for sensitive data), Risk Assessment Questions Extra (structured risk-elicitation questionnaires), and the two cross-framework mapping Extras, ComplianceForge SCF Extra and UCF Extra (see The ComplianceForge SCF Extra and The UCF Extra). The Extras model is how SimpleRisk funds the open-source Core: the company sells Extras, customers buy the ones they need, and the Core stays free.

The split is intentional. A small team running risk and compliance for a startup needs Core and probably nothing else. A regulated enterprise running SAML SSO, custom workflows, encrypted fields, and SCF mapping needs Core plus four Extras. Neither customer pays for what the other one needs, and the Core stays small enough to stay maintainable.

The rest of this guide is organized around the disciplines, not the features: chapters on risk management, compliance, governance, asset inventory, vulnerability management, assessments, incident management, audit and reporting, day-to-day usage, and continuous improvement. Each chapter draws on whichever Core features and Extras are relevant; the Requires: callouts make the gating explicit when it applies.

Common pitfalls

A handful of misconceptions cost new SimpleRisk users time on first install.

  • Assuming everything in the documentation ships in Core. The User Guide covers both Core and Extra features. If you're following an article and the screen looks empty, check the article frontmatter and the Requires: callout. An Extra-gated feature on a Core-only installation is invisible because the Extra isn't installed. That's working as designed; the article exists because customers with the Extra need it. The fix is to either install the Extra or move on to a Core feature that does the job.

  • Treating SimpleRisk as a SaaS. SimpleRisk doesn't run an on-demand version of the app for end customers; you install it on your own infrastructure. That's a deliberate part of the product (data sovereignty, deployment flexibility, no per-seat pricing for Core), but it means there's no "sign up at simplerisk.com and get a workspace" flow. The deployment story is in the Administrator Guide; the User Guide assumes a deployed instance is available.

  • Missing the upgrade cadence. SimpleRisk releases roughly every two to three months: bug fixes, security patches, new features, new framework support. Customers who skip a year of upgrades end up with an installation that's drifted significantly from current and that takes meaningful work to bring forward. The upgrade flow is well-documented (see The Upgrade Process), but the discipline of keeping current is on the customer to maintain.

  • Conflating the open-source Core with "SimpleRisk has no business model." SimpleRisk (the company) sells Extras, sells managed hosting through partners, and sells professional services for customers who want help operationalizing the platform. The Core is genuinely free; the company is genuinely a sustainable business. Both can be true; the open-source-with-paid-add-ons model is what makes both work.

  • Skipping the foundations chapters because "we already know GRC." The voice and conventions of this guide get established in Foundations. An experienced GRC practitioner won't learn what GRC is from What is GRC?, but they'll learn how this documentation talks about it: which terms get redefined, which get assumed, which framework citations show up where. That's worth twenty minutes; the rest of the guide reads faster when those conventions are already in your ear.

Related