10.03 When and How to Bring in Extras

Why this matters

SimpleRisk's Core ships with the GRC fundamentals; the Extras add capabilities that most installations don't need on day one but many programs need eventually. Knowing which Extras matter for your specific program (and when they're worth activating) saves the program from two failure modes: activating Extras that don't earn their operational overhead (each Extra has its own configuration, its own learning, its own maintenance), and failing to activate Extras that would substantially improve the program (especially the cross-framework mapping ones for multi-framework programs).

The trap is treating Extras as either "premium features for big customers" or "every Extra is worth activating." Neither is right. Each Extra solves a specific problem; the question is whether your program has that problem with enough operational pressure to justify the activation. A small Core-only program with no scanner and no auditor doesn't need the Vulnerability Management Extra; the same program three years later, running quarterly external audits and using two scanners, definitely does. The signal is in the program's evolving needs, not in the Extra's marketing.

The other thing worth knowing: Extras compose. Programs running multiple Extras get value from the integrations between them — the Workflows Extra can fire on events from the Incident Management Extra; the SCF Extra populates the controls the Compliance module's tests run against; the AI Extra reads the data the other Extras populate. This means the order you activate Extras matters; activating in the right sequence builds capability that the next activation extends. Activating in the wrong sequence (e.g., the Workflows Extra before there are events worth automating against) produces capability that sits unused.

The fourth thing: Extras have costs beyond licensing. Each Extra has activation overhead (database migrations, schema additions, sometimes async-load jobs that take hours). Each one has maintenance overhead (configurations to keep current, integrations to monitor, learning to absorb across the team). Programs that activate Extras casually accumulate maintenance debt; programs that activate deliberately get the value without the drag.

How frameworks describe this

Frameworks don't directly address "which tooling Extras should you buy" — that's vendor-specific. But the framework guidance on capability progression maps to the Extras conversation:

CMMI (Capability Maturity Model Integration) treats tooling as one of the enabling factors for capability advancement. Each maturity level has expected capabilities (see The GRC Maturity Model); some of those capabilities are easier to operate with specific Extras.
NIST CSF v2.0 under the Govern function expects organizations to identify the resources (including tooling) needed to support the program; the Extras conversation is part of that resourcing decision.
NIST SP 800-53 PM-3 (Information Security and Privacy Resources) addresses program resourcing including tooling; the federal interpretation is that the resourcing should be deliberate and tied to defined capability needs.

The framework view is consistent: tooling decisions should follow the program's capability needs, not lead them. Activate an Extra because the program has a problem it solves, not because the Extra exists.

How SimpleRisk implements this

SimpleRisk's Extras catalog includes (the major ones, not exhaustive):

Free with SimpleRisk registration

ComplianceForge SCF Extra — cross-framework control mapping covering 200+ frameworks. See The ComplianceForge SCF Extra. Free with registration; the install is asynchronous.
Notification Extra — event-driven email notifications. See Notifications and Email Preferences. Free; without it, no SimpleRisk emails fire at all.

Standard paid Extras

Authentication Extra — SAML 2.0 SSO, advanced authentication options. See the Administrator Guide's Authentication chapter.
Workflows Extra — custom event-driven automation with email templates. See Understanding SimpleRisk Workflows.
Vulnerability Management Extra — scanner integration (Qualys, Rapid7 InsightVM Cloud/On-Premise, Nexpose, Tenable.io) and the triage queue. See The Vulnerability Management Extra.
Assessments Extra (also labeled "Risk Assessment Extra") — questionnaire-driven self-assessments, vendor assessments, control assessments. See Running a Self-Assessment, Third-Party and Vendor Risk Assessments, and Control Assessments and Evidence Collection.
Incident Management Extra — full NIST 800-61 incident-response workflow with playbooks and lessons-learned tracking. See The Incident Management Extra.
Encryption Extra — database-level field encryption for sensitive data.
Import/Export Extra — bulk data import and export across most entity types. See Importing and Exporting Risks.
API Extra — adds the user-side API key generation surface to the profile page; required for programmatic API access.
Customization Extra — custom fields, custom reports, custom UI elements.
Advanced Search Extra — topbar search input scoped to risks. See Search.
AI Extra — AI chat sidebar plus AI-driven suggestions for controls, risks, and documents. See Working with SimpleRisk AI.
UCF Extra — Unified Compliance Framework regulatory-citation database. See The UCF Extra. Requires a UCF subscription separate from SimpleRisk licensing.
Risk Assessment Questions Extra — structured risk-elicitation questionnaires.
Organizational Hierarchy Extra — business-unit hierarchy with cross-unit reporting (registers business-unit exposure widgets on the Open Risks Dashboard).

Maturity-stage adoption pattern

Most programs converge on a similar adoption sequence as they advance. The exact order varies based on industry and regulatory pressures, but the typical pattern:

At Level 1 (Initial): Activate Notification Extra if you're not getting it free with the install. Without notifications, the program has no way to reach people outside the application; everything else builds on that.

Moving to Level 2 (Managed): Activate ComplianceForge SCF Extra if you're running more than one framework, or expect to within the year. The cross-framework mapping is the payoff that makes multi-framework programs sustainable. For organizations regulated under specific compliance regimes (HIPAA, SOC 2, PCI), activate the specific frameworks too.

Moving to Level 3 (Defined): - Workflows Extra for custom event automation that the standard Notification Extra can't cover. - Incident Management Extra if the program is running real incident response and needs the structured workflow. - Authentication Extra for SAML SSO when the user count grows past the point where local accounts are operational. - Assessments Extra when self-assessment or vendor-assessment cadences become substantial. - Vulnerability Management Extra if the program is running scanners and needs scanner integration.

Moving to Level 4 (Quantitatively Managed): - Import/Export Extra for bulk operations and reporting exports beyond the few built-in. - API Extra for programmatic integration with operational tooling. - UCF Extra if the program's compliance burden is regulatory-citation-heavy (financial services, healthcare, multi-jurisdiction).

Moving to Level 5 (Optimizing): - Customization Extra for the bespoke reports and fields the program has identified through measurement. - AI Extra for analytical assistance on recurring questions (with appropriate skepticism). - Advanced Search Extra for the search ergonomics the high-volume operational users need.

This is a typical pattern, not a prescription. A small program in a regulated industry might need Authentication Extra at Level 1; a research-shop SimpleRisk install might never need the Incident Management Extra at any level. Match the activations to your program's needs.

Activation discipline

Regardless of when you activate, follow the same activation discipline:

Confirm you have a clear use case for the Extra. "Someone might need this someday" isn't a use case. "Our auditor requires X and the Extra produces X" is.
Read the Extra's article in this guide before activating, so you know what to expect.
Confirm the prerequisites are in place (registration for SCF Extra, scanner credentials for Vulnerability Management Extra, AI provider credentials for AI Extra, etc.).
Activate in a non-production environment first when possible. Many Extras have async install jobs (SCF Extra in particular can take hours); discovering install behavior in production is more stressful than discovering it in test.
Configure deliberately. Don't just enable everything; the Extras with multiple configuration toggles (AI Extra's three feature toggles, Vulnerability Management Extra's threshold settings, Notification Extra's per-event routing) need conscious configuration.
Train the team on what the Extra adds. An activated Extra nobody on the team uses is operational overhead with no benefit.
Plan for the maintenance. Each Extra has its own configurations to keep current, credentials to rotate, integrations to monitor. Add the Extra-specific maintenance to the program's recurring operational schedule.

Deactivation discipline

Some Extras are easy to deactivate cleanly; others are destructive. The pattern across Extras:

The cross-framework mapping Extras (SCF, UCF) cascade-delete their installed frameworks and the test history attached to those frameworks on deactivation. Back up before deactivating; don't deactivate without weighing the loss.
The Workflows Extra deletes customer-authored workflows on deactivation (system-seeded workflows persist). Back up workflow definitions.
The Incident Management Extra drops the 35+ tables it created and the data they hold (incidents, playbooks, evidence, notes, lessons). Back up before deactivating.
Most other Extras are softer to deactivate — the data they wrote stays in the database, and reactivation typically restores access. But verify with a test deactivation before doing it in production.

The pattern: every Extra activation should include a documented deactivation plan even if you don't expect to deactivate. The plan documents what would be lost; that documentation makes future deactivation decisions clear.

Common pitfalls

A handful of patterns recur with Extras adoption.

Activating Extras the team can't operate. A two-person GRC team with five Extras active produces an operational footprint the team can't sustain. Each Extra has overhead — configurations, integrations, learning. Match the activation count to the team capacity. Three Extras well-operated beats ten Extras half-operated.
Skipping the SCF Extra when running multiple frameworks. The single biggest under-adoption pattern. Programs running ISO 27001 and SOC 2 and NIST CSF separately, mapping controls by hand, doing duplicate test work — the SCF Extra collapses most of that work. The Extra is free; the bookkeeping it eliminates is substantial. If your roadmap has more than one framework on it, the SCF Extra is the first paid (free in this case) capability to reach for.
Activating in a hurry before an audit. Activating the Incident Management Extra two weeks before a SOC 2 audit so the program "has incident management" produces a populated module with no operational history. The auditor will see the recent activation date and ask the questions that produce findings. Activate Extras as part of program-building, not as audit prep.
Treating activation as one-time. Activated Extras need ongoing care: API keys to rotate (Vulnerability Management Extra, AI Extra, UCF Extra), integrations to monitor (scanner connectivity, notification cron), framework versions to update (SCF Extra, UCF Extra). A program that activates and then ignores the Extra accumulates configuration drift and broken integrations.
Not coordinating overlapping Extras. The Notification Extra and the Workflows Extra both send emails on events. Programs running both without coordination produce duplicate emails. The Workflows Extra and the Incident Management Extra both have notification capabilities. Plan the role each plays before activating both.
Activating the AI Extra without spending limits. AI Extra calls cost money. Activating without provider-side spending limits produces unpredictable bills. Set the limits before activation.
Conflating SCF Extra and UCF Extra. Both are cross-framework mapping Extras with similar names. The SCF Extra is free (organized by control objectives, 200+ frameworks); the UCF Extra is paid (organized by regulatory citations, regulation-heavy programs). Most programs reach for the SCF first; reach for UCF only when regulatory citations specifically are the primary compliance burden.
Deactivating to "clean up" without backing up first. Deactivation is irreversible for the data the Extra cleared. The cleanup motivation is reasonable; the consequence of deactivation without backup is data loss. Always back up before deactivating.
Believing every Extra is worth eventually activating. Some Extras don't fit your program. A research-shop SimpleRisk install handling internal-only risk tracking probably doesn't need the Authentication Extra (local accounts work fine) or the Vulnerability Management Extra (no scanners). Activating Extras that don't fit produces complexity without benefit. Be honest about which capabilities your specific program actually needs.
Activating Extras the customer hasn't paid for. Most Extras require a paid SimpleRisk license. Activating without the license is a contract violation, not a feature decision. Confirm licensing before activation.