# 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.

<!--
Guidance: How to use this template
- Use it before you sign with a development agency, freelancer,
  nearshore or offshore team, or a vendor building a custom module for
  you. Use it again at each renewal and at the end of the engagement.
- Fill first: section 2 (tier the engagement), section 4 (the
  requirement set you will attach to the contract) and section 8
  (acceptance criteria). These three decide most of the risk.
- Main pitfall: relying on the supplier's own testing and their
  certificate. A.8.30 keeps you responsible for overseeing the
  outsourced work; acceptance testing by you is the evidence.
- Have legal counsel review clauses before use. The wording here is a
  checklist of what to cover, not contract language.
- Related templates: `isms/secure-development-policy` (DOC-ISMS-065),
  `isms/supplier-register` (DOC-ISMS-066),
  `compliance/supplier-security-assessment` (DOC-ISMS-067),
  `isms/supplier-security-agreement-27036` (DOC-ISMS-068),
  `security/secure-coding-standard`, `security/supply-chain-security`,
  `isms/offboarding-security-checklist`, `isms/control-evidence-matrix`.
-->

## Document control

<!-- Guidance: Keep one master copy of these requirements, and record per engagement which tier and which requirement IDs were attached to the contract (section 13). -->

| 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](#1-purpose-and-scope)
- [2. Engagement types and tiering](#2-engagement-types-and-tiering)
- [3. Engagement life cycle](#3-engagement-life-cycle)
- [4. Contract security requirements](#4-contract-security-requirements)
- [5. Secure development obligations](#5-secure-development-obligations)
- [6. Code ownership, licences and escrow](#6-code-ownership-licences-and-escrow)
- [7. Personnel and access to environments](#7-personnel-and-access-to-environments)
- [8. Testing and acceptance](#8-testing-and-acceptance)
- [9. Monitoring and right to audit](#9-monitoring-and-right-to-audit)
- [10. Vulnerabilities, incidents and subcontracting](#10-vulnerabilities-incidents-and-subcontracting)
- [11. Offboarding and end of engagement](#11-offboarding-and-end-of-engagement)
- [12. Size tiers](#12-size-tiers)
- [13. Records and evidence](#13-records-and-evidence)
- [14. References](#14-references)
- [15. Review triggers](#15-review-triggers)
- [Standard and licence note](#standard-and-licence-note)

## 1. Purpose and scope

<!-- Guidance: State which arrangements count as outsourced development. Auditors often find a freelancer on a purchase order, or a SaaS vendor building a paid customisation, that nobody treated as development. Questions: who decides that an engagement falls under this document, and where is that recorded? -->

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

<!-- Guidance: Tiering keeps the effort proportional. A one-week landing page and a core payment module need different requirements. Record the tier on the supplier register entry. Pitfall: tiering on contract value instead of on the data and systems the supplier will touch. -->

| 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

<!-- Guidance: Show the end-to-end flow so procurement, engineering and legal know when each check happens. The auditor will pick one supplier and follow it through these steps. -->

```mermaid
flowchart TD
  A["1. Need identified and tier assigned"] --> B["2. Supplier due diligence (DOC-ISMS-067)"]
  B --> C{"Risk acceptable?"}
  C -->|"No"| X["Reject or require remediation"]
  C -->|"Yes"| D["3. Contract with security requirements"]
  D --> E["4. Onboarding: accounts, repositories, briefing"]
  E --> F["5. Development under monitoring"]
  F --> G["6. Testing and acceptance by us"]
  G -->|"Fails"| F
  G -->|"Passes"| H["7. Release and warranty period"]
  H --> I["8. Offboarding and handover"]
```

| 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

<!-- Guidance: Under A.5.20, a security expectation that is not in the signed contract is hard to enforce later; A.8.30 adds the points specific to building software. Attach this table (or the IDs that apply) as a contract schedule and keep the signed version. Legal counsel turns each line into contract wording. -->

| 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

<!-- Guidance: Spell out what the supplier must do day to day. Ask for evidence that the practices run, not for a description. If the supplier uses its own method, map it to these obligations in the assessment. -->

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

<!-- Guidance: A.5.32 covers intellectual property rights. Decide ownership before the first commit. Escrow matters when the supplier keeps the code (a licensed product with customisation); it matters less when code lives in your repositories from day one. Pitfall: escrow deposits that are never verified and cannot be built. -->

| 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

<!-- Guidance: A.8.4 covers access to source code; A.5.19 covers supplier access to your assets. Give suppliers the least access needed, through named accounts you control, and review it often. The auditor will compare the access list with the active supplier staff list. -->

| 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

<!-- Guidance: A.8.30 expects acceptance testing of outsourced work, including security. Define the criteria before work starts so they can be enforced. Do the acceptance yourself or through an independent tester; do not accept the supplier's report alone for Tier 1. -->

| 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 |

Acceptance outcome:

| 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

<!-- Guidance: A.5.22 matters because a supplier that was sound at signing can drift, change staff or change its own suppliers. Plan the reviews and keep minutes. Exercise the audit right by risk, at least for Tier 1 suppliers. -->

| 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

<!-- Guidance: Agree what the supplier does when it finds or causes a problem. Link to your incident response plan so the supplier knows the reporting route and timeframes. -->

- 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

<!-- Guidance: Most outsourced-development findings appear at the end: accounts left active, code copies on supplier laptops, missing documentation. Use a checklist and keep it signed. -->

| 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

<!-- Guidance: Show how the requirements scale. A small company may outsource nothing; a large group may run dozens of suppliers per site. If nothing is outsourced, keep this document as the rule for when it happens and record A.8.30 status in the SoA. -->

| 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

<!-- Guidance: Name the records that prove the requirements operate, for each engagement. Link the record types in the control evidence matrix (`isms/control-evidence-matrix`, DOC-ISMS-033). -->

| 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

<!-- Guidance: Cite only editions you checked; legal references are examples for an international audience, not a complete list for any country. -->

| 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

<!-- Guidance: Review on a fixed cycle and when the supplier landscape changes. -->

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.