Outsourced Development - ISO 27001 Annex A Control

ISO 27001 Annex A 8.30

Outsourced does not mean unaccountable - the security expectations have to travel with the work.

ISO 27001 Annex A 8.30 - Outsourced Development

Outsourced development - to a development house, a freelance developer, an offshore team - extends the organisation's development boundary to people who are not employees. The control asks for those activities to be directed, monitored and reviewed so that the security standards applied internally also apply to the outsourced work.

Direction starts with the contract. Security requirements, coding standards, testing expectations, deliverable acceptance criteria, and access arrangements should all be set out before work starts. Generic non-disclosure agreements are not sufficient - the contract needs to specify what good looks like for the work concerned.

Monitoring and review continue through the engagement. Code reviews, security testing of deliverables, periodic check-ins on adherence to the agreed standards, and acceptance testing before release all confirm that the work meets requirements. Where issues surface, the contract should support remediation and, in serious cases, termination.

The outsourced development gap that surfaces in audit is the supplier whose security practices are unknown because nobody asked. The contract was signed years ago, the work has been delivered satisfactorily on schedule, and security has never been formally evaluated. The supplier review under A.5.22 is the natural mechanism for closing this gap.

Practical Compliance Guidance

Outsourced development arrangements are described in the IMS1 manual at section 8.5 alongside the Supplier Management Procedure. Contract records and review outputs provide the operational evidence.

alphaZ document	How to use it
ISO 27001 Toolkit	The full alphaZ ISO 27001 toolkit covering manual, policies, procedures, registers and audit checklists.
PP-8-100 Information Security Policy Procedure	Contains the supplier security arrangements that apply to outsourced development. Use as the source for the contractual baseline.

Note - all the above files can be downloaded with an alphaZ subscription.

Frequently Asked Questions

What should the contract cover?

Security requirements applicable to the work, secure coding and testing standards, code ownership and IP arrangements, source code repository access, security review and acceptance gates, vulnerability disclosure expectations, and rights to audit. The supplier security baseline under A.5.20 provides the framework.

How do we verify the supplier's practices?

Through supplier due diligence at engagement (certifications, references, security questionnaire), ongoing review through delivered artefacts (code review, security testing), and periodic supplier review under A.5.22. The depth of verification should match the criticality of the work.

What happens if the supplier delivers code with vulnerabilities?

The contract should provide for remediation at the supplier's cost where the issues fall within the agreed standards. Acceptance testing should catch most issues before release. Patterns of issues should drive review of the wider relationship rather than fixing each one in isolation.

Further Resources