When a platform holds your contracts and your prices, the security questionnaire is not a formality, it is the deal. Beyond keeping tenants apart, the real questions are where the data lives, how it moves, who can reach it, and what happens when you leave. Here are the answers, in plain terms.
A platform that holds your software contracts and your negotiated prices is holding some of the most commercially sensitive data your organization has. Your contracts reveal your obligations and your leverage; your prices reveal exactly what you pay and where you are exposed. So when your security team sends the questionnaire, it is not bureaucratic friction, it is the right instinct, because the value of the platform is inseparable from the trust that it will not become the source of a leak. The questions that matter are simple to ask and revealing in how they are answered: where does the data live, how does it move, who can reach it, and what happens to it when you go.
Isolation between customers is the first control and deserves its own scrutiny, but it is not the whole of a security posture. A buyer doing real diligence looks past the isolation claim to the surrounding architecture: how the data is protected in transit and at rest, where the actual files live, how the keys and secrets are handled, who among the vendor's own staff can reach anything, and whether every access is recorded. A platform worth trusting with this data should be able to answer each of those specifically, not with a reassurance but with a mechanism.
The baseline is encryption on both axes, and it should be genuinely baseline, not a premium feature. Data moving between you and the platform travels over encrypted connections, so it cannot be read in transit, and data sitting in the database and file storage is encrypted at rest, so a compromise of the underlying storage does not hand an attacker readable contracts. These are table stakes, and their absence would be disqualifying, but they are worth confirming explicitly rather than assuming, because "we take security seriously" is not the same statement as "everything is encrypted in transit and at rest."
Encryption at rest matters most for exactly the data this kind of platform holds. A stolen backup or a misconfigured storage bucket is one of the most common ways sensitive data leaks, and encryption at rest is what turns such an incident from a breach into a non-event, because the exposed data is unreadable without the keys. The right answer to "is our data encrypted?" is a flat yes on both axes, and the follow-up question, about how the keys themselves are managed, is where a serious buyer keeps pressing.
The contract documents themselves are the most sensitive artifacts, and where they live is a specific question worth asking. The right answer is private storage, never a public location, reachable only through short-lived signed links rather than durable URLs that could be shared or leaked, and subject to the same access rules as the rest of your data. Files should also be validated on the way in, checked that they are genuinely the file type they claim and scanned before they are trusted, so that the storage cannot be used as a vector for something malicious. A document that is less protected than the record pointing to it is a side door, and there should not be one.
The other quiet risk is secrets: the keys and credentials the platform uses to reach its own infrastructure and any connected systems. These should never live in the code or the repository, where they could leak through a source-code exposure, but in environment configuration, and where the platform stores credentials for your integrations, those should be encrypted rather than held in the clear. A vendor's handling of its own secrets is a strong signal of its overall discipline, because a team that hard-codes a key is a team that will make other mistakes, and a team that keeps every secret out of code and encrypts stored credentials is showing you how it thinks.
Access is the axis buyers most often underexamine. Beyond keeping customers apart, the question is who among the vendor's own people can reach your data, and the honest architecture keeps that power narrow and separate, held in its own place rather than granted casually, and protected by strong authentication, with multi-factor required for the privileged accounts that can see across the platform. The right posture treats broad access as a rare, deliberately controlled privilege, not a convenience, so the answer to "who can see everything?" is short and specific rather than "our support team, as needed."
And every consequential action should be recorded. An audit trail that captures who did what, to which record, and when, including views and downloads of your contract files, is both a security control and the thing that lets you verify the other controls are working. Isolation and access rules prevent what should not happen; the audit trail records what does, so trust is observable rather than promised. Rate limiting on the sensitive routes and strict security headers round out the posture, the unglamorous hardening that keeps the front door solid, and a buyer should expect all of it to be present and be told so plainly.
A sound architecture is necessary but not sufficient, and no honest vendor should ask you to take it on description alone. Controls have to be implemented correctly, tested, and maintained, and the right diligence goes beyond the design to the evidence, the audits, the penetration tests, the certifications, the track record. The architecture tells you how the platform intends to protect your data; the evidence tells you whether it actually does, and a buyer should ask for both.
What understanding the architecture gives you is the ability to ask the questions that matter and recognize a real answer. A platform that holds your contracts and prices owes you specifics: encrypted on both axes, files in private storage behind short-lived links, secrets kept out of code, access narrow and logged, and a clear path to delete your data when you leave. When the answers are that concrete, you are being shown a security posture rather than sold a reassurance, and concrete is the only thing that should earn your most sensitive data.
Fredrik has spent more than twenty years in enterprise software, with time at Oracle, IBM, SAP, and Salesforce before moving to the buy side. He structured and priced the kind of large agreements most buyers only see once or twice in a career, which taught him where the leverage sits and how far a vendor will actually move. He started VendorBenchmark to hand that knowledge to every sourcing team.
What shipped on the platform, and the pricing and licensing moves worth knowing before your next renewal. One email a week, to your work address. Unsubscribe any time.