The three lenses
Artificial intelligence; climate and physical hazards; third parties and the components they supply. A lens is not a layer: it cuts through every layer and adds attributes to the objects it touches.
What a lens is and is not
A lens is not a layer, because it has no step of the cycle of its own. It is not a branch of the taxonomy either, although each lens has one, because a branch tells you where a risk is filed and a lens tells you what else must be known about it. The nearest analogy is a set of mandatory extra columns. When a register row concerns an AI system, it acquires attributes an ordinary row does not need: which trustworthiness characteristic it threatens, what its current and target profile are, what decision right its appetite allows. When a row concerns a warehouse or a piece of collateral, it acquires a hazard code, an exposure and a vulnerability. When a row concerns a supplier, it acquires the component delivered, the parties behind the supplier and the place the thing was made. The row stays in the same register, under the same eleven fields, with the same owner and response. The lens is what the layers ask in addition.
The alternative, which most organizations have in fact built, is a separate register per subject: an AI inventory kept by technology, a climate assessment kept by sustainability, a third-party register kept by procurement. Each has its own fields and scales, none joins the enterprise register, and the board receives three reports that cannot be summed because they were never meant to be. The framework's rule is that there is one register and that a lens adds to it. Why these three lenses? Because they are the subjects on which the sources were still being written while this book was, on which no single discipline has authority, and on which the separate-register mistake is most common.
The AI lens
Artificial intelligence enters the framework twice, as a risk and as a tool that executes the framework; the lens concerns the first, and chapter 23 the second. Three sources shape it. The AI risk management framework [21] supplies the vocabulary: seven characteristics of a trustworthy system, four functions (govern, map, measure, manage) with seventy-two subcategories, and, in its generative profile, twelve risks each tagged with its stage and its source. The supervisors' report on AI in finance [27] supplies the systemic column: dependence on a few providers, correlated behavior across firms using the same models, cyber exposure, model and data risk, and misalignment. The project tradition's AI branch [3] supplies what both leave out, a rule tying what a system may do to the appetite declared for its branch.
Layer by layer, the lens works like this. In L0 the governing body decides, through the appetite scale of C1.3 applied to the AI branch, which of three decision rights a class of systems may hold: act reversibly under monitoring, prepare an action for a human to approve, or inform only; this is the appetite-to-autonomy rule of C4.7 [3], and it is a governance decision, not a technical one. In L1 the branch carries an appetite position like any other category. In L2 it exists in the source taxonomy of C2.1, populated with the twelve generative risks and the five vulnerabilities as controlled lists in C2.5, and every AI risk is a validated statement under C2.2 with the model or its use as the condition. In L3 the Measure function becomes a declared test per characteristic, with the three levels of testing, model, red team and field [21], recorded as the level the evidence reached. In L4 the system has a current and a target profile and the controls that close the gap, each carrying its hierarchy level under C4.2, because a policy forbidding a use is administrative and a technical block on it is engineering. In L5 the indicators include drift against the test that qualified the system, and an incident involving a system is an incident like any other under C5.4. In L6 the profile pair is the maturity instrument, and the assurer applies the topical requirement on cybersecurity [18] where the system is in scope.
The climate and physical hazards lens
This lens exists because the sources that describe physical risk come from three communities a bank does not usually read, and because, read together, they let the same register hold a transition risk, a flood and a supplier outage without changing its structure. The climate scenarios [13] supply the reference futures: long-term pathways with an explicit model chain, short-term scenarios with sectoral probabilities of default that join to an industry code, transition and physical variables kept apart, and, after the retraction of December 2025, a version and a retraction status on every input. The hazard profiles [24] supply the dictionary of two hundred and eighty-one coded hazards and its grammar: risk as hazard, exposure, vulnerability and capacity, each measured separately. The composite index methodology [7] supplies the three cadences, structural risk yearly, a crisis monthly, a warning months ahead, and the model of a georeferenced loss base in which a physical event is recorded with a place and a date.
Through the layers, the lens asks one question at each: where is it? In L0 and L1 the question is which objectives are exposed to place, and the appetite scale carries positions for physical and transition risk. In L2 identification consults the hazard dictionary as one of the controlled vocabularies of C2.5, so that a branch, a plant, a data center or a piece of collateral carries the codes of the hazards it is exposed to rather than the words “natural catastrophe.” In L3 the component C3.8 parameterizes a physical scenario by hazard, exposure, vulnerability and capacity [24] and a transition scenario by the reference pathway's variables [13], keeps the two apart, and records version and retraction status on each input. In L4 the response is often continuity rather than mitigation, which is why the lens reaches into C5.6, and a flood barrier or a relocated server room is an engineering control under C4.2, one of the few places in a financial register where the top of the hierarchy is available. In L5 the early-warning arrangement is judged against the four pillars and three cadences of C5.7, and a physical event enters the loss base with its coordinates. In L6 the register joins to any public dataset carrying the same hazard codes, which makes a principal-risk page about physical risk defensible rather than adjectival.
The third parties and components lens
The third lens moves the unit of analysis from the supplier to what the supplier delivered, and then back out to the system. The supply-chain tools [15] supply the component: bills of materials with eleven minimum fields, the known-unknowns rule under which a list that does not say it is complete is read as incomplete, the nth parties behind a supplier and the geography of manufacture. The supervisors' third-party toolkit [27] supplies the systemic view: the critical service, the nth party several contracts away, and the concentration that is systemic because many institutions depend on one provider, which is also the first AI vulnerability, so the two lenses share a column. The auditors' topical requirement on third-party management [18], mandatory since September 2026, supplies what an engagement must cover, which is the assurer's checklist for the lens. The operational-risk principles [17] add the older rule that a service outsourced is a risk retained, and that a new provider passes the gate of C4.4 before it is relied on.
Through the layers: in L0 the governing body names which services are critical and sets an appetite position for concentration, because concentration is a decision a board makes by not making it. In L2 the component record of C2.7 is populated from bills of materials where the supplier provides them and marked incomplete where it does not, and a vendor questionnaire is accepted only where every question traces to a standard [15]. In L3 the concentration measure is a composite index under C3.5 with its reliability published, since a vendor that left half the questionnaire blank must not score as well as one that answered it; and a supplier failure is one scenario touching several processes through the source-organized taxonomy of C2.1. In L4 exit and substitution are responses, and a contractual clause is an administrative control that should not weigh as heavily as a tested fallback provider. In L5 the incident record of C5.4 carries origin as a field, internal, third party or external, so that third-party incidents are a view of the one incident base and not a separate log [27]. In L6 the assurer follows the topical requirement and documents reliance on the provider's own assurance under C6.2, the point at which most third-party programs are weakest.
What the lenses share
Three regularities govern any fourth lens an adopter might add. A lens never opens a second register; it adds attributes to rows in the one register, and the attributes have sources. A lens contributes at least one external vocabulary to C2.5, so that a risk under it is named in words someone outside the organization also uses. And a lens names what the assurer should look for, because a subject that crosses every layer is exactly the subject on which the second line will otherwise audit itself. A proposed fourth lens can be tested against these three.