Trust & Security

How Release Assurance protects customer data and connects to Salesforce.

Release Assurance is a managed regression-testing service for Salesforce. We run our own automated tests against customer-approved Salesforce environments and return the resulting evidence — such as run status, screenshots, videos, and reports — to authorized customer users.

This overview is written for customer architects, security teams, and technology reviewers. It describes the controls we operate and the guarantees they provide. We deliberately describe what each control achieves rather than its internal implementation; for a deeper review, we complete security questionnaires and provide additional detail directly to prospective customers.

Security posture at a glance

1. Service architecture

Release Assurance runs on Google Cloud. The service is organized around two separated planes:

• a customer-facing application that authenticates users, applies authorization and tenant boundaries, dispatches test runs, and serves stored evidence; and
• an isolated execution environment that carries out a single test run and returns its results.

The two planes run under separate cloud identities. The execution environment has no standing access to our data store or to customer evidence; it works only with what a specific run requires and returns results through authenticated, run-scoped channels.

Customer data is encrypted in transit and at rest, and the primary data store is not exposed for direct access from untrusted networks. Access to it requires an authenticated internal path.

2. How Release Assurance connects to Salesforce

Customer-controlled connection

Release Assurance connects through a Salesforce Connected App and a customer-approved automation user. The customer controls that user, its permission assignments, and the Connected App configuration, and can withdraw access at any time by disabling the user, revoking its authorization, or changing the Connected App in Salesforce.

We use certificate-based OAuth rather than passwords. Release Assurance never requests or stores the automation user's Salesforce password. The signing material used to establish a connection stays within the platform and is never handed to the execution environment; the access granted for a run is short-lived.

Environment policy

Release Assurance is sandbox-first. Connected environments are classified before any test runs, and sandbox or scratch orgs are accepted by default. A production Salesforce org is rejected unless a customer has explicitly and verifiably authorized that specific org. This is a deliberate, recorded exception — never an automatic fallback. For an engagement intended to remain sandbox-only, no production org is authorized.

Least-privilege Salesforce user

Customers should use a dedicated, non-human automation user rather than a personal administrator account, with permissions limited to the business processes under test. If Salesforce presents a step-up or high-assurance identity challenge, Release Assurance stops and reports a clear failure rather than attempting to work around it. Broadly privileged Salesforce users are more likely to trigger those challenges, which is a further reason to use a narrowly scoped automation identity.

3. User authentication and sessions

Customer sign-in is handled through a managed identity provider. At sign-in we verify the identity, confirm the sign-in method is one we permit, and require a verified email address.

Release Assurance then issues its own application session. That session is cryptographically signed and tamper-evident, is not accessible to scripts running in the browser, is transmitted only over encrypted connections, and expires both after a period of inactivity and after a fixed maximum lifetime. Sessions can be revoked centrally, so a logout or an administrative action invalidates outstanding sessions.

Access to sensitive actions can require recent re-verification. Current customer sign-in is passwordless email, which we treat as single-factor authentication; we do not overstate our authentication assurance, and we continue to strengthen sign-in for privileged accounts.

4. Authorization and administrative access

Release Assurance applies role-based authorization for platform administrators, customer administrators, and customer users. Privileged actions are checked on the server; the interface never hides a capability the server would otherwise allow.

Customer users operate only within their own account. Platform-administrator access is separate from customer membership and is intended for Release Assurance operations and support. When a platform administrator enters a supervised customer-support session, elevated administrative powers are suspended for that session, and the activity is logged and continually re-checked.

Test runs execute under a single, explicitly assigned identity. If the requested identity is ambiguous or unavailable, the run fails rather than silently selecting another account.

5. Tenant isolation

Release Assurance is a multi-tenant service, and customer separation is enforced in layers rather than relying on any single check. Requests are bound to the authenticated customer, queries are scoped to that customer, and — importantly — an independent control at the data layer prevents one customer's records from being returned in another customer's context, even if an application-level mistake were made.

The service is built so that this data-layer isolation cannot be bypassed by the components that serve customer traffic, and it refuses to run in a configuration that would weaken it. We test these boundaries continuously as part of our development process.

This isolation is an independent backstop; it complements, and does not replace, the customer-scoping applied throughout the application.

6. Test execution security

Release Assurance is a managed service. Customers request coverage and review results; they do not upload or run arbitrary code. Our test code is authored and maintained by Release Assurance.

Each run executes in a separate, single-use environment that is created for that run and discarded afterward. The execution environment is given only the access a specific run needs, has no standing access to our storage or database, and does not receive the credentials used to protect the platform's internal connections. Tests are validated before they are allowed to run.

This design is intended to contain mistakes and limit the impact of any single run. It is not presented as a hostile-code sandbox, because customers do not supply the code that runs.

7. Data we collect and store

Depending on the workflows under test, Release Assurance stores:

• account, user, environment, schedule, and test-configuration information;
• the identifiers and connection settings for the Salesforce automation user;
• our test definitions and their version history;
• run status, timing, failures, and operational logs; and
• run evidence, which may include screenshots, videos, reports, and values visible in the tested Salesforce interface.

Customers should assume that evidence can contain personal or confidential data visible to the automation user. The automation user's permissions and the data present in the chosen test environment are therefore an important part of the customer's own security boundary.

Release Assurance does not store Salesforce passwords, and Salesforce access tokens are not retained in our database or kept as customer artifacts. Sensitive values such as API keys are stored only in a non-recoverable, hashed form.

8. Evidence protection and redaction

Run evidence is stored privately. Listing or downloading it requires an authenticated Release Assurance session and account-scoped authorization, and it is served only through our own authenticated routes — never through a public storage link.

Before evidence is stored, Release Assurance removes recognized Salesforce session credentials from the captured material. If a piece of evidence cannot be processed safely for this, it is withheld rather than stored in its original form.

This reduces the chance of credential exposure. It is not a general-purpose data-loss-prevention system, and it does not remove ordinary business records that are simply visible in a screenshot or video.

9. Retention and deletion

The default retention period for completed runs and their evidence is seven days, and it can be configured per customer. A scheduled process removes expired runs and their associated evidence.

Customer offboarding supports:

• deactivation, which stops access and scheduled activity without deleting data;
• legal hold, which prevents deletion while preservation is required; and
• permanent deletion, an irreversible operation that removes the customer's stored data, anonymizes any orphaned personal details, and deletes the customer's evidence.

Stored-data deletion is recorded together with its audit entry, and evidence deletion follows. Backups are maintained for operational resilience; specific backup, restore, and residency commitments for a customer's environment can be confirmed during contracting.

10. Secrets and service identities

Application secrets — including database credentials, session-signing material, and Salesforce signing keys — are held in a managed secrets service and provided to the running service at deployment. They are not committed to source control or built into container images.

Different parts of the platform run under different cloud identities with separately scoped permissions, so no single component holds more access than it needs. Release Assurance also supports per-environment Salesforce signing keys to limit the blast radius of any single key.

11. Application and network controls

Release Assurance applies current web-application hardening practices, including a content-security policy, restricted cross-origin access, protections against cross-site request forgery, request and upload size limits, typed validation of incoming requests, validation of Salesforce endpoints to guard against server-side request forgery, and rate limiting on authentication and other sensitive paths. Error responses are sanitized, and the service produces structured operational logs.

Operational telemetry is centralized, and we maintain alerting for important service conditions.

12. Audit logging

Release Assurance records authentication events — such as session creation, renewal, rejection, revocation, and logout — and records designated security-sensitive administrative operations with the relevant actor, action, target, and context.

Where an operation's control requires it, the business change and its audit record are saved together, so a change is not committed without its corresponding audit entry. This applies to the operations covered by that control; we do not represent every write in the system as an immutable audit event.

13. Secure development practices

Security controls are maintained alongside the application. Our engineering practice includes infrastructure defined as code, peer review and automated testing on changes, controlled database migrations, validation of our published tests before they can run, managed dependencies and container images, and documented threat models for the areas that matter most — sessions, tenant isolation, retention, and test execution.

We will provide additional architecture detail and complete customer security questionnaires as part of due diligence. We do not claim an independent penetration test, SOC 2 report, ISO 27001 certification, or other third-party attestation unless one is provided explicitly.

14. Compliance and service providers

• SOC 2: Release Assurance is not SOC 2 certified. SOC 2 Type I is a roadmap objective, currently targeted for 2027. A target is not a completed audit or certification.
• Data Processing Addendum: A GDPR-oriented DPA, including data-processing terms and subprocessors, is available for customer review. Contract language should be reviewed and executed by the parties before being treated as binding.
• Service providers: The platform is hosted on Google Cloud. We use a transactional-email provider for service messages, an optional error-monitoring provider, and a scheduling provider for website and demo bookings. The current subprocessor list is provided with the DPA.
• Data location: The deployed region and any specific data-residency requirement should be confirmed during contracting; this page does not make a universal residency commitment.

15. Shared security responsibilities

Release Assurance secures the platform and the data entrusted to it. Customers retain important responsibilities:

• use a dedicated Salesforce automation user;
• grant only the Salesforce permissions the agreed workflows require;
• prefer representative test data over unnecessary production-derived sensitive data where practical;
• review Release Assurance user membership and promptly report access changes;
• notify Release Assurance before changing or revoking the Connected App configuration when continuity is required; and
• tell Release Assurance about legal-hold, deletion, residency, or retention requirements that differ from the standard service.

16. Frequently asked questions

Security review contact

For architecture reviews, security questionnaires, DPA requests, or reports of a suspected vulnerability, contact your Release Assurance representative. A dedicated public security mailbox and response-time commitment will be published once that process is in place.

Last reviewed 14 July 2026 · Version 1.0