SECURITY & DATA PRACTICES

Security & Data Practices

Last updated: September 24, 2026 · Version 2026-09-24

What this page represents

This page describes security and data-handling controls currently implemented or configured for Revenue Recovery AI. It is intended to distinguish verifiable application controls from independent certifications.

Revenue Recovery AI does not claim that the Revenue Recovery AI service itself is independently SOC 2, ISO 27001, or similarly certified unless such a certification is expressly identified here in the future. Certifications held by infrastructure or service providers do not automatically certify Revenue Recovery AI.

For a shorter summary written for the person uploading the documents rather than for review of the controls, see what happens to your financial documents.

Service operator

Revenue Recovery AI is operated by Business Revenue Recovery. Security reports and data-practice questions can be sent to hello@businessrevenuerecovery.com .

Hosting

The production web service is configured on Render in the Virginia region of the United States.

The active SQLite application database is stored on a Render persistent disk. Render states that persistent disks and their automatic snapshots are encrypted at rest.

Transport and browser security

The production application is served through HTTPS. The application also sends security headers including HSTS in production, Content Security Policy, frame restrictions, content-type protections, and a restrictive referrer policy.

Authenticated application pages are marked to prevent browser and intermediary caching of sensitive page content.

Session handling

An authenticated session is a signed browser cookie. It is marked to prevent browser and intermediary caching of the pages it authenticates, and every state-changing request carries a CSRF token that is verified before the request is acted on. A request without a valid token is refused and changes nothing.

Sessions expire after 15 minutes without activity. The timeout is enforced on the server from the session’s own timestamp rather than by a timer in the browser, so closing a laptop does not keep a session alive and a page left open does not extend one.

A stated limit rather than a glossed one: the 15-minute timeout measures inactivity, not absolute age. A session that is used continuously stays valid for as long as it is used.

Bounds on abuse

Fixed-window rate limits apply per resolved network address, per authenticated account, and per address and account for uploads on a tighter window, plus one deployment-wide bucket. That last one exists because a flood spread thinly across thousands of addresses passes every per-address limit. The counters are held in the database rather than in process memory, so they are shared across replicas and a restart does not reset anyone’s window.

Login attempts are throttled on the combination of address and account. The account-only counter still bounds distributed guessing, but it is evaluated after credential verification rather than before it. Evaluating it first meant anyone who knew a customer’s email address could lock that customer out of their own account from a clean address, which is a denial of service wearing a brute-force control’s clothes.

A forwarded-address header is read only when the immediate peer is a configured trusted proxy, and the chain is then walked from the right past further configured proxies. The trusted list is empty by default, which attributes all traffic to the load balancer until an operator configures it, which is over-restrictive rather than trivially evadable.

Residual risks, stated rather than omitted. A distributed source staying inside the per-address limits is bounded only by the deployment-wide counter, and lowering that also bounds legitimate peak traffic. Fixed windows allow up to twice the nominal rate across a window boundary. Password guessing within the pair limit across many addresses is slowed rather than stopped.

Upload constraints

Uploads are bounded by an extension allowlist (PDF, CSV, XLSX and plain text), a 10 MB per-file ceiling, a limit of 10 files per upload, a filename length limit, and a 1,000-row ceiling on an accounting import. These are enforced before the file is processed rather than discovered during processing.

An allowlist rather than a blocklist is the deliberate choice: a blocklist has to anticipate every dangerous extension and fails open on the one nobody thought of, while an allowlist fails closed on anything unfamiliar.

Dependency and secret checks

The repository is scanned for known credential patterns, and dependencies are checked against published advisories, as conditions on changes being merged rather than as a periodic review somebody has to remember to run.

What this does not establish: a scan finds known patterns and published advisories. It does not find a credential that matches no known shape, or a vulnerability nobody has published yet, and no scan should be read as a statement that neither exists.

What these controls do not cover

A security page that lists only controls invites the reading that everything else is covered too. These are the boundaries of what is claimed above.

• No completed independent audit. There is no SOC 2, ISO 27001 or equivalent certification. Every control described on this page is one we implement and can point at in the application; none has been verified by an outside assessor.
• Encryption at rest is a provider statement. There is no application-level encryption of the database file. Render states that persistent disks and snapshots are encrypted at rest, and that is the basis for the claim. It is their control, not ours, and it is described that way throughout this page.
• The audit trail has a boundary. Provider-console and infrastructure access can occur outside the application’s role system. We do not claim that every lower-level console or shell action appears in a single application audit trail.
• Data sent for AI processing leaves this boundary. Everything on this page describes the application. Data sent to the AI provider is governed by that provider’s retention, which is described separately below and is not something the application can configure from inside a request.
• No formal penetration test has been commissioned. Where that changes, this page will say so and say by whom.

Business-level data separation

Customer analyses, search results, history, recovery records, imports, and related application queries are scoped to a business identifier. Business roles do not grant cross-business access.

Revenue Recovery AI supports Owner, Operator, and Viewer roles. Owners have administrative permissions such as billing, access management, audit access, and destructive data controls. Operators can perform operational work but do not receive Owner-only administrative permissions. Viewers receive read-oriented access.

Account verification

New security-managed accounts use email verification. Login verification can also be enabled using supported verified email or SMS destinations.

Twilio Verify is used for supported verification delivery and verification checks. Revenue Recovery AI stores the verification state needed by the application, while raw one-time verification codes are handled through the verification provider.

Password and invitation tokens

Password-reset and business-invitation tokens are stored in the Revenue Recovery AI database as hashes rather than as the raw token value. Raw secure links are delivered to the intended recipient through the applicable communication channel.

Temporary upload processing

New source-document uploads are configured to use ephemeral temporary storage outside the application's Render persistent data directory.

The upload workflow attempts to delete the temporary source file in a finally-style cleanup path after processing, including when analysis raises an exception.

Saved Analysis Records contain derived information such as filename, document hash, financial values, AI reasoning, and findings. They do not store a retained source-file path.

AI data flow

OpenAI's API is used for AI-assisted reasoning. Most features build structured requests from extracted and derived information rather than sending the customer's original uploaded file. Smart upload sends the full text read from each uploaded PDF (not the file itself) so the model can propose values for the customer to review.

Depending on the feature, structured AI context can include a filename, invoice fields, contract fields, accounting records, financial amounts, findings, and recovery-case information.

OpenAI states that API Platform business data is not used for model training by default unless the API customer explicitly opts in. Standard API inputs and outputs may be retained by OpenAI for up to 30 days by default, and longer where the law requires it or where it is reasonably necessary to protect the service or others from harm, unless a different eligible retention configuration applies. Revenue Recovery AI does not currently claim Zero Data Retention.

Two different retentions, and only one of them is ours to change. Application-state storage is what the Responses API keeps so a request can be retrieved later; abuse-monitoring retention is a separate safety process. Revenue Recovery AI now sends every AI request with application-state storage disabled (store=false), so the provider is asked not to retain that state. If a request cannot be sent that way, the feature answers that it is temporarily unavailable rather than sending it with storage enabled.

This is not Zero Data Retention. Disabling application-state storage does not switch off standard abuse-monitoring retention, which is governed by the provider's own policy and by account or project configuration that this application cannot set from inside a request. Zero Data Retention and Modified Abuse Monitoring are separate approved configurations with endpoint limitations, and Revenue Recovery AI continues to make no claim that either is enabled for its account.

Source: OpenAI API data-controls documentation, developers.openai.com/api/docs/guides/your-data. Provider statements above were verified against that page on 2026-09-24 and recorded in our internal change log. Provider policies change; this page states a verification date rather than implying continuous monitoring.

Human control over recovery actions

Recovery actions begin in a draft state. The application records approval status, reviewer, review time, and reviewer notes. Execution is blocked unless the action has been approved.

Customer contact is designed to require both an approved recovery action and a human-triggered execution step.

Audit trail

Revenue Recovery AI records business-scoped application audit events for important security, access, billing, and recovery activity. Normal customer application routes do not provide mutation or deletion controls for individual audit events.

A complete Owner-authorized workspace deletion removes the business's active audit-event records together with the workspace.

Analysis deletion

An Owner can delete an individual analysis after entering an exact confirmation. The deletion engine removes the analysis and its dependent findings and recovery graph from active storage, redacts associated import metadata, and clears potentially stale cross-document reasoning within that business.

Workspace deletion

Workspace deletion is Owner-only, CSRF-protected, requires an exact confirmation phrase and the Owner's current password, and invalidates the active browser session after successful deletion.

The deletion transaction is explicitly business-scoped and is tested to preserve another tenant's records.

Subscription cancellation

Subscription cancellation changes billing entitlement; it does not silently delete customer data. Workspace deletion is a separate explicit action.

Application backups

The application creates integrity-checked SQLite database backups. The default backup interval is 24 hours.

Application-created backup files are configured for a 14-day age limit when the backup cycle runs, together with a separate 14-copy limit. Age pruning runs even when creation of a new backup is not yet due.

Render snapshots

Render creates an automatic snapshot of the persistent disk once every 24 hours. Render states that snapshots are encrypted at rest and available for at least seven days.

Render does not describe that seven-day period as a maximum retention guarantee. Revenue Recovery AI therefore does not claim that provider-managed snapshots are always erased within seven days.

Operational and administrative access

Customer business roles are tenant-scoped. A separate founder-only application route exists for private product feedback and does not grant customer business roles cross-business access.

Authorized infrastructure operators can have technical access to production systems when necessary for maintenance, support, security, backup recovery, or incident response. Such access is governed by an internal administrative-access policy and should follow least-privilege and minimum-necessary principles.

Revenue Recovery AI does not provide a customer impersonation or "login as customer" feature. The current founder-only cross-business application capability is the private product-feedback inbox. Successful access to that route creates a generic administrative audit record containing operational metadata rather than customer feedback content.

Provider-console and infrastructure access can occur outside the application's customer-role system. Revenue Recovery AI does not claim that every lower-level provider console or shell action is captured in a single application audit trail.

Current service providers and data categories

Render

Purpose: hosting and persistent infrastructure. Potential data: application database, application-created backups, logs, and infrastructure metadata.

OpenAI

Purpose: AI reasoning and generation. Potential data: the full text read from PDFs uploaded with smart upload, and structured information derived from authorized business records and recovery cases.

Stripe

Purpose: subscription and payment processing. Potential data: account email, billing identifiers, subscription identifiers, plan and payment status, and related transaction metadata.

Twilio Verify

Purpose: email/SMS account verification. Potential data: verification destination and verification-related metadata. Revenue Recovery AI does not use this notification path to send uploaded business documents.

Twilio SendGrid

Purpose: transactional email. Potential data: recipient email address, email subject and body, secure reset or invitation link, and for team invitations the applicable business name and access role. Uploaded invoices and contracts are not sent through this notification path.

Incident response

Revenue Recovery AI maintains an internal incident-response process covering identification, containment, evidence preservation, scope assessment, provider coordination, remediation, recovery validation, notification assessment, and post-incident review.

If an incident affects customer information, notification decisions are based on the facts of the incident and applicable legal or contractual requirements. Revenue Recovery AI does not publish a fixed breach-notification deadline that may not apply to every incident.

Incident reporting

Suspected unauthorized access, security vulnerabilities, or privacy incidents can be reported to hello@businessrevenuerecovery.com . Please include enough information to investigate the issue without sending unnecessary sensitive customer records by email.

Related policies

See the Privacy Policy and Terms of Use for additional information.