Your CISO says "I want to know about ransomware." Turn that into something you can actually collect against.

As stated it is not a requirement — it has no decision attached, no scope and no end state, so no amount of collection would ever satisfy it. The first move is a conversation, not a collection plan.

I would go back and ask what decision this is supporting. "I want to know about ransomware" usually turns out to be one of several very different questions: are we likely to be hit, would we survive it, is our current control programme aimed at the right things, or do I need to answer a board question next month. Each of those produces a completely different requirement.

Suppose it is the control programme. The priority intelligence requirement becomes something like: which ransomware operations have targeted organisations in our sector and region in the last twelve months, what initial access vectors did they use, and which of those vectors would our current telemetry and controls fail to catch?

That decomposes into specific information requirements. Which operations are active against our sector, from what sourcing. What initial access techniques each used, mapped to ATT&CK. Which of those techniques we have detection for, validated rather than assumed. What our exposure looks like on the vectors that come out top — internet-facing services, remote access, third-party connections. And whether there is evidence of pre-positioning against us specifically.

Each of those is collectable, and each has a place to collect from, which the original request did not.

I would also agree three things up front: who the audience is and therefore what altitude the product is written at, when the decision point is so the timing is right, and what "answered" looks like so the requirement can be retired rather than becoming a standing obligation to produce ransomware content forever. And I would set a feedback point to find out whether it was actually used, because that is what improves the next requirement.