Tensor9 is SOC 2 Type II Compliant

What SOC 2 Type II is

SOC 2 is a security framework from the AICPA that evaluates how a company protects customer data. Type I assesses whether your controls are designed correctly at a single point in time. Type II assesses whether those controls actually operated effectively over a sustained window, typically 6 to 12 months, by examining evidence across the whole period: access logs, change records, incident response, vulnerability scans. You can stand up controls the week before a Type I. You can’t do that for a Type II.

We elected to include all the Trust Services Criteria relevant to how our customers depend on us, not just the mandatory Security criterion.

Why this matters when we sit between two trust boundaries

Tensor9 occupies an unusual position in the stack. We help you deliver your product inside your customers’ cloud environments, which puts us between two trust boundaries: you trust us to deploy your software correctly, and your customer trusts you to protect their environment.

When you’re evaluating us, our SOC 2 Type II report is table stakes. It’s how we show our work on security without asking you to take our word for it. The process went smoothly because we weren’t retrofitting controls onto an existing system; the architecture was already there.

Security as architecture, not policy

Most companies treat security as a layer on top of their product. Policies get written, controls get implemented, and someone is responsible for making sure everything stays compliant. That works, but it depends on people consistently doing the right thing. 

The strongest security property is one the system enforces structurally, where the wrong outcome isn’t possible rather than merely against policy.

The way we get there is by exchanging software instead of data. Rather than pulling customer data into our infrastructure, we deploy software into the environments where the data already lives. Software goes in; data stays put. Your application runs inside your customer’s account or datacenter, and your customer’s data, credentials, and secrets never leave their boundary.     

The platform has three layers, and the boundaries between them are critical:

• Our management plane handles coordination. It tracks deployment status, health, and version state. It never sees application data, only metadata.
• Your control plane runs in your own AWS account, not ours.
• Each customer environment is fully isolated, running in your customer’s own account or datacenter, with no connectivity to any other customer.

The result is that we architecturally cannot access your customers’ data, because the components that touch it don’t run in our environment. 

It also keeps your customer in control. Maintenance happens in time-bounded access windows your customer approves, actions are logged to their own systems, and access can be revoked instantly without coordinating with us. They keep using their own tools throughout: secrets stay in their vault, they choose the ingress posture and the network path, and they bring their own databases.

For the full breakdown, including the permissions model, egress-only connectivity, and what each party can and cannot see, see our security principles and the security model documentation.

The audit was natural because the controls already existed

When we looked at what SOC 2 Type II required of us, almost everything mapped to how we already operated.

Our engineering specs, runbooks, and incident response procedures existed before the audit because we built them for ourselves. When the auditors asked for documentation, we pointed them at the same artifacts our engineers use daily. There was no compliance-specific layer of documentation created for the audit. When they asked “how does X work?”, the answer was the same one we give each other internally.

We don’t maintain separate narratives for different audiences. The auditors reviewed the same systems and documents we actually use, and found them working as described, consistently, over the observation period.

What the report covers

The report covers the controls you’d expect: access management, change management, incident response, availability and monitoring, data protection, vendor management, and risk assessment. Existing customers and prospects can request a copy of the full report.

We want to be direct about what SOC 2 Type II is and isn’t.

It verifies that your controls are designed correctly and that you operated them effectively during the audit period. It’s a strong signal of organizational discipline around security. It is not a guarantee that a breach can’t happen, it doesn’t mean every possible attack vector is covered, and it’s an assessment of a time range, not a permanent state.

We treat it as a floor, not a ceiling. The audit confirms we’re doing the basics right and doing them consistently. The architecture, a management plane that only sees metadata and controllers and data that stay in your infrastructure, is what provides the deeper security properties.

Recent events in the compliance industry have made it clear that not all SOC 2 reports carry the same weight. Automation platforms can produce reports that look correct without reflecting real operational discipline. The report matters less than what it represents. Ours was produced by observing controls we built for ourselves and operated daily, long before we engaged an auditor.

What’s next

SOC 2 Type II is one milestone, and the work ahead builds on the same idea: move more of the security guarantees into the architecture itself, where a customer can see and control them. That means more certifications, deeper customer control over operations, richer audit logging, and tooling that generates what a customer’s security team needs for their own review.

For the technical details on the trust boundary, permissions model, and connection security, see the security model documentation.

If your enterprise customers are asking for your SOC 2 report and a security review of how you’d run inside their environment, the architecture behind ours is the part worth your time. Bring your deployment model and we’ll walk through what your customers would see.