2 min read · Updated September 2026
Essential elements of information are the sub-questions that break a priority intelligence requirement into parts a collector can actually pursue. A requirement states what the organisation needs to know; its EEIs state what specifically must be found out in order to answer it.
A priority intelligence requirement is usually too broad to collect against directly. Which threat actors are targeting my organisation is a legitimate question and a useless tasking: there is no single source you can point at it and no moment at which it is finished.
Essential elements of information are the layer that fixes this. They are the sub-questions that sit underneath a requirement, each narrow enough to assign to a source, and together sufficient to answer the parent.
Under which threat actors are targeting my organisation, the elements might be:
Each of those can be pointed at a particular asset. Each has an answer that can be found, recorded and later revised. Answered together, they produce a more detailed picture than any single sweep against the parent question would have.
It makes collection assignable. A requirement can be owned by a function; an element can be owned by a source. That distinction is what turns a requirement from a statement of intent into work somebody is doing this week.
It makes an answer auditable. When a report claims to address a requirement, the question "which element does it satisfy" has a real answer. Without the layer, relevance is asserted rather than demonstrated, and a report can be filed against a requirement it only glances at.
It exposes partial coverage. A requirement with four elements, three of which have sources behind them, is not being answered. It is being three-quarters answered, which reads as covered on a status board and is not the same thing at all.
Elements carry priority just as requirements do. Assigning explicit priority to both establishes a clear hierarchy and tells an analyst what to do when two things compete for the same afternoon. Without it the ranking still happens, but by accident.
Requirements in Conundrum carry their sub-questions rather than existing as single lines of text, and the wording of both is editable by the team that owns them. That matters because the phrasing is not decoration: it drives what surfaces beneath the requirement, so an element written more precisely changes what the analyst is shown.
