Security & Compliance

• Encryption in transit. All traffic to R2R is served over TLS 1.2+ (HTTPS). Internal service-to-service calls between our edge runtime and managed database are encrypted end-to-end.
• Encryption at rest. Application data, uploaded pitch decks, and database backups are encrypted at rest using AES-256 by our managed cloud provider.
• Row-level security (RLS). Every multi-tenant table enforces row-level security in the database itself, so a firm or user can only ever read or write their own rows — even if application code has a bug.
• PII minimization. Founder contact details are only ever shown to firms a founder has been matched with. Internal admin tools mask names, emails, and phone numbers by default, with click-to-reveal access that is written to an immutable audit log.
• AI training anonymization. Any dataset used to train, fine-tune, evaluate, or prompt our scoring models is run through a one-way anonymization pipeline: emails are hashed, founder names become role labels, phones and handles are removed, and company names are pseudonymized to stable opaque tokens. Raw PII and business-identifying names never reach our models.

• Authentication. Email + password with bcrypt-hashed credentials, plus optional Google sign-in. Investor accounts are invite-only; invite tokens are single-use and validated server-side.
• Role-based access. Platform administrators are granted via a dedicated roles table — there is no hard-coded admin allow-list. Firm members have admin/partner/analyst roles with progressively narrower permissions.
• Audit logging. Every privileged admin action (PII reveal, firm config change, invite send, training export, incident broadcast) is logged with actor, timestamp, and target. Logs are immutable and reviewable.
• PII anomaly detection. A background job continuously scans the audit log for unusual reveal patterns and alerts other administrators if any single actor exceeds a safe threshold.
• Idle session timeout. Active sessions expire after a period of inactivity and require re-authentication.

R2R runs on managed cloud infrastructure with a small, audited set of sub-processors. The full list — including legal entity, location, and purpose — is published in Annex III of our Data Processing Addendum.

• Application + database hosting on a managed Postgres provider with point-in-time recovery.
• Edge network and DDoS protection via Cloudflare.
• Inbound email ingestion via Postmark, with cryptographic webhook signature verification on every delivery.
• Transactional email delivery via Resend, from a dedicated authenticated subdomain (notify.r2rmedia.ai) with SPF, DKIM, and DMARC.
• Anti-malware scanning of every inbound attachment via OPSWAT MetaDefender; infected files are quarantined and never shown to investors.
• AI scoring via Google Gemini and OpenAI models, accessed through anonymized prompts only.

• Uptime monitoring. External monitors ping the application and database on a 1- and 5-minute cadence, with alerts routed to on-call administrators.
• Email deliverability monitoring. Every outbound message is tracked end-to-end. Bounce, complaint, and failure rates are reviewed daily, with spike alerts on any unusual pattern.
• Point-in-time backups. The primary database supports continuous point-in-time recovery covering the prior 7 days. Inbound pitch decks are also retained at the email provider for 45 days as a secondary source.
• Disaster recovery. We maintain a written DR runbook with documented restore procedures and run periodic recovery drills against a clone of production.
• Stuck-job retry. Long-running deck processing jobs are automatically retried; founders and platform admins are notified if a deck ever exhausts retries.

• Internal escalation. Operational alerts (delivery failures, sync failures, anomaly detections, AV errors) email all platform administrators in real time.
• User notification. Material incidents affecting service availability or data integrity are communicated to affected users by email through our incident broadcast system, with audience targeting by user type.
• Privacy incidents. Where required, we will notify affected customers and individuals in accordance with the timelines set out in our DPA and applicable law.

• GDPR data subject rights. Every account can self-serve a full data export and request account deletion from /settings/privacy. Deletions run on a 7-day grace window and propagate through all derived data.
• Cookie consent. Non-essential cookies are gated behind a consent banner; users can revisit their choices at any time from their privacy settings.
• Sub-processor transparency. Our DPA names every sub-processor that may process customer data, with advance notice for any addition or replacement.
• Data residency. Primary data is processed in the United States. See the DPA for full details on international transfers.

If you believe you have discovered a security vulnerability in R2R, please report it to support@r2rmedia.ai before disclosing it publicly. We will acknowledge your report promptly, investigate, and keep you updated on remediation. Please give us a reasonable window to fix the issue before publishing details, and avoid accessing or modifying data that does not belong to you.

Security questionnaires, DPA requests, and any other security-related inquiries can be sent to support@r2rmedia.ai.