Finally, we come to compensating controls. Think of these as activities we can take in lieu of replacing the vulnerable code by reducing risk to an acceptable level. Additionally, we may decide to fix the vulnerability but can’t do so for 90 days due to development schedules or the complexity of the fix. In those cases, we need to mitigate the risk posed by a vulnerability until you can fix the vulnerability.
How? You need information about the vulnerability and likely attack vectors. For example, there may be rules for your IDS or IPS that can alert you, or WAF rules that can block the attack. If you execute the exploit in a test environment, you can generate data on what to look for in your SIEM. You may even find that the compensating controls you implement mitigate the risk to an acceptable level for your organization, and eliminate the need for vulnerability remediation in this case.
Finally, in many cases, understanding the artifacts generated by the exploit are a good practice regardless of how quickly you can remediate a vulnerability. Remember that these vulnerabilities have often been in the code base for years prior to public disclosure. Heartbleed, for example, was present in OpenSSL for over 2 years. Shellshock was present in Bash for 25 years! Just because a vulnerability that has been present for years was only disclosed recently, it's a mistake to believe that nobody had prior knowledge of the issue.