Hubstaff vs Time Doctor vs gStride — DPDP Comparison (2026)

Why this comparison — and why DPDP is the right lens

Hubstaff and Time Doctor are the two best-known workforce-tracking incumbents in the India market. Both have category-leading installed bases (Hubstaff publicly claims 112,000+ businesses, Time Doctor publicly claims more than 10,000 brands). Both ship into India and both have meaningful market share in the 200-2,000-person India IT services, BPO, and KPO band. And both were designed for jurisdictions where consent-by-default and broad-purpose contracts are the operating norm.

That last point becomes the procurement question of 2026. India's Digital Personal Data Protection Act 2023 is enacted. Rules notification is expected during 2026. Workforce-monitoring tools become regulated processing systems under the Act — every keystroke, every screenshot, every application-use signal is processing of personal data of a data principal under Section 2(i). The fiduciary (the employer) is on the hook. The processor (the vendor) shares some of the duty only if the contract allocates it. Verify with counsel.

This piece compares the three vendors through a single lens: what does the DPDP Act 2023 require, and how does each product—Hubstaff, Time Doctor, gStride—line up against the requirement? It is not a feature comparison; it is a compliance-architecture comparison. For the broader DPDP buyer guide and 8-vendor scorecard, see the DPDP Act 2023 Workforce Monitoring Buyer's Guide.

Throughout: all assessments are based on each vendor's publicly available trust, privacy, and product documentation as of May 2026. Where public documentation does not address a specific DPDP obligation, the assessment is “Unknown,” not “Non-compliant.” Many vendors will produce private readiness statements on request; getting one in writing is the buyer's procurement step.

Snapshot — the one-page comparison

Default data capture — the architectural question

DPDP Section 8(2) requires that processing be strictly for the consented purpose. Default-on broad-spectrum monitoring is incompatible with purpose limitation unless every data principal has consented to every category of capture. Bundling all the capture into a single yes/no at install time does not survive the DPDP standard once Rules notify.

Hubstaff default capture

Hubstaff's published documentation describes a stack that includes time tracking, screenshots (configurable interval), keystroke counts (configurable), mouse activity, application use, URL tracking, and idle detection. The default install on a typical SMB tier turns on time tracking, screenshots, and idle detection; mid-tier deployments often extend to keystrokes and apps. An admin can disable each, but disabling is an admin action, not an architectural exclusion. Once enabled, the data flows through Hubstaff's standard storage tier.

Under DPDP, that creates two issues. First, each enabled capture is a separate processing purpose that requires separate consent — in practice, employees consent to “Hubstaff,” not to “screenshots every 10 minutes plus keystroke counts plus mouse-activity tracking.” Second, the admin toggle is operationally fragile: a new admin enabling keystrokes does not create new consent for existing employees. The DPB inquiry after a breach will ask both questions. Verify with counsel.

Time Doctor default capture

Time Doctor's documentation describes time tracking with screenshots (configurable cadence), application and URL tracking, and idle detection. Keystroke logging is not a documented default for the public-facing tier. Default install enables screenshots and application tracking. As with Hubstaff, capture is admin-configurable but not architecturally bounded; an admin can enable additional capture on existing deployments.

Under DPDP, the same purpose-limitation issue applies, though the surface area is smaller than Hubstaff's because keystrokes are not in the documented default. The bundled-consent issue remains: employees consent to “Time Doctor,” not to “screenshots every 3 minutes plus application logs.” The fiduciary carries the risk on consent quality.

gStride default capture

gStride was architected to start from outcome signals, not input capture. Default capture surfaces are calendar metadata (event titles, durations, attendees with worker-level redaction), repository metadata (commits, PR reviews, code-review velocity), ticket metadata (status transitions, cycle times, blocker durations), and focus-time signals derived from calendar gaps. There is no keystroke capture in the product; no admin toggle enables it. Screenshots exist as an opt-in feature for narrow vertical use cases (BPO billing audits where customer contracts require screen evidence), are off by default, and configurable per data principal with consent ledger entries.

Excluded by architecture (not admin toggle): emotion or sentiment inference, stress or burnout scoring, wellbeing prediction, political or religious inference. These cannot be enabled regardless of customer configuration. The architectural exclusion is the DPDP purpose-limitation answer.

Consent architecture — the consent ledger question

DPDP Section 6 and 7 require that consent be free, specific, informed, unconditional, and unambiguous — with proof of consent retrievable on demand. Bundled consent collapses the “specific” requirement; missing consent ledger collapses the “proof” requirement.

Hubstaff consent flow

Public documentation describes admin-led install with employee notification but does not document a per-feature consent ledger accessible to the fiduciary's DPO. Withdrawal of consent is operationally feasible (the employee can uninstall the agent), but the documentation does not describe per-feature withdrawal with timestamped record. India buyers should request the consent ledger architecture in writing.

Time Doctor consent flow

Public documentation describes admin-managed deployment with workspace-level configuration. Per-feature consent ledger with API access is not described in public materials. As with Hubstaff, fiduciaries should request the consent architecture in writing before contracting.

gStride consent ledger

Each monitoring feature is a separate consent surface inside the gStride product. Employees see per-feature toggles in their profile with timestamped consent ledger entries. The consent ledger is exposed via API to the fiduciary's DPO, with extract retrieval per data principal within 5 business days. Consent withdrawal takes effect within 24 hours and disables only the withdrawn feature. The ledger is retained for at least 7 years post-event.

The practical procurement consequence: under DPDP, the fiduciary must be able to demonstrate consent on demand. The fiduciary that cannot produce a consent ledger extract for a specific data principal in 5 business days fails the Section 6/7 standard, regardless of which vendor stamped the contract. The consent ledger is the fiduciary's defense.

Purpose limitation — architecture vs admin toggle

The DPDP Section 8(2) purpose-limitation obligation is the substantive control that determines whether a workforce-monitoring deployment is compliant or merely configurable into compliance. The distinction matters: under DPDP enforcement, the question is not “what was enabled when the breach occurred” but “what could have been enabled.”

Why admin-toggle is fragile

An admin toggle is a control surface for the customer, not a guarantee to the data principal. If an admin enables a new monitoring feature on Tuesday without re-running consent on Wednesday, the data principal's consent is stale and the processing is non-compliant. The DPB inquiry after a breach will ask the customer to produce the consent ledger entries showing the new consent was captured. If the ledger does not exist or shows blank for the new feature, the customer is exposed.

Why architectural exclusion is durable

An architectural exclusion is a guarantee that does not depend on customer configuration. If the product cannot infer emotion, the new admin cannot enable emotion inference. The product's design itself becomes the customer's defense in a DPB inquiry. For high-sensitivity categories — emotion, stress, wellbeing, political opinion, religious belief — architectural exclusion is the only durable answer.

Where public documentation does not address the category, India buyers should ask each vendor for a written commitment that the category is excluded by architecture, not by toggle. The written commitment becomes a contract schedule.

Breach SLA, cross-border posture, exit terms

Breach notification SLA

The fiduciary has 72 hours under DPDP draft Rules to notify the Data Protection Board and (where applicable) affected data principals. The vendor must notify the fiduciary fast enough that the fiduciary can meet that window. 24 hours is the practical target; 48 hours is the absolute outer limit.

• Hubstaff: Public SLA not documented in trust portal materials. Standard MSA language available on request.
• Time Doctor: Public SLA not documented in trust portal materials. Standard MSA language available on request.
• gStride: 24-hour vendor-to-fiduciary breach notification SLA committed in the standard DPA with continuing-duty updates every 24 hours, annual breach drill summary, no commercial conditioning on notification.

Cross-border transfers

DPDP Section 16 allows the central government to publish a list of permitted transfer destinations. Until that list is comprehensive, cross-border transfers require contractual safeguards. India-hosting is the simplest defense; SCC-equivalent clauses are the second-best.

• Hubstaff: Documented regions include US, EU, and APAC. India-region availability not explicitly documented in public materials; ask in writing.
• Time Doctor: Documented regions include US, EU, and AU. India-region availability not explicitly documented; ask in writing.
• gStride: India-region available; processing and storage can be confined to Indian data centres (Mumbai) at no incremental cost during the initial term. For non-India workforce, SCC-equivalent clauses with transfer impact assessment available.

Exit, export, and deletion

Exit terms determine whether a fiduciary can switch vendors when the regulatory posture changes. Tight deletion certification protects the fiduciary's own DPDP obligations.

• Hubstaff: Standard data export available via API; deletion timeline configurable per contract. Specific deletion-certificate process and timing not documented in public materials.
• Time Doctor: Standard data export available; deletion timeline per contract. Specific deletion-certificate process and timing not documented in public materials.
• gStride: 30-day full data export including consent ledger, audit logs, and signal histories. 60-day deletion of all copies (production, backup, sub-processor). 75-day signed deletion certificate. No commercial conditioning on export or deletion.

Cost comparison — total cost of compliance ownership

Per-seat licence cost is not the right comparison for DPDP-regulated procurement. The right comparison is total cost of compliance ownership over a 3-year horizon: licence + DPA negotiation cycles + breach response readiness + audit defense + migration cost when posture forces a switch.

The compliance ownership cost lines are where the 3-year math diverges. India buyers running 1,000+ seats in regulated verticals (BFSI, healthcare admin, large BPO) routinely find the DPA cycle plus consent ledger build-out plus audit-defense readiness exceeds the licence cost by year 2. Verify with your own pricing and legal estimates.

When to stay on Hubstaff or Time Doctor

This piece is published by gStride and the architectural recommendations point toward outcome-signal systems. That said, there are buyer profiles where staying on Hubstaff or Time Doctor is the right call — and worth saying so plainly.

• Pure freelancer / agency time-billing. If the use case is invoice-grade time capture for external billing, and the workforce is small (<20 people) with no India regulatory exposure, the incumbents' time-billing flows are mature and switching is overkill.
• BPO billing-audit screen capture is contractually mandated. Some BPO customer contracts require timestamped screen evidence. Hubstaff and Time Doctor have mature screen-capture pipelines; gStride supports this as an opt-in, but if the BPO is already integrated into the incumbent it may be operationally cleaner to redline DPDP into the existing contract than to switch.
• No India workforce, no EU workforce, mature DPA already in place. If the fiduciary is purely US-based with no DPDP or EU AI Act exposure and has already redlined the incumbent contract for SOC 2, GDPR, and breach-notification SLAs, the incremental switching value is low.
• The vendor produces a satisfactory private DPDP readiness statement. Many vendors will issue private DPDP statements on request. If Hubstaff or Time Doctor produces a written commitment covering the seven must-have clauses with timing comparable to gStride's DPA, the incremental switching value compresses.

Migration path from Hubstaff or Time Doctor to gStride

For buyers where the switch math works, the typical migration runs 6-8 weeks. The phases:

1. Week 1-2: DPA execution and historical data export. Sign the gStride DPA with required schedules. Initiate historical data export from incumbent (typically 90 days of time, project, and signal data). Configure the gStride workspace with team structure, role taxonomy, and reviewer-role matrix.
2. Week 3-4: Pilot team parallel run. Select 30-50 people across 2-3 teams for parallel run. Both systems collect; only gStride is referenced for decisions. Validate signal quality, reviewer flow, and consent ledger functionality. Surface and triage gaps.
3. Week 5-6: Phased rollout. Roll out by team or location with stop-the-line authority for the change-management lead. Communicate to employees: what is being turned off (screenshots, keystrokes, mouse activity, app-tracking), what is being turned on (granular consent, transparency on signal types, withdrawal control). Most rollouts see <5% objection rate.
4. Week 7-8: Cutover and incumbent deletion. Final cutover. Trigger incumbent deletion certification process. File the deletion certificate with internal DPO. Archive the parallel-run audit log for SOC 2 / DPDP audit defense.

gStride provides a migration coordinator for deployments of 200+ seats and import scripts for time-entry and project data from Hubstaff and Time Doctor exports.

What the India CISO should ask each vendor

Before the next renewal, ask each of your three candidates (incumbent + 1-2 challengers) the following five questions in writing. The answers are the procurement file:

1. DPDP readiness statement. Produce your current written DPDP Act 2023 readiness statement covering the five obligations: data fiduciary designation, granular consent, purpose limitation, 72-hour breach cascade, cross-border transfer assessment.
2. Consent ledger architecture. Provide the architecture of your consent ledger including per-feature granularity, withdrawal SLA, API access to the fiduciary DPO, and retention period.
3. Architectural exclusions. List the sensitivity categories (emotion, stress, wellbeing, political, religious, biometric) that are excluded by architecture — not admin toggle — in your product.
4. Breach SLA. State your vendor-to-fiduciary breach notification SLA in hours, the content of the structured notification, and the continuing-duty cadence.
5. Exit terms. State your export format, deletion timeline, and deletion certificate process. Confirm there is no commercial conditioning on data export.

The vendor that responds within 5 business days with crisp documentation is the vendor whose internal compliance is already operational. The vendor that responds with “our standard MSA addresses this” without producing the architecture is not ready.