Where your vendors' SOC reports and contracts should live, and what each choice gives up

A third-party risk system holds some of the most sensitive documents an organisation has about other organisations: vendors' SOC 2 reports shared under NDA, penetration test summaries, insurance certificates, signed contracts with their liability caps and pricing, and the organisation's own judgement of which suppliers are weak. For many companies, keeping that in a well-run SaaS service is the obvious choice. For banks, insurers, public bodies and others with strict outsourcing and data-location rules, putting it in yet another vendor's cloud is the very risk the system is meant to manage.

InsightVendors is offered both ways, from the same software. This post sets out what each edition gives you, what it gives up, and how to decide. It is written for CISOs and the risk and platform leads who will live with the choice. The short answer: choose SaaS unless a rule or a firm policy says you cannot, and if you choose self-hosted, know what you are giving up.

What sits in a vendor-risk system

Before choosing where it runs, be clear what it holds. Beyond the vendor list itself, a working programme accumulates:

• vendors' SOC 1 and SOC 2 reports, ISO certificates and penetration test summaries, usually shared under confidentiality terms that restrict where they may be stored and who may see them;
• contracts, order forms and DPAs (data processing agreements), with prices, liability caps, termination rights and notice dates;
• findings: the organisation's own written view of each vendor's weaknesses, some of them internal only;
• the map of which vendors hold which data and connect to which systems, which is also a map an attacker would value.

That is a third-party risk in its own right. Whoever hosts the system becomes one of your vendors, with access to all of the above. A sensible programme applies its own tiering to that decision: it is a Tier 1 relationship either way.

The two editions

Both editions are built from the same container images, so the product is the same: the same agents, the same lifecycle, the same vendor portal and outbox. What differs is who runs it, where the data lives, which AI model (if any) the agents use, and a small number of features that depend on a shared service.

	SaaS (default)	Self-hosted
Who runs it	VerticalServe: upgrades, availability, backups	Your team, with Docker Compose on your infrastructure
Database	Managed PostgreSQL; tenants isolated by row-level security	Your PostgreSQL, used only by you
Where documents live	In our hosted environment	In your environment
AI model	Provided with the service	The model of your choice, or none
Agents without a model	Available; every agent has a rule path	Fully supported; every agent has a rule path
Upgrades	Continuous, done for you	When you pull new images
Vendor network (planned for 1.3)	Will be available	Not available: it needs a shared service
Vendor portal and email approvals	Work out of the box	You expose the portal to vendors and provide outbound email

The AI question: your model, or none

For many risk teams the real concern is not the database but the model. Sending a vendor's SOC 2 report or a contract to a third-party AI service is a disclosure, possibly one the vendor's NDA does not allow. Self-hosted InsightVendors lets you point the agents at a model you already approve, including one running inside your own environment, or at no model at all.

No model at all is a real option, not a degraded demo. Every agent in InsightVendors has a rule-based path: pattern extraction for documents, rules for routing and tiering, deterministic arithmetic for risk scores, and templates for messages. The model makes the output better — better summaries, better handling of unusual document layouts, better-written redline proposals — but it never makes it work. Each agent run is badged “Rules” or “Model”, so reviewers always know which path produced what they are reading.

Two rails apply in both editions. Grounding: if a number in a model's answer is not in the source facts, the answer is thrown away. And the risk score itself is always deterministic arithmetic with weights the customer owns; a model can explain the score, but never invents it.

The vendor network, and why it is SaaS-only

The largest single difference between the editions is not available in either yet. The vendor network, planned for release 1.3, lets a vendor answer an assessment once and share it with every customer who asks, instead of filling in the same questions for each. For buyers it means faster answers; for vendors, far less repeated work.

A network needs a shared place where vendors' answers live and from which customers can request them. That place is the SaaS service. A self-hosted install is, by design, a closed environment, so it cannot join. If the vendor network matters to your programme — for example, if you review many common SaaS vendors that are likely to be on it — that is a reason to prefer SaaS. If your vendors are mostly specialised suppliers unlikely to be on any network, it matters less. Either way, we would not choose an edition today on the strength of a feature that is still planned.

How to decide

A first pass. Your compliance team's reading of the rules comes first.

In practice, the decision tends to follow the sector. Most technology companies, professional services firms and mid-sized businesses choose SaaS: the operational burden is the vendor's, they get features first, and their auditors are satisfied by the service's own assurance. Banks, insurers, healthcare providers and public bodies more often choose self-hosted because an outsourcing rule, a data-location requirement or an internal policy leaves little choice. Neither is the “serious” option; they answer different constraints.

Review the edition you choose like any Tier 1 vendor

Whichever edition you pick, apply your own programme to it. If you choose SaaS, VerticalServe becomes a Tier 1 vendor holding confidential documents about your other vendors, and it should get the review a Tier 1 vendor gets: its own assurance documents, its subprocessors, its DPA, where the data is held and which AI model sees what. Tenants in the SaaS service are separated by PostgreSQL row-level security, which means every query is filtered to your organisation inside the database itself, not only in the application; ask us how that is tested.

If you choose self-hosted, the review turns inward. Your platform team becomes the operator, and the questions an auditor would ask a hosting provider now land on them: who has administrative access, how backups are taken and tested, how quickly security updates are applied, how the vendor portal is exposed to the internet and protected, and where the AI model, if any, runs.

Moving between editions

Because the editions share the same images and the same PostgreSQL schema, the choice is not permanent. An organisation can start self-hosted while its outsourcing review runs and move to SaaS later, or start on SaaS and bring the system in-house if a new rule requires it. Plan the move as a data migration with a cut-over date, and expect to re-check integrations such as email and the vendor portal address. Talk to us before you commit to either path; pricing is by vendors under management in both editions, and we will quote against your situation.

Keep reading