Workspaces and registers
These two are easy to confuse, and getting them the wrong way round leads to settings nobody can find. The short version:
| Workspace | Risk register | |
|---|---|---|
| What it is | A folder of registers, plus default settings | A domain of risk, and the unit of configuration |
| Example | Operational Risk, ISMS, Third Party | IT & Security Risk, Branch Network Risk |
| Holds risks? | No | Yes |
| Methodology | Supplies a default | Owns it |
| Appetite | Supplies a default | Owns it |
| Layout | Supplies a default | Owns it |
Defaults are copied, not linked
A workspace supplies defaults at the moment a register is created. Changing a workspace default afterwards does not change registers that already exist. This is deliberate: a register’s methodology must not change under it because somebody edited a folder setting.
Why the register owns the configuration
Because the register is where the numbers are. Risk appetite is meaningless without the scale it is expressed in, and the scale comes from the assessment methodology. Put both on the same object and they can never drift apart.
This also keeps the permission model small. Because a workspace holds no configuration of its own, it does not need to be a separate dimension of access — it is simply one of the things a grant can point at.
Choosing between them
Create a new register when a set of risks needs its own methodology, its own appetite, or its own owner. Create a new workspace when a group of registers should be administered together and share defaults — typically one per risk domain, or one per business that runs its own risk programme.
When in doubt, create a register. Registers are cheap; workspaces are structure.