Six tools, six bills, no shared truth
Why your GRC, vendor risk, audit, vulnerability, pen test, and contract stack is the problem. Not the symptom.
I have spent twenty years in IT operations and security across labs, healthcare systems, airports, an MSP, and my own company. The shape of the compliance stack has been roughly the same the entire time. The names changed. The problem did not.
Here is the shape: a CISO buys a GRC tool. Compliance buys a vendor risk tool. Procurement buys a contract lifecycle suite. Audit buys an audit platform. Engineering buys a vulnerability aggregator. The CTO buys a pen test tracker because nothing else handles engagements.
Twelve months later, none of it talks to each other. The auditor asks why a vendor with an open critical CVE is still in your contracts pipeline and nobody can answer in under two days. The risk register has not been updated since the last quarterly board meeting because the people who own the risks do not have logins to the tool that holds them. The CLM knows when contracts expire; the risk register does not. The vulnerability scanner knows what is critical; the audit platform does not.
This is not a failure of the individual tools. Most of them are well-built. It is a failure of the architecture. Six tools, six data models, six SSO integrations, six bills, six SOC 2 reviews. The compliance team becomes a translation layer between systems that should never have been separate.
What “one graph” actually means
A control is also a vendor obligation. A vulnerability is also an audit finding. A contract is also a risk-register entry. The work happens at the intersections; the tools live in the silos.
What I want, and what I think you want, is a single graph where:
- A control node connects to the framework it satisfies, the risks it reduces, the assets it covers, and the evidence that proves it.
- An audit finding connects to the control that failed, the asset where it was found, the engineer who owns the asset, and the contract obligation that triggered the audit in the first place.
- A vendor record connects to the contracts you have with them, the questionnaire you sent them, the SOC 2 report they sent back, the assets you have at them, and the breach feed that flagged them yesterday.
- A vulnerability connects to the asset, the team that owns it, the SLA timer based on your control library, and the evidence record that auto-closes the loop when it is patched.
When that graph exists, every question you used to ask six tools is one query. When the auditor asks you to demonstrate that you have a vendor risk program with closure tied to your control state, you do not assemble it from spreadsheets. You show them.
“But our tools have an API”
They do. APIs are a workaround for the absence of a shared model, not a replacement for one. I have built three of these integration glue layers personally. They all break the same way: the source of truth becomes “whichever tool was last updated”, which means in practice no tool is the source of truth. The integration becomes a fourth system to maintain, with its own outages and its own subtle data corruption.
If your compliance program has a daemon syncing your GRC tool to your vendor risk tool, you are paying compliance team salaries to keep the integration alive. That is the work the platform is supposed to be doing.
“But we already bought the tools”
I know. I have been the person who bought the tools. The pitch I am making is not “rip and replace right now”; it is “the next time you renew, ask whether you are paying because the tool is the best, or because the cost of switching is too high”.
The cost-of-switching part is built on the bet that nothing will ever connect these silos. That bet is starting to lose.
What we are doing about it
opsnite ships GRC, audit, vendor risk, vulnerability management, pen test management, and contract lifecycle as six surfaces on the same data model. Adding a module is a feature flag, not an implementation project. Every node in the graph connects to every other node it should connect to.
We are not the only people thinking this way. We will not be the last. But we are honest about what we are building and what we are not, and we will tell you when our product is the wrong fit for what you are trying to do.
If your compliance stack feels like the failure mode I described above, talk to us. If it does not, that is a useful data point too. Please tell me what is working.