| Document ID | ISMS-SOA-001 |
| Version | 0.1 |
| Status | Draft |
| Classification | Internal |
| Owner | Information Security Officer |
| Approved by | Managing Director |
| Approval date | pending |
| Effective from | pending |
| Next review | Annually, and on every material ISMS change |
| Mandatory under | ISO/IEC 27001:2022 clause 6.1.3 d) |
This Statement of Applicability (SoA) is the master index that maps
every Annex A control of ISO/IEC 27001:2022 to:
Auditors typically open the SoA first; from here, every applicable
control should be traceable to the artefact that evidences it.
| # | Control | Status | Justification / Implementation |
|---|---|---|---|
| A.5.1 | Policies for information security | Y | Information Security Policy and the topic policies under /isms/policies. |
| A.5.2 | Information security roles and responsibilities | Y | InfoSec Policy §5 defines roles. The dual-role acknowledgement §5.1 records the sole-proprietor compensating controls. |
| A.5.3 | Segregation of duties | Y* | Sole-proprietor — full segregation not achievable. Compensating controls in InfoSec Policy §5.1; residual risk R-001 in Risk Register. |
| A.5.4 | Management responsibilities | Y | Managing Director owns the ISMS; see InfoSec Policy §5. |
| A.5.5 | Contact with authorities | Y* | Sächsischer Datenschutzbeauftragter is the relevant supervisory authority for personal-data matters; see Incident Response Policy §7.3. To formalise: documented contact list under /isms/authorities-and-groups (planned). |
| A.5.6 | Contact with special interest groups | Y* | At minimum: subscription to relevant CERT advisories (Bund, BSI, vendor advisories for Veeam / Proxmox). To formalise on the (planned) page above. |
| A.5.7 | Threat intelligence | Y* | Currently informal — vendor advisories and BSI notices. To formalise into a recurring review item. |
| A.5.8 | Information security in project management | Y | The development of wiki-cms and any new service brings information security into design from the start; documented in the Secure Development Policy (planned). |
| A.5.9 | Inventory of information and other associated assets | Y | Asset Inventory. |
| A.5.10 | Acceptable use of information and other associated assets | Y* | Acceptable Use Policy (planned). |
| A.5.11 | Return of assets | Y* | Sole-proprietor at present; will become substantive when staff or contractors are engaged. To be drafted with the Personnel Security Policy (planned). |
| A.5.12 | Classification of information | Y* | Initial four-tier scheme in Assets; full Data Classification Policy (planned). |
| A.5.13 | Labelling of information | Y* | To be specified within the Data Classification Policy (planned). |
| A.5.14 | Information transfer | Y* | Vaultwarden Send is the standard channel for credential transfer (Access Control Policy §6). Full Information Transfer Policy (planned). |
| A.5.15 | Access control | Y | Access Control Policy. |
| A.5.16 | Identity management | Y | Access Control Policy §4 — current state (no central IdP) plus compensating controls. |
| A.5.17 | Authentication information | Y | Access Control Policy §5. |
| A.5.18 | Access rights | Y | Access Control Policy §9 — quarterly review against Vaultwarden inventory. |
| A.5.19 | Information security in supplier relationships | Y | Sub-processor Register. Supplier Security Policy (planned). |
| A.5.20 | Addressing information security within supplier agreements | Y* | Hetzner DPA in place; customer-facing DPA template R-005 in the risk register, sequenced after operational documentation completes. |
| A.5.21 | Managing information security in the ICT supply chain | Y* | Sub-processor security attestations recorded as part of the supplier register's annual review. |
| A.5.22 | Monitoring, review and change management of supplier services | Y* | Annual supplier review committed in the Sub-processor Register §4. |
| A.5.23 | Information security for use of cloud services | Y* | Hetzner is the principal cloud-service provider; specifics to be folded into the Supplier Security Policy (planned). |
| A.5.24 | Information security incident management planning and preparation | Y | Incident Response Policy. |
| A.5.25 | Assessment and decision on information security events | Y | Incident Response Policy §5–§6. |
| A.5.26 | Response to information security incidents | Y | Incident Response Policy §5. |
| A.5.27 | Learning from information security incidents | Y | Incident Response Policy §5 step 8; post-mortems under /incidents/post-mortems/. |
| A.5.28 | Collection of evidence | Y | Incident Response Policy §8. |
| A.5.29 | Information security during disruption | Y | Business Continuity Plan. Business Continuity Policy (planned) will state the policy intent. |
| A.5.30 | ICT readiness for business continuity | Y | Backup Policy + BCP §5. |
| A.5.31 | Legal, statutory, regulatory and contractual requirements | Y* | Compliance / Legal Register (planned). |
| A.5.32 | Intellectual property rights | Y* | Software license obligations (Veeam, MinIO, Vaultwarden, Microsoft 365, Lexoffice) tracked alongside the supplier register. To formalise on the Compliance Register (planned). |
| A.5.33 | Protection of records | Y* | Retention rules to be folded into a Records Management section and the SoA. |
| A.5.34 | Privacy and protection of PII | Y* | Privacy / Personal Data Policy (planned) — mapping GDPR / BDSG obligations. |
| A.5.35 | Independent review of information security | Y* | Compensating control under sole-proprietor regime: external review at planned intervals; see InfoSec Policy §5.1. |
| A.5.36 | Compliance with policies, rules and standards for information security | Y* | Internal audit programme and management review, both (planned). |
| A.5.37 | Documented operating procedures | Y | The Runbooks section. Currently: Restore Procedure; others (planned). |
| # | Control | Status | Justification / Implementation |
|---|---|---|---|
| A.6.1 | Screening | Y* | Sole proprietor — self-declaration. To formalise as part of the Personnel Security Policy (planned) in advance of any future hiring. |
| A.6.2 | Terms and conditions of employment | Y* | Will become substantive on first hire / contractor engagement. Template to live with the Personnel Security Policy. |
| A.6.3 | Information security awareness, education and training | Y* | Risk Register R-012 — annual external training course + self-attestation. Records will accumulate in Training log (planned). |
| A.6.4 | Disciplinary process | Y* | For the sole proprietor: contractual obligation to customers and the supervisory authority. Future personnel: standard disciplinary process under German labour law, captured in the Personnel Security Policy. |
| A.6.5 | Responsibilities after termination or change of employment | Y* | Vaultwarden share-revocation and access-removal rules in the Joiner/Mover/Leaver procedure (planned). |
| A.6.6 | Confidentiality or non-disclosure agreements | Y* | Customer contracts include confidentiality obligations. Standalone NDA template (planned). |
| A.6.7 | Remote working | Y | Personal laptop (BYOD) used from home; covered by the Access Control Policy §10 (FDE, Defender, MFA, screen lock). Acceptable Use Policy (planned) will state the user-side rules in full. |
| A.6.8 | Information security event reporting | Y | Incident Response Policy §4. |
| # | Control | Status | Justification / Implementation |
|---|---|---|---|
| A.7.1 | Physical security perimeters | Y | Basement server room: locked metal door + CCTV; Hetzner data centres: ISO 27001 certified. Full statement in Physical Security Policy (planned). |
| A.7.2 | Physical entry | Y | Basement: key-controlled access. Hetzner: provider-controlled. |
| A.7.3 | Securing offices, rooms and facilities | Y* | Basement gaps in Risk Register R-003 (window, no climate control). |
| A.7.4 | Physical security monitoring | Y | 24/7 CCTV with 30-day retention on the basement server room. |
| A.7.5 | Protecting against physical and environmental threats | Y* | Self-hosted fire alarm in place; climate control absent (R-003). |
| A.7.6 | Working in secure areas | Y* | To be specified in the Physical Security Policy (planned). |
| A.7.7 | Clear desk and clear screen | Y* | To be specified in the Acceptable Use Policy (planned). |
| A.7.8 | Equipment siting and protection | Y | Basement server room and Hetzner data centre — both physically controlled environments. |
| A.7.9 | Security of assets off-premises | Y | BYOD laptop covered by Access Control Policy §10; to be reinforced in the Acceptable Use Policy. |
| A.7.10 | Storage media | Y* | LUKS at rest on pve03 and (where enabled) MinIO Object Lock on the basement target. Full media handling rules in the Cryptography Policy (planned). |
| A.7.11 | Supporting utilities | Y* | UPS in basement (to be inventoried); Hetzner provides utility resilience for hosted assets. |
| A.7.12 | Cabling security | Y* | Basement scope. To be documented in the Physical Security Policy. |
| A.7.13 | Equipment maintenance | Y* | To formalise into a maintenance schedule. |
| A.7.14 | Secure disposal or re-use of equipment | Y* | Currently informal disk wipes; certificate-of-destruction template tracked under Risk Register R-010. |
| # | Control | Status | Justification / Implementation |
|---|---|---|---|
| A.8.1 | User endpoint devices | Y | Access Control Policy §10 — BYOD laptop, BitLocker, Defender, MFA. |
| A.8.2 | Privileged access rights | Y* | Access Control Policy §8; separate Privileged Access page (planned). |
| A.8.3 | Information access restriction | Y | Vaultwarden vault scoping per customer; Tailscale ACLs for management network. |
| A.8.4 | Access to source code | Y* | wiki-cms repository protection — branch protection / signed commits to formalise. |
| A.8.5 | Secure authentication | Y | Access Control Policy §5. |
| A.8.6 | Capacity management | Y* | Monitoring tooling in place; thresholds and review cadence to formalise. |
| A.8.7 | Protection against malware | Y | Microsoft Defender on the work laptop; provider-side controls on Hetzner. Customer-side: out of BackupExperts scope but included in customer awareness materials. |
| A.8.8 | Management of technical vulnerabilities | Y* | Patching cadence not formalised — see pve03 §4 open items. |
| A.8.9 | Configuration management | Y | infra-as-code Ansible repository as source of truth for hypervisor + network configuration. |
| A.8.10 | Information deletion | Y* | Customer offboarding runbook (planned) will record the deletion procedure for GDPR Article 17. |
| A.8.11 | Data masking | N | Not applicable — BackupExperts does not produce or share data sets requiring masking; customer data remains under customer control and is not analysed or aggregated by BackupExperts. |
| A.8.12 | Data leakage prevention | Y* | Vaultwarden + MFA + endpoint hardening reduce the dominant DLP vectors. Formal DLP tooling not in place; risk acknowledged. |
| A.8.13 | Information backup | Y | Backup Policy; Restore Procedure. |
| A.8.14 | Redundancy of information processing facilities | Y* | Hardware RAID1 on pve03; basement off-site copy. Second off-site copy from BackupExperts side: R-002. |
| A.8.15 | Logging | Y | Proxmox host logs, Tailscale audit logs, Hetzner control-panel logs, fail2ban logs. Retention rules to formalise. |
| A.8.16 | Monitoring activities | Y* | Monitoring tooling in place; alert acknowledgement procedure to formalise. |
| A.8.17 | Clock synchronization | Y | NTP on hypervisor and VMs (Debian default). |
| A.8.18 | Use of privileged utility programs | Y | Limited to root on hypervisor and Vaultwarden-stored credentials; Access Control Policy §8. |
| A.8.19 | Installation of software on operational systems | Y | Changes via infra-as-code Ansible playbooks on the hypervisor; per-VM via standard package management; recorded in the change log when authored. |
| A.8.20 | Networks security | Y | Hetzner Robot firewall (perimeter); host iptables (NAT/DNAT); Tailscale (management overlay). |
| A.8.21 | Security of network services | Y | Same as A.8.20 plus TLS on customer-facing services. |
| A.8.22 | Segregation of networks | Y | Public bridge vmbr0 vs. internal vmbr2 on pve03; Tailscale tailnet for management. |
| A.8.23 | Web filtering | Y* | At endpoint level (Defender SmartScreen). Acknowledged as minimal; revisit if scope expands. |
| A.8.24 | Use of cryptography | Y* | LUKS at rest on pve03; Object Lock on MinIO (per-bucket — see R-011); TLS in transit. Full Cryptography Policy (planned). |
| A.8.25 | Secure development life cycle | Y* | wiki-cms and other internal development covered by Secure Development Policy (planned). |
| A.8.26 | Application security requirements | Y* | As above. |
| A.8.27 | Secure system architecture and engineering principles | Y* | As above. |
| A.8.28 | Secure coding | Y* | As above. |
| A.8.29 | Security testing in development and acceptance | Y* | As above. |
| A.8.30 | Outsourced development | N | Not applicable — BackupExperts does not currently outsource software development. To re-evaluate if this changes. |
| A.8.31 | Separation of development, test and production environments | Y* | wiki-cms: development on local laptop, push to repository, deploy through controlled publish. To document in the Secure Development Policy. |
| A.8.32 | Change management | Y | All host-level changes via infra-as-code; per-page changes via the wiki-cms publish flow with dry-run preview. Change log (planned). |
| A.8.33 | Test information | Y* | Dummy / scrubbed data only in any test scenario; no production customer data in non-production contexts. To formalise. |
| A.8.34 | Protection of information systems during audit testing | Y* | Audit testing on production restricted to read-only operations. To document explicitly. |
Of the 93 Annex A controls:
The roadmap to take Y* controls to Y is the ISO 27001 Roadmap.
This SoA is reviewed:
Each material change is recorded in the revision history.
| Version | Date | Notes |
|---|---|---|
| 0.1 | issue date | Initial issue. |