Cursor - Detailed Report

(Generated by AI, ChatGPT Deep Research, on April 1st 2025)

1. Tool Overview

Cursor is an AI-augmented code editor (available at cursor.com) designed to help developers write and refactor code more efficiently. Built as a fork of Microsoft’s Visual Studio Code (Security), it provides a familiar IDE interface enhanced with AI pair-programming features. Key functionality includes “Cursor Tab” autocomplete for multi-line code suggestions (Features), an in-editor AI chat assistant that can understand the context of your code (e.g. current file, cursor position) to answer questions or generate code changes (Features), and a codebase indexing feature that semantically searches your entire project to provide context-aware completions and Q&A (Security). Cursor can even run shell commands via an AI “agent” (with user confirmation required) to automate repetitive tasks (Features).

All versions share the core features, and generated code is owned by the user (Pricing). The Business/Enterprise offerings add capabilities for team use and security: for example, organisation-wide settings and admin controls, Single Sign-On integration, and enforced privacy settings (detailed below) (Pricing). Cursor reports that it is already used by engineers at major companies (e.g. Deloitte, Samsung, OpenAI) (Enterprise), indicating a level of maturity and real-world adoption. However, the company (Anysphere, Inc.) acknowledges that Cursor is still evolving its security posture; they advise caution if you work in a highly sensitive environment, encouraging a thorough risk assessment before use (Security).

2. Privacy Settings

Privacy Mode is the primary in-tool setting to protect user code and data. When Privacy Mode is enabled (users can turn it on during onboarding or in the settings menu Security), Cursor guarantees zero data retention for your code. In practice, this means none of your source code or prompts are stored on Cursor’s servers or used for training by Cursor or any third party Privacy Policy). Code still needs to be sent to Cursor’s backend to generate AI responses, but with Privacy Mode on it remains only in transient memory and short-term encrypted caches (not written to any persistent storage) Security). This mode can be used by anyone (it’s available to free and Pro users), and notably it is enforced by default for Business and Enterprise users – organisations on these plans have Privacy Mode automatically enabled for all members Enterprise Cursor – Privacy & Security).

With Privacy Mode off (the default for individual users unless they opt in), Cursor may collect usage data to improve the product. This telemetry can include snippets of prompts or code and editor actions Privacy Policy). For example, if not in privacy mode, Cursor’s AI autocomplete provider (Fireworks) might retain prompts to optimise model performance Privacy Policy). All such data collection is governed by Cursor’s Privacy Policy and used for product development, but it means code could be stored on Cursor’s servers or partners’ systems if privacy mode is not enabled. For government or sensitive use, it’s therefore recommended to keep Privacy Mode on at all times, to ensure no code is persisted beyond your local machine Pricing). (On enterprise plans this is automatic; on individual plans, users must manually enable it.) Cursor’s documentation provides clear guidance on Privacy Mode and confirms that even if you use your own API keys for the AI models, the requests still route through Cursor’s backend – so Privacy Mode remains relevant in all configurations Cursor – Privacy & Security). In summary, Privacy Mode is a crucial setting for maintaining confidentiality, and enterprise deployments leverage it to guarantee that proprietary code is not stored or learned from by the AI Cursor – Privacy & Security).

3. Terms of Use and Privacy Policy

Cursor’s Terms of Service (Terms of Service) (last updated 24 July 2024) and Privacy Policy (Privacy Policy) (last updated 8 November 2024) are publicly available on its website. These documents outline the conditions of using the software and how user data is handled. Notably for UK government users, the Terms of Service include a clause that users should not input data that is subject to special legal protections beyond ordinary personal data Terms of Service). This implies that highly sensitive data (for example, information protected under health, financial, or other regulations) is not intended to be processed by Cursor’s service. The Terms also specify that the agreement is governed by US law (California) by default Terms of Service), although an enterprise customer would typically negotiate a custom contract or Data Processing Agreement – something the Terms acknowledge by deferring to any separate master agreement for organisational use Terms of Service).

The Privacy Policy provides details on data handling relevant to UK GDPR expectations. It describes what personal data Cursor collects and for what purposes, distinguishing between normal operation and Privacy Mode use Privacy Policy). When Privacy Mode is on, the policy confirms that code will never be stored or used for training by Cursor or its providers Privacy Policy). With Privacy Mode off, some data (e.g. prompts or code snippets) may be retained for telemetry and model improvement Privacy Policy). The Privacy Policy also discusses how data may be shared with subprocessors and the legal bases for processing. It explicitly addresses international data transfers, stating that data will be processed on servers in the United States and that, for UK/EU users, Standard Contractual Clauses or equivalent safeguards are used when transferring data overseas Privacy Policy). UK government users should review these terms carefully – especially sections on data transfer and retention – to ensure they align with departmental policies. Importantly, Cursor’s policies do indicate compliance with GDPR principles (such as data minimisation under Privacy Mode, and providing user rights like account deletion), but any adoption would likely be accompanied by a formal contract that meets UK public sector requirements.

Links: Cursor Terms of Service Terms of Service); Cursor Privacy Policy Privacy Policy). These should be reviewed in full by legal advisors for government use.

4. Data Management

4.1 Server Location and Data Residency

Cursor is a cloud-based application, and understanding where it stores and processes data is key for government use. The service’s infrastructure is primarily hosted on Amazon Web Services (AWS) in the United States Security). According to Cursor’s security documentation, most servers (for application logic and AI processing) run in U.S. AWS regions, with some servers in Europe (London) and Asia (Tokyo) used for latency-critical tasks. This means that a UK user’s code queries might be routed to a London AWS data centre for speed, but they will ultimately be handled by infrastructure that is largely US-based. In addition, Cursor uses some services on Microsoft Azure and Google Cloud Platform, though those are also stated to be in the US regions. The company’s custom AI models are hosted via a provider called Fireworks with servers in the US, Europe, and Asia Security – so model inference could occur in those regions. All told, user data will leave the UK and be processed in the US (and potentially other jurisdictions) in the course of using Cursor’s cloud service.

From a legal jurisdiction standpoint, personal data and code sent to Cursor will be subject to US law while in those servers. Cursor’s Privacy Policy explicitly notes that the apps are hosted in the United States and that data will be stored and processed on servers in the US Privacy Policy). For transfers of personal data from the UK (or EU) to the US, Cursor relies on Standard Contractual Clauses (SCCs) as the mechanism to ensure GDPR-compliant protection Privacy Policy). This is a standard approach for US-based service providers dealing with European data. However, UK government organisations must consider whether the sensitivity of the code or data they plan to use with Cursor is compatible with storage in the US. Data classified as OFFICIAL (and especially OFFICIAL-SENSITIVE) in government might be subject to departmental cloud policies or risk assessments for overseas hosting. The presence of an AWS London region in Cursor’s infrastructure is helpful, but it does not guarantee UK-only data residency, since data can traverse or be stored in the US systems. Additionally, Cursor sends code data to third-party AI model providers like OpenAI and Anthropic (both US-based companies) as part of generating responses Security). The company has established zero data retention agreements with these AI providers (meaning OpenAI/Anthropic should not store the code after processing), but the data does transit to and through these US services.

On a positive note, Cursor is transparent about its subprocessors and does not use any infrastructure in China or any Chinese-owned service providers Security). This will reassure those concerned about data exposure to jurisdictions without UK-aligned security. In summary, UK government adopters of Cursor must be aware that data residency is primarily in the United States (with appropriate GDPR transfer safeguards in place), and there is currently no option for a UK-sovereign cloud deployment. Agencies should weigh this against their data handling policies. If strictly UK-only data processing is required, Cursor as it stands may not meet that requirement (since a self-hosted or on-premise version is not available Enterprise)).

4.2 Data in Transit

Cursor uses standard encryption protocols to protect data in transit. All network communication between the Cursor application (client) and its backend is encrypted using TLS 1.2 Enterprise), which is in line with NCSC cloud security guidance to encrypt data in transit. Whenever you invoke an AI function (autocompletion keystrokes, chat queries, etc.), your code context and prompt are sent over HTTPS to Cursor’s servers and then onward to the AI model providers. These connections are secured, and Cursor’s enterprise FAQ explicitly states that all code is encrypted in transit using TLS Enterprise). This means that as your data travels over the internet, it is protected from eavesdropping or interception by industry-standard encryption.

Within Cursor’s architecture, every AI request (e.g. a code completion or question to the assistant) first goes to Cursor’s backend servers, even if you have configured a personal API key for OpenAI or other models Security). Cursor’s server then forwards the request to the appropriate AI model (such as OpenAI’s GPT or Anthropic’s Claude) over secure channels. This design allows Cursor to do final prompt assembly and include any custom model logic before calling the external API Security). The implication for data in transit is that your code passes through multiple hops (your machine → Cursor server → model API), but each hop is encrypted. Furthermore, Cursor has obtained zero-retention assurances from its AI partners, meaning that those model APIs should not retain the data after responding Security). This reduces the risk of your code lingering in any third-party system beyond the immediate transit needed to get a result.

In addition to encryption, Cursor employs other transit-related safeguards. For instance, when Privacy Mode is on, Cursor segregates requests internally so that even if a request header were missing, it defaults to treating the data as sensitive Security). This kind of defensive design ensures that data in transit is always handled with the highest privacy setting unless explicitly flagged otherwise. From a UK government perspective, the use of TLS 1.2 (or higher) aligns with government security standards for protecting data in transit, and the clear delineation of how data flows to third-party AI services helps in assessing supply chain risks. Organizations should ensure network monitoring and approval processes account for Cursor’s endpoints (which will be connecting to US cloud services), and they may want to use additional VPN or private network controls if required by policy. Overall, data in motion with Cursor is well-protected by encryption, similar to other cloud services and coding tools like GitHub Copilot.

4.3 Data at Rest

For data stored within Cursor’s systems (“at rest”), the company implements strong protections and minimises what is retained. All code data that does get stored on Cursor’s servers is encrypted at rest using AES-256 encryption Enterprise). This means that if someone were to access the storage without authorisation, they would encounter encrypted blobs rather than plaintext code. However, under normal operation with Privacy Mode enabled, very little code data is ever written to disk in the first place. Cursor’s design is such that code and prompts are processed in memory and via ephemeral caches, then discarded. The security page notes that any temporary caching of file contents on the server is done using client-provided encryption keys that exist only for the duration of the request Privacy Policy). In other words, when Cursor temporarily holds a snippet of your file to reduce latency, it encrypts that snippet with a key from your client and deletes both the snippet and the key once the request is fulfilled Privacy Policy). This approach ensures that plaintext code is not lingering persistently on their servers.

If Privacy Mode is off, some data at rest is stored to enable product features and improvements. For example, Cursor may store certain prompts or code fragments in its database or logs as part of telemetry Privacy Policy). These could be used to train Cursor’s own models or to troubleshoot and enhance the AI suggestions. The scope of stored data in that case includes: prompts you sent, AI responses, and possibly code context around what you were doing (editor events). Cursor clarifies that such data might be saved if you opt out of Privacy Mode Concerns about Privacy Mode and Data Storage - Discussion - Cursor - Community Forum). For enterprise users and anyone concerned about retention, the simple solution is to keep Privacy Mode on, which guarantees none of your code is kept on Cursor’s servers or any third-party storage Cursor – Privacy & Security). In Privacy Mode, even usage analytics are limited to non-code metadata (for instance, incrementing a counter for “number of completions triggered” but not logging the content of those completions) Security).

Apart from source code, derived data from code may be stored. Cursor’s codebase indexing feature is illustrative: when enabled, Cursor computes vector embeddings of your code files. These embeddings (essentially numerical representations of file content) and some metadata like hashed or obfuscated file paths are stored on Cursor’s servers (using a service called Turbopuffer on Google Cloud in the US) Security). Importantly, the actual file text is not stored as-is – the system only retains the embeddings and metadata to allow searching, and these cannot be easily reversed to original code Cursor – Privacy & Security). If you were to disable indexing, or never use it, then even these derived artifacts would not be present. Cursor also notes that none of the stored embeddings for code indexing are used to train AI models; they are strictly for providing relevant context to you during usage Security).

In terms of personal data and account information at rest, Cursor will hold items like your account email, subscription details, and any settings, as with any SaaS product. These reside in databases (e.g. MongoDB for some analytics, Stripe for billing data) Security). Such data is protected in line with their SOC 2 controls and privacy policy. If a user or an organisation decides to stop using Cursor, the platform provides an account deletion option in the settings. On deletion, all data associated with that account (including any stored code embeddings or telemetry) is purged within 30 days from all systems and backups Security). This allows government users to enforce data removal if required (for example, at contract end or if a project using Cursor concludes and policy dictates data must be wiped).

To summarise, Cursor’s data-at-rest strategy emphasises encryption and minimal retention. With Privacy Mode engaged, essentially only non-sensitive metrics and anonymised vectors are stored, not source code. UK government adopters should nevertheless perform due diligence: reviewing encryption key management (Cursor uses cloud provider defaults, likely), ensuring any data at rest in non-UK regions is acceptable under their data governance rules, and possibly seeking assurances or audit rights via contract to verify these controls. The available documentation and certifications (SOC 2) indicate a strong approach to safeguarding data at rest in line with modern cloud security practices Enterprise).

5. Audit Logging

Audit logging and monitoring in Cursor comes in two forms: internal logging by Cursor for security/diagnostics, and user-facing usage analytics for enterprise administrators.

From the user organisation’s perspective, the Business/Enterprise plan includes an Admin Dashboard that surfaces key usage metrics Pricing). Through this dashboard, team admins can see statistics such as the number of AI queries made, completions accepted, and active users over time. This provides a form of audit trail in terms of usage patterns – for example, an admin could tell which developers are using the AI features heavily and during what timeframe Enterprise). It’s not explicitly stated if per-user logs are available for each prompt or completion, but the emphasis is on “detailed usage analytics” rather than raw log data. This likely means admins get aggregated information (counts of requests, perhaps breakdowns by feature) rather than the content of those requests, especially since Privacy Mode means the service isn’t retaining the content long-term. Still, these analytics help satisfy some oversight requirements by letting an organisation monitor how the AI coding tool is being used in their environment. Access to the admin dashboard is restricted to approved admin users in the organisation, and authentication is secured (with SSO integration available, as noted under access controls). There is no indication of an ability for a customer to retrieve full chat transcripts or code logs – which aligns with the privacy stance of not storing them in the first place.

Internally, Cursor does maintain logs for operational purposes, but with careful controls. All server requests go through a proxy which separates traffic into privacy-mode vs. non-privacy-mode pipelines, and for the privacy-mode pipeline, logging is greatly restricted Security). By default, the logging functions on the privacy side do nothing or omit any code data, to avoid accidentally recording sensitive material Security). Cursor uses monitoring tools like Datadog and Sentry for error tracking, but they explicitly state that for users with Privacy Mode on, no code content will appear in logs or error reports Security). Even analytics platform Amplitude is used only to record high-level events (like “user invoked completion X times”), not the substance of the code Security). For non-privacy-mode usage, more data might be logged, but those logs are internal to Cursor’s systems and protected by their security controls (accessible only by authorised Cursor engineers under strict conditions). If an enterprise customer needed an investigation (e.g. suspected misuse or a security incident), Cursor’s team could potentially query their internal logs for relevant event IDs or timestamps, but they would not find source code in those logs if Privacy Mode was enabled – which it always is for enterprise by default.

In terms of access to logs, Cursor follows the principle of least privilege internally Security). Infrastructure access is limited to team members who need it, and multi-factor authentication is enforced for accessing systems Security). Audit logs of administrative actions on their side (like who accessed what) are presumably maintained as part of SOC 2 controls, though those are not public. For a UK government user, the main audit consideration is whether they can get sufficient records of Cursor usage. They will get usage metrics via the admin console and can request additional info if needed through Cursor’s support (the trust center may provide more detailed security reports on request). However, because of the ephemeral handling of data, you should not expect a comprehensive content log of every code snippet that was processed by the AI – this is by design to protect your data. This approach aligns with NCSC guidance to minimise logs containing sensitive data, but it means auditing is focused on metadata. If detailed auditing of content is required (for instance, to review what code was sent to an external model), Cursor’s current design would not support that without turning off privacy (which is not advisable for sensitive code).

In summary, Cursor provides basic auditing through admin-visible usage statistics and ensures any internally kept logs are sanitized. Government security teams evaluating Cursor may request to see Cursor’s security audit reports or SOC 2 audit findings (available via their trust center) for assurance that logging and monitoring controls are in place Enterprise). It would also be prudent to include contractual terms about breach notification and log retention, given GDPR and government requirements, as the forum discussions have noted the desire for more clarity in these areas Do the Cursor Policies comply with GDPR fully? - Discussion - Cursor - Community Forum).

6. Access Controls

Cursor incorporates several layers of access control to ensure that only authorised users and actions occur within the tool, which is important for enterprise use in government.

At the user access level, Cursor supports integration with enterprise identity systems. Business and Enterprise plans come with Single Sign-On (SSO) support, including SAML 2.0 and OIDC, with just-in-time provisioning (Enterprise). This allows a department to tie Cursor access to its existing identity management – developers can log in with their corporate credentials, and if someone leaves the organisation, their access to Cursor can be centrally revoked. Account roles in Cursor’s team setting are essentially “admin” (team administrators who can manage seats and settings) and “member” (regular users). Admins can invite or remove users from the team, manage billing, and enforce settings like Privacy Mode org-wide (Pricing). It’s noted that Privacy Mode is enforced by default at the organisation level for business plans (Cursor – Privacy & Security), meaning individual developers cannot turn it off and accidentally expose code; even if a client’s UI somehow didn’t show it, the server will treat them as privacy-mode users by default (Security). This enforced policy is an important access control for data: it ensures an organisational policy (no code retention) cannot be overridden by an end-user. Additionally, Cursor’s backend double-checks team membership on each request – if the user belongs to a team that mandates privacy mode, the request will be handled in privacy mode regardless of the client setting (Security). This protects against misconfiguration or tampering at the client side.

In terms of privilege within the application, Cursor runs on the developer’s machine with the same permissions as the user running it (since it’s essentially an IDE). It doesn’t by default have autonomous write access to your repositories beyond what you yourself do with it. Any code changes the AI suggests happen in your editor session; you review and save them just as you would with any IDE. The question of “preventing Cursor from committing directly to git” is often raised as a safeguard. Out of the box, Cursor does not automatically commit or push code to any remote repository on its own. Git operations (commits, pushes) have to be initiated by the user. While Cursor provides features to help generate commit messages or even run certain Git commands via the agent, these require user action and confirmation (Features). By default, any destructive or external actions the AI agent tries to perform (like running a terminal command, which could include a git commit/push) will prompt the user for confirmation (Features). This ensures the developer remains in control of what changes are actually applied to the codebase and what gets sent to version control systems. For additional assurance, a team could establish internal policy that developers must review all AI-generated changes in a merge request before merging to protected branches, etc., just as a code review control. Cursor doesn’t introduce new vulnerabilities in Git usage beyond those a normal IDE might – it respects file system permissions and relies on the user’s Git credentials/config on their machine for repository access.

Another aspect of access control is internal access to systems and data on Cursor’s side. As mentioned in Data Management, Cursor’s team operates on a least-privilege model: infrastructure and database access is restricted to a small subset of engineers, with MFA enforced (Security). They also use a third-party auth provider (WorkOS) for handling user authentication and SSO integrations (Security), which means they delegate identity security to a reputable auth platform, reducing the risk of custom auth bugs. WorkOS will store some personal data (names, emails) for login purposes (Security), but it adds SAML support and ensures things like password policies or MFA from the organisation can be enforced at login.

For government solution architects, it’s worth noting that Cursor currently does not offer an on-premises or private cloud deployment option (Enterprise). All users access the same multi-tenant cloud service. However, the separation of data by organisation (logical tenant isolation) and the strict Privacy Mode controls mitigate the risk of any cross-tenant data leak. Each organisation’s data (what little is stored) is tagged and isolated in their databases, and no other customer can access it. Also, as a VS Code fork, Cursor supports many of the same local configurations – e.g., you can use a local proxy if required for internet access, and it inherits VS Code’s security sandbox for running extensions, etc. Cursor signs its application releases and since it is based on an open-source core, its integrity can be inspected (they periodically merge upstream VS Code changes to ensure security patches are included (Security)).

In summary, Cursor provides robust access controls suitable for enterprise use: SSO for user authentication, administrative controls at the team level, enforced privacy settings, and user-in-the-loop confirmations for any automated actions. These measures, combined with standard developer workstation security, mean the risk of unauthorised access or actions via Cursor is low. The primary consideration is ensuring that only approved users in the government entity can access the tool (which SSO addresses) and that those users follow development best practices when using AI assistance (e.g. code review of AI outputs, no sensitive data in prompts unless policy allows). By aligning Cursor’s use with existing DevSecOps controls, a government team can maintain a strong security posture while benefiting from the AI features.

7. Compliance and Regulatory Requirements

Cursor has begun to align with industry security standards and certifications, which is important for government adoption. Notably, Cursor (Anysphere, Inc.) is SOC 2 Type II certified (Security). This certification indicates that an independent auditor has evaluated Cursor’s security controls (and possibly availability, confidentiality, etc.) over an extended period and found them satisfactory according to the SOC 2 criteria. UK government security assessors may request the SOC 2 report for review; Cursor makes this available through their Trust Center (Security) on request. The SOC 2 Type II compliance strongly suggests that the company has formalised policies for security, data handling, and incident response, which will overlap with many UK GOV security principles.

In terms of GDPR and UK GDPR, Cursor’s Privacy Policy and practices indicate general compliance with data protection requirements. They obtain user consent (by virtue of the user agreeing to the terms and enabling features), and they offer rights such as data deletion (the account deletion process) and data access on request. They’ve addressed international transfers with SCCs (Privacy Policy), as mentioned, and their zero-retention approach for Privacy Mode is aligned with the principle of data minimisation. There was community discussion about some GDPR areas for improvement – such as being more explicit about telemetry data consent and breach notifications (Do the Cursor Policies comply with GDPR fully? - Discussion - Cursor - Community Forum) – so the UK government might want to confirm those points during procurement. For example, ensuring a proper Data Protection Impact Assessment (DPIA) is done and maybe obtaining a signed Data Processing Agreement that covers UK GDPR specifics (e.g. defining Cursor as a processor for any personal data in code, committing to 72-hour breach notifications, etc.). Since government code could contain personal data or other protected data, it’s key that Cursor’s contractual terms meet the bar for handling such data. Cursor does allow customers to enter separate agreements, so a tailored DPA or contract for a government department could be negotiated.

On the cloud security front, Cursor’s design and controls map well to many of the NCSC’s Cloud Security Principles. For example, Principle 2 (Asset Protection & Resilience) is addressed by encryption at rest and backup data limits (Enterprise) (Security), Principle 3 (Separation) by their multi-tenant isolation and privacy mode pipeline separation (Security), Principle 4 (Governance) by having SOC2 governance in place and clear assignment of security responsibility, etc. They also engage in regular penetration testing by third parties and can provide an executive summary of the latest pen test results (Security), which aligns with Principle 8 (Security Monitoring) and Principle 14 (Secure Incident Management) by proactively finding and fixing vulnerabilities. Cursor has a vulnerability disclosure program (via a GitHub Security page) to encourage researchers to report issues (Security). While not explicitly stated, their fast update cycle (tracking VS Code releases) and cloud delivery model mean security patches can be rolled out quickly to all users, which is good for compliance with any vulnerability management requirements.

In terms of other certifications: as of early 2025, Cursor has not announced ISO/IEC 27001 certification or FedRAMP authorization. SOC 2 is their main third-party attestment. They might be working towards other frameworks as they grow (the presence of big corporate customers often leads to ISO 27001 or others down the line). For now, government users should rely on the SOC 2 report and their own evaluation. If necessary, a risk assessment against the 14 Cloud Security Principles (NCSC) can be performed – from the information provided:

• Data in transit protection: TLS 1.2 enforced (Enterprise).

• Data at rest protection: AES-256 encryption and privacy-focused storage (Enterprise) (Privacy Policy).

• Supply chain security: Known subprocessors listed, no high-risk jurisdictions (Security).

• Operational security: SOC2 processes, regular logging/monitoring (with privacy-safe logging) (Security).

• Access control: SSO and least privilege internal access (Enterprise) (Security).

• Secure development: Based on VS Code (which has its own security scrutiny) and frequent updates (Security); Cursor’s team is responsive to vulnerabilities (via disclosure program) (Security).

Finally, compliance with UK government IT policies (like Technology Code of Practice or handling OFFICIAL data in cloud) will require that departments ensure a proper contract with Cursor/Anysphere is in place. This should cover data protection, security obligations, and liability. The good news is that Cursor’s enterprise offerings show awareness of these needs – e.g., enforceable privacy mode and zero-retention are strong features for compliance, and the company is transparent about its practices. The potential concerns would be mainly data residency (US-based processing) and the relative newness of the product (ensure it has been assured for use). Each department’s SIRO/CISO would need to sign off on that risk after reviewing the materials. Provided those considerations are addressed, Cursor can likely meet the key regulatory requirements for use at OFFICIAL level, given its SOC 2 compliance, GDPR-aligned policies, and technical safeguards. As always, ongoing compliance will require monitoring any changes to Cursor’s policies or architecture (the Trust Center and Security page are updated as the product evolves, such as the recent Feb 2025 security update (Security)). Keeping an open line with the vendor for updates will help ensure continuous alignment with UK government standards.

References:

• Cursor Security Overview
• Cursor Enterprise
• Cursor Privacy Policy
• Cursor Pricing
• Do the Cursor Policies comply with GDPR fully?