Vendor Security Snapshot
Before you trust a supplier with your data: what their public footprint says about security and privacy.
- Price
- Free in beta
- Typical time
- about 1 minute
- Input
- Website URL
Signing up a new SaaS tool or supplier means handing over customer data. The agent checks what anyone can see from outside: HTTPS and certificate, security headers, cookies and trackers, email spoofing protection, security.txt, and reads the privacy, security and terms pages for where data is stored, subprocessors and certifications. You get a snapshot with red flags and the exact questions to ask before signing.
Example result
Sample dataVerdict
Some gaps
Reasonable basics, but no DMARC and a privacy policy that doesn't say where your data is stored.
Why
- No DMARC policy — Mail providers aren't told to reject fake @vendor.example email, a common route for invoice fraud.
- No Content-Security-Policy — Nothing limits which scripts can run, so an injected script runs freely.
- No security.txt
- HTTPS
- yes
- DMARC
- no
- Trackers
- 3
- Policies found
- 2
Evidence 4
Every finding behind the verdict, with the fix where there is one.
Mail providers aren't told to reject fake @vendor.example email, a common route for invoice fraud.
Fix: Ask the vendor to publish DMARC (p=quarantine or p=reject).
Questions to ask before signing
- 1.In which countries is our data stored and processed?
- 2.Will you sign a DPA, and can we see the list of subprocessors?
- 3.Do you hold ISO 27001 or SOC 2, or can you fill in our security questionnaire?
- 4.How and how fast do you notify customers of a data breach?
What their policies say about your data
- Storage location: not stated.
- Retention: 'as long as necessary', no period given.
- Subprocessors: AWS and Stripe are named; no full list.
- Breach notification: not stated.