How we handle your data.
A short, plain account of what Oriel does with the information you give it — and what it doesn't.
Oriel is a research tool. You give us a prospect's name and a few identifiers; we return a brief. The inputs you submit are processed to produce that brief and then discarded on a fixed schedule. We do not maintain a profile on the prospect, we do not sell or share what you submitted, and we do not train models on your inputs or on the brief we returned to you.
The research itself draws on public sources — SEC filings, IRS Form 990 disclosures, real estate records, donor walls, annual reports, news. We do not buy data from consumer data brokers, and we do not combine your inputs with purchased identity files. Every factual claim in a brief is linked to a verifiable source so you can check our work.
Inputs and briefs are encrypted in transit (TLS 1.2+) and at rest on the hosting provider. Briefs are retained for 30 days by default and then deleted; you can request earlier deletion at any time. Access to production systems is limited to the two-person founding team, requires multi-factor authentication, and is reviewed quarterly. We use reputable infrastructure (commercial cloud hosting, established AI model providers operating under no-training terms for API traffic) and we publish a current subprocessor list on request. If we ever experience a security incident affecting your data, we will notify you within 72 hours of confirming it.
We are a two-person bootstrapped company and we do not hold a SOC 2 report. What we offer instead is a small attack surface, a privacy-first architecture that minimizes what there is to lose, and the willingness to answer specific questions on a call.
Security & privacy, in detail
An extended account of how Oriel is built, what we collect, what we don't, and the controls we operate.
This document is written for the person inside a development office or foundation who has been asked to vet a vendor before the team is allowed to use it. We will not pretend to be something we are not. Oriel is a small, bootstrapped company without a SOC 2 report. The compensating logic is that the surface area of what we hold is deliberately small, and the controls we do operate are the ones that actually matter for a tool of this shape.
What we collect
When a major gift officer submits a brief request, Oriel receives a prospect's name, an employer or affiliation, a city, and any optional context the MGO chooses to include. We also receive the requester's email address so we can deliver the brief. That is the complete list of personal data Oriel accepts. We do not ask for donor IDs, do not import CRM extracts, and do not accept uploaded documents.
What we don't collect
Oriel does not purchase data from consumer data brokers. We do not maintain a wealth-screening database or a persistent profile of any individual prospect. Inputs from one customer are never combined with another customer's inputs to enrich a record. We do not run cookies or third-party trackers on the brief delivery surface beyond what is required to authenticate the link.
Where the research comes from
Every brief is built from public, verifiable sources: SEC filings, IRS Form 990 disclosures, county real estate records, published donor walls, nonprofit annual reports, board listings, and reputable news. Each factual claim in a brief carries a source citation. If a claim cannot be cited, it does not appear in the brief.
Retention and deletion
The default retention window for a completed brief is 30 days, after which the brief and its underlying input record are deleted from production storage. A customer may request immediate deletion of any brief or input at any time by emailing the address on the brief itself; we honor deletion requests within five business days and confirm in writing. Backups follow the same retention logic and roll off on a 35-day cycle.
Encryption and transport
All traffic between the customer and Oriel is encrypted in transit using TLS 1.2 or higher. Data at rest in the hosting environment is encrypted using the provider's managed encryption (AES-256). Secrets — API keys, database credentials, third-party tokens — are stored in a managed secrets store, never in source code or in plain configuration files, and are rotated when a team member's access changes.
Access and authentication
Production systems are accessible to the two members of the founding team and to no one else. Both accounts require multi-factor authentication on every administrative surface, including the cloud console, the source repository, the secrets store, and the AI model provider dashboard. Access is reviewed quarterly. When a team member's role changes or a contractor engagement ends, credentials are revoked the same day.
AI model providers and training
Oriel uses commercial AI model providers via their API products. API traffic to these providers is, by the terms of those products, not used to train their models. We do not fine-tune models on customer inputs or on the briefs we have produced. The list of model providers and other subprocessors is maintained internally and provided on request to any prospective customer; we will notify existing customers in advance of material changes.
Incident response
If Oriel confirms a security incident affecting customer data, we will notify the requester email on file within 72 hours of confirmation, describe what we know, and provide updates as the picture clarifies. Our internal response runbook covers identification, containment, eradication, recovery, and post-incident review. The runbook is short because the system is small; it is reviewed annually.
Privacy regulation posture
Oriel's research draws exclusively on public sources, which materially limits the scope of personal data we process. We honor data subject access and deletion requests under GDPR and CCPA from any individual who contacts us, including individuals who appear as prospects in a brief. Because we do not retain prospect data beyond the brief retention window, most deletion requests resolve immediately by virtue of the 30-day rollover.
Code, change management, and dependencies
Source code lives in a private repository. Production deployments happen from a protected branch and are reviewed by the second team member before merge. Third-party dependencies are pinned, scanned for known vulnerabilities on each build, and updated on a regular cadence. Infrastructure is defined in code where practical, so configuration changes leave an auditable trail.
What we do not have
We do not hold a SOC 2 Type II report. We do not hold ISO 27001 certification. We are not HIPAA-covered and do not accept protected health information. We do not currently offer single sign-on integration or customer-managed encryption keys. If any of those are hard requirements for your organization, we would rather you know now than discover it in week six.
Questions
The most useful thing a prospective customer can do is send us a list of specific questions, or ask for a 30-minute call with one of the founders. We will answer in writing, on the record, and we will tell you when we don't know.