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

02.01 What is Compliance Management?

Compliance management is the discipline of demonstrating that the controls you said you operate are the controls you actually operate. Here's the discipline, the major frameworks, and how SimpleRisk implements it.

Why this matters

Compliance management is the part of GRC where the program proves what it does. Risk management identifies what could go wrong; governance decides what the organization will do about it; compliance is the evidence trail showing the doing actually happened. Without it, a program is a story leadership tells itself; with it, the program can withstand a serious assessor reading the documentation against the operations.

The trap is treating the report as the goal. A SOC 2 report is the byproduct of a working compliance program; it isn't the program itself. A team that builds a compliance program to pass an audit produces evidence that's true on the day it was generated and stops being true the day after. A team that builds a compliance program to know whether the controls are operating generates the same evidence as a side effect, and the audit goes well because the program was already operating well. The order matters.

The other thing worth knowing up front: compliance is the discipline that scales the worst when you do it manually. Twenty controls tested annually is a spreadsheet. Two hundred controls tested across three frameworks on a rolling quarterly cadence is a tool, because the bookkeeping crushes the manual approach. SimpleRisk's compliance module exists for the second case, but the discipline doesn't change between scales — it just gets harder to fake when the numbers grow.

How frameworks describe this

Compliance frameworks describe what good looks like. They don't run themselves; they're catalogs and cadences against which a program self-reports. The major ones SimpleRisk customers see, in roughly the order they encounter them:

  • NIST Cybersecurity Framework (CSF) v2.0 is the voluntary commercial frame for cybersecurity activities, organized into six functions (Govern, Identify, Protect, Detect, Respond, Recover) with subcategories under each that map to specific outcomes. CSF is widely used by US commercial companies that want a rigorous frame without a certification audit attached. It's the most "starter-friendly" of the major frameworks and a common first install in SimpleRisk.
  • ISO/IEC 27001 Information Security Management Systems — Requirements is the international standard for an ISMS, certifiable through an accredited certification body. Its Annex A controls (114 in the 2013 edition, 93 in the 2022 update) are the catalog; clauses 5 through 10 specify the management system that operates the catalog. The certification path is the audit; the controls and the management cycle together are what gets audited.
  • SOC 2 is 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 control design, 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 your customers are enterprise SaaS buyers, the SOC 2 report is what they'll ask for first.

Plus the catalogs that don't define a lifecycle on their own but are referenced by name by everyone:

  • NIST Special Publication 800-53 is the federal control catalog, organized into roughly two dozen control families (AC for access control, AU for audit, IR for incident response, and so on). It's the catalog SimpleRisk was originally built around (see Introducing SimpleRisk) and a frequent reference target for other frameworks' control mappings.
  • CIS Critical Controls (formerly CIS Top 20) is the prioritized list of cybersecurity actions, organized into Implementation Groups by organization size. Useful as a "where do we start" framework for early-stage programs that aren't ready to pursue a full ISMS.

For the broader tour of what each framework is for and where it shows up in SimpleRisk, see A Practitioner's Tour of GRC Frameworks.

How SimpleRisk implements this

SimpleRisk's compliance module is built around three pillars, each with its own surface in the product:

Frameworks and controls live under the Governance module at /governance/index.php. A framework is a named container (ISO 27001, SOC 2, your own homegrown control set); a control is a named line item inside a framework with a description, an owner, and a maturity assessment. Frameworks come from three sources: a library of seeded frameworks shipped with SimpleRisk, frameworks installed from the SimpleRisk GitHub content repository, and frameworks created by hand in the UI (see Installing a Framework). Controls within a framework can be hierarchical (a parent control with child controls underneath), which most frameworks use to express the relationship between high-level objectives and the specific implementation requirements that satisfy them. The full picture is in Control Frameworks and Control Families.

Control mappings are how SimpleRisk handles the same control showing up in two or more frameworks. Most working programs run more than one framework and most of those frameworks overlap considerably (an access-control requirement is going to appear in ISO 27001, SOC 2, and CSF, all saying basically the same thing). Mapping a SimpleRisk control to its peers in other frameworks lets one piece of test work generate evidence for all the frameworks the control is mapped to. The data lives in the framework_control_mappings table; the UI is on the control edit modal. See Mapping Controls Across Frameworks. Two Extras automate this at scale: the ComplianceForge SCF Extra ships pre-built mappings across 200+ frameworks (see The ComplianceForge SCF Extra) and the UCF Extra does the same for the Unified Compliance Framework's regulatory-citation database (see The UCF Extra).

Tests and evidence live under the Compliance module at /compliance/. A test is a named procedure for verifying a control operates as designed (test name, test steps, expected results, frequency); an audit is one execution of that test against the control on a specific date with a specific tester. Tests can be auto-initiated on a schedule, manually initiated as needed, or initiated in batches to support a recurring audit cycle. Each audit produces a test result (Pass, Fail, or Inconclusive) and can carry attached evidence files plus links to risks the test surfaced. The full walk-through is in Control Tests and Evidence Collection.

The three pillars feed each other. Frameworks define the controls; controls have tests scheduled against them; tests produce results and evidence; the results roll up into compliance posture reporting that tells leadership how the program is doing across each framework. Governance reads from the same tables and adds the policy and exception layer on top.

Common pitfalls

A handful of patterns recur across customers when compliance management goes sideways.

  • Treating the audit as the program. A team that "stands up" a SOC 2 program two months before the auditor arrives produces evidence covering the last two months. The audit may pass, but the program isn't operating; it's on display. The same effort spread across the year, against a smaller initial scope, produces a program that operates and a SOC 2 report that's a side effect. The audit is the test of the program; it isn't the reason for the program.

  • Implementing the catalog as written. Most frameworks publish controls as if every organization were the same size, in the same regulated industry, handling the same kind of data. They aren't. NIST itself publishes tailoring guidance (RMF Step 3) for exactly this reason. A five-person SaaS startup implementing every NIST SP 800-53 control as written produces a program that's expensive to operate and disconnected from the actual risk surface. Tailor the framework to the organization; document the scoping decisions; defend them at audit. That's how mature programs run.

  • Running multiple frameworks without mapping. A team running ISO 27001 and SOC 2 and CSF in parallel produces three control test cycles, three evidence repositories, and three quarterly reviews for a control population that probably overlaps 80% across them. The first quarter the team isn't doing the same work three times pays for the SCF Extra (or the UCF Extra, or a homegrown mapping) several times over. If the roadmap has more than one framework on it, get the mapping in place from the start; see Mapping Controls Across Frameworks.

  • Evidence that doesn't reflect reality. A control description that says "access reviews are performed quarterly" with the last review on file from the year before last is the kind of finding a serious assessor catches in the first hour. Evidence has to be current to be evidence; stale evidence is documentation that the program used to operate. The fix is operational, not documentary: schedule the review, perform it, attach the new evidence. SimpleRisk's test-cycle scheduling exists for exactly this — automating the "when's the next test due" tracking is most of what makes a real program possible.

  • Conflating control owners with test reviewers. The control owner runs the control day-to-day; the test reviewer verifies that the control runs as designed. A test reviewed by the same person who designed the control is a self-assessment, not an independent test. SimpleRisk's permission model supports the separation (control owner vs tester vs review approver); the discipline of using the separation is what turns the model into a real second-line check. See The Three Lines of Defense.

  • Picking the framework before knowing the audience. A team adopts NIST CSF "because it's modern" and discovers six months later that the audit conversation actually wants ISO 27001. Frameworks are for audiences; pick the one that satisfies the people who will read the report. Adopting two frameworks because the audience isn't yet clear is fine (the Extras mentioned above are designed for that case), but adopting random frameworks because they're trendy is overhead the program doesn't recover.

  • Treating the SCF or UCF Extras as overhead. Customers running one framework often skip the cross-framework mapping Extras as a luxury. The skip is fine until the second framework arrives; once it does, the mapping work has to happen anyway, and doing it in the Extras is much cheaper than doing it by hand. If the roadmap has a second framework on it, the Extras pay for themselves before the second framework ships.

Related