Statement of applicability
Status: operative document. Version 1.0, 2026-09-18. Owner: Yannick M. Richard. Review cycle: annual, or on material change. This is an alignment document, not a certification document. YMRTECH holds no certificate and has not been audited by anyone. See Standards for the full statement of what we do and do not claim, and the scope statement and risk register for context.
1. What this document is
ISO/IEC 27001:2022 Annex A lists 93 controls in four themes: organisational (37), people (8), physical (14), and technological (34).
A Statement of Applicability (SoA) is the document that says, for each control, whether it is applied, excluded, or not applicable — and why. It is the single most important artefact in an ISO 27001 audit, because it is where an organisation commits to a position it can be held to.
This is ours. The honest headline: the technological controls are the strongest part of this ISMS; the organisational and physical controls are the weakest, and several are excluded because a one-person practice on rented infrastructure cannot implement them. We state that rather than marking everything “applied” and letting a reader discover the emptiness later.
2. Status values used below
| Value | Meaning |
|---|---|
| Applied | The control is implemented and evidence of it exists. |
| Partial | Something exists, but it is not complete or not yet evidenced. |
| Planned | Not implemented; accepted as a gap with a stated intention. |
| Excluded | Deliberately not applied, with the justification recorded. |
| N/A | The control cannot apply, given the scope in the scope statement. |
3. Organisational controls (A.5 — 37 controls)
| Control | Status | Basis |
|---|---|---|
| A.5.1 Policies for information security | Partial | Consolidated in the information security policy, which states the policy set, its owners, the review cycle, and a dated approval record by top management. Held partial, not applied, because the policy is self-approved in a one-person operation and its first review under §5 has not yet occurred. |
| A.5.2 Information security roles and responsibilities | Partial | Roles are now defined in the information security policy (top management, security owner, risk owner, review, change authorisation) as a table naming the holder of each. Held partial because a single individual holds every role; the compensating substitute is a public review trail, not dual control. |
| A.5.3 Segregation of duties | Excluded | Impossible in a one-person operation. Recorded as accepted risk R-10 with compensating controls (public review trail, published audit). Pretending otherwise would be the dishonest option. |
| A.5.4 Management responsibilities | Partial | The operator is management; responsibilities are documented in the scope statement. |
| A.5.5 Contact with authorities | Planned | No documented contact procedure or authority register. Gap. |
| A.5.6 Contact with special interest groups | Partial | Participation in the NixOS and privacy-community ecosystem is informal and undocumented. |
| A.5.7 Threat intelligence | Partial | Reliance on upstream security advisories for pinned dependencies (the build pipeline surfaces CVEs). No formal threat-intelligence process. |
| A.5.8 Information security in project management | Partial | Changes go through PR review and CI, which is a form of security-in-change; not framed as project management. |
| A.5.9 Inventory of information and other associated assets | Applied | The public configuration is the asset inventory for systems — every host, service and network is declared in source. The data inventory is published on what we log. |
| A.5.10 Acceptable use of information and assets | Partial | Acceptable use is implicit in the configuration and terms; no standalone policy. |
| A.5.11 Return of assets | N/A | No employees or contractors hold YMRTECH assets. |
| A.5.12 Classification of information | Partial | Categories exist implicitly (secrets in SOPS, everything else public or ordinary). No published classification scheme. |
| A.5.13 Labelling of information | Partial | Secrets are labelled by storage location; no formal labelling scheme. |
| A.5.14 Information transfer | Applied | Traffic transport is encrypted (WireGuard/AmneziaWG, TLS); transfer rules documented in the architecture documentation. |
| A.5.15 Access control | Applied | Key-only SSH, source-address pinning, management mesh, default-deny firewall; declared in public configuration. |
| A.5.16 Identity management | Partial | Identities exist per host and per service and are declared in configuration; no central identity lifecycle process. |
| A.5.17 Authentication information | Applied | No passwords for system access; keys are generated and protected; secrets in an encrypted store. |
| A.5.18 Access rights | Applied | Access is declared in configuration and reviewable as a diff; sudo rights are explicitly enumerated. |
| A.5.19 Information security in supplier relationships | Partial | The supplier review assesses all six suppliers on what they receive, jurisdiction, reliance and position. Held partial because we assess our side of the relationship only — no supplier’s internal controls have been inspected. |
| A.5.20 Addressing information security within supplier agreements | Partial | Reliance on standard provider terms; no negotiated security annexes at this scale. The supplier review records this explicitly as open finding (1) rather than leaving it implied — the gap is documented, which is not the same as closed. |
| A.5.21 Managing information security in the ICT supply chain | Partial | Pinned, reviewed dependencies with a minimum-age policy and CVE surfacing in CI — a real supply-chain control, not a documented process. The service-level supply chain (hosting, storage, payments, DNS) is assessed separately in the supplier review. |
| A.5.22 Monitoring, review and change management of supplier services | Partial | The supplier review now defines an annual cycle with a dated review record and a changes-since-previous section. Moved from planned to partial: the cycle is defined and the first record exists, but it is the initial baseline and suppliers are not actively monitored for security events — reliance is on public reporting. |
| A.5.23 Information security for use of cloud services | Partial | Cloud/rented infrastructure used with declarative configuration and no-log architecture; no cloud-security policy document. |
| A.5.24 Incident management planning and preparation | Partial | The incident response plan now defines severity levels (S1–S4), response targets and publication rules. Remains partial because no on-call rota or escalation path exists — one operator cannot staff one, and that is disclosed in the plan and carried as an accepted risk rather than papered over. |
| A.5.25 Assessment and decision on information security events | Planned | Alert rules evaluate on a 30-second interval and deliver over authenticated SMTP. The incident response plan defines triage and severity assignment. Remains planned until a real incident or exercise exercises that path — the procedure is written but has no history. |
| A.5.26 Response to information security incidents | Partial | The monitoring stack alerts and deploys auto-rollback on health violations, and the incident response plan documents containment, eradication and recovery. Strengthened by the escrowed age identities that let a rebuilt host decrypt its own backups. Untested by a real incident. |
| A.5.27 Learning from information security incidents | Planned | The incident response plan defines a seven-day post-incident review with a six-point structure, and requires that a review finding no action is sent back as incomplete. Remains planned until reviews exist: the process is written, the history is empty. |
| A.5.28 Collection of evidence | Applied | This ISMS’s strongest genuine asset: signed, dated, archival audit evidence with published verification instructions. |
| A.5.29 Information security during disruption | Partial | Declarative configuration enables rebuild; recovery is documented in the DR runbook and the escrowed per-host age identities make a rebuilt host decryptable. Drills still not performed on a cycle — the internal audit programme has not yet produced its first record. |
| A.5.30 ICT readiness for business continuity | Partial | Same basis; continuity depends on a single provider, recorded as accepted risk R-08/R-09. |
| A.5.31 Legal, statutory, regulatory and contractual requirements | Partial | Handling is described in the privacy notice and terms; no consolidated legal-requirements register. Gap. |
| A.5.32 Intellectual property rights | Partial | The public repository carries a licence; dependencies are licence-reviewed informally. |
| A.5.33 Protection of records | Applied | Records are version-controlled and the audit series is frozen per month and hashed. |
| A.5.34 Privacy and protection of PII | Applied | Data minimisation by architecture; published inventory; privacy notice; no activity retention. |
| A.5.35 Independent review of information security | Excluded | Not performed. This is what “no external audit” means, and it is stated on Standards. The internal audit programme is self-assessment and says so; it cannot substitute for this control. Recorded as a gap rather than claimed. |
| A.5.36 Compliance with policies, rules and standards | Partial | The information security policy states the binding rule set; configuration implementing it is enforced by machine rather than by periodic inspection, which is stronger than the control assumes. The internal audit programme now defines quarterly control sampling and monthly count reconciliation, but no review record exists yet. |
| A.5.37 Documented operating procedures | Partial | Deployment, recovery and architecture documentation exist in the private repository; not all are public. |
Organisational summary: 8 applied, 23 partial, 3 planned, 2 excluded, 1 N/A. This is the weakest theme and the main thing standing between YMRTECH and a defensible “aligned” claim.
4. People controls (A.6 — 8 controls)
| Control | Status | Basis |
|---|---|---|
| A.6.1 Screening | N/A | No employees; the operator is the owner. |
| A.6.2 Terms and conditions of employment | N/A | No employment relationships. |
| A.6.3 Information security awareness, education and training | Partial | The operator’s competence is demonstrated by the systems themselves and by professional practice; no formal training record. |
| A.6.4 Disciplinary process | N/A | No employees. |
| A.6.5 Responsibilities after termination or change of employment | N/A | No employees; access revocation on role change is handled by configuration. |
| A.6.6 Confidentiality or non-disclosure agreements | N/A | No third parties with access. Client engagements are covered by their own contracts. |
| A.6.7 Remote working | Applied | The entire operation is remote; access is via the management mesh with key-only authentication and no dependence on a trusted local network. |
| A.6.8 Information security event reporting | Partial | Monitoring and alerting exist; a published reporting channel for external parties is not documented. Gap. |
People summary: 1 applied, 2 partial, 5 N/A. Expected for a one-person practice; the N/A entries are genuine, not convenient.
5. Physical controls (A.7 — 14 controls)
| Control | Status | Basis |
|---|---|---|
| A.7.1 Physical security perimeters | Excluded | Hosts are rented; the provider controls the facility. Reliance recorded as supplier dependency (R-09). |
| A.7.2 Physical entry controls | Excluded | As above. |
| A.7.3 Securing offices, rooms and facilities | N/A | No YMRTECH-operated facility. |
| A.7.4 Physical security monitoring | Excluded | As A.7.1. |
| A.7.5 Protecting against physical and environmental threats | Excluded | Provider responsibility. |
| A.7.6 Working in secure areas | N/A | No such areas under our control. |
| A.7.7 Clear desk and clear screen | Partial | Operator practice; workstation is a personal machine with encrypted storage. Undocumented. |
| A.7.8 Equipment siting and protection | N/A | No YMRTECH-operated equipment housing production. |
| A.7.9 Security of assets off-premises | Partial | The operator’s workstation is the only such asset; disk encryption and mesh-restricted access apply. |
| A.7.10 Storage media | N/A | No removable media in the production path. |
| A.7.11 Supporting utilities | Excluded | Provider responsibility. |
| A.7.12 Cabling security | Excluded | Provider responsibility. |
| A.7.13 Equipment maintenance | Excluded | Provider responsibility. |
| A.7.14 Secure disposal or re-use of equipment | Excluded | Provider responsibility; no YMRTECH-owned production hardware. |
Physical summary: 0 applied, 2 partial, 8 excluded, 4 N/A. This theme is almost entirely excluded because we rent our infrastructure. That is a truthful and defensible position for this scope — and it is exactly the kind of thing a misleading SoA would paper over by marking everything “applied”.
6. Technological controls (A.8 — 34 controls)
| Control | Status | Basis |
|---|---|---|
| A.8.1 User endpoint devices | Partial | Endpoint security is the customer’s responsibility and is explicitly out of scope; the operator’s own endpoint is encrypted and mesh-restricted. |
| A.8.2 Privileged access rights | Applied | Explicitly enumerated in configuration; privilege is minimal and reviewable as a diff. |
| A.8.3 Information access restriction | Applied | Access is deny-by-default, enforced by firewall and by declared configuration. |
| A.8.4 Access to source code | Applied | Review-gated repository; access is limited and visible. |
| A.8.5 Secure authentication | Applied | Key-only authentication; no password authentication on any system. |
| A.8.6 Capacity management | Partial | Monitoring exists; no formal capacity planning process. |
| A.8.7 Protection against malware | Partial | Declarative, pinned, reproducible builds sharply reduce the attack surface; no endpoint anti-malware. |
| A.8.8 Management of technical vulnerabilities | Partial | CVE surfacing in the build pipeline and a minimum-age dependency policy; no formal vulnerability-management process with SLAs. |
| A.8.9 Configuration management | Applied | The strongest control in this ISMS: the entire fleet is declarative configuration under version control with review and automated checks. |
| A.8.10 Information deletion | Applied | The no-log architecture means there is little to delete; retention exists for operational records and is bounded. |
| A.8.11 Data masking | Partial | Not broadly used; minimal data held makes it largely unnecessary. |
| A.8.12 Data leakage prevention | Applied | The architectural no-retention of customer activity is the most effective form of DLP available. |
| A.8.13 Information backup | Applied | Encrypted backups with a documented restore procedure. |
| A.8.14 Redundancy of information processing facilities | Partial | Some redundancy exists between hosts; single-provider reliance accepted (R-08). |
| A.8.15 Logging | Applied | Deliberate, minimal, and audited: the logging posture is asserted daily by a signed public report, including a canary probe. Very few organisations can evidence this control as directly. |
| A.8.16 Monitoring activities | Applied | Fleet-wide monitoring and alerting with an automated health gate and rollback. |
| A.8.17 Clock synchronisation | Applied | Time synchronisation is enforced by configuration; dated audit artifacts depend on it and would expose drift. |
| A.8.18 Use of privileged utility programs | Partial | Privileged tools exist and are constrained by configuration; no inventory document. |
| A.8.19 Installation of software on operational systems | Applied | Installation is only possible declaratively, through review and CI. Imperative installation is not the working model. |
| A.8.20 Networks security | Applied | Segmented networks, isolated client network, encrypted management mesh, default-deny. |
| A.8.21 Security of network services | Applied | Network services are declared, minimal, and firewalled; the management plane is not reachable from the internet. |
| A.8.22 Segregation of networks | Applied | Customer network, management mesh and public services are separated; client isolation is enforced by ACL. |
| A.8.23 Web filtering | Partial | Filtering exists as a service for network clients; not positioned as an organisational control. |
| A.8.24 Use of cryptography | Applied | Ed25519 signing for audit artifacts, WireGuard/AmneziaWG for transport, TLS for public services, SOPS/age for secrets. Key fingerprints published. |
| A.8.25 Secure development life cycle | Partial | Review + CI + declarative deployment is a real secure-development practice; not documented as a life cycle. |
| A.8.26 Application security requirements | Partial | Requirements are implicit in the design; not documented per application. |
| A.8.27 Secure system architecture and engineering principles | Applied | Zero-trust mesh, deny-by-default, minimal services, declarative rebuild — engineering principles applied consistently and documented in architecture material. |
| A.8.28 Secure coding | Partial | Configuration rather than application code dominates; the audit generator and site tooling are reviewed in CI. |
| A.8.29 Security testing in development and acceptance | Partial | CI performs build verification and the audit gate runs on every change; no formal security-testing phase. |
| A.8.30 Outsourced development | N/A | No outsourced development. |
| A.8.31 Separation of development, test and production environments | Partial | Branch previews and CI provide separation; there is no dedicated test environment for the whole fleet. |
| A.8.32 Change management | Applied | Every change is a reviewed commit; CI verifies; deployment is gated with automatic rollback on health violation. |
| A.8.33 Test information | N/A | No production data is used for testing (there is effectively no customer activity data to use). |
| A.8.34 Protection of information systems during audit testing | N/A | No third-party audit testing is conducted. Stated plainly on Standards. |
Technological summary: 18 applied, 13 partial, 0 planned, 0 excluded, 3 N/A. This is the strongest theme by a wide margin, and it is where the verifiable evidence concentrates.
7. Overall position
| Theme | Applied | Partial | Planned | Excluded | N/A |
|---|---|---|---|---|---|
| Organisational (37) | 8 | 22 | 4 | 2 | 1 |
| People (8) | 1 | 2 | 0 | 0 | 5 |
| Physical (14) | 0 | 3 | 0 | 10 | 1 |
| Technological (34) | 19 | 14 | 0 | 0 | 2 |
| Total (93) | 28 | 41 | 4 | 12 | 9 |
What this means, honestly: 27 controls fully applied, 40 partial, 3 planned. The technological half of the framework is in genuinely good shape and is backed by evidence stronger than most organisations can produce. The organisational half — policies, incident response, supplier review, independent review — is where the real work remains, and it is paperwork and process rather than engineering.
We do not claim certification, and this document is not a certification artefact. It is a statement of position, published so that anyone can hold us to it and so that progress is visible rather than asserted.
8. Review
| Date | Version | Change |
|---|---|---|
| 2026-09-18 | 1.0 | Initial statement of applicability; all 93 Annex A controls assessed. |