Risk Main Forms

A risk main form is the register that information security risks are opened in. It decides four things the risks underneath it cannot decide for themselves.

A main form is a scope, not a label. Choosing which form a risk belongs to is choosing its numbering, its authorization, its assessment approach and — where Asset Risk is installed — which assets are in play.

Fields

• Code / Name
  The register's identity.

• Code template
  The pattern that numbers the risks opened here. Optional.

• Code template editable
  Whether a person may overwrite the generated code.

• Counter start value / increment / width / padding character
  How the counter inside the template behaves.

• Counter
  How far the counter has advanced. Read-only — the register's own history, not a setting.

• Assessment approach
  Asset-based or event-based. See below.

• Asset selection required
  Whether a risk here must name something at stake.

• Active
  Controls whether the form is offered when opening a new risk.

• Authorizations
  The authorization matrix — see below.

• Asset groups
  The Asset Risk groups this register's risks may draw from — see below.

The code template

A main form can issue codes, issue codes that may be overwritten, or leave naming to the person entirely — a template is optional.

If a template is given it must carry the counter placeholder, and one without it is refused when you save. Without a counter, every risk under the form would be handed the same code and the failure would arrive later, on somebody else's save.

The risk form's code field shows the template, never a preview of the next number. A preview would name a code somebody else may consume before this person saves; showing the template is also how the system tells "untouched" from "typed by hand".

note

The counter advances per main form. Two forms given the same template both start at 1, independently — which is why a risk code is unique within its register rather than across the module.

The assessment approach

Approach	Means
Asset-based	Risks here are assessed against an asset. Something is at stake and the record names it.
Event-based	Risks here are scenarios with no particular asset behind them. The asset link may be empty.

The main form's choice is handed to every risk opened under it as a default, which the risk may then change on its own. A register is rarely purely one or the other.

note

Setting asset selection required on an event-based form contradicts the approach, so the requirement is dropped rather than enforced. If you need the asset link to be mandatory, default the form to asset-based.

The authorization matrix

Each row grants one identity a set of operations within this register:

Operation	Allows
Create	Opening a new risk here.
View	Reading the risks in this register.
Update	Editing a record that is open for editing.
Revise	Opening a new round on a risk in force.
Delete	Removing a record.
Cancel	Standing a record down, or giving up a revision.
View past revisions	Reading the earlier rounds of a chain.

Rows accept users, roles, user groups, positions and organization units — all five — so authorization follows the organization rather than a list of names.

Two properties matter in practice:

• The matrix is read live on every request and never copied onto a record. A change takes effect immediately on everything under the register, including records already in flight and revisions already open.
• It does not decide the approver. Approval tasks go to the record's own owners. The matrix decides who may act at all; the record decides who acts next.

A row that grants no operation at all is refused.

The asset group scope

Where Asset Risk is installed, a main form can name the asset groups its risks may draw from. This is what turns a main form from a label into a scope: a risk opened here can only link to assets assessed under those groups.

The picker is narrowed by Asset Risk's own authorization matrix, not by a query here — so you are offered only the groups you are allowed to see there. A group id posted directly, having never been offered, is refused.

note

Deactivating an asset group in Asset Risk is refused outright while any risk here still points at it. The group's own cascade reaches its assessments, not the security risks that name them — so the refusal has to come from this side.

Quick risk entry

Quick entry is the same create screen on a route that names no main form, so the form becomes a field on the screen rather than part of the address.

Forms you may create in	Quick entry	Menu landing
More than one	An ordinary picker, empty	The form list
Exactly one	The field arrives filled and read-only	Straight into that form's risks
None	An empty state	An empty state

Quick entry asks about create; the register's shortcut and the Statement of Applicability's shortcut ask about view. Somebody who may read three registers but write in none gets the form list and an empty quick entry — the expected outcome, not an inconsistency.

Deleting and deactivating

A main form cannot be deleted while any risk exists under it, and cannot be deactivated while any risk under it is still open.

It also cannot be deleted while it has a Statement of Applicability — the statement's lines are generated rather than written, so nobody would think of them as something to clear first, and the refusal has to be explicit.

Creating a main form

1. Open Information Security Risk Management → Definitions → Main Forms and choose New.
2. Enter the code and name.
3. Decide the code template, or leave it empty to name risks by hand.
4. Set the assessment approach and whether an asset link is required.
5. Build the authorization matrix.
6. Name the asset groups in scope, if Asset Risk is installed.
7. Save.

tip

One main form per ISMS scope, matching the scope statement your certificate describes. The Statement of Applicability is produced per main form — so a register whose boundary does not match your certified scope produces a statement that does not either.