Information Security Policy

ReactionGears LLC

Document Owner Mike Kerr, Founder & Principal Engineer
Version 1.0
Effective Date August 31, 2026
Last Reviewed August 31, 2026
Review Cadence Annually, or upon a material change to systems or services
Contact [email protected]

1. Purpose

This Information Security Policy defines how ReactionGears LLC (“ReactionGears,” “we,” “the Company”) protects the confidentiality, integrity, and availability of information entrusted to us by clients and partners. It documents the administrative, technical, and physical controls we apply to client data, source code, credentials, and the systems used to deliver our services.

2. Scope

This policy applies to:

  • All information and data processed, stored, or transmitted by ReactionGears on behalf of clients.
  • All computing devices, cloud services, accounts, and networks used to conduct Company business.
  • The Company’s Principal (Mike Kerr) and any subcontractor or collaborator engaged on a project. Any such party is required to follow controls equivalent to those in this policy and is bound by written confidentiality obligations before receiving access to client data.

ReactionGears is a single-principal software engineering consultancy. Where this policy references “personnel” or “the team,” it refers to the Principal and any approved subcontractors.

3. Roles and Responsibilities

  • Principal (Mike Kerr): Owns this policy and is responsible for its implementation, review, and enforcement. Acts as the security point of contact, incident responder, and approver for all access and third-party service decisions.
  • Subcontractors / Collaborators (if engaged): Responsible for adhering to this policy, protecting any credentials or data they are granted, and reporting suspected incidents immediately.

4. Data Classification and Handling

ReactionGears classifies information into three tiers and handles each accordingly:

Classification Examples Handling
Confidential Client source code, credentials, API keys, customer PII, business records Encrypted in transit and at rest; access limited to the Principal and, where required, an approved subcontractor; never stored on removable media unencrypted; never posted to public repositories.
Internal Project notes, non-sensitive configuration, internal documentation Stored in access-controlled systems; not shared publicly.
Public Marketing content, published portfolio work May be shared freely.

We collect and retain only the data necessary to deliver contracted services (data minimization). We do not sell client data and do not use client production data for any purpose other than delivering the agreed services.

5. Access Control and Authentication

  • Least privilege: Access to client systems, repositories, and data is granted only as needed to perform the work, and revoked promptly when no longer required or at the end of an engagement.
  • Multi-Factor Authentication (MFA): MFA is enabled on all critical accounts that support it, including email, source control (GitHub), cloud infrastructure, and payment providers.
  • Password management: Strong, unique passwords are generated and stored in a dedicated password manager. Credentials are never reused across services and never stored in plaintext, in code, or in chat/email.
  • Client credentials: When a client provides access, we prefer scoped, revocable credentials (e.g., a dedicated user with limited permissions) over shared administrator accounts. Client credentials are stored only in the password manager and are deleted at the end of the engagement upon request.
  • Session security: Devices lock automatically after a short period of inactivity and require authentication to resume.

6. Endpoint and Device Security

  • All workstations use full-disk encryption (e.g., FileVault on macOS).
  • Operating systems and software are kept current with security patches.
  • Devices are protected by a host firewall and reputable anti-malware protections native to the platform.
  • Automatic screen lock and strong device login credentials are enforced.
  • Devices are not left unattended in unsecured public locations, and lost or stolen devices are treated as a security incident (see Section 12).

7. Network Security

  • Company work is performed over trusted, password-protected networks. Public or untrusted Wi-Fi is avoided for sensitive work or used only with an encrypted tunnel.
  • Administrative access to servers is performed over encrypted channels (SSH) and, where applicable, restricted to a private network (e.g., a Tailscale/WireGuard tailnet) rather than exposed to the public internet.
  • Production servers run host firewalls that restrict inbound access to required ports only.

8. Secure Software Development

  • Secrets management: API keys, tokens, and credentials are kept out of source code and stored in environment variables or a secrets manager. Repositories are scanned to prevent accidental secret commits, and any exposed secret is rotated immediately.
  • Version control: All code is maintained in access-controlled Git repositories. Private client work is kept in private repositories.
  • Dependency hygiene: Third-party dependencies are sourced from reputable registries and monitored for known vulnerabilities; security updates are applied promptly.
  • Data protection in apps: Applications are built with secure defaults — parameterized queries, input validation, output encoding, HTTPS/TLS everywhere, and, for multi-tenant systems, tenant isolation enforced at the database layer (e.g., Postgres Row-Level Security).
  • Environment separation: Development, staging, and production environments are kept separate, with independent credentials. Production data is not copied into lower environments.
  • Change management: Changes are reviewed before deployment, deployed through repeatable pipelines, and can be rolled back if a problem is detected.

9. Encryption

  • In transit: All data transmitted over public networks is encrypted using TLS 1.2 or higher.
  • At rest: Confidential data is stored on encrypted disks and within cloud services that provide encryption at rest.

10. Third-Party Services and Subprocessors

ReactionGears relies on reputable cloud providers to deliver its services. We select vendors that maintain recognized security programs (e.g., SOC 2, ISO 27001) and we review their security posture before entrusting them with client data. Depending on the engagement, subprocessors may include:

Provider Purpose
GitHub Source code hosting and version control
Vercel Application hosting and deployment
Supabase Managed Postgres database, authentication, storage
Amazon Web Services (AWS) Cloud infrastructure and storage
DigitalOcean Cloud servers and hosting
Stripe Payment processing (PCI-DSS compliant)
Google Workspace Email and productivity
A dedicated password manager Credential storage

The specific subprocessors used for a given engagement are limited to those required for that project. A current list can be provided on request. We do not transfer client data to third parties except as necessary to provide the contracted services or as required by law.

11. Backup and Recovery

  • Source code is retained in distributed version control (local and remote copies).
  • Client production data hosted in managed services (e.g., Supabase, AWS) relies on the provider’s automated backup and point-in-time recovery capabilities, configured per project requirements.
  • Critical configuration and credentials are backed up securely within the password manager.
  • Recovery procedures are validated against the provider’s tooling as part of project setup.

12. Incident Response and Breach Notification

ReactionGears maintains a straightforward incident response process appropriate to its size:

  1. Detect & contain: Upon discovering a suspected incident (e.g., unauthorized access, malware, lost device, exposed credential), the Principal immediately works to contain it — revoking or rotating affected credentials, isolating affected systems, and stopping ongoing exposure.
  2. Assess: Determine what data or systems were affected and the potential impact.
  3. Notify: Affected clients are notified without undue delay and no later than 72 hours after confirmation of an incident that may affect their data, with the facts known at that time. Notification timelines and content will also comply with the terms of the applicable client agreement and any legal obligations.
  4. Remediate & review: Fix the root cause, restore normal operations, and update controls to prevent recurrence.

Exposed secrets are rotated immediately as a default response, regardless of confirmed impact.

13. Data Retention and Disposal

  • Client data and credentials are retained only for the duration of the engagement plus any period required by contract or law.
  • Upon completion or termination of an engagement, and upon client request, client credentials and data in our custody are securely deleted, and access is revoked.
  • Electronic data is disposed of using secure deletion; encrypted storage provides an additional layer of protection against recovery.

14. Physical Security

  • Work is performed from a secured private home office or other controlled environment.
  • Devices are physically secured and not left accessible to unauthorized persons.
  • No client data is stored on unencrypted removable media or printed materials beyond what is strictly necessary; any such materials are securely destroyed when no longer needed.

15. Acceptable Use

Company devices and accounts are used for legitimate business purposes. Personnel do not install unvetted software on systems used to access client data, do not disable security controls, and do not use client data outside the scope of the engagement.

16. Business Continuity

As a single-principal firm, ReactionGears relies on cloud-hosted, geographically redundant services for the systems it delivers, so that client-facing applications remain available independent of the Principal’s local availability. Source code and critical credentials are redundantly stored to allow continuity of client projects.

17. Compliance

ReactionGears operates in a manner consistent with applicable data protection expectations, including the principles of the California Consumer Privacy Act (CCPA) and, where relevant to a client’s end users, the General Data Protection Regulation (GDPR). Where a client engagement involves specific regulatory requirements (e.g., HIPAA, PCI-DSS), controls are agreed and documented on a per-project basis. ReactionGears is not currently independently certified against SOC 2 or ISO 27001, but aligns its practices with the control objectives those frameworks describe.

18. Security Awareness

The Principal maintains current knowledge of secure development and operational practices and applies them across all engagements. Any subcontractor is briefed on these requirements before receiving access to client systems or data.

19. Policy Review and Enforcement

This policy is reviewed at least annually and updated when systems, services, or obligations change materially. Failure by any collaborator to follow this policy may result in immediate revocation of access and termination of the engagement.


This document describes the information security practices of ReactionGears LLC and is provided for the purpose of vendor and client due diligence. Specific contractual security terms, where they exist, take precedence over this general policy.

ReactionGears LLC · Yorba Linda, California · [email protected] · www.reactiongears.com