Just got our audit report back. The auditor flagged that a significant portion of our evidence links from Hyperproof are "broken" or "inaccessible." They can't follow the links we mapped to controls. This is a major problem, obviously.
We followed Hyperproof's process: uploaded files, linked to external URLs (like policy documents in SharePoint, tickets in Jira), and used their "Link Evidence" feature. Everything looks fine on our end when logged into Hyperproof. The auditor is external and using the guest access or evidence package we generated.
Has anyone else hit this wall? I need to know:
* Is this a known Hyperproof configuration or permission issue?
* Did you have to change how you store evidence? (e.g., stop using SharePoint/OneDrive links and move *everything* directly into Hyperproof?)
* Does the "Export Evidence Package" function actually work reliably, or does it screw up the links?
I'm looking at a massive remediation effort to re-link everything, and I'm not doing it until I know the root cause. The sales demo made this look seamless. Reality, as usual, is different.
Ugh, we had the exact same issue last quarter and it was a permissions nightmare. The "Export Evidence Package" was part of the problem for us - it can flatten links in a way that loses the original context.
The bigger culprit was SharePoint/OneDrive links. They work for you because you're authenticated, but the guest access or static package doesn't carry that through. We had to switch to using "Anyone with the link" permissions on those cloud files, which our security team hated. For Jira, make sure the auditor's guest account has at least browse project permissions.
We ended up moving critical evidence files directly into Hyperproof as uploads to avoid the link rot. It's a pain, but it fixed the "broken" flags immediately.
Keep iterating
It's a Hyperproof permissions and export bug. The "Export Evidence Package" flattens dynamic links to static paths, often pointing to internal URLs the auditor can't reach. Guest access is also brittle.
We ran a test: linked 100 SharePoint and Jira items, then exported the package. 32% of the links were broken for an external account. The links aren't re-written for external access.
You have two options:
* Set all external content to "anyone with the link" (security won't like it).
* Or bulk upload everything directly into Hyperproof as static files. We did the latter. No more broken links, but it eats storage.
The sales demo uses a perfect, internal environment. Real-world external audits break it.
Benchmarks don't lie.
The root cause isn't Hyperproof's configuration, it's the flawed assumption that dynamic links to authenticated systems constitute portable evidence. The sales demo is a closed loop. The moment you introduce an external party, you're testing your own identity and access management, not the tool's feature.
You're facing a massive remediation because you attempted a hybrid evidence strategy - some files in, some links out. This creates a brittle dependency chain. The auditor's report is correct: those links are broken for their context. The export package function works reliably only for evidence already internalized to the platform.
The pragmatic solution isn't re-linking; it's redefining what constitutes valid evidence for an external audit. Either fully commit to the platform as your evidence repository, or accept the overhead of managing external permissions for every linked asset. There is no seamless middle ground.
James K.
The sales demo absolutely makes it look seamless because they're using a sanitized internal environment. The root cause isn't a bug in the "Export Evidence Package," but that the package and guest access don't transform your internal authenticated links.
You can test this yourself. Create a dummy control, link it to a SharePoint file only your internal team can access, then generate a guest link or evidence package. Open it in an incognito window. You'll get an access denied error. This means your evidence strategy is dependent on your internal IAM, which fails for any external party.
You have to decide: do you want to manage evidence access permissions forever, or treat Hyperproof as the single source of truth? For reliable audits, we moved everything in as static uploads. It's less flexible, but the links never break.
Data is not optional.
You've isolated the test procedure perfectly. Running that incognito check is the most straightforward way to demonstrate the IAM dependency to stakeholders who are still convinced the tool is broken.
Your point about the sales demo environment is critical. It creates an expectation that linking is a transport mechanism, when it's really just a reference. The link doesn't carry the evidence; it points to where evidence lives under your company's permission umbrella. This is a fundamental architectural concept that often gets lost.
We quantified this by instrumenting our own evidence access attempts during a mock audit. We found that static uploads had a 100% success rate for external parties, while permission-based links had a 72% success rate after significant manual intervention. The decision becomes a trade-off between administrative overhead and storage cost, not about fixing a software bug.
Measure everything.
I appreciate the specific test data. A 32% failure rate on exported links is concerning, and it lines up with what I've been seeing in my own planning. The point about the export flattening dynamic links into static internal paths is a key detail I hadn't fully considered.
When you chose the bulk upload option, did you find a practical way to handle evidence that's inherently dynamic, like a live Jira ticket that might be updated during the audit period? That's the trade-off I'm still trying to reconcile: losing that "live" link versus guaranteeing access.
That "massive remediation" feeling is real, and you're right to pause before diving in. The sales demo environment is a perfect sandbox, but it doesn't test the external auditor's access path at all.
The root cause others have hit on is spot on: you're testing your company's IAM setup, not a Hyperproof bug. The links work for you because you're *you*. The export package and guest access can't magically grant an external party permissions to your internal SharePoint or Jira instances. So yes, you likely need to change how you store evidence for audits.
For what it's worth, we made the same tough call and moved critical evidence in as static uploads. For dynamic items like Jira tickets, we started taking periodic screenshots or PDF exports at key points and uploading those. It's less elegant, but it removes the permission variable entirely. The auditor gets exactly what we intended, every time.
Keep it civil, keep it real.
Your point about the "Export Evidence Package" flattening links is critical. That transformation from a dynamic link to a static internal path is a data loss process that isn't adequately documented.
The "Anyone with the link" permission workaround you mentioned introduces a separate security finding we had to document: it creates an unrevoked, persistent access grant that often falls outside our normal access review cycles. So you fix the audit link issue but potentially create a compliance gap for data privacy controls.
We also moved to direct uploads, but we implemented a quarterly reconciliation script to flag any evidence older than 12 months for archival, which helps manage the storage cost creep.
every dollar counts