FirstReq is prepared around a B2B data-processing boundary: public source evidence, customer workspace configuration, audit records, and governed exports.
The target production DPA covers customer account data, workspace configuration, source evidence metadata, audit logs, and export packets.
Public pilot requests do not create a customer account or subscription.
Customer workspace processing starts only after explicit approval and onboarding.
Contact Context remains confidence-labelled and subject to suppression controls.
Customer controls
Production customers need clear controls for access, retention, deletion, export, and suppression.
Admin controls must expose users, roles, billing, audit, suppression, and retention posture.
Deletion workflows and retention windows remain commercial launch gates.
DNC and suppression checks must run before contact reveal, contact export, and commercial outbound. They do not block magic links, billing or account notices, or allowed product notifications.
Data categories
FirstReq should classify source evidence, workspace configuration, contact context, audit logs, billing records, and analytics separately.
Analytics must avoid raw PII and include tenant context.
Evidence and snapshots must follow retention policy.
Billing records follow finance/legal retention requirements.
Launch boundary
The DPA page is an operational readiness surface until a final legal document is signed with a customer.
No legal certification is implied by public access to this page.
Paid pilot requires legal/trust acceptance before customer processing expands.
Production launch requires processors, retention, deletion, and support paths to be verified.
Trust boundary
These pages describe the current security, privacy, and production-readiness posture. They do not create a compliance certification or data-processing commitment; paid access is governed by the Terms and Stripe activation, while any DPA requires a signed agreement.