Storacle Security Standards

1. Purpose and Scope

2. Your Data Stays in Your Org — and Is Never Read

• Storacle runs entirely within your Salesforce org. There are no external servers, services, or databases. Nothing about your org leaves your org.
• Storacle never reads the contents of your records. The product measures storage: it works with aggregate numbers — record counts and storage usage — and org metadata (which objects exist and how they are configured). The field values inside your business records are never queried, inspected, or processed.
• Storacle never modifies your records. It creates and manages only its own packaged records; it performs no writes of any kind against your business data.
• Storacle's own records live in your org, under your control. The data Storacle does create — snapshots, measurements, alerts, and logs — consists of ordinary records in your org, visible to and administrable by your administrators like any other data, and subject to your org's own security model.

3. No Syndacon Access to Your Org

• Syndacon has no access to customer orgs. The product contains no remote-administration capability, no telemetry, and no channel through which Syndacon can reach into an org where Storacle is installed.
• Support works by invitation only. If you want Syndacon's help inside your org, access happens exclusively through Salesforce's own grant-login mechanism — explicitly granted by you, scoped by Salesforce, time-limited, and revocable by you at any time.

4. Callouts and Credentials

• The only callouts Storacle makes are to your own org's Salesforce APIs. Storacle calls Salesforce's APIs on your org itself to gather the record counts and storage statistics it reports on. It makes no callouts to any external endpoint.
• All credentials stay in your org's Named Credential store. The credential Storacle uses for those same-org API calls is created in your org during setup and held in Salesforce's Named Credential store, protected by the platform. No credential is ever transmitted outside your org or shared with Syndacon.

5. Built on the Platform Security Model

Storacle is developed to Salesforce's security model and secure-coding requirements, as detailed in the Syndacon Security Standards, §4. Salesforce and AppExchange Standards:

• Object- and field-level security and sharing rules are enforced in Apex; the code declares its sharing model explicitly.
• SOQL uses bind variables; dynamic query construction from untrusted input is prohibited.
• Lightning Web Components follow the platform's Lightning Web Security model, with Salesforce's LWC security lint rules enforced on all component code.
• No record IDs, org IDs, usernames, endpoints, or secrets are hardcoded.
• Access to Storacle's features and records inside your org is governed by permission sets you assign — your administrators decide who can see and do what.

6. Release Integrity and Security Review

Every Storacle release passes the full validation pipeline described in the Syndacon Security Standards, §3. Secure Development Lifecycle — layered code review, static security analysis, and test suites that run under non-administrator user contexts — before it is packaged. Promotion of a release is a human-approved step, and the product is submitted to the Salesforce AppExchange security review, with re-submission as required for material changes.

7. Reporting and Review of These Standards

Suspected vulnerabilities in Storacle can be reported to security@syndacon.com; the Syndacon Security Standards, §5. Vulnerability Management describe how reports are handled. This document is reviewed at least annually, and whenever the product or platform requirements change materially. The "Last updated" date above reflects the most recent revision.