What IT and data protection teams ask first

What the client records

The client groups the windows of one application into a session. A session becomes one row, and everything below is a field on that row. The full field list, with notes, is on the data collected page of the documentation.

What is never collected

None of the following is captured, uploaded or stored, and none of it can be switched on by a setting.

• ×Screenshots or screen recording of any kind
• ×Keystroke contents. Typing is measured as a duration; what was typed is never read
• ×Clipboard contents
• ×Camera or microphone. The client does not request access to either
• ×File contents, file paths or the contents of documents
• ×Email, chat or call contents. The client can tell a meeting is happening; nothing inside it is read
• ×Location or GPS
• ×Passwords or form contents
• ×Anything while tracking is off for the account, and anything outside configured working hours

Working hours and the corporate list

Nothing is recorded outside the working days and hours configured for the organization or the person. Within working hours, the corporate list decides attribution: time in listed applications and websites is recorded under the person's name, and everything else is recorded against an anonymous identifier, so it counts at group level but cannot be traced to an individual.

That decision is made on the machine before anything is uploaded, not by filtering afterwards. An organization without a corporate list records every row under the person's name.

How the components connect

There are three components: the desktop client on the tracked computer, a hosted backend that holds accounts, settings and activity, and a hosted web dashboard. The client talks only to the backend and to the update hosts. It never talks to the dashboard, the dashboard never connects to a client, and there is no agent-to-agent traffic.

Every connection is outbound from the component that starts it, over HTTPS on port 443. Nothing listens for inbound connections on a tracked machine and no fixed source address is needed. The hosts to allow-list are on the domains and URLs page.

Installers and updates

The installers are code signed and timestamped, so their integrity can be verified independently of how they were fetched. Two installers exist, one that needs local administrator rights and one that does not, and both support silent installation through SCCM, Intune or a logon script. Updates install themselves from a version file served over HTTPS.

Each PC signs in with its Windows account, so no password is typed or stored by the employee. Background components keep the client running, and an uninstall password is available per organization. The client does not hide from Task Manager and uses no kernel drivers. Details are on the code signing page.

Dashboard access and separation between customers

Supervisors and administrators sign in with an email address and password set by an administrator, which can be forced to change on first sign-in. Every query is scoped by the signed-in user's role and organization: a supervisor sees their assigned groups and everything below, an enterprise administrator sees the whole organization. Dashboard sign-ins are recorded in an access log.

Larger customers are given a dedicated backend application with its own credentials, separate from the application that serves other customers. Activity data exists in exactly two places: the machine that produced it until it is uploaded, and the backend.

Processor terms

Reclaim Time Ltd processes activity data on behalf of the customer, which is the controller. The Data Processing Agreement on this site lists the data categories, our obligations, breach notification and audit rights, and a signed copy is available on request. Our privacy policy explains what this means for an employee whose employer runs ReclaimTime.