Application configuration¶

Configuration Hub controls organization-wide behavior. Changes are audited and some take effect immediately, so read confirmation messages carefully. Actions with meaningful side effects use a confirmation dialog, and particularly high-impact, irreversible actions can require a typed acknowledgement.

On a new installation, the most important settings are chosen during First-run setup. Every later change is made here, not by re-running setup.

Find a setting fast¶

The search box at the top of the Configuration Hub takes you straight to a setting, not just the page it lives on.

1. Type what you're after in plain words, such as “smtp port,” “logo,” or “session timeout.” Common nicknames work too: “2fa” finds the MFA requirement, “sso” finds the sign-in providers, and “segregation of duties” finds the rule that stops people reviewing their own risks.
2. Review the results. Each shows where the setting lives, such as Email Settings › SMTP Server, with a one-line description.
3. Select a result, or use the arrow keys and press Enter. RiskVault opens the page, switches to the right tab, scrolls to the setting, and briefly outlines it in blue.

Press / anywhere on the Configuration Hub to jump to the search box, and Esc to clear it. If you select Back after visiting a setting, your results are still there.

You see only settings you're allowed to view. Some settings appear only after you turn something else on, such as the virus-scanning API key, which appears once scanning is enabled; for those, the search takes you to the switch that reveals them. Feature switches are searchable by name, including new ones added later.

Image needed: Configuration Hub search showing a query, grouped results with their page › section location, and a highlighted setting on the destination page.

Organization and Base URL¶

Set the organization name and the public Base URL used in notification and workflow links. The Base URL must include http:// or https://, a host, and optionally an application path, such as https://risk.example.com or https://portal.example.com/riskvault. Do not include a query string or fragment. A change takes effect after the application restarts (see Restart a service).

The Allowed Email Domains list, which controls who may self-register or sign in, is checked before it saves. A bare domain such as contoso.com is fine; a typo, a stray space, or a pasted URL is rejected with a clear error instead of saving a rule that would lock out the addresses it was meant to allow.

Branding¶

The logo library stores up to five variants.

1. Open Organization Settings > Branding.
2. Add an optional internal label.
3. Upload PNG, JPG, GIF, SVG, or WebP, no larger than 300 KB. Raster images must be at most 400 × 100 pixels.
4. Choose whether to activate immediately.
5. Save and verify the sign-in page and sidebar.

Activate an older variant to roll back. The active variant cannot be deleted.

Image needed: Branding logo library showing thumbnails, Active status, Activate, Rename, and Delete controls.

Configure the risk matrix¶

1. Open Configuration Hub > Risk Matrix.
2. Choose 3–10 likelihood levels and 3–10 impact levels.
3. Enter scale labels or apply a preset.
4. Define rating bands that cover the entire score range without gaps or overlaps.
5. Choose accessible colors and review the live grid.
6. Select Activate, read the warning, and type ACTIVATE when certain.

After activation, dimensions and score ranges are locked. Labels, band names, colors, and descriptions remain editable. Activation is blocked after risks have already been scored.

Maintain reference data¶

Use Reference Data for the shared pick-lists people choose from: Impact Areas, Risk Factors, Regions, Business Units, and — when the asset inventory is on — Asset Types. Business Units and Asset Types have a Sort order column that controls their dropdown order (lower numbers first).

1. Open the relevant tab.
2. Select Edit on an entry to change its name or description, then Save or Cancel.
3. Select Add at the bottom of the tab to create a new entry. Asset type names must be unique.
4. Select Remove to retire an obsolete choice.
5. Test a risk or asset form.

Removal is a soft delete: new selections no longer show the item, while existing risks and assets keep their value. Removing a business unit doesn't change department-based confidentiality on existing risks.

If the Asset Types tab is missing, the AssetInventory feature switch is off (Configuration Hub > Feature Switches).

File uploads and file encryption¶

Configure file size, allowed extensions, and optional malware scanning. Files above the scan-size threshold are accepted without scanning, so align the threshold with policy. The scanner's address is set during deployment and can't be changed here.

Turning scanning on or off, or saving a new scanning API key, takes effect only after the application restarts. Saving alone doesn't change what happens to uploads.

RiskVault can use customer-managed AWS KMS keys for stored files. After changing the key, wait for re-encryption to finish and verify it before disabling or scheduling deletion of the old key.

Retention and legal holds¶

General Retention counts from the first Closed, Rejected, or Archived date. It determines when manual deletion becomes eligible; it does not automatically purge records.

Legal Hold Policies are reusable templates with a name, description, and optional default duration. Apply a policy from a risk's Details page or a register bulk action.

While any hold is active, it overrides general retention and blocks deletion. A hold marked Delete automatically when this hold ends can permanently purge the risk only after every active hold has expired with that flag. Permanent purge cannot be restored.

Releasing a hold early requires a meaningful reason of at least 10 characters.

Manage legal-hold policies¶

1. Open Configuration Hub > Data Retention & Legal Hold.
2. Under Legal Hold Policies, create a name and description that explain the legal or records purpose.
3. Set a default duration in days, or leave it indefinite.
4. Save and make sure the intended hold managers understand when to use it.

A never-used policy can be deleted. Once it has been assigned, deactivate it instead so historical hold records remain understandable.

The Legal Holds area lists active holds across the register and allows authorized release with a reason. Holds are assigned from a risk or the Register bulk action, not from this list.

Configure external sign-in¶

1. Open the external-authentication settings.
2. Add or edit the supported provider, such as Microsoft, Google, or Okta.
3. Enter the provider values supplied through your approved secret process.
4. Test sign-in in a separate private browser session with a non-admin account.
5. Confirm name, email, and identity linking.
6. Keep a tested local administrator path before enforcing or changing external sign-in.
7. Review provider health in Monitoring Hub.

When SCIM is enabled, it becomes the authority for creating new accounts. External sign-in authenticates the provisioned person rather than creating them on first use.

Require multifactor authentication¶

By default MFA is optional: anyone can enable it from their account, but nobody is forced to.

1. Open Configuration Hub > Password & Login Policies.
2. In the Multi-Factor Authentication card, tick Require MFA?.
3. Choose Admin Role Only (only accounts in the Admin role must enroll) or Organization-wide (All users).
4. Save.

The setting takes effect immediately, with no restart and no need for anyone to sign out. People in scope who haven't enrolled are sent to the MFA setup page on their next request and can't continue until they finish. People already enrolled aren't affected. Untick Require MFA? to return to Optional.

People who sign in only through an external identity provider (Okta, Google, Microsoft, or another SSO connection) and have never set a local RiskVault password are exempt, because their provider normally enforces its own MFA. Someone with both a local password and a linked external login is still covered, since they could sign in with the local password.

Email delivery: built-in provider or SMTP¶

RiskVault sends every system email — invitations, password resets, notifications, digests, and workflow-rule emails — through one of two services and chooses automatically:

• Built-in provider (default). A deployment-level service that works out of the box with no administrator setup. It delivers mail on a brand-new installation, including the first administrator invitation.
• Your own SMTP server (optional). Configure it under Configuration Hub > Email Settings: host, port, username, password, encryption, and the default sender address and name.

Saving SMTP settings is not enough on its own. RiskVault switches to your server only after you select Send test email and a real message gets through using exactly the settings you saved. Until then it keeps using the built-in provider, so mail keeps flowing.

1. Enter and save your SMTP settings.
2. Select Send test email.
3. Confirm the test message arrives. RiskVault now sends through your server.
4. Verify sender alignment, links, and spam handling.

RiskVault asks for a fresh successful test before trusting SMTP again when:

• any SMTP field (host, port, username, encryption, sender address, or sender name) is changed and saved without re-testing;
• a test used values that weren't saved yet — useful for trying a change, but it doesn't switch delivery;
• the SMTP password changes. The password is never shown back to you, so a new one always needs a test; otherwise a typo in a rotated password could silently break mail.

In each case RiskVault routes mail through the built-in provider instead. That is a routing fallback, not a delivery guarantee: the built-in provider can still fail if its deployment key is missing or invalid, the service is unreachable, or it rejects a message. If mail isn't arriving, first re-test your saved SMTP settings. If the built-in provider itself seems to be failing, ask your deployment operator to check the application logs and the provider key.

An in-app notification can succeed even when email fails.

Terms of Use and Privacy Policy re-acceptance¶

RiskVault can require every active user to accept the current Terms of Use and Privacy Policy again whenever your organization revises them. Users see the re-acceptance page on their next visit. The controls are in the Legal & Terms card under Configuration Hub > Organization Settings:

• Terms & Privacy version — a short version string such as 1.1. This is the switch: RiskVault compares it with what each user last accepted. Leave it blank to turn the requirement off; no prompt appears and no acceptance records are written.
• Terms & Privacy effective date — shown next to the version on the re-acceptance page. Optional.
• Legal contact email — shown on that page for users with questions. Optional; a default address is used if blank.

Keep the version and effective date in step with the /Terms and /Privacy pages, which show their own version and effective date. One version string should always correspond to one fixed set of legal wording. The wording on those pages is part of the application, not something you edit here, so a wording change and its version bump go through whoever maintains the deployment. RiskVault doesn't keep old copies, so archive each superseded version before it's replaced.

Changing the version prompts everyone again. When you change or clear the version and save, RiskVault shows a confirmation banner explaining the effect, and nothing is saved until you select Confirm and save. The change is written to the audit log.

Almost nobody is exempt. The internal automation account is never prompted, and specific user IDs can be listed in the TermsExemptUserIds setting for break-glass access. Everyone else, including the administrator who set up the organization, is prompted after a version change.

Auto-accept Terms for provisioned users¶

If you onboard people in bulk through User Import, SCIM, or first-time external sign-in, and your onboarding process already covers the legal agreement, RiskVault can record acceptance of the current version automatically for accounts created that way.

The organization-wide default (AutoAcceptTermsOnProvision) is chosen in the Authentication & security step of first-run setup. It isn't on the Legal & Terms card and has no screen after setup; ask whoever manages your configuration to change it. It is off by default and has no effect while the version is blank. Two provisioning paths have their own override:

Path	Control
User Import	The Confirm screen shows Record Terms of Use acceptance for these users, pre-ticked to match the organization default. Your choice applies to that import only, and only to accounts it creates; reactivated accounts are left alone.
SCIM	Each connector has Terms of Use auto-accept: Use organization default, Always, or Never.
External sign-in (JIT)	No separate control; these accounts follow the organization default. They sign in interactively right away, so the normal re-acceptance page also catches them.

Both controls appear only when a Terms & Privacy version is set.

Feature switches¶

Optional features remain hidden until enabled. If another administrator has the Feature Switches page open at the same time, saving applies only the switch you changed and leaves alone any switch that changed underneath you; RiskVault names that switch so you can reload and check it.

Before changing a switch:

1. Read its description and dependencies.
2. Complete any required configuration or data preparation.
3. Identify affected users and pages.
4. Enable it in a controlled window.
5. Test with intended and unintended roles.
6. Monitor errors and provide user guidance.

Compliance Catalog and MCP both require preparation beyond flipping the switch. Follow their dedicated guides.

Monitoring Hub¶

Use Monitoring Hub to review the health of external sign-in, Jira, webhook processing, and enabled SLA digest or KPI jobs. A healthy configuration screen does not guarantee recent business events were delivered, so pair health checks with audit or activity records.

Restart a service¶

Some changes, such as rotating the certificate that protects MCP sign-in tokens or other startup-only settings, take effect only when the application next starts. Service Restart lets an administrator trigger that from the browser.

The page has no menu item or hub tile. Press Ctrl+K and search for “Service Restart” (or “ecs” or “reboot”). It requires its own permission, Admin.RestartAppServices, which is kept separate from general settings management; grant it sparingly. If you have the permission but the search finds nothing, your deployment isn't connected to the restart infrastructure, and there is nothing to restart from here.

The page lists each restartable service — the web application, and the MCP server if your organization has one — with its current status and the outcome of its last restart.

1. Select Restart on the service.
2. Type a reason, such as “sign-in certificate rotation.” A reason is required.
3. Select Confirm restart.
4. Reload the page later to see the result. You also get an in-app notification when the restart finishes or fails.

Image needed: Service Restart page showing the web and MCP services, their status, last-restart outcome, and the reason dialog.

Before you restart:

• The service can be briefly unavailable. The page doesn't refresh itself.
• Restarting the web application doesn't sign anyone out of their browser session, but it does break any AI assistant connected through MCP, which will need to reconnect. Warn connected users if you can.
• Only one restart per service can run at a time. Another restart is refused while one is in progress or within about 10 minutes after it finished.
• A restart is refused if the service can't be found, is deliberately scaled to zero, or isn't Active (for example, it is draining or being replaced). The message says which. An Active service whose tasks are still starting up can be restarted.
• Occasionally the outcome can't be confirmed, usually because of a network or cloud-provider hiccup. That is neither success nor failure; check again in a few minutes and it resolves itself.
• The page shows only the most recent restart for each service, so you can confirm it actually finished and succeeded.

Configuration change checklist¶

• Record the business reason and approver.
• Capture the current value or rollback path.
• Confirm secret-handling requirements.
• Test with a normal account.
• Check notification and absolute-link behavior after Base URL changes.
• Verify audit history.
• Communicate changes that affect required fields, access, scoring, retention, or integrations.