Outsourced Development Security Requirements: [Organization name]
Defines the security requirements that apply when a third party
designs, builds, tests or maintains software or systems for
[Organization name]: tiering of engagements, contract requirements,
secure development obligations, code ownership and escrow, access to
environments, testing and acceptance, monitoring, incidents,
subcontracting and offboarding. Supports ISO/IEC 27001:2022 + Amd
1:2024 Annex A control A.8.30 (outsourced development), with A.5.19 to
A.5.22, A.5.32 and A.8.4, guided by ISO/IEC 27002:2022 and the ISO/IEC
27036 series. Replace every [bracketed] value and every row marked
Example. This is a documentation format, not legal advice.
Document control
| Field | Value |
|---|
| Document ID | DOC-ISMS-077 |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@head-of-engineering] |
| Approvers/reviewers | [@isms-manager], [@legal-counsel], [@procurement-lead] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024 (A.8.30, A.5.19 to A.5.22, A.5.32, A.8.4); ISO/IEC 27002:2022; ISO/IEC 27036-2:2022 |
| Next scheduled review | YYYY-MM-DD (12 months, or at a trigger in section 15) |
| Applies to | [All contracts under which a third party writes, changes, tests or maintains code or configuration for in-scope systems] |
| Parent policy | DOC-ISMS-065 Secure development policy |
Approvals
| Role | Name | Decision | Date |
|---|
| Owner | [@head-of-engineering] | [Prepared] | YYYY-MM-DD |
| ISMS manager | [@isms-manager] | [Reviewed] | YYYY-MM-DD |
| Legal | [@legal-counsel] | [Reviewed] | YYYY-MM-DD |
| Top management | [@cto] | [Approved] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change |
|---|
| 0.1 | YYYY-MM-DD | [@author] | First draft |
| 1.0 | YYYY-MM-DD | [@author] | Approved for issue |
| [x.y] | YYYY-MM-DD | [@author] | [Change summary] |
Contents
1. Purpose and scope
These requirements make sure that software and configuration produced by
third parties meet the same security level as work produced internally
under DOC-ISMS-065, and that [Organization name] keeps control over
its code, data, environments and the ability to continue without the
supplier.
| Item | Value |
|---|
| Covered | [Custom software, mobile apps, integrations, infrastructure as code, data pipelines, low-code builds, customisations of purchased platforms, maintenance and support that changes code] |
| Not covered | [Purchased software used unchanged, covered by supplier assessment DOC-ISMS-067; staff augmentation contractors who work as employees under internal rules, covered by HR controls and DOC-ISMS-065] |
| Decision owner | [Head of engineering with procurement] |
| Register | Every engagement appears in the supplier register DOC-ISMS-066 with the tag "development" |
2. Engagement types and tiering
| Tier | Criteria (any one applies) | Examples (Example) |
|---|
| ODS Tier 1 (critical) | Supplier builds or maintains components that handle authentication, payments, personal or regulated data at scale, or has access to production | Core platform module, mobile banking app, clinical integration |
| ODS Tier 2 (significant) | Supplier builds components that process scoped data but has no production access | Reporting module, internal workflow tool, data pipeline in staging |
| ODS Tier 3 (limited) | No scoped data, no access to internal networks or production | Marketing website on separate hosting, prototype with synthetic data |
| Requirement set | Tier 1 | Tier 2 | Tier 3 |
|---|
| Supplier security assessment (DOC-ISMS-067) | Full, with evidence | Standard questionnaire | Short form |
| Contract requirements (section 4) | All | ODS-REQ-001 to ODS-REQ-014 | ODS-REQ-001 to ODS-REQ-006 |
| Acceptance testing (section 8) | Full, including independent penetration test | Full, pentest risk-based | Functional and dependency scan |
| Monitoring (section 9) | Quarterly review, annual audit right exercised by risk | Semi-annual review | At delivery |
| Escrow or equivalent (section 6) | Required unless code is in our repositories | Considered | Not required |
3. Engagement life cycle
| Step | Owner | Key output |
|---|
| 1. Need and tier | Requesting manager, head of engineering | Tier recorded in DOC-ISMS-066 |
| 2. Due diligence | ISMS manager | Supplier assessment DOC-ISMS-067 |
| 3. Contract | Procurement, legal | Signed contract with requirement IDs attached, DOC-ISMS-068 where used |
| 4. Onboarding | Platform lead | Named accounts, access list, security briefing record |
| 5. Development | Engineering lead | Merge requests, progress reviews |
| 6. Acceptance | QA and application security | Acceptance report |
| 7. Release | Release manager | Change record |
| 8. Offboarding | Engineering lead, platform lead | Offboarding checklist, handover confirmation |
4. Contract security requirements
| ID | Requirement topic | What the contract must cover |
|---|
| ODS-REQ-001 | Confidentiality | Confidentiality obligations covering code, data, designs and credentials, surviving termination (DOC-ISMS-051) |
| ODS-REQ-002 | Ownership of deliverables | Who owns code, documentation and designs; assignment or licence at payment or creation |
| ODS-REQ-003 | Open-source and third-party components | Disclosure of every component with its licence; no components under licences on our deny list without approval |
| ODS-REQ-004 | Secure development | Compliance with DOC-ISMS-065 and the secure coding standard, or an equivalent the ISMS manager approves |
| ODS-REQ-005 | No malicious code | Warranty against backdoors, hidden functions, time bombs and undisclosed telemetry |
| ODS-REQ-006 | Defect correction | Correction of security defects found during acceptance and warranty at no extra cost, within agreed timeframes |
| ODS-REQ-007 | Personnel | Named personnel, screening appropriate to the role (DOC-ISMS-050), security awareness, notice of changes |
| ODS-REQ-008 | Access and environments | Use of our repositories and environments, named accounts with MFA, no copies of our data outside approved locations |
| ODS-REQ-009 | Data protection | Processing of personal data only on instructions, with a data processing agreement where the supplier processes personal data |
| ODS-REQ-010 | Testing evidence | Delivery of test results, static analysis output and SBOM with each release |
| ODS-REQ-011 | Vulnerability and incident notification | Notification of incidents and vulnerabilities affecting our deliverables within [24] hours of awareness |
| ODS-REQ-012 | Subcontracting | No subcontracting without prior written approval; flow-down of these requirements |
| ODS-REQ-013 | Right to audit | Our right, or that of an independent auditor, to audit or assess the supplier's development practices |
| ODS-REQ-014 | Return and deletion | Return of all code, documentation and data and certified deletion at the end of the engagement |
| ODS-REQ-015 | Escrow or continuity | Source code escrow or equivalent continuity arrangement for code we do not hold |
| ODS-REQ-016 | Location of work | Countries where work and data access take place, with notice of changes |
| ODS-REQ-017 | Regulatory cooperation | Cooperation with our regulators and customers where law or contract requires it |
Regulatory examples that may add contract content: GDPR Article 28
processor terms where personal data is processed; DORA (Regulation (EU)
2022/2554) Article 30 contract provisions for financial entities using
ICT third-party services; the EU Cyber Resilience Act (Regulation (EU)
2024/2847) where the deliverable becomes part of a product with digital
elements placed on the EU market. Record which apply in DOC-ISMS-014.
5. Secure development obligations
The supplier must, for every deliverable:
| ID | Obligation | Evidence expected |
|---|
| ODS-DEV-01 | Develop in repositories owned by [Organization name], or mirror to them at least daily | Repository access log |
| ODS-DEV-02 | Follow the secure coding standard and our review rules; no self-approval of merges | Merge request history |
| ODS-DEV-03 | Run our pipeline gates (static analysis, composition analysis, secret scanning) without bypass | Pipeline results |
| ODS-DEV-04 | Produce or update threat models for Tier 1 features with our security champion | Threat model |
| ODS-DEV-05 | Keep secrets in our secrets manager only (security/secrets-management-standard) | Secret scan results |
| ODS-DEV-06 | Use only approved AI coding assistants under the rules in DOC-ISMS-065 section 12, and disclose their use | Supplier declaration |
| ODS-DEV-07 | Use synthetic or masked data in development and test (DOC-ISMS-062) | Test data log |
| ODS-DEV-08 | Provide documentation sufficient for another team to maintain the code | Handover pack |
| ODS-DEV-09 | Keep developer devices secured (disk encryption, endpoint protection, patched operating system) | Supplier attestation, sample check |
6. Code ownership, licences and escrow
| Topic | Rule |
|---|
| Ownership | Custom code and documentation are owned by [Organization name] or licensed to it on terms recorded in the contract |
| Pre-existing supplier code | Listed in the contract with the licence granted to us, including rights to maintain and modify |
| Open-source components | Listed in the SBOM; licences checked against [the licence policy]; copyleft obligations assessed before acceptance |
| Code location | In our repositories by default (ODS-DEV-01), which removes the need for escrow for that code |
| Escrow | For code the supplier keeps: deposit with an independent escrow agent, updated at each major release, with release conditions (insolvency, end of support, material breach) |
| Escrow verification | Tier 1: verification that the deposit builds, at least [annually] |
| Build reproducibility | Build scripts, dependency lists and environment definitions are part of the deliverable |
7. Personnel and access to environments
| ID | Rule |
|---|
| ODS-ACC-01 | Every supplier person has a named account in our identity provider with MFA; no shared accounts. |
| ODS-ACC-02 | Access is limited to the repositories, environments and tools the engagement needs; production access only for Tier 1 support roles, time-limited and approved. |
| ODS-ACC-03 | Remote access uses our approved method (isms/remote-working-policy, DOC-ISMS-054); no direct database access from supplier networks. |
| ODS-ACC-04 | The supplier informs us of joiners and leavers within [1] working day; leavers lose access the same day. |
| ODS-ACC-05 | Supplier access is reviewed at least [monthly] for Tier 1 and [quarterly] for Tier 2 (ops/access-review). |
| ODS-ACC-06 | Supplier personnel complete our security briefing before access and acknowledge the acceptable use policy (DOC-ISMS-040). |
| ODS-ACC-07 | Supplier activity in repositories and environments is logged and retained for [12] months. |
8. Testing and acceptance
| Acceptance check | Tier 1 | Tier 2 | Tier 3 |
|---|
| All pipeline gates passed (DOC-ISMS-065 section 4.2) | Required | Required | Required |
| Security requirements traced to passing tests | Required | Required | Where defined |
| SBOM delivered and composition scan clean of Critical and High findings | Required | Required | Required |
Independent penetration test (security/pentest-report) | Required before first production release | Risk-based | Not required |
| Code review sample by our engineers | At least [10]% of changed files, all authentication and authorisation code | At least [5]% | Not required |
| Malicious code review (unexpected network calls, obfuscation, hidden accounts) | Required | Required | Recommended |
| Documentation and handover pack complete | Required | Required | Required |
| Licence review of components | Required | Required | Required |
| Outcome | Meaning |
|---|
| Accepted | All criteria met; payment milestone may be released |
| Accepted with conditions | Only Medium or Low findings open, with dates in the tracker |
| Rejected | Critical or High findings, missing evidence or failed tests; supplier corrects at its cost under ODS-REQ-006 |
| Acceptance ID | Deliverable | Result | Open findings |
|---|
| ODS-ACPT-001 (Example) | Patient reminder mobile app 2.0, Quillmere Health Systems | Accepted with conditions | 2 Medium (session timeout, verbose error), due in 30 days |
9. Monitoring and right to audit
| Activity | Frequency | Owner | Record |
|---|
| Delivery and security review meeting | Tier 1 [monthly], Tier 2 [quarterly] | Engineering lead | Minutes with actions |
| Review of pipeline metrics (findings, bypass attempts) | [Monthly] | Application security lead | Metrics report |
| Access review | Per ODS-ACC-05 | Platform lead | Access review record |
| Reassessment of the supplier | Tier 1 [annually], Tier 2 every [2] years | ISMS manager | Updated DOC-ISMS-067 |
| Audit or on-site assessment | By risk, Tier 1 at least once per contract term | ISMS manager | Audit report |
| Review of supplier certificates and reports (scope and validity) | At renewal | ISMS manager | Note on DOC-ISMS-066 |
A supplier ISO/IEC 27001 certificate is useful evidence only when its
scope covers the delivery team and location; check the scope statement
and the certificate's validity in the issuing certification body's
records.
10. Vulnerabilities, incidents and subcontracting
- Security incidents involving our code, data, credentials or the
supplier's development environment are reported to [security contact]
within [24] hours and handled under DOC-ISMS-020.
- Vulnerabilities in deliverables found after acceptance are fixed
within the timeframes in
security/vulnerability-management-policy
during the warranty period, and under the support agreement after it.
- The supplier tells us of vulnerabilities in components it supplied
when it becomes aware of them.
- Subcontractors require our prior written approval, are recorded in
DOC-ISMS-066 and receive the same requirements by flow-down.
- A change of ownership, location of work or key personnel of the
supplier triggers a reassessment.
11. Offboarding and end of engagement
| ID | Step | Owner | Evidence |
|---|
| ODS-OFF-01 | Final code merged to our repositories; no pending branches outside them | Engineering lead | Repository check |
| ODS-OFF-02 | Handover pack delivered and walked through with the receiving team | Engineering lead | Handover sign-off |
| ODS-OFF-03 | All supplier accounts disabled; tokens, keys and certificates revoked or rotated | Platform lead | Access list, rotation log |
| ODS-OFF-04 | Secrets the supplier could see are rotated | Platform lead | Secrets manager log |
| ODS-OFF-05 | Supplier confirms return and deletion of code, data and documentation, including backups and devices | Supplier, procurement | Signed deletion confirmation |
| ODS-OFF-06 | Escrow deposit updated or released as agreed | Legal | Escrow record |
| ODS-OFF-07 | Supplier register updated and lessons recorded | ISMS manager | DOC-ISMS-066 entry |
Personnel-level offboarding steps follow
isms/offboarding-security-checklist (DOC-ISMS-053).
12. Size tiers
| Topic | Small: Quillmere Analytics Ltd (Example) | Medium: Quillmere Health Systems (Example) | Large: Quillmere Group (Example) |
|---|
| Profile | 46 staff (38 employees, 8 contractors); product built in-house | 320 staff; one agency builds the patient reminder mobile app | 2,400 staff, 6 sites in 4 countries; suppliers build plant systems, portals and integrations |
| Current use | No outsourced development; the 8 contractors work as team members under internal rules; SoA records A.8.30 as not applicable with that reason (or keeps it applicable with no current engagement; agree the approach with your auditor) | One Tier 1 engagement (mobile app) and one Tier 3 (marketing site) | 23 development suppliers (Example): 5 Tier 1, 11 Tier 2, 7 Tier 3 |
| Contracting | Template kept ready; CTO and ISMS manager approve any first engagement | Legal schedule with ODS-REQ IDs; DOC-ISMS-068 for the agency | Group procurement standard schedule; local legal review per country |
| Acceptance | Not applicable today | Our QA plus an independent pentest before each major release | Central application security service performs acceptance for Tier 1 |
| Monitoring | Not applicable today | Monthly review with the agency | Supplier management office runs quarterly reviews and an annual audit plan |
| Escrow | Not applicable | Not needed: code in our repositories | Escrow for 2 licensed OT software products (Example) with annual build verification |
The large-tier count adds up: 5 + 11 + 7 = 23 suppliers.
13. Records and evidence
| Record | Proves | Owner | Location | Retention (Example) |
|---|
| Supplier register entry with tier | A.5.19, A.8.30 | ISMS manager | DOC-ISMS-066 | Life of relationship + 6 years |
| Supplier security assessment | A.5.19 | ISMS manager | DOC-ISMS-067 | Life of relationship + 6 years |
| Signed contract with security schedule | A.5.20, A.8.30, A.5.32 | Legal | [Contract repository] | Contract term + 6 years |
| Access lists and access reviews | A.8.4, A.5.15 | Platform lead | [IAM, review records] | 3 years |
| Merge requests and pipeline results | A.8.28, A.8.30 | Engineering lead | [Repository host] | Life of the repository |
| Acceptance reports and pentest reports | A.8.29, A.8.30 | QA lead | [Document store] | 3 years after end of engagement |
| Review meeting minutes and audit reports | A.5.22 | Engineering lead | [Document store] | 3 years |
| Incident notifications | A.5.24 | Security team | DOC-ISMS-021 | Per incident register |
| Offboarding checklist and deletion confirmation | A.5.20, A.8.30 | Procurement | [Contract repository] | 6 years |
| Escrow agreement and verification reports | A.8.30 | Legal | [Contract repository] | Contract term + 6 years |
14. References
| Reference | Edition and status (checked 2026-11-01) | Use |
|---|
| ISO/IEC 27001:2022 + Amd 1:2024 | Current; https://www.iso.org/standard/82875.html, Amd 1 https://www.iso.org/standard/88435.html | A.8.30, A.5.19 to A.5.22, A.5.32, A.8.4 |
| ISO/IEC 27002:2022 | Current; https://www.iso.org/standard/75652.html | Control guidance |
| ISO/IEC 27036-2:2022 | Current; https://www.iso.org/standard/82060.html | Supplier relationship requirements |
| ISO/IEC 27036-3:2023 | Current; https://www.iso.org/standard/82890.html | Hardware, software and services supply chain |
| NIST SP 800-218, SSDF version 1.1 | Final, February 2022, https://csrc.nist.gov/pubs/sp/800/218/final; Rev. 1 (SSDF version 1.2) is a draft from December 2025: check whether it is final | Practices to ask suppliers to follow |
| DORA, Regulation (EU) 2022/2554 | Applies from 17 January 2025; https://eur-lex.europa.eu/eli/reg/2022/2554/oj | Example: contract provisions for ICT third-party services |
| EU Cyber Resilience Act, Regulation (EU) 2024/2847 | In force since December 2024; manufacturers' vulnerability and incident reporting applies from 11 September 2026 and most other obligations from 11 December 2027; check the official text | Example: product security obligations |
Related templates: isms/secure-development-policy,
isms/supplier-register, compliance/supplier-security-assessment,
isms/supplier-security-agreement-27036, security/secure-coding-standard,
security/supply-chain-security, isms/offboarding-security-checklist,
isms/control-evidence-matrix.
15. Review triggers
Review these requirements every [12] months and when: a new type of
development engagement starts, a supplier incident affects us, a law or
customer contract adds supplier requirements, DOC-ISMS-065 changes, or an
internal or certification audit raises a finding on supplier controls.
Standard and licence note
Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 Annex A control
A.8.30 and related supplier controls A.5.19 to A.5.22, A.5.32 and A.8.4,
with ISO/IEC 27002:2022 and ISO/IEC 27036-2:2022 and 27036-3:2023 as
guidance. The text, requirement IDs and examples are original. Control
numbers are cited with short descriptive labels; no ISO/IEC text is
reproduced, and you need the official standards to implement the
controls. Regulations are cited as international examples only; this is
a documentation format, not legal advice. Check the current editions and
legal texts before use. Template licence: MIT.