Why recommendations are capability-driven

Capabilities are the source of truth in Forest, and recommendations inherit that discipline. Every suggestion points at a security function or process, not a product you should buy.

This choice has real consequences. A capability like Patch Management or Identity Provisioning describes what your program needs to do. It outlives any single tool. When you swap vendors, your capabilities and their maturity scores stay meaningful, and so do the recommendations built on them. A recommendation tied to a product would expire the moment a contract did.

Capability anchoring also keeps the logic honest. Priority comes from maturity gaps and criticality, both measured at the capability level. Impact comes from recalculating capability-weighted scores. Because the chain runs capability to priority to recommendation, every result traces back to something concrete you assessed.

Contracts and tools still matter, but they play a supporting role. They map to capabilities to reveal overlap and spend issues, and they inform effort. They do not drive the scoring or generate recommendations on their own.

Tool-first guidance sells products. Capability-first guidance solves problems. Forest is built for the second.

The payoff is advice you can trust across reorganizations, vendor changes, and budget cycles. To see how this flows end to end, revisit how recommendations are generated.