Third Party Vendors and Due Diligence

Standard procurement procedures should be used in the selection and engagement of appropriate subcontractors or software vendors (OEMs included). Use of these procedures should ensure that the subcontractor or software vendor:

• Is capable of delivering the services to the required standard;
• Can meet the required delivery timescales;
• Represents the best value for the organization;
• Can meet the specified security requirements.

The use of subcontractors by your organization for any aspects of the development should be understood and an assessment of these subcontractors included before engagement.

The contract with the subcontractor or software vendor should require compliance with this policy and include a clear statement of the requirements for secure design, coding, and testing of the software. The subcontractor or vendor should also be required to establish a secure development environment under your organization standards.

Requirements definition should be carried out by your organization so that a clear definition of the software to be created (including its security features) is agreed upon with the business and used as a contractual starting point. Whilst the subcontractor or software vendor may in some circumstances assist in the definition of requirements, the exercise should be led, managed, and ideally carried out by internal resources so that there is a clear separation between requirements and design/development.

A comprehensive picture of the anticipated threat model faced by the software should be provided to the subcontractor or software vendor so that a clear understanding is gained of the types of vulnerabilities that must be avoided if the software is to be secure.

Measures should be put in place to ensure adequate supervision of the activities of the subcontractor or software vendor and regular monitoring of progress.

For a large project with significant time gaps between deliverables, your organization could introduce multiple points of verifications, and an agreed method of verifying interim progress should be in place so that early warning is given of delays.

Review points should be established as part of the project planning process to verify progress and give the formal acceptance of the software deliverables created. These will involve appropriate testing activities and code reviews.

The subcontractor or software vendor should be required to provide evidence of the security testing activities carried out during the development, including tests for concealed malware, backdoors, and known vulnerabilities.

Where appropriate a security review of developed code may be engaged with a suitable 3rd Party with the relevant security expertise.

Conducting vendor risk assessments can be a long and tedious process. However, failing to do so could result in reputation damage, lost business, legal fees, and fines. If one of your vendors fails to comply with regulations (such as data privacy or safety standards), your company will face consequences, too.

Steps for identifying risks

1. Know the types of vendor risk
2. Determine risk criteria
3. Assess each product and service
4. Get help from experts
5. Assess every vendor
6. Separate vendors by risk level
7. Make a risk management plan
8. Stay up to date on regulations
9. Conduct annual assessments

your organization should have the contractual right to undertake a second audit of the subcontractor or vendor. This may be used to review whether the development methods used comply with your organization policies and whether all information provided to the supplier is protected by appropriate security controls.

Any software that is developed under an agreed contract with a subcontractor or vendor must be understood to be your organization's intellectual property. Appropriate legal advice should be taken particularly if the outsourcer is based outside of your organization's home country.

Arrangements should be made for your organization to be able to legally access the source code of any developments undertaken if the subcontractor or vendor ceases trading for any reason. This should be the case during development and if appropriate after the code has been delivered.