Information Security and Access Control Policy

Last updated November 8, 2026

Summary: how Ten10 protects the system and your data, who can get in, and what happens if something goes wrong.

1. Data separation between companies

Every company's records are separated in the database with row-level security, designed so the database itself refuses to return one company's rows to another company's session, in addition to the checks in Ten10's code. A limited set of platform processes (for example billing, sign-in and the Ten10 Load Board) work across companies and are restricted to what they need.

2. Encryption

All traffic to Ten10 uses HTTPS (TLS).
Passwords are stored only as salted bcrypt hashes; driver PINs the same way.
Tax ID numbers, bank account numbers, CLABEs and integration passwords and API keys are encrypted in the database with AES-256-GCM.
Card numbers and bank logins for online payments are handled by Stripe and never stored by Ten10.

3. Access control

Each person has their own login; sharing logins is not allowed.
Roles (admin, dispatch, accounting, compliance, broker agent and others) limit what each user can see and change, and company admins can tighten them further.
Two-step sign-in: after the password, every TMS user (and Ten10 Admin) enters a 6-digit code emailed to them. A code works once, for 10 minutes, with limited tries. A user may trust a browser so it skips the code for up to 30 days (7 days for Ten10 Admin); changing the password removes every trusted browser. Keep your email account secure, since sign-in codes go there.
Repeated failed sign-ins lock the login temporarily; sign-in links and password resets expire.
Signing in again is required after a password change.
Ten10 staff can enter a customer's account only through support access the customer approves in the dashboard. It is time-limited, every change is logged and shown to the customer, and the customer can end it at any time.
Ten10 production systems are reachable only by authorized Ten10 personnel, using accounts protected with multi-factor authentication where the provider supports it.

4. Application security

Requests are rate-limited to slow down password guessing and scraping.
Webhooks from payment and ELD providers are verified by signature or shared secret.
Uploaded files are stored under random names and served so they can't run as web pages.
Public links (tracking, carrier packets, portals) use long random tokens and show only what that link is for.
Security headers, input validation and parameterized database queries are used throughout.
Dependencies are kept up to date, and security fixes are prioritized.

5. Logging and monitoring

Ten10 keeps logs of sign-ins, support access and key changes, and monitors for errors and unusual activity.

6. Backups and recovery

The database runs on a managed hosting service with backups. Ten10 maintains procedures to restore service and data after an outage. No system is perfectly secure, and Ten10 does not guarantee that the Service will be free of security incidents.

7. Incident response

If Ten10 suspects a security incident, it will contain it, investigate, fix the cause, and notify affected customers without unreasonable delay and as required by law (including the Texas data breach notification law and the laws of other affected states). Report a security concern to hello@getten10.com with "Security" in the subject.

8. Customer responsibilities

Customers are responsible for their users' passwords and devices, removing users who leave, reviewing who has admin access, and the security of systems they connect to Ten10.

9. Responsible disclosure

Security researchers who find a vulnerability should report it privately to hello@getten10.com and give us reasonable time to fix it. Do not access, change or delete data that isn't yours, run denial-of-service tests, or use social engineering.