Where your payroll data lives, and who can see it.

Two stages, both customer-initiated.

Pre-payment (the order form at /order). Five inputs: company legal name, work email, engineering FTE count, tax year, and a click-wrap acceptance of our four agreements. Roughly two minutes. Nothing financial, nothing sensitive, no upload widgets. We need this much to size the engagement and confirm you have a CPA-of-record.

Post-payment (the intake form at /intake/<customer-id>). Six categories of input:

• Entity details: entity type, state of incorporation, fiscal year end. We need these to compute the correct Section 41 base period and to flag state R&D credit add-on opportunities.
• Two contacts: your primary technical contact (CTO, VP Engineering, or equivalent) and your CPA-of-record (full name, firm, email). The technical contact gets methodology questions during binder authoring; the CPA gets the final binder and workpapers.
• Payroll register: a single export from your payroll provider (Gusto, Rippling, ADP, Paychex, Justworks, etc.) for the tax year. PDF, CSV, or XLSX. We use this to compute Qualified Research Expense (QRE) wages by employee.
• Contractor invoices: PDFs from US-based engineering contractors for the tax year. We compute the 65 percent allowable contract research expense per Section 41(b)(3).
• Cloud-spend export (optional): an annual cost export from AWS Cost Explorer, GCP Billing, or Azure Cost Management. Skip this unless your cloud is a meaningful R&D expense (research-stage workloads, GPU clusters, ephemeral test environments). Production-hosting cloud spend is generally not QRE.
• GitHub App install: a read-only OAuth install of the R&D Binder GitHub App into your engineering organization. We read repository metadata, pull request titles, commit timestamps, and (only if you opt in) design-doc files. We never read source code by default and never have write or admin permissions.

Cloudflare R2 object storage, US region. Every uploaded file lands in our rdbinder-customer-files R2 bucket under a per-customer prefix (customer-files/<customer-id>/). Encrypted at rest by default (AES-256 server-side encryption) and in transit (TLS 1.3 to Cloudflare).

Order and intake metadata. Stored as JSON in our rdbinder-orders R2 bucket. Two keys per customer: an immutable day-bucketed audit row (orders/<yyyy-mm-dd>/<customer-id>.json) and a mutable pointer for current-state lookups (customers/<customer-id>.json). Same encryption posture as customer files.

Email transit. Order, payment, and intake confirmation emails go out via Resend on a verified sub-domain (mail.rdbinder.com). We never include payroll registers, contractor invoices, or any other sensitive file content in email bodies. Emails contain customer IDs and links to documents stored in R2; the documents themselves never leave our R2 storage via email.

No persistent customer-data copies outside R2. Pipeline runs read from R2, render the binder PDF, and write the PDF back to R2. Nothing intermediate persists on a worker filesystem, in a database, or in a third-party SaaS.

No payroll data in source control. Our public sample binders (Cal.com 2024 today) are built from public open-source data. Real customer data never enters a Git repository.

• Aliso LLC personnel with audit-engagement scope. Today this is the founder. Access is via Cloudflare R2 console with two-factor authentication and per-action audit logging.
• Your CPA-of-record, only at delivery time. We send the final binder PDF, QRE workpaper, and Section G appendix directly to the email you provided on intake. Your CPA does not get access to the underlying R2 files unless you explicitly request it as a separate engagement.
• Cloudflare as our infrastructure sub-processor for R2, Workers, and Pages.
• Resend as our transactional email sub-processor. Email content only; no file content ever transits Resend.
• Stripe as our payment sub-processor. Payment metadata only; no payroll or engineering data transits Stripe.

The full sub-processor list is in the Data Processing Agreement.

• We never train AI models on your data. Not LLMs, not embeddings, not anything. Your data is used to produce your binder and nothing else.
• We never sell or share your data with third parties. Not for analytics, not for marketing, not for any commercial purpose.
• We never transit payroll data through email. Emails contain customer IDs and document links. The documents stay in R2.
• We never write to your GitHub organization. The GitHub App permissions are strictly read-only. We cannot push commits, open PRs, modify settings, or invite users.
• We never read your source code by default. The GitHub App reads repository metadata, pull request titles, and commit timestamps. Reading design-doc files is opt-in per repository on intake.
• We never store your data outside the US. R2 buckets are pinned to the US region. Migadu (our human-inbox provider for the support and partner mailboxes reachable through our contact form) is Switzerland-hosted, but we never route customer financial data through Migadu; the human inbox is for human-readable correspondence only.

Seven years. The IRS may examine an R&D credit claim for up to seven years from the original return-due date in the worst case (six-year statute under Section 6501(e) for substantial understatements, plus the year of the credit itself). We retain customer data for seven years after the tax year covered by the binder so we can support audit defense if the IRS examines the claim.

After seven years, we purge the customer's R2 prefix and the order ledger row. The purge is soft (90-day delete delay) so we can recover from accidental purges, then hard.

Before seven years, you can request earlier deletion of any data not needed for IRS substantiation through the contact form. We honor the request within 30 days unless retention is required by IRS examination or another legal hold.

72-hour breach notification. Per our Data Processing Agreement, we notify affected customers within 72 hours of confirming any unauthorized access, loss, or disclosure of personal or financial data. The notification includes the nature of the incident, the data categories involved, our containment steps, and any action we recommend you take.

How to reach us. Security questions, suspected incidents, or vulnerability disclosures: use the contact form with subject "SECURITY." We commit to acknowledging within one business day and substantively responding within five business days.

We aim to be straight about what we do and do not have today.

• SOC 2: not currently certified. Planned for 2027 once customer count justifies the audit cost. If your procurement requires SOC 2, contact us; we can provide sub-processor lists and security questionnaire responses as an interim.
• GDPR: not applicable. We serve US customers only and do not process personal data of EU residents.
• HIPAA: not applicable. We do not collect, store, or process Protected Health Information (PHI). Health-tech SaaS customers should not upload patient data; we only need payroll, contractor, and cloud-spend data.
• IRS Circular 230 and Section 6695: our scope is documentation only. We do not prepare, sign, or take a position on Form 6765 or any other IRS form. Your CPA-of-record is the preparer of record and carries Circular 230 and Section 6695 obligations.
• State privacy laws (CCPA / CPRA / VCDPA / etc.): we honor data subject access and deletion requests through the same process described under retention above.

Three ways to confirm what is on this page.

1. Read the Data Processing Agreement and Master Services Agreement. Both are click-wrap accepted at order time and are the binding versions of these commitments. If something on this page differs from those documents, the legal documents govern.
2. Ask a security or procurement question. Use the contact form with subject "Security / procurement" and we will respond in writing within two business days.

This page is a public commitment. We update it as our infrastructure changes; the date at the bottom shows when it was last reviewed.

Last reviewed: May 8, 2026.