I've been evaluating Hyperproof for a potential SOC 2 audit prep project, and the distinction between a 'test' and 'evidence' was initially confusing. It's a core conceptual model in their platform, and getting it right is key to using the tool effectively. After working through their documentation and a trial, here’s my breakdown.
Think of a **Control** as the rule you need to follow (e.g., "All employee laptops must have disk encryption enabled"). In Hyperproof, you prove a control is operating effectively by performing **Tests**. A test is the *activity* or *procedure* you execute.
* **Test:** The act of sampling 10 employee laptops and checking their encryption status.
* **Test:** The act of reviewing the output of a MDM compliance report.
* **Test:** The act of interviewing the IT Security Manager about the process.
**Evidence** is the *artifact* you collect *from* performing that test. It's the objective proof you attach to the test record.
* **Evidence:** The spreadsheet listing the 10 sampled laptops with a "Encryption Status" column.
* **Evidence:** The PDF export of the MDM compliance report from your dashboard.
* **Evidence:** The signed meeting notes from the interview.
In practical Hyperproof terms, you create a test within a control. That test has fields for a description, schedule, and assignee. Once you perform it, you upload files (screenshots, documents, spreadsheets) or link to external sources (like a Jira ticket or Google Doc) as the evidence. The platform then allows you to mark the test as passed/failed based on your review of that evidence.
The key takeaway is that a test without attached evidence is essentially an unproven plan. The evidence is the objective, reviewable output that satisfies the test's requirement. This separation is quite logical from a data model perspective and ensures a clear audit trail: what we said we would do (the test) versus what we actually produced (the evidence).