Information security policy
Status: operative document. Version 1.0, 2026-09-18. Owner: Yannick M. Richard. Approved by: Yannick M. Richard, as sole member of YMRTECH LLC (see the approval record in §7). 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 and management commitment
This document is the primary information security policy of YMRTECH. It states what the organisation commits to, the policy set that implements that commitment, who owns each part of it, and how the policy set is reviewed and approved. It is the document that ISO/IEC 27001:2022 Clause 5.2 and Annex A control 5.1 call for, and it exists so that every other YMRTECH document on security has a single, dated, approved statement to hang from.
YMRTECH’s commitment is deliberately narrow rather than expansive, because a policy that promises more than the organisation can demonstrate is worse than a smaller policy it can. Specifically, YMRTECH commits to:
- Not retaining customer traffic. The VPN service is operated so that customer traffic content and metadata are not stored. This is an architectural property, not an aspiration: the statement is re-asserted daily on the running hosts and published with a cryptographic signature, and a failure to comply is visible to any reader. See what we log and the infrastructure audit.
- Making verifiable claims only. Where YMRTECH publishes a security claim, it is stated so that a reader outside the organisation can check it against signed, dated artifacts, or it is qualified explicitly as an assertion. The Standards page records which of the two each claim is.
- Operating a management system, not a document set. Policies are reviewed on a defined cycle, the review produces a dated and signed record, and the internal audit programme treats an unreviewed policy as a finding. See the internal audit programme.
- Handling incidents by a defined process. Incidents are classified by severity, responded to under a written runbook, and reviewed afterwards. See the incident response plan.
- Complying with applicable law and supplier terms. Personal data is handled consistently with applicable law, and the fleet operates within the acceptable use terms of its suppliers, which are treated as operating constraints rather than as matters of preference.
2. Scope of this policy
This policy governs the information security management system whose boundary is defined in the ISMS scope statement. It applies to the operator of YMRTECH, to the production hosts and management mesh, to the configuration source and deployment pipeline, and to the evidence systems. It does not extend to the excluded elements recorded in that statement — in particular customer endpoint devices, client-owned infrastructure, and the internal controls of suppliers — which are excluded there with reasons.
3. The policy set
This policy does not itself contain every rule. Under Annex A 5.1 it is supported by topic-specific policies and statements, each a separate published document with its own owner and review cycle. The set is:
| Document | Covers | Control |
|---|---|---|
| Information security policy (this document) | Management commitment; the policy framework; approval and review | A.5.1, Cl. 5.2 |
| ISMS scope statement | The system boundary, interested parties, interfaces | Cl. 4.3 |
| Risk register | Risk identification, assessment method, treatment and residual risk | Cl. 6.1 |
| Statement of applicability | Which Annex A controls are claimed, excluded, or planned, and why | Cl. 6.1.3 |
| Change management statement | How change reaches production and how a bad change is reverted | A.8.32 |
| Incident response plan | Severity levels, response runbook, post-incident review | A.5.24–A.5.27 |
| Internal audit programme | The dated internal review cycle and its records | A.5.29, A.5.35 |
| What we log | The data inventory: what is retained and what is not | A.5.34, A.8.15 |
| Privacy notice | Lawful basis, retention, and data-subject choices | A.5.34 |
| Terms and fair use | Acceptable use, the contractual relationship, governing law | A.5.31 |
| Standards | What “aligned with ISO/IEC 27001:2022” does and does not mean here | A.5.36 |
A note on the word “policy”. YMRTECH distinguishes a governance document from a service description. The /security/ page is not part of this policy set: it describes offensive and defensive security services offered to clients. It describes work YMRTECH performs; it does not state rules YMRTECH binds itself to. Earlier revisions of the statement of applicability listed it among the policy set, which was a category error and has been corrected.
4. Roles and responsibilities
YMRTECH is operated by one individual. There is no separation of duties available, and the ISMS records that as a risk (R-10) rather than describing roles that do not exist.
| Responsibility | Held by | Note |
|---|---|---|
| Top management / policy approval | Yannick M. Richard, sole member, YMRTECH LLC | Approval authority under Clause 5.2 |
| Security owner and system administrator | Yannick M. Richard | Same person; no dual control available |
| Risk owner for every register entry | Yannick M. Richard | Every entry names the same owner by necessity |
| Internal review (audit programme) | Yannick M. Richard | Self-assessment; see §6 for the limit this implies |
| Change authorisation | Automated by policy — PR-gated CI and a deployment health gate | Not a human approver; recorded in the change management statement |
Because a single person holds every role, the compensating controls are transparency rather than dual control: changes are made in public version control with a review trail, the deployment pipeline is declarative and revertible, and the evidence layer is published where a third party can check it. That substitution is stated here deliberately — it is the honest substitute for segregation of duties, not an equivalent of it.
5. Compliance, review and enforcement
Review cycle. This policy and the set in §3 are reviewed at least annually, and on any material change to the scope, the risk register, or the fleet. The review is performed under the internal audit programme; it produces a dated record stating what was reviewed, what changed since the previous review, and any findings. A cycle in which no review record was produced is itself a finding.
What review checks. Each review verifies at least that the documents listed in §3 still exist and resolve, that the control counts they assert agree with the statement of applicability, that each document’s stated owner and review cycle remain accurate, and that no policy in the set contradicts another. The first scheduled review has not yet occurred; §7 records the initial approval instead, and says so.
Enforcement. The policy set is binding on the operator. Where a rule in the set is not enforced by the systems themselves, this is recorded as a gap rather than asserted as compliance. Controls that do not operate are marked as such in the statement of applicability; a control is not marked applied merely because a document describing it exists.
Deviations. Any deliberate departure from a rule in the set is recorded in the risk register as an accepted risk with its reasoning. Unrecorded deviation is treated as a finding by the next review.
6. Limitations and honest qualifications
The following limits are stated so that a reader is not misled about the strength of this policy:
- Self-assessment only. This policy is written, reviewed and approved by the sole operator. The approval in §7 is an owner’s approval, not independent assurance. It carries the weight of a signed commitment by the person accountable, and no more than that.
- No certification. YMRTECH holds no ISO/IEC 27001 certificate. “Aligned with ISO/IEC 27001:2022” describes the structure of this management system, not an audited status.
- No separation of duties. Stated in §4 and recorded as risk R-10. A reader evaluating this policy should assume that every control depending on a second person does not exist here.
- The evidence layer has a known limit. The daily audit runs on the hosts it audits, so a full host compromise could forge a report. That limit is recorded in the risk register (R-05) and published rather than concealed.
- Approval predates review. The initial approval in §7 is the act of establishing the policy; the first review under §5 has not yet taken place. The distinction is recorded because claiming a reviewed policy on the day of its first publication would be false.
7. Approval record
This record is the formal approval required by Clause 5.2 and Annex A 5.1. It is a statement by the accountable individual, made on the date shown, that the policy set in §3 is established and binding.
| Field | Value |
|---|---|
| Document | Information Security Policy, version 1.0 |
| Approving authority | Yannick M. Richard, sole member and top management of YMRTECH LLC |
| Entity | YMRTECH LLC, 30 N Gould St Ste R, Sheridan, WY, United States |
| Date of approval | 2026-09-18 |
| Approval action | This document and the policy set in §3 are adopted as the information security policy of YMRTECH |
| Scope of approval | The policy set listed in §3, as it stands at the approved revision |
| Approval evidence | The commit introducing this version into the public configuration repository, signed and dated in git history |
| Review due | 2027-09-18, or earlier on material change (see §5) |
How a reader can check this approval. The approval is not merely asserted here. This document is version-controlled in YMRTECH’s public repository; the commit that introduced version 1.0 carries its author, timestamp and content hash, and is retrievable by anyone without credentials. A later edit to this section is equally visible, and the recorded version and date above must agree with that history — a reader who finds them in disagreement has found a real defect, and the disagreement is the evidence.
That is the limit of what an approval record can be in a one-person organisation: it cannot be countersigned, so it is made verifiable instead of authoritative. A reader should treat the date and content as checkable facts and the approval itself as the owner’s commitment, which is what it is.
8. Change history
| Date | Version | Change |
|---|---|---|
| 2026-09-18 | 1.0 | Initial information security policy and approval record. Consolidates the previously scattered policy set; corrects the statement of applicability to remove the service description page from the policy set. |