Customer-applied evidence

Before recording customer evidence

Use this page after a customer, developer or agency applies a remediation outside WebRiskOps connected access. Customer-applied evidence tells WebRiskOps what changed, where it changed and whether the task is ready for a retest. Do not use customer-applied evidence to claim that WebRiskOps changed the site automatically. It is a safe record of externally applied work, not proof that the issue is fixed until a retest confirms the outcome.

Record customer-applied evidence

Follow the path `Ticket-only fallback → Customer-applied evidence → Retest request → Retest outcome → Monitoring decision`.

1. Open /fix-tasks/{fixTask} after the customer or developer says the change is applied. Result: source finding, expected fix, handoff notes and customer-applied status are visible.
2. Confirm the work happened outside WebRiskOps connected access. Result: evidence is recorded as customer-applied instead of automated or connected remediation.
3. Enter the changed URL, component, configuration, pull request, release note or external ticket reference. Result: the retest has the exact place and context to check.
4. Add a short evidence note that explains what changed and when. Result: a reviewer can understand the fix without reading private systems.
5. Remove secrets, credentials, payment data, private account content and unrelated customer data before saving. Result: evidence stays safe for reports, tickets and retests.
6. Save the evidence and request a retest when plan and task state allow it. Result: customer_applied_status and retest_status show whether verification is pending, queued or blocked.

Evidence-ready states

Continue only when evidence explains the work clearly enough to retest.

• Evidence submitted means the task has a changed URL, component, configuration or external ticket reference.
• Retest ready means the task has enough before evidence and plan state to verify the change.
• Retest requested means WebRiskOps has queued or is waiting to queue verification for the changed surface.
• Customer-applied status remains separate from connected access approval, patch generation and automatic remediation.

Blocked or unsafe states

Do not request a retest when evidence is incomplete or unsafe.

• No changed reference means ask for the URL, component, release, pull request or external ticket before saving evidence.
• Secret in evidence means use [Privacy redaction](/docs/projects/privacy-redaction) before saving or sharing the evidence.
• Unclear change means return to [Ticket-only fallback](/docs/remediation/ticket-only-fallback) and ask for a safer handoff note.
• Missing before evidence means WebRiskOps may need a scoped scan before comparing the applied change.
• Retest unavailable means keep the task pending until plan, credit or workflow state allows verification.

Continue to retests

Continue to [Retests and monitoring conversion](/docs/remediation/retests-and-monitoring-conversion) after the evidence is saved and safe. Use [Retest outcomes](/docs/monitoring-retests/retest-outcomes) to understand passed, failed, pending and inconclusive verification states, and review [Automation boundaries](/docs/remediation/automation-boundaries) before representing external work as automated remediation.