How we protect the people, businesses, and data on our platform. Built and operated with a security-first mindset by a team led by a security professional.
A note on this page. My Treat is a pre-launch platform, and this page reflects that. We mark each control with In place for what we operate today and Planned for what we are implementing before public launch. We would rather be honest about our maturity stage than overstate our posture — a security program is only as credible as its weakest claim.
My Treat is operated by a Managing Member with a professional background in security. That isn't a marketing line — it's a design constraint. Every architectural decision, from how staff log in to how sponsor data is segregated, is evaluated through a security lens before it ships, and our posture is intended to be publicly defensible, not performative.
We default to defense in depth: no single control should be load-bearing on its own. Where a vendor offers a stronger default, we adopt it. Where the cheapest secure option exists, we choose it before scale forces our hand.
| Control | Status |
|---|---|
| Encryption at rest — AES-256 on all primary data stores via Google Cloud defaults (Firestore, Cloud Storage) | In place |
| Encryption in transit — TLS on all customer-facing endpoints via Firebase Hosting managed certificates | In place |
Responsible disclosure policy — security.txt per RFC 9116, security policy publicly documented | In place |
| Privacy & data subject rights — Published Privacy Policy, Terms, and Community Guidelines; export/deletion via direct contact | In place |
| Secrets handling — No credentials in source control; production secrets stored outside the codebase | In place |
| Single-operator authentication hygiene — All Managing Member accounts use a dedicated password manager with cryptographic passkey support; no shared credentials | In place |
| Vendor minimization — Deliberately small set of third-party services; no tracking pixels on auth or billing surfaces | In place |
The following controls are part of our pre-launch build-out. Each will move to "In place" as it is deployed and verified.
| Control | Status |
|---|---|
| Operations console behind Google Cloud Identity-Aware Proxy — staff-only allowlist enforced at the network edge before requests reach application code | Planned |
| Cloud Armor web application firewall — OWASP rule coverage and rate limits on public endpoints | Planned |
| Phishing-resistant passkeys (WebAuthn) enforced — no password-only sessions for any My Treat-operated system | Planned |
| Hardware security keys anchoring identity-provider and credential-vault accounts | Planned |
| Multi-factor authentication required for sponsor accounts on all billing-touching flows | Planned |
| Immutable audit log on privileged operations console actions; mirrored to long-term retention storage | Planned |
| DNSSEC + CAA + DMARC reject — cryptographically signed DNS, certificate-issuance pinning, and enforced email authentication, all independently verifiable | Planned |
| Strict Content Security Policy with server-generated nonces on the operations console and sponsor portal | Planned |
| Least-privilege service accounts — separated read and write identities for analytics versus operational data | Planned |
My Treat is built on Google Cloud Platform. Production services include Firebase Hosting (web), Firestore (primary data store), Firebase Authentication (identity), Cloud Functions (event handlers), and Cloud Storage. As we deploy the operations console and analytics warehouse, we are adding Cloud Run, BigQuery, Cloud IAP, Cloud Armor, Secret Manager, and Cloud Logging — each described in the tables above.
Google Cloud's underlying platform inherits the certifications and operational practices documented at cloud.google.com/security/compliance.
We welcome reports from independent security researchers. Our security.txt file follows RFC 9116 and lists the canonical contact, expiration date, and policy link. Full reporting procedures, scope, and safe-harbor language are documented in our security policy file (SECURITY.md) in our source repositories.
Report a vulnerability: security@mytreat.club
We acknowledge within 2 business days, triage within 5, and target remediation of critical issues within 30 days, high within 60, and medium/low within 90.
Our security program is structured against published, recognized frameworks. We name them explicitly so our posture is something a knowledgeable reviewer can evaluate against a real standard, not against marketing language.
We are not currently audited against SOC 2 Type II, ISO 27001, or similar attestation frameworks. We are deliberate about this: a formal audit is meaningful at scale, and we would rather invest in real controls now than in an attestation our customers cannot yet verify. The control areas measured by SOC 2 Type II — security, availability, confidentiality, processing integrity, and privacy — are part of our roadmap, and we expect to pursue a formal audit once platform scale justifies the cost. Until then, we are happy to walk sponsors, investors, or partners through our current control posture on request, mapped against any framework relevant to their procurement requirements.
Where possible, the claims on this page can be verified by anyone, without needing to take our word for it:
security.txt file: /.well-known/security.txtIf any of these report a score lower than this page implies, that is a bug — please tell us at security@mytreat.club.
We publicly thank researchers who responsibly disclose vulnerabilities. With your permission, we will list your name or handle here after your report has been validated and remediated.
No external researcher acknowledgments yet — we expect this list to grow.
/.well-known/security.txt