Documented Operating Procedures
Effective: March 17, 2026 · DCF-171
1. Purpose
This document establishes the requirement for documented operating procedures for all information processing systems at H33.ai, in accordance with ISO 27001:2022 control A.5.37 and SOC 2 Common Criteria CC8.1. Documented procedures ensure consistent, repeatable, and auditable operations across H33.ai's post-quantum cryptographic infrastructure and supporting systems.
2. Scope
This policy applies to all information processing systems operated by H33.ai, including production infrastructure, development environments, supporting services, and administrative systems. All procedures that affect the confidentiality, integrity, or availability of H33.ai's systems and data must be documented, approved, and maintained.
3. Operating Procedures Index
The following operating procedures are maintained by H33.ai. Each procedure is documented, assigned an owner, stored in an accessible location, and reviewed on a defined schedule.
3.1 System Deployment
| Procedure | Application deployment via GitLab CI/CD to AWS Elastic Beanstalk |
| Owner | Eric Beans, CEO/CISO |
| Location | GitLab internal wiki; Drata procedure library |
| Review Frequency | Annually or after significant infrastructure changes |
| Description | Covers the end-to-end deployment pipeline from GitLab merge request through CI/CD testing, build, and deployment to AWS Elastic Beanstalk production environment. Includes pre-deployment checklist, rollback procedures, and post-deployment verification steps. Graviton4 production deployments use the dedicated deploy script with SSH key-based access. |
3.2 Database Backups
| Procedure | RDS PostgreSQL automated and manual backup management |
| Owner | Eric Beans, CEO/CISO |
| Location | GitLab internal wiki; Drata procedure library |
| Review Frequency | Annually |
| Description | Covers automated daily backups with 7-day retention, point-in-time recovery configuration, manual pre-change snapshots, backup integrity verification (quarterly), and cross-region snapshot procedures. Includes RTO/RPO targets from BIA (DCF-167): RPO 15 minutes, RTO 1 hour. |
3.3 Monitoring and Alerting
| Procedure | DataDog infrastructure monitoring, dashboard management, and alert configuration |
| Owner | Eric Beans, CEO/CISO |
| Location | GitLab internal wiki; Drata procedure library |
| Review Frequency | Quarterly |
| Description | Covers DataDog agent deployment, dashboard configuration for production infrastructure (CPU, memory, network, latency, error rates), alert threshold definitions, escalation paths, and on-call procedures. Includes monitoring of authentication pipeline throughput (target: >2M auth/sec sustained), FHE batch latency, and ML agent health. |
3.4 Incident Response
| Procedure | Security and availability incident detection, response, and recovery |
| Owner | Eric Beans, CEO/CISO |
| Location | Drata incident response plan; GitLab internal wiki |
| Review Frequency | Annually with tabletop exercise |
| Description | Covers incident classification, escalation procedures, communication templates, containment strategies, evidence preservation, root cause analysis, and post-incident review. Includes specific runbooks for cryptographic key compromise, data breach, DDoS, and service outage scenarios. |
3.5 Access Provisioning and Deprovisioning
| Procedure | User access lifecycle management across IAM, GitLab, and Microsoft 365 |
| Owner | Eric Beans, CEO/CISO |
| Location | Drata procedure library |
| Review Frequency | Annually |
| Description | Covers new hire onboarding (account creation, role assignment, MFA enrollment, biometric registration), role changes (access modification with approval), and offboarding (account deactivation within 24 hours of termination, access revocation across all systems, device wipe verification). Includes quarterly access reviews. |
3.6 Change Management
| Procedure | Change control for production systems via GitLab merge requests |
| Owner | Eric Beans, CEO/CISO |
| Location | GitLab internal wiki; Drata procedure library |
| Review Frequency | Annually |
| Description | All production changes require a GitLab merge request with description of change, risk assessment, testing evidence, and approval from an authorized reviewer. Emergency changes follow an expedited process with post-hoc documentation within 24 hours. Change categories: Standard (pre-approved types), Normal (requires approval), Emergency (expedited with post-approval). |
3.7 Key Rotation
| Procedure | Dilithium/Kyber cryptographic key lifecycle and rotation |
| Owner | Eric Beans, CEO/CISO |
| Location | GitLab internal wiki (restricted access); Drata procedure library |
| Review Frequency | Annually |
| Description | Covers generation, distribution, storage, rotation, and destruction of cryptographic keys. Dilithium signing keys and Kyber key exchange parameters follow defined rotation schedules. BFV FHE parameters (N=4096, t=65537, modulus chain) reviewed annually for cryptographic strength. Emergency key rotation procedure for suspected compromise. All key material stored in AWS Secrets Manager. |
3.8 Certificate Management
| Procedure | TLS certificate lifecycle management via AWS Certificate Manager |
| Owner | Eric Beans, CEO/CISO |
| Location | Drata procedure library |
| Review Frequency | Annually |
| Description | Covers certificate issuance, renewal, and revocation using AWS Certificate Manager (ACM) with automatic renewal. Includes certificate inventory, expiration monitoring via DataDog, manual renewal procedures for non-ACM certificates, and emergency certificate replacement for compromised certificates. |
3.9 Patch Management
| Procedure | Dependency updates and vulnerability remediation via Dependabot and cargo audit |
| Owner | Eric Beans, CEO/CISO |
| Location | GitLab internal wiki; Drata procedure library |
| Review Frequency | Quarterly |
| Description | Covers automated dependency scanning (Dependabot for GitLab, cargo-audit for Rust crates), vulnerability triage (Critical: 24 hours, High: 72 hours, Medium: 30 days, Low: 90 days), patch testing in staging, and production deployment. Includes OS-level patching for EC2 instances and container base images. |
4. Procedure Documentation Standards
All operating procedures must include the following elements:
- Title and identifier: Unique name and reference number
- Purpose: Why the procedure exists and what it achieves
- Scope: Systems and personnel covered
- Prerequisites: Required access, tools, and knowledge
- Step-by-step instructions: Detailed, numbered steps that can be followed by any authorized person
- Expected outcomes: What success looks like at each step
- Error handling: What to do when something goes wrong
- Rollback instructions: How to reverse the procedure if needed
- Owner and approver: Who maintains and authorizes the procedure
- Version history: Change log with dates and descriptions
5. Change Control for Procedures
Operating procedures are subject to the following change control requirements:
- All procedure changes must be reviewed and approved by the procedure owner before publication
- Significant changes (new steps, removed steps, changed outcomes) require CISO approval
- Minor changes (formatting, clarification, updated screenshots) may be approved by the procedure owner
- All changes are version-controlled in GitLab or Drata with full audit trail
- Personnel affected by procedure changes are notified within 5 business days
6. Availability and Access
All operating procedures are stored and accessible as follows:
| Primary Location | Drata compliance platform (procedure library) |
| Secondary Location | GitLab internal wiki (version-controlled) |
| Access Control | Available to all authorized H33.ai personnel; restricted procedures (e.g., key rotation) limited to CISO and authorized administrators |
| Offline Access | Critical procedures (incident response, disaster recovery) available in offline format for scenarios where primary systems are unavailable |
7. Review Schedule
This policy and the operating procedures index are reviewed annually, or sooner if:
- Significant changes occur to H33.ai's infrastructure or processes
- An incident reveals a gap in documented procedures
- An audit finding identifies procedure deficiencies
- New regulatory or compliance requirements necessitate procedure updates
Individual procedures follow their own review schedules as defined in Section 3. The next scheduled review of this policy is March 2027.
Questions?
Contact the Security Officer at security@h33.ai or the Compliance team at compliance@h33.ai.
H33.ai, Inc. · 11533 Brighton Knoll Loop, Riverview, FL 33579 · 813-464-0945