Vendor Security Review Kit
Turn reassuring claims into specific questions and evidence requests.
For: Small teams evaluating document-sharing and data room providers
- Define the service, data types and use case before deciding which security questions matter.
- Ask for evidence that covers the actual service and relevant assessment period.
- Separate a vendor claim, supplied documentation and observed test behaviour in the review record.
- Record unresolved requirements and decision conditions rather than treating missing evidence as a pass.
01 / Practical guide
Define what you are evaluating
Scope the review around the service and information you intend to use.
A vendor security review should start with your intended use, not a generic list of every possible security question. Record the document types, sensitivity, audience, access needs and receiving workflow. A public marketing brochure and a restricted transaction room do not create the same requirements.
- Define the reviewed service
- List essential requirements
- Check evidence scope
- Record unperformed tests
- Assign unresolved conditions
Define what you are evaluating
Bring the essential details together before work begins.
Read the practical details
Identify the service and plan being reviewed. Capabilities, contractual terms and assurance scope can differ across products or deployments. Do not assume a statement about one product covers another service from the same company.
Choose a review owner and the roles that need to approve the decision. A small team may handle several responsibilities together, but legal terms, privacy requirements and technical access controls can require different expertise. Record unresolved areas rather than implying one person has validated everything.
Prioritise questions that could change your decision. If you must restrict external audiences, recipient identity and permission behaviour matter. If you need to leave the service later, export and retention matter. A long questionnaire is not automatically a better review.
02 / Practical guide
Ask questions that require specific answers
Ask specific questions that produce assessable answers.
Ask how the control works, what configuration is required, what limits apply and what evidence supports the answer. “Are you secure?” invites a broad claim. “How does access removal affect named recipients, public links and downloaded copies?” identifies a concrete boundary to discuss.
Ask questions that require specific answers
Follow the work in a clear sequence.
Read the practical details
Cover identity, permissions, data handling, hosting scope, activity records, incident communication, export and deletion. Add contractual or sector-specific requirements only where they apply to your use. Do not request sensitive internal evidence unnecessarily; vendors may offer a restricted review route.
For certifications or assessments, confirm the service covered, assessment period, issuing party and relevant exclusions. A badge on a homepage is not enough to conclude that your proposed workflow has been assessed. Different assurance documents answer different questions.
Ask about responsibility on both sides. A provider may supply controls while your team chooses the audience, configures access and reviews activity. Your assessment should record these customer tasks so a documented feature does not become an unimplemented assumption.
Copy and customise this template
Ready-to-use templateService and plan: [exact scope] Intended use: [document types and audiences] Required control: [specific requirement] Vendor statement: [answer] Evidence reviewed: [document title, scope and period] Harmless test result: [observed result or not tested] Remaining gap: [unresolved issue] Decision owner: [role] Decision and conditions: [accept / mitigate / reject / pending]
03 / Practical guide
Separate claims, evidence and observed behaviour
Keep claims, evidence and sample-test observations distinct.
Use separate worksheet fields for the vendor’s answer, evidence reviewed, test result and remaining gap. This avoids treating a sales statement as an independently verified conclusion. A document can describe a control accurately while your chosen configuration still needs testing.
Separate claims, evidence and observed behaviour
Use a realistic example to show what changes.
Read the practical details
The fictional example marks identity as Needs confirmation, access as documented but not tested, assurance as not provided, and exit handling as partly explained. Those outcomes are useful: they tell the team what evidence or decision is still missing.
Run permitted tests with harmless material. Check the recipient route, intended permissions, access removal and export format where those functions matter. Do not probe systems outside your authorised scope or describe a functional test as a penetration test.
When evidence cannot be shared, record the offered alternative and decide whether it meets your review needs. A refusal is not automatically proof of insecurity, but an unanswered requirement remains a gap. The decision owner should accept, mitigate or reject that gap explicitly.
| Review area | Question | Evidence requested | Finding | Follow-up |
|---|---|---|---|---|
| Identity | How are external recipients verified? | Current configuration documentation | Needs confirmation | Test intended recipient route |
| Access | Can former reviewers retain access? | Permission and removal process | Documented; not tested | Run approved sample test |
| Assurance | What assessment covers this service? | Report scope and review period | Not provided | Ask authorised contact |
| Exit | How are files exported and retained? | Export and deletion process | Partly explained | Clarify backup handling |
Choose the next action
| Situation | Action | Outcome |
|---|---|---|
| Recipient verification unclear | Request configuration detail and test a sample route | The intended identity check is evaluated |
| Assessment not provided | Record it as an evidence gap | Missing assurance does not become a pass |
| Backup deletion partly explained | Ask for the relevant retention process | The exit decision acknowledges unresolved handling |
04 / Practical guide
Make and maintain a scoped decision
Record a scoped decision with owners for unresolved conditions.
Summarise the use case, controls required, evidence reviewed, open issues and conditions for approval. Avoid a single universal “security score” that hides a critical unresolved requirement. A decision can be conditional on a setting, contract clarification or restricted pilot.
Make and maintain a scoped decision
Verify the exact conditions that matter before closing the work.
Read the practical details
Record who approved the decision and when it should be revisited. Material product changes, new document types or a changed audience can invalidate assumptions from the initial review. Renewal is another practical point to check current terms and evidence.
Keep the assessment in an appropriate restricted location. It can contain confidential vendor evidence and details about your organisation’s needs. Share a shorter decision summary with users who only need the operating instructions.
This kit organises questions and evidence. It does not certify a provider, establish regulatory compliance or replace an organisation’s security and legal review. Its value is making the decision and remaining uncertainty understandable.
Your completion check
Operational completion verification items
These are the only interactive checkboxes. Selections stay in this page session.
Use the worksheet
Interactive Worksheet Record
Fill one record per task. Work stays in this page session; export before closing.
Do not enter passwords, raw account details or confidential document contents.
05 / Practical guide
Questions before you select a provider
Start with the requirement that would block your intended use.
Does a certification mean every feature is safe for my use?
No. Check scope, exclusions and your own configuration. Assurance evidence is one input to a decision.
Should I compare vendors by the number of security features?
Feature counts can obscure whether a required control works for your workflow. Compare the requirements that matter and the evidence supporting them.
What if the vendor gives only marketing answers?
Ask a specific follow-up and identify the evidence needed. If the requirement remains unresolved, keep it visible in the decision summary.
Can I use this for regulated documents?
Use it as an organising aid, then involve the authorised specialists for applicable contractual and regulatory requirements. The worksheet does not determine those requirements.
What should I do first?
Write your use case in five lines, choose the three requirements that could block adoption, and request evidence for those requirements before reviewing less relevant features.
Questions before you select a provider
Show who owns each part of the work.
Related guides & articles
Enterprise Due Diligence Software: Requirements and Evaluation Framework
Evaluating compliance certifications, encryption architectures, and SLA guarantees.
Datasite Pricing and Cost: What Buyers Should Verify
Auditing vendor contract structures, page-count overages, and administrative fees.
Virtual Data Room Pricing and Cost: M&A Data Room Models Explained
Comparing transparent flat-rate models against per-user or storage-based pricing.