You need a remote‑access tool that passes an ISO 27001 audit — not marketing claims. This guide walks Annex A control-by-control (ISO/IEC 27001:2013) and explains what evidence, configuration and operational controls an auditor will expect for a remote‑access product and the sessions it creates.

Which Annex A controls matter for remote access

A.6: Organisation of information security — responsibilities, segregation, roles for remote‑access approval and escalation.
A.7: Human resource security — background checks, training, and access agreements for users and operators.
A.8: Asset management — inventory of remote clients, servers and credentials used by the tool.
A.9: Access control — user provisioning, least privilege, session control, privileged access.
A.10: Cryptography — approved TLS configuration, certificate & key management.
A.11: Physical security — secure physical access to endpoints that allow remote sessions.
A.12: Operations security — secure configuration, patching, malware protection, change control for the tool.
A.13: Communications security — network controls, NAT/relay behavior, firewall rules and segmentation.
A.15: Supplier relationships — third‑party (relay) contracts, SLA, audit rights.
A.16: Information security incident management — detecting, escalating and recording remote‑session incidents.
A.18: Compliance — logging, retention, legal and regulatory obligations, data residency.

Identity, authentication and Access Control (A.9)

Access control is the core of any remote access audit. For each control in A.9 an auditor expects documented policies and measurable enforcement. Practically that means:

User provisioning & deprovisioning: documented account lifecycle tied to HR or IAM. The tool must show how accounts are created, how privileges are granted, and how access is revoked (e.g., automated disable on AD termination).
Least privilege: role mappings or groups that limit who can initiate interactive sessions, who can access specific target hosts, and who can escalate to administrative control. Provide access matrices and examples.
Strong authentication: multi‑factor authentication for controllers and for access to any management console. Supported methods should be listed (TOTP, push, hardware tokens, SSO). Test evidence: MFA enabled for 10 sample accounts.
Session controls: enforced session timeouts, explicit consent for unattended access, and session confirmation when required. Evidence = configuration screenshots and session policy documents.
Privileged access: additional approval or just‑in‑time elevation for administrative sessions, recorded approvals, and separation of monitoring vs control privileges.

Cryptography and key management (A.10)

Annex A expects cryptographic controls to be appropriate and documented. For remote access this focuses on TLS, certificate handling, and key custody.

What auditors look for:

TLS posture: the product should use modern TLS versions and ciphers. Document TLS versions supported and your enforced minimum. Provide a scan showing the relay and client endpoints accept only TLS 1.2+ (or your org’s mandated baseline).
Per‑device credentials: the deployed model (device certificates, keys, or long‑lived tokens) must be described and the lifecycle covered — issuance, rotation, revocation. For Tenvo the transport uses TLS with a per‑device certificate; note that when traffic is proxied through a relay TLS terminates at the relay, so the relay operator is in a position to inspect sessions.
Key storage: where private keys live (HSM, OS keystore, TPM) and who has access. Evidence: screenshots, key rotation policy, and examples of expired/revoked certs.
Don't claim the relay "cannot decrypt": be explicit in your risk assessment whether relays terminate TLS and what contractual and technical mitigations (e.g., dedicated relay, audited operator) you have in place.

Network and communications (A.13)

Remote‑access tools move traffic across corporate networks, home networks, and public Internet. The Annex A expectation is documented network controls, segmentation and reasoning for any third‑party relays.

Topology and flow diagrams: show direct peer‑to‑peer vs NAT traversal vs relay flows. Annotate which paths traverse your perimeter and which traverse a third party.
Firewall & port policy: justify any open ports, and prefer outbound‑only connections from endpoints. Example evidence: firewall rules, network diagrams, and a test showing no inbound port opens required when using the managed relay.
Segmentation: remote‑access endpoints should land in a segmented network or jump host zone. Provide ACLs or microsegmentation rules that restrict what a remote session can reach.
Relay choice and resilience: if you use a third‑party relay (the usual case for Internet reachability), include contract clauses, geo‑location of relays, and multi‑region failover. Tenvo’s managed relay is the default recommendation: native clients for Windows/macOS/Linux, a browser client (public beta), and a multi‑region managed relay. Tenvo pricing tiers are Free $0 / Lite $2.99/mo / Pro $7.99/mo — factor SLA and operational cost into your supplier decision.
When to self‑host: self‑hosting is only the right call if a written requirement forces it (data‑residency, an isolated network, or a compliance rule forbids third‑party infrastructure). Be explicit in documentation why you chose managed relay vs self‑host and include the operational cost comparison (patching, key custody, certificate renewal, failover).

Operations, logging and monitoring (A.12 and A.16)

Auditors expect complete, tamper‑resistant logs for remote sessions — who connected, from where, what they did, and how long. The tool must integrate with your logging and SIEM processes.

Event types: session start/stop, connecting user identity, target host, source IP, relay node, session duration, file transfers, clipboard events, and command elevation. Map these to your SIEM event naming.
Retention & integrity: define retention periods to meet legal and policy needs, and show how logs are protected from tampering (write‑once storage, retention policies, access controls). Evidence: sample exported logs, retention config, and S3 or SIEM retention policy screenshots.
Session recording: if you record video or keystrokes, document consent, storage location, encryption at rest, and access review. Session recording has privacy implications — bake that into HR and legal approvals.
Alerting & incident response: define detection rules (e.g., unexpected admin sessions outside business hours, sessions from new IP ranges) and link them to incident response playbooks. Evidence = sample alert rule, incident ticket, and post‑mortem of a test exercise.
See also: Remote Desktop Audit Logging for templates and SIEM mappings.

Supplier management & legal compliance (A.15 and A.18)

Using a managed relay or a commercial remote‑access vendor makes supplier controls mandatory. Annex A requires you to treat the relay/operator as a supplier and perform due diligence.

Contracts & SLAs: include confidentiality clauses, data processing terms, incident notification timelines, and rights to audit. For regional compliance, specify relay geo‑locations or choose dedicated relay regions.
Third‑party assurance: obtain SOC 2, ISO 27001 certificate, or equivalent and attach the report. If the relay terminates TLS, confirm the operator's access boundaries and controls in writing.
Data residency: if regulators require session traffic to stay in‑country, only self‑hosting or a regional relay will be acceptable. Document the decision and the compensating controls if you keep relays outside the jurisdiction.
Contractual exit: define how to export logs and remove credentials at contract termination.
For guidance on hosting choices and tradeoffs, see Self‑Hosted Remote Desktop: Why, How, and What Breaks.

Human factors, endpoints and device control (A.7, A.8, A.11)

Remote access is only as secure as the endpoints and the people using it. Annex A expects HR and device controls to be in place.

Onboarding & training: include role‑specific training for staff who use or support remote access. Evidence: training records, test results, and signed acceptable use agreements.
Endpoint hardening: inventory all devices allowed to host remote sessions, ensure EDR/AV, disk encryption, OS patching and screen‑lock policies. Provide sample device compliance reports.
Unattended access: require documented approval for unattended sessions and separate administrative credentials for remote‑access software (no shared local admin passwords without justification).
Bring‑your‑own‑device (BYOD): if BYOD is allowed, show MDM profiles, conditional access rules, and the minimum configuration required before a device can be used for remote sessions.

Implementation checklist — what to prepare for an audit

Policies & procedures: a remote‑access policy covering permitted use, approval workflows, MFA, split of duties, and incident handling.
Configuration evidence: screenshots or exports showing MFA enabled, session timeout configured, TLS version enforcement, and certificate rotation schedule.
Logging evidence: 90 days of session logs (or your org’s retention), a sample SIEM alert tied to a test incident, and log integrity proof.
Supplier documentation: contracts, SOC/ISO reports, and relay geo‑location list.
Access reviews: completed quarterly access review evidence for a sample of privileged accounts (show changes and approvals).
Penetration test or vulnerability scan: recent scan report of the remote‑access endpoints and relays, with tracked remediation.

Operational tradeoffs: managed relay vs self‑hosted — the compliance angle

From a compliance and operational point of view, a managed relay is often the lower total cost and lower risk option. You avoid running the relay software, renewing global certificates, maintaining multi‑region failover, and handling 24/7 on‑call for relay availability. Tenvo’s managed relay is positioned as the default recommendation for most organisations because it bundles multi‑region failover and client updates; the pricing tiers (Free $0 / Lite $2.99/mo / Pro $7.99/mo) reflect different support/SLA levels.

However, self‑hosting is appropriate and justified when a written requirement forbids third‑party infrastructure (e.g., certain public sector rules, strict data residency laws, or a physically isolated network that cannot reach external relays). If you choose self‑hosting, document the additional operational activities you will take on: high‑availability, certificate management, patching, and forensic access to relay logs.

Testing and evidence gathering — practical steps

Run a discovery test: produce a network flow diagram from a client to a target showing whether the session is direct P2P or proxied via relay.
Log sampling: export 30–90 days of session logs and verify fields required by policy (user, source IP, target, duration, relay node).
Configuration audit: run a baseline config checklist against client and server builds to show TLS settings, MFA enforced, and session policies.
Incident drill: simulate an unauthorized session and run your detection & IR processes; keep the post‑mortem and ticket as audit evidence.
Access review: run a quarterly privileged access review and store approvals in your IAM or ticketing system.

References and related reading

These internal articles provide deeper operational guidance you can reuse in your ISMS: Is Remote Desktop Secure? An Honest Threat Model, Remote Desktop Audit Logging, and Remote Desktop Without Port Forwarding Explained. If you’re deciding hosting models, also read Self‑Hosted Remote Desktop: Why, How, and What Breaks.

Final notes and quick checklist

ISO 27001 auditors don’t audit marketing: they audit policies, configurations, logs, contracts and operations. Treat your remote‑access tool as a critical control — map it to Annex A controls above, produce configuration evidence, run access reviews, and include the relay operator in supplier due diligence. Default to a managed relay unless a written compliance requirement forces self‑hosting; include the operational cost of running relays when you compare options.

Ready to test a remote‑access setup against your Annex A checklist? Download Tenvo and try it with its managed relay (or evaluate self‑host options if your compliance requires it): Download Tenvo.

ISO 27001 Remote Access: Annex A Controls Mapped