← All insights

Practical checklist or tool

Before You Buy the Software: A Cybersecurity Due-Diligence Worksheet for Central Florida Businesses

A practical worksheet for evaluating software vendors before purchase—covering identity, logging, patching, resilience, data handling, contracts, and evidence using current NIST, CISA, and FTC guidance.

Central Florida business team evaluating a software vendor using evidence cards and product-risk worksheets in a U.S. procurement room

Security decisions happen before the contract is signed

Small businesses often evaluate software by features, price, implementation time, and user experience. Security questions arrive late—after data has been imported, integrations have been built, and employees depend on the product. At that point, weak authentication, limited logs, unclear breach duties, or poor export options become expensive to correct.

NIST published Special Publication 1326 in July 2026 as a quick-start guide for cybersecurity supply-chain due diligence. It describes due diligence as research into relevant information about a supplier or product so an organization can make informed acquisition decisions. CISA’s Secure by Demand guide gives software customers practical questions about authentication, logging, vulnerability handling, patching, and secure defaults. The FTC advises small businesses to put vendor-security expectations in writing, limit vendor access, and verify compliance.

This worksheet translates those principles into a repeatable small-business review. It is not a certification and does not prove a product is secure. The depth of review should match the sensitivity of the data, the privileges granted, operational dependence, regulatory and contractual requirements, and the harm a failure could cause.

Step 1: classify the purchase

Write down what the product will do before reviewing the vendor.

  • Business process supported: ____________________
  • Business owner: ____________________
  • Technical owner: ____________________
  • Data processed, stored, transmitted, or generated: ____________________
  • Users and locations: ____________________
  • Systems or devices connected: ____________________
  • Administrative privileges required: ____________________
  • Maximum tolerable outage: ____________________
  • Required recovery point and recovery time: ____________________
  • Legal, contractual, insurance, or industry requirements: ____________________

Assign a review level. A low-impact tool may process public information with no integration. A moderate-impact product may handle internal business records or employee information. A high-impact product may process sensitive client, patient, student, payment, legal, financial, or operational data; control critical equipment; or receive broad administrator access.

Do not reduce the review simply because the product is popular, cloud-based, offered by an existing vendor, or described as compliant.

Step 2: verify the supplier

NIST SP 1326 identifies areas such as ownership and control, provenance, resilience, foundational cyber practices, and supply-chain tiers. A small company may not conduct an intelligence-grade investigation, but it can document basic facts.

  • Legal company name, headquarters, and contracting entity verified: Yes / No
  • Product publisher and reseller roles distinguished: Yes / No
  • Hosting providers and material subprocessors identified: Yes / No
  • Acquisition, merger, or ownership changes reviewed: Yes / No
  • Public security contact and vulnerability-disclosure process found: Yes / No
  • Relevant breach, enforcement, or service-history claims checked: Yes / No
  • Support location, hours, and emergency escalation confirmed: Yes / No
  • End-of-life and product-support commitments documented: Yes / No

Use authoritative records and vendor documentation. Record uncertainty rather than converting a missing answer into a favorable assumption.

Step 3: ask about identity and access

CISA’s Secure by Demand guide encourages customers to ask whether secure authentication features are included in the baseline product. For each answer, request documentation or a demonstration.

  • Standards-based single sign-on supported: Yes / No / Additional cost
  • Multifactor authentication available and enforceable for all users: Yes / No
  • Phishing-resistant authentication supported for administrators: Yes / No
  • Default or shared passwords eliminated: Yes / No
  • Separate named administrator accounts supported: Yes / No
  • Role-based access and least privilege available: Yes / No
  • Dormant users and sessions can be identified: Yes / No
  • Emergency access is controlled and logged: Yes / No
  • Vendor support access requires approval, time limits, and logging: Yes / No
  • Automated provisioning and deprovisioning supported: Yes / No

Ask who can reset authentication, export data, change retention, disable logs, or delete backups. A product may support MFA for ordinary users while leaving a support portal, API key, service account, or recovery channel less protected.

Step 4: evaluate logs and monitoring

A business cannot investigate events it cannot see. CISA recommends that security logs be available to customers in the baseline product and discusses meaningful retention for cloud and software services. Ask:

  • Which sign-in, administrator, configuration, data-access, sharing, and deletion events are logged?
  • How long are logs retained, and is retention included or separately priced?
  • Can logs be exported in a usable format or sent to a monitoring service?
  • Can administrators alter or delete the audit history?
  • Are alerts available for risky sign-ins, privilege changes, mass downloads, retention changes, and disabled safeguards?
  • Are timestamps, user identities, source addresses, affected objects, and outcomes included?
  • How quickly can the vendor provide additional evidence during an incident?

Test a representative event during a trial. Confirm that the action appears in the log with enough detail to support an investigation. A checked feature box is weaker evidence than an observed result.

Step 5: examine vulnerability and update practices

  • Public vulnerability-disclosure policy: Available / Missing
  • Security advisories and CVE records: Timely / Inconsistent / Unknown
  • Automatic security updates: Default / Optional / Unavailable
  • Customer-controlled maintenance windows: Yes / No
  • Critical update timeline documented: Yes / No
  • Unsupported components or operating systems disclosed: Yes / No
  • Software bill of materials available when appropriate: Yes / No / Restricted
  • Secure development or independent testing evidence available: Yes / No
  • End-of-support notification period: ____________________

An attestation, penetration-test summary, or certification may be useful evidence, but read the scope, date, exclusions, responsible entity, and product version. Do not treat a company-wide report as proof that every module, integration, or configuration is covered.

Step 6: map data handling

  • Data categories and purposes documented: Yes / No
  • Data storage and processing locations documented: Yes / No
  • Encryption in transit and at rest documented: Yes / No
  • Vendor workforce access controlled and logged: Yes / No
  • Subprocessor list and change-notification process available: Yes / No
  • Retention and deletion controls match business requirements: Yes / No
  • Data used for analytics, advertising, or model training: Yes / No / Optional
  • Customer can export data and important metadata: Yes / No
  • Secure deletion after termination documented: Yes / No
  • Legal-hold and records requirements supported where needed: Yes / No

If the product includes artificial intelligence, distinguish customer prompts, uploaded files, retrieved content, outputs, feedback, and operational telemetry. Verify which information may be used to improve models and whether settings apply to every feature.

Step 7: test resilience and exit options

NIST includes resilience in due-diligence assessment. Ask the vendor to explain dependencies, recovery, and the customer’s responsibilities.

  • Published availability and support commitments: ____________________
  • Backup responsibility divided between vendor and customer: ____________________
  • Recovery tests performed and results summarized: Yes / No
  • Regional or provider concentration understood: Yes / No
  • Offline or alternate operating procedure available: Yes / No
  • Bulk export tested with representative data: Yes / No
  • Required formats, relationships, permissions, and audit history exportable: Yes / No
  • Contract termination assistance and time window defined: Yes / No
  • Customer data deletion confirmation available: Yes / No

For Central Florida organizations, include hurricane, extended-power, telecommunications, and facility-access conditions. A resilient cloud product does not help if staff cannot authenticate, retrieve emergency contacts, or use an approved alternate workflow.

Step 8: put obligations in the contract

The FTC recommends specific, written security provisions and verification. Depending on risk and legal advice, address:

  • Required safeguards and configuration responsibilities.
  • Incident-notification triggers, contacts, content, and timing.
  • Cooperation, evidence preservation, and investigation support.
  • Subprocessor oversight and notice of material changes.
  • Patch, vulnerability, and end-of-support obligations.
  • Availability, backup, restoration, and recovery responsibilities.
  • Data location, use, retention, export, return, and deletion.
  • Audit reports, assessments, or other evidence the customer may receive.
  • Cyber-insurance requirements where appropriate.
  • Transition assistance, termination rights, and survival of security duties.

Marketing pages can change. Preserve the contractual version, security exhibits, configuration decisions, and evidence relied upon.

Step 9: record the decision

Choose one outcome: Approve / Approve with conditions / Pilot with restricted data / Defer / Reject.

Document the important gaps, compensating controls, owner, due date, residual risk, approval authority, and next review date. Conditions might include disabling an unsafe integration, using a separate identity group, limiting data, requiring MFA, obtaining a contract addendum, or completing a restoration test before broader rollout.

Reassess after a major product change, breach, acquisition, new integration, significant data expansion, contract renewal, or control failure. Vendor due diligence is not a one-time questionnaire; it is a lifecycle decision.

The goal is not to collect the most paperwork. It is to obtain enough reliable evidence to understand what the product can access, how it is protected, how the organization will detect trouble, and how operations and data can be recovered or moved when assumptions fail.

Human-reviewed draft. This worksheet provides general information and is not legal, procurement, compliance, or product-specific advice.

Sources