Security questionnaire

Denwen Ltd, registered in England and Wales, company number 12725457, registered office [TO CONFIRM: registered office address]. Denwen RMM is a registered trade mark of Denwen Ltd.

As a hosted, multi-tenant software-as-a-service platform only. There is no self-hosted edition. A Windows agent is installed on each managed endpoint.

security@denwen.co.uk for security matters and vulnerability reports; hello@denwen.co.uk for everything else. Named security owner: [TO CONFIRM: name and role of the person accountable for information security].

[TO CONFIRM: whether a written information security policy exists, its owner and review cycle]

Everyone Denwen authorises to process customer personal data is bound by confidentiality (DPA clause 4). Pre-employment screening: [TO CONFIRM: screening carried out (e.g. right to work, references, BPSS / DBS)].

[TO CONFIRM: security awareness training content and frequency]

[TO CONFIRM: insurance held and level of cover]

Processor for the data the service processes from customers’ endpoints and consoles; the customer is the controller. Where the customer is a managed service provider acting for its own clients, Denwen is a sub-processor. Denwen is controller only for its own website, account and billing data (see the Privacy Policy).

Yes, published at /legal/dpa. It contains each Article 28(3) term, (a) to (h), as a separate clause, plus provider-access controls, 48-hour breach notification, and UK IDTA / EU SCC terms for transfers. It is incorporated into the Terms of Service.

In the United Kingdom, on a server Denwen owns and operates itself at its own premises. No third-party hosting or cloud provider holds customer data. Sub-processors that may process data elsewhere, and the safeguard used, are listed on the sub-processors page.

Device inventory and telemetry (hardware, operating system, installed software, patches, performance), which can include usernames; event log entries queried by operators; remote desktop sessions and, where enabled, recordings of them; files transferred; scripts and their output; alerts and notification delivery logs; PSA ticket mappings; and the audit trail of console users’ actions, including names, email addresses and IP addresses.

Each tenant sets its own retention policy, enforced by a scheduled sweep that deletes expired data. Session recordings are capped at 90 days whatever the setting.

At the customer’s choice it is deleted or returned, within [TO CONFIRM: deletion period after end of service] (DPA clause 11). Backup copies roll off as the backup cycle rotates, within approximately 14 days. Written confirmation of deletion is available on request.

Yes (DPA clause 8). Customers can find and delete device data and recordings themselves in the console. Requests that reach Denwen directly are forwarded to the customer.

No. Customer data is processed only on the customer’s documented instructions (DPA clause 3). Only aggregated, de-identified operational information (such as error rates) is used to run and improve the service. If the optional Denwen AI assistant is enabled, its model runs on Denwen’s own hardware: prompts do not leave Denwen’s infrastructure, are not sent to any third-party AI provider, and are not used to train any model. Tenants that bring their own model send prompts to their own provider instead, and Denwen stores no completions.

ICO registration number: [TO CONFIRM: ICO registration number]. Privacy contact: hello@denwen.co.uk [TO CONFIRM: DPO or named privacy contact, if appointed].

No. Denwen staff have no standing access to any customer tenant’s devices or data through the service.

Only through a support access grant. Either the customer’s administrator creates it (Administration → Provider access), or Denwen staff request it and the customer’s administrator approves it. Each grant carries:

• a level — View (read-only), Manage (read and act, e.g. run scripts, change settings) or Control (Manage plus remote desktop);
• a separate choice whether session recordings may be viewed;
• a reason or ticket reference;
• a fixed duration, after which it expires automatically: Denwen staff can request 1 hour to 30 days; the customer’s administrator can grant, approve or renew for up to 365 days, optionally recording the support contract it rests on; and
• optionally, a single named Denwen staff member it applies to.

The customer can revoke a grant at any time. A renewal is recorded as a new grant in the customer’s audit log, with the old and new expiry, and the customer’s administrators are emailed seven days before a grant of 90 days or more ends.

In a security emergency affecting the customer, or to comply with a legal obligation, a Denwen administrator may open emergency access for at most 4 hours, with a written reason. The customer’s administrators are emailed immediately, the access is recorded in the customer’s audit log, and every use is reviewed afterwards.

Yes. Everything Denwen staff do inside a tenant appears in that tenant’s own audit log, marked “Provider staff”. The audit log is append-only.

No. Remote desktop sessions by Denwen staff always show the end-user consent prompt when someone is signed in at the device and it is unlocked, whatever the tenant’s own consent setting, and Denwen staff cannot change a tenant’s consent setting. When nobody is signed in, or the computer is locked, nobody can be asked; the customer’s grant is then the authorisation, and the session is recorded in their audit log.

Multi-factor authentication is mandatory; remembered-device trust is not available to them; their sessions are shorter than customer sessions; and they can be restricted to approved IP addresses. Platform-level API keys cannot reach customer data at all.

No. Alerts from a customer’s devices are delivered only to that customer’s own notification channels and PSA, never to Denwen.

The controls above govern access through the service. A limited number of authorised Denwen personnel administer the servers, database and backups the service runs on, which is necessary to operate it. That access is bound by confidentiality and is not used to view or act on customer data except as strictly necessary to operate, secure, back up or restore the service (DPA clause 6.7). Because recordings are encrypted with a platform-managed key rather than a customer-held key, this is a matter of control and trust, not cryptography. Number of personnel with infrastructure access: [TO CONFIRM: number and roles].

Yes. Time-based one-time passwords (TOTP). Mandatory for all Denwen platform staff; optional for customer users and enforceable per tenant by the customer.

Yes, through OpenID Connect. Microsoft Entra ID is supported. The identity provider is chosen and controlled by the customer.

Yes. Roles are editable by the customer, and each role assignment can be scoped to specific sites, so an operator can be limited to the part of the estate they look after.

Hashed; plain-text passwords are never stored. A generated password is shown once and cannot be read again.

An API key acts only for the organisation that issued it, and is confined by the same tenant and permission checks as a person. Platform-level keys cannot reach customer data.

Customers manage their own users and roles in the console, and every sign-in, role change and key issue or revocation is in the audit log for review. Denwen’s own joiner/leaver and access review process for staff: [TO CONFIRM: process and frequency].

Yes. TLS for all connections: console, API, agents and remote session relay. Minimum TLS version and cipher policy: [TO CONFIRM: minimum TLS version].

Yes. AES-256-GCM envelope encryption: each recording is encrypted with its own data key, which is in turn protected by a platform-managed master key.

No. Keys are managed by the platform; customer-held or customer-managed keys are not offered.

[TO CONFIRM: database / disk encryption at rest]

Webhook secrets, SMTP passwords, single sign-on client secrets and AI provider keys are sealed at rest and are never returned to any console after being saved.

[TO CONFIRM: backup encryption]

Yes. It records who acted, what they touched, which tenant it belonged to, when, and from which IP address — including sign-ins and failures, role changes, API key issue and revocation, every script, patch and uninstall with its outcome, and changes to retention and recording policy with the previous value.

Yes. Updates and deletes on the audit table are refused by a database trigger, so the log is append-only regardless of application behaviour.

Yes, in the customer’s own audit log, marked “Provider staff”.

[TO CONFIRM: audit log retention period]

Logically, on shared infrastructure. Tenant scoping is enforced on the server for every request, in the database query itself rather than by filtering results afterwards.

The request is answered with HTTP 404 (“not found”), never 403, so the API cannot be used to confirm that another tenant’s device exists.

Yes. Isolation is covered by automated tests that run on every build; the security page lists each tested claim with the test file and the number of assertions, and the build fails if they drift.

Yes. Each client can be a separate tenant, and providers that resell through partners can use a tenant hierarchy. Operators can be scoped to specific tenants and sites.

Yes. The Windows agent is code-signed, and agent updates are signed installers that the agent verifies before replacing itself.

State-changing commands (script execution, patch deployment, software uninstall, lifecycle commands) are signed (V3 envelope, ECDSA) and checked on the endpoint for signature, key identifier, sequence and expiry before anything runs. A command that fails any check is refused and recorded. The signing keys are held separately from the application database. A compromised relay, DNS record or proxy therefore cannot forge commands; an attacker able to use the platform’s signing key could.

Each command carries a sequence number and an expiry, and is bound to a per-connection epoch, so a captured command cannot be replayed later or on a different connection.

As a Windows service with SYSTEM privileges, which is required to manage the endpoint. That is why the controls in AGT-01 to AGT-03 exist.

Yes. An Allow/Refuse consent prompt, configurable at platform, tenant, site and device level. It is always shown for sessions started by Denwen staff when a user is signed in.

Yes. An on-screen notice is shown on the endpoint whenever a session is being recorded.

Yes. A remote session with no operator activity is ended after an idle timeout, 15 minutes by default.

Encrypted at rest (ENC-02), visible only to users whose role allows it (and to Denwen staff only under a grant that explicitly includes recordings), and deleted under the tenant’s retention policy, at most 90 days.

Not yet by an independent third party. Denwen carries out its own security testing of the service, including the tenant-isolation and provider-access controls described above, which are also covered by automated tests on every change. Date and summary of the most recent internal assessment: 17–18 October 2026, an external test of the live service from outside the application plus a full review of its source code. One high-severity and four medium-severity findings were fixed and in production by 18 October 2026; the low-severity findings are being worked through. A test from the public internet, and an independent third-party test, are still to come.

By email to security@denwen.co.uk. Please report privately before disclosing. Remediation targets by severity: [TO CONFIRM: vulnerability remediation SLAs].

Every build runs type checking, automated test suites (including the security-claim tests named on the security page), and design and accessibility gates, and fails on any error. Code review, dependency vulnerability scanning and static analysis: [TO CONFIRM: describe what is in place].

[TO CONFIRM: server operating system patching process and frequency]

Without undue delay and in any event within 48 hours of becoming aware of it, with the information needed for your own Article 33 notification (DPA clause 10).

[TO CONFIRM: incident response plan, owner and last test]

Yes. Your administrators are emailed immediately, and it is recorded in your audit log (PRV-03).

Nightly. Seven backups are kept on the production server and fourteen are copied, with a checksum verified on every copy, to a separate Denwen-owned machine. Both are at Denwen’s premises in the United Kingdom; there is not yet a copy at a second, geographically separate location. No third-party storage provider is used.

With nightly backups, the recovery point is up to 24 hours. Recovery time objective: [TO CONFIRM: RTO]. Frequency of restore tests: [TO CONFIRM: restore testing].

[TO CONFIRM: high availability / failover arrangements]

No availability commitment applies by default (Terms clause 3.4). Enterprise plans include a response SLA agreed in contract.

None at present. Denwen does not hold ISO/IEC 27001 certification, a SOC 2 report or Cyber Essentials / Cyber Essentials Plus certification. The controls described here are real and can be inspected during a trial; an auditor’s attestation is a separate thing and we do not claim one.

The mapping below shows which of the controls above address each requirement. It is our own assessment, not a certification or third-party audit.

We act as a processor under a published Article 28 DPA, store customer data in the UK, and provide the information and assistance customers need as controllers. Customers remain responsible for the lawfulness of their own monitoring and for informing their users.