Security and trust
Last updated · September 16, 2026
This page describes how UpgradIQ, Inc. protects the data you entrust to UpgradIQ. It is written to be accurate rather than reassuring: where we have a control we say what it is, and where we do not yet have one we say that too, in the section near the end. It should be read alongside our Privacy Policy and Cookies Policy.
1. Where your data is hosted and processed
UpgradIQ runs on managed infrastructure in the United States. We do not operate our own servers or data centres. The providers below each process a defined slice of data on our behalf under their own security and compliance programmes, and each is named in our Privacy Policy:
- Vercel: application hosting and edge functions. The site and its APIs are served from here.
- Supabase: the application database (PostgreSQL, US region) holding accounts, memberships, orders, and course progress.
- Stripe: card payment processing. Stripe holds and processes all card data and is subject to PCI-DSS. We never see or store full card numbers.
- Amazon Web Services (SES): delivery of transactional email such as access links and receipts.
- Cloudflare: DNS and network security.
- Upstash: rate limiting and short-lived caching.
- Sentry: error and performance monitoring, with personal data stripped before an event is stored (see section 4).
- PostHog: product analytics, loaded only after you consent, with your IP address anonymised.
2. Encryption
In transit: every connection to upgradiq.com and to the providers above is served over HTTPS with TLS. Traffic between your browser and the site, and between the site and its database, email, and payment providers, is encrypted.
At rest: the application database is managed by Supabase, which encrypts stored data at rest on the underlying platform. Card data is never stored on our systems: it lives with Stripe under PCI-DSS. Uploaded bank-transfer receipts are kept in private storage that only an administrator can read.
3. Access control and the admin model
Every table in the database has row-level security enabled, so a signed in member can reach only their own rows. Server code that needs to act across accounts uses a separate service-role connection that runs only on the server and is never exposed to the browser.
The admin surface is governed by a role-based access control model. Each staff account carries one role, and each admin area is mapped to the exact set of roles allowed to reach it, checked on every request so that removing a role takes effect immediately rather than at the next sign in. Money and member-data actions are held to a stricter role than the page they sit on, so read access does not imply the power to refund, delete, or export. The site owner retains a separate break-glass credential for recovery.
4. Monitoring and personal data minimisation
We monitor errors and performance with Sentry. Before any event leaves the browser or the server it passes through a scrubber that removes personal fields, including email address, name, phone, postal address, user identifier, and payment identifiers. Analytics through PostHog are anonymised at the IP level and are loaded only after you consent. Both are described in full in our Cookies Policy.
5. Incident response and reporting a vulnerability
If you believe you have found a security vulnerability, or you suspect your account has been accessed without your permission, email adam@upgradiq.com with the details and, where you can, the steps to reproduce it. Please give us a reasonable opportunity to investigate and fix an issue before disclosing it publicly. We read every report and will acknowledge it.
When we confirm an incident that affects personal data, we investigate its scope, contain it, and notify affected users and any relevant authority where the law requires, in line with our Privacy Policy.
6. Your data: export and deletion
A signed in member can export everything we hold about them as a single file, and can ask us to delete their account, both from the account settings in the dashboard. On deletion, personal details such as your name, company, and country are anonymised. Records we are required to keep for accounting and tax purposes, such as the fact and amount of a transaction, are retained on the schedule set out in our Privacy Policy. You can also make either request by writing to adam@upgradiq.com.
7. Backups
The application database is a managed Supabase project, which takes automated platform backups of the underlying PostgreSQL data. Uploaded files and course media are held in managed object storage. We do not publish a specific recovery-time objective, and you should not treat UpgradIQ as the only copy of anything you also hold elsewhere.
8. Payments
Card payments are the main rail and are handled entirely by Stripe. Because some members, particularly in Egypt, cannot reliably complete an international card payment, we also support paying in USDT and by Egyptian-pound bank transfer, and some earlier purchases are still being paid in instalments. Whichever rail you use, we store only what is needed to confirm the payment and grant access: we do not hold card numbers, and bank-transfer receipts are kept in private storage.
9. What we do not have yet
We would rather tell you this plainly than let a trust page imply more than is true:
- We are not SOC 2 certified, and we are not certified under ISO 27001. We rely on the compliance programmes of the providers named in section 1 rather than holding those certifications ourselves.
- We are not HIPAA covered and UpgradIQ is not intended for protected health information.
- We do not run a paid bug-bounty programme. Vulnerability reports are handled by email, as described in section 5.
- We do not publish a formal penetration-test schedule or a signed uptime guarantee.
As our controls change, we will update this page and the “Last updated” date above.
10. Contact
Security questions and vulnerability reports: adam@upgradiq.com. UpgradIQ, Inc., 131 Continental Dr, Suite 305, Newark, DE 19713, United States.