System Configuration

System Configuration holds two kinds of setting:

  • How the platform summarises the review work your team records — how per-control answers roll up into an assessment status, and how assessment statuses roll up into a project status.
  • Which components appear on the project dashboard.

These settings shape how results are summarised and displayed. They do not decide anything on your behalf: the platform structures human review and reflects the state your team has recorded. See the Overview for how the Assessment stage fits alongside Authoring, Testing, and Runtime Governance.

Where to find it: open the System Admin dashboard and select the Configuration tab. The dashboard component toggles sit at the top of that tab; the settings table sits below them.

Table of Contents

Start here: which settings matter

The page lists a number of settings, but they are not equally important. Most of what you will want to change lives in a single one.

Setting What it affects
complianceThresholds (six values) Nearly every status shown in the product — on assessments, the project dashboard, governance tables, drill-downs, and reports. This is the one to reach for.
RISK_SCORE_HIGH, RISK_SCORE_MEDIUM, RISK_SCORE_NONE, PLATFORM_RISK_APPETITE_PERCENT, PLATFORM_UNACCEPTABLE_RISK_PERCENT One screen only: the risk column of the project tables on Governance → Policy Details.
PLATFORM_OP_RISK_APPETITE, PLATFORM_OP_RISK_UNACCEPTABLE The Inherent Risk card, and only for projects that have no screening classification.
dashboardComponentsVisibility Which components appear on the project dashboard. Changes what is shown, never what is calculated. See Dashboard components.
NUMBER_OF_ANSWERS_BUNDLES How much assessment version history is returned. No effect on any status.
AZURE_AD_CLIENT_ID, ENTRA_ID_MODE Microsoft sign-in only.
RISK_SCORE_LOW, PLATFORM_ALIGNMENT_APPETITE, PLATFORM_COMPLIANCE_MIN_PERCENT, PLATFORM_COMPLIANCE_MAX_PERCENT, PLATFORM_POLICY_ALIGNMENT_RISK_HIGH_THRESHOLD, PLATFORM_POLICY_ALIGNMENT_RISK_MEDIUM_THRESHOLD Nothing. These are present on the page but are not read. See Settings with no effect.

If you remember one thing: to change how strictly the platform summarises status, edit complianceThresholds. The RISK_SCORE_* settings do not determine any assessment’s status.

How a status is worked out

There are three layers. Thresholds apply only at the two roll-up layers.

Layer 1   ANSWER       a label per control          no setting involved
Layer 2   ASSESSMENT   rolls up Layer 1             complianceThresholds — assessment values
Layer 3   PROJECT      rolls up Layer 2             complianceThresholds — project values

Layer 1 — the control label. Each answered control gets one label, taken from the compliance identifier on the answer option the user selected — fully-compliant, partially-compliant, not-compliant, or not-applicable. How that is decided depends on the control:

Control type How the label is chosen
Single-select scored The label is taken from the selected option’s identifier.
Multi-select scored The label is taken from the weakest of the selected options.
Test score The numeric result is placed in a band using the thresholds defined on the control.
Free text, document upload, plain cards Treated as informational — they carry no label and do not count towards the roll-up.

A control nobody has answered counts as unanswered rather than as a failure, which still keeps the assessment below thresholdFullyCompliant.

No System Configuration setting is involved at this layer, not even complianceThresholds. To change what a given answer means, change the answer options in the policy — see Policy Configuration.

Layer 2 — the assessment status. The labels from Layer 1 are counted, and the three assessment thresholds set which status the assessment shows.

Layer 3 — the project status. The assessment statuses from Layer 2 are counted, and the three project thresholds set which status the project shows.

The two groups are connected. A project’s status is the worse of its technology-risk half and its alignment half — and the technology-risk half is graded with the assessment values. So changing an assessment threshold also moves project status. Expect both to shift when you edit either group.

Compliance thresholds

Type: object · Six values, all percentages from 0 to 100

complianceThresholds is edited differently from the other settings: it opens a dedicated form with validation, rather than being edited inline, and it cannot be deleted from the page.

Assessment values

Counted across the scored controls in one assessment.

Value Default What it means Raise or lower it to…
thresholdNotCompliant 0 If the share of controls labelled Not Compliant exceeds this, the assessment reads Not Compliant. Raise it to tolerate a few failing controls. At 0, a single failing control pulls the assessment down.
thresholdPartialCompliant 0 If the share of controls labelled Partially Compliant exceeds this, the assessment reads Not Compliant. Raise it to let partial answers accumulate before the status drops.
thresholdFullyCompliant 100 The share of controls that must be Fully Compliant for the assessment to read Fully Compliant. Lower it to let assessments read Fully Compliant while some controls are still outstanding.

Project values

Counted across the assessments in one project.

Value Default What it means Raise or lower it to…
thresholdHighRisk 0 If the share of assessments reading Not Compliant exceeds this, the project reads High risk. Raise it to tolerate some failing assessments.
thresholdMediumRisk 0 If the share of assessments reading Partially Compliant exceeds this, the project reads High risk. Raise it to let partial assessments accumulate.
thresholdLowRisk 100 The share of assessments that must read Fully Compliant for the project to read Low risk. Lower it for project status to improve sooner.

What the defaults mean

The defaults are the strictest setting available: every scored control must be answered and carry the top label before an assessment reads Fully Compliant, and the same idea applies at the project level. Loosening them is a deliberate choice to report a more forgiving picture.

What the form checks

The form rejects the whole change, listing every problem at once, unless:

  • every value is a number from 0 to 100
  • thresholdFullyCompliant is greater than or equal to thresholdPartialCompliant
  • thresholdLowRisk is greater than or equal to thresholdMediumRisk

Before you change these

These values re-label existing assessments and projects the next time status is recomputed — not only new work. Treat a change with the same care as a policy change, and tell the teams whose records will move.

Other settings

Policy Details risk column

Settings: RISK_SCORE_HIGH (default 1), RISK_SCORE_MEDIUM (0.75), RISK_SCORE_NONE (0), PLATFORM_RISK_APPETITE_PERCENT (25), PLATFORM_UNACCEPTABLE_RISK_PERCENT (75)

A common misreading is that these compute an assessment’s status. They do not. They take the statuses that complianceThresholds has already produced and re-aggregate them into a single figure for one column on Governance → Policy Details.

Think of it as an average penalty for one project, seen from one policy:

1. Take each assessment's status
2. Convert it to points:  High → RISK_SCORE_HIGH
                          Medium → RISK_SCORE_MEDIUM
                          Low or Unavailable → RISK_SCORE_NONE
3. risk% = (total points ÷ number of assessments) × 100
4. risk% above PLATFORM_UNACCEPTABLE_RISK_PERCENT  → High
   risk% at or below PLATFORM_RISK_APPETITE_PERCENT → Low
   anything else                                    → Medium

Worked example. A project has four assessments reading High, Medium, Low, Low.

Points: 1 + 0.75 + 0 + 0 = 1.75. So risk% = 1.75 ÷ 4 × 100 = 43.75% — not above 75, not at or below 25, so the column shows Medium.

From that same starting point:

Change Result Column becomes
PLATFORM_UNACCEPTABLE_RISK_PERCENT 75 → 40 43.75 is above 40 High
PLATFORM_RISK_APPETITE_PERCENT 25 → 50 43.75 is at or below 50 Low
RISK_SCORE_MEDIUM 0.75 → 0 points 1.0, so 25% Low

Three things to know:

  1. RISK_SCORE_NONE covers both Low and Unavailable. An assessment nobody has started scores the same as one that is fully answered, so an untouched project reads Low on this column.
  2. A project with no assessments reads Low, not Unavailable.
  3. Keep RISK_SCORE_HIGH at 1 and set the others as fractions of it. The calculation divides by the number of assessments, which assumes a maximum of 1 per assessment. Setting it to 2 lets the figure exceed 100% and the bands stop meaning anything.

Inherent Risk fallback

Settings: PLATFORM_OP_RISK_APPETITE (default 0.25), PLATFORM_OP_RISK_UNACCEPTABLE (default 0.75)

These affect the Inherent Risk card on the project dashboard, and only when a project has no screening classification. A project that has been classified through screening uses that classification instead, and these settings are not consulted.

score above PLATFORM_OP_RISK_UNACCEPTABLE  → High
score below PLATFORM_OP_RISK_APPETITE      → Low
anything else                               → Medium

Scale trap. These are fractions between 0 and 1, compared against a total that is not capped at 1 — so in practice they behave close to all-or-nothing. Do not set them to 25 and 75 on the assumption that they are percentages.

Version history depth

Setting: NUMBER_OF_ANSWERS_BUNDLES · Default: 32

Caps how many answer-bundle versions are returned for an assessment, newest first. This controls how far back version history goes — including the depth behind the risk-over-time graph and the version selector. It does not change any status.

Raising it increases the size of the response for long-running assessments; lowering it hides older versions from your team.

Microsoft sign-in

These affect the “Sign in with Microsoft” flow only. Email and password sign-in and Google sign-in are unaffected.

Setting Type Default Notes
AZURE_AD_CLIENT_ID string empty Required for Microsoft sign-in. While it is empty, that sign-in method returns a not-configured error.
ENTRA_ID_MODE string single-tenant Either single-tenant for a dedicated deployment or multi-tenant for shared. Any other text is treated as single-tenant. The wrong mode causes Microsoft sign-in to fail validation.

Settings with no effect

These appear on the page but are not read by the platform. Editing them changes nothing.

Setting Default
RISK_SCORE_LOW 0.25
PLATFORM_ALIGNMENT_APPETITE 0.75
PLATFORM_COMPLIANCE_MIN_PERCENT 75
PLATFORM_COMPLIANCE_MAX_PERCENT 100
PLATFORM_POLICY_ALIGNMENT_RISK_HIGH_THRESHOLD 0.5
PLATFORM_POLICY_ALIGNMENT_RISK_MEDIUM_THRESHOLD 0.75

RISK_SCORE_LOW is the one that catches people out: an assessment reading Low is weighted with RISK_SCORE_NONE, not with this setting.

Dashboard components

The toggles at the top of the Configuration tab control which components appear on the project dashboard. They change what is shown, not what is calculated — no status moves because a component is hidden.

Each toggle is on or off, and the setting applies across the deployment rather than per user. There is also a control to switch them all on or off at once.

Component Default What it shows
Project Residual Risk On A pie chart of AI systems by residual risk level — Low, Medium, High.
Project Compliance On A pie chart of AI systems by policy compliance status.
Assurance Status by Project On A grouped bar chart of assurance results across Security, Privacy, and Bias categories.
Assessment Status Off A grouped bar chart of assessment progress — Not Started, In Progress, Approved — across Pre-Screening, Privacy, and Safeguard assessments.
Jurisdiction Map On A world map of AI systems by jurisdiction. Shown to Compliance and Governance Managers and to Org Admins.
Project Table — Assessment Status Columns Off Per-policy assessment status columns in the project list. See the note below.

Two are off by default. Assessment Status and the project table columns start hidden, so turning them on is how you add them rather than restore them.

The project table toggle is a swap, not an addition. With it on, the project list shows per-policy status columns for Pre-Screening, Privacy, and Safeguard. With it off, the list shows a single Assessment Completion column instead. You get one view or the other, so pick whichever your team reads more often.

Changes here take effect on the next page load. Because this setting is created the first time you save it, it may not appear in the settings table until then — that is expected, and the defaults above apply in the meantime.

Value scales

Mixing up a percentage and a fraction is the most common mistake on this page.

Group Scale
complianceThresholds (all six) Percentage, 0 to 100
Settings ending in _PERCENT Percentage, 0 to 100
RISK_SCORE_* Fraction, 0 to 1
PLATFORM_OP_RISK_* Fraction, 0 to 1

Setting a PLATFORM_OP_RISK_* value to 75 rather than 0.75 behaves very differently from what you intended.

Changing a setting safely

  1. Check it is not in Settings with no effect — otherwise nothing will change.
  2. Check the scale — percentage or fraction, from the table above.
  3. For complianceThresholds, remember the reach. It re-labels existing assessments and projects, and the assessment values also move project status.
  4. Reload before judging the result. A complianceThresholds change applies on the next page load — refresh and look again. The other settings are cached for up to five minutes, so give them a little longer before concluding a change did not work.
  5. Confirm the change landed by finding a record you expect to move and checking it did.

If a setting is missing from the page

A missing setting is not an error: the platform falls back to the default shown in this guide, so behaviour continues unchanged. You can add it back from the same page.

Requesting a new setting

If you need a setting that does not exist, contact your Asenion representative with the key you want, the value, its type, and what it should control. New settings are added by the Asenion team so that the change can be reviewed against the platform’s calculation logic.

  • Policy Configuration — control-level compliance identifiers, which produce the Layer 1 labels
  • Rules Configuration — screening rules and the classification that Inherent Risk prefers
  • Overview — how Assessment fits with Authoring, Testing, and Runtime Governance