Trust & Compliance · Self-Attested · AICPA TSC 2017

SOC 2, self-attested.

A self-maintained review inventory organized by Trust Services Criteria topics. It separates source observations from operational evidence still needed; it is not an independent SOC 2 report.

33 common-criteria topics · Availability, processing integrity, confidentiality and privacy review · Product-specific evidence
Self-attestation notice: not a SOC 2 report

No independent SOC 2 report or executed engagement letter was supplied in this review. Earlier target dates are withdrawn pending approval. review evidence.

AICPA Trust Services Criteria 2017

The 5 trust principles.

The categories organize this review; they do not establish the scope of an executed SOC 2 engagement. Personal data occurs in submitted content and telemetry, so privacy is not treated as largely inapplicable.

Security
Security

The system is protected against unauthorized access, both physical and logical. Covers CC1 to CC9 (Common Criteria). Mandatory for all SOC 2 engagements.

Review focus: service-specific signing, administrator access and software key custody.

Evidence review
Availability
Availability

The system is available for operation and use as committed. Covers uptime, performance monitoring, incident response, and recovery objectives. Criteria: A1.1 to A1.3.

Review focus: measured monitoring, recovery objectives and restoration records.

Evidence review
Processing Integrity
Processing Integrity

System processing is complete, valid, accurate, timely, and authorized. Covers transaction integrity, error handling, and audit trails. Criteria: PI1.1 to PI1.5.

Review focus: schema validation, authorization, durable capture and replay tests by endpoint.

Evidence review
Confidentiality
Confidentiality

Information designated as confidential is protected as committed. Covers encryption at rest and in transit, access restriction, and disposal. Criteria: C1.1 to C1.2.

Review focus: readable processing, stored metadata, transport and class-specific disposal.

Evidence review
Privacy
Privacy

Personal 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.

Review focus: actual data paths, legal roles, processor terms and approved retention.

Evidence review
Common Criteria CC1 to CC9

All 33 common criteria, mirrored.

These summaries organize 33 common-criteria topics. They are navigation aids, not the standard's exact text or an independent control opinion. Each row identifies evidence needed for acceptance.

CC1

Control Environment: 5 criteria

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. Approve conduct and responsible-disclosure policies with accountable owners. Evidence open
CC1.2 Board Independence & Oversight The board of directors demonstrates independence from management and exercises oversight of internal controls. Independent oversight and founder-independent recovery remain unverified. Evidence open
CC1.3 Management Structures & Reporting Management establishes structures, reporting lines, and appropriate authorities and responsibilities in pursuit of objectives. Name security owners, reporting relationships and accepted delegates. Evidence open
CC1.4 Competence & HR Policies The entity demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives. Collect competence, training and authorized-personnel records. Evidence open
CC1.5 Accountability The entity holds individuals accountable for their internal control responsibilities in pursuit of objectives. Record control ownership, exceptions and follow-up decisions. Evidence open
CC2

Communication and Information: 3 criteria

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. Validate the completeness and accuracy of control-evidence records. Evidence open
CC2.2 Internal Communication The entity internally communicates information, including objectives and responsibilities for internal control, necessary to support the functioning of internal control. Test internal escalation and incident communication. Evidence open
CC2.3 External Communication The entity communicates with external parties regarding matters affecting the functioning of internal control. Publish service-specific processing and supplier boundaries; contracts remain to be verified. Evidence open
CC3

Risk Assessment: 4 criteria

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. Approve risk objectives and tolerances for each service. Evidence open
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. Maintain risk assessments tied to source, configuration and customer scope. Evidence open
CC3.3 Fraud Risk Assessment The entity considers the potential for fraud in assessing risks to the achievement of objectives. Assess key misuse, payment fraud and privileged-access abuse. Evidence open
CC3.4 Change Risk Identification The entity identifies and assesses changes that could significantly impact the system of internal control. Document change risks and acceptance decisions. Evidence open
CC4

Monitoring Activities: 2 criteria

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. Retain monitoring configuration and observed test delivery. Evidence open
CC4.2 Communicating Deficiencies The entity evaluates and communicates internal control deficiencies in a timely manner to those parties responsible for taking corrective action. Record deficiencies, accountable owners and remediation decisions. Evidence open
CC5

Control Activities: 3 criteria

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. Map selected controls to identified risks and operating scope. Evidence open
CC5.2 Technology Controls The entity selects and develops general control activities over technology to support the achievement of objectives. Verify authentication, deployment and signing controls at the actual service boundary. Evidence open
CC5.3 Policy Deployment The entity deploys control activities through policies that establish what is expected and procedures that put policies into action. Approve operating policies and evidence their use. Evidence open
CC6

Logical and Physical Access Controls: 8 criteria

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. Typed minting checks authorization; cross-endpoint access coverage requires tests. Evidence open
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. Verify identity before credential issuance and record approvals. Evidence open
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. Test user and service-account deprovisioning. Evidence open
CC6.4 Physical Access Controls The entity restricts physical access to facilities and protected information assets to authorized personnel. Document physical responsibility boundaries and relevant provider evidence. Evidence open
CC6.5 Logical Access Decommission The entity discontinues logical access to protected information assets when appropriate. Track revoked access, retained data and asset recovery. Evidence open
CC6.6 External Access Controls The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software. Test edge rules and direct-origin authentication coverage. Evidence open
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. HTTPS is not a no-plaintext guarantee; inspect origin and outbound paths. Evidence open
CC6.8 Unauthorized Software Controls The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software. Review deployed package controls and code-release permissions. Evidence open
CC7

System Operations: 5 criteria

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. Reconcile runtime configuration with approved baselines. Evidence open
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. Test anomaly thresholds, alert routing and observed delivery. Evidence open
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. Define event classification and preserve triage records. Evidence open
CC7.4 Incident Response The entity responds to identified security incidents by executing a defined incident response program. Approve the incident outline and contract-specific notification rules. Evidence open
CC7.5 Post-Incident Recovery The entity identifies, develops, and implements activities to recover from identified security incidents. Run recovery exercises and record corrective actions. Evidence open
CC8

Change Management: 1 criterion

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. Match approved code changes to exact deployed revisions. Evidence open
CC9

Risk Mitigation: 2 criteria

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. Verify processors, agreements, regions and supplier risks. Evidence open
CC9.2 Business Disruption Risk The entity assesses and manages risks associated with engaging a vendor or business partner. Test founder-unavailability recovery; escrow and insurance evidence remain open. Evidence open
Availability Principle: A1

A1.1 to A1.3: Availability criteria.

Availability commitments must be verified against applicable agreements and operational measurements. No monitoring or recovery target is established by this table.

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. Measure saturation, scaling behavior and accepted capacity limits. Evidence open
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. Verify monitoring coverage, recovery objectives and alert delivery. Evidence open
A1.3 Recovery Testing The entity tests recovery plan procedures supporting system availability to address and recover from processing interruptions. No backup restoration or founder-independent recovery test was supplied. Evidence open
Processing Integrity Principle: PI1

PI1.1 to PI1.5: Processing integrity criteria.

A valid signature authenticates signed bytes under a trusted key. Completeness, accuracy, timeliness and authorized effects require separate evidence.

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. Source contains bounded exports and best-effort persistence; complete coverage is not established. Evidence open
PI1.2 Accuracy System processing is complete, valid, accurate, timely, and authorized. Signature validity does not establish the truth of underlying submitted data. Evidence open
PI1.3 Validity & Authorization The system inputs are authorized before processing begins and the results of processing are valid and accurate. Test authorization and schema validation for each endpoint. Evidence open
PI1.4 Timeliness System processing is complete and accurate within the specified timeframe. Verify timeouts, timestamp accuracy and service-specific processing targets. Evidence open
PI1.5 Replay & Error Protection The entity protects information involved in processing activities from accidental disclosure to inappropriate parties. Test replay boundaries, durable-write failures and error disclosure. Evidence open
Confidentiality Principle: C1

C1.1 to C1.2: Confidentiality criteria.

Client-side hashing can limit payload exposure. Carnac processes readable text and receipt/telemetry fields may contain personal or confidential information.

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. Classify readable inputs, receipt fields, identifiers and operational logs. Evidence open
C1.2 Disposal of Confidential Information The entity disposes of confidential information to meet the entity's objectives related to confidentiality. Approve retention and deletion by class; a signature authenticates a statement, not all-copy erasure. Evidence open
Privacy Principle: P1 to P8

P1.0 to P8.1: Privacy criteria, all 18 sub-criteria.

Personal information can occur in submissions, account records and telemetry. Applicability and operating controls require a service-specific legal and technical review.

CC# Criterion AICPA Description Our Posture Status
P1.0 Privacy Notice The entity provides notice about its privacy practices to data subjects. The privacy notice now describes Carnac text processing, telemetry and open schedules. Evidence open
P2.1 Choice & Consent The entity communicates choices available regarding the collection, use, retention, disclosure, and disposal of personal information. Assess actual collection, legal basis and any required consent controls. Evidence open
P3.1 Collection Personal information is collected consistent with the entity's objectives related to privacy. Verify field minimization against each request, log and processor path. Evidence open
P3.2 Explicit Consent for Sensitive Data For sensitive personal information, the entity obtains explicit consent. Identify sensitive inputs and determine appropriate restrictions and legal basis. Evidence open
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. No approved start events, durations, holds or verified deletion schedule were supplied. Evidence open
P4.2 Retained for Legal Proceedings The entity retains personal information identified as relevant in a legal proceeding for the period of that proceeding. Define hold authority, scope, review and release before overriding deletion. Evidence open
P4.3 Disposal Procedures The entity securely disposes of personal information once it is no longer needed. Test deletion across authoritative stores, replicas and known downstream copies. Evidence open
P5.1 Access The entity provides data subjects with access to their personal information for review or update. Authenticate rights requests and define data-discovery scope. Evidence open
P5.2 Correction The entity corrects, amends, or appends personal information based on objections from data subjects. Specify correction handling without silently rewriting signed evidence. Evidence open
P6.1 Disclosure to Third Parties Personal information is disclosed to third parties only for the purposes identified in the privacy notice. Confirm the recipient inventory and authorized disclosure purposes. Evidence open
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. Verify recipient agreements, permissions and processing instructions. Evidence open
P6.3 Government Disclosure The entity discloses personal information to government authorities only when required by law. Approve lawful-request assessment and escalation procedures. Evidence open
P6.4 Third-Party Notification The entity notifies third parties when disclosures are prohibited or not provided. Verify applicable processor/customer notification requirements. Evidence open
P6.5 Onward Transfer The entity provides notice to data subjects of potential onward transfers of personal information. Identify onward recipients and applicable transfer mechanisms. Evidence open
P6.6 Privacy Notice to Third Parties The entity includes privacy protections in its agreements with its vendors and third-party processors. Match third-party notices and agreements to actual data classes. Evidence open
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. Test correction and quality controls for account and submitted metadata. Evidence open
P8.1 Monitoring & Enforcement The entity monitors compliance with its privacy policies and procedures and has procedures to address privacy-related complaints and disputes. Collect privacy reviews, complaint handling and remediation evidence. Evidence open
Beyond SOC 2

Product-specific evidence boundaries.

These technical topics supplement the inventory. They do not imply that a SOC 2 report guarantees, excludes or validates a particular cryptographic implementation.

Beyond SOC 2 / A
Cryptographic Algorithm Transparency

Algorithm disclosure must identify the exact service, revision and signing path.

Scope
A standards name does not establish a validated module or protected key boundary.
Observed boundary
Inspected keys enter application memory from environment values, local files or generated key material.
Review evidence
review evidence records the software custody matrix and remaining configuration checks.
Reviewed algorithm and custody boundaries
Ed25519: typed API, receipt/Carnac and countersigner signing
ML-DSA-65: dedicated signer application-memory keypair
Key custody: software process, not a verified KMS
Hybrid formats: not universal across reviewed services
ML-KEM: key encapsulation, not a signature
Self-tests: implementation checks, not a certificate
CAVP: algorithm implementation validation
CMVP: cryptographic module validation
Evidence open
Beyond SOC 2 / B
Post-Quantum Readiness (FIPS 203/204)

The reviewed services do not all use hybrid signatures.

Scope
Ed25519 and ML-DSA-65 have separate service and verifier boundaries.
Observed boundary
Typed API, receipt/Carnac and countersigner paths use Ed25519. The dedicated signer implements ML-DSA-65 in software.
Review evidence
signing boundaries. A self-test is not a CAVP or CMVP certificate.
Acceptance scope
signing boundaries. A self-test is not a CAVP or CMVP certificate.
Evidence open
Beyond SOC 2 / C
Substrate-Level Entropy Provenance

No hardware entropy provenance or validated entropy-source evidence was supplied.

Scope
A software assertion about entropy is not a hardware attestation.
Observed boundary
Key generation and entropy sources require per-path review, especially optional QPuF modes.
Review evidence
Do not infer NIST validation from metadata, algorithm labels or a self-test page.
Acceptance scope
Do not infer NIST validation from metadata, algorithm labels or a self-test page.
Evidence open
Beyond SOC 2 / D
Verifiable Build Provenance (SLSA)

Deployed source revisions were reviewed; that is not a SLSA level determination.

Scope
Source lineage is distinct from reproducible build and runtime integrity evidence.
Observed boundary
No applicable build-level assessment or complete attestation chain was supplied.
Review evidence
Build provenance scope and acceptance tests remain to be established; earlier target dates are withdrawn.
Acceptance scope
Build provenance scope and acceptance tests remain to be established; earlier target dates are withdrawn.
Evidence open
Beyond SOC 2 / E
Open-Source Customer-Deployable Verifier

Customer-held verification depends on the receipt format, verifier code and trusted issuer key.

Scope
Independent operation must be demonstrated without a required Hive lookup.
Observed boundary
Retain signed bytes, dependencies, keys and any optional inclusion evidence before an outage.
Review evidence
Use the browser verifier only for its supported format and test dependencies.
Acceptance scope
Use the browser verifier only for its supported format and test dependencies.
Evidence open
Beyond SOC 2 / F
Public Incident Transparency (Post-Mortems)

Incident transparency requires an approved publication policy and actual records.

Scope
Contractual and legal notification obligations need case-specific review.
Observed boundary
The security page contains an outline, not a verified five-day publication SLA.
Review evidence
Acceptance scope
Incident response review.
Evidence open
Beyond SOC 2 / G
On-Chain Settlement Attestation (Base 8453)

A payment transaction is distinct from a receipt signature or evidence anchor.

Scope
Anchoring, if selected, needs a defined commitment, destination and verification method.
Observed boundary
No promise is made that every receipt or commercial transaction is anchored.
Review evidence
Verify signature authenticity separately from payment or inclusion evidence; retain trusted keys and checkpoints.
Acceptance scope
Verify signature authenticity separately from payment or inclusion evidence; retain trusted keys and checkpoints.
Evidence open
Beyond SOC 2 / H
Customer-Controllable Deletion with Cryptographic Proof

A signed deletion record authenticates the signer's statement and identified scope.

Scope
It does not prove that all backups, replicas, caches or exports were removed.
Observed boundary
No universal deletion endpoint, 72-hour all-copy guarantee or dual-signature deletion format is established.
Review evidence
retention inventory lists open schedule, hold, method and verification requirements.
Acceptance scope
retention inventory lists open schedule, hold, method and verification requirements.
Evidence open
Evidence Room

30 evidence references.

These are evidence requests, not completed review dates or a promise of NDA material. The review evidence contains source-backed observations and open operational checks.

Control ID Evidence Type Location / Reference Access Last Reviewed
CC1.1 Responsible disclosure policy Request scoped, dated responsible disclosure policy records. Not supplied Open
CC1.2 Founder-risk disclosure Request scoped, dated founder-risk disclosure records. Not supplied Open
CC1.4 ACVP self-test results Request scoped, dated acvp self-test results records. Not supplied Open
CC1.5 Git commit history (audit trail) Request scoped, dated git commit history (audit trail) records. Not supplied Open
CC2.3 Sub-processor list Request scoped, dated sub-processor list records. Not supplied Open
CC3.1 Internal risk register Request scoped, dated internal risk register records. Not supplied Open
CC3.2 Monthly red-team exercise log Request scoped, dated monthly red-team exercise log records. Not supplied Open
CC4.1 Uptime monitor configuration + logs Request scoped, dated uptime monitor configuration + logs records. Not supplied Open
CC5.2 GitHub branch protection config Request scoped, dated github branch protection config records. Not supplied Open
CC5.3 Internal operations handbook Request scoped, dated internal operations handbook records. Not supplied Open
CC6.1 Access control log retention (90d) Request scoped, dated access control log retention (90d) records. Not supplied Open
CC6.1 MFA enforcement configuration Request scoped, dated mfa enforcement configuration records. Not supplied Open
CC6.3 KMS key rotation audit log Request scoped, dated kms key rotation audit log records. Not supplied Open
CC6.4 Render physical security documentation Request scoped, dated render physical security documentation records. Not supplied Open
CC6.4 Cloudflare physical security documentation Request scoped, dated cloudflare physical security documentation records. Not supplied Open
CC6.6 Cloudflare WAF rules configuration Request scoped, dated cloudflare waf rules configuration records. Not supplied Open
CC6.7 TLS 1.3 configuration + HSTS header Request scoped, dated tls 1.3 configuration + hsts header records. Not supplied Open
CC7.2 Anomaly alert configuration Request scoped, dated anomaly alert configuration records. Not supplied Open
CC7.3 Incident response runbook Request scoped, dated incident response runbook records. Not supplied Open
CC7.5 Recovery test procedure + results Request scoped, dated recovery test procedure + results records. Not supplied Open
CC8.1 GitHub Actions CI pipeline config Request scoped, dated github actions ci pipeline config records. Not supplied Open
CC9.1 Vendor DPA execution records Request scoped, dated vendor dpa execution records records. Not supplied Open
A1.2 Uptime monitor SLA + alert log Request scoped, dated uptime monitor sla + alert log records. Not supplied Open
PI1.1 Receipt schema documentation Request scoped, dated receipt schema documentation records. Not supplied Open
PI1.2 ACVP cryptographic validation results Request scoped, dated acvp cryptographic validation results records. Not supplied Open
C1.1 Data classification policy Request scoped, dated data classification policy records. Not supplied Open
C1.2 Signed deletion proof mechanism Request scoped, dated signed deletion proof mechanism records. Not supplied Open
Beyond/B ML-DSA-65 signature on live receipt Request scoped, dated ml-dsa-65 signature on live receipt records. Not supplied Open
Beyond/E Open-source edge verifier code Request scoped, dated open-source edge verifier code records. Not supplied Open
Beyond/G Base 8453 on-chain settlement hash Request scoped, dated base 8453 on-chain settlement hash records. Not supplied Open

Request the required control records at security@thehiveryiq.com. Availability and delivery timing must be confirmed.

Audit Roadmap

SOC 2 assessment plans and status

No executed engagement or approved assessment date was supplied. Earlier targets are withdrawn pending accountable-owner approval.

Date unapproved

Self-Attested Inventory Published

Establish scope, owner and supporting agreement before publishing a target or completion claim. No independent report, completed penetration test or approved evidence-delivery date was supplied.

Evidence open
Date unapproved

Engagement Letter + First Transparency Report

Establish scope, owner and supporting agreement before publishing a target or completion claim. No independent report, completed penetration test or approved evidence-delivery date was supplied.

Evidence open
Date unapproved

SOC 2 Type 1 Audit Window

Establish scope, owner and supporting agreement before publishing a target or completion claim. No independent report, completed penetration test or approved evidence-delivery date was supplied.

Evidence open
Date unapproved

SOC 2 Type 1 Report Review

Establish scope, owner and supporting agreement before publishing a target or completion claim. No independent report, completed penetration test or approved evidence-delivery date was supplied.

Evidence open
Date unapproved

SOC 2 Type 2 Observation Period

Establish scope, owner and supporting agreement before publishing a target or completion claim. No independent report, completed penetration test or approved evidence-delivery date was supplied.

Evidence open
Date unapproved

ISO 27001 Certification

Establish scope, owner and supporting agreement before publishing a target or completion claim. No independent report, completed penetration test or approved evidence-delivery date was supplied.

Evidence open
Engagement letter availability

Establish scope, owner and supporting agreement before publishing a target or completion claim. No independent report, completed penetration test or approved evidence-delivery date was supplied.

For Procurement Teams

How to use this page today.

Use this inventory to scope a review and request evidence. Decisions remain with the responsible reviewer and the applicable contract.

01

Interim Attestation

Use this inventory to identify the services and control records your review needs. It is not an independent assurance report.

02

Gap Analysis Starting Point

Compare the evidence requests with your own requirements and separately determine applicability and acceptance.

03

Evidence Request

Request the specific records and control IDs at security@thehiveryiq.com. Availability and delivery dates require confirmation.

04

Vendor Security Questionnaire

Reference this page as a source-and-evidence review, not a certification or guarantee of operating effectiveness.

Frequently Asked Questions

Assessment questions and answers

Is self-attested as good as a Type 1 report?

No. This page is maintained by Hive and is not an independent SOC 2 report. Its evidence requests are not an auditor's control opinion.

Why not just buy Vanta?

Automation tooling can support evidence collection but does not establish an independent report. No deployed Vanta configuration or approved audit schedule was supplied.

Does this page satisfy our security review process?

Your reviewer determines the required assurance. Specify the service and data scope when requesting controls evidence or a questionnaire.

What if the Type 1 letter never materializes?

No executed engagement letter or report was supplied. The status remains evidence open until the applicable record is reviewed; no report date is promised.

How do you prevent self-attestation drift over time?

The review evidence ties important wording to source revisions and explicit limitations. Future review ownership and publication cadence require approval.

Can our auditor talk to your security team?

Request a scoped discussion at security@thehiveryiq.com. Participant availability, evidence access and timing require confirmation.

Get Started

SOC 2 is a floor. Here is our floor, and the ceiling above it.

Request the evidence needed for your service and review scope. Material availability and dates require confirmation.