Every document, published in full

The principles we work to

Describe only what is true. A control this page describes is a control we have and can evidence to your security reviewer. We do not describe a control we lack as though we had it.

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.

• —Encryption in transit: traffic between browsers, our applications and our endpoints is encrypted with TLS 1.2 or higher using strong cipher suites, plain HTTP is permanently redirected to HTTPS, and HTTP Strict Transport Security is enforced. Screenshots are uploaded to storage over encrypted connections. Certificates are issued and renewed automatically.
• —Encryption of credentials and secrets: integration credentials and access tokens, single sign-on secrets and certificates, two-factor authentication seeds, provisioning tokens and per-organization signing keys are encrypted at the application layer with AES-256 authenticated encryption. Passwords are stored only as salted one-way hashes.
• —Access control: role-based, least-privilege, scoped to an organization by the credential and scopable to a node within it. Single sign-on and two-factor authentication are available, and administrators can restrict the sign-in methods their organization accepts.
• —Staff access: limited to personnel who need it and recorded on the audit trail. Every member of our staff must complete two-factor authentication to sign in to our administration console.
• —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, protection against framing by unauthorized sites, rate limiting on public endpoints, and databases that are not reachable from the public internet.

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 two-factor authentication where your plan offers them, and ask your administrators to turn two-factor authentication on for their own accounts.
• —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, a detailed description of our controls and their current limitations, 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. The description of our controls and their limitations is provided to customers and prospective customers under a non-disclosure agreement, and some of the other documents are too.

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.