Can I run this checklist on a vendor without their permission?

Yes. RedScore checks public signals anyone on the internet can see. No credentials or vendor cooperation required.

Is an outside-in scan enough for vendor due diligence?

It is a strong first pass. It catches public gaps fast. Full vendor reviews still need questionnaires, SOC 2 reports, and deeper testing for high-risk suppliers.

What score should I expect from a good vendor?

There is no single cutoff. Look for critical failures in TLS, headers, and email auth. A vendor with multiple public gaps may not take security seriously.

Can I share scan results with my team?

Yes. RedScore reports are shareable. Use them as a starting point for vendor conversations.

Vendor security review checklist

Why run a vendor security review?

Before you share customer data with a supplier, check what their public posture looks like. A vendor with weak TLS, missing security headers, or no email authentication is a risk you can spot in 60 seconds.

Full vendor assessments take weeks. This checklist gives you a fast signal before you invest time in questionnaires and contract reviews.

What is on the vendor security review checklist?

Scan the vendor's production domain from the outside.
Check TLS and certificate health on their live hostname.
Review security headers on their deployed responses.
Verify DNS hygiene for dangling or misconfigured records.
Check email authentication so their domain cannot be easily spoofed.
Look for public exposure signals that should not be internet-facing.
Compare the score to your own domain to see if they take security seriously.

RedScore runs all of this in one passive outside-in pass. No vendor credentials needed.

How do I run the checklist?

Go to /lookup and enter the vendor's production domain. Read the category grades and fix-first summary. Flag anything critical before you proceed with the contract.

For specific signal detail, see the SSL checker, DNS checker, and DMARC checker pages.

What should I flag in a vendor review?

Focus on failures that suggest the vendor does not manage their public posture:

Critical TLS issues. Expired certificates, weak configs, or HTTP-only endpoints handling sensitive data.
Missing security headers. No HSTS, no CSP, no X-Frame-Options on a SaaS product.
Weak email auth. Missing DMARC or SPF set to +all on a vendor that sends mail on your behalf.
Public exposure. Admin panels, debug endpoints, or services that should not be internet-facing.
Stale DNS. Records pointing to decommissioned services, a common subdomain takeover vector.

One or two minor warnings may be fine. Multiple critical failures across categories is a red flag.

What is this checklist not?

It is not a SOC 2 review. It is not a penetration test of the vendor's application. It is not a review of their internal policies or employee access controls.

It is the public check you can run today, without waiting for their security team to return a questionnaire. Use it to decide whether a vendor is worth a deeper review.

If the public posture is bad, ask them about it before you sign. If it is clean, you still need questionnaires and compliance docs for high-risk vendors. But you will know where to start the conversation.