Monitoring Transparency and Privacy

Monitoring should support a defined work process, such as confirming recorded time, reviewing project progress, resolving a billing question, or understanding where a workflow is blocked. The purpose should be documented before any monitoring feature is enabled and explained in language that team members can understand.

A clear purpose helps a workspace avoid collecting information simply because a feature is available. Administrators should consider whether each enabled feature is necessary for the stated purpose and whether a less intrusive approach could provide the context the team needs.

• Describe the business reason for monitoring.
• Identify the teams, projects, or work periods covered.
• Explain how the information will—and will not—be used.
• Review the purpose when the workflow or team changes.

The information available in a workspace depends on the features that are enabled and how the workspace is configured. It may include account details, projects and tasks, time entries, comments, approvals, reports, and other work context. Optional monitoring workflows may also involve screenshots, application or website activity, webcam context, idle-period signals, or keyboard and mouse activity.

Not every workspace uses every feature. Before rollout, administrators should give team members a current description of the information that may be collected, when collection can occur, and which devices or work sessions are within scope. Product availability and exact behavior should be confirmed against the relevant workspace and plan.

People should not have to guess whether monitoring is active. A practical notice should be provided before rollout and whenever the scope changes materially. The notice should be easy to find and should use direct language rather than relying only on a general policy or contract reference.

The explanation should cover the purpose, enabled information categories, expected work periods, review process, access roles, retention approach, and contact path for questions. Where notice, consultation, consent, or another process is required, the organization operating the workspace is responsible for confirming and following the requirements that apply to its workforce and location.

Access to monitoring information should be limited to people who need it for the documented workflow. Workspace administrators should review roles and permissions regularly, remove access when responsibilities change, and avoid sharing monitoring records outside the intended review process.

Retention should also have a clear purpose. Organizations should decide how long different work records need to be kept, taking account of operational, contractual, dispute-resolution, and legal requirements. Exact retention or deletion behavior may depend on the workspace configuration, plan, backup process, and the type of record involved.

• Document who can view, export, or manage monitoring information.
• Use the least access needed for each role.
• Set a review date for access and retention decisions.
• Confirm deletion and backup behavior before promising a fixed timeline.

Monitoring information is one source of work context; it is not a complete measure of performance, effort, or intent. A screenshot, idle signal, application record, or time entry can be incomplete or open to more than one explanation. Reviewers should consider the related task, expected outcome, working arrangement, and information supplied by the person doing the work.

Important decisions should include appropriate human review. Teams should avoid treating a single signal or automated classification as a final conclusion, particularly when the information could affect approval, payment, access, or another significant outcome.

Team members should know where to ask how monitoring works, report missing context, or question an inaccurate record. The process should identify who will review the request, what supporting information may be useful, and how the outcome will be communicated.

Where the workflow allows a record to be corrected, rejected, annotated, or resubmitted, those options should be explained before they are needed. If the requested change cannot be made, the reviewer should explain the reason and identify any available next step.

Use this checklist before enabling a monitoring workflow and repeat it when features, policies, team membership, or legal requirements change.

• Define and document the purpose of monitoring.
• Confirm the features and information categories that are actually enabled.
• Identify the people, projects, devices, and work periods in scope.
• Assign access roles and review permissions.
• Document retention, deletion, and export expectations.
• Provide notice and complete any required consultation or consent process.
• Explain how records are reviewed and how context can be added or corrected.
• Give team members a clear contact for privacy and monitoring questions.
• Schedule a periodic review of the workflow and remove collection that is no longer needed.