CREW EATS SECURITY OVERVIEW

1. OUR APPROACH, HONESTLY

Crew Eats Inc. ("Crew Eats," "we," "us," or "our") is an early-stage company. We do not have a security department, and we will not pretend to. Our security model is deliberate for our size: build on a small number of heavily-audited managed providers, keep sensitive data off our own systems wherever possible, keep the surface area small, and be straight with you about the rest.

This page describes what we actually run today. As the company grows, this policy will grow with it — and the date above will tell you when it last changed.

2. WHAT WE BUILD ON

The most sensitive workloads are handled by providers whose security programs are independently certified and audited at a scale we could never match ourselves:

• Payments — Stripe. All card processing is handled by Stripe, a PCI DSS Level 1 certified processor. Card numbers go from your device to Stripe; card numbers are never stored on, and never pass through, systems Crew Eats controls.
• Login — Auth0 (Okta). Sign-in and identity for the app are handled by Auth0 using standard OAuth 2.0 / OpenID Connect flows. We do not build our own password storage.
• Infrastructure — AWS. Our systems run on Amazon Web Services (US East), whose data centers and platform services carry SOC 2, ISO 27001 and related certifications, with physical security, redundancy and environmental controls documented by AWS.
• SMS and email — Twilio and AWS SES. One-time codes and transactional messages are delivered through these providers.

Provider certifications belong to those providers, not to us — we do not claim SOC 2 or ISO 27001 certification of Crew Eats itself.

3. WHAT WE RUN OURSELVES

• Encryption in transit: All traffic between your device, our website, and our services uses TLS (HTTPS).
• Access control: Administrative access to our cloud accounts follows least privilege; the root account is protected with multi-factor authentication; access is reviewed and removed when people leave.
• Monitoring: AWS GuardDuty threat detection and CloudTrail audit logging are enabled on our cloud account.
• Website: creweats.com is a static site served through a content delivery network — there is no server-side session or database behind the marketing site, which keeps its attack surface deliberately small.
• Backups: Our database is backed up automatically with point-in-time recovery. We are actively investing in stronger resilience (multi-availability-zone deployment and longer retention) ahead of launch, and we do not publish recovery-time guarantees we have not yet proven.
• Development: Changes are version-controlled, reviewed before deployment, and dependencies are kept current. Security-relevant changes get an additional review pass.

4. WHO IS RESPONSIBLE

Security at Crew Eats is owned directly by the founder and CEO, with engineering support — not by a dedicated security officer, because we do not have one yet. What that means in practice:

• One accountable person, reachable quickly, with authority to act immediately — no ticket queue between a report and a decision
• A bias toward managed services over home-built systems, precisely because our team is small
• External review where it counts: our stack and access model have been through independent technical review, and findings are tracked to closure

5. DATA WE HANDLE

What we hold, and what we deliberately do not:

• We never hold on our own systems: card numbers (they stay with Stripe) or login passwords (they stay with Auth0).
• We hold: account and profile details, order history, and the flight or shift information you give us to time an order.
• We treat as sensitive: crew verification details and anything related to airport access — held to the minimum needed, shared only as each airport's own process requires.

Full detail on collection, use, retention and your rights is in our Privacy Policy.

6. AIRPORT AND AVIATION SECURITY

Operating airside is a security discipline of its own, and it is the one closest to our founder's day job as an airline captain:

• Deliveries are made by dedicated Crew Eats runners engaged through our contracted airport ground-services partner
• Runners are badged through each airport's own SIDA process — background checks, TSA security training, and the airport authority's access rules — never around it
• We operate only where, and exactly how, the airport authorizes; airport and TSA direction supersedes our operations, always
• Flight and crew information is used for order timing, held to the minimum, and never resold

7. IF SOMETHING GOES WRONG

Our incident response is honest about our size: there is no 24/7 operations center, there is a founder with his phone on and full authority to act. If we have a security incident:

• We contain first — isolating affected systems and revoking compromised access takes priority over everything else
• We notify regulators within 72 hours where the law requires it, and affected users without undue delay
• We tell the truth about what happened, what was affected, and what we changed — in plain language, not a lawyer's shrug
• We document the incident and fix the class of problem, not just the instance

8. REPORTING A VULNERABILITY

If you find a security problem in our app, website, or infrastructure, we genuinely want to hear about it:

• We will acknowledge your report quickly and keep you informed as we fix it
• We will not pursue legal action against good-faith research that respects user data and does not disrupt the service
• We do not run a paid bounty program yet — but we will credit you, if you want to be credited

9. CONTACT

Questions about this policy or our security practices:

© 2025–2026 Crew Eats Inc. All rights reserved.

This Security Overview was last updated on 08/21/2026, when it was rewritten to describe our actual practices and providers, replacing an earlier version that overstated our internal security organization.