02.06 The UCF Extra

Requires: UCF Extra

The UCF Extra ships the Unified Compliance Framework's regulatory-citation database — authority documents (regulations, standards, contracts) mapped to a unified set of common controls, plus pre-built audit items for the standard test patterns. The Extra is paid; it requires a UCF API key from Unified Compliance.

Why this matters

The Unified Compliance Framework (UCF) takes a different cut at cross-framework mapping than the ComplianceForge SCF Extra does. Where the SCF organizes around control objectives, the UCF organizes around authority documents (the regulations, standards, and contracts that require the controls) and maps each authority document's requirements to a unified set of common controls underneath.

That distinction matters when the program's compliance burden is heavy on regulatory citation. A healthcare organization tracking HIPAA, HITECH, state breach-notification laws, and SOC 2 has dozens of authority documents to satisfy and not many "frameworks" in the security-team sense. The UCF's regulatory orientation is the right tool for that case. A SaaS company tracking SOC 2, ISO 27001, NIST CSF, and a few PCI requirements is more naturally served by the SCF, where the controls are the unit of organization.

The UCF Extra also ships audit items — pre-built test questions and procedures mapped to UCF controls. The audit items are useful because they reduce the "what should I actually test for this control" thinking that consumes program-startup time. The trade-off is that audit items written for a generic UCF control may not fit your specific implementation; the items are starting points the program adapts, not finished tests the program runs as-is.

The other thing worth knowing: the UCF is paid. The SCF Extra is free with SimpleRisk registration; the UCF Extra requires a separate UCF subscription with an API key, and the API key is what authorizes the data sync from Unified Compliance's servers. If your program doesn't already have a UCF subscription, the cost-benefit calculation against the free SCF Extra is the first decision to make.

Before you start

Have these in hand before activating the Extra:

A UCF subscription with an API key. The UCF data lives on Unified Compliance's servers; the API key is what authenticates the SimpleRisk install's data fetches. Contact Unified Compliance directly for the subscription; SimpleRisk doesn't resell or provision UCF access.
Admin access to your SimpleRisk installation plus the Able to Add New Frameworks permission. The Extra activation lives in the admin section; the framework operations the Extra triggers gate on the standard governance permissions.
Network access from the SimpleRisk server to Unified Compliance's API endpoints. The Extra fetches authority documents and controls through HTTPS; an air-gapped install can't sync the UCF data without an alternative content channel.
An understanding of how the UCF differs from the SCF. If your program needs control mapping across major security frameworks, the SCF Extra is usually the right starting point and is free. If your program needs regulatory mapping across authority documents (regulations, standards, contracts), the UCF Extra is the right tool and the cost is justified. If you're not sure which fits, the comparison in the SCF Extra article and the broader framework tour help.
Decisions on the per-test defaults. The UCF Extra captures default values for new tests it generates: a default tester, a default test frequency, and an approximate-time estimate. Decide who that default tester will be and what frequency makes sense for your program before configuring; changing defaults later doesn't retroactively update tests already created.

Step-by-step

1. Activate the UCF Extra

Sidebar: Configure → Extras opens the Extras administration page. Find UCF Extra in the list and click Activate. Activation creates the four UCF-specific tables in the SimpleRisk database:

ucf_ad_lists — UCF authority document lists (groups of authority documents).
ucf_authority_documents — UCF authority document definitions (each regulation or standard).
ucf_authority_document_controls — UCF control definitions, with simplerisk_control_id columns linking to the SimpleRisk side.
ucf_audit_items — UCF audit questions, with simplerisk_control_test_id columns linking to the SimpleRisk side.

Activation is synchronous — unlike the SCF Extra's async install, the UCF activation completes in the request cycle. (The actual data sync from UCF's servers is gated by the API key configuration below; activation just sets up the local schema.)

2. Configure the UCF API key and defaults

Sidebar: Configure → UCF (or the equivalent path in your install — labeling varies slightly with theme) opens the UCF configuration page. The form asks for:

UCF API Key — the API key from your Unified Compliance subscription. Required for any data sync; without it, the Extra is activated but inert.
Default Tester — single-user picker. The user assigned as the default tester on tests the Extra generates from UCF audit items. Pick a real user; "admin" or "system" defaults make for a confusing audit trail.
Default Test Frequency — number of days between scheduled tests for tests created from UCF audit items. Defaults vary by audit item; this setting overrides them. Common values are 90 (quarterly) for most controls and 30 (monthly) for high-criticality controls.
Approximate Time — minutes per test execution. Used for capacity planning in reporting; doesn't affect the test execution itself.

Submit the form. The API key gets stored in the UCFAPIKey configuration setting (along with UCFDefaultTester, UCFTestFrequency, and UCFApproximateTime); subsequent UCF data syncs use these values.

3. Sync UCF authority documents

With the API key configured, the UCF Extra can fetch authority documents from Unified Compliance's servers. The sync UI exposes a list of available authority documents (HIPAA, HITECH, GDPR, SOX, ISO 27001, the long list — UCF tracks thousands); pick the authority documents your program reports against and trigger the sync.

For each selected authority document, the Extra fetches:

The authority document metadata (name, version, scope).
The control catalog the authority document maps to.
The audit items associated with each control.

The sync writes UCF data to the ucf_* tables and creates corresponding SimpleRisk-side rows in the standard frameworks, framework_controls, and framework_control_tests tables. The ucf_authority_document_controls.simplerisk_control_id links connect the two sides; the ucf_audit_items.simplerisk_control_test_id links connect UCF-defined tests to SimpleRisk tests.

After the sync completes, the synced authority documents appear as installed frameworks in Governance → Frameworks, and the audit items appear as scheduled tests in the standard Compliance → Active Audits queue.

4. Use the UCF-sourced frameworks like any other framework

Once the sync completes, the UCF-sourced authority documents behave like manually-installed frameworks. Test execution, evidence collection, control mapping, dashboard reporting all work the same as for any other framework. The UCF differentiation is in what gets installed (regulations and authority documents) and how (pre-built audit items reducing the "what should I test" startup cost), not in the operational mechanics afterward.

For control-test execution against UCF-sourced controls, see Control Tests and Evidence Collection. The pre-populated UCF audit items appear as the test definition's expected steps and expected results; the program adapts them to the local implementation but doesn't have to write them from scratch.

5. Handle UCF updates

Unified Compliance updates authority documents and controls as regulations change. The UCF Extra exposes an update mechanism that re-syncs authority documents the program has installed; trigger the update from the UCF configuration page when notifications arrive (or on a scheduled cadence — quarterly is common).

Updates can:

Add new authority documents or controls.
Update existing control descriptions and audit items.
Mark deprecated controls as retired.

The update behavior is controlled by configuration similar to the SCF Extra (whether to add new content, update existing content, delete removed content). Most programs review updates before applying them; an automatic update of regulatory data without admin awareness can produce surprise compliance-posture changes.

6. Deactivate carefully

Deactivating the UCF Extra cascades through all UCF-sourced authority documents, controls, tests, and test history — the same cascade pattern as the SCF Extra, with the same caveats. The cascade also drops the four ucf_* tables. Take a database backup before deactivating, and only deactivate when the UCF data genuinely isn't needed anymore.

The deactivation does not affect the SimpleRisk-side frameworks, framework_controls, or framework_control_tests rows that don't link back to UCF data; only UCF-sourced rows are removed. Frameworks that exist for other reasons (manually-created, GitHub-installed, SCF-sourced) survive the deactivation.

Common pitfalls

A handful of patterns recur with the UCF Extra.

Activating without an API key and assuming nothing's working. Activation creates the tables but doesn't fetch any data; the data fetch needs the API key. Customers occasionally activate the Extra, see no UCF authority documents appear, and conclude the Extra is broken. The fix is to configure the API key and trigger the sync.
Confusing the UCF Extra with the SCF Extra. Both are cross-framework mapping Extras with similar names; they're different vendors with different approaches. The UCF Extra is paid (regulatory citations as the unit) and the SCF Extra is free (control objectives as the unit). Most programs run the SCF Extra first and add the UCF Extra only when the regulatory burden specifically justifies it. See the comparison in the SCF Extra article.
Picking every available UCF authority document. UCF tracks thousands of authority documents; selecting all of them produces an enormous local install with most of the content unused. Pick the authority documents your program actually reports against. Most programs use a small number (5–15) even when they're heavily regulatory.
Treating UCF audit items as finished tests. UCF audit items are starting points adapted to local implementations, not finished tests run as-is. A UCF audit item that says "Verify that access control is configured per HIPAA Security Rule §164.312(a)(1)" is a useful prompt; the program's actual test is the specific procedure for verifying this in your environment, which the program writes by adapting the UCF prompt. Customizing the audit item to local context is the program's work, not UCF's.
Letting the API key live in the wrong configuration. The UCF API key is stored in UCFAPIKey and is sensitive; an exposed key authorizes UCF data fetches that bill against the subscription. Treat the key like any other API credential — restrict admin access to the configuration page, rotate the key periodically per UCF's guidance, don't paste the key into customer-visible test data.
Running the UCF Extra and the SCF Extra without understanding the overlap. Both Extras can be active simultaneously; some controls will be sourced from both with different mappings and audit items. The overlap isn't broken (the data model handles it) but it can produce confusing reporting where the same logical control appears twice. Programs running both Extras usually pick one as the "primary" source and treat the other as supplementary.
Skipping the regulatory updates because "nothing changed." Regulatory environments change continuously — new state breach laws, updated HIPAA guidance, GDPR enforcement actions reshaping interpretation. The UCF Extra's update path is what keeps the local content current with these shifts. Skipping updates for a year produces a register that reflects the prior regulatory landscape and missed the recent shifts. Schedule the update review on a regular cadence.
Treating the Extra's defaults as load-bearing. Default Tester, Default Test Frequency, and Approximate Time apply to new tests created during the next sync; they don't retroactively update existing tests. Setting the defaults right before the first big sync matters; setting them right after the sync only affects the next batch of tests.