8.30 Outsourced development
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.
Source: ISO/IEC 27002:2022, 8.30. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open ISO/IEC 27002:2022 in the compliance library.
ISO/IEC 27002 is guidance on the Annex A controls; certification is against ISO/IEC 27001. Use this set when your sheet follows the 27002 numbering.
These are the artefacts auditors commonly ask for on this requirement, our guidance rather than text from the standard. Your assessor decides what is sufficient in your context, and asks for samples across the period when a report covers one.
system holds itEvidence a system already holds
none for this control
periodic reviewEvidence produced at each review
- Acceptance test records for delivered software, including checks for malicious content and known vulnerabilities · Vulnerability scanner / patch tooling
- Supplier assurance reports demonstrating minimum security and privacy capabilities · Vendor register / contract repository
- Monitoring and review records of the supplier's delivery against agreed expectations · SIEM / log platform
governing documentDocuments that govern the control
- Development contracts covering intellectual property, secure design, coding and testing obligations, right to audit, development environment security and legal compliance · Vendor register / contract repository
- The threat model or security requirements provided to the external developer · Vendor register / contract repository
- Source code escrow agreements for critical software · Policy repository / GRC workspace
First move
Common gaps auditors find
- 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
Do this for your whole sheet
Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.
Build my evidence sheet8.29 Security testing in development and acceptance · 8.31 Separation of development, test and production environments