A healthcare insurance organization chose a vendor to develop a software application. Upon review of the draft contract, the information security professional notices that software security is not add

The SLA governs service performance metrics and availability targets, not the development-level security capabilities of the software itself, so auditing rights in the SLA would not obligate the vendor to build secure software.

The SLA is a supplementary document focused on operational service levels rather than development obligations; requiring security capabilities in the SLA is less enforceable and less appropriate than placing that requirement in the primary contract.

The contract is the binding legal agreement that defines the vendor's obligations for software development, making it the most authoritative and enforceable place to require security capabilities. Updating the contract ensures that security requirements are legally obligatory from the outset of the engagement, not just operationally expected. This approach addresses the root issue-absent security language in the primary agreement-by embedding security obligations directly where they carry the most legal weight.

Requiring only security code reviews in the contract is too narrow-it addresses one specific activity rather than broadly obligating the vendor to provide comprehensive security capabilities throughout the software development lifecycle.