Cursor vs Windsurf SOC2 HIPAA FedRAMP: Whose Compliance Stack Passes Procurement?

A vendor's trust page said "FedRAMP High" last quarter. This quarter it says "FedRAMP High (in progress)." Nobody announced the change. That's the kind of thing that shows up in a procurement review three weeks before signature, and it's exactly why cursor vs windsurf SOC2 HIPAA FedRAMP claims need to be treated like uptime SLAs: verify before you trust, and re-verify before you renew.

Why Is Procurement Different From a Developer Trial?

Procurement is different because the failure mode is different: a developer trial fails when autocomplete is slow or wrong, a procurement review fails when the tool passes a security audit based on claims that turn out to be unverifiable. Two different buyers are answering two different questions with the same marketing page.

Two different buyers, two different failure modes

An engineer evaluating Claude Code, Cursor, or Windsurf cares about completion latency, context window handling, and whether the agent mode actually finishes a task without babysitting. A security reviewer cares about whether SSO enforces MFA, whether SCIM deprovisioning fires inside the access-revocation SLA in the SOC 2 control matrix, and whether a FedRAMP claim maps to an actual authorization boundary. Both buyers can look at the same product page and reach opposite conclusions about whether it's "ready."

Where the marketing page and the SOC 2 report disagree

A public trust page is copy written by whoever owns the website. A SOC 2 Type II report is an attestation from an independent auditor covering a specific period, with a specific list of controls tested and a specific list of exceptions noted. A FedRAMP Marketplace listing is a matter of public federal record. These are not interchangeable forms of evidence, and treating them as equivalent is the single most common mistake in this kind of review.

The thesis of this post: test whether Windsurf's compliance checklist is deployable today, against Cursor's narrower but more verifiable claim set, and give a security team a way to check both without waiting on a vendor's sales engineer to get back to them.

What Does Windsurf Actually Claim on Its Compliance Page?

Windsurf's public compliance messaging centers on SSO, RBAC, hybrid/on-prem deployment, SOC 2 Type II, HIPAA, and a FedRAMP High claim, positioned as enterprise-ready out of the box. The gap between "claims" and "proof" is widest on the FedRAMP line, and that's the one worth stress-testing first.

SSO, RBAC, and hybrid deployment

SSO and role-based access control are table stakes for enterprise tooling at this point, and Windsurf publishes both as headline features alongside a hybrid or on-prem deployment option for teams that can't send code to a multi-tenant SaaS boundary. Hybrid deployment is the more interesting claim operationally, because it implies Windsurf can run inference and indexing inside a customer's own network perimeter. That claim needs an architecture diagram and a network flow review before anyone signs off on it, not just a checkbox.

SOC 2 Type II and HIPAA

SOC 2 Type II and HIPAA are both claimed on the compliance page. The operational question isn't whether the claim exists, it's whether the actual report is available under NDA, what period it covers, and whether a signed Business Associate Agreement (BAA) is available as contract language rather than a bullet point on a webpage.

FedRAMP High: shipped, self-attested, or roadmap?

This is the load-bearing claim. FedRAMP status comes in at least three flavors that get flattened into one badge on a marketing page:

• Listed authorization — the product appears on the FedRAMP Marketplace with an active ATO (Authority to Operate) from a sponsoring agency or the Joint Authorization Board (JAB).
• Agency-sponsored, in progress — a named federal agency is actively sponsoring the authorization process, but it hasn't completed.
• Self-attested target — the vendor intends to pursue FedRAMP High and says so, with no sponsoring agency and no marketplace listing.

A vendor claiming "FedRAMP High" without a marketplace listing or a named sponsoring agency is describing an aspiration, not a control. That distinction is not pedantic. It's the difference between a control a federal buyer can rely on today and a roadmap slide.

What Does Cursor Enterprise Actually Claim?

Cursor Enterprise claims a narrower set of controls, anchored in SCIM-based provisioning, audit logging, and model access restriction, without a FedRAMP or HIPAA claim attached. Narrower isn't worse for procurement purposes. It's easier to verify, which matters more than breadth when a report ships late.

SCIM and seat management

Cursor Enterprise leads with SCIM-based provisioning and deprovisioning, which maps directly to one of the most commonly tested SOC 2 controls: timely revocation of access when an employee leaves or changes role. This is a testable claim. You can provision a user, revoke them, and time the propagation.

Audit logs and model access restrictions

Audit logs and the ability to restrict which underlying models a workspace can call are both concrete, narrower capabilities than "FedRAMP High." They're also easier to validate in a proof of concept, because you can pull a log export and check what it actually captures, and you can try to call a restricted model and see if the restriction holds.

PO billing as a procurement signal

Cursor Enterprise supports purchase-order billing and enterprise contracts, which is itself a signal: a vendor built for procurement cycles, not just self-serve credit card checkout, tends to have contract language, security questionnaires, and a dedicated security contact ready to go. Notably absent from Cursor's public claims: any FedRAMP status, and no visible HIPAA BAA language. For a security reviewer, that absence is informative. It's a vendor being honest about scope rather than overreaching on a marketing page.

Cursor vs Windsurf: How Do the Compliance Claims Compare Side by Side?

Side by side, Windsurf claims more surface area (FedRAMP High, HIPAA, hybrid deployment) while Cursor claims a smaller set of controls that are easier to independently verify (SCIM, audit logs, model restriction). Here's the comparison a reviewer should actually work from, with each cell marked by evidence status rather than a simple yes/no.

Comparison table

Control	Cursor Enterprise	Windsurf
SSO / RBAC	Claimed	Claimed
SCIM provisioning	Claimed, testable	Claimed, testable
Audit logs	Claimed, testable	Claimed
Model access controls	Claimed, testable	Claimed
SOC 2 Type II	Claimed-unverified (request report)	Claimed-unverified (request report)
HIPAA / signed BAA	Not offered	Claimed-unverified (request BAA text)
FedRAMP status	Not offered	Claimed-unverified (verify Marketplace listing)
Hybrid / on-prem deployment	Not offered	Claimed-unverified (request architecture diagram)
PO billing / enterprise contracts	Verified (public pricing/contract terms)	Claimed

Reading the table correctly

Every "claimed-unverified" cell is a homework assignment, not a rejection. A "yes" on a marketing page and a "yes" backed by a report number, an auditor's name, and a coverage period are not the same yes. Treat the table as a request list, which is exactly what the next section turns it into.

Is FedRAMP High Actually Available, or Is It Roadmap?

FedRAMP High status is verifiable in public record within minutes: check the FedRAMP Marketplace for the vendor's name, authorization type, and sponsoring agency. If the vendor isn't listed there, whatever their compliance page says is marketing language, not an active authorization.

What FedRAMP authorization actually requires

A FedRAMP High authorization requires either a JAB provisional authorization or a specific federal agency sponsoring the ATO, plus a completed assessment by an accredited Third Party Assessment Organization (3PAO), plus continuous monitoring obligations after authorization. None of this happens quietly. It's tracked in a public system of record maintained by GSA.

How to check a FedRAMP claim in five minutes

1. Go to marketplace.fedramp.gov.
2. Search the vendor's legal entity name, not just the product brand.
3. Check the authorization type: JAB, Agency, or "In Process."
4. Note the sponsoring agency name and the authorization date, if listed.
5. If the vendor isn't listed at all, go back to their compliance page and check the exact wording: "FedRAMP High" versus "FedRAMP High (in progress)" versus "targeting FedRAMP High" are three different claims wearing the same badge icon.

If the vendor's own page hedges with "in progress" or "planned," that's roadmap language dressed as a checklist item. This is the single highest-leverage fact-check in the entire evaluation. Get it wrong and you've bought a promise, not a control, and that gap surfaces during your own agency's audit, not the vendor's.

What Should a Security Team Actually Ask For in a POC?

A security team should ask for primary documents, not marketing collateral: the actual SOC 2 Type II report, the FedRAMP authorization letter or Marketplace listing, a signed BAA template, SCIM test credentials, and a sample audit log export. Anything short of that is a sales conversation, not a security review.

The document request list

• The full SOC 2 Type II report under NDA, including the exception list, not the badge or summary page.
• The FedRAMP authorization letter or a direct link to the Marketplace listing showing status and sponsoring agency.
• A signed BAA template, with subprocessor language spelled out.
• Test SCIM credentials against a sandboxed tenant.
• A sample audit log export, ideally covering both admin actions and end-user prompt/response metadata.

The technical verification checklist

• Provision and deprovision a test user via SCIM, and time how long revocation takes to actually reflect in session access, not just the admin console.
• Pull an audit log export and confirm it captures more than login events, specifically whether prompt and response metadata is logged.
• Attempt to restrict model access to an approved provider and confirm the restriction is enforced at the API layer, not just hidden in the UI.

Sample questions to send the vendor

"What is your FedRAMP authorizing agency and ATO date?"
"Can you provide the SOC 2 report bridge letter for the gap period between report issuance and today?"
"Does your HIPAA BAA cover the underlying model provider, or only your platform layer?"

That last question matters more than it looks. A BAA that covers the platform but not the model provider leaves PHI exposure at the exact layer where the actual inference happens.

How Do You Validate SCIM and Audit Logging Actually Work Before You Sign?

You validate SCIM and audit logging the same way you'd validate any access-control claim in a production system: run the test yourself, on a sandbox tenant, and measure the result against your own policy SLA rather than the vendor's stated one.

A runbook for the technical reviewer

1. Stand up a test group in your IdP (Okta, Entra ID, or whatever you run) with three test users.
2. Provision all three into the sandbox tenant via SCIM and confirm they can authenticate.
3. Revoke one user's group membership in the IdP and start a timer.
4. Poll the tool's API or admin console until access is actually revoked, not just flagged.
5. Compare that elapsed time against your internal access-revocation SLA. If your policy requires revocation within an hour and the tool takes four, that's a finding, not a footnote.

Config and API checks

A representative SCIM deprovisioning call looks roughly like this against a SCIM 2.0-compliant endpoint:

curl -X PATCH https://api.vendor.com/scim/v2/Users/{userId} \
  -H "Authorization: Bearer $SCIM_TOKEN" \
  -H "Content-Type: application/scim+json" \
  -d '{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [{
      "op": "replace",
      "path": "active",
      "value": false
    }]
  }'

And a representative audit log pull, checking for prompt/response metadata rather than just auth events:

curl -X GET "https://api.vendor.com/v1/audit-logs?start=2024-01-01&end=2024-01-31&type=prompt" \
  -H "Authorization: Bearer $AUDIT_API_KEY" \
  | jq '.events[] | {user, action, model_used, timestamp}'

If that query returns login events only, and nothing about which model handled which request, the audit log claim is thinner than it looked on the compliance page. Teams that don't want to trust a vendor's native log viewer should pipe exports into existing tooling like Honeycomb or Grafana, both built for exactly this kind of high-cardinality event correlation against your own SIEM. And if a vendor claims hybrid or on-prem deployment isolates data the way they say, a posture tool like Wiz can validate that isolation against your actual cloud environment instead of a diagram in a sales deck.

Which Model Access Restrictions Actually Matter for Regulated Data?

The model access restriction that matters is whether third-party model calls can be blocked entirely and inference routed through an approved provider or a self-hosted model, not whether a dropdown menu exists to "select a model." If code or PHI can leak to an unapproved model provider through a fallback path, the restriction claim is cosmetic.

Restricting which LLMs can see your code or PHI

Ask specifically: does the restriction block the call at the network layer, or does it just hide the model from the UI while a background call still routes elsewhere for a fallback or a smaller subtask? Vendors rarely volunteer this distinction unless asked directly, and it's the difference between a real data boundary and a UI preference.

Self-hosted and hybrid alternatives

For teams that need inference to stay fully in-house for HIPAA or FedRAMP boundary reasons, the more defensible fallback isn't trusting a SaaS vendor's boundary claim, it's running the model yourself. Ollama (panel score 8.4/10 by the TopReviewed AI panel) supports running open models locally or in a controlled cloud environment you own. Open-weight models like Llama (panel score 8.7/10), hosted through Hugging Face (panel score 8.9/10), give a regulated team a model-level data boundary that doesn't depend on a third party's contractual promise. If neither Cursor nor Windsurf can prove model-level data isolation in your specific environment, that's a hard blocker, not a negotiation point.

What Are the Common Failure Modes in This Kind of Procurement Review?

The common failure modes in this review show up the same way a bad deploy shows up in an on-call retro: quietly, until the thing they were supposed to prevent actually happens. Here's the checklist worth running before signature, not after.

Failure mode checklist

• Accepting a trust-page badge or logo as proof instead of requesting the actual SOC 2 report.
• Not reading the SOC 2 report's exception list, where the real risk usually lives.
• Assuming a HIPAA BAA automatically covers subprocessors, including the underlying model provider.
• Never testing SCIM deprovisioning speed against your own internal policy SLA, only the vendor's stated number.
• Treating "FedRAMP High" language on a marketing page as equivalent to an active, listed ATO.

Every one of these is the kind of thing that gets a paragraph in a post-incident report six months later, right after "root cause: assumed the vendor's documentation was current."

Cursor or Windsurf: What Should a Regulated Team Actually Choose?

A regulated team should choose Cursor if it wants a smaller, independently verifiable control set and can operate without FedRAMP or HIPAA today, and should choose Windsurf only if it can get the FedRAMP authorization letter and actual BAA text in writing before signing, not just marketing language.

When Cursor's narrower story wins

If SCIM provisioning, audit logs, and model access restriction cover the actual regulatory surface you're working under, Cursor's smaller claim set is easier to trust precisely because there's less of it to fact-check. No FedRAMP claim to chase down, no BAA gap to worry about, no hybrid deployment diagram to validate.

When Windsurf's broader claims are worth the verification effort

Windsurf's broader compliance surface, SSO, RBAC, hybrid deployment, SOC 2, HIPAA, and FedRAMP, is worth pursuing only if procurement gets the primary documents rather than the trust-page summary: the Marketplace listing, the authorizing agency name, and the actual BAA contract text.

Send Windsurf's security team a written request for the FedRAMP Marketplace listing and the SOC 2 report bridge letter before your next call. If they can't produce both within a week, treat the compliance page as unverified and price the deal, and the timeline, accordingly.