Renewal time is when most businesses accidentally accept risk. Not because you are careless, but because the tool “works”, your team is busy, and security questions feel like a detour.

Secure by Design flips that. The idea is simple: vendors should build products that are safer by default, and prove it with real practices and real evidence, not marketing.

Use this checklist before you renew any software that touches customer data, finances, identity (logins), or core operations.

Start with one framing question

Before you ask about certifications or policies, ask this:

“If we get hit with a vulnerability next month, what will you do, how fast will you ship a fix, and how will you prove we are protected?”

That question pulls the conversation out of the abstract and into how your business will actually experience a security issue: communication, patches, and clear next steps.

Patching and updates: how do fixes reach you?

A lot of vendor risk is not “do they patch”, it is “do patches reliably land in your environment without drama”. You want to know the vendor’s normal cadence, their emergency process, and what you are responsible for.

Ask:

  • What is your normal security patch cadence? Monthly, weekly, continuous, or “as needed”. Get a plain answer, not a paragraph.
  • How do you handle urgent, out-of-band fixes? If something is being actively exploited, what changes in their process?
  • How will you notify us? Email list, in-app banner, status page, RSS, customer portal. Also ask if you can subscribe without being a technical admin.
  • What do we have to do on our side? For SaaS, patches should usually be vendor-handled. For on-prem or self-hosted, ask what the update steps look like and how long a typical update takes.
  • How do you prove the fix is applied? Look for release notes that clearly identify security fixes, plus a way to confirm version/build in the admin console.

Evidence to request:

  • A sample security advisory or release note. You are checking for clarity: affected versions, what changed, and what the customer must do.
  • A copy of their customer notification process. Even a one-page “here’s how we communicate security issues” is useful.

Secure development: do they build software with security baked in?

This is where Secure by Design v1.1-style thinking helps you stay practical. You are not trying to audit their engineering team. You are trying to confirm they follow a secure software development framework, and can show repeatable proof.

Ask:

  • Do you follow a secure development framework? A good sign is alignment to NIST’s Secure Software Development Framework (SSDF).
  • How do you prevent insecure changes from shipping? You are listening for security requirements, code review, automated testing, and gates in their build process.
  • How do you manage open-source components? Most products include third-party libraries. Ask how they track them and respond when a library has a vulnerability.
  • Do you do independent security testing? Internal testing is good. Third-party testing, done regularly, is better.

Evidence to request:

  • A secure development policy summary mapped to SSDF. Even a short mapping is a sign they take this seriously.
  • A recent penetration test attestation letter or summary. You do not need the full report. You do need proof it happened recently and what scope it covered.
  • A software bill of materials (SBOM) process statement. You are not asking for every component list in the sales cycle, you are asking whether they can produce one and how they use it.

Vulnerability reporting: can researchers tell them about flaws safely?

You want vendors who make it easy to report vulnerabilities, and who handle reports in an organised, predictable way. This is one of those “boring until it matters” topics.

Ask:

  • Do you have a public vulnerability disclosure policy (VDP)? Where is it published, and what systems/products does it cover?
  • How can someone report a vulnerability? You want a clear contact method and expectations for response.
  • Do you coordinate disclosure timelines? You are listening for a coordinated vulnerability disclosure approach, not “we do not comment”.

Evidence to request:

  • Their published VDP. File it with your vendor records.
  • A sample security advisory. Again, you are checking for customer-friendly communication.

Access and identity: what happens when an account is compromised?

Even great software gets used badly. Secure by Design also means the product helps you recover quickly from the most common real-world failures: stolen passwords, over-permissioned users, and risky integrations.

Ask:

  • What MFA options do you support? For admins and for regular users.
  • Can we enforce MFA and strong sign-in rules? Especially for privileged roles.
  • Do you support single sign-on (SSO)? If yes, what standards, and what does it cost?
  • Do you provide audit logs we can actually use? Who logged in, from where, what changed, what data was accessed.

Evidence to request:

  • An admin guide page or security configuration guide. You want something your team can follow during onboarding.
  • A sample audit log export. Redact it if needed, you are just confirming it exists and is usable.

Data handling: what exactly are you trusting them with?

This is where business owners tend to ask the right question, but stop one step early.

“Is our data encrypted?” is fine. “Show me how you separate our data from other customers, back it up, and delete it when we leave” is better.

Ask:

  • Where is our data stored and processed? Country and cloud provider are a start.
  • How do you back up customer data, and how often do you test restores? You are looking for routine testing, not just “we have backups”.
  • What is your retention and deletion process? When you terminate, what happens to your data and how long does it take?

Evidence to request:

  • A current SOC 2 Type II report (or equivalent) and a plain-English bridge letter. If they have it, they are used to serious customer questions.
  • A data retention and deletion statement. This matters for offboarding and compliance.

How to use this checklist without turning it into a 6-week project

A simple approach that works for growing businesses:

  • Pick your “renewal tier”. Tier 1 is anything tied to money, identity, customer data, or operations. Tier 2 is everything else.
  • Ask for evidence once, then file it. Create a vendor folder with: VDP, SOC report, pen test attestation, security contact, and patch communication method.
  • Decide what is a deal-breaker. For Tier 1 tools, “no MFA” or “no audit logs” should stop the renewal.

Want a second set of eyes on a renewal?

You do not need to become a software security assessor to ask good questions. You just need a repeatable list, and the confidence to request proof.

If you would like help turning these questions into a vendor renewal process your team can run every quarter, the Flexnet Networks team can help you put it in place.

Sources