What should a risk taxonomy look like when it is not only about IT?
A risk taxonomy that only covers IT risk misses most of what a board or a regulator actually needs answered. It should cover operational, financial, third-party, conduct and technology risk within one consistent structure, with technology positioned as one category among several rather than the organising idea for the whole taxonomy. If a supplier outage is filed as a technology risk simply because a system was involved, the taxonomy is already organised around the wrong axis.
Published · Updated
Maximilian Bazzi, Founder and CEOWhat belongs in a taxonomy that is not only about IT
A taxonomy built to actually support decisions needs to cover, at a minimum, operational risk (process and people failure), financial risk, third-party risk, conduct and compliance risk, and physical or resilience risk, alongside technology and cyber risk. None of these should be a subcategory of another. A supplier outage is a third-party risk with an operational consequence, not a technology risk simply because a system was involved.
Why IT-only taxonomies happen
Most organisations do not set out to build an IT-only taxonomy. It happens because the first serious attempt at formalising one is usually driven by a cyber security programme or a GRC tool selection led by IT, and whichever categories that project needs become the default the rest of the organisation inherits. By the time other risk owners are asked to use the taxonomy, its shape is already set.
Where teams commonly run into difficulty
Two patterns repeat. The first is a taxonomy inherited from a platform or a prior project that quietly encodes an IT-first view of risk, which non-technology risk owners do not recognise as describing their own work. The second is the opposite overcorrection: a taxonomy so broad and generic that it fits everything and therefore decides nothing, because no category maps to a real owner or a real control.
How Bazzi Consulting helps
We build the taxonomy from how your organisation actually experiences risk across every function, not from whichever platform or team happens to be formalising it first. See risk and resilience advisory.