EXECUTIVE AND VCISO INSIGHTS
Software Vendor Security Due Diligence: What to Ask Before Buying SaaS
A security questionnaire is not due diligence if every answer is accepted without context, evidence, or a decision. Before buying software as a service (SaaS), an organization should understand what the product will access, how failure or compromise could affect the business, which security duties remain with the customer, and what evidence supports the vendor’s claims.
Current CISA and NIST guidance treats secure software acquisition as a lifecycle activity. The review begins before selection, informs contract and configuration, continues through changes and incidents, and ends only after data and access are removed. This article adapts that approach for business SaaS purchasing without implying that one questionnaire or certification makes a vendor safe.
Executive summary
A proportionate SaaS review has five parts:
- classify the business, data, identity, and operational impact of the product;
- ask questions that match that risk instead of sending the same list to every vendor;
- collect evidence for important answers;
- put responsibilities, notification, access, recovery, and exit terms into the agreement;
- record the decision, unresolved risk, owner, conditions, and review date.
CISA’s 2025 Software Acquisition Guide Supplier Response Web Tool was designed to make risk-informed acquisition questions more manageable and to create exportable summaries. NIST’s July 2026 SP 1326 due-diligence quick-start guide describes due diligence as researching pertinent information about a supplier or product so informed acquisition decisions can be made. Those government resources can inform commercial reviews, but a business should tailor depth to its own use, obligations, and risk.
Tier the product before asking questions
Review effort should follow potential impact. A public event-scheduling tool is not equivalent to a platform that processes patient information, controls identity, stores financial records, deploys code, or supports manufacturing.
Classify:
- data sensitivity and volume;
- whether the product creates, receives, maintains, or transmits regulated or contract-controlled information;
- integration with identity, email, finance, HR, clinical, production, or administrative systems;
- delegated and application permissions;
- ability to create, change, send, approve, or delete;
- number and type of users;
- Internet exposure and third-party access;
- outage tolerance and recovery dependency;
- replaceability, export, and concentration risk;
- legal, privacy, records, geographic, and customer commitments.
Define review tiers before a purchase request arrives. A high-impact system should require stronger evidence, legal and security review, technical testing, executive risk acceptance, and ongoing monitoring.
Map the complete service and responsibility boundary
Ask the vendor for a current architecture and data-flow explanation that covers customer devices, authentication, application services, APIs, storage, backups, logging, support, development, deployment, and subprocessors. Confirm what is dedicated, logically separated, shared, customer-configurable, or controlled only by the vendor.
Create a responsibility matrix. “The service supports MFA” is not the same as “MFA is enforced for every customer and vendor administrator.” “The platform encrypts data” does not identify who manages keys, where plaintext exists, how backups are protected, or whether exports remain encrypted.
Identity and access questions
Ask:
- Does the service support standards-based single sign-on and automated provisioning/deprovisioning?
- Can the customer require phishing-resistant multifactor authentication for administrators and high-risk users?
- Are vendor support and production administrators uniquely identified and strongly authenticated?
- Are privileged roles separated, approved, time-limited, and logged?
- Can the customer define granular roles, groups, locations, devices, sessions, and application permissions?
- Are service accounts, API tokens, OAuth grants, and machine identities inventoried, scoped, rotated, and revocable?
- Can access reports and administrative events be exported to the customer’s monitoring platform?
Collect evidence such as configuration documentation, a role matrix, sample audit events, identity architecture, and an administrator-access procedure. A feature roadmap is not current control evidence.
Data protection and lifecycle questions
Identify what data enters the service, derived data it creates, and metadata it retains. Ask about:
- purpose and permitted use;
- tenant separation;
- encryption in transit and at rest and key responsibilities;
- storage and backup locations;
- retention defaults and customer controls;
- deletion from primary, backup, log, and support systems;
- data export format and completeness;
- customer-managed keys when justified;
- subprocessors and cross-border processing;
- production data used in development, testing, support, analytics, or model training;
- privacy requests, legal holds, and account termination.
Verify contract and product settings. The organization should know whether disabling an account, deleting a record, and ending the contract produce different retention outcomes.
Secure development and supply-chain questions
CISA’s Secure by Demand guide suggests buyers ask about secure-by-default features, vulnerability disclosure, timely and accurate vulnerability records, multifactor authentication, default passwords, software bills of materials, and plans to eliminate classes of defect. NIST SP 800-161 Rev. 1 provides a broader cybersecurity supply-chain risk-management framework.
For the product under review, ask:
- Is there a secure development lifecycle with threat modeling, code review, dependency management, and security testing?
- How are third-party packages, build systems, signing keys, source repositories, and deployment pipelines protected?
- Does the vendor publish a vulnerability-disclosure policy and maintain a monitored reporting channel?
- How are vulnerabilities prioritized, remediated, communicated, and validated?
- How quickly are actively exploited or critical product issues addressed, and what temporary mitigations are provided?
- Can the vendor provide appropriate software-component or provenance evidence for the risk level?
- Are penetration tests independent, current, scoped to the purchased service, and followed by remediation?
Do not request sensitive exploit details that the organization cannot protect. Ask for useful assurance: scope, date, tester independence, methodology, material findings, remediation status, and retest evidence.
Logging, monitoring, and investigation questions
A SaaS service can be secure by design and still leave the customer unable to investigate account misuse. Confirm whether logs include successful and failed authentication, administrator activity, role and permission changes, application grants, data access and exports, configuration changes, API activity, integrations, security alerts, and vendor support access.
Ask about timestamp consistency, retention, immutability, search, export, API access, licensing, alert delivery, and event latency. Obtain sample events and test them during a pilot. A PDF describing logging is not proof that the purchased license exposes the needed fields.
Incident response and notification questions
Contract and operating procedures should address:
- what constitutes a security incident and a confirmed breach;
- how and when the vendor notifies the customer;
- which contact paths operate outside the affected service;
- initial facts, updates, evidence preservation, and final reporting;
- customer access to relevant logs and investigation support;
- responsibility for regulators, affected individuals, partners, and insurers;
- subprocessor incidents;
- coordination of public statements;
- remediation and correction of inaccurate early information.
Avoid relying on “without undue delay” without understanding how the term interacts with the organization’s real deadlines. Qualified counsel should review legal requirements and the exact contract.
Availability, backup, and recovery questions
Service-level percentages do not explain recovery. Ask for dependency mapping, redundancy, backup isolation, restore testing, recovery objectives, capacity, denial-of-service protections, regional failure planning, and customer responsibilities.
Test how the business operates if the service, identity provider, integration, or Internet connection is unavailable. Determine whether the organization can export essential records, continue a critical process, and reconcile changes after restoration. Review status and incident-history information in context; past uptime is not a guarantee.
Evidence that deserves closer review
Depending on risk, collect and validate:
- current independent assessment or certification reports and their scope;
- penetration-test summary and remediation evidence;
- architecture and data-flow diagrams;
- secure-development and vulnerability-management documentation;
- subprocessor list and change process;
- incident-response and recovery test summaries;
- role, permission, and sample audit-log exports;
- data retention, deletion, and export documentation;
- cyber-insurance evidence when contractually relevant;
- financial, ownership, provenance, resilience, and supply-chain information appropriate to the decision.
A certification report can be helpful, but verify the covered service, dates, locations, control period, exclusions, customer responsibilities, exceptions, and complementary controls. Do not convert a report logo into a blanket approval.
Put security into selection and contract terms
Security requirements have more leverage before signature. Convert high-priority findings into evaluation criteria and contractual obligations, including:
- required authentication and logging capabilities;
- security configuration and customer-responsibility documentation;
- restrictions on data use and subprocessors;
- vulnerability and patch communication;
- incident notification and cooperation;
- evidence access and audit rights appropriate to risk;
- availability, recovery, and support commitments;
- data return, deletion, transition assistance, and termination;
- change notification for material architecture, ownership, or service changes.
The contract does not replace technical validation. It gives the parties a documented basis for responsibility and escalation.
Record the decision and monitor the lifecycle
The approval record should state:
- product and approved use;
- risk tier and data classification;
- evidence reviewed and date;
- gaps, compensating measures, and owner;
- contract conditions;
- configuration required before launch;
- residual risk acceptance and approver;
- review triggers and next review date;
- incident, offboarding, and replacement contacts.
Reassess after material product, subprocessor, data, integration, permission, ownership, contract, incident, or threat changes. Monitor advisories, expiring reports, new vulnerabilities, access drift, unused integrations, and business reliance.
OC Security Audit’s vendor risk management guidance and NIST supply-chain risk management resource can help turn procurement evidence into an accountable review program. The vendor-hosted service exposure assessment can support initial scoping but does not replace a professional review.
Questions executives should ask before approval
- What business process stops or becomes unsafe if the service fails?
- What data and authority does the vendor receive, directly and through integrations?
- Which important answers were verified with evidence?
- What controls must the customer configure and monitor?
- What unresolved risk remains, who accepts it, and for how long?
- What happens when the vendor, product, contract, or subprocessor changes?
- Can the organization retrieve its data and remove access without depending on the vendor’s production service?
Sources
- CISA: Software Acquisition Guide Supplier Response Web Tool, August 2025
- CISA: Software Acquisition Guide Fact Sheet
- CISA: Secure by Demand Guide for Software Customers
- CISA and partners: Choosing Secure and Verifiable Technologies
- NIST SP 1326: Cybersecurity Supply Chain Risk Management Due Diligence Assessment Quick-Start Guide, July 2026
- NIST SP 800-161 Rev. 1 Update 1: Cybersecurity Supply Chain Risk Management Practices
Make the SaaS decision before the risk is locked into a contract
Contact OC Security Audit to discuss an independent vendor, cloud, identity, or security-risk review. Learn more about Ali Hassani, CISO and his experience across cybersecurity, infrastructure, vendor risk, audit, and executive security leadership.
Extend the vendor review when the service uses autonomous workflows by applying the AI-agent identity and permission controls; record the decision in an executive cyber-risk decision register; and, when ePHI may be involved, use the HIPAA and AI tools review.
Update and correction history
- July 2026: Initial analysis prepared from CISA and NIST software-acquisition and supply-chain guidance available through July 2026.