Compliance catalogue administration¶

The Compliance Catalog lets administrators and control stewards maintain reference releases, choose frameworks, adopt or author organization controls, review updates, and perform the one-time move from legacy mappings.

The administration area has four tabs:

• Releases — import, validate, compare, activate, and roll back SCF releases.
• Frameworks — select framework versions and review requirement coverage.
• Controls — browse source controls and maintain organization-owned controls.
• Cutover — replace legacy risk mappings with the new model.

Permissions¶

• Manage releases — import, activate, roll back, and delete eligible releases.
• Manage framework selections — choose active framework versions.
• Author controls — adopt, create, and maintain organization controls. Give this to control stewards, not every analyst.
• View catalogue — read-only browsing for analysts, owners, reviewers, auditors, and others who need context.

Cutover steps also require application-settings authority.

Import a catalogue release¶

1. Open Configuration Hub > Compliance Catalog > Releases.
2. Obtain the intended full SCF JSON export and confirm its source and version.
3. Upload the full-scf file, up to 50 MB.
4. Wait for the background import to finish; the page refreshes its status.
5. Open the validation report.
6. Resolve every blocking problem before activation.
7. Review warnings and document whether each is acceptable.

Image needed: Compliance Releases page showing one active release, one imported candidate, background status, validation report, and comparison action.

Uploading the same content again is harmless. A file claiming an existing version but containing different content is refused.

Validation results¶

• Blocking problems prevent activation, for example inconsistent counts or an unknown framework label.
• Warnings allow activation only after an administrator explicitly acknowledges them; the acknowledgement is audited.

For an unknown framework label, add the correct alias on Frameworks, delete the never-activated failed release, and import it again.

Compare and activate a release¶

1. Open the candidate release's comparison with the active release.
2. Review unchanged, text-changed, structure-changed, and mapping-only changes.
3. Investigate suspected renames, splits, and merges. RiskVault does not decide these automatically.
4. Review and acknowledge permitted warnings.
5. Choose Activate and confirm the impact.
6. Verify catalogue browsing, pickers, and reports use the new release.
7. Open the Controls review queue and process proposed control updates.

Activation takes effect immediately. A release that has ever been active is retained permanently because historical records can refer to it.

Roll back¶

1. Open the previous release.
2. Select the rollback or activate-previous action.
3. Enter a clear reason.
4. Confirm and verify that browsing and mappings use the intended release.

Rollback moves the active pointer; it does not delete the newer release or rewrite historical links.

Select frameworks¶

1. Open Frameworks.
2. Select the framework versions the organization reports against.
3. Save and review the coverage view.
4. Identify mapped requirements with no adopted organization control.
5. Adopt appropriate controls individually or use the bulk-adoption workflow.
6. Download and review the result report after a bulk action.

Selecting a framework does not create controls or link risks. More than one version can remain selected during a transition.

The coverage view can indicate whether the underlying requirement list is official or inferred. Treat inferred coverage with appropriate caution.

Adopt a source control¶

1. Open Controls > Catalogue browser.
2. Browse by domain or search for the source control.
3. Review its objectives, evidence references, and framework mappings.
4. Select Adopt.
5. Review the proposed organization-control title and text.
6. Add an owner, implementation guidance, and testing guidance as required.
7. Publish the initial version.

RiskVault assigns a stable key such as CTL-0042. Adopting the same source control again returns the existing organization control rather than creating a duplicate.

Create a homegrown control¶

Use a homegrown control when the organization needs a control that is not adopted from the current source catalogue.

1. Open the organization-controls list and select Create control.
2. Enter a clear title and control statement.
3. Assign an owner and domain.
4. Add implementation and testing guidance.
5. Map relevant selected-framework requirements when supported.
6. Review and publish the version.

Use the same governance and review expectations as adopted controls. The absence of source provenance makes clear ownership and wording particularly important.

Review a proposed control update¶

After a new release is activated, changed adopted controls enter a review queue.

1. Open the affected control.
2. Compare current organization text with the proposed source update.
3. Review structural and mapping changes.
4. Promote the proposal to create the next organization-control version, or reject it with a reason.
5. Notify relevant owners when a material change needs implementation work.

Promotion does not silently move existing risk links. Analysts see a newer-version advisory and re-affirm deliberately. Mapping-only source changes can flow through without a text-version review.

Respond to adoption requests¶

When an analyst selects Request adoption from a risk:

1. Open the adoption-request queue or notification.
2. Review the source control and the requesting risk context.
3. Check whether an equivalent organization control already exists.
4. Adopt and publish the control, or reject the request with a useful explanation.
5. Let the analyst know when it is available to link.

Perform legacy cutover¶

Cutover is a deliberate one-way replacement of the old ISO, CIS, and SCF risk fields. Complete backups, approvals, catalogue preparation, and user communication before starting.

1. Block old writes — old compliance fields stop accepting saves, including from stale browser tabs.
2. Archive and verify — export the existing legacy values and verify the archive.
3. Clear old data — remove legacy values in one audited operation and confirm counts match the archive.
4. Enable the new feature — turn on the Compliance Catalog experience.
5. Finish — complete the later cleanup and record completion.

If a step fails, the process remains at that step and can be retried. Old writes stay blocked to prevent the archive and live data from drifting apart.

Legacy risk-to-framework selections are not automatically converted into control links. Analysts re-map risks to organization controls, using the archived export where history matters.

Image needed: Cutover page with the five steps, current step, completed checks, warning, and retry state, using a non-production example.

Operational checklist¶

• Keep exactly one intended release active.
• Review import warnings and release comparisons before activation.
• Process control-update and adoption-request queues.
• Periodically review framework coverage and unmapped requirements.
• Confirm selected frameworks match current reporting obligations.
• Audit high-impact activation, rollback, bulk adoption, and cutover actions.
• Train analysts on re-affirming and snapshots; neither happens silently.

For the analyst workflow, see Controls and compliance frameworks.