Terminologies
CyberGuard ships a default vocabulary for the values that appear in dropdowns and badges — risk origin types, project statuses, personal-data categories, accreditation labels and more. Terminologies lets you reshape that vocabulary to match how your organisation actually speaks, without touching the data model underneath. One team’s “Risk origin: state” is another team’s “Adversary: nation-state”; the records behave identically either way.
Where to find it
Section titled “Where to find it”Extra → Terminologies in the sidebar.
How an entry works
Section titled “How an entry works”A terminology entry binds a name to a field path — the specific place in the interface where that value can appear. The field paths that ship today are:
| Field path | Where it surfaces |
|---|---|
ro_to.risk_origin | Risk origin types on risk-origin / target-objective couples in EBIOS RM |
qualifications | Qualification tags on incidents, risk scenarios and BIA escalation thresholds |
accreditation.status | Status values on accreditation records |
accreditation.category | Category values on accreditation records |
entity.relationship | Third-party relationship types |
metric_definition.unit | Units shown alongside metric values |
project.status | Workflow statuses on projects |
project.health | Health indicators on projects |
processing.nature | The nature of a processing activity in the privacy register |
personal_data.category | Categories of personal data in the privacy register |
Each field path arrives with a built-in set of entries. Against that set you can:
- Add entries of your own, alongside the built-ins.
- Hide built-in entries you never want offered, using the visibility flag.
- Translate entries through the standard library translation mechanism.
Terminology is additive on top of a working set, never a replacement: whenever an entry is missing or hidden, the platform falls back to its built-in default, so nothing breaks if you hide too much.
Scoping
Section titled “Scoping”Terminology entries live in the root folder, so they apply organisation-wide rather than per domain. Treat the list as a shared asset: renaming a status changes it for everyone, on records that already exist.
Working with it
Section titled “Working with it”Start from the objects you use most. If you run the privacy register, the two field paths worth curating first are processing.nature and personal_data.category — they are the ones the processings register and personal data pages read from, and getting them aligned with your internal data dictionary makes the ROPA far easier for privacy staff to fill in. If you run project management, do project.status and project.health next.
Hide before you add. A dropdown of thirty values, twenty-five of which your organisation never uses, is worse than the default — hide the irrelevant built-ins first, then add the handful of terms you actually need.
Related
Section titled “Related”- Processings (ROPA) and Personal data — the privacy field paths.
- Projects and Accreditations — the project-management field paths.
- Labels — a different kind of organisation-defined vocabulary.