What IT and security teams should ask before approving any wellness tool

A request lands in the queue: HR wants to roll out a wellness app, or an employee is asking you to approve a browser extension that "just schedules breaks." It sounds harmless enough that reviewing it feels like a formality. Then you open the permissions screen and see it wants access to every page the employee visits, or a login flow that routes through a server you've never heard of, and the formality stops being a formality.

The short answer is that the question to ask isn't "is this a good wellness tool" — it's "what does it touch, where does that data go, and what's the blast radius if the vendor is compromised or just disappears." A tool built so it never has anything worth stealing (no stored tokens, no copy of calendar data on a server, narrow delegated permissions instead of account-wide access) is a fundamentally different risk than one that routes everything through the vendor's backend, even if the two look identical in a demo. That architectural difference is the thing worth spending your review time on, more than the feature list.

Browser extensions get less scrutiny than they deserve

Wellness tools are disproportionately shipped as browser extensions, because that's the easiest way to sit next to a calendar or inbox all day. That convenience is exactly why extensions deserve more scrutiny than a typical SaaS sign-up, not less. A 2024 study from Stanford's Empirical Security Research Group and the CISPA Helmholtz Center, "What is in the Chrome Web Store? Investigating Security Noteworthy Browser Extensions" (Sheryl Hsu, Manda Tran, and Aurore Fass), scanned the Chrome Web Store and found that more than 346 million installs belonged to extensions the researchers flagged for security concerns — unsafe scripting practices, policy violations, or known vulnerabilities — over a roughly two-and-a-half-year window. Store review alone doesn't catch this reliably, which means the burden shifts to whoever approves the install inside the company.

CISA's Capacity Enhancement Guide on securing web browsers makes a related point for non-federal organizations: browsers are a common entry point precisely because they're treated as a consumer tool instead of an access-controlled piece of infrastructure. An extension with broad page access can read page content, cookies, and session tokens, and ship them out over ordinary HTTPS — traffic that looks unremarkable to most network monitoring. None of that means every extension is a threat. It means the review needs to look at scope of access, not just the vendor's pitch.

The data-flow question matters more than the feature list

Most procurement checklists ask about uptime and support SLAs. For anything that touches calendars, contacts, or health-adjacent data, the more important questions are architectural:

• What OAuth scopes does it request, and are they delegated (per-user) or tenant-wide? A tool asking for Calendars.ReadWrite or a single Google Calendar scope is doing something very different from one requesting mail, Drive, or admin-level access it doesn't need for its stated function.
• Where do calendar data and access tokens live — on the device, or on the vendor's servers? A vendor that stores nothing has nothing for an attacker to steal in a breach and nothing to hand over under a subpoena it can't contest. NIST SP 800-161, the federal guide for cybersecurity supply chain risk management, frames this as a minimization question: risk scales with what a vendor holds, not just how well they say they protect it.
• Can the vendor answer a standard assessment, or only a sales deck? The Cloud Security Alliance's CAIQ gives a consistent set of yes/no questions — covering data handling, access control, and subprocessors — mapped to its Cloud Controls Matrix. A vendor that can fill one out (or already has one published) is telling you something different than one that can't.
• What happens on offboarding? Ask specifically how access is revoked per user and tenant-wide, and whether that revocation is immediate or dependent on the vendor acting on a request.

None of this requires taking the vendor's word for it. Ask for the specific scopes in writing, not a paraphrase, and test the offboarding claim against the actual admin console before you rely on it.

What to check this week, with or without a specific vendor in front of you

• Pull your browser's extension admin console (Google Admin's Chrome extensions page, or Edge management) and sort by permission level — you'll likely find extensions with broader access than anyone intended to approve.
• Ask any pending wellness-tool vendor for their exact OAuth scope list, not a feature description, before the trial starts.
• Confirm in writing what's stored server-side versus only on the device — "we don't read your events" and "we store no data" are both claims worth asking the vendor to make precisely, since vague versions of both are easy to say and hard to verify.
• Check whether revocation is self-service — if removing access tenant-wide requires emailing the vendor and waiting, that's a real operational gap, not a minor inconvenience.

(This is exactly the kind of review our own extension, TinyTimeouts, is built to pass cleanly — it schedules short breaks in an employee's own Google Calendar or Outlook using narrow, delegated access and stores no calendar data or tokens on our servers. For reviewers, the exact data flow, OAuth scopes, and admin-console steps for both providers are laid out at tinytimeouts.com/it-admins, so a security team can check the real answer instead of taking our word for it.)

The bottom line

A wellness tool that needs broad, standing access to do something simple should raise more questions than one that asks for exactly the narrow permission its feature requires. The Stanford/CISPA research is a reminder that store approval isn't a substitute for your own review, and frameworks like NIST SP 800-161 and the CAIQ exist precisely because "trust the vendor's description" doesn't scale. If you're reviewing a wellness app this quarter — whatever it does — ask what it touches and where the data goes before you ask whether employees will like it. (If you're building the case for why that review matters at all, the research on why most wellness tools don't get used is worth reading alongside this one — a tool nobody adopts is its own kind of wasted security review.)