ISMS scope statement

Status: operative document. Version 1.0, 2026-09-18. Owner: Yannick M. Richard. Review cycle: annual, or on material change. This document is part of the management-system substrate that makes the phrase “aligned with ISO/IEC 27001:2022” defensible; it is not a certification claim, and we hold no certificate. See Standards for what we do and do not claim.

1. Purpose

This document defines the boundary of the YMRTECH information security management system (ISMS): the organisational units, services, infrastructure, locations and interested parties it covers, and the parts it deliberately does not cover. It exists so that every other document in the ISMS — the risk register, the policy set, the change-management statement — has a defined subject and so that a reader can tell whether a given claim falls inside the system or outside it.

2. The organisation

YMRTECH is a small infrastructure-engineering practice operated by Yannick M. Richard. It performs two distinct kinds of work:

A consumer/client VPN service (clientsv) — the product this ISMS is primarily concerned with.
Client infrastructure engineering and security work — consulting and engineering engagements for third parties.

Both are operated by the same individual on the same fleet of hosts. That fact is recorded here rather than glossed over, because it is the single largest source of risk in this ISMS: there is no separation of duties available within a one-person operation, and the controls below are designed around that constraint rather than pretending it does not exist.

3. Scope — included

The ISMS covers:

Element	In scope	Notes
Service	The YMRTECH VPN service (`clientsv`): client authentication, network isolation, DNS resolution, and the transport of customer traffic	The customer-facing product
Supporting infrastructure	The `vpn`, `public`, and `mail` hosts and the management mesh (AmneziaWG `wg0`) that connects them	These are the systems on which the service depends
Management systems	The public configuration repository and its CI/CD pipeline; the deployment runner; the secrets store (SOPS/age); the monitoring and alerting stack	Where changes to the above are made and detected
Evidence systems	The infrastructure audit: the daily signed no-log assertion, the dated history, the monthly roll-up, and the publication path that serves them	The evidence layer that makes §4.1 claims checkable
People	Yannick M. Richard, as the sole operator, security owner, and system administrator	—
Assets	Configuration source, cryptographic key material, customer account records, billing records, and the hosts and network themselves	The customer traffic is deliberately not an asset, because it is not retained

4. Scope — excluded, and why

Stating exclusions explicitly is as important as stating inclusions; an ISMS whose boundary is vague cannot be audited.

Customer traffic content and metadata. Not merely out of scope — it is architecturally not retained. There is nothing to protect because there is nothing held. The enforcement of that statement is itself in scope (see §3, evidence systems). This exclusion is the point of the product.
Customer endpoint devices. The ISMS does not extend to the security of customers’ own machines, their choice of client software, or their local networks. We assert only what happens to traffic once it reaches our entry point.
The personal workstation (giga) and personal data on it. The workstation participates in the management mesh, so its network access to production is in scope; its contents are not YMRTECH information assets.
Third-party services we consume. The hosting provider, the mail relay path, and any external service used for delivery are supplier-managed. Their security is addressed as a supplier relationship (§8) — we assess and record our reliance on them — but their internal controls are outside our ISMS.
Client consulting engagements and client-owned infrastructure. Work performed for clients on systems we do not own or operate is governed by engagement contracts, not by this ISMS. Where such work touches YMRTECH’s own systems (e.g. credentials handling), that part is in scope.
Physical security of the hosting provider’s facilities. Outside our control and outside the scope; reliance on the provider is recorded as a supplier dependency rather than asserted as a control.

5. Interested parties and their requirements

Interested party	What they require of us	How it is addressed
Customers	That the no-log claim is true and that they can check it themselves	The signed daily audit and its publication (see Infrastructure Audit)
Prospective customers	Evidence of security posture sufficient to trust the service	Standards, the audit, and this ISMS
Regulators / data-protection authorities	Handling of personal data consistent with applicable law	The privacy notice and the data inventory on what we log
The operator	That the systems remain operable and recoverable	Backup and recovery statement and the disaster-recovery documentation and drills it records
Hosting / network suppliers	Compliance with their acceptable-use terms	Their terms are the operating constraint on what the fleet may do

6. Interfaces and dependencies

The ISMS depends on, but does not control: the hosting provider’s compute and network; the account and billing records’ storage; the domain registrar and DNS delegation; the certificate authorities used for TLS. Each is recorded as a supplier dependency in the risk register where it carries a risk that is not otherwise mitigated.

7. Statement of applicability

The selection of Annex A controls, including the justified exclusions and the reason each remaining control is either implemented, planned, or not applicable, is recorded in the Statement of Applicability. That document is the authoritative answer to “which controls do you actually claim, and on what basis” — the question this scope statement exists to make answerable.

8. Change history

Date	Version	Change
2026-09-18	1.0	Initial scope statement.