Security Policy

OHMIC LABS, INC.
Information Security Policy

This policy describes the technical and organizational security measures maintained by Ohmic Labs, Inc. to protect Customer Data processed through the Ohmic platform.

1. Definitions.
   "Customer Data" means any data that a customer or its authorized users upload, transmit, or otherwise provide to Ohmic through the Service, including battery test protocols, cell and chemistry configurations, fleet operational data, and associated metadata.
   "Service" means the Ohmic cloud-native battery test workflow management platform, including the Protocol Builder, Fleet Manager, Test Plan Builder, Translation Engine, Simulation Engine, and related APIs and user interfaces accessible at ohmic.io.
   "Sub-processor" means any third-party entity engaged by Ohmic to process Customer Data on behalf of a customer in connection with the Service.

2. Scope.
   This Information Security Policy (this "Policy") describes the administrative, technical, and organizational security measures that Ohmic Labs, Inc. ("Ohmic," "we," or "us") maintains to protect the confidentiality, integrity, and availability of Customer Data.

3. Compliance Framework.
   Ohmic maintains SOC 2 Type I certification and is progressing toward SOC 2 Type II certification targeted for Q1 2027. Ohmic's security program aligns with the AICPA Trust Services Criteria for Security, Availability, and Confidentiality. Ohmic is additionally pursuing GDPR compliance to support customers operating in the European Economic Area.

4. Information Security Management Program.

   1. Governance.
      The Chief Technology Officer serves as the designated security lead responsible for establishing, implementing, and maintaining this Policy. Security responsibilities are communicated to all personnel. This Policy is reviewed and updated at least annually or upon material changes to infrastructure, operations, or threat landscape.

   2. Personnel Security.
      Ohmic shall maintain the following personnel security controls:
      (a) Background checks on all personnel with access to Customer Data, to the extent permitted by applicable law.
      (b) Security awareness training upon onboarding and at least annually thereafter, covering secure coding practices, phishing identification, incident response, and data handling.
      (c) Internal acceptable use policies binding all personnel, prohibiting unauthorized access to or disclosure of Customer Data.
      (d) Role-based separation of duties ensuring no single individual has unilateral ability to deploy code to production, modify access controls, or access production databases without appropriate review.

   3. Sub-processor Management.
      Ohmic evaluates the security posture of each Sub-processor prior to engagement and on an ongoing basis. Each Sub-processor is subject to contractual obligations requiring security measures no less protective than those described herein. Current Sub-processors are identified in Section 11.

5. Infrastructure and Network Security.

   1. Hosting Infrastructure.
      The Service is hosted on Railway (PaaS), with database services provided by Supabase (PostgreSQL) and messaging infrastructure provided by Google Cloud Platform. Each provider maintains independent SOC 2 Type II certifications. Ohmic inherits physical security, environmental controls, and infrastructure-level redundancy from these providers.

   2. Network Protection.
      Ohmic maintains the following network security controls:
      (a) Transport Encryption. All data in transit is encrypted using TLS 1.2 or higher, including API traffic, database connections, Pub/Sub message transport, and storage operations. HSTS headers are enforced with a minimum max-age of one year.
      (b) Web Application Firewall. All inbound traffic passes through Cloudflare WAF, providing DDoS mitigation, bot management, and request filtering.
      (c) Outbound-Only On-Premises Architecture. On-premises software communicates with Ohmic's cloud infrastructure exclusively via outbound connections to GCP Pub/Sub. No inbound connections to customer networks are initiated by Ohmic, ensuring customer firewalls need not expose any inbound ports.
      (d) Per-Organization Isolation. Pub/Sub topics and subscriptions are provisioned per-organization with environment-prefixed namespacing. Message filtering ensures each on-premises instance receives only commands for its assigned equipment.
      (e) Security Headers. API responses include X-Content-Type-Options: nosniff, X-Frame-Options: DENY, and Strict-Transport-Security headers to mitigate common attack vectors.

6. Access Control.

   1. Authentication.
      User authentication is managed by Clerk, a SOC 2-compliant identity provider. Ohmic supports the following authentication mechanisms:
      (a) Single Sign-On. Enterprise customers may configure SSO integration through their identity provider.
      (b) Multi-Factor Authentication. MFA is supported for all accounts and required for administrative access to production infrastructure.
      (c) JWT-Based Sessions. All authenticated API requests are validated using cryptographically signed JWTs issued by Clerk and verified on each request.

   2. Authorization and Multi-Tenancy.
      (a) Organization-Scoped Access. All data operations are scoped to the authenticated user's organization. Row-Level Security policies are enforced at the database level to ensure strict tenant isolation.
      (b) Role-Based Access Control. Configurable roles (Administrator, Member) with granular permissions for protocol creation, editing, approval, and publication.
      (c) Approval Workflows. Configurable approval workflows requiring designated approvers to authorize protocol changes before publication.

   3. Administrative Access.
      Access to production infrastructure is restricted on a least-privilege basis, requires MFA, and is logged for audit purposes. Service account credentials are managed through environment-specific secrets and rotated periodically.

7. Data Protection.

   1. Encryption.
      Ohmic maintains encryption in accordance with industry standards:
      (a) In Transit. TLS 1.2 or higher for all communications between customers and the Service and between internal components.
      (b) At Rest. AES-256 encryption for all Customer Data at rest. Supabase and GCP encrypt stored data using platform-managed keys. Secrets are managed through provider-native secret management.

   2. Data Segregation.
      Customer Data is logically segregated at application and database layers via Row-Level Security. On the messaging layer, per-organization Pub/Sub topics ensure fleet command isolation. On-premises data is stored in per-organization GCS buckets with isolated IAM permissions provisioned via Terraform.

   3. Data Retention and Deletion.
      Ohmic retains Customer Data for the duration of the subscription and a reasonable wind-down period. Upon written request following termination, Ohmic will delete Customer Data within the timeframe specified in the DPA, subject to legal retention obligations.

   4. Backup and Recovery.
      Supabase provides automated daily backups with point-in-time recovery. Backups are encrypted at rest and stored in geographically separate locations. Ohmic periodically tests backup restoration procedures.

8. Application Security.

   1. Secure Development Lifecycle.
      Ohmic maintains the following development security controls:
      (a) Code Review. All changes undergo peer review via pull request with branch protection rules requiring at least one approval.
      (b) Automated Testing. CI/CD pipelines via GitHub Actions run unit tests, integration tests, linting, and type checking on every pull request.
      (c) Dependency Management. Third-party dependencies are monitored for vulnerabilities using Dependabot. Critical and high-severity issues are remediated within commercially reasonable timeframes.
      (d) Input Validation. All API endpoints validate input using typed models. File uploads, protocol translations, and simulation inputs are validated against defined schemas.

   2. API Security.
      All API endpoints require authenticated requests bearing valid JWTs. CORS policies permit requests only from authorized origins. Rate limiting and request filtering are applied at the Cloudflare WAF layer.

   3. Architecture.
      The Service is composed of independently deployable microservices with defined API surfaces and isolated deployment contexts, limiting the blast radius of any individual compromise.

9. Logging, Monitoring, and Incident Response.

   1. Logging.
      Ohmic maintains centralized logging and monitoring capabilities:
      (a) Application and infrastructure logs are aggregated in Axiom. Logs capture API requests, authentication events, errors, and system activity.
      (b) Each request is assigned a unique correlation ID propagated across service boundaries for end-to-end traceability.
      (c) PostHog is used for product analytics. No sensitive Customer Data is transmitted to PostHog.

   2. Incident Response.
      Ohmic maintains an incident response plan including:
      (a) Detection. Automated alerting on anomalous activity, error rate spikes, and authentication failures.
      (b) Triage and Containment. Defined severity levels, escalation paths, and a designated security lead coordinating response.
      (c) Notification. Affected customers are notified of confirmed security incidents without undue delay per the applicable DPA and law.
      (d) Post-Incident Review. Root cause analysis and remediation tracking following all material incidents.

10. Business Continuity.
    Ohmic targets commercially reasonable uptime. Cloud infrastructure providers maintain high-availability architectures with automated failover and geographic redundancy. The on-premises software is designed for resilience to intermittent connectivity; commands are durably delivered via Pub/Sub with acknowledgment-based semantics. Ohmic's disaster recovery strategy leverages infrastructure-as-code (Terraform), version-controlled source code, and encrypted database backups.

11. Sub-processors.
    The following Sub-processors are engaged as of the effective date of this Policy. Ohmic will notify customers of material changes per the applicable DPA.