Gusto commits to de-identification maintenance

The updated Privacy Policy now explicitly states it covers retirement account management (401k, SEP IRA, IRA accounts) and adds Stripe alongside Plaid as a third-party service provider that collects financial institution data. The policy restructures how it describes Gusto's role in different contexts: when Gusto acts as a service provider processing payroll or other data on behalf of employers, when it acts as an employer itself, or when it operates as a co-employer under a professional organization (PEO) arrangement, with separate privacy notices applying in each case. The policy introduces a new commitment that de-identified data will not be re-identified except to verify compliance with applicable law. If you connect a bank account through Stripe, that data will be treated under Stripe's Privacy Policy, which you should review separately.

The updated terms make explicit that using Gusto's background check service constitutes a binding agreement. Previously, the terms of the service relationship may have been less clearly stated. Now, the agreement clarifies that an authorized signatory represents they have authority to bind the organization, and that three actions trigger binding acceptance: checking a box, initiating a background check, or accessing the service. This means employers should ensure the person clicking through has actual authority to commit the organization to the full Background Check Customer Agreement before proceeding.

Developers who build integrations with Gusto's API are now required to resolve any disputes with Gusto through mandatory individual binding arbitration rather than pursuing class action lawsuits, which may limit their legal remedies and transparency into disputes with Gusto. Additionally, Gusto explicitly reserves the right to modify, restrict, or discontinue its developer tools and API access at any time without notice or liability, meaning developers could lose access to critical platform capabilities that their business depends on without warning or recourse. Developers should review Section 19 of these terms carefully and consider whether the arbitration requirements and lack of access guarantees are acceptable before continuing to build on the Gusto API.