Skip to content

Compliance Posture

Endeavor Engineering does not currently hold a SOC 2 or ISO 27001 certification. SOC 2 Type II for the VirtualForge cloud is the target, and the program is underway. We would rather say that on the first line than have you find it on the third call.

What follows is the scope, the approach, and what we can actually give you today.

What is being pursued
Framework SOC 2 — Type II, which reports on how controls operated over a period rather than how they were designed
Also in view ISO 27001, as a later step rather than a parallel effort
Timeline Tied to production launch readiness rather than to a fixed date. We are not going to name a quarter we cannot commit to

Audit scope

In scope: the AWS-hosted production VirtualForge environment. That is where customer data would be processed and stored, and it is the boundary the program is built around.

Out of scope:

  • Our on-premises development estate, except where it holds data or credentials that reach production.
  • Connectors running inside your environment. This one matters and is easy to get wrong: a Seeq connector runs on your Seeq agent, inside your network, reading your historian. That deployment sits within your control environment and is covered by your own controls and audits, not ours. What we are responsible for is the software we ship you and the process that produced it.

We keep the boundary deliberately narrow, and we defend it. As one example: we declined to route knowledge-base analytics into the customer datastore specifically so that marketing telemetry could not widen the audit boundary.

The approach: a by-product, not a sprint

Our position is that SOC 2 is not reachable by a compliance project bolted on at the end. The practices that produce a clean report — recorded decisions, tracked changes, monitored systems, managed access — only produce usable evidence if they were running all along.

So the following exist because they are how we work, and are usable as evidence rather than having been built for an auditor:

  • Decision records. Every significant architectural decision is written down with its context, the alternatives rejected, and the conditions that should reopen it. That is a change-rationale record covering years, not a reconstruction.
  • Change tracking. Documentation and configuration are versioned in Git, which is the source of record. Published documentation is a derived artifact of it.
  • Attributable privileged action. Cloud management activity is captured in a consolidated, validated audit trail so privileged actions are attributable to an actor.
  • Release test evidence. Two test tiers. A hermetic suite runs in CI on every change and again at release — the release build is the gate, so a failing test stops the release rather than annotating it. A final acceptance tier runs against a real source system; that system sits inside our network, so the tier runs on an engineer's host rather than in CI. That run produces an evidence bundle holding both tiers' results, a per-file hash manifest, and the identity of the engineer and machine that produced it — written to versioned, encrypted storage under a 365-day retention lock, so "this version was tested" is a retrievable, attributable artifact rather than a recollection.

Where that stands honestly: the store is live and the mechanism works, but because the bundle comes from the manual acceptance run it exists for the releases where that run happened, not for every release. The pipeline can already be told to refuse a release that has no evidence for its commit. Turning that on by default — and finding a way to reach the acceptance environment from CI — is committed work, not finished work. - Identity foundation. Federated SSO, no long-lived machine credentials, and no shared service accounts. See Security posture.

What we can give you today

A certification is not the only useful answer, and for most reviews it is not the immediate one. Available on request now:

  • A completed security questionnaire, including your own format.
  • An architecture and data-flow walkthrough with the engineers who built it, rather than a salesperson reading a slide.
  • The current subprocessor list — who processes customer data on our behalf and for what — with the corresponding agreements.
  • Our written position on specific controls you need to assess, including where a control is designed but not yet operating. We will tell you which is which.
  • Contractual commitments on data handling, retention and deletion, agreed in writing during contracting rather than inferred from a documentation page.

Interim positions, disclosed

While pre-production we hold some positions that a mature audit posture would not, and we record them explicitly with the conditions that end them — the first of which is generally first external customer. A disclosed interim position with a trigger is a defensible engineering decision. An undisclosed one is a finding waiting to happen.

If you are evaluating us and want to know whether any of those affect you specifically, ask. We will answer the question as asked.

Asking

Reach us through the Endeavor Engineering resources hub or your usual Endeavor Engineering contact. Where our software reached you through a channel partner, that route reaches the same engineers.