Vulnerability Catalogue

A vulnerability is the weakness a threat would act through. A risk record pairs one threat with one vulnerability: something that could act, and the gap it would exploit.

The pairing is what makes a risk record a scenario rather than a worry. "Ransomware" is a threat; "unpatched internet-facing software" is a vulnerability; the two together are something you can assess and treat.

Fields

• Code
  Unique identifier, issued from the catalogue's number template when left empty.

• Name
  The weakness itself.

• Vulnerability area
  Which area the weakness sits in. One of six fixed values — see below.

• Description
  What the vulnerability covers.

• Active
  Inactive vulnerabilities are no longer offered on a risk form. Existing risks keep the one they named.

The six areas

The area is a fixed set, not a list you curate:

Area	Covers
Hardware	Physical equipment: ageing, unpatchable, unmaintained.
Software	Application and operating system faults, missing updates.
Network	Unsegmented, unencrypted or unmonitored communication.
Personnel	Missing training, unclear duties, absent segregation of duties.
Physical	Access control, siting, environmental protection of premises.
Organizational	Missing policy, unassigned ownership, unreviewed process.

note

The area is fixed for the same reason the threat source is: the catalogue is a reporting taxonomy before it is a picker. "Which area do most of our risks come from" is a question worth asking of a register, and it only answers if the areas mean the same thing everywhere.

The organizational area is the one most often under-used, and it is usually the most revealing. A register with no organizational vulnerabilities is describing a technical environment rather than a management system — and ISO 27001 is a management system standard.

The shipped catalogue

The module ships with 44 vulnerabilities across the six areas. It is a starting point: rename, deactivate, delete or add to it freely.

The rows ship in English as default content, and are meant to be curated.

note

Seeded on first install only. A later upgrade will not re-add a row you removed or overwrite one you rewrote.

Vulnerability and existing control are different things

A vulnerability is the gap. An existing control on the risk record is what is already in place against it. Recording both is what makes the initial score meaningful:

• The vulnerability says what is wrong.
• The existing controls say what is already mitigating it.
• The initial score is the risk as it stands today, with those controls working.

If you record the vulnerability but not the existing controls, the initial score will read as though nothing at all were in place — which makes the residual score look like an improvement that never happened.

Keeping the catalogue usable

The picker shows the catalogue flat — nothing narrows it by area or by the threat you chose. Search and filtering carry the weight.

tip

Write vulnerabilities as conditions rather than events: "administrator accounts without multi-factor authentication" rather than "account compromise". An event belongs in the risk definition; the catalogue is the list of conditions those events exploit, and conditions are what get fixed.

Deleting a vulnerability

A vulnerability cannot be deleted while any open risk names it, and bulk delete refuses the whole selection when any one row is in use — a partial delete would leave nobody able to say what happened.

Deactivate rather than delete: the picker loses the row while the risks that named it stay readable.

Excel import and export

The catalogue exports to Excel and re-loads from a filled-in template, with blank codes issued from the catalogue's number template.

Exporting the shipped 44 rows, editing them in a spreadsheet and loading them back is the practical way to put your own list in place.