Supplier review
Status: operative document. Version 1.0, 2026-09-18. Owner: Yannick M. Richard. Review cycle: annual, or on material change to a supplier. Covers Annex A controls 5.19 (information security in supplier relationships), 5.20 (addressing information security within supplier agreements), 5.21 (managing information security in the ICT supply chain) and 5.22 (monitoring, review and change management of supplier services). Part of the management-system substrate that makes the phrase “aligned with ISO/IEC 27001:2022” defensible; not a certification claim, and we hold no certificate. See Standards.
1. Purpose and method
This document is the periodic assessment of the third parties YMRTECH depends on. It exists because A.5.19 and A.5.22 require supplier relationships to be assessed and reviewed on a cycle, and because a supply-chain dependency that is never examined is a risk carried without being understood.
Method. Each supplier is assessed on four questions:
- What do they receive? The data or capability that actually crosses the boundary to this supplier — stated narrowly, not as a category.
- Where does it go? The jurisdiction and control boundary, since that determines which legal regime can compel the supplier.
- What is our reliance, and what breaks without them? The concrete failure mode if the supplier becomes unavailable, uncooperative, or compromised.
- What is our mitigation or accepted position? For each reliance, either the control that reduces it or an explicit statement that the risk is accepted and why.
What this is not. This is not an audit of the suppliers. We have no right to assess their internal controls and no visibility into them; asserting otherwise would be false. What is assessed here is our side of the relationship — what we send them, what we depend on, and what we would do about it. Their own assurance (such as it is) is taken as a claim by them, recorded where relevant, and not independently verified. That limit is stated in §3 and applies to every entry below.
Why publish it. A supplier list is a normal privacy-notice artefact (privacy notice §3.3); the assessment behind it normally is not. It is published here so that the reasoning is checkable and so that a change in our supplier posture is visible as a diff rather than as silence.
2. The register
| Supplier | What they receive | Jurisdiction | Reliance — what breaks | Position |
|---|---|---|---|---|
| Oracle Cloud | The production hosts themselves: vpn, public, mail — machine state, disk contents, network position. Not customer traffic content, which is never written. |
Oracle Cloud Infrastructure, same region per host | Total for service availability. All customer-facing functions run here. Loss of the region is loss of the service until rebuilt elsewhere. Provider-side access to a running host would defeat the host’s controls. | Mitigate + accept residual. Rebuild-from-configuration is the primary mitigation (declarative config, encrypted offsite backups, escrowed key material — see disaster recovery). Accepted residual: a provider that can access live hosts can compromise them, and no control of ours prevents that. Recorded as R-01/R-08. |
| Cloudflare (R2) | Encrypted backup objects: restic repositories of host state. Encrypted client-side before upload, so the objects are opaque to Cloudflare. | Cloudflare R2, US jurisdiction | Backup durability. Without R2 there is no offsite copy; a host loss becomes unrecoverable data loss. | Mitigate. Client-side encryption means Cloudflare holds ciphertext it cannot read; the passphrase is not stored with the backups. Recovery is additionally possible from git escrow alone, so R2 is not a single point of failure for key material. Account compromise remains a risk to object durability, not to confidentiality. |
| Stripe | Payment card details and customer email addresses, as the payment processor. | Stripe Inc., US | Revenue collection. No payments can be taken without them. Customers’ card data is held by Stripe, not by us. | Accept, with scoping. We deliberately never hold card data ourselves — that decision removes the largest possible data-protection exposure. Stripe’s own PCI-DSS posture is relied upon and taken as their claim. A breach at Stripe is outside our control and outside our scope statement. |
| SMTP2GO | Transactional service email: recipient addresses and message content of account/service emails. | US | Account operations. Password resets, receipts and service notices cannot be delivered without an email path. | Accept. No marketing email is sent. The mail path carries no customer traffic data. A failure degrades account operations but not the VPN service itself. |
| Quad9 | Upstream DNS queries originating from our resolvers — i.e. the queries of our customers, at the moment of resolution. | Quad9 Foundation, Switzerland (non-profit) | DNS resolution for VPN clients. Without an upstream resolver, client DNS fails unless reconfigured. | Accept, deliberately. This is the one supplier that sees customer query data in the clear, and it is chosen for that reason: Quad9 is a non-profit that does not retain personal data and does not sell query data. It is the only entry here where customer-derived data reaches a third party, and the choice of supplier is itself the mitigation. Documented in what we log and the privacy notice. |
| Domain registrar / DNS hosting | The delegation of ymrtech.com and its records. |
per registrar terms | Reachability. Loss of DNS delegation takes the service off the internet even while it is running. | Mitigate. Registrar account protected by the same credential hygiene as production; DNS changes are recorded rather than routine. Accepted residual: a registrar-level hijack is a recognised industry attack with no complete defence available to a small operator. |
3. Limits of this assessment — stated plainly
- We assess our side, not theirs. No supplier’s internal controls have been inspected. Where a supplier’s compliance (PCI-DSS at Stripe, for example) is mentioned, it is their published claim, relied upon by us, and not verified by us. A reader should treat every such mention as “they say so” rather than “we checked”.
- No contractual security review has been performed. A.5.20 asks that information security be addressed within supplier agreements. YMRTECH operates on standard consumer/business terms with these providers and has not negotiated security schedules with them. This is an honest gap: the control is assessed as partial precisely because the agreements are not bespoke. It is recorded in the statement of applicability rather than claimed as met.
- Supplier security events may not be detected by us. We would learn of a supplier breach from public reporting, not from our own monitoring — we do not monitor suppliers. This is recorded as a risk rather than presented as a capability.
- This assessment is a document, not yet a history. It is the first one. Until a later review exists to compare against, there is no evidence the cycle operates — see §5.
4. Changes since the previous review
This is the initial review; there is no previous version to compare against. Establishing a baseline is the purpose of a first review. The register in §2 reflects the supplier set published in the privacy notice and the hosts defined in the ISMS scope statement.
5. Review record
| Field | Value |
|---|---|
| Review performed | 2026-09-18 |
| Reviewer | Yannick M. Richard, sole operator |
| Method | Manual assessment against the four questions in §1, derived from the published privacy notice and the configuration repository |
| Suppliers assessed | 6 |
| Changes since previous review | N/A — initial review |
| Open findings | (1) No bespoke security schedules in supplier agreements (A.5.20 remains partial). (2) Suppliers are not actively monitored for security events; reliance is on public reporting. |
| Next review due | 2027-09-18, or on a material change to any supplier |
How a reader can check this record. As with the policy approval record, the value here is not that a document asserts a date but that the assertion is falsifiable: this document is version-controlled in a public repository, the commit introducing version 1.0 is retrievable without credentials, and any later edit is equally visible. A reader who finds the date above inconsistent with that history has found a real defect.
6. Change history
| Date | Version | Change |
|---|---|---|
| 2026-09-18 | 1.0 | Initial supplier review. Six suppliers assessed; two open findings recorded. |