Every document, published in full

The principles we work to

State what is true, including when it is unflattering. A control we describe is a control we can show you in the source. A control we lack is disclosed rather than omitted, because a buyer who catches one overstated claim is right to distrust every other one.

Isolate by construction, not by convention. Tenant separation is derived from the credential and enforced in the data layer, so a request cannot reach another organization's data by changing an identifier in it.

Make the watchers watchable. Every consequential action, including every access to captured material and every staff action, lands on a tamper-evident chain that the customer can inspect and re-verify.

Collect less. Input activity is counted rather than captured, capture policy is enforced on the device before anything leaves it, and retention deletion is automatic and irreversible.

How the platform is protected

A summary; Annex II of the Data Processing Addendum has the detail and the caveats.

• —Transport security: TLS 1.2 or better with AEAD-only cipher suites, permanent redirect from HTTP, HSTS with a two-year max-age, includeSubdomains and preload, and automated certificate issuance and renewal.
• —Encryption of secrets: AES-256-GCM authenticated field encryption with a fresh random initialization vector per value protects integration credentials, single sign-on secrets, multi-factor seeds, provisioning tokens and per-organization signing keys. The master key is mandatory in production and the platform refuses to start without it.
• —Access control: role-based, least-privilege, scoped to an organization by the credential and scopable to a node within it. Single sign-on and multi-factor authentication are available.
• —Auditability: a hash-chained, tamper-evident record of configuration changes, permission grants, data access, exports and staff actions.
• —Resilience: continuous archiving with point-in-time recovery, automated backups and tested restore procedures.
• —Secure development: peer-reviewed, version-controlled changes; automated test suites gating merges; dependency and container scanning in the build pipeline; secrets held in an encrypted store rather than in the repository.
• —Hardening: security headers applied application-wide, framing denied except for an explicit allow-list of partner-embedded widget routes, rate limiting on public endpoints, and a data tier on an internal-only network with no published ports.

What we do not yet have

We publish this list rather than waiting to be asked. Each item is tracked with an owner and a remediation commitment, and each is available to your security reviewer in writing.

• —No blanket encryption at rest for monitoring content. Field encryption covers our secrets; screenshots, window titles, activity counts and clock-in coordinates are stored without application-layer encryption, and the deployment does not yet use volume-level encryption. Verified storage-level encryption is committed work.
• —No key-management service and no bring-your-own-key capability. Do not accept a BYOK claim from us today.
• —No independent penetration test has yet been performed. Commissioning one is committed work.
• —No enforced multi-factor authentication for customer administrators. It is available and we recommend enabling it.
• —No database row-level security; isolation is enforced by schema constraints and by the credential rather than by the database's own row policies.
• —Deactivating a user does not immediately invalidate an already-issued session token.
• —Internal traffic between components on the host is not separately encrypted; it runs on an internal-only network with no published ports.
• —No certifications are held, and no SOC 2 or ISO 27001 report exists to share.

Your side of the boundary

Security is shared. The controls below are yours, and the platform cannot supply them for you.

• —Decide who gets access, review it regularly, and remove it promptly when someone leaves.
• —Enable single sign-on and multi-factor authentication where your plan offers them.
• —Keep credentials, API keys and signing secrets out of code repositories, mobile and browser bundles, support tickets and screenshots. Rotate them when someone leaves and immediately on suspected exposure.
• —Keep administrator contact details current, because that is where breach and sub-processor notices go.
• —Configure capture policy — deny lists, blurring, retention — so that the platform collects no more than your legal basis and your notices cover.
• —Secure the devices the agent runs on and the systems you connect the platform to.

When something goes wrong

We maintain a documented incident-response plan with severity classification, containment, investigation, notification and post-incident review, and we record every incident and its outcome. A summary of the plan is available on request.

Where we become aware of a personal-data breach affecting Customer Data, we notify the affected customer without undue delay and in any event within 48 hours, with the detail set out in the Data Processing Addendum. That obligation is contractual and is not limited by the Service Level Agreement.

We publish a summary of what happened and what we changed after a significant incident.

Reporting a vulnerability

Report security issues to security@workmonitor.ai under our Vulnerability Disclosure Policy, which sets out what is in scope, what we ask of you, and the safe-harbour commitment we make to researchers who follow it.

Do not report a vulnerability through support, through the in-product messenger, or in a public issue. Those routes are not confidential.

Documents a security review can ask for

Our completed security-questionnaire responses, our control inventory with source references, our open gap list, our incident-response plan summary, our business continuity and disaster recovery plan, our transfer impact assessment summary, and the data-processing terms we hold with a named sub-processor.

Ask at security@workmonitor.ai or legal@workmonitor.ai. Some are provided under a confidentiality undertaking.

Changes to this policy

We will update this policy as our controls change, and we will not reduce the measures in Annex II of the Data Processing Addendum in a way that materially lowers the level of security. Changes are recorded in the Legal Change Log.