Security Overview

ByteMechanix LLC builds compliance and security software for K-12 schools and managed service partners. Security is core to our work and a foundation of customer trust. This Security Overview describes the safeguards, practices, and program elements that protect ByteMechanix systems and customer data. It is a public summary; detailed control descriptions are available under NDA as part of our customer trust package.

1. Security Program #

ByteMechanix maintains a written information security program governed by the policies in our internal policy library (BMX-POL-001 through 009), including:

• Information Security Policy
• Access Control Policy
• Acceptable Use Policy
• Risk Management Policy
• Incident Response Policy
• Data Retention Policy
• Vendor Management Policy
• Business Continuity and Disaster Recovery Policy
• Change Management Policy

The program is reviewed at least annually and following material changes to the business, infrastructure, or threat landscape.

ByteMechanix is undergoing SOC 2 Type II readiness with automated evidence collection across access reviews, change management, vendor reviews, and security training. Customers may request the current readiness status under NDA.

2. Infrastructure Security #

Hosting: ByteMechanix Services run on hardened Linux virtual servers operated through reputable cloud infrastructure providers, with data centers maintaining SOC 2, ISO 27001, or equivalent third-party attestations.

Network controls: production hosts are protected by host-level firewalls (UFW or equivalent), fail2ban for brute-force protection, and segmentation between production, staging, and management networks. Administrative access requires SSH key authentication; password authentication is disabled.

TLS: all customer-facing endpoints enforce TLS 1.2 or higher with modern cipher suites. Certificates are managed through automated renewal (Let's Encrypt / certbot) with monitoring for expiration.

Hardening: servers run minimal required services, are patched regularly, and receive security updates within defined SLAs based on severity.

3. Data Protection #

Encryption in transit: TLS 1.2+ for all customer connections; mutual TLS or VPN for select internal services.

Encryption at rest: customer data is encrypted at rest using AES-256 or equivalent, with key management handled by the underlying cloud platform's KMS or equivalent service.

Database security: databases are not exposed to the public internet; access is restricted to application servers and authorized administrators through firewall rules and SSH tunneling.

Backups: automated daily backups with retention aligned to our Data Retention Policy. Backup restoration is tested at least annually as part of our DR exercises.

Data segregation: multi-tenant Services maintain logical separation through application-level controls (organization scoping, row-level security) and authenticated subdomain isolation where applicable.

4. Access Control #

Identity: access to production systems is limited to authorized ByteMechanix personnel and authorized contractors under written agreement.

Authentication: SSH key-based authentication for server access; multi-factor authentication for administrative consoles, source code repositories, and cloud provider accounts.

Authorization: role-based access control following least privilege. Production database access is logged and limited to defined operational roles.

Joiner / mover / leaver: access provisioning and deprovisioning are tied to formal onboarding and offboarding processes. Access reviews are conducted at least quarterly.

Customer-side access: ByteMechanix products support role-based access controls (administrator, manager, end user) so that customers can apply least privilege within their own organizations. Single sign-on through Google Workspace and Microsoft Entra ID is available on supported plans.

5. Application Security #

Secure development: ByteMechanix follows secure coding practices including parameterized queries, input validation, output encoding, and use of vetted authentication libraries (such as bcrypt for password hashing and JWT for stateless authentication).

Dependencies: third-party libraries are tracked, monitored for known vulnerabilities, and updated according to severity-based SLAs.

Code review: material changes to production code go through peer review before merge. Changes are tracked in source control with full history.

Change management: production deployments follow defined change procedures with rollback plans. Smoke tests and pre-deployment checklists are run for material releases.

Testing: unit and integration tests cover critical authentication, authorization, billing, and data-handling paths. Security-relevant code paths receive additional review.

6. Logging and Monitoring #

ByteMechanix maintains logs covering:

• Authentication events (success and failure)
• Administrative actions
• Application errors and exceptions
• Network and host-level security events

Logs are retained according to our Data Retention Policy and are reviewed for anomalies. Critical security events generate alerts to the on-call operator.

7. Vulnerability Management #

• Patching: operating systems, runtimes, and dependencies are patched on a defined cadence based on severity (critical: 7 days; high: 30 days; medium: 60 days; low: best effort).
• Scanning: infrastructure and application dependency scanning is performed regularly.
• Penetration testing: ByteMechanix engages or participates in independent security assessments as part of our SOC 2 readiness program. Summary results may be shared with customers under NDA.
• Responsible disclosure: security researchers may report vulnerabilities to security@bytemechanix.co. We commit to acknowledge reports within 5 business days and to work in good faith with researchers acting in good faith.

8. Incident Response #

ByteMechanix maintains a documented Incident Response Policy with defined roles, escalation paths, and customer notification timelines. In the event of a confirmed security incident affecting customer data:

• We will contain and investigate the incident
• We will notify affected customers without undue delay, consistent with the timelines set in the DPA and applicable law
• We will provide reasonable cooperation with customer investigations and regulatory notifications
• We will conduct a post-incident review and apply lessons learned to our controls

9. Business Continuity and Disaster Recovery #

• Backup strategy: daily automated backups with offsite or cross-region storage
• Recovery objectives: target Recovery Time Objective (RTO) of 24 hours and Recovery Point Objective (RPO) of 24 hours for production Services; specific commitments may be set in customer agreements
• DR testing: restoration is tested at least annually
• Redundancy: critical Services are designed to recover from single-host failures through documented runbooks and snapshot-based recovery

10. Personnel Security #

• Background checks for personnel with access to production systems, where permitted by law
• Confidentiality and IP assignment agreements signed by all personnel and contractors
• Annual security awareness training covering phishing, social engineering, password hygiene, and incident reporting
• Defined offboarding procedures with credential revocation and equipment return

11. Vendor and Subprocessor Management #

Subprocessors with access to customer data are evaluated for security posture before onboarding and reviewed at least annually. A current subprocessor list is published at bytemechanix.co/subprocessors. Material additions are communicated to customers in accordance with the DPA.

12. Compliance and Frameworks #

• SOC 2: active readiness program with automated evidence collection
• FERPA: ByteMechanix supports K-12 customers in meeting their FERPA obligations as detailed in our FERPA Notice and DPA
• State student privacy laws: addressed through the DPA and applicable addenda
• GDPR / UK GDPR: Standard Contractual Clauses and other transfer mechanisms available where required

ByteMechanix is not itself a HIPAA-covered entity and Services are not designed for processing protected health information. Customers should not submit PHI to the Services without a separately negotiated agreement.

13. Customer Responsibilities (Shared Responsibility) #

Security is shared. Customers are responsible for:

• Provisioning and deprovisioning end users within the Service
• Configuring role-based access controls appropriately
• Choosing strong authentication (SSO and MFA on supported plans)
• Reviewing audit logs available within the Service
• Notifying ByteMechanix of suspected unauthorized access to customer accounts

14. Transparency and Documentation #

The following documents make up the ByteMechanix customer trust package:

• This Security Overview (BMX-LEG-SEC-001)
• Privacy Policy (BMX-LEG-PRIV-001)
• Terms of Service (BMX-LEG-TOS-001)
• FERPA Notice (BMX-LEG-FERPA-001)
• Data Processing Addendum (BMX-LEG-001), including the FERPA addendum
• Subprocessor list (bytemechanix.co/subprocessors)
• SOC 2 readiness summary (available under NDA)

15. Contact #

Security incidents and vulnerability reports: security@bytemechanix.co Privacy and FERPA: privacy@bytemechanix.co General trust and compliance inquiries: trust@bytemechanix.co Mailing address: ByteMechanix LLC, [Registered Texas Address]