CAIQ-Lite — HailBytes ASM and SAT

Framework: Cloud Security Alliance Consensus Assessments Initiative Questionnaire — Lite (v4.0.2). Last updated: 2026-05-10. Update cadence: Reviewed every release; reissued whenever a control answer changes.

Audience: Enterprise procurement and third-party-risk-management teams who use CAIQ as their first-pass vendor-security questionnaire.

Purpose: Pre-fill the 35 CAIQ-Lite questions honestly. “No” or “Partial” answers point at the BYOC architecture, the in-flight compliance roadmap, or the trust-package artifact that addresses the underlying control. Where a control is partially implemented, the rationale states the dated path to full implementation.

A note on the BYOC effect throughout: many CAIQ questions about “the cloud service provider” are awkward for a BYOC vendor, because the customer’s data plane operates in the customer’s own cloud account. Where the question makes structural sense as “what HailBytes does with the data we process on the customer’s behalf” the answer follows directly. Where the question presumes a multi-tenant SaaS posture, the answer notes the structural difference and points to byoc-architecture.md.

A&A — Audit & Assurance

A&A-01. Are audit assurance plans developed and maintained to address business processes and information processing facilities? Partial. HailBytes maintains a security-evidence package per release (see security-evidence-package.md) covering build, signing, and supply-chain artifacts. SOC 2 Type 1 readiness is underway with auditor selection in progress, kickoff targeted 2026-Q4, and attestation targeted 2027-02-14 per compliance-roadmap.md.

A&A-02. Are audits performed independently and based on risk-based plans and policies? Partial. Internal security review is conducted per release; independent third-party penetration test booking targeted for 2026-Q4 with Astra Pentest, first report targeted 2027-Q1 (covering HailBytes ASM and HailBytes SAT as separate targets, annual cadence thereafter — see compliance-roadmap.md §5). SOC 2 audit will be independent.

A&A-03. Are documented standards, procedures, and policies established for audit assurance plans? Yes for per-release supply-chain assurance; documented in security-evidence-package.md and the CI workflow files (.github/workflows/build.yml, ci.yml) in the product repositories. Internal control documentation is being formalized under the SOC 2 readiness program.

AIS — Application & Interface Security

AIS-01. Are application security policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained? Yes. Coding standards, code review, and CI gates are documented in CONTRIBUTING.md and enforced through GitHub branch protection and required status checks (golangci-lint for SAT, format/test/vet for both, govulncheck, Trivy SARIF, license scan).

AIS-02. Are baseline requirements for security to all organizational information assets identified? Yes for application baseline; documented in the hardening guide (docs/HARDENING_GUIDE.md in the ASM repo) covering Ubuntu 24.04 baseline, SSH hardening, UFW firewall, sysctl, AppArmor, auditd, unattended-upgrades, Fail2Ban.

AIS-03. Are application security capabilities defined for input validation, output encoding, cryptographic operations, and session management? Yes. Django (ASM) and Go standard libraries with crypto/... (SAT) provide the cryptographic primitives. Sessions are server-side, cookies are Secure; HttpOnly; SameSite=Strict. Output encoding follows the framework defaults (Django template auto-escaping; Go html/template).

AIS-04. Are software vulnerability assessments performed? Yes. Trivy (container images) and govulncheck (Go) run on every push to main; SARIF output uploaded to GitHub Security tab; results retained 90 days in CI artifacts, longer in the Trust Pack archive attached to each release. See security-evidence-package.md §1.

BCR — Business Continuity Management & Operational Resilience

BCR-01. Is a documented business continuity plan in place? Yes. See bcp-dr-plan.md — covers HailBytes-side recovery, customer-side continuity, and customer continuity under HailBytes-vanishing scenarios.

BCR-02. Are policies for protection against environmental risks defined and implemented? Not directly applicable. HailBytes operates a small office footprint and does not house customer data on-premises. Production infrastructure runs in major cloud providers’ data centers (AWS, Azure, GitHub) which carry environmental controls per their respective attestations.

BCR-03. Are business continuity and operational resilience strategies tested? Partial. First annual tabletop exercise scheduled 2026-Q3 (see bcp-dr-plan.md §7). Customer-side restore drill documentation is published in the hardening guide.

CCC — Change Control & Configuration Management

CCC-01. Are change management policies and procedures defined and implemented? Yes. All changes flow through GitHub pull requests; required review by at least one engineer other than the author; CI must pass; merge to main is the only path to production.

CCC-02. Are baseline configurations for systems and applications managed and maintained? Yes. Docker-Compose with pinned dependency versions; Packer templates with pinned plugin versions; hardening script for the Ubuntu LTS baseline. Specific version pins refresh with each release and are visible in the Trust Pack archive attached to that release.

CEK — Cryptography, Encryption, and Key Management

CEK-01. Are cryptography, encryption, and key-management policies defined? Yes. TLS 1.3 in transit at the customer’s ingress (nginx termination, modern cipher suites) and TLS to the database within the customer VPC. AES-256-GCM at rest. For SAT, column-level encryption on PII fields (email, name, position). Key material lives in environment variables on the customer’s VM; HailBytes does not hold customer keys.

CEK-02. Are cryptographic keys generated, stored, distributed, used, and destroyed in accordance with documented policy? Yes for HailBytes’ own signing keys (Sigstore keyless via GitHub Actions OIDC; no human-held key). Customer-side key rotation for SAT field-level encryption is documented in the SAT operations guide; a CLI for rotation is provided.

DCS — Datacenter Security

DCS-01. Are datacenter security policies enforced? Not directly applicable to HailBytes-operated infrastructure (customer data plane runs in the customer’s cloud account; cloud-provider datacenters carry their own attestations). For HailBytes’ corporate office and the small footprint of HailBytes-operated infrastructure, controls follow cloud-provider baselines.

DSP — Data Security and Privacy Lifecycle Management

DSP-01. Are data security and privacy policies defined? Yes. See lgpd-compliance.md for the regulatory posture and byoc-architecture.md for the structural data-handling model.

DSP-02. Is data classified according to risk? Yes for HailBytes-processed data (support-ticket contents, billing). For customer-tenant data, the customer is the controller and performs classification.

DSP-03. Are sensitive data inventories maintained? Yes for HailBytes-processed categories; documented in subprocessor-list.md and lgpd-compliance.md. HailBytes does not maintain an inventory of customer-tenant data because HailBytes does not hold it.

DSP-04. Are data handling and protection requirements derived from regulations? Yes; LGPD and GDPR analysis in lgpd-compliance.md. HIPAA, PCI-DSS, FedRAMP, NIST CSF, ISO 27001:2022, CIS v8 IG1/IG2, NYDFS 23 NYCRR 500 control mappings are documented at hailbytes.com/compliance.

GRC — Governance, Risk Management, and Compliance

GRC-01. Is a risk-management framework defined and implemented? Yes. Formal internal risk register maintained (available under NDA to auditors and active procurement reviewers via security@hailbytes.com). Named risks across product/supply-chain, operational, people, compliance, reputational, and financial categories; each with likelihood × impact rating, existing controls, residual rating, named owner, and next-review date. Reviewed quarterly. No risk accepted without a documented control.

GRC-02. Are policies and procedures defined, communicated, and reviewed? Partial. Coding standards, security-disclosure policy (SECURITY.md), and contributor guidelines (CONTRIBUTING.md) are documented in each product repository. Information-security policy as a single named document is under construction under SOC 2 readiness.

HRS — Human Resources Security

HRS-01. Are background verification checks performed? Yes for personnel with elevated production access; documented in the HailBytes employment policy. Contractor relationships are governed by NDA + IP assignment (see subprocessor-list.md §A). Access is revoked within 24 hours of role change or contract end.

HRS-02. Are security awareness and training programs in place? Partial. Security-awareness training (delivered using HailBytes SAT, which HailBytes uses internally) is in place for technical staff; formal frequency and completion-tracking will be documented under SOC 2 readiness.

IAM — Identity & Access Management

IAM-01. Are identity and access management policies and procedures established? Yes. SSO + MFA required for all internal systems with elevated access. RBAC enforced in the products (3 roles × 8 permissions in ASM; role-based access in SAT). Internal production-access map is documented in the key-person succession plan (available under NDA).

IAM-02. Are user-access reviews performed? Partial. Reviewed on personnel changes; formal periodic-review cadence to be documented under SOC 2 readiness.

IAM-03. Are privileged-access controls enforced? Yes. Elevated GitHub access is restricted to named individuals with SSO, MFA, and hardware security keys required. Sigstore signing identity is OIDC-federated to specific GitHub Actions workflows; no individual holds a signing key.

IPY — Interoperability & Portability

IPY-01. Are interoperability and portability standards documented? Yes. The products use open standards: PostgreSQL for storage (data is exportable with pg_dump); REST + JSON APIs documented in the product repositories (ASM: web/api/; SAT: openapi/); standard SARIF, SPDX, CycloneDX for security artifacts; STIX/TAXII and OpenVEX support on the ASM roadmap.

IVS — Infrastructure & Virtualization Security

IVS-01. Are infrastructure and virtualization security policies defined? Yes for HailBytes’ corporate posture; for the customer-deployed product, the customer’s own infrastructure security policies govern. The hardening guide (docs/HARDENING_GUIDE.md) provides recommended baselines.

LOG — Logging and Monitoring

LOG-01. Are logging and monitoring policies defined? Yes. The products log RBAC-relevant events (login, scan create, report generate, campaign create, template publish, etc.). ASM emits ~21 audit-action types; SAT has the comprehensive audit/ package with 5 retention/query/export modules. Outputs can be forwarded to customer-side SIEMs (Splunk HEC, Sentinel, syslog/CEF).

LOG-02. Are logs protected against unauthorized access and modification? Yes. Audit logs live in the customer’s PostgreSQL database with role-based access; production access requires authenticated user.

SEF — Security Incident Management, E-Discovery, & Cloud Forensics

SEF-01. Are security-incident-management policies and procedures defined? Yes. Coordinated disclosure documented in SECURITY.md in both product repositories; security mailing list maintained; incident response runbook is part of the SOC 2 readiness deliverables. Notification commitments under LGPD and GDPR are in lgpd-compliance.md §5 and §13.

SEF-02. Are responsibilities for incident response defined? Yes. See key-person-succession.md §4.

STA — Supply-Chain Management, Transparency, and Accountability

STA-01. Is supply-chain management implemented? Yes. Per-release SBOMs (SPDX + CycloneDX), license reports, Trivy vulnerability scans, govulncheck for SAT, Cosign keyless signing for ASM (SAT signing planned 2026-Q3). See security-evidence-package.md.

STA-02. Is supplier risk management performed? Yes for the limited subprocessor list (subprocessor-list.md §A); all are large, well-audited cloud-platform vendors (GitHub/Microsoft, AWS, Azure, Cloudflare, Google Workspace, Stripe, Anthropic, Sigstore). The HailBytes Support Hub runs on Cloudflare as already in scope.

TVM — Threat & Vulnerability Management

TVM-01. Is a vulnerability-management program in place? Yes. Trivy + govulncheck + go-licenses run on every push; CodeQL SARIF in the GitHub Security tab; coordinated disclosure to security@hailbytes.com with 90-day window documented in SECURITY.md; third-party penetration test booking targeted for 2026-Q4 with Astra Pentest, first report 2027-Q1 (annual cadence thereafter).

TVM-02. Are threat-intelligence sources used? Yes. The product itself integrates threat-intelligence providers as customer-elected integrations (Shodan, Censys, GreyNoise, VirusTotal, AbuseIPDB, MISP, OpenCTI, AlienVault OTX), and HailBytes’ own security function reviews advisories from upstream dependencies (Django, Python, Go, Ubuntu, PostgreSQL, Redis, all tracked via Dependabot).

UEM — Universal Endpoint Management

UEM-01. Are endpoint-security policies in place? Yes for HailBytes corporate endpoints (FileVault / BitLocker, MDM-enrolled, password-manager required, screen lock policy). Customer-tenant endpoints are out of HailBytes’ scope.

Summary statistics for procurement triage

Cross-references: byoc-architecture.md (controls referencing structural data-handling); security-evidence-package.md (controls referencing supply-chain artifacts); compliance-roadmap.md (Partial-status controls with dated remediation); key-person succession plan (incident-response role assignments — available on request to security@hailbytes.com).