How to check a supplier’s security before signing a contract
For non-technical buyers who need a practical supplier security check before approving a contract. This guide gives you a short evidence-based review process, exact questions to ask, and clear pass/fail checks so you can decide without a support ticket.
TL;DR — Before you sign with a software supplier, collect five pieces of evidence: their security certificate or questionnaire, penetration test (a controlled security test) summary, incident process, subprocessor list (their own vendors), and proof of MFA (multi-factor authentication) plus encryption. The fastest path is to send one standard evidence request, review the documents against the checklist below, and stop the deal if they refuse to share basics or give only vague answers. Reading time: ~5 min
Goal
By the end of this check, you will have a simple yes/no supplier security decision backed by saved evidence: the supplier’s security documents, your answers to a short checklist, and a clear list of any risks that must be accepted before signing.
Prerequisites
- Your supplier’s sales or security contact email address
- Access to your company’s contract, procurement, or vendor review folder
- A place to save files, such as SharePoint, Google Drive, or your document system
- A PDF reader or web browser
- A spreadsheet or notes app for recording answers
- The supplier’s legal name and website domain
- The services you plan to buy from them, written in one sentence
- If your company has one: your standard security questionnaire, DPA (data processing agreement), or vendor review template
Steps
Step 1: Send one standard evidence request
Send this exact email from your work email to the supplier’s sales contact and ask them to forward it to their security or compliance team:
Subject: Security review request before contract signature
Hello,
Before we sign, please send the latest version of the following:
1. Security certificate or report: ISO 27001 certificate, SOC 2 Type II report, or equivalent
2. Most recent penetration test executive summary and confirmation that critical findings are closed
3. Completed security questionnaire, if you have one
4. Data processing agreement (DPA)
5. Subprocessor list
6. Incident notification process, including notification time after a confirmed breach
7. Confirmation of:
- MFA for admin access
- Encryption in transit (TLS 1.2+)
- Encryption at rest
- Backups and restore testing
- Access reviews for staff
- Logging and monitoring
8. Hosting regions and where our data will be stored
9. Retention and deletion process when the contract ends
10. Security contact for follow-up questions
Please reply with documents or links and the date each item was last updated.
Thank you.
What you should see when this succeeds: you receive either the documents themselves or a reply with links, dates, and a named security contact.
Step 2: Save the evidence in one folder
Create one folder named with the supplier and date, for example:
Acme-Software_security-review_2026-10-30
Save every file and email thread there. If you use a document system, use your provider’s folder path, for example:
Shared Documents → Vendor Reviews → Acme-Software_security-review_2026-10-30
What you should see when this succeeds: one folder contains the questionnaire, reports, contract documents, and the email thread.
Step 3: Check for independent security evidence
Open the supplier’s certificate or report and record the exact answer for each item below in your notes or spreadsheet:
Certificate/report present: Yes / No
Type: ISO 27001 / SOC 2 Type II / Other / None
Legal entity on report matches supplier name: Yes / No
Report date within last 12 months: Yes / No
Scope includes the service we are buying: Yes / No
Any major exceptions or qualified opinion: Yes / No
If they sent a SOC 2 report, look for these exact sections in the table of contents or summary:
Independent Service Auditor’s Report
Management’s Assertion
System Description
Tests of Controls
What you should see when this succeeds: you can point to one current, independent document that covers the actual service you plan to buy.
Step 4: Check their real operational controls
Review their answers and fill in this table exactly:
| Control | Accept if | Mark |
|---|---|---|
| MFA for admin accounts | Supplier explicitly says "Yes" | Pass / Fail |
| Encryption in transit | Supplier explicitly says "TLS 1.2" or "TLS 1.3" | Pass / Fail |
| Encryption at rest | Supplier explicitly says disks, databases, or object storage are encrypted | Pass / Fail |
| Backups | Supplier confirms backups exist | Pass / Fail |
| Restore testing | Supplier confirms restores are tested, not just backups taken | Pass / Fail |
| Access reviews | Supplier confirms periodic access review for staff | Pass / Fail |
| Logging/monitoring | Supplier confirms centralized logs or active monitoring | Pass / Fail |
| Incident notification | Supplier gives a time commitment in contract or policy | Pass / Fail |
| Data deletion | Supplier explains deletion timing after termination | Pass / Fail |
| Data location | Supplier names storage region/country | Pass / Fail |
What you should see when this succeeds: each control is marked Pass or Fail, with no blanks.
Step 5: Check their supplier chain and data handling
Open the subprocessor list and DPA. Record these exact answers:
Subprocessor list provided: Yes / No
Public URL or attached list: Yes / No
Countries where subprocessors process data: <list countries>
DPA provided: Yes / No
Customer data deletion period after termination: <number of days>
Breach notification period: <hours or days>
Use this decision rule:
If subprocessor list = No, mark overall result = Fail
If DPA provided = No and supplier will process personal data, mark overall result = Fail
If breach notification period is not stated, mark overall result = Needs clarification
What you should see when this succeeds: you know who else may handle your data and under what legal terms.
Step 6: Review public security signals
In your browser, check the supplier’s website login and trust pages. Use these exact checks:
Open https://supplier-domain.example
Open https://supplier-domain.example/security
Open https://supplier-domain.example/privacy
Open https://supplier-domain.example/subprocessors
If a page does not exist, note "Not published". On the login page, look for SSO (single sign-on), MFA, or password policy wording. On the security/privacy pages, look for contact details, certifications, and incident reporting language.
What you should see when this succeeds: your notes match the documents they sent, with no obvious contradiction.
Step 7: Make the sign / don’t sign decision
Use this exact rule in your notes:
Sign = current independent report + DPA + subprocessor list + all of these pass: MFA, encryption in transit, encryption at rest, backups, restore testing, incident notification
Do not sign = missing independent report and missing questionnaire, or refusal to answer, or no DPA where personal data is involved, or no MFA for admin access
Escalate = one or two fails that your legal/security approver can explicitly accept in writing
Save a one-paragraph decision note in the review folder:
Decision: Sign / Do not sign / Escalate
Reason: <one sentence>
Open risks accepted by: <name>
Date: YYYY-MM-DD
What you should see when this succeeds: the folder contains a documented decision that another colleague could understand without redoing the review.
Verify it works
Use this end-to-end checklist. The review is complete only if all items below are true:
[ ] Evidence request email sent and answered
[ ] All received files saved in one folder
[ ] Independent report checked for date, scope, and legal entity
[ ] Control table completed with Pass/Fail for every row
[ ] DPA reviewed
[ ] Subprocessor list reviewed
[ ] Data location, deletion, and breach notification recorded
[ ] Final decision note saved with date and approver
Expected result: every box is checked, and you can answer "Why is this supplier acceptable or not acceptable?" in one paragraph using saved evidence.
Common pitfalls
The supplier sends a certificate logo, not the actual evidence
Mistake: accepting a website badge or sales slide as proof of certification.
Symptom: you cannot see the legal entity, scope, issue date, or expiry date.
Fix: ask for the actual certificate PDF or the report under NDA (non-disclosure agreement), not a screenshot.
The report is for the wrong company or wrong service
Mistake: reviewing a parent company report that does not cover the product you are buying.
Symptom: the report names a different legal entity or lists a scope that excludes the service.
Fix: compare the legal entity and scope text in the report to the contract entity and purchased service name.
The penetration test is old or unresolved
Mistake: treating any pentest summary as a pass.
Symptom: the test is older than 12 months or the supplier will not confirm critical findings are closed.
Fix: ask for the latest executive summary and a written statement: "All critical findings from the latest test are remediated."
No DPA is provided even though personal data is involved
Mistake: proceeding with legal review only.
Symptom: the supplier says they can send the DPA after signature, or only on request later.
Fix: stop the signature process and request the DPA before approval.
You get vague answers like "industry-standard security"
Mistake: accepting marketing language instead of evidence.
Symptom: answers do not include dates, named controls, or documents.
Fix: reply with the original numbered list and ask them to answer each item with "Yes/No + document/link + last updated date".
Public pages contradict the documents
Mistake: not checking the supplier’s website after receiving PDFs.
Symptom: the website says one hosting region or subprocessor set, but the DPA or questionnaire says another.
Fix: send the contradiction back to the supplier and ask which document is current before signing.
This article was written by an AI system and published pending human review. Verify anything you intend to act on.
Have a project in mind?
Get an instant AI price estimate for it, or talk directly to our team.
One email a month on what we learn building with AI