Trust & Security

Compliance

• GDPR / UK GDPR: Org Loom acts as a data processor. A Data Processing Addendum is available on request.
• CCPA / CPRA: Org Loom does not sell personal information.
• HIPAA: Org Loom is not a Business Associate and does not offer a BAA. See Section 5 of our Terms for our PHI stance.
• PCI DSS: not certified. Your subscription payments are processed by Stripe, so Org Loom never sees your card information. Because we are not PCI certified, customers agree not to load cardholder data from their own Salesforce records into Org Loom (see Restricted data).
• SOC 2: not certified. Our security architecture is documented below, and our canvas core is source-available for direct review.

Restricted data

You agree not to use Org Loom to upload, store, view, or transmit PHI (HIPAA), cardholder data (PCI DSS), government-classified or export-controlled data, or children's personal information subject to COPPA.

Org Loom authenticates to Salesforce as the signed-in user, so its permissions do not extend beyond those of the authenticated Salesforce user. You are responsible for keeping restricted data out of the records and fields you push into Org Loom. Full enforcement terms live in Section 5 of our Terms of Service.

Architecture and data handling

• You own the connection. Org Loom authenticates to Salesforce via OAuth with your credentials and acts only within your user's permissions. The refresh token used to renew your session silently is held in server memory only; it is never written to our database and is discarded at sign-out, disconnect, or server restart.
• Canvas storage in your org. Saved canvases live in your Salesforce org as a custom object (Orgloom_Canvas__c) with the body stored as an encrypted Salesforce file. The latest three encrypted saved bodies are retained for recovery. Access requires both the applicable Salesforce sharing and an Org Loom canvas role.
• Collaboration is filtered for each user. While a saved canvas is actively shared, bounded live state is held temporarily in process memory. Before content is sent to a recipient, it is filtered using that person’s Salesforce access. Submitted teammate responses are encrypted and stored privately in Salesforce until the canvas owner merges them.
• Keys live in your org, not ours. Each canvas and upload batch is encrypted with its own data encryption key, wrapped by a key encryption key stored in your Salesforce org as a Protected Custom Setting, readable only by the Org Loom managed package's Apex methods. Org Loom's database stores only the wrapped data encryption keys. During an authorized request, plaintext and the plaintext data key exist transiently in the web process; persistent wrapped keys cannot decrypt anything without your org's key encryption key; every decryption goes through an Apex call inside your org during your active session. The protected root key is inaccessible to subscriber users and administrators and never leaves your org. The current package does not expose a destructive key-deletion operation.
• Encryption. AES-256-GCM for canvas bodies, submitted contributions, and upload-batch ledgers; AES-256-CBC with HMAC-SHA256 for the key-encryption-key wrap (Apex does not offer GCM yet); TLS 1.2+ in transit.
• Activity history in your org. Data-touching audit events (uploads, recalls, canvas saves, share changes) are queued best-effort to a custom object (orgloom__Audit_Event__c) in your Salesforce org. Successfully delivered rows are owned and retained on your terms; durable delivery/reconciliation is still being hardened.
• AI data flow. In-product generation sends the prompt and selected schema metadata to Anthropic; existing canvas records are not automatically included, but record data typed into the prompt is sent. MCP uses the client you configure. Under Anthropic's commercial terms, submitted data is not used to train models.

Access control

• Workspace plan, member roles, and capability gates control what each user can do. Per-user overrides let admins grant or deny specific actions.
• Production-org connections can be gated behind an admin-approval step, configurable per workspace, so non-admin members cannot silently push data to prod.
• Org Loom personnel access production systems only when needed for an authorized support case, service operation, or security incident. Access is limited by provider roles and reviewed using the provider evidence available for the applicable plan. Do not send Salesforce record contents in a support request unless necessary.

Subprocessors

Org Loom uses a small set of subprocessors to deliver the service. The current list, with purpose, data categories, and DPA links, is in the Privacy Policy. Material changes are emailed to registered users before taking effect.

Vulnerability disclosure

Security research is welcome. Report findings to security@orgloom.com. Please email before testing anything intrusive (for example authenticated fuzzing or denial-of-service simulation) so we can scope the engagement. We aim to acknowledge reports within 3 business days and provide an initial assessment within 7.

Source transparency

The deployment version manifest reports the application commit and links it to the corresponding source-available canvas core. This provides release traceability, not cryptographic proof of the remote server. The public repository contains the canvas core only; account, billing, and other hosted-service code remain private. Repository use is governed by its license, while orgloom.com is governed by our Terms of Service.

Contact

Security questionnaires and assessments: security@orgloom.com.
Privacy and data-subject requests: privacy@orgloom.com.
Procurement and legal: legal@orgloom.com.

See also: Terms of Service · Privacy Policy.