In the previous post, I provided examples of some controls-related data that can’t be used to support automated cyber risk quantification (CRQ). But the news isn’t all bad. There are some data that can be used to support CRQ.
I covered a lot of ground in the previous posts, and rather than summarize them here I’ll assume you’ve read those posts already. So, let’s dive into the last analytic dimension…
In the previous two posts, I briefly discussed that:
- The CRQ market is rapidly growing, and there’s a strong desire to automate CRQ analysis...
In Part 1 of this series, I discussed that the market for cyber risk quantification (particularly automated CRQ) is growing rapidly, but that automation, done poorly, can to more harm than good. In this post, I’ll begin to discuss what it takes to automate CRQ responsibly.
Until recently, it’s mostly been organizations with visionary and early adopter tendencies who have embraced cyber risk quantification (CRQ). They understood the value and were willing to deal with the challenges.
