Cluster F’s buyer checklist

Last updated: October 11, 2026

Quick answer: If I were choosing a SaaS vendor for a Cluster F team, I would use this 12-question security checklist before signature. The right vendor should answer in writing what they protect, how they isolate data, how access is controlled, what logs exist, how incidents are handled, where data lives, what subprocessors they use, how they support SSO and MFA, how they back up and restore, how they delete data, how they handle admin actions, and what evidence they can show for all of it. In practice, procurement teams often expect that level of detail before approval; for example, the 2023 IBM Cost of a Data Breach Report put the average breach cost at $4.45 million, which is why buyers should verify controls early. That is the checklist that usually separates a vendor that can pass procurement from one that only sounds secure, though buyers should still consult legal, security, or procurement professionals and review authoritative guidance such as NIST and CIS before signing.

Key Takeaways

• I want a data map, not a slogan.
• A generic checklist asks if a vendor is secure; a useful one asks how security works in practice.
• The best answer comes with evidence.
• Strong vendors lower uncertainty.

I write security due diligence for software buyers because most SaaS risk lives in the gaps between product pages, sales decks, and the legal addendum. Cluster F is the point where a vendor may be viable, but only if it can prove controls without hand-waving.

The 12 questions I would ask before I sign

1. What data do you store, and what do you explicitly not store?
   I want a data map, not a slogan. A vendor that stores customer content, metadata, admin logs, and support attachments has a very different risk profile from one that stores only account data. If the answer is vague, I assume the vendor has not classified its own system well enough for procurement, though I would still verify that assumption with a security or legal review.

2. How is tenant data isolated from other buyers?
   The useful answer names the isolation model: separate databases, row-level controls, bucket segregation, or dedicated environments. “Logical separation” by itself is not enough. If the vendor cannot explain this in plain language, ask for an architecture diagram.

3. What authentication methods do you support: SSO, SAML, SCIM, and MFA?
   For most business buyers, SSO and MFA are table stakes; SCIM matters if user provisioning must be automated. I would not accept “password login only” for anything with sensitive data unless the rollout is tiny and temporary.

4. Can you restrict access by role, field, or action?
   Fine-grained permissions matter when finance, operations, and support all touch the same system. If the platform only offers all-or-nothing admin rights, privilege creep becomes your problem.

5. What audit logs exist, how long are they retained, and can we export them?
   I want admin actions, login events, permission changes, API activity, and data exports. If the vendor keeps logs for only a short window, that limits incident review and compliance work.

6. Where is data stored and processed, and can we choose region?
   Data residency is not a vanity question. It affects legal exposure, transfer mechanisms, and sometimes buyer commitments. If the vendor cannot pin down regions, assume the answer is “it depends on product tier or tenant setup.”

7. Which subprocessors do you use, and how do you notify buyers of changes?
   This is where many teams get surprised. A credible vendor can name the categories of subprocessors and explain how changes are communicated. I would ask for the current list and the notice process, not just a promise.

8. What is your incident response process, and what is the notification window in the contract?
   You are not asking whether incidents happen. You are asking how fast the vendor detects, escalates, and notifies you when they do. The contract language matters because sales language is not enforceable.

9. How do you back up data, and what is your restore objective?
   Vendors often speak about backups in the abstract. I care about whether restore is documented, tested, and tied to a realistic recovery time and recovery point. If they will not discuss restoration, the backup story is incomplete.

10. What happens when we delete data or close the account?
    Ask about deletion timing, backup retention, and whether any residual data remains in logs or archives. “Deleted” can mean “removed from the user interface” while backups linger for a long time.

11. Can admins see sensitive data, and what controls limit internal access?
    Support access, production access, and break-glass procedures are easy places for trust to get overstated. I want to know who can reach production, under what approval, and whether access is logged and reviewed.

12. What independent evidence can you provide?
    This is the final gate. I would ask for a current SOC 2 report if available, ISO 27001 certification if claimed, recent pen test summary, and any relevant penetration or vulnerability management evidence. If the vendor cannot show evidence, the rest is mostly promises.

Why these questions matter more than a generic security questionnaire

These 12 questions are the ones that change the buying decision. A generic questionnaire asks whether a vendor is “secure”; a useful checklist asks how security actually works in production, and NIST SP 800-53 and the CIS Controls both emphasize documented controls, evidence, and verification over vague assurances.

The biggest mistake I see buyers make is starting with a 100-line spreadsheet and ending with a sales conversation. That flips the burden onto the vendor in the wrong way. Instead of learning how the product handles tenant isolation, data deletion, log retention, or admin access, the buyer collects checkbox answers that never affect the contract.

The practical test is simple: if a vendor can answer these 12 items crisply, there is usually a real security program behind the scenes. If the answers are slippery, the problem is rarely wording. It is usually that the product, the process, or both are still too immature for a serious deployment.

This matters most for SaaS with customer records, internal files, support attachments, financial data, or employee data. It matters less for a low-risk team tool with no sensitive content and no external obligations. That is the dividing line.

A second mistake is treating certifications like a finish line. SOC 2, ISO 27001, and similar frameworks help, but they do not answer everything a buyer needs. A report can show a control environment and still leave you guessing about subprocessor change notices, deletion timing, or role-based access inside the app. I would use certifications as evidence, not as the whole decision.

The exact evidence I would ask for

The answer I trust most is the one that comes with artifacts. If the vendor claims a control, I want documentation that matches the claim.

For the 12 questions above, I would ask for:

• a security overview or trust page,
• a current subprocessor list,
• a sample or summary of the SOC 2 report, if the vendor will share one under NDA,
• the incident response notification clause from the MSA or DPA,
• a data retention or deletion policy,
• a list of supported auth methods and identity providers,
• a screenshot or admin guide for roles and permissions,
• and a description of logging/export options.

If the vendor says “yes” to all 12 but cannot produce any artifact, I would treat that as a weak answer. A good vendor usually knows which questions procurement will ask before procurement asks them.

Here is the comparison that actually matters:

What a strong vendor answers well, and where it still falls short

Because the controls are clearer, a strong vendor wins by reducing uncertainty. It does not just say “we are secure”; it names controls, boundaries, and proof. That usually means enterprise auth support, useful logs, documented deletion, a subprocessor list, and a contract that says what happens after an incident. That is the package I would want before putting customer or employee data into the system.

The weakness is cost and complexity in practice. Strong controls can mean more implementation work, more admin overhead, and more dependency on the vendor’s support team during rollout. If the team needs to buy and deploy in a week with no IT help, some strong vendors will feel heavy.

That trade-off matters. A vendor that supports SAML, SCIM, and granular permissions may be exactly right for a 200-person company with central IT. It may be the wrong choice for a five-person startup that wants a quick tool for a low-risk workflow. Security depth is not free; it shows up in setup time, governance, and sometimes a more opinionated product.

I would choose the strong-vendor path when the SaaS will touch sensitive records, require auditability, or live inside a procurement process. I would skip it when the use case is low stakes and the team cannot support the admin overhead. That is not a knock on the vendor; it is a fit issue.

What a weak vendor gets wrong, and when it might still be acceptable

A weak vendor loses because it cannot answer the operational questions that buyers actually need. It may have a polished website, but if it cannot explain access control, retention, subprocessor changes, or incident notification, then the buyer is carrying hidden risk. In practice, that risk becomes extra legal review, slower rollout, and a bigger chance of a painful replacement later.

The weaknesses usually show up in the details. Password-only login, minimal role controls, no exportable audit trail, unclear deletion timing, and no hard evidence for claims. Each one adds friction. Together, they make the product hard to defend in front of security, legal, or procurement.

Still, I would not dismiss a weaker vendor automatically if the use case is narrow. A lightweight tool that never sees sensitive data, never integrates deeply, and can be replaced quickly may not justify a heavy procurement process. The key is that the business owner must be honest about blast radius. If the tool is going to sit near payroll, customer contracts, or regulated records, “good enough” security is usually not good enough.

I would reject the weak-vendor option when the vendor cannot answer at least half the 12 questions with specificity. That is usually the point where the product’s convenience stops compensating for the risk. A vendor that cannot explain its own security model is not ready for a serious buyer.

When does the verdict change?

The verdict flips in four situations. First, if the data is low sensitivity and the tool is easy to replace, I would tolerate fewer controls. Second, if the vendor is the only one with a must-have workflow or integration, I would accept some security gaps temporarily while documenting them in the contract. Third, if the buyer already has strong compensating controls upstream — identity enforcement, data-loss prevention, strict role management — the vendor’s weaknesses matter less, though not zero. Fourth, if the vendor will contractually commit to roadmap items such as SSO, audit logs, or retention controls within a defined period, I would treat that as a conditional win only if the commitment is written, dated, and tied to a renewal or exit right.

One number does matter here: if a vendor cannot produce evidence for even one of the core controls before signature, I would treat that as a blocker for a sensitive deployment. It is not a soft concern; it is a signal that security is still undocumented.

The verdict: which vendor to choose

Choose the strong vendor if the SaaS will hold customer data, employee data, or operational records, and if you need SSO, logs, subprocessor transparency, and a real deletion story. Choose the weaker vendor only if the workflow is low risk, the dataset is small, and the tool can be swapped without pain. Neither if the vendor cannot answer the 12 questions in writing or refuses to show evidence for the controls it claims.

What I would ask in the final procurement call

I would ask three closing questions before signature: What changed since the last security review? Which controls are still on the roadmap? What would the vendor put in writing today that it will also stand behind during an audit or incident? Those answers usually reveal whether the earlier checklist was substance or theater.

FAQ

Do I need all 12 answers before buying?

Yes, for a sensitive SaaS purchase. For a low-risk internal tool, I would still want most of them, but I would rank them by blast radius and contract exposure.

Is SOC 2 enough by itself?

No. SOC 2 is useful evidence, but it does not replace questions about deletion, access, logging, subprocessors, or incident notice.

What if the vendor says some details are confidential?

That is normal for parts of an architecture, but it should not block basic answers about controls, retention, identity, or incident handling. A serious vendor can share enough to let a buyer decide.

Should I ask legal or IT to review the answers?

Yes. For SaaS touching regulated, financial, or personal data, I would have legal review the MSA/DPA and IT review identity, logging, and access controls before signing.

Drafted with AI; not yet reviewed by a person.