Exactly. This is the Evidence Collection stage. In real GRC work, you are trying to prove two things:
- The control exists — it has been formally defined.
- The control operates — people actually perform it.
Collect Objective Evidence — Real-Life GRC Process
| Order | Tab | What you do in real life | LondonBuild example |
|---|---|---|---|
| 1 | Select Control | Identify the control you need evidence for. | AC-002: Quarterly user-access review |
| 2 | Define Evidence Needed | Decide what evidence would prove the control exists and operates. | Access-review procedure + completed access-review reports |
| 3 | Send Evidence Request | Send a formal request to the control owner. | Request evidence from IT Manager |
| 4 | Receive Evidence | Control owner provides the documents/data. | Access review report for Q2 2026 |
| 5 | Check Evidence Exists | Confirm the control is formally documented. | Access Control Policy exists and is approved |
| 6 | Check Evidence Is Current | Confirm the evidence relates to the assessment period. | Q2 2026 report, not an old 2023 report |
| 7 | Check Evidence Is Complete | Confirm all required information is present. | All systems/users included in the review |
| 8 | Check Evidence Is Relevant | Confirm it actually proves the specific control. | Report demonstrates access was reviewed |
| 9 | Check Evidence Is Authentic | Confirm it comes from a reliable company source. | Export from Microsoft Entra ID / approved GRC system |
| 10 | Check Evidence Shows Operation | Determine whether the control was actually performed. | Review was completed and approved quarterly |
| 11 | Store / Link Evidence | Store the evidence in the GRC system or link to its approved repository. | Evidence ID: EVD-002 |
| 12 | Record Evidence Result | Record whether the evidence is sufficient. | Sufficient / Insufficient / Missing |
| 13 | Prepare for Testing | Use the evidence to perform your control test. | Sample users and verify access approvals |
Example: What you actually request
Control:
AC-002 — User access is reviewed quarterly by the IT Manager.
You might send:
Evidence Request: Please provide the Q2 2026 user-access review report, evidence of IT Manager approval, and the list of users reviewed.
The IT Manager gives you:
Q2_Access_Review.xlsx- Manager approval record
- User access report
You then examine the evidence.
| Evidence Test | Question | Result |
|---|---|---|
| Existence | Does the access-review process exist? | ✅ Yes |
| Current | Is it from the assessment period? | ✅ Yes |
| Complete | Were all relevant users reviewed? | ✅ Yes |
| Relevant | Does it demonstrate the control? | ✅ Yes |
| Approved | Was the review approved? | ✅ Yes |
| Operating | Was the review actually performed? | ✅ Yes |
| Sufficient | Can this evidence support our conclusion? | ✅ Yes |
The key distinction
Control exists:
LondonBuild has a documented quarterly access-review procedure.
Control operates:
LondonBuild actually performed the quarterly review and can provide evidence showing it happened.
So don’t accept:
❌ “We do quarterly access reviews.”
That’s management’s statement, not objective evidence.
You want:
✅ Documented procedure + actual completed review + supporting records
Your GRC workflow is now
Framework
↓
Requirement
↓
Control Objective
↓
Control Mapping
↓
Crosswalk
↓
Risk Event
↓
Risk Register
↓
Collect Objective Evidence
↓
Test Control
↓
Pass / Partial / Fail
↓
Gap
↓
Risk
↓
Remediation
↓
Reporting
This is the point where your GRC work becomes evidence-based rather than just documentation-based.