No cloud in the path

There is no cloud in the path. That is the plain version, and it is the one a platform owner can repeat in a meeting; the procurement version is that there is no vendor in the data path at all. Most security reviews of a Salesforce analysis tool are really reviews of the vendor’s cloud: where the copied org metadata sits, who can reach it, how it is encrypted, what happens when the vendor is breached. Stood Flows removes that entire surface, and the claim decomposes into three parts, in order. There is no Stood cloud — no Stood backend, no Stood-operated service, no Stood tenancy holding your analysis; nothing is sent to us, ever, in any mode. By default the analysis is local — it runs on the analyst’s machine and stays there as local files. And when a team needs to share it, sharing is explicit and runs on infrastructure the customer owns — your own GitHub repository or your own S3 bucket, with publisher and reader roles governing who can push a refresh and who can only read. Competitors are SaaS scanners that ingest your org’s metadata into their own tenancy; at no point, in any configuration, does Stood hold yours. You cannot breach a server that does not exist.

Read-only, enforced three times

The first question an admin asks is whether the tool can change the org. It cannot: write access is excluded at three independent layers. The application itself contains no code path that writes to a Salesforce org — no update, no insert, no deployment. The Salesforce CLI session it uses is invoked for retrieval only. And the fetch operates on a strict allowlist: only the object types and endpoints named in the published fetch tree are requested, so a compromised or misbehaving analysis cannot wander into data it was never meant to see.

The boundary is architectural, and it is re-enforced on your side by a permission setting: the connecting user is a dedicated read-only user under a least-privilege permission set, prepared with your admins before the first scan. Defence in depth, deliberately — the application has no way to write, and the account it connects with has no right to. Either control alone would hold; the permission set is the one your own admins can audit in Setup, which is why it is part of the configuration rather than something the architecture excuses you from.

Authentication: your CLI, your keychain

There is no new credential store to govern and no new login flow to audit. Stood Flows does not implement its own Salesforce login and does not store credentials: it authenticates through the Salesforce CLI already installed and authorised on the analyst’s machine, and the CLI’s tokens sit where the CLI puts them — the operating system keychain. Revoking access is a Salesforce-side operation you already know how to do: revoke the CLI session, and Stood Flows can fetch nothing. The org’s login history shows the CLI session, so every fetch is traceable on your side as well as ours.

The connecting user needs only read access to the objects and metadata under analysis — a dedicated read-only user, set up through a read-only permission set, is the clean configuration and the first thing a scoped project prepares. No Modify All Data, no admin profile, no OAuth grant to a third party.

What is fetched — and what is not

The boundary that matters to a data-protection review: business records never leave the org. From each org, Stood Flows retrieves configuration and metadata (objects, record types, flows, Apex, validation rules, layouts, profiles), license assignments, and usage counts — not business records. Record volumes arrive as counts per object and per stage — 34,558 cases in a process, not the cases themselves. No customer names, no opportunity amounts, no PII.

The one area that deserves a precise statement is event log analysis, which supplies the DML and I/O views. Event log files give Stood Flows real logins, DbSave (database write) events, and which Apex entry classes actually run — to mention a few. In every case the app reads operation counts — who performed how many operations of which type on which object — not the contents of the records those operations touched.

Worth saying in the same breath: what event-log depth is available depends on your org’s own options. Event log file retention and the hourly detail behind it are licensed features on the Salesforce side — Event Monitoring, typically through Shield — so how far back the usage and I/O analysis can look is a property of your org, not of Stood Flows. The scoping call establishes what your logs can and cannot support before anything is promised on them, and a Quickstart answers it in the first hour. Structure, complexity, volumes and licensing assignment do not depend on it.

Where the analysis lives

Everything lands as local files — JSON and .sfschema — on the analyst’s machine. You can open them, diff them, archive them under your own retention policy, or delete them. There is no format lock-in and no vendor copy: in every mode described below, the only parties holding the analysis are you and the infrastructure you already govern.

Team sharing runs on infrastructure you own

A portfolio analysis is only useful if the architecture board, the platform owners and the renewal team read the same one — so Enterprise sharing exists, and it is built as a governance capability, not a hole in the model. Sharing is opt-in and explicit: until it is switched on, the analysis does not leave the analyst’s machine. When you enable it, it runs on infrastructure you provision and control — your own GitHub repository or your own S3 bucket — inside your existing security perimeter, under your existing access management, encryption and retention rules.

Roles govern the flow. Publishers can push a refreshed snapshot; readers can only read. Each refresh is a versioned snapshot the team subscribes to, so everyone reads the same numbers with the same date on them, and who published what, when, is answerable from your own repository or bucket history. The same channel carries issue tracking through the GitHub plugin, using your GitHub credentials. Stood never holds the repository, the bucket, the keys, or a copy.

What is transmitted, in each mode

• Local mode (the default). Outbound traffic is CLI traffic to Salesforce, and nothing else. No telemetry, no phone-home, no vendor endpoint. The analysis exists only as files on the analyst’s machine.
• Team sharing enabled (opt-in). In addition: publishers push analysis files — the same JSON and .sfschema snapshots, which contain metadata, structure and counts, never business records — to your GitHub repository or S3 bucket, and readers pull them from there. The transport and storage are yours end to end.
• In every mode. Nothing is transmitted to Stood. There is no Stood endpoint in the data path to send it to.

Software integrity

Installers for Mac and Windows are signed, and every release ships with SHA-256 checksums so you can verify an installer before it runs. Updates are explicit — the application does not silently replace itself. Installers are provided when an engagement is scoped; a license key is issued with them.

GDPR posture

Stood is built by Hway Digital SAS, a French company operating under GDPR. The posture is unusually simple to state: analysis data is processed on the customer’s own machines and, where sharing is enabled, on the customer’s own infrastructure, by the customer’s own staff. Stood does not receive personal data in the course of normal product use. Where a Data Processing Agreement is required for procurement, one is available — see below.

Paperwork

For security and procurement teams, on request:

• Data Processing Agreement — countersigned on request.
• Subprocessor list — short, because the product has no backend; it covers the corporate services around it.
• Security architecture document — the fetch allowlist, storage formats, and the sharing model described above, in reviewable form.
• Vulnerability disclosure — report issues to contact@stoodcrm.com. We acknowledge reports and credit reporters who want credit.

Verify it yourself

The strongest security claim is one you can test. Point the opening scan at a full or partial sandbox if that is easier to authorise — we offer it, and plenty of first projects start there — or point it at production, which is where the usage numbers are real. Either way it runs on your machine, with your own network monitor open if you want it: the traffic you will see is CLI traffic to Salesforce, and nothing else. Enable team sharing later and the only addition is pushes to the repository or bucket you configured — verifiable in exactly the same way.