Outsourced development

What the requirement asks

When another party develops systems for the organization, the organization is to steer that work, watch it and review it. Purpose: make sure the security measures the organization requires are actually applied in development done by others. Guidance: communicate and agree requirements and expectations with the developer and keep monitoring and reviewing whether the delivered work meets them. Across the whole external supply chain, consider licensing, code ownership and intellectual property in the outsourced work (5.32); contract terms requiring secure design, coding and testing practices (8.25 to 8.29); giving external developers the threat model to work to; acceptance testing of the quality and accuracy of deliverables (8.29); evidence, such as assurance reports, that minimum security and privacy capabilities are in place; evidence that testing on delivery was enough to guard against malicious content, deliberate or accidental; evidence that testing was enough to guard against known vulnerabilities; source code escrow in case, for example, the supplier fails; a contract right to audit how the supplier develops and what controls it runs; security requirements for the development environment (8.31); and applicable law, such as personal data protection. Other information: the ISO/IEC 27036 series covers supplier relationships further. In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.

What the guidance adds

Outsourced development carries the same requirements. The guidance asks for the contract, the assurance and the acceptance.

What good looks like

Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep development contracts covering intellectual property, secure design, coding and testing obligations, right to audit, development environment security and legal compliance and one live sample together.

Evidence an assessor asks for

• Outsourced development governanceDevelopment contracts covering intellectual property, secure design, coding and testing obligations, right to audit, development environment security and legal compliance
• Outsourced development governanceThe threat model or security requirements provided to the external developer
• Outsourced development governanceAcceptance test records for delivered software, including checks for malicious content and known vulnerabilities
• Outsourced development governanceSupplier assurance reports demonstrating minimum security and privacy capabilities
• Outsourced development governanceSource code escrow agreements for critical software
• Outsourced development governanceMonitoring and review records of the supplier's delivery against agreed expectations

The question an assessor will ask

An assessor will ask for development contracts covering intellectual property, secure design, coding and testing obligations, right to audit, development environment security and legal compliance, then trace it to the system it protects. For A.8.30 the test is whether that record ties to a live sample, not whether the control is named in a policy.

Common gaps

• Contracts focus on functionality and deadlines with no secure development obligations
• Delivered code is accepted without any security testing
• No escrow exists for critical software from small suppliers
• Sub-contracted developers further down the chain are unknown and unmanaged

Before the next audit

Before the next audit, check one live sample for this gap: contracts focus on functionality and deadlines with no secure development obligations.