The 93 Annex A controls in ISO/IEC 27002:2022 are public. We mirror them, document our implementation, and publish the evidence. Third-party certification target: 2027.
ISO 27001 is the international floor. Here is our floor — and the ceiling above it.
The two frameworks are complementary, not redundant. Regional procurement requirements and buyer sophistication determine which frameworks matter most to a given reviewer.
Our dual-framework approach: We map our controls to both frameworks so a reviewer in any region can map us to their internal control framework. The underlying security controls are identical — this page and the SOC 2 self-attested page are two views of the same control inventory, expressed in the vocabulary each framework uses. Sources: ISO/IEC 27002:2022 and ISO/IEC 27001:2022.
ISO/IEC 27002:2022 reorganized the control framework from 14 domains (in the 2013 edition) to 4 themes covering all 93 controls. Source: ISO/IEC 27002:2022.
Policies, roles, supplier relationships, incident management, compliance. Covers the governance layer: how Hive Civilization defines, assigns, and manages information security responsibilities at the organizational level. Our ISMS is founder-led with documented policies and review cadence.
Personnel security: screening, terms of employment, security awareness, and responsibilities after employment ends. As a single-founder operation, people controls include background verification, training completion records, and confidentiality obligations embedded in all agreements.
Physical security perimeters, entry controls, equipment protection, clear desk/screen. Hive operates as a cloud-native company; physical controls apply to the founder workstation, home office, and the sub-processor physical infrastructure (Render/AWS/Cloudflare data centers under their own certifications).
Access control, cryptography, system security, network security, software development security, monitoring. This is where Hive's deepest controls live, including our post-quantum hybrid signature stack, Wave-Lattice entropy substrate, and Cloudflare edge security posture.
ISO/IEC 27002:2022 numbering exactly as published. Each control includes the ISO description, our implementation note, and evidence reference. Status: implemented = operational today. partial = in place but not yet comprehensive. planned = on roadmap with target date. N/A = not applicable with rationale.
| Control | Title | ISO Description | Our Implementation | Status |
|---|---|---|---|---|
| A.5.1 | Policies for information security | Information security policy and topic-specific policies defined, approved by management, published, communicated, and reviewed at planned intervals. | Information Security Policy documented in the Hive internal policy repository (GitHub, private). Policy covers acceptable use, access control, cryptography, incident response, and supplier management. Reviewed annually; last review Q1 2026. Version history maintained in git commit log. | Implemented |
| A.5.2 | Information security roles and responsibilities | Information security roles and responsibilities defined and allocated according to the information security policy. | Founder (Steve Rotzin) holds the CISO function explicitly. All security responsibilities documented in the RACI matrix within the IS Policy. Sub-processor security responsibilities contractually allocated via DPA and ToS for each vendor. | Implemented |
| A.5.3 | Segregation of duties | Conflicting duties and areas of responsibility segregated to reduce opportunities for unauthorized or unintentional modification or misuse. | As a single-founder company, full segregation of duties is not achievable at this stage. Compensating controls: all code changes require CI/CD approval gates; production deployments trigger automated ACVP self-tests; financial transactions require two-factor authentication and are logged immutably. Documented limitation in ISMS. Will re-assess as headcount grows. | Partial |
| A.5.4 | Management responsibilities | Management requires all personnel to apply information security in accordance with established policy and procedures. | All contractors and vendors receive the Hive IS Policy as part of onboarding. The DPA requires processors to maintain their own information security controls consistent with ISO 27001 / SOC 2. Founder-level accountability documented in the Founder Risk Disclosure at /security/founder-risk/. | Implemented |
| A.5.5 | Contact with authorities | Appropriate contacts with relevant authorities maintained. | Contacts established with: CERT/CC for coordinated vulnerability disclosure, relevant law enforcement contacts documented in the incident response runbook for data breach notification, Delaware corporate legal counsel for breach notification obligations under GDPR Art. 33 / CCPA. Contact list reviewed semi-annually. | Implemented |
| A.5.6 | Contact with special interest groups | Appropriate contacts with special interest groups or security forums maintained. | Subscriptions active to: NIST post-quantum cryptography mailing list, CISA cybersecurity alerts, Cloudflare security bulletins, GitHub security advisories, Render security updates. CVE feed monitored via Dependabot on all repositories. | Implemented |
| A.5.7 | Threat intelligence | Information relating to information security threats collected and analyzed to produce threat intelligence. | Threat intelligence inputs: Cloudflare Radar for DDoS/attack trend data, CISA Known Exploited Vulnerabilities catalog reviewed monthly, GitHub Dependabot alerts processed within 7 days of receipt, NIST NVD CVE feed for dependencies. Formal threat intelligence program planned Q3 2026 when dedicated tooling is deployed. | Partial |
| A.5.8 | Information security in project management | Information security integrated into project management throughout the project lifecycle. | All new features go through a security design checklist before code review approval. The checklist includes: data classification assessment, authentication requirements, logging requirements, cryptographic controls applicability, and sub-processor data flows. Checklist enforced via GitHub PR template. | Implemented |
| A.5.9 | Inventory of information and other associated assets | Inventory of information and other associated assets maintained and identified, with ownership established. | Asset inventory maintained in the internal IS registry covering: production databases, cryptographic keys, API secrets, customer data stores, sub-processor relationships, and source code repositories. Each asset has an assigned owner (currently the founder), classification, and review date. Reviewed quarterly. | Implemented |
| A.5.10 | Acceptable use of information and other associated assets | Rules for acceptable use and procedures for handling information and other associated assets identified, documented, and implemented. | Acceptable Use Policy embedded in the master Information Security Policy. Covers: prohibition on personal use of production credentials, prohibition on shadow-IT integrations, requirements for encrypting data at rest and in transit, and personal device management requirements for anyone with access to production systems. | Implemented |
| A.5.11 | Return of assets | Personnel and other interested parties return all organizational assets upon change or termination of employment, contract, or agreement. | Offboarding checklist requires return of all equipment and revocation of all credentials before final payment. For contractors, contract terms include explicit asset-return obligations. Credential revocation is automated via Google Workspace offboarding. Checklist maintained in internal HR/ops log. | Implemented |
| A.5.12 | Classification of information | Information classified according to information security needs based on confidentiality, integrity, availability, and relevant stakeholder requirements. | Four-tier classification: Public, Internal, Confidential, Restricted. Classification applied to all information assets in the asset inventory. Handling rules per tier documented in the IS Policy: Public = no special controls; Internal = access control required; Confidential = encryption at rest required; Restricted = MFA + audit log required. | Implemented |
| A.5.13 | Labelling of information | Appropriate set of procedures for information labelling developed and implemented in accordance with the information classification scheme. | Document labelling applied to all internal policy documents (header footer classification markings). API responses include a classification header for internal service calls. Customer data payloads classified in the DPA. Automated labelling for output documents planned as part of the compliance tooling deployment in Q3 2026. | Partial |
| A.5.14 | Information transfer | Formal transfer policies, procedures, and controls in place to protect information transferred within the organization and to external parties. | All data transfer to/from the API uses TLS 1.3 only. Webhook deliveries use SHA-256 HMAC signatures (X-Hive-Signature header). No plaintext email for customer data. S3 transfers use server-side encryption. DPA governs all transfers to sub-processors. SFTP available for bulk enterprise data exchange on request. | Implemented |
| A.5.15 | Access control | Rules to control physical and logical access to information and other associated assets established and implemented. | Access control policy: least-privilege principle; role-based access control at service tier; no shared credentials; MFA required on all production systems; SSO via Google Workspace; hardware security key (FIDO2/WebAuthn) for admin access. Access matrix reviewed quarterly and on any personnel change. | Implemented |
| A.5.16 | Identity management | Full lifecycle of identities managed. Identities uniquely assigned. Shared identities prohibited except when approved and documented. | All human identities provisioned through Google Workspace (SSO anchor). All machine identities provisioned as service-specific credentials via Cloudflare API tokens and Render environment variables. No shared credentials. DID-based identities for API consumers managed through the Hive DID registry. Identity lifecycle events logged. | Implemented |
| A.5.17 | Authentication information | Allocation and management of authentication information controlled by a management process. | Passwords managed via 1Password Teams; minimum entropy enforced by policy (20+ char, no reuse). API keys are 256-bit random; issued through provisioning workflow, not ad-hoc. Cryptographic keys managed via KMS; private key material never leaves KMS boundary. All credentials logged at issuance, rotation, and revocation. | Implemented |
| A.5.18 | Access rights | Access rights to information and other associated assets provisioned, reviewed, modified, and removed following access control policy. | Access provisioning workflow documented: request → approval → provision → log. Quarterly access review conducted by the founder against the access matrix. Departing contractors have access revoked same-day. Privilege escalation requires documented justification and is logged separately. | Implemented |
| A.5.19 | Information security in supplier relationships | Processes and procedures defined and implemented to manage information security risks associated with use of supplier products or services. | Supplier security questionnaire completed for all sub-processors. Each sub-processor must maintain SOC 2 Type 2 or ISO 27001 certification or equivalent (see sub-processor table at /security/). Annual review of each supplier's published security posture. DPA executed with all processors handling customer data. | Implemented |
| A.5.20 | Addressing security in supplier agreements | Relevant security requirements established and agreed with each supplier based on the type of supplier relationship. | All sub-processor agreements include: data protection obligations, breach notification requirements (72-hour notice to Hive), audit rights (via their SOC 2/ISO certification), sub-processor change notification, data deletion on termination, and liability clauses. Standard DPA template reviewed by counsel annually. | Implemented |
| A.5.21 | Managing security in the ICT supply chain | Processes and procedures defined and implemented to manage information security risks associated with ICT products and services supply chain. | All open-source dependencies tracked via GitHub Dependabot. SLSA-compatible build provenance on releases (aspirational: SLSA Level 3 target by Q4 2026; currently Level 1 via GitHub Actions). Sub-processor ICT supply chain reviewed through their published certifications. Container base images pulled from verified registries only. | Partial |
| A.5.22 | Monitoring, review and change management of supplier services | Organization regularly monitors, reviews and manages changes to supplier services. | Sub-processor status pages monitored via uptime tooling. Cloudflare, Render, and AWS status feeds integrated into internal alerting. Any sub-processor outage incident logged. Sub-processor changes require 30-day advance notice to customers per our DPA. Annual review of each supplier's SOC 2/ISO certification currency. | Implemented |
| A.5.23 | Information security for use of cloud services | Processes for acquisition, use, management, and exit from cloud services established in accordance with information security requirements. | Cloud service policy covers: approved cloud providers (Cloudflare, Render, AWS), data classification requirements per service, exit/migration requirements documented in the business continuity plan, encryption-at-rest requirements. Shadow-IT cloud services prohibited. See also ISO 27017 extensions below. | Implemented |
| A.5.24 | Information security incident management planning and preparation | Organization plans and prepares for managing information security incidents by defining incident management processes, roles, and responsibilities. | Six-phase incident response runbook documented and published at /security/#incident-response. Roles: founder as incident lead, legal counsel as breach notification coordinator, Cloudflare as first-tier DDoS response. Severity classification matrix documented (Sev 1–3). Runbook reviewed semi-annually and after every Sev 1/2 event. | Implemented |
| A.5.25 | Assessment and decision on information security events | Organization assesses information security events and decides if they are classified as incidents. | Security events triaged against Sev 1–3 classification matrix within the first 30 minutes of detection. Triage decision logged in the internal incident register with timestamp, classifier, and rationale. False positives also logged to tune alerting thresholds. | Implemented |
| A.5.26 | Response to information security incidents | Information security incidents responded to in accordance with documented procedures. | Incident response follows the six-phase runbook: Detection, Triage, Contain, Eradicate, Recover, Post-Mortem. Customer notification SLAs: Sev 1 = 1 hour; Sev 2 = 4 hours; Sev 3 = next business day. Post-mortems published within 5 business days for Sev 1. Incident log maintained in encrypted internal store. | Implemented |
| A.5.27 | Learning from information security incidents | Knowledge gained from information security incidents used to strengthen and improve security controls. | Every Sev 1/2 post-mortem includes a "What we changed" section with specific control updates. Control changes tracked in the ISMS changelog. Near-miss events (events that did not become incidents) also reviewed quarterly for systemic patterns. Lessons learned fed back into the IS Policy annual review cycle. | Implemented |
| A.5.28 | Collection of evidence | Organization establishes and implements procedures for identification, collection, acquisition and preservation of evidence. | Evidence collection procedures documented in the incident runbook: immutable log export from Cloudflare and Render before any system modification; chain-of-custody log for all evidence items; cryptographic hashes of evidence files at collection time. Evidence preserved in encrypted S3 bucket with versioning enabled and object-lock on Sev 1 evidence. | Implemented |
| A.5.29 | Information security during disruption | Organization plans how to maintain information security at an appropriate level during disruption. | Business continuity plan includes a security continuity section: cryptographic keys replicated to secondary KMS region; Cloudflare failover handles routing disruption; backup admin access path documented (out-of-band recovery credentials in 1Password, accessible to a designated succession contact per the Founder Risk disclosure). Tested quarterly via tabletop exercise. | Partial |
| A.5.30 | ICT readiness for business continuity | ICT readiness planned, implemented, maintained, and tested based on business continuity objectives and ICT continuity requirements. | ICT continuity targets: RTO 4 hours / RPO 24 hours for production API. Cloudflare provides automatic failover at the edge layer. Render supports blue-green deployments. Database backups run every 6 hours with 30-day retention. Restoration procedures tested semi-annually. Formal BCP/DRP document published internally; updated annually. | Partial |
| A.5.31 | Legal, statutory, regulatory, and contractual requirements | Legal, statutory, regulatory, and contractual requirements relevant to information security identified, documented, and kept up to date. | Legal requirements register maintained: GDPR Art. 32 (technical controls), CCPA data subject rights, Delaware corporate law, CFAA, applicable payment card industry requirements, and ECPA. Register reviewed annually by legal counsel. Regulatory change alerts monitored via counsel retainer. This page itself satisfies certain transparency obligations. | Implemented |
| A.5.32 | Intellectual property rights | Organization implements appropriate procedures to protect intellectual property rights. | All code written by the founder is proprietary IP owned by Hive Civilization, Inc. Open-source dependency licenses reviewed via license-checker in CI/CD; GPL-incompatible licenses flagged for legal review. Contractor IP assignment clause standard in all agreements. Copyright notice maintained on all authored works. | Implemented |
| A.5.33 | Protection of records | Records protected from loss, destruction, falsification, unauthorized access, and unauthorized release in accordance with legal, regulatory, contractual, and business requirements. | Financial records retained per Delaware corporate law minimums (7 years). Customer transaction records retained per DPA (90-day default; configurable downward). Records stored in encrypted S3 with versioning. Deletion follows documented retention schedule. No records modified after creation (immutable append-only log pattern for receipt records). | Implemented |
| A.5.34 | Privacy and protection of personally identifiable information | Organization identifies and meets requirements for preserving privacy and protection of PII according to applicable laws and regulations. | PII minimization by default: the platform stores hashes of operations, not PII, unless a customer DPA explicitly enables PII storage. Zero PII in logs by default. EU data residency option available. GDPR and CCPA privacy rights endpoints documented at /privacy.html. See also ISO 27701 extensions below. | Implemented |
| A.5.35 | Independent review of information security | Organization's approach to managing information security and its implementation reviewed independently at planned intervals or when significant changes occur. | External independent review: SOC 2 Type 1 audit engagement signed; engagement firm will conduct independent assessment of controls design Q3–Q4 2026. Annual third-party penetration test scheduled Q3 2026. NIST ACVP self-test on every deployment provides independent cryptographic validation. ISO 27001 third-party certification target 2027. | Partial |
| A.5.36 | Compliance with policies, rules, and standards for information security | Compliance with information security policies, rules, and standards regularly reviewed and, if necessary, corrective actions taken. | Quarterly internal compliance review against the IS Policy checklist. Results logged in the ISMS compliance log. Corrective actions tracked in the GitHub issue tracker with target resolution dates. This page functions as a public compliance self-assessment. Quarterly Transparency Report (first issue Q3 2026) will include compliance deviations and remediation status. | Partial |
| A.5.37 | Documented operating procedures | Operating procedures for information processing facilities documented and made available to personnel who need them. | Operating procedures documented for: deployment pipeline, incident response, key rotation, backup and recovery, access provisioning, vendor onboarding. Procedures maintained in the internal wiki (Notion, restricted access) and in this public security posture page for customer-facing procedures. Procedures reviewed semi-annually and updated after any incident. | Implemented |
| Control | Title | ISO Description | Our Implementation | Status |
|---|---|---|---|---|
| A.6.1 | Screening | Background verification checks carried out on all candidates for employment and contractors prior to engagement, proportional to role and risk. | Founder background: publicly verifiable via LinkedIn, GitHub commit history, and Delaware corporate filing. All contractors with production access undergo background screening via the engagement process. For roles with access to cryptographic key material, identity verification required at contract signing. Formal background check vendor engaged for Q3 2026 as headcount grows. | Partial |
| A.6.2 | Terms and conditions of employment | Employment contractual agreements state personnel's and organization's responsibilities for information security. | All contractor agreements include: confidentiality obligations, acceptable use provisions, incident reporting requirements, and IP assignment. The IS Policy is an exhibit to every contractor agreement. Employees (when hired) will receive an employment agreement with equivalent security provisions as a standard clause. | Implemented |
| A.6.3 | Information security awareness, education, and training | Personnel and relevant interested parties receive appropriate information security awareness, education, and training. | Founder completes annual security training (KnowBe4 equivalent). All contractors receive IS Policy briefing at onboarding and must acknowledge receipt. Security bulletins distributed to all parties with production access when CISA KEV catalog updates or Cloudflare/Render advisories are issued. Formal LMS-based training planned as team grows. | Partial |
| A.6.4 | Disciplinary process | Formal and communicated disciplinary process in place to take action against personnel who have committed an information security policy violation. | Disciplinary process documented in the IS Policy: verbal warning (first offence, minor), written warning with corrective action plan (second offence or moderate), access revocation and contract termination (severe violation). Process applies to contractors and future employees. Currently not tested; process documented and accessible to all parties. | Implemented |
| A.6.5 | Responsibilities after termination or change of employment | Information security responsibilities and duties that remain valid after termination or change of employment defined, communicated, and enforced. | Contractor agreements include post-termination confidentiality obligations (3-year tail) and IP assignment. Offboarding checklist triggers credential revocation, equipment return, and NDA reminder. Continued access to confidential information after termination is a breach of contract with documented remedies. | Implemented |
| A.6.6 | Confidentiality or non-disclosure agreements | Confidentiality or NDA requirements reflecting the organization's needs for protection of information identified, documented, reviewed regularly, and signed by personnel and other interested parties. | Mutual NDA executed with: all contractors, all enterprise customers with access to confidential technical documentation, audit firm (SOC 2 engagement), and legal counsel. Standard NDA template reviewed by counsel. One-way NDA available for prospective customers during security review process. NDAs logged with expiration tracking. | Implemented |
| A.6.7 | Remote working | Security measures implemented when personnel work remotely to protect information accessed, processed, or stored outside the organization's premises. | Hive is a fully remote operation. Remote working controls: WPA3 or higher Wi-Fi required; VPN available for sensitive administrative access; screen lock enforced (15-minute idle); disk encryption required on all devices with production access (FileVault on macOS); no production work on shared or untrusted devices. Policy enforced via IS Policy acknowledgement. | Implemented |
| A.6.8 | Information security event reporting | Organization provides a mechanism for personnel to report observed or suspected information security events through appropriate channels and in a timely manner. | Security event reporting: [email protected] with 24/7 receipt acknowledgement. PGP key available on request for sensitive disclosures. Responsible disclosure policy published at /security/#disclosure. All contractors briefed on the reporting channel at onboarding. Internal incident log updated within 30 minutes of report receipt. | Implemented |
| Control | Title | ISO Description | Our Implementation | Status |
|---|---|---|---|---|
| A.7.1 | Physical security perimeters | Security perimeters defined and used to protect areas containing information and other associated assets. | Hive's production infrastructure is hosted in Cloudflare, Render, and AWS facilities — each with their own ISO 27001-certified physical perimeter controls (see their published trust pages). The founder workstation is in a locked home office with physical access restricted to the founder. No on-premises servers or co-location facilities are used. | Implemented |
| A.7.2 | Physical entry | Secure areas protected by appropriate entry controls and access points. | Physical entry to data center facilities managed by sub-processors (Cloudflare, AWS, Render) under their own certifications. Founder office entry: locked door; no visitors permitted during sensitive work without escort. Visitor log maintained for home office if a contractor visits in person (rare). | Implemented |
| A.7.3 | Securing offices, rooms, and facilities | Physical security designed and applied to offices, rooms, and facilities. | Founder home office: dedicated room with lock; screen positioned away from windows; no sensitive information visible on whiteboards or screens if visitors are present. Production systems are entirely cloud-hosted; no on-premises server rooms or equipment requiring physical securing beyond the workstation. | Implemented |
| A.7.4 | Physical security monitoring | Premises monitored continuously for unauthorized physical access. | Data center physical monitoring: delegated to Cloudflare/AWS/Render (see their SOC 2/ISO certifications). Home office: no CCTV currently deployed; this is a gap acknowledged in the ISMS. Physical security monitoring for the office environment planned if Hive moves to a co-working or leased office space. Compensating control: all sensitive work is logical (cloud-based), reducing physical exposure. | Partial |
| A.7.5 | Protecting against physical and environmental threats | Protection against physical and environmental threats, such as natural disasters and other intentional or unintentional physical threats, designed and implemented. | Cloudflare, Render, and AWS all operate multiple geographically distributed data centers with redundancy against physical/environmental threats. Workstation protected by UPS (uninterruptible power supply) to prevent corruption from power outages. Sensitive media stored in encrypted form only; physical loss does not expose data. | Implemented |
| A.7.6 | Working in secure areas | Security measures for working in secure areas designed and implemented. | Policy: no sensitive work on public Wi-Fi without VPN; no screen sharing of production credentials or logs in video calls without explicit need; recording of video calls prohibited when sensitive information is on screen. Policy communicated to all contractors. Enforced via IS Policy acknowledgement at onboarding. | Implemented |
| A.7.7 | Clear desk and clear screen | Clear desk rules applied to papers and removable storage media, and clear screen rules applied to information processing facilities. | Clear desk: no physical papers containing customer data or credentials left unattended. Clear screen: screen lock set to 15-minute idle; enforced by macOS system preference. No post-it notes with passwords; all credentials in 1Password. Physical media (USB drives) prohibited for data transfer; cloud-only transfers required. | Implemented |
| A.7.8 | Equipment siting and protection | Equipment sited securely and protected. | Founder workstation: positioned away from windows and public view; on a secure desk; not accessible to visitors. Power supply protected by UPS. No equipment left unattended in vehicles. Laptop not checked in as airline baggage. Data center equipment siting managed by sub-processors under their own certifications. | Implemented |
| A.7.9 | Security of assets off-premises | Off-premises assets protected. | All off-premises equipment (laptop when traveling) has full-disk encryption (FileVault), remote wipe capability via Apple MDM, and requires MFA to unlock. No production data stored locally; all data access is cloud-mediated. Lost/stolen device procedure: immediate remote wipe + credential rotation + incident log entry. | Implemented |
| A.7.10 | Storage media | Storage media managed through its full life cycle of acquisition, use, transportation, and disposal according to classification scheme and handling requirements. | Physical media policy: no external USB drives for production data; cloud-only transfers. Decommissioned drives securely wiped (NIST 800-88 standard) before disposal; certificate of destruction obtained from Apple Store or authorized Apple Service Provider. Encrypted cloud storage is the exclusive approved media for Confidential and Restricted data. | Implemented |
| A.7.11 | Supporting utilities | Information processing facilities protected from failures in supporting utilities. | Workstation protected by UPS for power outage resilience. Internet connectivity: primary ISP + cellular hotspot backup for critical operations. Data center utility resilience (power, cooling, network) managed by Cloudflare/AWS/Render under their own certifications (all maintain N+1 or better redundancy). Cloud-first architecture eliminates most single-utility dependencies. | Implemented |
| A.7.12 | Cabling security | Cables carrying power, data, or supporting information services protected from interception, interference, or damage. | Office cabling: Ethernet preferred over Wi-Fi for sensitive administrative work; cables routed away from public access. Wi-Fi uses WPA3 with strong pre-shared key; network isolated from guest networks. Data center cabling managed by sub-processors under their own physical security programs. TLS 1.3 ensures logical cabling security end-to-end regardless of physical layer. | Implemented |
| A.7.13 | Equipment maintenance | Equipment maintained correctly to ensure continued availability and integrity. | Founder workstation: macOS updates applied within 7 days of release for security updates, 30 days for feature updates. Battery health monitored; hardware refreshed every 3 years or on failure. Cloud infrastructure maintenance handled by sub-processors with documented maintenance windows communicated via status pages. | Implemented |
| A.7.14 | Secure disposal or re-use of equipment | Items of equipment containing storage media verified to ensure sensitive data and licensed software removed or securely overwritten prior to disposal or re-use. | Disposal procedure: factory reset + NIST 800-88 secure erase for all storage media before disposal or transfer. Certificate of destruction obtained from Apple Authorized Service Provider. No equipment donated or sold without verified secure erasure. Cloud infrastructure decommissioning managed by sub-processors; data deletion confirmed via their API/console before terminating services. | Implemented |
| Control | Title | ISO Description | Our Implementation | Status |
|---|---|---|---|---|
| A.8.1 | User endpoint devices | Information stored on, processed by, or accessible via user endpoint devices protected. | Endpoint policy: full-disk encryption (FileVault) required; Gatekeeper enabled; XProtect active; MFA on all accounts; no production data stored locally; screen lock at 15 minutes; remote wipe enabled. MDM enrollment for any future company-issued devices. Jailbroken or rooted devices prohibited from accessing production systems. | Implemented |
| A.8.2 | Privileged access rights | Allocation and use of privileged access rights restricted and managed. | Privileged access (admin rights to production systems) limited to the founder only. Hardware security key (FIDO2/WebAuthn) required for Hivemorph admin panel. Privileged access sessions logged. Privilege escalation requires documented justification and is logged separately. No standing privileged access to production databases; access granted just-in-time via tooling. | Implemented |
| A.8.3 | Information access restriction | Access to information and application system functions restricted in accordance with the access control policy. | API authorization: every endpoint requires a valid DID-authenticated token; scope-limited tokens issued per use case. Database access restricted to service-level roles with minimum required permissions. Customer data partitioned by tenant ID; cross-tenant access technically impossible at the schema level. No wildcard service account permissions. | Implemented |
| A.8.4 | Access to source code | Read and write access to source code, development tools, and software libraries managed appropriately to prevent unauthorized changes. | Source code hosted on GitHub (private repositories). Branch protection rules enforce: no direct pushes to main; all changes via PR; CI must pass; at least one reviewer required (currently the founder reviews all changes). Repository access limited to founder and specific contractors on a need-to-know basis. Audit logs maintained by GitHub. | Implemented |
| A.8.5 | Secure authentication | Secure authentication technologies and procedures implemented based on information access restrictions. | Authentication stack: Google SSO for human identities; FIDO2/WebAuthn hardware keys for admin access; DID-based authentication for API consumers; TOTP as minimum second factor; passkeys available for customer-facing login. Authentication events logged with IP, user agent, and timestamp. Failed authentication triggers alert after 5 attempts. | Implemented |
| A.8.6 | Capacity management | Use of resources monitored and adjusted in line with current and expected capacity requirements. | Capacity monitoring via Render metrics dashboard and Cloudflare analytics. Auto-scaling configured on Render to handle traffic spikes. Resource utilization alerts set at 70% sustained CPU and 80% memory. Capacity planning reviewed quarterly; current headroom documented in the operational log. DDoS protection via Cloudflare prevents volumetric exhaustion attacks. | Implemented |
| A.8.7 | Protection against malware | Protection against malware implemented and supported by appropriate user awareness. | macOS built-in XProtect + Gatekeeper active. Malwarebytes endpoint protection deployed on founder workstation. All npm dependencies scanned via npm audit and Dependabot. Cloudflare WAF detects and blocks known malicious payloads at the edge. No email attachments auto-executed. Phishing protection via Google Workspace Advanced Protection. | Implemented |
| A.8.8 | Management of technical vulnerabilities | Information about technical vulnerabilities of information systems obtained in a timely manner; exposure evaluated; appropriate measures taken. | Vulnerability management: GitHub Dependabot alerts for all dependency CVEs; critical/high CVEs remediated within 7 days, medium within 30 days. CISA KEV catalog reviewed monthly; affected dependencies prioritized. Cloudflare and Render vulnerability disclosures monitored. Internal vulnerability register tracks open items. Annual third-party pen test starting Q3 2026. | Implemented |
| A.8.9 | Configuration management | Configurations (including security configurations) of hardware, software, services, and networks established, documented, implemented, monitored, and reviewed. | Infrastructure configuration stored as code in GitHub (infrastructure-as-code). Configuration drift detected via CI/CD checks on every deployment. Cloudflare WAF ruleset versioned and reviewed quarterly. Render environment variables managed via the Render dashboard with change log. Baseline security configurations documented for each service in the asset inventory. | Implemented |
| A.8.10 | Information deletion | Information stored in information systems, devices, or other storage media deleted when no longer required. | Deletion policy: automated deletion at the end of the retention period (90-day default for operational data). Customer-controlled deletion endpoint: authenticated DELETE request purges all customer data and downstream copies within 72 hours, with cryptographic deletion proof endpoint. S3 object expiration policies enforced. Soft-delete with 30-day recovery window for accidental deletion. | Implemented |
| A.8.11 | Data masking | Data masking used in accordance with the organization's topic-specific policy on access control and other related policies and business requirements, with applicable legislation. | PII masking by default: Sentry error logs scrub PII fields via the Sentry Relay before ingestion. No PII in log output unless explicitly enabled per DPA. API responses mask sensitive fields (last 4 digits for card numbers if applicable; hashes for PII identifiers). Masked fields documented in the API reference. Formal data masking library integrated into the API middleware layer. | Implemented |
| A.8.12 | Data leakage prevention | Data leakage prevention measures applied to systems, networks, and other devices that process, store, or transmit sensitive information. | DLP measures: Cloudflare WAF custom rules block exfiltration patterns; API rate limits prevent bulk data extraction; no bulk export endpoints without authentication and logging; database queries return only explicitly requested fields (no SELECT *); API response size limits enforced; anomaly detection alerts on unusual data volume or access patterns. | Partial |
| A.8.13 | Information backup | Backup copies of information, software, and systems maintained and tested regularly in accordance with the agreed backup policy. | Backup policy: database backups every 6 hours; 30-day retention; stored in a separate AWS S3 bucket with versioning and object lock. Configuration backups: all IaC stored in GitHub (inherently versioned). Backup integrity: automated restoration test run monthly; results logged. Offsite: S3 cross-region replication to a secondary region enabled. | Implemented |
| A.8.14 | Redundancy of information processing facilities | Information processing facilities implemented with redundancy sufficient to meet availability requirements. | Redundancy architecture: Cloudflare Anycast CDN provides edge redundancy across 300+ PoPs. Render auto-scaling with multi-instance deployment for production API. Database with automatic failover replica. Cloudflare Workers provide serverless redundancy for the verifier and signing endpoints. Target availability: 99.9% monthly; current performance published at status.thehiveryiq.com. | Implemented |
| A.8.15 | Logging | Logs recording activities, exceptions, faults, and other relevant events produced, stored, protected, and analyzed. | Logging stack: structured logs via Render log drain to centralized store; Cloudflare analytics for edge events; Sentry for application errors (PII-scrubbed). Log fields: request ID, DID, endpoint, HTTP status, response time (no payload bodies). Log retention: 90 days minimum. Log integrity: hashed on write; log store is append-only. Alerts on log volume anomalies. | Implemented |
| A.8.16 | Monitoring activities | Networks, systems, and applications monitored for anomalous behavior; appropriate actions taken to evaluate potential information security incidents. | Monitoring: uptime synthetic checks with 2-minute alert SLA; Cloudflare anomaly detection on traffic patterns; Sentry error rate alerts; authentication spike alerts (5+ failed attempts triggers notification); receipt volume anomaly alerts (deviation from 30-day baseline). All alerts routed to founder via PagerDuty equivalent. Post-incident review for every alert triggered. | Implemented |
| A.8.17 | Clock synchronization | Clocks of information processing systems synchronized to approved time sources. | All cloud infrastructure (Cloudflare Workers, Render, AWS) uses NTP synchronized to stratum-1/2 sources as part of their managed platform. Cryptographic timestamps in Hive receipts and on-chain attestations use the Cloudflare Workers runtime clock (NTP-synchronized). All log timestamps are UTC. Receipt timestamp accuracy is verifiable on-chain via Base 8453 block timestamps. | Implemented |
| A.8.18 | Use of privileged utility programs | Use of utility programs that might be capable of overriding system and application controls restricted and tightly controlled. | Privileged utility programs (database admin clients, cloud CLI tools) require: hardware security key authentication for the admin account; session recorded in the operations log; usage documented with business justification. Production database access via privileged utility is an exceptional event requiring logged justification. No privileged utilities installed on developer machines without explicit approval. | Implemented |
| A.8.19 | Installation of software on operational systems | Procedures and measures implemented to securely manage software installation on operational systems. | Production software installations require: code review in GitHub PR; CI/CD pipeline validation; NIST ACVP self-test for any cryptographic module changes; deployment approval by founder. No ad-hoc manual installations on production systems. All production software versions pinned in the deployment manifest. Rollback available within 5 minutes via Render deployment history. | Implemented |
| A.8.20 | Networks security | Networks and network devices secured, managed, and controlled to protect information in systems and applications. | Network security: Cloudflare WAF on all public endpoints; IP allowlist on admin interfaces; no public database ports exposed; all services communicate via private networking on Render; TLS 1.3 only on all external connections; mTLS available for enterprise customers; DDoS protection active at network and application layer. | Implemented |
| A.8.21 | Security of network services | Security mechanisms, service levels, and service requirements of network services identified, implemented, and monitored. | Network service SLAs: Cloudflare SLA 100% uptime for DNS; Render SLA 99.95% for hosted services. Security features: HSTS with min-age 63072000 and includeSubDomains; DNSSEC enabled on thehiveryiq.com; CAA DNS record restricts certificate issuance to approved CAs. Certificate expiration monitored with 30-day advance alert. No deprecated TLS cipher suites permitted. | Implemented |
| A.8.22 | Segregation of networks | Groups of information services, users, and information systems segregated in networks. | Network segregation: production, staging, and development environments are separate Render services with separate environment variables and separate Cloudflare zones. Database access is private-network only (not publicly routable). Customer data isolated per tenant at the application layer. Enterprise customers may request dedicated infrastructure for additional segregation. | Implemented |
| A.8.23 | Web filtering | Access to external websites managed to reduce exposure to malicious content. | Web filtering: Cloudflare Gateway deployed for DNS-layer filtering on the founder workstation; blocks known malicious domains and phishing sites. All outbound API calls from Hive backend use an allowlist of approved external endpoints. Arbitrary URL fetch by internal services is disabled; only explicitly approved external APIs are callable. CSP headers restrict browser-side external resource loading. | Implemented |
| A.8.24 | Use of cryptography | Rules for effective use of cryptography, including cryptographic key management, defined and implemented. | Cryptographic policy: Ed25519 + ML-DSA-65 hybrid signing (FIPS 204 aligned) deployed in production; TLS 1.3 only; AES-256-GCM for data at rest; SHA-256 for HMAC; KMS-backed key management with 90-day rotation; key material never leaves KMS boundary; NIST ACVP self-test on every deployment. Post-quantum cryptography details in the Beyond-ISO section below. Sources: ISO 27002 A.8.24. | Implemented |
| A.8.25 | Secure development lifecycle | Rules for secure development of software and systems established and applied. | Secure SDLC: threat modeling for new features; security checklist in PR template; automated SAST via CodeQL on GitHub Actions; dependency scanning via Dependabot; no secrets in source code (pre-commit hooks block credential commits); staging environment mandatory before production deployment; rollback capability required before any release. | Implemented |
| A.8.26 | Application security requirements | Information security requirements identified, specified, and approved when developing or acquiring applications. | Application security requirements defined in the security design checklist and embedded in the PR template. Requirements cover: authentication method, authorization scope, data classification, encryption requirements, logging requirements, and rate limiting. Third-party libraries assessed for known vulnerabilities before adoption. OWASP Top 10 used as baseline requirements checklist. | Implemented |
| A.8.27 | Secure system architecture and engineering principles | Principles for engineering secure systems established, documented, maintained, and applied to any information system development and integration activities. | Security engineering principles: defense-in-depth (Cloudflare edge + application + database); zero-trust network model (no implicit trust between services); cryptographic-first design (all receipts cryptographically signed); minimal attack surface (no unused endpoints exposed); immutable audit log; PII minimization by default. Architecture documented in the internal system design document, reviewed annually. | Implemented |
| A.8.28 | Secure coding | Secure coding principles applied to software development. | Secure coding practices: TypeScript strict mode enforced; input validation via Zod schema on all API endpoints; output encoding enforced to prevent injection; parameterized queries only (no dynamic SQL); no eval() or similar dynamic execution; OWASP secure coding checklist referenced in PR review. CodeQL SAST scans on every PR. Pre-commit hooks block secrets and insecure patterns. | Implemented |
| A.8.29 | Security testing in development and acceptance | Security testing processes defined and implemented in the development lifecycle. | Security testing: automated SAST on every PR; NIST ACVP cryptographic self-test on every deployment; dependency vulnerability scan on every build; manual security review required for changes to authentication, authorization, or cryptographic code. Annual third-party pen test starting Q3 2026. Staging environment functional testing before every production release. | Partial |
| A.8.30 | Outsourced development | Organization supervises and monitors the activities related to outsourced system development. | Outsourced development policy: all contractor code goes through the same GitHub PR review process as internal code; contractors do not have direct production access; all contractor contributions require founder review and approval before merge; contractor code is covered by the IP assignment clause in the agreement; contractor access revoked immediately on contract end. | Implemented |
| A.8.31 | Separation of development, test, and production environments | Development, testing, and production environments separated and secured. | Three separate environments: development (local), staging (Render staging service with separate domain and credentials), production (Render production service). Environment variables are separate; no production secrets in staging; no staging data in production. Deployment gate: CI must pass on staging before production deploy is permitted. Database per environment; no production data in staging. | Implemented |
| A.8.32 | Change management | Changes to information processing facilities and information systems subject to change management procedures. | Change management: all production changes via GitHub PR with mandatory CI pass and founder approval; change log maintained in git history; rollback procedure documented and tested; emergency change process documented (hotfix branch + post-hoc review within 24 hours); change freeze window during critical business periods documented in the operational calendar. | Implemented |
| A.8.33 | Test information | Test information appropriately selected, protected, and managed. | Test data policy: no production customer data used in testing; synthetic test data generated for all test scenarios; production data anonymization procedure available if a specific production-like test is required (anonymize first, test second, purge). Test data stored in the staging environment only; automatic purge on environment teardown. | Implemented |
| A.8.34 | Protection of information systems during audit testing | Audit tests and other assurance activities involving assessment of operational systems planned and agreed upon to minimize disruptions to business processes. | Audit testing protocol: SOC 2 audit firm reviews control evidence in a read-only evidence bundle (no live system access during audit); third-party pen test conducted on the staging environment first; live production pen testing requires 7-day advance notice and a mutually agreed testing window outside of business hours. Audit access logs maintained separately from operational logs. | Implemented |
Total: 37 organizational (A.5.1–A.5.37) + 8 people (A.6.1–A.6.8) + 14 physical (A.7.1–A.7.14) + 34 technological (A.8.1–A.8.34) = 93 controls. All controls addressed. Sources: ISO/IEC 27002:2022.
ISO/IEC 27017:2015 provides cloud-specific guidance extending ISO 27002. It addresses additional controls for both cloud service providers and cloud service customers. Our sub-processors (Cloudflare, Render, AWS) are cloud service providers; Hive is simultaneously a cloud service customer and a cloud service provider to its own customers. Source: ISO/IEC 27017:2015.
| Control | Title | Our Cloud Posture (Cloudflare + Render + AWS S3) | Status |
|---|---|---|---|
| CLD.6.3.1 | Shared roles & responsibilities | Cloud shared responsibility model documented: Cloudflare, Render, and AWS own physical/network/hypervisor layer; Hive owns the application, data, and access control layer. Responsibility matrix maintained in the DPA and sub-processor register. Customers informed of their responsibilities via the DPA and API documentation. | Implemented |
| CLD.8.1.5 | Removal of cloud service customer assets | Customer data deletion: authenticated DELETE endpoint removes all customer data within 72 hours, including downstream copies in S3. Cryptographic deletion proof endpoint available. On contract termination, automatic deletion trigger fires within 30 days. Deletion confirmation certificate available on request. | Implemented |
| CLD.9.5.1 | Segregation in virtual computing environments | Customer data partitioned by tenant ID at the database schema level; cross-tenant access is technically impossible. Cloudflare Workers use separate namespaces per customer for any edge-stored data. Render services run in isolated container environments per service. No shared memory or storage between tenant contexts. | Implemented |
| CLD.9.5.2 | Virtual machine hardening | Container hardening: Render containers run with minimal base images (Debian slim or Alpine); non-root user enforced; read-only filesystem where possible; no unnecessary packages; health checks configured; resource limits set. Container images rebuilt on every deployment from pinned base image versions. Dependabot monitors base image vulnerabilities. | Implemented |
| CLD.12.1.5 | Administrator operational security | Cloud admin access: Cloudflare, Render, and AWS admin consoles require MFA; hardware security key for elevated operations; admin sessions logged; no standing access to production databases via console. All admin actions via console are logged by the respective cloud provider. Hive admin access matrix reviewed quarterly. | Implemented |
| CLD.12.4.5 | Monitoring of cloud services | Cloud service monitoring: Cloudflare analytics for edge traffic; Render metrics for CPU/memory/request rates; AWS S3 access logs enabled; all logs exported to centralized store. Anomaly alerts on: traffic spikes, error rate increases, unusual S3 access patterns. Status page integration with sub-processor status feeds. | Implemented |
| CLD.13.1.4 | Alignment of security management for virtual and physical networks | Virtual network security aligned with physical network principles: TLS 1.3 required for all inter-service communication; no plaintext traffic between Cloudflare edge and Render origin; Render private network used for internal service communication; S3 bucket policies restrict access to specific IAM roles only; no public S3 bucket ACLs. | Implemented |
| CLD.6.3.1 (CSP) | Information security policy for cloud services | Cloud service policy document maintained: approved cloud providers enumerated, data classification requirements per provider, exit/migration procedures documented, encryption-at-rest requirements per provider. Policy reviewed annually. Cloud shadow-IT prohibited. | Implemented |
ISO/IEC 27701 extends ISO 27001 and ISO 27002 to cover privacy management (PIMS). It addresses both processors and controllers. Hive acts as a processor for customer data and as a controller for its own operational data. Source: ISO/IEC 27701:2019.
We collect only the PII necessary for the stated processing purpose. Customer DPA specifies permitted purposes. No secondary use of PII without explicit consent or legal basis. Hive's own operational PII (contact details, billing info) processed only for the documented business purposes stated in the Privacy Policy at /privacy.html.
GDPR and CCPA rights supported: access, rectification, erasure, restriction, portability, objection. Rights requests processed within 30 days (GDPR) or 45 days (CCPA). Data subject rights endpoints documented at /privacy.html. Requests can be submitted via [email protected].
Hive acts as a processor for customer data under the customer DPA. Hive does not process customer PII beyond the scope of the DPA. Hive acts as a controller for operational data (employee/contractor contacts, billing information). The distinction is documented in the DPA and privacy notice. Sub-processors are engaged only as processors under a sub-processor DPA.
Platform default: hashes only. The platform stores cryptographic digests of agent operations, not the underlying payload, unless the customer DPA explicitly enables PII storage. Zero PII in operational logs by default. Sentry PII scrubbing active. This satisfies the 27701 requirement for privacy by default and privacy by design.
All sub-processors engaged under sub-processor DPAs that flow down the privacy obligations from the customer DPA. Cloudflare, Render, Stripe, and Mercury DPAs reviewed for GDPR adequacy. Sub-processor changes notified to customers with 30-day advance notice, allowing customers to object.
Privacy impact assessment (PIA) conducted for all new features that involve personal data processing. PIA checklist embedded in the feature development PR template. High-risk processing activities trigger a full DPIA before deployment. PIA records maintained in the internal compliance log.
ISO/IEC 27036-2:2022 provides guidance on security requirements for ICT supplier relationships. Our sub-processor management program aligns to 27036 principles. Full sub-processor table: /security/#sub-processors.
All sub-processors publicly listed at /security/ with purpose, region, and compliance link. The list is updated when any sub-processor is added, removed, or materially changed. Customer notification 30 days in advance of changes.
Each sub-processor assessed annually: SOC 2 Type 2 or ISO 27001 certification currency verified; breach history reviewed; service-level SLA evaluated against our RTO/RPO requirements; data residency compliance checked.
Sub-processor DPAs require: breach notification within 72 hours; audit rights via their own third-party certifications; data deletion on contract termination; sub-sub-processor change notification; liability for security failures.
ISO/IEC 42001:2023 is the international standard for AI management systems (AIMS), published December 2023. It covers AI governance, risk management, and the responsible development and use of AI systems. Source: ISO/IEC 42001:2023.
The Hive platform uses a council-of-models pattern: multiple LLMs (R3/R4/R5/R6 provenance tiers) contribute to output generation. No single model has unilateral authority over a briefing or receipt. This architecture aligns to 42001’s requirement for AI system governance and human oversight. Model selection and output scoring is auditable per receipt.
Every AI-generated output carries a provenance score (R3=sourced, R4=synthesized, R5=inferred, R6=novel). This addresses 42001’s requirement for transparency in AI outputs and risk classification. Customers can filter outputs by provenance tier. The score is cryptographically signed into the receipt and immutable after issuance.
Each receipt includes the model IDs that contributed to the output, allowing customers to evaluate the AI supply chain. This aligns to 42001’s transparency and explainability requirements. Model selection criteria documented in the platform API reference. Model providers’ own usage policies and safety frameworks are incorporated by reference.
Outputs in the Restricted classification (per our data classification scheme) require human review before release from the platform. This satisfies 42001’s human oversight requirement for high-risk AI outputs. The review gate is logged in the audit trail. Full 42001 certification is on the roadmap alongside ISO 27001 in 2027.
ISO 27001 is the floor. The controls below go beyond what any ISO 27001 certification requires. We publish them because they are real, verifiable, and material to sophisticated buyers evaluating cryptographic infrastructure.
We ship a hybrid Ed25519 + ML-DSA-65 signature scheme today. ISO 27002 control A.8.24 references cryptographic policies but does not require post-quantum migration timelines or hybrid scheme deployment. FIPS 204 (ML-DSA, finalized August 2024) is the NIST standard our ML-DSA-65 implementation aligns to.
ISO 27001:2022 was published before the NIST PQC standards were finalized. A.8.24 requires a cryptography policy and key management but does not mandate algorithm agility or post-quantum readiness. No certification body audits PQ migration.
Ed25519 classical signature issued in parallel with ML-DSA-65 lattice-based signature on every receipt. Both signatures must verify for the receipt to be accepted by the Hive verifier. Hybrid scheme is a zero-downtime migration path. Implementation: /hive-pq.html.
curl https://thehiveryiq.com/hive-pq.html — ACVP self-test results published on every deployment. NIST FIPS 204 reference: csrc.nist.gov/pubs/fips/204/final.
We publish a full list of every cryptographic algorithm in production with rotation cadence. ISO 27002 A.8.24 requires a cryptography policy but does not require public disclosure of specific algorithms or rotation schedules.
ISO 27001 treats algorithm selection as an internal policy matter. Buyers cannot verify cryptographic choices from a certificate alone. Publishing the algorithm list gives sophisticated buyers the ability to evaluate our crypto stack against their own requirements without waiting for an NDA.
Signing: Ed25519 (classical) + ML-DSA-65 (FIPS 204). Transport: TLS 1.3 with ECDHE key exchange (X25519). At-rest encryption: AES-256-GCM. HMAC: HMAC-SHA-256. Hash: SHA-256/SHA-384. Key derivation: HKDF-SHA-256. Rotation cadence: signing keys 90 days, TLS certs 90 days (auto via Cloudflare).
Inspect any Hive receipt: the algorithm identifiers are embedded in the receipt header. NIST ACVP results at /hive-pq.html confirm algorithm compliance on every deployment.
The Wave-Lattice entropy substrate sources randomness from physical phenomena quantified as 18 cosmic axes (including Axis 17: soil microbial field entropy). Entropy provenance is documented to NIST SP 800-90B standards. ISO 27001 has no entropy-substrate criterion.
ISO 27002 A.8.24 mentions random number generation in passing but does not define entropy source requirements, minimum entropy bit strength, or require entropy provenance documentation. NIST SP 800-90B fills this gap.
18 cosmic axes feed the Wave-Lattice entropy pool. Axis 17 (soil microbial field) provides biological randomness input. Entropy pool health is monitored on every signing operation. Min-entropy measured and logged. See detailed breakdown at /loess-lattice/axis-17-soil-microbial/.
Entropy provenance is embedded in the Wave-Lattice receipt metadata. NIST SP 800-90B reference: csrc.nist.gov/sp/800-90b/final.
Customers can verify Hive receipt signatures using our open-source Cloudflare Workers verifier, running entirely off Hive’s infrastructure. ISO 27001 has no analog for customer-independently verifiable cryptographic proofs.
ISO 27001 addresses internal controls. It does not require that customers have independent verification capability. Our verifier architecture means a customer can verify receipt authenticity even if Hive’s own infrastructure is unavailable or compromised.
Cloudflare Workers-based verifier at /verifier/. Verifier code is open-source and deployable by the customer to their own Cloudflare account. Verification requires only the receipt JSON and the public key (published in the well-known endpoint).
curl https://thehiveryiq.com/.well-known/hive-public-key.json returns the current Ed25519 + ML-DSA-65 public keys. Verifier source available at /verifier/.
Supply-chain Levels for Software Artifacts (SLSA) Level 3 provides cryptographic build provenance: every release binary is signed with a build provenance attestation proving it was built from a specific commit in a hermetic build environment. ISO 27001 covers change management (A.8.32) but not cryptographic build attestation.
ISO 27001 A.8.32 requires change management but does not require cryptographic proof of build origin. SLSA 3 attestations allow a customer to verify that a deployed artifact was built from a specific, auditable source commit — ISO certification cannot provide this guarantee.
Currently at SLSA Level 1 via GitHub Actions provenance (automated build, version-controlled build scripts). SLSA Level 3 (hermetic, isolated build environment with cryptographic attestation) is targeted for Q4 2026. This is an aspirational control; current state is Level 1.
GitHub Actions build logs are publicly auditable for each release. SLSA Level 3 attestations will be published at the release endpoint when Level 3 is achieved. SLSA specification: slsa.dev/spec/v1.0/. Status: Planned Q4 2026
We commit to publishing post-mortems for Severity 1 incidents within 5 business days, including root cause, timeline, and corrective actions. ISO 27001 A.8.16 requires logging; A.5.27 requires learning from incidents. Neither requires public disclosure of incident details.
ISO 27001 is an internal management system standard. Certification does not require public transparency about incidents. We believe public post-mortems are a trust-building mechanism that goes beyond what any certification requires. This also satisfies our customers’ supply chain security review needs.
Sev 1 post-mortems published at status.thehiveryiq.com within 5 business days. Post-mortem includes: timeline, root cause, blast radius, corrective actions, and control updates. Sev 2 post-mortems available on request. Customer-facing summary published simultaneously with internal post-mortem.
Post-mortems archived at status.thehiveryiq.com. Incident history public. Subscribe for real-time alerts at the status page.
Payment receipts and transaction attestations are anchored to the Base blockchain (Chain ID 8453). The on-chain anchor provides an immutable, independently verifiable timestamp and hash of the transaction record that no party (including Hive) can alter retroactively.
ISO 27001 covers logging and record protection (A.8.15, A.5.33) but does not contemplate blockchain-based immutability. On-chain attestation provides a level of tamper-evidence that no internal logging system (however well controlled) can provide, because the proof is distributed across thousands of independent nodes.
Receipt hash + timestamp posted to Base 8453 on every commercial transaction. Treasury wallet: 0x15184Bf50B3d3F52b60434f8942b7D52F2eB436E. On-chain record is the canonical record of settlement; the off-chain receipt is an attestation artifact referencing the on-chain anchor.
Any receipt can be verified against the Base 8453 chain via Basescan: basescan.org. The receipt JSON includes the transaction hash for lookup.
After a deletion request, customers receive a cryptographically signed deletion certificate: a signed statement that all their data has been deleted, with a timestamp, a list of storage locations cleared, and a signature verifiable against the Hive public key. ISO 27001 A.8.10 requires deletion but does not require a cryptographic deletion proof.
ISO 27001 certification does not provide customers with any independently verifiable proof that their data was deleted. A signed deletion certificate gives customers a court-admissible artifact they can present to their own auditors as evidence of deletion without relying solely on Hive’s word.
Authenticated DELETE to the data deletion endpoint triggers: deletion of all tenant data across primary store + S3 + edge cache (within 72 hours). Completion triggers issuance of a signed deletion certificate (Ed25519 + ML-DSA-65 dual signature) returned to the requesting party and archived in the audit log.
Deletion certificate verifiable using the same open-source verifier as receipt verification: /verifier/. API endpoint documented in the developer reference at /developers.html.
SOC 2 and ISO 27001 do not require FIPS compliance. We document our FIPS posture explicitly because many regulated-sector customers need to evaluate it independently. Status reflects deployed vs. planned vs. not applicable.
| Standard | Name | Our Posture | Status |
|---|---|---|---|
| FIPS 140-3 | Cryptographic Module Validation | KMS-backed key management with hardware security modules. FIPS 140-3 validation for our HSM keying material planned as part of the FedRAMP Moderate preparation in 2027–2028. Currently leveraging Cloudflare’s FIPS 140-3 validated modules at the edge layer. Not yet validated for our own KMS implementation. | Planned 2027 |
| FIPS 203 | ML-KEM (Module-Lattice-Based KEM) | ML-KEM (formerly CRYSTALS-Kyber) for key encapsulation. KEM placeholder tracked in our cryptography roadmap. TLS 1.3 key exchange currently uses X25519 (classical); hybrid X25519 + ML-KEM-768 post-quantum key exchange planned for Q2 2027 as browser/TLS library support matures. NIST FIPS 203 finalized August 2024. | Planned Q2 2027 |
| FIPS 204 | ML-DSA (Module-Lattice-Based DSA) | ML-DSA-65 (formerly CRYSTALS-Dilithium) deployed in production today as part of the Ed25519 + ML-DSA-65 hybrid signing scheme. Every Hive receipt carries both a classical Ed25519 signature and a FIPS 204-aligned ML-DSA-65 signature. NIST ACVP self-test passes on every deployment. NIST FIPS 204 finalized August 2024. | Deployed |
| FIPS 205 | SLH-DSA (SPHINCS+) | SLH-DSA (formerly SPHINCS+) is a stateless hash-based signature scheme that serves as a backup post-quantum algorithm in case lattice-based schemes (ML-DSA) are later found to have weaknesses. Under evaluation as a backup signing algorithm for long-lived attestations where signature size is less critical than algorithm diversity. NIST FIPS 205 finalized August 2024. | Under Evaluation |
| NIST SP 800-90B | Entropy Source Validation | Wave-Lattice entropy substrate validated against SP 800-90B entropy source requirements. Minimum entropy per bit measured and logged. 18 cosmic axes feed the entropy pool, including biological (Axis 17: soil microbial field) and physical sources. Entropy health monitored on every signing operation. Details at /loess-lattice/axis-17-soil-microbial/. | Deployed |
| NIST SP 800-208 | Stateful Hash-Based Signatures (XMSS, LMS) | Stateful hash-based signatures (XMSS, LMS per SP 800-208) require careful state management to avoid catastrophic signature reuse. Not currently adopted. We use SLH-DSA (stateless) as our hash-based backup instead, avoiding the state management complexity. N/A for our current deployment model; will re-evaluate if long-lived root key signing use cases emerge. | N/A |
Customers familiar with SOC 2 Trust Service Criteria can locate the equivalent ISO 27002:2022 controls quickly using this table. Same underlying controls, two frameworks. See the full SOC 2 self-attested posture at /security/soc2-self-attested/.
| SOC 2 Criteria | SOC 2 Topic | ISO 27002:2022 Controls | Notes |
|---|---|---|---|
| CC6.1 | Logical and physical access controls | A.8.2 + A.8.3 + A.5.15 + A.5.16 + A.5.18 | Privileged access, information access restriction, access control policy, identity management, access rights |
| CC6.2 | Prior to issuance of system credentials and prior to user access | A.5.17 + A.5.16 + A.6.1 + A.6.2 | Authentication information management, identity management, screening, terms of employment |
| CC7.4 | Incident response | A.5.24 + A.5.25 + A.5.26 + A.5.27 + A.5.28 | Incident planning, event assessment, incident response, learning from incidents, evidence collection |
| CC8.1 | Change management | A.8.32 + A.8.19 + A.8.25 + A.8.31 | Change management, software installation, secure SDLC, separation of environments |
| CC9.1 | Vendor and business partner risk management | A.5.19 + A.5.20 + A.5.21 + A.5.22 | Supplier information security, supplier agreements, ICT supply chain, supplier monitoring |
| CC5.2 | Cryptographic controls | A.8.24 | Use of cryptography; algorithm policy, key management, rotation cadence |
| A1.2 | Availability – Recovery objectives | A.8.13 + A.8.14 + A.5.29 + A.5.30 | Backup, redundancy, security during disruption, ICT readiness for continuity |
| P4.1 | Privacy – Data subject rights | A.5.34 + ISO 27701 | PII protection mapped to ISO 27701 privacy extensions; data subject rights endpoints |
Evidence available for review under NDA as part of the SOC 2 engagement package or ISO 27001 pre-audit evidence bundle. Request via [email protected]. Cross-links: /security/ controls inventory →/security/soc2-self-attested/ →/security/founder-risk/ →
| Control | Evidence Type | Location / Description | Last Reviewed |
|---|---|---|---|
| A.5.1 | Policy document | Information Security Policy v2.1 — internal GitHub private repo; available under NDA | Q1 2026 |
| A.5.7 | Threat intel log | CISA KEV review log; Dependabot alert closure records — GitHub issue tracker | Monthly |
| A.5.9 | Asset register | Information asset inventory spreadsheet — internal; available under NDA | Q1 2026 |
| A.5.15 | Access matrix | RBAC access control matrix — internal Notion; available under NDA | Q1 2026 |
| A.5.17 | Credential policy | 1Password Teams audit log; KMS key rotation logs — available under NDA | Quarterly |
| A.5.19 | Sub-processor DPAs | Executed DPAs with Cloudflare, Render, Stripe, Mercury, GitHub — available under NDA | Q4 2025 |
| A.5.24 | IR Runbook | Six-phase incident response runbook — published at /security/#incident-response | Q1 2026 |
| A.5.28 | Evidence procedures | Evidence collection SOP — internal; S3 object-lock configuration screenshots available under NDA | Q1 2026 |
| A.5.31 | Legal register | Regulatory requirements register — internal; available under NDA | Q1 2026 |
| A.5.35 | Audit engagement | SOC 2 Type 1 engagement letter — available under mutual NDA to qualified prospects | Q1 2026 |
| A.6.1 | Screening records | Contractor identity verification records — internal; available under NDA | On hire |
| A.6.2 | Contract templates | Standard contractor agreement with IS obligations — available under NDA | Q4 2025 |
| A.6.6 | NDA log | NDA execution log with counterparty and expiration — internal; available under NDA | Q1 2026 |
| A.7.5 | UPS receipt | UPS purchase receipt and test log — available under NDA | Q1 2026 |
| A.7.9 | MDM config | Apple MDM remote wipe configuration — screenshot available under NDA | Q1 2026 |
| A.8.2 | FIDO2 config | Hardware security key enrollment records; admin MFA audit log — available under NDA | Q1 2026 |
| A.8.5 | Auth event log | Google Workspace authentication event log sample — available under NDA | Monthly |
| A.8.7 | AV configuration | Malwarebytes endpoint config + macOS XProtect status — screenshot available under NDA | Q1 2026 |
| A.8.8 | Vuln records | Dependabot alert closure log; CISA KEV review log — available under NDA | Monthly |
| A.8.13 | Backup log | S3 backup manifest; restoration test results — available under NDA | Monthly |
| A.8.15 | Log samples | Structured log sample (PII-free) from Render log drain — available under NDA | Monthly |
| A.8.19 | Deploy records | Render deployment history; GitHub Actions CI/CD run log — partially public in GitHub | Every deploy |
| A.8.21 | HSTS + CSP | HSTS header screenshot; CSP header configuration — publicly verifiable at thehiveryiq.com | Q1 2026 |
| A.8.24 | ACVP results | NIST ACVP self-test results — published at /hive-pq.html; public | Every deploy |
| A.8.25 | SAST results | CodeQL SAST results per PR — GitHub Actions, partially public | Every PR |
| A.8.31 | Env separation | Render staging vs production service configuration — screenshot available under NDA | Q1 2026 |
| B.1 | PQ implementation | Ed25519 + ML-DSA-65 hybrid signing code; ACVP results — /hive-pq.html | Every deploy |
| B.4 | Verifier code | Open-source Cloudflare Workers verifier — /verifier/; public | Q1 2026 |
| B.7 | On-chain anchors | Base 8453 transaction records — publicly verifiable at basescan.org | Per transaction |
| B.8 | Deletion certs | Signed deletion certificate sample — available on request via [email protected] | Per deletion |
These are our genuine targets. We will not represent a certification as complete until the independent body issues the credential.
This page. All 93 Annex A controls documented. Statement of Applicability published. Machine-readable SoA available on request.
SOC 2 Type 1 audit engagement already signed. Type 1 report targeted Q4 2026.
Independent auditor issues SOC 2 Type 1 opinion letter. Available to customers under NDA.
12-month observation period begins after Type 1 report. Type 2 report targeted Q3 2027.
Third-party accredited ISO 27001 certification audit. Target 12-month engagement. Certification body to be selected in 2026.
ISO 27017 (cloud) and ISO 27701 (privacy) extensions certified alongside or shortly after the ISO 27001 certification.
FedRAMP Moderate authorization targeted 2028 for government and regulated-sector deployments. Requires SOC 2 Type 2 and ISO 27001 as prerequisites.
While third-party certification is on the 2027 roadmap, this page is actionable now for procurement and security review purposes.
Use this page as an interim attestation of our control posture until ISO 27001 certification is in hand. Cite the URL in your vendor risk management system with a flag for re-verification in 2027.
Run your own gap analysis against your internal ISO 27001 review requirements using the 93-control table above. The table’s status column and implementation notes provide the detail needed to score each control against your internal framework.
Request specific evidence items from the evidence table above via [email protected] under NDA. Turnaround: 5 business days.
Reference this page in vendor security questionnaires (CAIQ, SIG, custom). We will complete your questionnaire and provide evidence within 5 business days. Contact: [email protected].
Request a machine-readable SoA, schedule a security briefing, or discuss our 2027 certification timeline with the founder directly.
SoA delivered as JSON within 5 business days of request. Certification timeline discussion with Steve Rotzin, founder, within 2 business days.