Trust CenterSOC 2

HASP and SOC 2

HASP runs on a managed compliance substrate that holds a current SOC 2 Type II report, and our own direct SOC 2 engagement is underway. This page lays out both — what we inherit today, what we own, and the path to a HASP-direct attestation.

Current posture

What HASP has today, in plain language.

Substrate — available under NDA

The managed compliance substrate HASP is deployed on carries a SOC 2 Type II report covering the compute, managed database, network, and operational controls HASP inherits. Most security teams accept this substrate attestation as evidence for the infrastructure layer while HASP's direct engagement is in progress.

Available under mutual NDA. Email [email protected].

Direct attestation — engagement planned

HASP's own SOC 2 Type II engagement is triggered by the first of: $100K ARR, or the first enterprise contract that contractually requires a HASP-direct report. A Type II observation window runs six to twelve months after kickoff.

We plan to skip Type I entirely — there is no business reason to publish a point-in-time report when the substrate is already Type II and HASP's application-layer controls have been operating continuously since launch.

Trust Services Criteria

Which criteria are addressed.

SOC 2 reports describe how a service organization meets the AICPA Trust Services Criteria. The substrate report HASP inherits from covers Security, Availability, and Confidentiality. When HASP's own engagement starts, the planned scope is the same three criteria for V1, with Privacy added in a subsequent cycle.

Security (Common Criteria)

Logical and physical access controls, change management, risk assessment, and incident response. Inherited at the infrastructure layer from the compliance substrate; extended at the application layer by HASP's gateway, IAM model, and signed audit chain.

Availability

System uptime, capacity planning, backup integrity, and disaster recovery. The compliance substrate carries the substrate availability commitments; HASP's application-layer availability targets and incident handling are described in the control matrix shared on request.

Confidentiality

Designating and protecting confidential information through encryption, access restriction, and disposal controls. The PHI gateway, per-org isolation boundaries, and customer-data retention controls map directly into this criterion.

Privacy (planned, future cycle)

The GDPR / CCPA controls HASP operates — Article 17 erasure, Article 20 portability, consent, sub-processor notice — will be mapped into the Privacy TSC once they have a long enough operating history to support a Type II observation. Not in the V1 scope.

Processing Integrity (out of scope)

HASP does not perform transactional processing that warrants the Processing Integrity criterion. We do not intend to include it. The signed audit chain provides a stronger equivalent for the events HASP does record.

Substrate inheritance

Controls inherited from the compliance substrate.

The compliance substrate covers compute, database, and network. The following controls live in the substrate's SOC 2 Type II report and HASP does not duplicate them. The control matrix we share with prospects calls out every line so your auditor can trace each criterion to the responsible party.

Infrastructure layer

  • Data-center physical security and environmental controls
  • Host hardening, kernel patching, anti-malware
  • Network segmentation between HASP's tenant and the substrate's management environment
  • Vulnerability scanning and intrusion detection on the substrate
  • Backup integrity and substrate-level disaster recovery

Operational layer

  • 24×7 substrate monitoring and alerting
  • Substrate change-management and release controls
  • Substrate-operator personnel access logging on production hosts
  • Substrate-level incident response and customer notification
  • Annual third-party penetration testing of the platform
HASP-owned controls

What HASP operates on top of the substrate.

Inherited substrate controls do not cover the layer where most AI risk actually lives — the gateway between users, agents, models, and customer data. Those controls are HASP's responsibility. They are documented today and will be tested in our direct SOC 2 engagement.

AI gateway and IAM

A single gateway sits between every caller — user, API key, or agent — and every model provider. The gateway enforces tenant boundaries, BAA status, and pre-action authorization. Maps directly into the Security and Confidentiality TSCs.

Signed audit chain

Every PHI-adjacent event is hash-chained and Ed25519-signed. Auditors can verify integrity on their own machine with no HASP software. Verification recipe.

PHI handling

PHI handling is a HASP-owned capability — not outsourced to a third-party AI gateway product. HASP's PHI anonymization pipeline runs inside HASP's tenant boundary before prompts reach the model.

Document request

How to request the report.

  1. Email [email protected] from your work address. Mention SOC 2 and reference your evaluation if you are in an active procurement cycle.
  2. Mutual NDA. We countersign the standard mutual NDA promptly, or execute your form if your security team prefers. The NDA covers the substrate report and the HASP control matrix together.
  3. Bundle delivered. You receive the substrate SOC 2 Type II report, the current bridge letter (if applicable), HASP's signed control matrix mapping each criterion to its owner, and the sub-processor register snapshot pinned to that date.
  4. Walkthrough on request. If your auditor wants to walk through the matrix line by line, we run a one-hour session with compliance and engineering on the call. No extra cost, no enterprise gating.

Active procurement?

Send the questionnaire format your team prefers — SIG, CAIQ, HECVAT, or a custom workbook. Most are completed promptly.

Universal posture

One compliance floor. Every tier.

HASP's compliance posture is universal. Every tier runs on the same compliance substrate, the same gateway, the same signed audit chain. There is no separate "compliance edition" and no tier where audit logging or PHI handling is switched off. SOC 2 substrate inheritance applies to every organization on HASP.

Higher tiers add capacity and isolation — Enterprise gets a dedicated data plane on dedicated infrastructure, custom domains, and SSO — but the underlying SOC 2 posture is the same control set. See pricing for the full tier matrix and the Trust Center for the foundational architectural decision behind this commitment.

FAQ

Frequently asked questions.

Is HASP SOC 2 compliant?

HASP runs on a managed compliance substrate that holds a current SOC 2 Type II report covering the underlying infrastructure, network, and operational controls HASP inherits. HASP does not yet hold its own direct SOC 2 attestation — that engagement is planned and is described in detail on this page. Customers requiring formal evidence today receive the substrate's SOC 2 Type II report (substrate layer) plus HASP's signed control matrix (application layer) under mutual NDA.

Is HASP SOC 2 Type I or Type II?

The substrate report HASP inherits from is a SOC 2 Type II report. When HASP's own engagement begins, the plan is to skip Type I entirely and pursue a Type II observation window directly — there is no business reason to publish a Type I given that the substrate is already Type II and HASP's application-layer controls have been operating continuously since launch.

Can I see HASP's SOC 2 report?

HASP does not yet have a direct SOC 2 report to share. We can share the compliance substrate's SOC 2 Type II report under a mutual NDA. Email [email protected] and reference your evaluation. We can also share HASP's signed control matrix mapping each Trust Services Criterion to the responsible owner (HASP, the substrate, or shared).

Which Trust Services Criteria are in scope?

The substrate's SOC 2 Type II covers Security, Availability, and Confidentiality at the substrate layer. When HASP pursues a direct attestation, the planned scope is the same three criteria for the V1 audit, with Privacy added in a subsequent cycle once the multi-tenant Privacy controls mapped to GDPR / CCPA enforcement are old enough to observe over a Type II window. Processing Integrity is not currently planned — HASP does not perform transactional processing.

Who is the auditor?

The substrate's SOC 2 Type II is performed by a registered CPA firm; the auditor of record is named on the cover of the report itself, which we share under NDA. HASP has not yet selected an audit firm for its direct engagement — auditor selection is part of the engagement kickoff, which is timed to the trigger described below.

How often is the audit performed?

The substrate's SOC 2 Type II covers a rolling twelve-month observation window and is re-issued annually. The most recent report and bridge letter (if any) are both available under NDA. Once HASP's direct engagement begins, our intent is to maintain the same annual cadence with a continuous controls baseline — meaning we operate the controls every day, not only during the observation window.

When will HASP have its own SOC 2 report?

HASP's direct SOC 2 engagement is triggered by whichever comes first: reaching $100K ARR, or signing the first enterprise contract that requires a HASP-direct attestation. A Type II observation window typically runs six to twelve months, so a first report is realistically nine to fifteen months after engagement start. We will not publish a placeholder Type I to shortcut that timeline.

What about inherited controls from the compliance substrate?

The compliance substrate is the managed hosting platform HASP is built on. The substrate is responsible for the physical and logical security of the cloud environment HASP runs in: data-center security, network segmentation, host hardening, vulnerability scanning, intrusion detection, backup integrity, and incident response at the infrastructure layer. Those controls are evidenced in the substrate's SOC 2 Type II. HASP inherits them and does not duplicate them. The control matrix we share calls out, line by line, which controls are inherited, which are HASP-owned, and which are shared.

How are HASP's sub-processors treated in the SOC 2 scope?

When HASP's direct SOC 2 audit begins, the major sub-processors — the compliance substrate, BAA-covered inference providers, and edge/CDN providers — will be in scope with the controls each one carries described in the eventual report. The current sub-processor register is published at /sub-processors and is governed by the 30-day advance-notice commitment.

What encryption modules does HASP use?

Encryption in transit (TLS) and at rest (AES-256) are described in the SOC 2 control matrix. FIPS 140-3 module references — including the validated modules used by the compliance substrate and edge provider in HASP's chain — are documented separately at /trust/fips-modules so they can be cited in CAIQ and HECVAT questionnaires without depending on the SOC 2 report itself.