The Operations Security Policy governs the secure day-to-day running of botBrains’ production systems. It covers how changes reach production, how botBrains manages capacity and protects systems from malware, how it keeps environments separate, and how clocks stay synchronized.
botBrains is not yet ISO 27001 certified. We are preparing our ISMS and writing these policies as part of pursuing certification, and we fully intend to get our controls attested.
Scope
This policy applies to all production and supporting systems that process, store, or transmit botBrains or customer data, and to both members of the team. Infrastructure runs on AWS, Hetzner, and DigitalOcean, with the full supplier set listed at Subprocessors.
Change management
Code reaches production through GitHub and a CI/CD pipeline. Every change runs through automated tests and dependency scanning before merge, then deploys through the CI/CD pipeline after validation in a separate staging environment. botBrains rolls back failed changes by redeploying the previous known-good version. Database and configuration changes follow the same path.
Known gap: no mandatory second-person review. With our small team, botBrains can’t today enforce a mandatory pull-request review or a second approver on every change, which is a segregation-of-duties and change-approval gap. The compensating controls are CI/CD gates that automatically block merges on failing tests, automated dependency scanning (for example Dependabot), validation in a separate staging environment with monitoring, and post-merge review of changes by the other team member. botBrains will introduce a required-review rule on the production branch as the team grows and tracks this gap for remediation.
Capacity management
botBrains monitors processing and storage capacity through CloudWatch and Better Stack metrics, and queue capacity through Better Stack metrics and alerting. It adjusts cloud resources to keep availability and performance within target. Provider-managed scaling lets botBrains add capacity without a code change. Because the team is small, botBrains treats human capacity and key-person availability as capacity factors themselves and weighs them during risk review under the Risk Management Policy.
Protection from malware
Company laptops run full-disk encryption and the operating system’s built-in malware protection, kept current with automatic updates. Production servers run hardened, minimal Linux images with a reduced service surface, no interactive end users, and network isolation, which is the recognized alternative control where traditional anti-malware adds little value. botBrains treats customer-supplied files as untrusted and scans them with ClamAV on upload, so malicious files can’t be stored or later downloaded by a customer. botBrains runs untrusted code and inputs inside isolated Modal execution sandboxes, kept separate from core infrastructure. Firewalls and spam filtering protect email and ingress. The Incident Management Policy governs how botBrains handles suspected malware.
Separation of environments
botBrains keeps separate local, staging, and production environments. Tests run outside production, and botBrains doesn’t use production customer data in development or testing. botBrains restricts access to production, authenticates it with MFA, and grants it on a least-privilege basis per the Access Control Policy. The Network Security Policy describes network controls for production.
Configuration and software control
botBrains provisions production systems from hardened, version-controlled configuration so that builds stay repeatable and drift stays visible. Installing or changing software on production systems follows the change management process above. The Acceptable Use Policy defines restrictions on what personnel may install on endpoints.
Clock synchronization
All production systems synchronize their clocks to reputable network time sources so that log timestamps line up across services for monitoring and incident investigation.
Logging, backups, and vulnerabilities
The Logging and Monitoring Policy defines event logging and monitoring, the Backup Policy covers backup scope and restore testing, and the Vulnerability Management Policy covers patching and vulnerability handling. This policy doesn’t restate them.
ISO 27001 mapping
This policy supports Annex A 8.6 (capacity management), 8.7 (protection against malware), 8.9 (configuration management), 8.19 (installation of software on operational systems), 8.31 (separation of development, test, and production environments), and 8.32 (change management).
Review
The CISO owns this policy and reviews it at least annually and on any material change to the production architecture or deployment process. 
