Outsourced development
Purpose
Direct, monitor and review outsourced system development so required security measures are implemented.
How to meet this control
In short: Direct, monitor and review outsourced development activity.
- Step 01Set contractual security requirements for outsourced development covering secure design, coding and testing, and clarify intellectual property rights
- Step 02Provide the threat model and security standards external developers must build against
- Step 03Require evidence that agreed minimum security levels are met, including testing against known vulnerabilities
- Step 04Run acceptance testing on deliverables for quality, accuracy and security before they are accepted
- Step 05Secure a contractual right to audit the supplier development processes and environment
- Step 06Consider source code escrow in case the supplier ceases trading
Tip: Put security requirements and code-review rights in the contract.
What ISO 27002 says to cover
Reference points from the ISO/IEC 27002:2022 guidance for this control. Use them to check the steps above cover everything relevant to you.
- ›Communicate and agree security requirements with the supplier across the supply chain
- ›Set contractual requirements for secure design, coding and testing and clarify IP rights
- ›Provide the threat model for external developers to work against
- ›Run acceptance testing for the quality and accuracy of deliverables
- ›Require evidence that minimum security levels are met and testing guards against known vulnerabilities
- ›Put source code escrow agreements in place in case the supplier goes out of business
- ›Secure a contractual right to audit the supplier development processes
- ›Specify security requirements for the development environment and relevant legislation
Audit evidence to keep
- - Contract clauses specifying secure development and IP rights
- - Threat model or security standard provided to the supplier
- - Acceptance test results for outsourced deliverables
- - Supplier evidence of security testing against vulnerabilities
- - Right-to-audit clause or completed supplier audit record
Common mistakes
- - Treating security review as optional when release pressure rises
- - Testing only happy paths and missing abuse cases
- - Not linking production changes to approvals and rollback plans
Owner, cadence, and proof
Assign one accountable owner for A.8.30. Review this control at least annually, after related incidents, and whenever the underlying process, supplier, system, office, or legal obligation changes. The control is audit-ready when the owner can show the policy or procedure, the latest operating evidence, the latest review, and any open exceptions with due dates.
Policy templates for this control
Use these starting documents to turn the control into evidence. Adapt each template to your scope, systems, legal obligations and actual operating process.