Cursor for Teams: Rollout, Security, Policy and ROI

The Teams plan ($40/user/mo) adds SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition., an admin dashboard, centralized billing and pooled usage. Enterprise adds SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition. provisioning, customer-managed encryption keys (CMEK), a HIPAA BAA and advanced governance. If you have a security or compliance function, you'll likely need Enterprise. See the security section.

Most of what Teams adds is administrative: centralized billing, SAMLSecurity Assertion Markup Language. The XML-era enterprise standard that powers single sign-on: your identity provider vouches for you to each app. Older than OIDC but still what many enterprise tools speak. Press Enter for the full definition./OIDCOpenID Connect. The modern single sign-on standard, built as an identity layer on top of OAuth 2.0. Where SAML is XML and enterprise-legacy, OIDC is JSON and what newer tools implement first. Press Enter for the full definition. SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition., usage analytics, team-wide Privacy ModeCursor's setting that guarantees code data is not used for training by Cursor or its model providers, and that an admin can enforce org-wide; data-retention terms are a separate, contractual layer. Press Enter for the full definition. enforcement and a marketplace for internal rules, skills and plugins. Two items on that list are not administrative at all, BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. code review and cloud agents with shared team context, and those are the ones engineers notice in week one.

Cursor's own guidance is Teams for any customer happy to self-serve, and Enterprise for teams that need priority support, pooled usage, invoicing, SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition. or advanced security controls. That list is shorter than most vendor comparisons imply. If nothing in your security questionnaire maps onto those five, Teams probably covers you, and it is usually the compliance extras (CMEK, a HIPAA BAA, US data residency) that pull an org across the line rather than the governance features themselves.

Seat type is a separate decision, and a later one.

A Premium seat at $120/user/mo carries 5x the included usage of a Standard seat, so the extra $80 is only earned back by someone who reliably runs out. You cannot tell who those people are until a few weeks of dashboard data exist. Put everyone on Standard, then upgrade individuals from the member context menu when the usage page says so; upgrades take effect immediately and bill pro-rata, so waiting costs you nothing.

Billing cycle is the setup choice worth pausing on. Yearly saves 20% against the monthly rate, and it commits the team for the year. For a team whose headcount is still moving, that discount is probably worth less than one cycle of flexibility.

Turn on the two that decide where your code can travel: enforced Privacy ModeCursor's setting that guarantees code data is not used for training by Cursor or its model providers, and that an admin can enforce org-wide; data-retention terms are a separate, contractual layer. Press Enter for the full definition., and SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition. tied to your identity provider. The table below maps each control to what it does and the tier it lands on, so you can sort the must-haves from Enterprise-only governance before you talk to a vendor reviewer.

The order in that table is not the order to do them in. Privacy ModeCursor's setting that guarantees code data is not used for training by Cursor or its model providers, and that an admin can enforce org-wide; data-retention terms are a separate, contractual layer. Press Enter for the full definition. goes first, because enforcement governs traffic from the moment you lock it and not a request earlier, so a week of delay is a week of requests under whatever each member happened to have set. SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition. goes second, because SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition. will not configure without an active SAMLSecurity Assertion Markup Language. The XML-era enterprise standard that powers single sign-on: your identity provider vouches for you to each app. Older than OIDC but still what many enterprise tools speak. Press Enter for the full definition. connection. Spend caps can wait until there is a week of real usage to size them against.

Spend alerts and spend limits get conflated in rollout plans, and finance always notices. An alert emails you when on-demand spend crosses a threshold you set and stops nothing, while a limit is what actually caps the bill. Teams sets monthly team-wide limits in the dashboard. Per-member limits are Enterprise.

When a control is missing from your own dashboard, check the tier before you open a ticket. SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition., CMEK, per-member spend limits and the BAA all sit on Enterprise, and SCIM hides itself further: the setup link only appears once SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition. is verified. That, I suspect, is the most common reason an admin concludes provisioning is broken.

Four failures come up more than the rest: seats handed out before the org settings were locked, SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition. attempted before SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition., a pilot measured against no baseline, and paid seats nobody reclaimed after the people on them stopped signing in.

Ordering is the expensive one. Enforced Privacy ModeCursor's setting that guarantees code data is not used for training by Cursor or its model providers, and that an admin can enforce org-wide; data-retention terms are a separate, contractual layer. Press Enter for the full definition. cannot be applied backwards, so requests sent before you lock it went out under whatever each member happened to have set. Fifty engineers signing in during the week before that lands is not a catastrophe, and it is still the only part of a rollout you cannot go back and redo.

The baseline gets skipped because nothing breaks when you skip it.

Cycle time, PR throughput and a two-question time survey take an afternoon to capture and cannot be reconstructed later, which is, unhelpfully, exactly when somebody asks for them. If you are three weeks in with nothing from before, say so, measure the second half properly and report a partial result rather than a reconstruction.

Dormant seats are the easiest of the four to fix and the last thing anyone checks. Billing runs per active paid seat, so removing someone who never signed in stops the charge and comes back as pro-rated credit on the next invoice. Removal is also permanent for their Memories and any Cloud Agent history, which deserves a second look when a seat is dormant because somebody is on leave rather than gone.

Onboarding works best when the admin settings are locked down before the first developer logs in. Configure the org, run one hands-on session, then pilot on something low-risk and measure. These five steps are the order most teams follow.

1. 1Configure org settings first: SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition., enforced Privacy ModeCursor's setting that guarantees code data is not used for training by Cursor or its model providers, and that an admin can enforce org-wide; data-retention terms are a separate, contractual layer. Press Enter for the full definition., spend caps, shared .cursor/rules/.
2. 2Run a 1-hour hands-on session on the Ask/Agent mental model and context habits.
3. 3Give each team a shared rules file so the AI follows your conventions from day one.
4. 4Pick a low-risk pilot project; measure before scaling.
5. 5Share a one-page AI-coding policy (below) so expectations are explicit.

Those steps are ordered by what blocks what rather than by importance. Step one blocks everything after it, since Privacy ModeCursor's setting that guarantees code data is not used for training by Cursor or its model providers, and that an admin can enforce org-wide; data-retention terms are a separate, contractual layer. Press Enter for the full definition. enforcement does nothing about requests already sent. The rules file is the step I would move. Give people a week of unguided use first and write the rules from what they actually got wrong, because a rules file authored before anyone has worked in Cursor describes the conventions you wish you had rather than the ones the agent keeps breaking.

Team size changes the shape of this more than the plan choice does. Under roughly ten engineers, domain matching and one shared rules directory cover membership and conventions, and the hour-long session can be a screen share over lunch. Past a hundred seats, the session has to be recorded and membership belongs in your identity provider, which means Enterprise, because SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition. is not on Teams. The onboarding playbook has the full sequence.

Tie it to delivery metrics you already track. The defensible ones: developer time saved per week (survey + sampling), PR throughput and cycle time (DORADORA metrics. Four widely-used delivery measures: deployment frequency, lead time for changes, change failure rate and time to restore service. Press Enter for the full definition.) and cost per developer per month under your actual model mix. Avoid claiming a single headline multiplier. Measure your own baseline and the delta.

Hours saved per engineer per week and cycle time carry most of the argument between them. The survey number is soft and everyone in the room knows it, which is survivable so long as you sample the same way twice and say how you sampled. Cycle time is harder to argue with, though it moves for reasons that have nothing to do with Cursor, so hold a pilot team against its own previous quarter instead of against a different team.

If the AI share of committed code comes back lower than the team's own sense of it, check the tracking limits before drawing a conclusion. Attribution is computed on-device and matched against later commits by the same author on the same machine, so work committed from a second laptop drops out of the count. Automated formatters can invalidate the diff signatures, and Background Agents and the CLI are not covered yet, so a team leaning on cloud agents will under-report on that chart. Team usage analytics carries the rest of the caveats.

Cost per developer is the number finance checks, and the one most rollout decks leave out. On Teams it is the seat plus whatever on-demand usage that person generated, tracked per user in the admin dashboard. Pull it for the pilot month before anyone asks.