The AICPA Trust Services Criteria are public. We mirror them line by line, document our control implementations, and publish the evidence. A third-party Type 1 letter is engaged for Q4 2026 to put a CPA seal on what is already true today.
AICPA TSC 2017 defines five trust principles. Security (Common Criteria) applies to all SOC 2 engagements. The remaining four are selected based on what the service organization commits to. Hive attests to Security, Availability, Processing Integrity, and Confidentiality as primary. Privacy criteria are addressed but largely N/A given our hashes-only-by-default architecture. Source: AICPA-CIMA SOC Suite of Services.
The system is protected against unauthorized access, both physical and logical. Covers CC1–CC9 (Common Criteria). Mandatory for all SOC 2 engagements.
Our posture: 32 implemented security controls across access, cryptography, network, application, and monitoring domains. Ed25519 + ML-DSA-65 hybrid signing. TLS 1.3 only. KMS-backed key management. MFA enforced.
Attested — CC1–CC9The system is available for operation and use as committed. Covers uptime, performance monitoring, incident response, and recovery objectives. Criteria: A1.1–A1.3.
Our posture: External synthetic uptime monitoring with 2-minute alert SLA. Cloudflare global CDN with DDoS protection. Sentry error monitoring with PII scrubbing. Post-mortems within 5 business days of Sev 1.
Attested — A1.1–A1.3System processing is complete, valid, accurate, timely, and authorized. Covers transaction integrity, error handling, and audit trails. Criteria: PI1.1–PI1.5.
Our posture: Deterministic signing chain with idempotency keys. SHA3-256 and KMAC256 content addressing. Replay protection via nonce enforcement. Zod schema validation on all API inputs. Signed deletion proofs returned on authenticated DELETE requests.
Attested — PI1.1–PI1.5Information designated as confidential is protected as committed. Covers encryption at rest and in transit, access restriction, and disposal. Criteria: C1.1–C1.2.
Our posture: Hashes-only-by-default. AES-256-GCM at rest. TLS 1.3 in transit. KMS-backed key management; private key material never leaves KMS boundary. FIPS 203/204 aligned cryptographic implementation. EU data residency available on enterprise tier.
Attested — C1.1–C1.2Personal information is collected, used, retained, disclosed, and disposed of in conformity with commitments and AICPA privacy criteria. 18 sub-criteria covering notice, choice, collection, use, disclosure, retention, and individual rights.
Our posture: Largely N/A by design. Platform stores no PII by default (hashes only). When PII is processed under a customer DPA, criteria apply. Each P1–P8 sub-criterion is individually addressed in the Privacy section below.
N/A by default — DPA-gatedThe table below mirrors the AICPA TSC 2017 Common Criteria (CC1 through CC9) with 2022 points-of-focus. Each row states the AICPA criterion description, our specific control implementation, and evidence references. This is the primary exhibit of our self-attestation. Source: AICPA-CIMA SOC Suite of Services, TSC Section 100.
| CC# | Criterion Title | AICPA Description | Our Control Implementation | Evidence Reference |
|---|---|---|---|---|
| CC1.1 | Integrity & Ethical Values | The entity demonstrates a commitment to integrity and ethical values. | Security policies documented in internal operations handbook. Founder-maintained security posture published publicly at /security/. Responsible disclosure policy publicly committed. No misrepresentation of certification status; this page explicitly discloses self-attestation vs. audited opinion. | /security/ security.txt implemented |
| CC1.2 | Board Independence & Oversight | The board of directors demonstrates independence from management and exercises oversight of internal controls. | Single-founder entity; formal board not yet constituted. Founder-risk disclosure at /security/founder-risk/ documents key-person controls, treasury continuity, and legal succession. Advisory oversight documented and available under NDA. Target: advisory board with independent security oversight by Q3 2026. | /security/founder-risk/ partial — single-founder |
| CC1.3 | Management Structures & Reporting | Management establishes structures, reporting lines, and appropriate authorities and responsibilities in pursuit of objectives. | Founder serves as CISO, CTO, and CEO. Incident response runbook documents escalation paths and decision authorities. All production deployments require founder approval; no automated production pushes without explicit trigger. Role responsibilities documented in internal operations handbook. | Internal ops handbook IR runbook (NDA) implemented |
| CC1.4 | Competence & HR Policies | The entity demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives. | Founder maintains documented cryptography competency through NIST ACVP self-test suite passing on every deployment. External security consultants engaged for pen-test review (Q3 2026). SOC 2 audit firm engagement underway. Commitment not to deploy cryptographic primitives without documented validation. | ACVP results at /hive-pq.html implemented |
| CC1.5 | Accountability | The entity holds individuals accountable for their internal control responsibilities in pursuit of objectives. | Founder is sole individual with production access; full accountability rests on documented controls. Git commit history is the audit trail for code changes. Deployment logs retained 90 days. All key operations logged in KMS audit trail. Quarterly transparency report planned Q3 2026. | Git commit log KMS audit trail implemented |
| CC# | Criterion Title | AICPA Description | Our Control Implementation | Evidence Reference |
|---|---|---|---|---|
| CC2.1 | Information Quality | The entity obtains or generates and uses relevant, quality information to support internal control functioning. | Structured logging with request ID, DID, endpoint, HTTP status, and response time on all API calls. No payload bodies logged. Sentry error logging with structured context and PII field scrubbing. Cloudflare analytics for anomaly detection. Log retention minimum 90 days. | Sentry log retention Cloudflare analytics implemented |
| CC2.2 | Internal Communication | The entity internally communicates information, including objectives and responsibilities for internal control, necessary to support the functioning of internal control. | Security policies maintained in internal operations handbook. Incident runbook is version-controlled. Security posture page (/security/) serves as primary internal and external communication artifact. Changes to security posture are documented in commit history of this page, which is public. | /security/ Git commit history implemented |
| CC2.3 | External Communication | The entity communicates with external parties regarding matters affecting the functioning of internal control. | Responsible disclosure policy at /security/#disclosure with 2-business-day response commitment. [email protected] is publicly listed. Incident status published at status.thehiveryiq.com. Sub-processor list published on /security/#sub-processors. 30-day advance notice provided for material sub-processor changes. | /security/#disclosure status.thehiveryiq.com implemented |
| CC# | Criterion Title | AICPA Description | Our Control Implementation | Evidence Reference |
|---|---|---|---|---|
| CC3.1 | Risk Objectives | The entity specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives. | Security objectives documented: protect cryptographic key integrity, maintain 99.9% API availability, ensure no unauthorized data access, and prevent signing-key compromise. Risk register maintained internally; top risks include single-founder key person, cryptographic implementation error, and supply-chain compromise. | Risk register (NDA) /security/founder-risk/ implemented |
| CC3.2 | Risk Identification & Analysis | The entity identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed. | Monthly internal red-team exercises covering authentication bypass, privilege escalation, and API abuse scenarios. NIST ACVP self-test catches cryptographic implementation drift on every deployment. Third-party pen test scheduled Q3 2026. Threat model documented for Wave-Lattice signing chain. | Monthly red-team log ACVP test results implemented |
| CC3.3 | Fraud Risk Assessment | The entity considers the potential for fraud in assessing risks to the achievement of objectives. | Anomaly alerts for unusual receipt volume, authentication spikes, and DID key-rotation frequency trigger manual review. All payment flows pass through Stripe with its own PCI DSS fraud controls. On-chain settlement on Base 8453 creates immutable audit trail that prevents retroactive modification of payment records. | Anomaly alert config Stripe fraud controls implemented |
| CC3.4 | Change Risk Identification | The entity identifies and assesses changes that could significantly impact the system of internal control. | All production deployments are version-controlled and require explicit approval. Cloudflare and Render dependency versions are pinned and reviewed on update. Sub-processor changes require 30-day advance customer notice. Cryptographic algorithm changes require ACVP validation before deployment. | GitHub Actions log Sub-processor notice policy implemented |
| CC# | Criterion Title | AICPA Description | Our Control Implementation | Evidence Reference |
|---|---|---|---|---|
| CC4.1 | Ongoing Evaluations | The entity selects, develops, and performs ongoing and separate evaluations to ascertain whether the components of internal control are present and functioning. | NIST ACVP cryptographic self-test runs on every production deployment. External synthetic uptime check polls every minute; 2-minute alert SLA. Sentry error rate monitoring with threshold alerting. Cloudflare security event dashboard reviewed weekly. Monthly internal red-team exercises. | ACVP per-deploy Uptime monitor logs implemented |
| CC4.2 | Communicating Deficiencies | The entity evaluates and communicates internal control deficiencies in a timely manner to those parties responsible for taking corrective action. | Deficiencies identified via red-team or monitoring trigger documented incident report. Sev 1 incidents require post-mortem within 5 business days. All deficiencies tracked in internal security log with remediation status. This self-attestation page publicly discloses known gaps (e.g., single-founder governance, pre-Type-1 status). | Internal security log (NDA) IR post-mortems implemented |
| CC# | Criterion Title | AICPA Description | Our Control Implementation | Evidence Reference |
|---|---|---|---|---|
| CC5.1 | Control Activity Selection | The entity selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives. | Controls selected based on AICPA TSC 2017 framework and NIST SP 800-53 guidance. Priority given to cryptographic controls (signing integrity), access controls (MFA, RBAC), and monitoring controls (ACVP, synthetic uptime). Control selection documented in internal controls matrix; this page is the public version. | Controls matrix (NDA) This page implemented |
| CC5.2 | Technology Controls | The entity selects and develops general control activities over technology to support the achievement of objectives. | MFA enforced via Google Workspace SSO on all production systems. GitHub branch protection requires signed commits and PR review before merge to main. Cloudflare WAF custom ruleset blocks known API abuse patterns. IP allowlist on admin panel. Session timeouts enforced at 4h idle / 12h absolute. All infrastructure-as-code versioned in git. | GitHub branch protection config Cloudflare WAF rules implemented |
| CC5.3 | Policy Deployment | The entity deploys control activities through policies that establish what is expected and procedures that put policies into action. | Security policies documented in internal operations handbook covering: access control, cryptographic key management, incident response, data classification, vendor management, and change management. Policies reviewed quarterly. This self-attested controls inventory is the public-facing deployment of those policies. | Internal ops handbook (NDA) This page implemented |
| CC# | Criterion Title | AICPA Description | Our Control Implementation | Evidence Reference |
|---|---|---|---|---|
| CC6.1 | Logical Access Controls | The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events. | MFA required on all production systems enforced at Google Workspace identity provider. SSO with no password-only logins. Role-based access control at service and data-tier boundaries. FIDO2/WebAuthn hardware security key required for Hivemorph admin access. IP allowlist on admin panel at Cloudflare CDN layer before reaching origin. | Google Workspace SSO logs Cloudflare access logs (90d) implemented |
| CC6.2 | Prior to Issuing Credentials | Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users. | All service credentials bound to specific service identities; no shared credentials across services. Vendor credentials issued via service-account workflow with documented purpose and least-privilege scope. New DID key registrations require cryptographic proof-of-control. Customer API keys are scoped to specific DID namespaces. | Service account registry DID key registration log implemented |
| CC6.3 | Removing Access | The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on approved and documented access rules. | Cryptographic key rotation on 90-day maximum cycle; keys not rotated within the window are automatically invalidated. Session timeout enforced: 4 hours inactive, 12 hours absolute. Deprovisioning procedure documented: access removal within 1 business day of role change or termination. KMS audit log records all key operations. | KMS rotation log Session timeout config implemented |
| CC6.4 | Physical Access Controls | The entity restricts physical access to facilities and protected information assets to authorized personnel. | All infrastructure runs on Render (compute) and Cloudflare (edge/CDN); no physical data center operated by Hive. Physical security is entirely delegated to Render and Cloudflare, both of which hold third-party certifications. Physical access to founder workstation: encrypted disk (FileVault 2), screen lock enforced, no USB booting. | Render security Cloudflare trust hub implemented |
| CC6.5 | Logical Access Decommission | The entity discontinues logical access to protected information assets when appropriate. | API key revocation is immediate via the /keys/revoke endpoint. Revoked keys are added to a deny-list checked before signature operations. KMS key deletion follows NIST SP 800-57 key lifecycle management guidance. Customer data deletion: authenticated DELETE removes data and all downstream copies within 72 hours; signed deletion proof returned. | Key revocation endpoint Deletion proof mechanism implemented |
| CC6.6 | External Access Controls | The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software. | Cloudflare WAF with custom ruleset blocks known exploit patterns, credential stuffing, and prompt-injection payloads. Subresource Integrity (SRI) enforced on all third-party scripts with sha384 hash required. Input validation via Zod schema on all API endpoints. Rate limiting per-DID and per-IP at Cloudflare Workers edge. GitHub dependency scanning enabled. | Cloudflare WAF logs GitHub Dependabot alerts implemented |
| CC6.7 | Transmission Controls | The entity restricts the transmission, movement, and removal of information to authorized internal and external users and processes, and protects it during transmission. | TLS 1.3 only on all external-facing endpoints; TLS 1.2 and below rejected at Cloudflare edge. HSTS with max-age 63072000 and includeSubDomains enforced. Cloudflare-to-origin traffic encrypted end-to-end. Outbound webhooks use HTTPS with SHA-256 HMAC signature in X-Hive-Signature header. No plaintext HTTP anywhere in the stack. | TLS configuration HSTS header verification implemented |
| CC6.8 | Unauthorized Software Controls | The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software. | All production deployments require explicit founder approval and pass through GitHub Actions CI pipeline with dependency audit step. No production access from unmanaged devices. Signed commits enforced on main branch. Build artifacts are deterministic and version-pinned. SLSA 3 build attestation targeted Q3 2026. | GitHub Actions config Signed commit enforcement SLSA 3 — planned Q3 2026 |
| CC# | Criterion Title | AICPA Description | Our Control Implementation | Evidence Reference |
|---|---|---|---|---|
| CC7.1 | Configuration Baselines | The entity uses detection and monitoring procedures to identify changes to configurations or the introduction of new vulnerabilities. | All infrastructure configuration is version-controlled in git. Cloudflare configuration managed as code via Terraform (target; currently manual with documented config). Render service configuration pinned to version snapshots. Dependency versions pinned; Dependabot alerts reviewed within 5 business days. ACVP tests catch cryptographic configuration drift on every deploy. | Git config history Dependabot alert log implemented |
| CC7.2 | Anomaly Detection | The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives. | Anomaly alerts configured for: authentication spike (>3x baseline), unusual receipt volume (>5x baseline per DID), DID key-rotation frequency anomaly, and Cloudflare security event rate increase. All alerts route to founder on-call. External synthetic uptime monitor with 2-minute alert SLA. Sentry error rate thresholds with page-duty escalation. | Alert configuration docs Uptime monitor logs implemented |
| CC7.3 | Incident Identification | The entity evaluates security events to determine whether they could or have resulted in a failure to meet its objectives and, if so, takes actions to prevent or address such failures. | Six-phase incident response process: Detection, Triage, Contain, Eradicate, Recover, Post-Mortem. Severity classification documented: Sev 1 (complete outage/breach/key compromise), Sev 2 (significant degradation/potential exposure), Sev 3 (minor, no data risk). Customer notification SLAs: Sev 1 within 1 hour, Sev 2 within 4 hours. | /security/#incident-response implemented |
| CC7.4 | Incident Response | The entity responds to identified security incidents by executing a defined incident response program. | Incident runbook documents specific playbooks for: cryptographic key compromise, data breach, DDoS attack, API availability outage, and unauthorized access. Runbook is version-controlled. Post-mortem template published internally. Status page updated within 30 minutes of Sev 1 declaration. Customer notification templates pre-approved for rapid dispatch. | IR runbook (NDA) status page implemented |
| CC7.5 | Post-Incident Recovery | The entity identifies, develops, and implements activities to recover from identified security incidents. | Post-mortem published within 5 business days of any Sev 1 incident (customer-facing summary). Root cause, timeline, and corrective actions documented. Corrective actions tracked to closure. Recovery test: Render service restoration from snapshot tested semi-annually. Cryptographic key recovery: backup key material in offline cold storage per documented procedure. | Post-mortem template Recovery test log implemented |
| CC# | Criterion Title | AICPA Description | Our Control Implementation | Evidence Reference |
|---|---|---|---|---|
| CC8.1 | Change Management Process | The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives. | All code changes go through GitHub pull request with documented purpose, test results, and founder approval before merge to main. ACVP self-test must pass before production deployment of cryptographic changes. Cloudflare configuration changes are logged. Rollback procedure documented; deployments are atomic on Render. Breaking API changes require 30-day deprecation notice to customers. Infrastructure changes staged in preview environment before production. | GitHub PR history ACVP test logs Render deploy log implemented |
| CC# | Criterion Title | AICPA Description | Our Control Implementation | Evidence Reference |
|---|---|---|---|---|
| CC9.1 | Vendor and Business Partner Risk | The entity identifies, selects, and develops risk mitigation activities for risks arising from potential business disruptions and the use of vendors and business partners. | Sub-processors listed publicly at /security/#sub-processors. Each processor (Render, Cloudflare, Stripe, Mercury, GitHub, AWS S3 via Render) contractually bound to data protection standards consistent with Hive DPA. Sub-processor SOC 2 reports reviewed annually. 30-day advance notice to customers for material sub-processor changes. Vendor risk documented in internal risk register. | /security/#sub-processors Vendor review log (NDA) implemented |
| CC9.2 | Business Disruption Risk | The entity assesses and manages risks associated with engaging a vendor or business partner. | Cloudflare provides DDoS protection and geographic redundancy that reduces single-region outage risk. Render runs in US East with documented failover posture. Business continuity plan documented: treasury continuity, code escrow, and legal succession detailed in /security/founder-risk/. Recovery time objective (RTO) for API tier: 4 hours. Recovery point objective (RPO): 1 hour (daily Render snapshots). | /security/founder-risk/ BCP document (NDA) implemented |
Availability criteria apply because Hive commits to SLA-based uptime in customer agreements. The three availability criteria cover capacity, monitoring, and recovery testing.
| CC# | Criterion Title | AICPA Description | Our Control Implementation | Evidence Reference |
|---|---|---|---|---|
| A1.1 | Capacity Planning | The entity maintains, monitors, and evaluates current processing capacity and use of system components to manage capacity demand and to enable the implementation of additional capacity. | Render auto-scales API workers based on CPU and memory thresholds. Cloudflare Workers edge compute scales globally with demand. Capacity baseline reviewed monthly. Cloudflare analytics provide p50/p99 latency tracking. Alert threshold set at 70% of maximum observed capacity. Load test performed on major releases against staging environment. | Render scaling config Cloudflare analytics implemented |
| A1.2 | Availability Monitoring | The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data backup processes, and recovery infrastructure. | External synthetic uptime monitor checks API health endpoint every 60 seconds from multiple geographic locations. Alert fires within 2 minutes of detection. Sentry real-time error rate monitoring with threshold alerting. Status page (status.thehiveryiq.com) updated automatically on incident detection. Daily automated snapshots via Render backup service. 90-day log retention minimum. | Uptime monitor config status.thehiveryiq.com implemented |
| A1.3 | Recovery Testing | The entity tests recovery plan procedures supporting system availability to address and recover from processing interruptions. | Render service restoration from snapshot tested semi-annually. Recovery procedure documented with RTO target of 4 hours for full API tier restoration. Cryptographic key recovery tested annually: restore from offline cold-storage backup and re-verify signing chain. Test results documented with pass/fail status and corrective actions where applicable. Next scheduled test: Q3 2026. | Recovery test log RTO/RPO documentation next test Q3 2026 |
Processing integrity is central to Hive's value proposition. Every receipt is cryptographically bound to its content. The five PI criteria address completeness, accuracy, validity, timeliness, and authorized processing.
| CC# | Criterion Title | AICPA Description | Our Control Implementation | Evidence Reference |
|---|---|---|---|---|
| PI1.1 | Completeness | The entity obtains or generates, uses, and communicates relevant, quality information to support the functioning of internal control. | Each signing operation produces a deterministic receipt with: content hash (SHA3-256), Ed25519 signature, ML-DSA-65 signature, KMAC256 message authentication code, timestamp, DID reference, and idempotency key. All fields required; incomplete receipts are rejected by schema validation before signing. Receipt schema versioned and published. | Receipt schema docs Schema validation logs implemented |
| PI1.2 | Accuracy | System processing is complete, valid, accurate, timely, and authorized. | SHA3-256 content hashing ensures any bit-level change in the underlying document produces a different digest. Ed25519 + ML-DSA-65 dual signatures provide independent accuracy verification: both signatures must verify against the same content hash. KMAC256 provides additional keyed authentication. Idempotency keys prevent double-signing the same content with different outputs. | Signing chain docs ACVP test results implemented |
| PI1.3 | Validity & Authorization | The system inputs are authorized before processing begins and the results of processing are valid and accurate. | All signing requests require authenticated API key bound to a registered DID. Zod schema validation on all inputs before signing is initiated. Rate limiting per-DID prevents flooding. Requests with malformed or unauthorized DID references are rejected with HTTP 403 before reaching signing logic. KMS signing key can only be invoked by authenticated service identity. | DID authentication logs KMS IAM policy implemented |
| PI1.4 | Timeliness | System processing is complete and accurate within the specified timeframe. | Signing API target p99 latency is 200ms. Cloudflare Workers edge verifier operates at sub-50ms p99. Receipt timestamp is included in the signed payload; timestamp is within 5 seconds of signing request receipt. Stale-timestamp detection: receipts presented for verification more than 24 hours after signing timestamp are flagged with a staleness warning. All timestamps use ISO 8601 UTC. | Latency metrics /verifier/ implemented |
| PI1.5 | Replay & Error Protection | The entity protects information involved in processing activities from accidental disclosure to inappropriate parties. | Replay protection via nonce enforcement: each idempotency key is single-use per DID namespace; re-submitted idempotency key returns the original receipt, not a new signing. Replay attempts against expired nonces are rejected with HTTP 409. Error handling returns structured error codes; no stack traces or internal state exposed in API error responses. All errors logged with request ID for internal review. | Nonce enforcement log Error response schema implemented |
Hive's hashes-only-by-default architecture significantly reduces the confidentiality exposure surface. Customer content is not stored; only cryptographic digests are retained unless the applicable DPA explicitly enables payload persistence.
| CC# | Criterion Title | AICPA Description | Our Control Implementation | Evidence Reference |
|---|---|---|---|---|
| C1.1 | Identification of Confidential Information | The entity identifies and maintains confidential information to meet the entity's objectives related to privacy. | Hive classifies data into three tiers: (1) Signing keys — highest sensitivity, KMS-only, never exported; (2) Receipt metadata (hashes, timestamps, DID references) — confidential, 90-day retention, encrypted at rest with AES-256-GCM; (3) Operational logs — internal, PII-scrubbed, 90-day retention. No customer document content stored by default. Data classification policy documented in internal handbook. | Data classification policy (NDA) KMS key policy implemented |
| C1.2 | Disposal of Confidential Information | The entity disposes of confidential information to meet the entity's objectives related to confidentiality. | Customer-controlled deletion endpoint: authenticated DELETE request removes all receipt metadata and downstream copies within 72 hours; signed deletion proof is returned to the customer. Cryptographic deletion proof uses Ed25519 signature over a deletion record containing: deleted record hash, deletion timestamp, and requesting DID. Signing key disposal follows NIST SP 800-57 key destruction procedure. Retention boundary enforced automatically at 90 days; post-retention data purged without customer action required. | Deletion endpoint docs Key destruction procedure implemented |
Privacy criteria apply to personal information. Hive's platform is architecturally designed to minimize PII exposure: we store hashes by default, not underlying content. Most privacy criteria are therefore not applicable in the default deployment. Each is individually addressed below. Where criteria apply under customer DPA, our posture is noted.
| CC# | Criterion | AICPA Description | Our Posture | Status |
|---|---|---|---|---|
| P1.0 | Privacy Notice | The entity provides notice about its privacy practices to data subjects. | Privacy policy published at /privacy.html. DPA template available on request. Sub-processor list published at /security/#sub-processors. In default deployment, no PII is collected, so notice requirements are minimal. | /privacy.html implemented |
| P2.1 | Choice & Consent | The entity communicates choices available regarding the collection, use, retention, disclosure, and disposal of personal information. | N/A — Default deployment collects no PII. Applies only under DPA where customer enables payload persistence; in that case, DPA governs consent mechanisms. | N/A by default |
| P3.1 | Collection | Personal information is collected consistent with the entity's objectives related to privacy. | N/A — Default deployment stores only SHA3-256 hashes of content, not content itself. No PII is collected, stored, or processed in the default configuration. PII in logs is scrubbed at ingestion by Sentry Relay. | N/A by default |
| P3.2 | Explicit Consent for Sensitive Data | For sensitive personal information, the entity obtains explicit consent. | N/A — No sensitive personal information categories are processed in the default deployment. Any expansion of data collection requires DPA amendment with explicit consent provisions. | N/A by default |
| P4.1 | Use, Retention & Disposal | Personal information is limited to the purposes identified in the entity's privacy notice and is retained only as long as necessary. | Receipt metadata (hashes, timestamps, DID references) retained 90 days maximum; configurable downward on request; automatic purge at boundary. Customer DELETE endpoint removes data within 72 hours. No personal information retained beyond these limits. | implemented |
| P4.2 | Retained for Legal Proceedings | The entity retains personal information identified as relevant in a legal proceeding for the period of that proceeding. | N/A — Not yet triggered. Documented procedure: legal hold process initiated on receipt of valid legal process; data preservation implemented before scheduled deletion. Procedure documented in internal legal response policy. | documented, not triggered |
| P4.3 | Disposal Procedures | The entity securely disposes of personal information once it is no longer needed. | Automated deletion at 90-day retention boundary. Customer DELETE endpoint returns signed cryptographic deletion proof. KMS key destruction per NIST SP 800-57. Receipt data purged from all downstream copies (log archives, backups) within 72 hours of deletion request. | implemented |
| P5.1 | Access | The entity provides data subjects with access to their personal information for review or update. | N/A — Platform stores no PII in default configuration. For DPA-enabled deployments, data subject access requests are fulfilled within 30 days via [email protected] per GDPR Article 15 requirements. | N/A by default |
| P5.2 | Correction | The entity corrects, amends, or appends personal information based on objections from data subjects. | N/A — Cryptographic receipts are immutable by design (hash-locked content cannot be amended without invalidating the signature). Correction requests for DPA-enabled deployments handled on a case-by-case basis; see DPA for process. Note that receipt metadata correction would require re-signing with new content. | N/A by default |
| P6.1 | Disclosure to Third Parties | Personal information is disclosed to third parties only for the purposes identified in the privacy notice. | Sub-processors listed at /security/#sub-processors. No personal information disclosed to parties outside this list. Sub-processors contractually restricted from using data for any purpose other than providing the contracted service. No data sold to third parties. Customer notified 30 days in advance of new sub-processor additions. | /security/#sub-processors implemented |
| P6.2 | Authorized Third-Party Disclosure | The entity discloses personal information to third parties with the individual's consent or as otherwise consistent with the privacy notice. | N/A — No personal information disclosed beyond listed sub-processors. No discretionary third-party sharing occurs in the platform's current operational mode. | N/A |
| P6.3 | Government Disclosure | The entity discloses personal information to government authorities only when required by law. | Legal process policy documented: government requests reviewed by legal counsel before compliance; data minimization applied; customer notification provided where legally permitted. Warrant canary concept documented in transparency report (first issue Q3 2026). | documented; canary Q3 2026 |
| P6.4 | Third-Party Notification | The entity notifies third parties when disclosures are prohibited or not provided. | N/A — No discretionary third-party sharing. Legal compulsion disclosures handled per P6.3 legal process policy. | N/A |
| P6.5 | Onward Transfer | The entity provides notice to data subjects of potential onward transfers of personal information. | N/A — Sub-processors listed publicly. No onward transfers beyond listed sub-processors occur. Privacy policy discloses this. DPA restricts sub-processor onward transfers. | N/A by default |
| P6.6 | Privacy Notice to Third Parties | The entity includes privacy protections in its agreements with its vendors and third-party processors. | Sub-processor DPAs executed with Render, Cloudflare, Stripe, Mercury, GitHub, and AWS (via Render). DPA terms restrict data processing to contracted purposes and require sub-processors to maintain appropriate security controls. | implemented |
| P7.1 | Quality of Personal Information | The entity collects and maintains accurate, up-to-date, complete, and relevant personal information for the purposes identified in the privacy notice. | N/A — Default deployment stores no PII. Customer account information (email address for billing) is maintained via Stripe; accuracy is customer-controlled. No additional PII collected or maintained by Hive platform. | N/A by default |
| P8.1 | Monitoring & Enforcement | The entity monitors compliance with its privacy policies and procedures and has procedures to address privacy-related complaints and disputes. | Privacy complaints addressed via [email protected] within 5 business days. GDPR data subject requests fulfilled within 30 days. Privacy policy reviewed quarterly alongside security policy. Quarterly transparency report (first issue Q3 2026) will include a section on privacy monitoring outcomes. No privacy complaints received to date. | implemented |
SOC 2 is a floor. The following controls go beyond what the AICPA TSC 2017 requires or even contemplates. We publish them because they are real, verifiable, and meaningful to sophisticated buyers evaluating cryptographic infrastructure. Each entry covers: what it is, why SOC 2 misses it, how we implement it, and a verification command or link.
SOC 2 requires that encryption be used but does not require disclosure of which algorithms. We publish every algorithm in production.
SOC 2 has no criterion for post-quantum cryptography. We ship hybrid signatures today, combining Ed25519 (classical) with ML-DSA-65 (post-quantum) in parallel during the transition period.
curl https://<your-worker>.workers.dev/verify?id=<receipt-id> — response includes both ed25519_sig and mldsa65_sig fields. Full verifier deployment: /verifier/SOC 2 does not measure where the randomness used to generate signing keys comes from. We document the entropy source of every signing key to a provable substrate.
SOC 2 CC8.1 requires change management but does not require build attestations proving that released artifacts were built from the claimed source code without tampering.
SOC 2 has no concept of a customer-deployable independent verifier. We publish an open-source Cloudflare Workers verifier so customers can verify Hive signatures completely off our infrastructure.
GET /verify?id=<receipt-id>SOC 2 CC7.4 requires incident response procedures but only requires internal post-mortems. We commit to publishing customer-facing post-mortems within 5 business days of any Sev 1 incident.
SOC 2 does not measure settlement integrity. Hive payment receipts anchor cryptographic commitments to Base blockchain (chain ID 8453), creating an immutable audit trail that prevents retroactive modification of payment records.
0x15184Bf50B3d3F52b60434f8942b7D52F2eB436ESOC 2 C1.2 covers disposal of confidential information but does not require cryptographic proof of deletion be returned to the customer. We return a signed deletion proof on every authenticated DELETE request.
DELETE /v1/receipts/:id — Returns signed deletion proof JWT — verify proof: GET /verify?type=deletion&proof=<jwt>The table below indexes evidence for each control. Public items are linked. Items marked NDA require an executed mutual NDA; request via [email protected]. Last reviewed dates reflect the most recent internal review cycle. Additional evidence available on request for enterprise procurement.
| Control ID | Evidence Type | Location / Reference | Access | Last Reviewed |
|---|---|---|---|---|
| CC1.1 | Responsible disclosure policy | /security/#disclosure | Public | Q2 2026 |
| CC1.2 | Founder-risk disclosure | /security/founder-risk/ | Public | Q2 2026 |
| CC1.4 | ACVP self-test results | /hive-pq.html | Public | Per deploy |
| CC1.5 | Git commit history (audit trail) | GitHub — main branch history | Public | Continuous |
| CC2.3 | Sub-processor list | /security/#sub-processors | Public | Q2 2026 |
| CC3.1 | Internal risk register | Internal security log | NDA | Q2 2026 |
| CC3.2 | Monthly red-team exercise log | Internal security log | NDA | Monthly |
| CC4.1 | Uptime monitor configuration + logs | status.thehiveryiq.com | Public | Continuous |
| CC5.2 | GitHub branch protection config | GitHub repo settings (requires access) | NDA | Q2 2026 |
| CC5.3 | Internal operations handbook | Internal document | NDA | Q2 2026 |
| CC6.1 | Access control log retention (90d) | Cloudflare access logs — /security/#controls | NDA | Q2 2026 |
| CC6.1 | MFA enforcement configuration | Google Workspace admin console | NDA | Q2 2026 |
| CC6.3 | KMS key rotation audit log | KMS audit trail (90d retention) | NDA | 90d cycle |
| CC6.4 | Render physical security documentation | render.com/security | Public | Q2 2026 |
| CC6.4 | Cloudflare physical security documentation | cloudflare.com/trust-hub | Public | Q2 2026 |
| CC6.6 | Cloudflare WAF rules configuration | Cloudflare dashboard (screenshot on request) | NDA | Q2 2026 |
| CC6.7 | TLS 1.3 configuration + HSTS header | Verifiable: curl -I https://thehiveryiq.com |
Public | Continuous |
| CC7.2 | Anomaly alert configuration | Internal alert rules document | NDA | Q2 2026 |
| CC7.3 | Incident response runbook | IR runbook — summary at /security/#incident-response | NDA (full) | Q2 2026 |
| CC7.5 | Recovery test procedure + results | Internal recovery test log | NDA | Semi-annual |
| CC8.1 | GitHub Actions CI pipeline config | GitHub repo (requires access grant) | NDA | Q2 2026 |
| CC9.1 | Vendor DPA execution records | Internal vendor management file | NDA | Q2 2026 |
| A1.2 | Uptime monitor SLA + alert log | status.thehiveryiq.com | Public | Continuous |
| PI1.1 | Receipt schema documentation | /developers.html | Public | Q2 2026 |
| PI1.2 | ACVP cryptographic validation results | /hive-pq.html | Public | Per deploy |
| C1.1 | Data classification policy | Internal security policy document | NDA | Q2 2026 |
| C1.2 | Signed deletion proof mechanism | /developers.html — DELETE endpoint docs | Public | Q2 2026 |
| Beyond/B | ML-DSA-65 signature on live receipt | /verifier/ — deploy and inspect | Public | Continuous |
| Beyond/E | Open-source edge verifier code | /verifier/ | Public | Q2 2026 |
| Beyond/G | Base 8453 on-chain settlement hash | basescan.org — search by tx hash in receipt | Public | Per receipt |
To request NDA-gated evidence: [email protected] with subject line "Controls evidence request". We respond within 2 business days. NDA execution to evidence delivery typically within 5 business days.
These are genuine targets with committed next actions. We will not represent a certification as complete until the independent body issues the credential. If any milestone slips, we will publish a transparent update on this page.
This page. AICPA TSC 2017 (2022 PoF) mirrored line by line. 33 common criteria documented with control implementations and evidence references. Beyond-SOC-2 addendum published.
Live — This pageEngagement letter signed with audit firm (target: a top-25 firm specializing in SOC 2). Engagement letter available under NDA via [email protected]. First quarterly transparency report issued. SLSA 3 build attestations deployed. Third-party pen test completed.
PlannedType 1 audit window opens. Auditor reviews design and implementation of controls at a point in time. Report issued Q1 2027. Type 1 report replaces this self-attestation as the primary posture document; this page remains as a supplemental exhibit.
PlannedIndependent CPA opinion on control design. Report available to enterprise customers under NDA. This self-attested inventory transitions to a supplemental exhibit to the formal report.
Future12-month observation period covers operating effectiveness of controls over time. Type 2 report targeted Q3 2027. This is the gold standard for enterprise procurement and regulated-sector deployments.
FutureISO 27001 ISMS certification in parallel with SOC 2 Type 2 observation period. Provides international recognition and meets procurement requirements for customers with European or APAC headquarters.
FutureThe SOC 2 Type 1 audit engagement letter will be available under a mutual NDA in Q3 2026. To receive a copy when issued, contact [email protected] with subject line "SOC 2 engagement letter under NDA". If the Q4 2026 audit window slips, we will publish a transparent update on this page with the revised timeline and the reason for the slip.
This self-attestation is not a substitute for a Type 1 report, but it is a meaningful starting point for procurement and security review. Here are four practical uses.
Use this page as an interim posture statement until the Type 1 letter is available in Q1 2027. The controls documented here are implemented and operational today. Reference this URL in your vendor security documentation as "self-attested SOC 2 posture published [date]" with a link to this page.
Run your own gap analysis against your internal SOC 2 review requirements. The CC1–CC9 table above maps directly to the AICPA TSC 2017 Common Criteria. Download the AICPA TSC document and compare our stated implementations against your control requirements line by line.
Request specific evidence items via [email protected]. Reference the control ID from the evidence table above (e.g., "CC6.1 access control log evidence"). We respond within 2 business days. NDA-gated evidence delivered within 5 business days of NDA execution.
Reference this page in a vendor security questionnaire response. We also directly fill out CAIQ, SIG Lite, SIG Core, or custom questionnaires within 5 business days of receiving your template via [email protected].
No. A Type 1 report carries an AICPA-licensed CPA opinion on the design of controls as of a specific date. Self-attestation is made by the entity itself with no independent verification. The difference matters: a Type 1 report provides third-party assurance that an independent auditor has reviewed the controls and concurs with the design assessment. This self-attestation provides transparency about what we have implemented, without that independent CPA opinion. It is meaningfully better than "we have no posture statement," but it does not substitute for a formal audit.
Vanta is compliance automation software, not the audit itself. Vanta automates evidence collection and continuous controls monitoring against the AICPA Trust Services Criteria, which are the same public criteria mirrored on this page. Using Vanta accelerates preparation for a third-party SOC 2 audit but does not replace it — Vanta-monitored companies still require an independent CPA firm to issue the audit opinion. We chose to publish our controls inventory now in a human-readable format and pursue the third-party Type 1 engagement in Q4 2026. We may add Vanta-style continuous monitoring tooling as a pre-audit readiness measure; the decision does not affect the audit timeline.
Probably not on its own, and we are not claiming it does. Most formal security review processes require a Type 1 or Type 2 report from a CPA firm. This page is a starting point: it lets your security team evaluate our controls before the formal report is available, and it provides a structured basis for a questionnaire response. We will fill out your organization's specific questionnaire (CAIQ, SIG, or custom format) and provide evidence under NDA. If your process requires a formal report, we target having the Type 1 report available Q1 2027.
The engagement letter will be available under NDA in Q3 2026 before the audit window opens. If the Q4 2026 audit window slips, we will publish a transparent update on this page with the revised timeline and the specific reason for the slip. Transparency about delays is a commitment, not an aspiration. The engagement letter creates a contractual relationship with the audit firm that is a meaningful milestone independent of the final report issuance.
Two mechanisms: first, the commit history of this page is public in the site's GitHub repository — any change to a claimed control is documented in the commit log with a timestamp and message. Second, we commit to a quarterly transparency report beginning Q3 2026 that reviews this inventory against the actual implementation state and flags any items that have moved from "implemented" to "planned" or vice versa. If a control degrades, we document it.
Yes. We welcome direct dialogue with your auditors as part of your vendor assessment process. Contact [email protected] to arrange a call. We will provide an honest account of our controls, current limitations, and the audit timeline. We do not script these conversations — your auditor can ask what they need to ask.
Request controls evidence, the engagement letter, or a direct conversation with the security team. We respond within 2 business days.