Information Security Policy

Hive Bastion LLC · Version 1.0 · Effective 24 June 2026

1. Purpose and Scope

This Public Summary describes, at a high level, how Hive Bastion LLC ("Hive Bastion," "we," "us," or "our") approaches information security across the products, services, and engagements we deliver. It is written for prospective and current customers, their security and procurement teams, and other interested parties who want to understand our security posture before or during an engagement.

This document is the customer-facing summary of our internal master security policy, Information Security Policy (Master). The master policy and the supporting policy set are more detailed and are treated as confidential; we make them available to qualified parties under a mutual non-disclosure agreement (see Section 11).

We have written this summary to be honest about what a security program at our current stage actually looks like. Hive Bastion is a veteran-owned Tennessee LLC. Where a control is fully in place, we say so. Where a control is partially in place or planned, we say that too. We believe that accurate disclosure is itself a form of risk management — and the strongest assurance we can offer a careful reviewer.

Published baseline, not a contract. This Public Summary is a good-faith description of our security program as of the date shown. It is not a contract, a warranty, or a service commitment. Any engagement between Hive Bastion and a customer is governed by a separate signed written agreement between the parties, which controls in the event of any conflict with this summary. Customer-specific security commitments (including service levels, breach-notification timing, and data-handling terms) are set out in that agreement and its addenda, such as our Data Processing Addendum and MSA Security Addendum.

No reliance; no third-party rights. This Summary is provided for general informational purposes. It is not an offer, representation, or warranty, and no person should rely on it as the sole basis for any decision. Prospective and current customers are expected to conduct their own due diligence and, where needed, to request our detailed documentation under NDA (Section 11). This Summary creates no rights enforceable by any person, is not intended to benefit any third party, and is not incorporated into and does not modify any agreement between Hive Bastion and any customer unless that agreement expressly incorporates it in writing. In the event of any conflict between this Summary and a signed agreement, the signed agreement controls. To the maximum extent permitted by applicable law, Hive Bastion's aggregate liability arising out of or relating to this Summary or your access to or use of our Services is limited as set forth in your separate signed agreement (if any) and, where no fees have been paid by you, to one hundred U.S. dollars (US$100). Nothing in this Summary limits or expands either party's liability beyond what a separate signed agreement provides; in the event of any conflict, the signed agreement controls. To the extent permitted by law, Hive Bastion will not be liable for indirect, incidental, consequential, special, exemplary, or punitive damages.


2. How to Read This Summary

For each security domain in Section 4, we present our program in two parts so a reviewer can immediately separate what we commit to from what is on our roadmap:

Label Meaning
Commitment The control we commit to maintain, written in commercially reasonable, "designed to" terms.
Roadmap Planned maturation of the control as the organization grows (for example, formal third-party attestation, automated scanning, and periodic independent testing).

This structure is applied consistently throughout. It reflects our governing principle: we do not assert an unverified control as fully implemented. Detailed current-implementation status and supporting evidence are available to qualified reviewers under NDA (see Section 11).


3. Our Security Philosophy

Three ideas shape everything below:

  1. Data minimization by default. The most reliable way to protect data is not to hold it. Our default architecture is transient pass-through: wherever a workflow allows it, customer and consumer data flows through to the customer's own systems and accounts without being retained by Hive Bastion. We design to store only what an engagement genuinely requires, for only as long as it is required. Specific data flows are confirmed per engagement and recorded in our Data-Flow & Architecture document.
  2. Inherited strong foundations, honestly scoped. We deliberately build on enterprise-grade cloud and platform providers (Google Cloud Platform, Cloudflare, Google Workspace, GitHub, Anthropic) so that our customers inherit the substantial physical, network, and platform security those providers maintain. We are clear about which protections we operate ourselves and which we inherit from a provider. Controls inherited from a provider are subject to the provider's terms; Hive Bastion does not independently warrant provider controls.
  3. Alignment now, certification on the roadmap. Our program is designed to align with recognized frameworks (Section 5). We are candid that alignment is not the same as certification, and we state plainly what we have and have not yet achieved.

4. Security Program by Domain

The following domains summarize our program. Each maps to one or more internal policies (referenced by ID) and to the framework controls in Section 5.

Detailed current-implementation status and supporting evidence for each domain below are provided to qualified reviewers under a mutual non-disclosure agreement (see Section 11). This public summary states our security commitments and roadmap.

4.1 Encryption — In Transit and At Rest

We are designed to protect customer data in transit and at rest using commercially reasonable, industry-standard encryption. Data transmitted over public networks is designed to be protected with current Transport Layer Security (TLS). Data at rest within our cloud environment is designed to be protected using provider-managed encryption.

Roadmap: Formalize a documented encryption standard (approved protocol versions and cipher suites), evaluate customer-managed encryption keys (CMEK) where a customer requires them, and record encryption settings as evidence in our control register.

Maps to: SOC 2 CC6; NIST CSF PR.DS; ISO/IEC 27001:2022 A.8 (Technological); CMMC L1.

4.2 Access Control, MFA, and Least Privilege

Access to systems and data is designed to be granted on a least-privilege, need-to-know basis, protected by strong authentication, and reviewed periodically. We are designed to enable multi-factor authentication (MFA) on accounts and services that support it.

Roadmap: Document a formal access-control matrix and a recurring access-review cadence; adopt centralized identity (SSO) and hardware-backed authenticators as the organization grows. Detailed in Access Control Policy and Password & Credential Policy.

Maps to: SOC 2 CC6.1–CC6.3; NIST CSF PR.AA; ISO/IEC 27001:2022 A.5/A.8; CMMC L1 (AC, IA).

4.3 Logging and Monitoring

We are designed to capture security-relevant logs from our cloud and application environment and to retain them for a commercially reasonable period to support detection and investigation.

Roadmap: Centralized log aggregation, defined alerting rules, and documented review cadence. Detailed in Logging & Monitoring Policy.

Maps to: SOC 2 CC7.2–CC7.3; NIST CSF DE.CM/DE.AE; ISO/IEC 27001:2022 A.8; CMMC L1.

4.4 Incident Response and Breach Notification

We maintain a documented process designed to identify, contain, investigate, and remediate security incidents, and to notify affected customers of a confirmed breach affecting their data without undue delay, and as required by applicable law.

Roadmap: Periodic tabletop testing of the incident-response plan, a defined on-call rotation as the organization grows, and — in our customer contracts — a committed target breach-notification timeframe set out in the applicable Data Processing Addendum and MSA Security Addendum rather than on this public page. Public-page statements about timing are illustrative only and do not themselves create a notification commitment.

Maps to: SOC 2 CC7.3–CC7.5; NIST CSF RS/RC; ISO/IEC 27001:2022 A.5; CMMC L1.

4.5 Vendor and Subprocessor Management

We are designed to engage reputable subprocessors, to limit the data shared with each to what their service requires, and to maintain a current list of the subprocessors that may process customer data.

Roadmap: A formal vendor-risk questionnaire and recurring review cadence, captured in Vendor & Subprocessor Risk Management Policy.

Maps to: SOC 2 CC9.2; NIST CSF GV.SC/ID.RA; ISO/IEC 27001:2022 A.5 (supplier relationships); CMMC L1.

4.6 Secure Development

We are designed to develop and change software using version control, code review proportionate to the change, separation of source from secrets, and a controlled release process.

Roadmap: Automated dependency and container scanning, branch-protection and required-review gates, and periodic third-party penetration testing.

Maps to: SOC 2 CC8.1; NIST CSF PR.PS/ID.RA; ISO/IEC 27001:2022 A.8 (secure development); CMMC L1.

4.7 Data Minimization and Data Handling

We are designed to collect and retain only the data an engagement requires, to handle data according to its classification, and to delete or return data when it is no longer needed. As of the date of this Summary, Hive Bastion does not itself use customer or consumer personal data, or client confidential data, to train, fine-tune, or otherwise improve any AI model.

Roadmap: Per-engagement data-flow diagrams maintained as standing evidence, and an automated retention/deletion workflow.

Maps to: SOC 2 C-series (Confidentiality), P-series (Privacy), PI (Processing Integrity); NIST CSF PR.DS/GV; ISO/IEC 27001:2022 A.5/A.8; CMMC L1.

4.8 Business Continuity, Backup, and Recovery

We are designed to maintain backups of critical systems and data and to be able to restore service within commercially reasonable timeframes following a disruption.

Roadmap: Documented recovery objectives (our primary client-facing service recovery-time target is 8 hours — a design target, not an SLA — with the recovery-point objective documented per the Backup & Restore Policy), scheduled restore tests, and a periodic continuity exercise.

Maps to: SOC 2 A-series (Availability), CC7.4–CC7.5; NIST CSF RC; ISO/IEC 27001:2022 A.5/A.8; CMMC L1.

4.9 Endpoint and Workstation Security

We are designed to protect the endpoints used to deliver our services with current operating systems, host protections, and access controls.

Roadmap: Centralized endpoint management and inventory as the organization grows; see Asset Management Policy.

Maps to: SOC 2 CC6.6–CC6.8; NIST CSF PR.PS/PR.AA; ISO/IEC 27001:2022 A.7/A.8; CMMC L1.


5. Frameworks We Align To — and Our Certification Status

Our security program is designed to align with the following recognized frameworks. We name them so reviewers can map our controls to a common vocabulary.

Framework How we use it
SOC 2 Trust Services Criteria (CC1–CC9, plus Availability, Confidentiality, Processing Integrity, Privacy) Primary organizing structure for our control set.
NIST CSF 2.0 (Govern, Identify, Protect, Detect, Respond, Recover) Functional view of our program maturity and gaps.
ISO/IEC 27001:2022 (Annex A themes: A.5 Organizational, A.6 People, A.7 Physical, A.8 Technological) Control-theme coverage and policy structure.
CMMC Level 1 (17 practices; FAR 52.204-21) Baseline for safeguarding Federal Contract Information in any government-adjacent engagement.

A complete control-to-framework mapping is maintained internally in Control-Framework Crosswalk, available under NDA.

Certification status — stated plainly. Hive Bastion is NOT currently certified or independently attested under any of the frameworks above. We are aligned to them; we are not yet certified. A SOC 2 Type I examination is on our roadmap and has not been completed. We do not claim to be "compliant," "certified," "audited," or "fully aligned." Veteran-owned status is accurate; an SDVOSB certification is in progress and is not yet active — we make no claim of an active federal certification. We will update this summary as our attestation status changes.


6. Shared Responsibility

Security in any engagement is shared. In general:

The precise allocation for a given engagement is set out in the governing agreement and the Data Processing Addendum.


7. AI-Generated Content Notice

Hive Bastion delivers AI-assisted products and services. The following disclosure applies to AI output we produce and, by extension, to this summary insofar as it was AI-assisted:

This document contains content generated, in whole or in part, by AI systems operated by Hive Bastion LLC, and may contain errors. It is provided for general information and for the reader's independent professional review. It is not, and should not be relied upon as, a regulated determination, underwriting decision, rate quote, or legal, medical, tax, or investment advice. Readers are responsible for independently verifying any factual claim before acting on it. The recipient-specific AI-output disclosure used in our client deliverables appears in those deliverables; this notice governs this public Summary.


8. Subprocessors at a Glance

The providers below may process customer data in connection with our services. This is a summary; the authoritative, current list is Subprocessor List (Public).

Subprocessor Service Region Data Type
Google LLC / Google Cloud Platform Hosting, compute, logging US Operational / customer data
Cloudflare, Inc. DNS, CDN/edge, email routing US Network metadata, inbound email
Anthropic, PBC AI inference (Claude API) US Prompt content (provider terms: not used to train models by default, as of the date of this Summary)
Google Workspace (Google LLC) Business email / productivity US Business communications
GitHub, Inc. (a Microsoft company) Source code hosting US Source code; not intended to contain customer PII

Additional providers, if used, are confirmed by Hive Bastion: Stripe (payments), Bitwarden (secrets), and Twilio/Google Voice (communications).


9. Limitations and Honest Disclaimers

We want careful reviewers to draw accurate conclusions. Accordingly:


10. Updates to This Summary

We expect this summary to mature as our program does. We may update it from time to time to reflect changes in our controls, providers, or certification status. The version and effective date shown above indicate the current edition. Statements in this summary describe our program as of the date shown; configurations change, and a statement true as of that date is not a continuing representation.


11. Requesting the Full Policy Set and Reporting Security Issues

Full internal policy set under NDA. The detailed internal master policy (*) and the supporting policy, evidence, and control documents are available to qualified prospective and current customers and their security teams under a *mutual non-disclosure agreement. To request access, contact us at the address below.

Security inquiries and reports. To ask a security question, request our trust documentation, or report a suspected vulnerability or security issue affecting Hive Bastion or its services:

Coordinated vulnerability disclosure. We welcome good-faith security research. If you believe you have found a vulnerability, please email david@hivebastion.com with sufficient detail to reproduce it and allow us a reasonable period (we target an initial response within five business days and coordinated disclosure thereafter) before any public disclosure. Authorized testing is limited to systems Hive Bastion owns or operates; you must not access, modify, exfiltrate, or store any customer, personal, or confidential data, must not degrade or disrupt service, and must comply with our Acceptable Use Policy and applicable law. This program does not authorize any activity outside that scope, grants no right to compensation or bounty, and confers no waiver of Hive Bastion's legal rights. Out of scope: denial-of-service, social engineering, physical attacks, and testing of third-party providers (report those to the provider).


12. Related Documents

ID Document
Information Security Policy (Master) — internal, available under NDA
Subprocessor List (Public)
Incident Response Plan
Breach Notification Policy
Data Processing Addendum (DPA)
MSA Security Addendum
Vendor Security Whitepaper / Trust Center
Control-Framework Crosswalk
Data-Flow & Architecture