Finding the answer should not require a security engineer.

If you use Supabase (most common for small teams): go to supabase.com and log in → click into your project → in the left-hand menu click Table Editor or Authentication → open the Policies tab. Each table shows a green "RLS enabled" tag, or a warning that it's off. A table with no policies listed counts as "no."

If you use a different database host (AWS RDS, Google Cloud SQL, PlanetScale, etc.): this is a developer-level setting inside the database console, usually under something called "row security" or "permissions." It's faster to just ask whoever set up the database.

Not sure who manages your database? Check your hosting bill for a company name - Supabase, AWS, and Google Cloud are the most common - or ask whoever built the product.

If you use Supabase: supabase.com → your project → Settings (gear icon) → API. You'll see two keys - anon (safe to expose publicly) and service_role (full access, must stay secret). Ask your developer where the service_role key is used. It should only run on a server you control, never inside code a visitor's browser can see.

If you use Firebase: Project Settings → Service Accounts.

Quick question to ask instead of digging in yourself: "Where does our admin key get used?" - if the answer is "in the website code," that's a "no."

If you use Supabase: supabase.com → your project → Settings → Database → scroll to Backups. It shows whether backups are on, how often, and whether Point-in-Time Recovery is available (usually a paid-plan feature).

If you use AWS RDS: your database's page in the AWS console → Maintenance & backups tab.

For your own team's logins to tools like GitHub, Supabase, or your hosting provider, check each one separately - most have this under an admin or organization security setting:

GitHub: your organization → Settings → Authentication security → look for "Require two-factor authentication for members."

Google Workspace: admin.google.com → Security → 2-Step Verification → check the enforcement setting.

For your product's own users (if you use Supabase Auth): Authentication → Providers / Settings - check whether MFA is required or just offered.

Check the "created on" date next to each key: Supabase (Settings → API), Stripe (Developers → API keys), AWS (IAM → Users → Security credentials). A key that's a year or more old and has never been replaced is worth flagging.

If your code is on GitHub: your repository → Settings tab → Branches (left menu) → look under Branch protection rules for your main branch. Nothing listed there means it's not protected.

If you use GitLab: Settings → Repository → Protected branches.

In your GitHub repository, use the search bar (magnifying glass icon) and search the repo for words like API_KEY or password. If real key values show up in the code itself, that's a "no." Keys should live in your hosting provider's Environment Variables page instead - in Vercel or Netlify: your project → Settings → Environment Variables.

If you use Stripe: Developers → Webhooks → click into each endpoint and confirm a "signing secret" is set up. Ask your developer to confirm the code actually checks it - having a secret listed isn't the same as using it.

The fastest way to build this: open your company card or billing statement and write down every recurring software charge - that covers most of it. Add anything else that touches customer data even if it's free, like an email or analytics tool.

Most vendors publish their Data Processing Agreement on their own site - search "[vendor name] DPA" or look under Legal, Trust, or Privacy on their homepage. Supabase, Stripe, and Google Workspace all publish one without needing to contact anyone.

Search "[vendor name] trust center" or "[vendor name] SOC 2." Most larger vendors - Supabase, Stripe, AWS, Google, GitHub - publish a security or trust page, and some let you request their own SOC 2 report directly from it.