ISO 27001 Annex A 8.30: how to govern outsourced development

The enterprise questionnaire asks who builds your software and how you verify it. Your answer is an agency in another time zone and a contract signed two years ago. ISO 27001 Annex A 8.30 is the control that decides whether that answer survives scrutiny.

This guide is for CTOs, heads of engineering and security leads at 25 to 250-person firms that use agencies, offshore teams or freelancers. It covers what the control asks, the contract schedule, the checks before sign-off, and how to automate supplier oversight. Done that way, the audit evidence builds itself.

What does ISO 27001 outsourced development require under Annex A 8.30?

ISO 27001 Annex A outsourced development control 8.30 makes you accountable for software that agencies, offshore teams and freelancers build for you. You must set security expectations in the contract, monitor the work while it is in flight, and verify the deliverable before production. Certification scope does not shrink when someone else writes the code.

Responsibility can't be subcontracted. Only the typing can.

Any bespoke code written for you counts, from a large agency to a single freelancer. The standard sketches what steering that work covers, and five questions frame it:

• Ownership: who owns the code and its intellectual property?
• Practice: which secure build and test practices must the supplier follow?
• Inspection: can you look at how they build?
• Proof: what evidence of testing arrives with the delivery?
• Failure: what happens to the source if the supplier folds?

Reviewers know outsourced code is a supply-chain door into your product, so "we trust the agency" stalls deals. The failures also outlast the project. A backdoor or injectable flaw shipped by a supplier becomes your breach and your regulatory exposure.

At audit, a firm that outsources development must show security terms in the contract and proof that it checked what was delivered. The rest of this guide builds both without adding red tape.

What changed in ISO 27001:2022 Annex A 8.30 outsourced development?

The 2022 revision carries the 2013 control A.14.2.7 forward as Annex A 8.30 under the technological controls domain. The core duty is unchanged: outsourced software stays your responsibility. The control covers confidentiality, integrity and availability alike, because outsourced code can leak data, ship tampered logic or fail in production.

If you certified against the 2013 edition, your A.14.2.7 evidence is the starting point. Contracts, oversight records and acceptance tests carry across, so the work is re-mapping and tightening rather than building from nothing.

The control works on both sides of delivery:

• Prevention: contract terms, milestone reviews and checks before sign-off stop insecure or malicious code reaching production.
• Recovery: a remediation service level gives you a route to fix the flaws testing finds. Escrow keeps the source alive if a supplier goes under.

The evidence splits the same way the work does. Engineering holds the build records: reviews, scans and acceptance tests. Whoever owns supplier contracts holds the schedule and the due diligence file.

How does ISO 27001 Annex A 8.30 differ from A.5.19 and the secure development controls?

A.5.19 governs supplier relationships in general; A.8.30 zooms in on the software artefact being built for you and the engineering practices behind it. You need both, and they share evidence. A.8.25 to A.8.29 define the lifecycle and testing discipline your contract should point suppliers at.

Evidence overlaps by design. The due diligence file and contract baseline that serve A.5.19 also open the A.8.30 trail. You build the supplier-management process once and add software checks on top.

Three of the secure development siblings do most of the work:

• A.8.25 secure development life cycle: the stages the supplier's process should follow.
• A.8.28 secure coding: the practices their developers apply.
• A.8.29 security testing in development and acceptance: the discipline behind your acceptance gate.

Those controls need to exist in your own practice first. A contract cannot point a supplier at standards you have not defined.

A shared vocabulary helps when the supplier is not ISO-minded. The NIST SP 800-218 Secure Software Development Framework overview gives producers and acquirers a common language for describing secure development practices. You can then set requirements and judge supplier risk in terms both sides recognise.

Which contract clauses does outsourced development need before work starts?

The MSA or statement of work should name the coding standard the supplier builds to, with the OWASP Top 10 as the practical reference. It should require security testing of what they deliver and set a remediation service level. It should also settle IP and open-source licensing, reserve your right to audit, and bind sub-contractors to the same baseline.

The NCSC Supply Chain Security: Establish Control guidance makes the underlying point: suppliers must understand their responsibility to protect your information and what follows if they fail. A security schedule is where that understanding becomes enforceable. Each clause needs a specific wording to be testable:

• Coding standard: name the version, such as the current OWASP Top 10, and require the supplier to build against it.
• Security testing: state which testing (SAST, DAST, dependency checks) runs and who delivers the reports.
• Remediation service level: set fix times by severity, so a finding has a clock attached.
• IP and licensing: state ownership of the code explicitly and set which open-source licences are acceptable.
• Right to audit: reserve the right to inspect their development process. The NCSC Supply Chain Security: Check Your Arrangements guidance adds that you should exercise it and require suppliers to do the same with their own contracts.
• Sub-contractors: flow every term down, so a freelancer hired by your agency carries the same baseline.

Do proportionate due diligence before onboarding. A security questionnaire plus whatever independent assurance the supplier holds, such as ISO 27001 or SOC 2, is enough for most engagements. File it, because auditors ask for the pre-engagement risk assessment.

Hand over context as well as requirements. Share the threat model for what the supplier is building, and your secure design rules on input validation, error handling and cryptography. That way your security intent survives the handover.

The contract schedule and due diligence are about a week's work, and they must precede the engagement. Retro-fitting clauses mid-project is a negotiation; writing them in up front is a template.

The common failure is trusting the supplier's good name instead of paper. A contract with no named standard, no audit right and no independent checks reduces the control to hope. Every silent clause comes back later as a dispute or a due-diligence finding.

Why do source code escrow and IP terms matter for outsourced development?

Escrow and IP terms decide whether you can keep running and legally own your product if a supplier fails or a dispute starts. They are continuity and licensing controls, not legal boilerplate. For a system you could not rebuild quickly, agree source code escrow, and settle ownership and open-source licence terms before work begins.

Three scenarios show what these terms prevent:

• Unclear ownership: a dispute over who owns your own product, raised at the worst moment.
• A copyleft dependency: a GPL library pulled into the codebase and discovered by an acquirer's or customer's due diligence.
• Supplier failure: a two-person agency folds and nobody can maintain a revenue-critical system.

Escrow is proportionate, not universal. A bespoke tool you could replace in a sprint does not justify it, but a business-critical platform built by a tiny agency does. Agree what is deposited, what triggers release, and have someone check the deposit actually builds.

Do you need a standalone procedure or a secure development policy section?

At 25 to 250 people, a section in your secure development policy usually carries outsourced development, and a dedicated procedure is over-engineering. Name an internal owner for the supplier who knows the monitoring is theirs. A standalone procedure is enterprise apparatus you can grow into if outsourcing becomes central to the product.

The policy section stays short. It needs to say:

• which coding and testing standards apply to external developers;
• what the contract schedule must contain;
• which verification gates precede acceptance;
• how supplier access is granted and revoked.

Pick the person who deals with the supplier day to day. That is usually the head of engineering or a product owner. Write their name into the policy and the supplier register, because auditors ask who does the monitoring and "the team" is not a name.

Outgrow the section when outsourcing stops being occasional: several suppliers, or most of a product built externally. Until then, one clear page beats a procedure nobody reads.

How do verification gates and milestone reviews stop the end-of-project dump?

Review at milestones, not just on delivery day: supplier scan reports and spot code reviews while problems are cheap. Then gate acceptance on verification: UAT in an isolated staging environment, a check for known vulnerabilities and malicious content, and for sensitive work an independent penetration test. Sign-off is a recorded decision.

A single acceptance gate after months of unmonitored build is a deadline, not a control.

In-flight review is light by design. At each milestone, collect the supplier's scan reports, spot-check a sample of the code and review the design against your security expectations. That weaves checks into delivery rather than running a separate inspection regime.

Acceptance then follows a fixed sequence:

1. Run UAT in an isolated staging environment, never against production data.
2. Check for known vulnerabilities in the delivered code and its dependencies.
3. Check for malicious content and licence problems, so backdoors and copyleft dependencies are found before payment, not after.
4. Commission an independent penetration test where the system is sensitive.
5. Record the decision with the evidence attached, not an email thread petering out.

Write the failure condition into the statement of work, such as no unresolved critical findings at acceptance. A gate that cannot say no is a formality.

The table compares the verification methods by what each catches, how often it runs and the evidence it leaves.

How do you automate supplier oversight and offboarding?

Land supplier code in repositories you control. Run SAST, DAST and dependency and licence scans on every merge, and let the pipeline decide. Turn each contractual milestone into a ticket that closes only with the scan report attached. Provision supplier access through your identity provider, time-boxed and role-scoped, so project close triggers revocation automatically.

The pipeline replaces promises with reports. Each rail leaves its own evidence:

• Repositories: conformance to the contracted standard becomes a per-delivery report that nobody has to compile. If the supplier worked elsewhere, migrate the code into your repositories at close.
• Tickets: the milestone ticket holds the scan report and review notes, so the oversight trail the auditor asks for assembles itself.
• Access: external developers get least-privilege roles with MFA, scoped to the engagement. The de-provisioning log is your offboarding proof, covering credentials, keys and tokens.
• Register: due diligence renewals, certificate expiry dates and escrow checks live as tracked records with owners and reminders. They are not a spreadsheet reviewed once a year under duress.

Credentials left live after the project closes are an audit finding with a login.

Standing supplier access with no MFA, no scoping and no end date is the classic finding when an auditor pulls the access list. Tying removal to project close, not to someone's memory, takes that finding off the table.

At this scale, one engineer can maintain these rails. The same trail satisfies the certification body and the enterprise customer's security review, without a single extra meeting with the supplier.

How do auditors test ISO 27001 Annex A 8.30 in practice?

Outsourced development ISO 27001 audits trace one live engagement end to end: the contract security schedule, due diligence file, milestone oversight, acceptance records and supplier access. The auditor then cross-checks the contract against what the delivery team describes. No contractual security requirements and no verification of deliverables grades major; single gaps grade minor.

Expect questions like these in the room. Each one is answered by a record from the earlier sections:

• "Show me the security requirements in your agency's contract." The contract security schedule.
• "What checks did you run on this supplier before engaging them?" The due diligence file and risk assessment.
• "Walk me through the acceptance evidence for last quarter's delivery." The milestone tickets with scan reports, the UAT sign-off and any penetration test report.
• "Who at the supplier can reach your environments today, and who reviewed that access?" The access list from your identity provider and the de-provisioning log.
• "If this agency went out of business tomorrow, what happens to the source code?" Code in your own repositories, plus any escrow agreement.

Typical single gaps are a missing due diligence record, a skipped milestone review, or supplier credentials left active after close. Certification bodies usually grade each one minor, but a pattern of them adds up to a major.

Built this way, the trail is the audit file. The sample becomes a walk through records, not a search for them.

Frequently asked questions