Zum Hauptinhalt springen
CENEDRIL WIKI
DE
Annex A · Technological Control

A.8.30 — Outsourced Development

Updated on 4 min Reviewed by: Cenedril Editorial
A.8.30 ISO 27001ISO 27002BSI OPS.2.3

A software development agency delivers a customer portal on time and within budget. Post-launch, a security audit reveals hardcoded credentials, missing input validation and a dependency on a library with a known critical vulnerability. The contract says nothing about security standards, and the agency has moved on to other projects. A.8.30 ensures that outsourced development meets your security standards — through clear requirements, contractual controls and verification.

When you outsource development, you delegate the work — you do not delegate the accountability. This control requires organizations to communicate security requirements, monitor compliance and verify results throughout the engagement.

What does the standard require?

  • Communicate security requirements. Clearly define and agree security standards with the external developer before work begins.
  • Include security in contracts. Contracts must specify secure coding practices, testing obligations, audit rights, IP ownership and incident notification.
  • Monitor and review. Regularly assess the external developer’s work for compliance with security requirements.
  • Conduct acceptance testing. Perform security testing on delivered code before deploying it.
  • Arrange code escrow. Where appropriate, establish code escrow agreements to protect against supplier failure.

In practice

Define security requirements in the contract. Specify: secure coding standards to follow, minimum security testing requirements (SAST, DAST), dependency management obligations, vulnerability disclosure timelines and your right to conduct independent security assessments.

Conduct incoming security reviews. Scan every code delivery with SAST and SCA tools. For high-risk components, commission manual security reviews. Reject deliveries that fail security acceptance criteria.

Require evidence of secure practices. Ask suppliers to provide: SAST scan results, dependency audit reports, evidence of code review and developer security training records. Verify these claims through your own testing.

Maintain ongoing oversight. For long-term engagements, conduct periodic security assessments of the supplier’s development practices. Review their incident response capability and verify they are maintaining the agreed security standards.

Typical audit evidence

Auditors typically expect the following evidence for A.8.30:

  • Contracts with security clauses — documented security requirements in supplier agreements (see Secure Software Development Policy in the Starter Kit)
  • Security acceptance test results — SAST/SCA scans of delivered code
  • Supplier assessment records — periodic evaluations of supplier security practices
  • Code escrow agreements — where applicable
  • Incident notification records — evidence that suppliers report security issues

KPI

Percentage of outsourced development contracts with enforced security requirements

Measured as a percentage: how many of your outsourced development contracts include security requirements that are actively verified? Target: 100%.

Supplementary KPIs:

  • Percentage of code deliveries that pass incoming security review on first submission
  • Number of security findings in outsourced vs. in-house code (comparison)
  • Percentage of suppliers with verified secure development practices

BSI IT-Grundschutz

A.8.30 maps to BSI modules for outsourcing and supplier management:

  • OPS.2.3 (Use of External IT Services) — security requirements for outsourced IT services, including development.
  • APP.7 (Development of Individual Software) — requirements applicable to externally developed custom software.

Sources

Frequently asked questions

What should the contract include?

Secure coding requirements, security testing obligations, IP ownership, code escrow, audit rights, incident notification timelines, data handling at contract end, compliance with your security policies and the right to conduct independent security assessments.

Should we review outsourced code for security?

Yes. Trust but verify. Conduct your own security review (automated SAST scan at minimum, manual review for high-risk components) of delivered code. You are accountable for the security of systems you deploy, regardless of who wrote the code.

What about offshore development teams?

The same requirements apply. Additional considerations: data protection regulations for code and test data transferred across borders, secure communication channels and time zone management for incident response.