Controlled evaluation

Evaluate Tunnel Sovereign against your operational environment.

A demonstration shows what a vendor chose to show. An evaluation answers the questions your organization actually has to answer. Tunnel runs controlled evaluations with a defined scope, a defined duration and a defined set of questions agreed before it starts.

  • Defined scope
  • Your environment
  • Your evaluators
  • Written findings

EVALUATION BRIEF

Download the Controlled Evaluation Brief

Twelve pages: what the platform controls, what Tunnel Command does not require in order to control it, which platforms are implemented, what evidence exists today and what does not, what a controlled evaluation involves, and what it cannot establish. Enough for a technical reader to reach a view before the first call.

Download the Controlled Evaluation Brief

PDF · 12 PAGES · NO REGISTRATION

Why it works this way

The organization sets the questions.

Every organization that deploys communication infrastructure of this kind has a specific reason, a specific risk owner and a specific set of conditions under which the answer has to hold. An evaluation is built around those, not around a feature list.

Questions organizations typically bring

Who holds the deployment and enrollment authority? What exactly does the relay hold, and for how long? What happens to communication when the network is gone? What happens to a device lost in the field? What can an administrator see, and what can they never see?

Conditions organizations typically set

Their own devices and device policy. Their own network, including its absence. Their own compartment structure. Their own administrators and role separation. Their own jurisdiction and hosting constraints.

Responsibilities

What each side brings.

An evaluation stalls when this is discovered halfway through. It is agreed in the scoping session and written down.

THE ORGANIZATION PROVIDES

  • An evaluation owner who can make the deployment decision.
  • A technical contact for the environment and the devices.
  • The devices and the network conditions the evaluation will run under.
  • Infrastructure and access where the deployment is sovereign.
  • The questions the evaluation has to answer, in writing.

SOVEREIGN INC. PROVIDES

  • The evaluation package and the deployment for the agreed scope.
  • An architecture and trust-boundary briefing, with an engineer present.
  • Deployment support through installation and enrollment.
  • The evidence package: test vectors, the independently implemented internal verifier and the relay exposure measurement.
  • Engineering participation through the evaluation window.
  • A findings review and a written outcome against the agreed criteria.

Output

What an organization holds at the end.

An evaluation that produces an impression has failed. It produces documents a procurement process can act on.

OUTPUT

A documented outcome

Findings against the criteria agreed before the evaluation began, not criteria written afterwards.

OUTPUT

A procurement record

A contract, an acceptance criterion and a delivery against it. This is the artifact a deployment contract can follow.

OUTPUT

A security findings review

Anything found is routed through a security reporting process rather than a slide.

OUTPUT

A decision, either way

On a known date. An evaluation that cannot conclude is a failed evaluation.

Scope and duration are defined before the evaluation begins. What follows a positive outcome is a commercial scope conversation and then a Managed or Sovereign deployment.

Structure

How an evaluation runs

Five phases, agreed at the start, with the scope written down before anything is deployed.

01 · Scoping
A working session that establishes what the evaluation must answer, who the evaluators are, what environment it runs in and what evidence would satisfy your risk owner.
02 · Deployment
A dedicated deployment configured for the evaluation, managed or sovereign, with or without the Tactical Profile, in the environment the evaluation requires.
03 · Operation
Your operators use the platform under conditions you set: your devices, your compartments, your links, your loss and degradation scenarios.
04 · Technical review
Architecture and security sessions with your evaluators, working through the questions your own assessment process needs answered.
05 · Findings
A written record of what was configured, what was exercised, what was observed and what remains open, including anything the evaluation did not cover.

What is agreed first

Scope is decided before deployment, not during it.

An evaluation without an agreed boundary produces a disagreement about what it proved. These are settled in the scoping session.

  • The capabilities in scope for this evaluation, confirmed in writing before it begins.
  • The deployment model, managed or sovereign, and whether the Tactical Profile applies.
  • The environment, the devices and the network conditions the evaluation will run under.
  • The number of operators, the compartment structure and the duration.
  • Which questions the evaluation is intended to answer, and which it is not.
  • Who the evaluators are, and what evidence their assessment process requires.
  • What is recorded, who holds the record, and what happens to the deployment afterwards.

An evaluation states what it did not cover as clearly as what it did. A finding that an organization discovers after signing is worth less than one it was told about during the evaluation.

Product configurations, integrations and operational capabilities are delivered according to customer requirements, deployment environment, validation scope and applicable authorization. No approval for classified information is represented.

Controlled evaluation

Tell us what the evaluation has to prove.

Describe your environment, the decision the evaluation supports and who will be assessing it. The scoping conversation is the first step, and it is a conversation rather than a form.

Request a Controlled EvaluationRead the security architecture