Supplier review — the providers we rely on

Status: operative document. Version 1.2, 2026-10-29. 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: each host’s restic repository of host state, and the database path’s pgBackRest repository (full backups plus continuous WAL). Both are 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. Backup scope, retention and the restore that has been exercised are published in the backup and recovery statement.
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.
Cloudflare (registrar + DNS hosting)	The delegation of `ymrtech.com` and its records. This is the same supplier as the Cloudflare (R2) entry above, recorded separately because it is a different relationship: this one holds DNS delegation, not backup objects.	Cloudflare, Inc., US jurisdiction	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.
nixbuild.net	The fleet’s aarch64 build requests — derivations and their build inputs — executed on the supplier’s infrastructure, from fleet CI only; back comes the built closure plus the supplier’s own signing key (`nixbuild.net/SFV6IN-1`). Contracting entity is Immutable Solutions AB, registration number 556968-0308, named as party (1) in the Terms of Use. They receive no customer data, no host state, no customer traffic and no credentials: the inputs are the public Nix closure of this configuration repository. Terms §4.1 restricts use to our own activities; §4.4 forbids third-party use and malicious content.	Sweden (EU) — Terms §15.1 applies the substantive law of Sweden; §15.3 seats arbitration in Stockholm (SCC)	Build wall-clock only. Without them CI builds take longer; the service does not stop, no deployed host is touched (deploys keep building on-fleet), and an artifact cannot be poisoned by them: their key is not in this fleet’s `trusted-public-keys`, and a closure they built must pass a local rebuild-and-compare gate before it is published to Attic.	Accept, scoped to CI builds, and gated. Their published controls (privacy): each build isolated by KVM; no network inside the build sandbox; intermediate output never written to disk (memory only); output paths stored on an encrypted filesystem; build inputs reused only when signed by a key both accounts trust (default `cache.nixos.org` only); account deletion removes all data the account produced or uploaded. Recorded caveat — byte-identical store paths are deduplicated across accounts, so identical content is stored once and, after an account is deleted, “will no longer be possible to relate to the deleted account”: acceptable here because our build inputs are public Nix closures, but stated rather than omitted, as it is the only clause under which our content can be co-resident with another account’s. Billed €0.12 per CPU-hour (§3.1), monthly in arrears, charged via Stripe (§3.2) — Stripe is itself an assessed supplier above.

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 a recorded 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.
The comparison history is short. The first review, 2026-09-18, had no previous version to compare against. This revision is the first comparison — §4 records exactly what moved — so the cycle has now been exercised once. One comparison is evidence the cycle operates, not proof of a settled habit, and any claim that the review cycle is reliable is a claim to re-check at the next review (§5).

4. Changes since the previous review

Compared with version 1.1 (2026-09-28), two things changed:

nixbuild.net was added as a build-only supplier. The fleet’s aarch64 build requests are executed on infrastructure run by Immutable Solutions AB, Sweden. What crosses the boundary is the public Nix closure of the configuration repository and nothing else. Assessed, accepted and gated in §2.
The registrar/DNS row was named. The entry previously headed “Domain registrar / DNS hosting” is now Cloudflare (registrar + DNS hosting). It deliberately remains a separate row from Cloudflare (R2): same supplier, different data flow (DNS delegation, not backup objects) and different reliance (reachability, not backup durability), so merging them would lose the distinction.

No other supplier’s position changed, no supplier was removed, and no open finding was closed. The register in §2 continues to reflect 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-10-29
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	7
Changes since previous review	nixbuild.net (Immutable Solutions AB, Sweden) added as a build-only supplier; the registrar/DNS row named Cloudflare (registrar + DNS hosting), kept separate from the Cloudflare (R2) entry. See §4.
Open findings	(1) No bespoke security schedules in supplier agreements (A.5.20 remains partial) — this includes nixbuild.net, which publishes no security schedule or data-processing agreement beyond its terms and privacy pages. (2) Suppliers are not actively monitored for security events; reliance is on public reporting.
Next review due	2027-10-29, 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.
2026-09-28	1.1	The Cloudflare (R2) entry now records both backup paths it holds — the per-host restic repositories and the database path’s pgBackRest repository (full backups plus WAL) — under the same client-side-encryption position. No finding changed and no supplier was added.
2026-10-29	1.2	Added nixbuild.net (Immutable Solutions AB, Sweden) as a build-only supplier; named Cloudflare on the registrar/DNS row, keeping it separate from the R2 entry.