> ## Documentation Index
> Fetch the complete documentation index at: https://docs.speckle.systems/llms.txt
> Use this file to discover all available pages before exploring further.

# Plans and Governance

> A single place for plan controls, governance features, compliance, and secure sharing practices.

Use this page as a central governance hub for Speckle workspace operations. It
helps technical leads, IT, security, and procurement teams align on controls,
ownership, and rollout decisions.

## Who this is for

* Workspace admins defining guardrails for delivery teams
* IT and security teams reviewing enterprise controls
* Procurement and compliance teams reviewing assurance evidence
* Project leads setting sharing policies for external collaboration

## Governance scope at a glance

This page consolidates:

* Plan-linked governance capability boundaries
* Identity and access management controls
* Data location and deployment model choices
* Secure sharing controls for links and tokens
* Compliance assurance context, including SOC 2

## Plan and control boundaries

Speckle governance capabilities vary by plan. Use these summaries to choose a
fit before implementation detail.

### Explore

* Best for evaluation and lightweight proof-of-concept use
* Basic workspace controls
* Not intended for enterprise identity/compliance requirements

### Team

* Best for active project delivery with broader collaboration
* Higher operational limits
* Suitable when governance requirements are moderate and contractual controls
  are not required

### Enterprise

* Best for regulated and scaled production environments
* Advanced governance controls such as SSO, SCIM, and data residency
* Deployment and commercial options that support stronger assurance workflows

For plan details and limits, see [Billing](/workspaces/billing) and [New Plans
FAQ](/workspaces/new-plans-faq).

## Identity and access governance

Manage identity and authorization at workspace level first, then refine at
project level where needed.

* Authorize by role with [Roles and seats](/workspaces/roles-and-seats)
* Control onboarding and offboarding with [Inviting](/workspaces/inviting)
* Reduce account-claim risk with [Domain protection](/workspaces/domain-protection)
* Centralize authentication via [SSO](/workspaces/sso)
* Automate user lifecycle with [SCIM](/workspaces/scim)

## Data governance and deployment choices

For regulated environments, combine workspace controls with hosting and regional
requirements.

* Keep data in required regions with [Data residency](/workspaces/data-residency)
* Review enterprise network and operational setup in [IT Setup
  Guide](/workspaces/it-setup)
* Choose cloud or self-hosted operating model using [Cloud vs self-hosted
  Speckle](/developers/server/self-hosted-vs-cloud-hosted-speckle)

## Secure sharing governance model

Speckle supports tokenized sharing for models, presentations, and dashboards.
Treat these links as governed access paths, not one-off convenience URLs.

Minimum recommended policy:

* Apply expiration dates to all external links by default
* Require passwords for sensitive or externally distributed links
* Require meaningful labels for issued links (owner, purpose, expiry intent)
* Revoke links immediately when access purpose ends
* Review active tokens on a fixed cadence (for example weekly or monthly)

Implementation guides:

* Models and embeds: [Share your models](/3d-viewer/sharing)
* Presentations: [Presentation](/3d-viewer/presentation)
* Dashboards: [Layout and sharing](/analytics/dashboards/layout-and-sharing)

## SOC 2 and compliance context

Speckle supports enterprise governance programs through platform controls and
deployment options.

Speckle's SOC 2 attestation is current and covers the current reporting year.
SOC 2 documentation is available to Enterprise prospect customers as part of
the security and procurement review process. Request access via
[support@speckle.systems](mailto:support@speckle.systems).

## Common operating patterns

### Pattern 1: Internal delivery workspace

* Primary focus: project throughput with controlled team access
* Typical controls: role governance, invitation policy, periodic token review
* Typical plans: Team or Enterprise

### Pattern 2: Client-facing collaboration workspace

* Primary focus: frequent external sharing and presentation
* Typical controls: mandatory link expiry, password-protected external links,
  strict token revocation cadence
* Typical plans: Team or Enterprise

### Pattern 3: Regulated enterprise workspace

* Primary focus: identity integration, compliance evidence, data location
* Typical controls: SSO, SCIM, residency strategy, formal access governance
* Typical plans: Enterprise

## Governance rollout checklist

Use this checklist when setting up a new governed workspace:

1. Confirm required plan and commercial terms.
2. Configure workspace roles and invitation policy.
3. Set up SSO and SCIM where required.
4. Confirm data residency and hosting model requirements.
5. Define secure sharing rules (expiry, password, revocation cadence).
6. Assign token review ownership and review frequency.
7. Record compliance evidence requirements (for example SOC 2 package request).

## FAQ

### Commercial model and plans

<AccordionGroup>
  <Accordion title="Is Speckle open source, commercial, or both?">
    Both.

    Speckle core platform is open source, including self-hosted deployment
    options. Commercial offerings add hosted operations, enterprise controls, and
    licensed capabilities for organizations that need managed service, stronger
    contractual assurances, or expanded governance features.
  </Accordion>

  <Accordion title="What is the governance difference between open source and commercial deployments?">
    Open-source self-hosting gives you direct infrastructure control and
    implementation responsibility.

    Commercial offerings can provide additional governance capabilities and
    operating models (for example managed hosting, enterprise identity features,
    and licensing terms) depending on your plan and deployment type.
  </Accordion>

  <Accordion title="Can we start on open source and move to commercial later?">
    Yes. This is a common path.

    Teams often begin with open-source self-hosted or lightweight workspace use,
    then move to Team or Enterprise plans as governance, procurement, compliance,
    or scale requirements become stricter.
  </Accordion>

  <Accordion title="How should we choose between Team and Enterprise for governance?">
    Choose Team when you need collaborative delivery controls but do not require
    enterprise identity or compliance-heavy operating constraints.

    Choose Enterprise when you need controls such as SSO, SCIM, stronger data
    governance options, and formal security or procurement assurance workflows.
  </Accordion>

  <Accordion title="Are plan limits and governance controls the same thing?">
    No.

    Plan limits cover operational capacity (for example users, projects, or
    usage thresholds), while governance controls cover how identity, access,
    data location, and external sharing are managed and audited.
  </Accordion>
</AccordionGroup>

### Forma Data Management (ACC) integration governance

<AccordionGroup>
  <Accordion title="Does Forma Data Management / ACC data get copied into Speckle SaaS?">
    In Forma Data Management (ACC) integration workflows, Speckle reads source files from Autodesk cloud storage and creates
    synced models in Speckle for viewing, coordination, and downstream workflows.

    The integration is documented as read-only from Speckle to Autodesk cloud sources, so
    Speckle does not write changes back to your source files. See [Autodesk
    Forma Data Management (ACC)](/connectors/cloud-integrations/acc).
  </Accordion>

  <Accordion title="Does Speckle change data in Forma Data Management / ACC?">
    No. The integration is read-only from Speckle to Autodesk cloud sources.

    Speckle syncs and processes data for Speckle-side use, but does not modify
    the original cloud-hosted files.
  </Accordion>

  <Accordion title="Whose permissions do Forma Data Management / ACC syncs use?">
    Cloud syncs run using the account that set up the connection.

    In practice, access is limited to what that account is already allowed to
    view in Autodesk Forma Data Management (ACC). To reduce risk, use a dedicated least-privilege Autodesk account for
    production syncs.
  </Accordion>
</AccordionGroup>

### Security and compliance controls

<AccordionGroup>
  <Accordion title="What encryption is available (at rest and in transit)?">
    Encrypted sharing is supported through secure links and token controls.

    Public documentation describes HTTPS/TLS transport protection and secure link
    controls (including expiry, optional password, and revocation).

    If you need formal attestations for encryption at rest, key management, or
    control implementation details, request the security package via
    [support@speckle.systems](mailto:support@speckle.systems).
  </Accordion>

  <Accordion title="Can security-sensitive design data leave our controlled tenant boundary?">
    This depends on deployment model.

    Speckle Cloud provides managed hosting with plan-based governance controls.
    If you need stricter boundary control over infrastructure and operations, use
    Enterprise self-hosted deployment and define those controls in your own
    environment. See [Cloud vs self-hosted
    Speckle](/developers/server/self-hosted-vs-cloud-hosted-speckle).
  </Accordion>

  <Accordion title="Can we enforce data residency or regional storage (for example Australia)?">
    Yes, on Enterprise plans.

    Workspace-level region controls are available, and additional regional or
    project-level options can be discussed for stricter residency needs. See
    [Data residency](/workspaces/data-residency).
  </Accordion>

  <Accordion title="Do you provide a current SOC 2 Type II report (or equivalent assurance)?">
    Speckle's SOC 2 attestation is current for the reporting year.

    SOC 2 documentation is available during Enterprise security and procurement
    review. Request access via
    [support@speckle.systems](mailto:support@speckle.systems).
  </Accordion>
</AccordionGroup>

### Sharing, audit, and operational resilience

<AccordionGroup>
  <Accordion title="Can public or anonymous sharing be restricted or disabled?">
    Yes.

    Public exposure is controlled through project visibility. Keep projects
    Private or Workspace if they should not be publicly visible.

    Anonymous access can be controlled through share tokens. In Project
    settings -> Tokens, limit token use, set expiry and optional passwords, and
    revoke tokens when they are no longer needed.

    Regular project links still follow project visibility and role permissions.
    Share tokens provide scoped read-only access for specific sharing workflows.
    See [Share your models](/3d-viewer/sharing) and
    [Configuration](/workspaces/configuration).
  </Accordion>

  <Accordion title="Is audit logging available for support monitoring and compliance requirements?">
    Access to shared data is governed by project visibility, collaborator roles,
    and share token controls.

    Administrators can review and manage issued tokens in Project settings ->
    Tokens, including revocation when access is no longer needed.

    Audit and evidence requirements remain plan and contract scoped. For formal
    compliance reviews, define required evidence up front and confirm delivery
    expectations during Enterprise commercial and security review via
    [support@speckle.systems](mailto:support@speckle.systems).
  </Accordion>

  <Accordion title="How are backups and disaster recovery handled?">
    Backup and disaster recovery responsibility depends on deployment model.

    For self-hosted deployments, your team owns backup policy, restore testing,
    and recovery operations. For Speckle-hosted environments, operational
    reliability is managed by Speckle, with support and SLA commitments defined
    by plan and commercial agreement.
  </Accordion>

  <Accordion title="Can Speckle support air-gapped or isolated recovery requirements?">
    Speckle Cloud is internet-hosted and is not an air-gapped deployment model.

    An air-gapped Speckle deployment is possible, but it is typically bespoke and
    more complex to operate.

    In practice, this usually aligns with self-hosted, open-source-core style
    deployments and a reduced set of cloud-dependent integrations. Backup,
    recovery, and operational controls are then implemented under your internal
    standards.

    Speckle has also been deployed in highly security-sensitive environments.
  </Accordion>

  <Accordion title="Do you publish RPO/RTO targets publicly?">
    RPO and RTO commitments are not presented as one universal public value
    across all deployment models and plans.

    If you need formal recovery targets for procurement or compliance, confirm
    them in your Enterprise commercial and security review via
    [support@speckle.systems](mailto:support@speckle.systems).
  </Accordion>
</AccordionGroup>

### Implementation baseline

<AccordionGroup>
  <Accordion title="What should our team define before go-live for backup and recovery?">
    At minimum, define and approve:

    1. Backup frequency and retention policy.
    2. Restore testing cadence and acceptance criteria.
    3. Named recovery owners and escalation path.
    4. Target RPO and RTO aligned to business impact.
    5. Evidence artifacts required for audits.
    6. A documented failover and communication runbook.
  </Accordion>

  <Accordion title="What is the minimum governance setup before production rollout?">
    Start with this baseline:

    1. Confirm plan and contractual governance requirements.
    2. Configure roles, invitation policy, and ownership.
    3. Enable SSO, then SCIM, if centralized identity lifecycle is required.
    4. Confirm data residency and hosting model.
    5. Enforce external sharing controls (expiry, password, token review and revocation cadence).
    6. Record compliance evidence contacts and review cadence.
  </Accordion>
</AccordionGroup>