Technology

Software Security Starts Before the Contract Is Signed

Oct 19, 2026 • 9 min read

A software demonstration shows what a product can do under selected conditions. A purchasing decision commits the business to something broader: the way that product will be configured, updated, supported and eventually replaced. Security depends partly on those less visible arrangements.

For companies buying cloud services, business applications or connected software, the challenge is to turn broad assurances into usable evidence. A claim that a product is secure does not explain who handles a vulnerability, how customers receive important information or which controls require a more expensive subscription.

That makes procurement part of the security process. Commercial teams do not need to become software engineers, but they need a clear route for involving the people who understand the business use, technical dependencies and potential consequences of failure. The most useful questions arise while there is still time to compare options and negotiate responsibilities.

Start with the business dependence

A small application can become important through the work it supports. A scheduling tool may be easy to replace in one department but essential to a service with time-sensitive customer commitments. The purchase price alone does not describe the risk.

NIST's guidance on cybersecurity supply-chain risk management, including its November 2024 update, addresses the identification, assessment and management of risks associated with acquired products and services. It provides a framework for considering technology dependencies rather than treating each supplier questionnaire as a separate administrative task.

An illustrative manufacturer evaluating a production-reporting application should consider what happens if it becomes unavailable or produces incorrect data. Would the business lose a convenient dashboard, or would staff be unable to release an order safely? Different answers justify different levels of scrutiny.

This assessment should include the intended data and access. A product that begins with a limited trial can later gain sensitive information or connections to important systems. The review should be reopened when the use changes materially, rather than assuming that the original approval covers every future expansion.

Ask how the supplier builds and maintains software

The NIST Secure Software Development Framework version 1.1, published in 2022, describes practices intended to reduce software vulnerabilities and address their causes. It also gives purchasers and suppliers a shared vocabulary for discussing development practices. It should be used as guidance for inquiry, rather than treated as a product guarantee.

A buyer can ask how a supplier identifies defects, prioritises remediation and communicates changes. The answers should connect to the product being purchased. A general corporate presentation may say little about a legacy product maintained by a different team or a recently acquired service.

Evidence should be interpreted within its scope. An assessment covering one environment, date or product version does not necessarily establish the condition of another. A self-attestation records a supplier's statement; an independent assessment may provide different evidence, but it also has limits.

The business needs a judgment about the proposed use, not a collection of impressive-looking documents. If a material question remains unanswered, the decision record should identify the uncertainty, the person accepting it and any conditions attached to deployment. Recording acceptance does not remove the underlying risk.

Security features need a commercial explanation

The CISA and FBI Secure by Demand Guide, issued in August 2024, encourages software customers to examine manufacturers' security practices and make security part of their purchasing conversations. Its significance is the influence customers can exert before and after procurement.

For a buyer, an important distinction is between a capability the product offers and a capability included in the proposed contract. Features needed to manage access, investigate activity or connect to existing controls may depend on edition, configuration or additional services.

An illustrative finance department might compare two applications with similar subscription prices. One requires extra spending to obtain the audit information the company needs. Another includes that information but requires more integration work. The meaningful comparison concerns the cost of operating the service with appropriate controls, rather than the headline licence price.

Procurement should therefore involve the teams who will administer the product. They can identify requirements that may not be visible during a demonstration. The exercise can also reveal whether the business has the internal capacity to operate the chosen configuration consistently.

Component visibility must lead to a response

Software often contains components obtained from other developers. A software bill of materials, or SBOM, can describe those components and their relationships. CISA's SBOM resources provide material on using that information across the software lifecycle.

Possessing a component list is different from being able to act on it. A buyer needs to understand which version the information covers, how it is refreshed and who determines whether a reported issue affects the deployed product. An inventory without ownership can become another file that nobody consults during an incident.

The depth of information required should follow the use case. A small business buying a managed service may rely on the supplier to investigate affected components and communicate material findings. A larger organisation may maintain its own analysis. In both cases, the responsibilities should be clear enough to support a timely decision.

The appropriate question is not whether an SBOM proves that software is safe. It is how component information helps the customer and supplier identify an exposure and decide what to do. Visibility supports risk management when it is connected to a maintained process.

Contract terms should describe an operating relationship

A contract can allocate responsibilities, but it cannot make every future incident predictable. Useful terms establish how the parties will work when there is uncertainty: how they exchange information, which contacts can make decisions and what support is available.

A buyer should distinguish an initial response from a substantive remedy. A promise to acknowledge an issue quickly does not mean the supplier will restore a service or release a fix in the same period. Service commitments should be read in the context of their definitions, exclusions and dependencies.

An illustrative critical-service contract might include a clear escalation route and a way to coordinate customer communications. That helps when several organisations need consistent information. It does not justify promising customers that every incident will be resolved within a fixed period regardless of its cause.

Commercial remedies also have practical limits. A service credit may compensate for part of a fee without covering wider operational disruption. The business should assess the consequences it retains rather than assume the supplier's contractual liability equals the possible impact on customers or revenue.

Onboarding is part of the purchase

Software can arrive with controls available but not configured for the organisation's use. A purchase is therefore incomplete as an operating decision until the business understands how access, data handling and administration will work.

The NIST Cybersecurity Framework offers a broader structure for managing cybersecurity risk, including governance and the relationship between protection, detection, response and recovery. For procurement, the analytical implication is that a product should fit the organisation's operating responsibilities, not simply pass a one-off purchasing check.

The implementation plan should name the service owner and identify who approves changes. It should also establish the handover between the project team and the people responsible for normal operation. A successful launch can otherwise leave maintenance tasks without an accountable recipient.

Testing should use representative workflows and appropriate data. An integration that works in a demonstration may still behave differently when users have different permissions or when an input is missing. The business should know how incomplete or uncertain activity will be detected and resolved.

Updates change the risk after purchase

The operating environment does not remain fixed when a contract is signed. Suppliers release changes, integrations evolve and the buyer's use of the service expands. Those changes can affect both security and continuity.

A renewal review can examine whether the product still performs the role for which it was approved. Has it gained access to additional information? Has support moved to a different arrangement? Does a newly introduced feature alter how data leave the organisation? These questions help keep the commercial relationship connected to actual use.

The review should remain proportionate. Repeating an extensive questionnaire for an unchanged, low-impact service can consume resources without improving the decision. A material change to a critical service may require deeper work. The point is to identify what has changed and whether the existing assessment still applies.

Changes within the buyer matter as well. A product may become more important when a manual alternative is retired. The resulting dependence should be recorded even if the supplier has changed nothing. Security and resilience assessments need to follow the business process, not just the vendor's release schedule.

An exit plan should preserve usable information

A firm can understand the risk of changing suppliers more clearly if it has considered the practical steps before a dispute or service failure. Exporting data is only part of the task. The information must remain interpretable, accessible to authorised staff and usable in the next operating arrangement.

An illustrative business may be able to download transactions while losing the attachments or contextual fields needed to explain them. A migration test can reveal that gap while the current service is available. The organisation should also understand the relevant retention, deletion and access arrangements under its contract and applicable obligations.

An exit plan does not mean maintaining a duplicate of every application. It means having a credible view of the dependencies, effort and decisions involved in leaving. That view can improve a renewal discussion and reduce the chance of an urgent choice based on incomplete information.

Questions buyers often ask

Does a security assessment remove supplier risk

No. It provides evidence within a defined scope and period. The buyer still needs to consider its own configuration, dependencies and continuing responsibilities.

Is the lowest subscription price the lowest operating cost

Not necessarily. Integration, required control features, administration, support and eventual migration can change the total. The comparison should reflect the service the organisation actually needs to operate.

Who should own the final decision

The business should identify an accountable owner who can consider operational needs alongside technical and commercial advice. Responsibility should remain clear after implementation and when the service changes.

Software purchasing creates a continuing relationship with a product and its supplier. Better decisions connect the promised functionality with the evidence, resources and responsibilities needed to operate it. The contract is one milestone in that relationship; the business value depends on what happens throughout the service's life.