DSPM can answer how many records are contained in a database, and coupled with cyber risk quantification, can help you estimate the financial exposure that would be if they were all compromised. It will tell you which data is “restricted” or “confidential,” and which records are subject to additional regulation. Finally, you can use it to understand how many users or roles can access the database, and help you apply a more limited role, add security monitoring or alerting, and add human touchpoints to autonomous workflows.
If this seems too fundamental, you may already be in a highly mature or regulated environment. But elsewhere, and especially down market, there are lots of edge cases and grey areas that this kind of analysis helps inform. Crucially, it helps us move from binary labels and all-or-nothing decisions to quantified, accepted and mitigated risk.
Scaling the approach to bigger decisions
Let’s take this up a level, and this time, consider your entire security architecture. You have 15 “restricted” repositories. A critical remote code execution vulnerability is released, which affects eight of them, and your team moves into incident response mode. Which ones do you prioritize for patching with IT operations and forensic analysis? Pick the one with the most sensitive records (weighed against compensating controls), and thus, value at risk. You don’t need a six-figure platform to make that call, but you do need to have done the work of understanding where your most sensitive data sits.
