How to Design a CTI Service Catalog People Can Actually Use
Define CTI services by consumer, decision, input, output, timing, owner, and boundary so people know what to request and what to expect.
A service catalog prevents CTI from becoming an inbox where every request is urgent and every output is called a report. It tells consumers which decisions the team supports, what to provide, when to expect an answer, and what remains outside scope.
Build it from recurring decisions and validated intelligence requirements. A source feed, dashboard, or weekly document is not automatically a service; it becomes one only when an owner and consumer use it within a repeatable decision workflow.
Write One Service Card at a Time
Each card should name purpose, consumers, supported decisions, eligibility, required input, output, delivery channel, priority, normal timing, escalation, owner, review, feedback, and exclusions. Include one concrete example.
Use human names such as “urgent threat relevance assessment” or “quarterly threat landscape briefing.” Avoid internal process labels that consumers cannot recognize.
Balance the Portfolio Against Capacity
Estimate demand, effort, surge variability, specialist needs, and review load. Reserve capacity for urgent work. Remove duplicate services and clarify handoffs with incident response, vulnerability management, security architecture, and risk.
Publish prioritization rules. A transparent decline or later delivery is better than accepting work that the team cannot complete reliably.
Review Services Through Decisions
Track use, timeliness, repeat demand, feedback, rework, and examples of changed decisions. Interview non-users to find access or relevance problems. Retire decorative products that consume effort without a consumer action.
Review the catalog with requirement owners at least annually and after structural change. The intelligence lifecycle guide shows how feedback should change future collection and production.
Frequently asked questions
Is a CTI service catalog just a list of reports?
No. A service includes the consumer, decision, intake, method, output, timing, owner, feedback, and boundary—not only a document type.
How many services should a new team offer?
Start with the few services tied to the highest-priority requirements and proven capacity, then add only when demand and ownership are clear.
Does every service need an SLA?
Every service needs a timing expectation and escalation path; the formality depends on consequence and organizational practice.
How should one-off requests be handled?
Use a bounded research or advisory service with triage criteria rather than allowing exceptions to bypass all prioritization.
When should a CTI service be retired?
Retire or redesign it when its decision disappears, usage falls, outcomes are weak, another team owns it better, or capacity no longer justifies it.
