Compliance

FileYield is an early-stage marketplace. We are not yet certified under SOC 2, ISO 27001, HIPAA, or any other formal compliance framework. We have not yet undergone an independent audit. We do not yet have a formal Data Processing Agreement (DPA) program with our processors, although our processors themselves operate under their own SOC 2 / ISO 27001 certifications.

What we DO have in place today:

• —Encryption in transit (TLS) for all platform communications
• —Encryption at rest provided by our hosting and database providers (Supabase, Vercel)
• —Role-based access controls in our application database
• —Authentication via Supabase Auth, including hashed passwords and session tokens
• —Audit logging on key administrative actions
• —Industry-standard application security practices (input validation, parameterized queries, security headers)
• —A documented Privacy Policy, Terms of Service, and Acceptable Use Policy
• —A defined data retention schedule (see Privacy Policy)
• —A process for responding to user data requests (access, deletion, portability)

What we are working toward (not yet in place):

• —SOC 2 Type II certification
• —Formal Data Processing Agreements with all processors
• —Standard Contractual Clauses for international data transfers
• —Independent penetration testing program
• —Formal incident response procedures and breach notification SLAs
• —Bug bounty program
• —Compliance program for HIPAA workflows (when handling listings that include PHI)

FileYield does not host, transfer, or take possession of the actual datasets sold between buyers and sellers. This is the most important fact about our compliance posture because it shapes everything else.

When a seller lists data on FileYield, the underlying dataset stays in the seller’s systems. When a buyer agrees to purchase, the data is transferred directly from seller to buyer through whatever secure delivery method they choose. FileYield is not in the data path.

This means compliance obligations attach primarily to the seller and buyer:

• —Sellers warrant they have lawful basis to sell the data and have disclosed any compliance frameworks that apply
• —Buyers commit to using the data only as licensed and complying with all applicable laws
• —Where data is subject to HIPAA, GDPR, CCPA, or other frameworks, the seller and buyer enter the necessary agreements (BAAs, SCCs, DPAs) directly between themselves
• —FileYield’s role is limited to discovery, matching, and the audit trail

This architecture significantly reduces FileYield’s direct exposure to regulated data, but it does not eliminate our responsibility to operate the platform ethically and lawfully. We enforce the Acceptable Use Policy to keep prohibited data off the marketplace.

FileYield processes the following data directly (see the Privacy Policy for full detail):

• —User account data (email, name, phone, password hash)
• —Listing and request metadata (titles, descriptions, formats, samples)
• —Buyer-seller messages
• —Voice recordings of outreach calls
• —SMS message logs
• —Analytics events (PostHog)
• —Vector embeddings of listing and request text
• —Server logs and IP addresses

We treat this data as personal information where it identifies an individual, and we apply the privacy safeguards described in the Privacy Policy.

4.1 GDPR (EU / EEA / UK / Switzerland)

We respect the rights of users under the GDPR, including the rights of access, rectification, erasure, restriction, portability, and objection (Articles 15-22). We are not currently certified under any GDPR seal or scheme, and we do not yet have Standard Contractual Clauses formally executed with all processors. EU users should consider this when deciding whether to use the Service.

4.2 CCPA / CPRA (California)

We respect the rights of California residents under the CCPA / CPRA, including the rights to know, delete, correct, and opt out. FileYield does not sell personal information for monetary consideration as defined by CCPA. The marketplace facilitates transactions for third-party datasets between sellers and buyers; this is conceptually different from FileYield itself selling user data.

4.3 HIPAA

FileYield is not currently a HIPAA-covered entity or business associate. Listings that involve protected health information require the seller and buyer to enter the necessary HIPAA agreements between themselves, and to ensure that any data transfer complies with the HIPAA Security Rule and Privacy Rule. FileYield does not host PHI and does not process PHI on behalf of a covered entity.

4.4 TCPA / CAN-SPAM

FileYield’s outreach system sends SMS and email and may place AI-driven phone calls. We design these features to comply with the U.S. Telephone Consumer Protection Act and CAN-SPAM Act, including honoring opt-out requests, providing clear sender identification, and disclosing call recording where required by state law. Implementation maturity is ongoing.

4.5 State-Level Privacy Laws

We aim to honor state-level privacy laws (Virginia VCDPA, Colorado CPA, Connecticut CTDPA, Utah UCPA, Texas TDPSA, and others) where they apply to our processing. Implementation is ongoing as each state law takes effect.

FileYield’s security posture is designed around well-known industry practices:

• —All web traffic served over HTTPS (TLS 1.3)
• —Application-level password hashing via Supabase Auth
• —Session-based authentication with secure, http-only cookies
• —Row-level security policies on the application database
• —Rate limiting on public APIs
• —Security headers (CSP, X-Frame-Options, X-Content-Type-Options) on the web application
• —Dependency monitoring for known vulnerabilities
• —Production credentials stored in secure environment variables, not in source code

We do not currently operate a 24/7 security operations center or provide formal security SLAs. Users should report suspected security issues to support@fileyield.com.

If FileYield becomes aware of a security incident affecting user data, we will:

• —Investigate the scope and root cause
• —Take steps to contain and remediate
• —Notify affected users without undue delay where the incident creates a risk to their rights and freedoms
• —Notify relevant regulators where required by law (e.g., GDPR Article 33 within 72 hours)
• —Document the incident and corrective actions

We do not currently maintain a formal incident response program with documented playbooks and tabletop exercises. This is on the roadmap.

We rely on the following subprocessors to operate the Service (this list is current as of the effective date and may change):

• —Supabase — database, authentication, file storage
• —Vercel — hosting, edge functions, analytics, logging
• —PostHog — product analytics, session recording, feature flags
• —Anthropic (via Vercel AI Gateway) — AI model inference for assistants
• —Twilio (or equivalent) — SMS and voice calling
• —Resend (or equivalent) — transactional email
• —Stripe (planned) — payment processing
• —Firecrawl — public web research (does not process user data)

Each of these providers operates under their own security and privacy programs. We rely on their certifications (SOC 2 / ISO 27001 where available) as part of our due diligence.

We will update this page as our compliance maturity grows. Items on the near-term roadmap include:

• —Formal SOC 2 Type II audit
• —Standard Contractual Clauses with all processors handling EU data
• —Documented Data Processing Agreement template for enterprise sellers and buyers
• —Independent penetration test
• —Formal incident response runbook
• —Documented HIPAA process for sellers handling PHI

Compliance questions, audit requests, security disclosures: support@fileyield.com