A practical decision guide
Software security review checklist
Turn a security claim into a question you can actually resolve. Check the proposed plan, collect the right evidence and keep open issues with a named owner.
1. Start with the data and the workflow
List what the service would receive, who would use it and which systems it would connect to. A shared meeting calendar and a customer database need different reviews. Describe the proposed use before asking a vendor to complete a questionnaire.
Record the exact product, paid plan, deployment, region and optional integrations. Keep the owner of the business process and the person accepting the security decision on the same review. A statement about a vendor is not automatically a statement about every service it sells.
| Decision detail | What to record | Why it helps |
|---|---|---|
| Data | Types of records, sensitivity and retention needs. | Defines what needs protection. |
| People | Members, administrators, guests and support access. | Makes permission tests specific. |
| Connections | Imports, exports, integrations and service accounts. | Shows where data and credentials travel. |
| Scope | Product, plan, deployment and region. | Keeps evidence tied to the proposed purchase. |
2. Separate a statement from its supporting document
Start with the public security page and follow each relevant source. Keep the document title, link, scope, period covered and date of your review. When a report is restricted, record how to request it and leave the question unresolved until someone reviews the relevant material.
For a SOC 2 report, ISO/IEC 27001 certificate or other assurance document, read what it actually covers. Ask whether the named service, operating entity and region match your proposed use, what exceptions are identified and which controls remain your responsibility. A logo or a yes/no answer does not settle those questions.
A missing entry in our research means we have not established the answer. It does not show that a vendor lacks a control. Use the gap to form a follow-up question rather than treating it as a failed security test.
Explore documented security evidence by product3. Test the access your team will actually use
Create a non-sensitive pilot with the roles you expect to use. Try inviting a guest, changing a role and removing a user. Check the outcome as that user, including an existing session or shared link where relevant. Record the steps and the plan used.
Ask which authentication, provisioning and logging controls are included in the quote. Check administrator and service-account access separately. If a trial does not expose a required control, keep the test unresolved and ask for a supported way to evaluate it.
Plan repeatable software pilot tests4. Follow the data through recovery and exit
Ask where the proposed service stores and processes your data, including backups and support access. Request the relevant subprocessor list and how changes are communicated. Record scope and exceptions instead of shortening a complex answer to a country name.
Agree which accidental deletion or outage your team needs to recover from. Ask who performs the recovery, which data can be restored and what evidence supports the stated objectives. Then test the export you would need to leave: records, attachments, relationships and readable formats.
For contract terms, notification duties and retention requirements, record the questions for the people responsible in your organisation. This checklist organises the review; it does not determine the requirements for your situation.
5. Leave a decision trail, not just a completed form
Mark each question Unresolved, Evidence received, Reviewed, or Not applicable with a reason. Receiving a document is a separate step from deciding that it supports your requirement. Name an owner and a next review date for every unresolved item.
Write an outcome: proceed with stated conditions, request more evidence, or stop for a recorded reason. Keep the accepted exceptions, required configuration and follow-up work beside it. Revisit the decision when the use, service scope or relevant evidence changes.
Get the questionnaire in CSV or MarkdownYour decision checklist
Checkmarks stay on this page only. Use your browser’s print command to keep a copy.
Common questions
Does a security statement mean a product is safe for our use?
It establishes only what its evidence supports. Review scope, required configuration and your own use before accepting a control. The public product page is a starting point for that review.
What if a report is available only under an agreement?
Ask how to obtain it through your normal review process. Record the request and leave the relevant question unresolved until a responsible reviewer has examined the evidence.
Should every supplier receive the same questionnaire?
Start with the proposed data and workflow. Keep the relevant questions, add requirements from your organisation and record why any question does not apply. A completed form is not itself a security approval.