A.8.30
Outsourced development
Technological controlsCheckpoints 6Evidence 7Cases 7
Control objective
This control ensures that when all or part of system development is outsourced to external personnel or suppliers, the organization's security requirements are applied throughout the development process and their fulfillment is continuously directed, monitored, and verified. Because outsourcing shifts control over source code, data, and infrastructure to an external party and moves security activities outside the organization's direct oversight, the control requires clear requirements from the contract stage and verification steps up to acceptance, in order to reduce the risk of vulnerabilities being introduced, malicious functionality being inserted, and intellectual property or data being leaked. The goal is to achieve the same level of security in outsourced deliverables as in in-house development.
Key checkpoints
- Do outsourced development contracts/requests for proposal (RFP) specify security requirements (secure coding, testing, deliverables, intellectual property, data handling, right to audit, and so on)?
- Are the supplier's secure development capability and security management maturity assessed before contracting and reflected in the selection criteria?
- Are there procedures and deliverable submission requirements that let the organization check/oversee fulfillment of its security requirements during development?
- Is security verification (security testing, vulnerability assessment, source code review, malware/backdoor checks) performed before accepting deliverables, and are the results reflected in acceptance approval?
- Are controls defined for provided/generated source, data, privileges, and environments, including return/disposal of assets/data and access revocation at termination?
- Are source code ownership/escrow, licensing, restrictions on sub-contracting (secondary outsourcing), and maintenance/warranty responsibility stipulated in the contract?
Implementation guidance
- Include in the outsourced development contract and RFP, in specific terms, the security requirements, the secure development standards/secure coding rules to comply with, the deliverable list, acceptance criteria, right to audit, and sanctions for violations.
- Assess secure development capability, personnel security, past track record, and sub-contract management ability when selecting a supplier, and stipulate that sub-contracting requires prior approval and inherits equivalent security obligations.
- Minimize production data provided for development, replacing it with pseudonymized/anonymized or test data, and grant least-privilege access to source code/development environment/documentation with access logging.
- Direct and oversee requirement fulfillment through phase-based security checks (design review, interim deliverable review, sharing of security test results) and regular reporting.
- Before acceptance, use code/component analysis and security tests suited to deliverables and risk to check vulnerabilities, malicious functionality, and hardcoded secrets. Remediate/retest blocking findings; approve permissible exceptions with accountable risk acceptance, compensating controls, and deadlines.
- Stipulate intellectual property ownership, source code escrow, license compliance, maintenance and warranty responsibility, and notification/joint-response duties in the event of a security incident.
- At termination, verify return or deletion of provided/generated assets and data with evidence, and revoke access at the defined termination time. Manage legally required retained records separately by basis, scope, use restrictions, and final deletion timing.
Evidence
- Outsourced development contracts/RFP and security requirement specifications (including secure coding, acceptance criteria, right to audit, sub-contracting clauses)
- Supplier security capability assessment and selection review records
- Phase-based security check/oversight records and progress reports
- Acceptance-stage security testing/vulnerability assessment/source code review/malware check reports and defect remediation records
- Acceptance approval records and deliverable lists
- Source code escrow agreements and license/intellectual property documents
- Termination records confirming asset/data return or disposal and access revocation
Nonconformity examples
- The outsourced development contract lacks security requirements and acceptance criteria, so deliverables are accepted with a lower level of security than in-house development.
- No security testing/vulnerability assessment is performed before acceptance, so vulnerabilities or hardcoded credentials are carried into production.
- Production data is supplied for outsourced development without verifying need, lawful basis, approval, minimization, and safeguards, exposing personal/confidential information.
- The contract has no restriction on sub-contracting, so a secondary supplier the organization was unaware of processes the source code.
- Source code/development environment access privileges granted to the supplier are not revoked and remain after the contract ends.
- Source code ownership/escrow and maintenance responsibility are not stipulated in the contract, making maintenance impossible when the supplier withdraws.
- There is no right to audit/inspection over the development process, so requirement fulfillment cannot be verified.