RequestVault Privacy for Claims Intake

1. Claim intake data we handle

RequestVault may process sender account details, claimant contact information, claim identifiers, workflow metadata, checklist items, uploaded files, text responses, signatures, reminder history, access events, review-stage updates, and support or billing records connected to the request.

For claims workflows this can include claim numbers, policy references, incident dates, evidence photos, estimates, statements, completion scores, and communications metadata such as email or SMS delivery state.

2. Why RequestVault uses this data

RequestVault uses intake data to deliver the request, guide the claimant through the checklist, store submitted evidence, show adjusters what is missing, support reminders and follow-up, package the claim for review, and operate security and abuse controls.

We also use workflow and event data to investigate delivery failures, support upload screening, enforce message suppression, troubleshoot issues, and maintain product integrity.

3. Who can see claim data

Claim data is available to the sender account and authorized teammates because that is the core function of the product. In claims workflows, the creator, assigned owner, and claim admins can review the claim, and broader team ownership/admin roles can manage assignment and compliance actions.

RequestVault also uses infrastructure and service providers for storage, email, authentication, and related operations when needed to run the service.

4. File lifecycle

Uploaded claim files move through a defined lifecycle: upload, storage, automated screening, claim review, optional export packaging, retention scheduling, and eventual purge or continued retention based on the request policy.

Suspicious uploads may be quarantined before adjusters can open them normally, and quarantined files may be excluded from standard download or export flows until reviewed.

5. Retention and deletion

RequestVault supports different retention modes for request data. Depending on the workflow, uploaded documents and submission payloads may be kept until manual action or scheduled for automatic purge after completion or other milestones.

Audit-level history may remain after file payloads are removed so teams still have a record that the request existed and what lifecycle events occurred.

6. Communications metadata

When RequestVault sends reminders or claim notifications, it may record delivery attempts, reminder timing, message purpose, provider response data, and suppression state. This helps claims teams see whether the claimant was reached and whether outbound messaging is still allowed.

RequestVault may block future SMS sends when the provider reports an opt-out or similar suppression event until a claims admin documents fresh consent and clears that block.

7. Security and abuse records

We may retain operational records about suspicious uploads, screening outcomes, access activity, message suppression, and related platform-protection signals so RequestVault can prevent misuse and explain what happened during a review.

These operational records can outlast the underlying claim file payload when needed for abuse prevention, dispute review, or platform integrity.

8. Sender responsibilities

RequestVault is an intake and delivery layer. Senders remain responsible for collecting only information they are authorized to receive, maintaining any required notices or legal basis, and handling downloaded claim materials according to their own obligations.