How to Keep Security Under Control When Someone Else Is Writing the Code
When you outsource development, you don’t outsource responsibility.
ISO 27001 Control 8.30 Outsourced development is about making sure that systems built by third parties are still designed, coded and tested to your information security standards – not just whatever your supplier happens to provide.
This control expects you to:
- Set clear security expectations up front
- Bake those expectations into contracts and ways of working
- Monitor and review what suppliers actually do in practice
- Protect your organisation if something goes wrong (security-wise or commercially)
Think of it as extending your secure development life cycle (8.25–8.29) into someone else’s building.
What ISO 27001 Control 8.30 Actually Expects
In plain English, ISO 27001 Control 8.30 – Outsourced development wants you to:
- Treat outsourced development as part of your supply chain risk
- Make sure contracts and SOWs include security and privacy requirements, not just features and deadlines
- Get evidence that secure design, coding and testing actually happen
- Check for malicious or vulnerable code in what you receive
- Protect your position with IP, licensing and escrow
- Retain the ability to assess and audit how development is being done
If an auditor asked, “How do you know your suppliers are building secure systems?”, you should be able to answer with more than “they’re reputable”.
Step 1 – Start with IP, Licensing and Ownership
Before you get into security details, you need to be clear on who owns what.
Make sure your outsourced development agreements:
- Define IP ownership clearly
- Who owns the source code, documentation, designs and build pipelines?
- Can the supplier re-use components for other clients?
- Clarify licensing and usage rights
- Can you modify the code yourself or with another supplier?
- Are there any third-party licences embedded in the solution (libraries, components) that you need to respect?
- Cover liability for IP issues
- Warranties that the supplier isn’t copying someone else’s code unlawfully.
- Indemnities in case an IP claim arises later.
From a security point of view, this links directly to continuity (if the relationship ends, you can still maintain and secure the system).
Step 2 – Put Secure Development Requirements into the Contract
Next, bring in your secure development expectations. Don’t leave them implied.
Contracts and statements of work should:
- Reference your secure development life cycle (and ISO 27001 Controls 8.25–8.29)
- Require adherence to secure coding standards (e.g. OWASP guidelines, language-specific standards)
- State expectations for:
- Secure design and architecture
- Secure coding practices
- Security testing (SAST, DAST, SCA, penetration tests, etc.)
- Vulnerability management and patching
Also include:
- Non-compliance consequences
- What happens if agreed security practices aren’t followed?
- How quickly must security defects be fixed?
- Who pays if a breach is linked to poor development practices?
This is how you make security contractually enforceable, not just “nice to have”.
Step 3 – Align on Threat Modelling and Security Risks
Suppliers need to understand what you’re worried about.
Build threat modelling into your outsourced development approach:
- Share your threat models and risk assumptions for the system
- Key assets and data
- Likely attackers and threats
- Key misuse and abuse cases
- Require the supplier to:
- Perform their own threat modelling for the solution
- Document security assumptions and mitigations
- Discuss changes if the design evolves
- Have your internal security team review and challenge supplier threat models
- Check that important risks are understood and sensibly treated.
This keeps everyone working from the same risk picture, rather than just hoping they “design it sensibly”.
Step 4 – Define Security Acceptance Testing, Not Just Functional Testing
ISO 27001 Control 8.29 covers security testing; 8.30 simply ensures that outsourced work follows the same rules.
Your acceptance criteria should include:
- Security test coverage
- Static analysis (SAST) and dependency scanning (SCA)
- Dynamic testing (DAST) for web and API components
- Penetration testing for higher-risk systems
- Security regression tests for future releases
- Clear security acceptance thresholds
- No critical or high vulnerabilities at go-live, or risk-accepted at the right level
- Medium/low issues tracked with agreed remediation timelines
- Evidence from the supplier
- Test plans and results
- Details of tools used and configurations
- Confirmation of fixes for previously identified issues
You can then perform independent testing (internal or external) before you sign off, especially for important systems.
Step 5 – Ask for Security and Privacy Assurance Evidence
You don’t have to take everything on trust.
Where appropriate, require suppliers to provide:
- Security certifications
- e.g. ISO 27001, SOC 2 reports, or similar independent attestations.
- Privacy compliance evidence
- How they handle personal data and support your GDPR or other regulatory obligations.
- Development lifecycle documentation
- How they manage secure coding, change control, testing, and vulnerability management across their projects.
This doesn’t replace your own checks, but it gives you baseline assurance that security is part of their normal way of working.
Step 6 – Test for Malicious and Unintentional Content
Outsourced code can introduce risk unintentionally – or, in worst cases, deliberately.
To reduce this risk:
- Scan delivered code and artefacts
- Use static code analysis tools to spot suspicious or risky constructs.
- Use malware and backdoor detection where appropriate.
- Review privileged and sensitive areas of code
- Authentication and authorisation logic
- Security controls (logging, crypto, key handling)
- Admin interfaces and debug functions
- Require proof of internal security checks
- Supplier’s own SAST/DAST results
- Evidence of code reviews, particularly for sensitive modules
The goal is to ensure there are no hidden surprises – malicious or accidental – in what you deploy.
Step 7 – Ensure Testing Covers Known Vulnerabilities
It’s not enough to say “we’ve tested it”; you want to know what you’ve tested it against.
Ask suppliers to:
- Test explicitly against known vulnerability classes
- e.g. OWASP Top 10 for web apps and APIs.
- Known weaknesses in your tech stack.
- Use vulnerability scanners and composition analysis
- Regularly scan libraries and frameworks against public vulnerability databases.
- Demonstrate a process to update or replace vulnerable components.
- Maintain a vulnerability disclosure process
- How they handle issues reported by third parties.
- How and when you’ll be notified of issues that affect your systems.
This reinforces that security isn’t “one test before go-live” but an ongoing activity throughout the relationship.
Step 8 – Use Source Code Escrow Where It’s Justified
If a system is important and you depend heavily on one supplier, consider source code escrow.
Your escrow arrangement should:
- Cover source code, build scripts and documentation
- Enough detail that another supplier or in-house team could reasonably take over.
- Define trigger events clearly
- Supplier insolvency or ceasing to trade
- Serious, unresolved contract breach
- Extended failure to support or maintain the system
- Describe the handover process
- How the code is released
- How you’ll receive updates if development continues in parallel
From an ISO 27001 perspective, this supports business continuity and risk treatment for outsourced development.
Step 9 – Retain the Right to Audit and Request Evidence
You don’t need to audit every supplier every year, but you should have the right to do so, particularly for high-risk systems.
Contracts should allow you to:
- Audit security practices related to your work
- Development processes, access controls, test results, vulnerability management.
- Request regular reporting
- Security updates, risk assessments, incident notifications and mitigation plans.
- Agree audit scope in advance
- So both parties know what’s in and out of scope, and how frequently checks might occur.
This doesn’t mean you’ll constantly turn up with clipboards – it just ensures you can dig deeper if risk rises or issues appear.
Step 10 – Check Security of the Supplier’s Development Environment
Outsourced development is only as secure as the environment it’s built in.
You should expect suppliers to:
- Use secure development environments
- Access-controlled repositories
- Isolated build and test environments
- Strong authentication and least privilege for developers
- Separate development, test and production
- No direct coding on live systems
- No live data in lower environments unless it’s properly masked or protected.
- Apply configuration management and hardening
- Standardised, secure build images and dependencies
- Patching and vulnerability management as part of BAU
These requirements should be explicit in your contracts or security schedules, not just assumed.
Step 11 – Ensure Legal and Regulatory Compliance
Outsourced development doesn’t dilute your legal obligations.
Make sure:
- Your contracts reflect data protection and privacy requirements
- Data processing agreements where personal data is involved.
- Clear roles: controller vs processor, sub-processor approvals, etc.
- Suppliers acknowledge and support sector-specific requirements
- e.g. PCI DSS for payment systems, healthcare regulations, or local cyber laws.
- Legal teams review agreements for alignment with current regulations
- And there is a process to update terms as regulations evolve.
ISO 27001 Control 8.30 is satisfied when outsourced development doesn’t become a blind spot in your compliance posture.
Continuous Improvement and Ongoing Review
Outsourced development arrangements shouldn’t be “set and forget”.
To keep them secure over time:
- Review supplier performance regularly
- Security incidents, testing results, responsiveness to vulnerabilities, quality of deliverables.
- Refresh threat models and requirements
- As the system evolves, cloud platforms change, or new regulations appear.
- Have contingency plans
- How you’d move work to another supplier or in-house if needed.
- How you’d handle a significant security issue affecting the supplier.
For more structured guidance on supplier risk, ISO points to the ISO/IEC 27036 series, which digs more deeply into managing security in supplier relationships.
Quick Implementation Checklist for ISO 27001 Control 8.30
A simple way to assess your position:
- ISO 27001 Control 8.30 (Outsourced development) is covered in your supplier and development procedures, not just contracts.
- IP ownership, licensing and rights to modify/maintain the code are clearly defined.
- Contracts/SOWs include explicit secure development requirements (design, coding, testing, vulnerability management).
- Threat modelling is shared, and suppliers are expected to document and address security risks in their designs.
- Security acceptance criteria include security testing, not just functional testing, and you see evidence.
- Code and deliverables are checked for malicious or unintended security issues, including known vulnerability classes.
- Source code escrow is in place where outage or supplier failure would be high impact.
- You retain the right to audit, and receive regular security and risk reports from key suppliers.
- Supplier development environments meet basic security expectations (access control, separation of environments, configuration management).
- Legal and regulatory requirements (GDPR, PCI DSS, industry rules) are explicitly reflected in contracts and ways of working.
- There is a regular review cycle to reassess security, performance and risk of outsourced development.
If you treat outsourced development as an extension of your own secure development life cycle – with clear expectations, evidence and oversight – ISO 27001 Control 8.30 becomes far easier to demonstrate, and your real risk from third-party code drops dramatically.
Explore the ISO 27001 Controls