4.5 Asset Identification and Evaluation of Existing Controls

4.5 Asset Identification and Evaluation of Existing Controls

PECB's certification requirements state that valid risk management project activity must include "identifying assets, existing measures, risk sources, and potential consequences". Asset identification is therefore not an optional preliminary — it is part of the examined competency for risk identification, and the primary/supporting asset distinction appears in PECB's published sample questions.

---

Primary Assets vs. Supporting Assets

The classification comes from the information security risk lineage that PECB teaches alongside ISO 31000, and it is deceptively simple to state and easy to get wrong under exam pressure.

Primary assets are what the organization actually needs to achieve its objectives:

• Business processes and activities — order fulfilment, claims adjudication, clinical care delivery, payment settlement. A process is primary when its loss would prevent the organization from meeting a legal, contractual, or strategic obligation.
• Information — business information, customer records, intellectual property, strategic plans, and any data whose disclosure, alteration, or loss carries consequence.

Supporting assets are the resources that primary assets depend on:

Exam Tip: A published PECB sample question asks for an example of a primary asset, offering business information, personnel, and organizational structure. The answer is business information. Personnel and organizational structure are both supporting assets — they are indispensable, but their value is derived from the primary assets they enable.

The consequence of misclassifying is practical, not academic. Valuing a server rather than the process it runs leads an organization to protect replaceable hardware while leaving an irreplaceable process exposed.

---

Asset Valuation and Ownership

Each identified asset needs three attributes before it is useful in risk identification:

1. An owner — a named individual accountable for the asset, distinct from its custodian. The finance director may own the payments process; the IT operations manager merely custodies the server.
2. A value — expressed in whatever terms the organization's risk criteria use: financial replacement or revenue-at-risk, regulatory exposure, safety consequence, or reputational impact. Value should reflect consequence of compromise, not purchase price.
3. A dependency map — which supporting assets the primary asset relies on. Dependency mapping is what turns a flat asset list into an identification tool, because it exposes the single points of failure that a control inventory alone will not reveal.

---

The Identification Chain

Asset identification feeds directly into the ISO 31000 risk ontology:

Read as a sentence: a primary asset depends on supporting assets; a risk source acting on that dependency may cause an event; the event produces a consequence for objectives; existing controls modify either the likelihood of the event or the severity of the consequence.

---

Investigating the Effectiveness of Existing Controls

ISO 31000 requires that risk identification consider existing controls and their effectiveness. This is the step most often skipped, and skipping it corrupts everything downstream.

Design effectiveness asks: if this control operated exactly as intended, would it adequately modify the risk? A control can be perfectly executed and still be badly designed — a monthly reconciliation cannot detect a fraud that completes and is withdrawn within a week.

Operating effectiveness asks: is the control actually performed, consistently, by someone competent, with evidence? A well-designed control that is skipped during peak periods provides no assurance in exactly the conditions where it is needed most.

An assumed-effective control — one credited in the register but never tested — is the single most common cause of understated residual risk. If control effectiveness is not evidenced, the honest position is to rate the risk closer to inherent and flag the assurance gap as a finding.

Exam Trap: If a scenario states that a risk was rated "after taking existing controls into account" but no control testing has ever been performed, the register is recording an assumed residual rating. The correct response is to obtain assurance over the controls, not to accept the rating.

---

Real-World Example: A Hospital's Asset Reframe

A hospital group's risk register listed 1,400 supporting assets — servers, medical devices, licences — each with a replacement cost and a risk rating. The board could not use it, because nothing in it mapped to patient outcomes.

The risk team rebuilt identification around eleven primary assets: the clinical processes (emergency admission, surgical scheduling, medication administration, diagnostic imaging, discharge) and the information assets (the electronic patient record, the drug formulary). Each was assigned a clinical director as owner and valued in terms of patient safety consequence and regulatory exposure rather than replacement cost. Supporting assets were then mapped as dependencies.

The reframe immediately exposed a single point of failure invisible in the old register: three of the five critical clinical processes depended on one un-replicated integration server whose control set had never been tested. That server had been rated a low risk on replacement cost alone.