Standards, certifications, and the words we are allowed to use
This page exists because “ISO certified VPN” is one of the most common claims in this industry and one of the most commonly overstated. Here is which standard actually applies to a service like ours, what certification really requires, what we hold today — which is nothing, deliberately — and the path and vocabulary we are working to.
Read it next to Infrastructure Audit, which is where our verifiable claims live, and the management system, which is how this is actually governed and reviewed.
1. The short version
- A VPN product cannot be “ISO certified.” ISO/IEC 27001 certifies an organisation’s management system, for a defined scope — not a product, and not a feature. “Our VPN is ISO certified” is a category error before it is even a lie.
- Certification implies a third party. A certificate is issued by an accredited certification body after a formal audit, is valid for three years, and is subject to annual surveillance. Without that, the honest phrases are “conform to” or “aligned with” — and only once the work behind them exists.
- We hold nothing today, and we say so plainly: no certificate, no accreditation, no external audit, no SOC 2 report, no self-declaration of conformity. Our claims are the ones you can verify on our infrastructure — the signed audit and the behavioural no-log assertions — plus whatever you can read in the public part of our configuration, which is most of it but not all of it (the boundary is described at Audit).
- The gap between us and ISO/IEC 27001:2022 is almost entirely documentation and process, not technology. That is a deliberate, checkable statement, and §4 sets out what is missing item by item.
2. Which standard applies to a VPN service
ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection — Information security management systems — Requirements. It specifies the requirements for establishing, implementing, maintaining and continually improving an information security management system (ISMS).
Two structural facts cause most of the confusion in this market:
- 27001 is the requirements standard; ISO/IEC 27002:2022 is the guidance. You are certified against 27001. Nobody is certified “to 27002” — it is the reference that explains the controls.
- Annex A of ISO/IEC 27001:2022 contains 93 controls in four themes — 37 organisational, 8 people, 14 physical, 34 technological. Those 93 controls are the menu an ISMS selects from after its own risk assessment; conformance is not “we did all 93”.
Supporting and adjacent standards, and how we read them for a service our size:
| Standard | What it is | Our reading |
|---|---|---|
| ISO/IEC 27001:2022 | ISMS requirements (certifiable) | The standard that actually applies. Organisation-level, scope-defined. |
| ISO/IEC 27002:2022 | Control guidance | Reference material, not a certificate. |
| ISO/IEC 27017 | Cloud-specific controls, split by customer/provider responsibility | Relevant because our fleet runs on cloud infrastructure; it is the right lens for the shared-responsibility boundary. An add-on to a 27001 certificate, not a separate certificate. |
| ISO/IEC 27018:2025 | Protecting PII in public clouds | Useful as a checklist for the account data we do hold. A code of practice, not normally a standalone certificate. |
| ISO/IEC 27701:2025 | Privacy Information Management System (PIMS) | Revised in October 2025 into a standalone management-system standard — it no longer presumes a certified 27001 ISMS. The natural privacy target once an ISMS exists. |
| CSA STAR | Cloud security assurance registry | Level 1 is a free self-assessment (a published CAIQ); Level 2 requires an independent third-party assessment. Level 1 proves you published honest answers, not that anyone checked them — we would label it exactly that way if we filed one. |
| i2Coalition VPN Trust Initiative (VTI) | The only VPN-specific programme: principles across security, privacy, advertising practices, disclosure/transparency and social responsibility, with a VPN Trust Seal for providers that pass a compliance assessment | The most VPN-specific external mark that exists. It is an industry-body programme, not an accredited certification of a management system — a step above self-assessment, and we would describe it as such. |
| SOC 2 | Attestation report (not a certificate) | Relevant for business customers. Type II exists only once an independent CPA has tested controls over a period. |
There is no “GDPR certification” either. There is no “certified no-logs” mark. Where a mark like that is advertised, ask for the issuing body and the audit report.
3. What certification actually takes
An accredited certification audit is two stages. Stage 1 reviews the ISMS documentation and readiness. Stage 2 tests whether the system is actually implemented and effective. Surveillance audits follow annually for two years, with recertification in the third.
For a scope of our size, published vendor and certification-body estimates put the audit at roughly 4–6 auditor-days and a five-figure cost range at the low end for a small organisation — and the audit fee is not the real cost. The dominant cost is operator time: a risk assessment, a policy set, internal audit, management review, supplier assessments, and the records an auditor samples. On a one-person operation, that time is the project.
What this means practically: the technical half is the part we already do. The half that is missing is a management system that documents, reviews, and improves it.
4. Where we stand
4.1 What we can prove today
Not certification — evidence, and it is evidence about specific technical assertions rather than about how we run the company:
- Behavioural no-log assertions, enforced daily and signed publicly. The invariants are re-applied, a live probe query is sent, and the audit requires that nothing was logged. A failing check still publishes the signed violation. See Infrastructure Audit.
- Most of the system configuration is public source, and we say which part is not. The bulk of the fleet’s OS configuration — every host definition, the firewall, the WireGuard and AmneziaWG setup, the resolver settings, the monitoring stack — is public and readable at git.ymrtech.com/ymrtech/nix-config. A smaller set of modules that make up the product perimeter — the client-facing VPN service, its isolation rules, and the audit’s own generator — live in a separate repository that is not public. We describe that boundary in full at Audit rather than calling the whole configuration public. Anything you can verify about the audit itself you verify through the published artifacts, which do not require reading our source.
- Deployment control. Changes go through review, automated checks, and a health gate with automatic rollback on violation.
- Data minimisation by design and a published inventory of what is held — see What We Log and Privacy.
4.2 The four Annex A themes, honestly assessed
| Theme | Controls | Where we are |
|---|---|---|
| Technological (34) | Access control, cryptography, logging/monitoring, network security, hardening | Strongest area. Key-only access, no-log enforcement, encrypted backups, declarative hardening, monitored fleet. The controls exist; the evidence of deliberate selection and review is mostly implicit in git history. |
| Organisational (37) | Policies, roles, risk management, supplier relationships, incident management, continuity | The remaining gap. The policy set, risk register, change-management statement and incident response plan are now published and approved. What is still missing is supplier assessment and a produced review history — process and habit, not engineering. |
| Physical (14) | Facilities, equipment, environmental | Inherited from the cloud provider, which is exactly what ISO/IEC 27017’s shared-responsibility framing is for. Needs a documented assessment, not new controls. |
| People (8) | Screening, awareness, competence | Trivial at current headcount, and still needs records. This is the theme that grows the moment anyone else is involved. |
4.3 The gap list
The items below are the documented work between us and a defensible claim. None of them is a technical control we lack:
ISMS scope statement— done, 2026-09-18.Risk assessment and risk register— done, 2026-09-18; fifteen risks with assessed likelihood, impact, treatment and residual.Documented policy set— done, 2026-09-18; consolidated in the information security policy with a dated approval record.Internal audit programme— done, 2026-09-18. Note what it is: a written process and a schedule. Our automated audit is evidence, not a substitute for a documented internal audit, and a produced review record is still outstanding.Incident response plan— done, 2026-09-18.Supplier review— done, 2026-09-18; all six providers assessed with a dated record and a defined annual cycle. A.5.22 moves from planned to partial: the cycle now exists, but it is the initial baseline.
What remains is mostly the difference between having a management system and operating one — this list has stopped being a list of missing documents:
- A produced review history — the documents exist and the cycles are scheduled, but few dated records have been produced yet. The daily signed audit and the review records are the evidence; right now there are days of them, not months. This closes with time and repetition, not with writing.
- Bespoke supplier agreements (A.5.20) — we operate on standard provider terms without negotiated security schedules. The supplier review records this as an open finding rather than leaving it implied.
- Independent review — the whole system is self-assessed. An external auditor is the only thing that closes this, and it is a business decision rather than an engineering task.
- Objective metrics — the internal audit programme defines the review cycle, but the measurements it will report (audit uptime, time-to-patch, alert acknowledgement) have no baseline yet.
4.4 What we will not say
The rule is simple: certification language implies a third party. Until an accredited body issues a certificate, any word that implies one is a misrepresentation — a consumer-protection problem, not a style preference, and an explicit violation of the VTI’s own advertising principle that VPNs will not make false claims about their services.
| We will not say | We say instead |
|---|---|
| “ISO 27001 certified” / “ISO certified” / “ISO-compliant VPN” | nothing until it is true; then “certified to ISO/IEC 27001:2022 for the operation of …” |
| “our VPN is ISO certified” | never said — certificates attach to organisations and scopes, not products |
| “independently audited” (when the auditor is our own script) | “daily self-audit, cryptographically signed and publicly verifiable” |
| “certified no-logs” | “no activity logs, enforced by automated assertions and published daily as a signed report anyone can verify” |
| “SOC 2 certified” | nothing until a SOC 2 Type II report exists (reports, not certificates) |
| “approved by the i2Coalition” | “participant in the i2Coalition VPN Trust Initiative” — and only “accredited under the VTI Trust Seal programme” once that review has actually been passed |
| “GDPR certified” (no such thing) | “designed to support GDPR obligations — see the privacy notice” |
5. The path we are on
In order, cheapest and highest-credibility first:
Publish the management-system substrate— done, 2026-09-18. The scope statement, risk register, statement of applicability and change-management statement are published as versioned documents at the management system. The statement of applicability assesses all 93 Annex A controls individually and states plainly which are only partial — 27 applied, 40 partial, 10 excluded. That disclosure is what makes the phrase “aligned with ISO/IEC 27001:2022” defensible. The policy set was closed on the same date: the information security policy carries a formal, dated approval record (A.5.1) and the incident response plan closes A.5.24–A.5.27. Remaining under this step: a periodic supplier review (A.5.22, A.5.19).- Add a signed, periodically re-issued transparency statement (a warrant canary) — reusing the signing and publication machinery the audit already runs on, publishing what legal demands have and have not been received, with a plain statement of what such a statement does and does not prove.
- Map our published policies to the five VTI principle areas, then participate in the VTI and pursue the VPN Trust Seal — the only VPN-specific external review in existence.
- Operate the ISMS: internal audit, management review, metrics, and one tested recovery drill per cycle. This is what an auditor samples.
- Undergo ISO/IEC 27001:2022 certification when a customer segment actually requires it — and then say “certified to ISO/IEC 27001:2022 for the operation of the YMRTECH VPN service”, with the certificate number and issuing body published here.
- After that, the privacy layer: ISO/IEC 27701:2025, and CSA STAR Level 2 if a cloud-assurance audience wants a third-party assessment in a registry.
Until step 5 is done and a certificate exists, this page will keep saying we hold none. The date and content of every change here is in the public history of this site.