I've been using Hyperproof for a few months for our vendor risk process. Overall, I like it, but the questionnaire library feels really behind.
A lot of the templates are for standards or regulations that have been updated. I had to manually edit a SOC 2 one recently because it was missing key points from the new trust services criteria. Isn't that the whole point of a library? To save time? 😕
Has anyone else run into this? How are you dealing with it? Do you just build all your questionnaires from scratch now?
I've seen this exact lag in other GRC platforms too. The issue is these libraries treat compliance frameworks like static artifacts, not living documents that evolve annually. You're editing the SOC 2 template because the platform's update cycle likely only aligns with major UI releases, not AICPA publications.
Building everything from scratch isn't scalable either, especially for a small team. My approach has been to treat their library as a structural baseline only. I maintain a separate, version-controlled repository (using plain markdown or YAML) for the *actual* question sets per standard. Then I import that curated content into the platform when I need to launch an assessment. It adds an extra step but guarantees control.
Isn't it ironic? We use these tools to mitigate vendor risk while accepting significant operational risk from the tool's outdated content.
infrastructure is code
It's the same dynamic we see with some API client libraries: they promise convenience but can introduce their own form of technical debt when they fall behind. You're effectively maintaining a fork.
I've observed this lag makes the supposed time-saver a net negative. The manual edit you did for the SOC 2 template is now a unique artifact in your instance. When Hyperproof *does* finally update their master template, you'll have a merge conflict on your hands. Do you adopt their new version and re-apply your changes, or ignore their update entirely? You're now managing version drift.
Treating vendor libraries as a starting point, not a source of truth, is the only safe approach. Build your questionnaires from a controlled source, then push. It's more work initially, but it's predictable and avoids the surprise of outdated content.
sub-100ms or bust
You've hit on a classic platform problem that goes way beyond GRC - the library model itself has a fundamental flaw.
It's a versioning and dependency issue, just like in software. When you manually edit their template, you've forked it. Now you're on the hook for managing that divergence every time they push an update. That technical debt can really sneak up on you.
I agree with the other posters that treating the library as a baseline is wise, but I'd go a step further. Build your own core set of questions as plain text files or structured data (YAML, JSON) outside the tool. You can version those with Git, and it becomes your single source of truth. When you need to run an assessment, you import your curated content into Hyperproof. It's an extra step, but it gives you control and makes you resilient to their update schedule, which will always lag behind the actual publications.
What does your current process look like for tracking changes you make to their templates?
Design for failure.
You're right about the fork and dependency issue. It's the same problem we have with generated API client SDKs that lag behind the OpenAPI spec.
The version drift you mention is real. My process mirrors what you described: I keep core questions in a git repo as YAML. Each standard gets its own file with sections, question text, and references. A small script transforms it into the vendor's import format (usually CSV). This makes the tool just a runtime, not a source.
But there's a tradeoff you didn't mention. By externalizing the library, you lose any platform-specific features tied to their native templates, like automated scoring logic or pre-mapped control frameworks. You have to rebuild that mapping yourself, which can negate the time saved.
benchmark or bust