Security you can check, not just read about.
We build software that makes hazmat compliance provable, so we hold ourselves to the same standard. Here is our security posture — the controls that run continuously, the frameworks we're working toward, and a plain list of the things we do not claim.
Continuous control monitoring
Our security controls aren't a once-a-year checklist. Seventy-nine automated tests run continuously against our live infrastructure, identity provider, code repositories, and endpoints — checking encryption, access, logging, backups, and vulnerability management, and alerting us the moment one of them drifts.
Eight of those tests are not passing today, and we'd rather name them than publish a rounder number. The great majority of what they flag is a single structural limit: we have one engineer, so our pull requests cannot carry an independent approver, and the code-review tests count every one of them. The remainder are open items we are working through — vendor security assessments, two database configuration settings, an account-mapping cleanup, and one load balancer check.
What runs in place of that second reviewer, since we would rather name it than let "one engineer" stand alone: main is a protected branch and the protection applies to administrators too, so no change merges by exception, including ours. A branch has to be up to date with main before it can merge, so the full automated test suite runs against what will actually land rather than against a stale copy, and it has to pass. Automated code scanning runs on every pull request. None of that is the same thing as a second person reading the diff, and we are not presenting it as equivalent — it is what a one-person team can enforce mechanically rather than promise.
Live control status
Our trust center publishes the live status of every monitored control, our security policies, and the subprocessors we rely on — updated continuously, not at our convenience.
View our trust centerWhere we are on SOC 2
We've engaged an audit firm for a SOC 2 Type II examination. We are not SOC 2 certified, and we won't say otherwise until we hold a report.
Concretely: our control set, policies, and evidence are being built and monitored against the SOC 2 Security Trust Services Criteria. No audit has been completed, and no independent auditor has issued an opinion on our controls. We're also building toward NIST SP 800-171 for customers whose contracts require it.
Johanson Group LLP is engaged to perform the examination against the Security criteria. We're going straight to Type II rather than doing a Type I first. A Type I tests how controls were designed on a single date; the security leads we asked told us plainly that it wouldn't tell them much.
Our observation window is live: August 26 through November 24, 2026. A Type II tests how controls actually operated across a period of time, so that window is the report. Fieldwork begins after the window closes, which puts the report realistically in early 2027. We'll say we hold one when we hold one, and not before.
If your procurement process needs a specific artifact, or our current status, ask us — we'd rather tell you exactly where we are than let a badge imply something we haven't earned.
What's actually in place today
- A tamper-evident audit chain you can verify yourself. Every scan is recorded in a SHA-256 hash-chained ledger. The public verifier re-computes the chain in your own browser — you don't have to take our word that a record wasn't altered.
- Encryption in transit and at rest. All traffic is TLS-encrypted. Data at rest is stored on Azure Storage and encrypted by the platform. We do not yet add an application-layer encryption envelope on top of that — it's on the roadmap, and we'd rather say so than round up.
- Two-step verification. TOTP two-step verification is available on every account, and fleet managers can require it across their whole organization.
- Vulnerability management. Continuous dependency and code scanning across our repositories, with findings triaged and tracked to closure.
- Off-site encrypted backups, with restore drills. Backups replicate to an independent off-site provider under a retention policy. Restores are drilled rather than assumed — most recently exercised during our July 2026 infrastructure migration.
- Access control and review. Least-privilege access with a documented quarterly access review and a written deprovisioning runbook covering every system, API key, and integration credential.
- Documented incident response. A written incident response plan and a separate breach notification SOP, with defined severity levels, owners, and regulatory notification timelines.
- Data minimization by design. We collect the driver data hazmat compliance actually requires — name, CDL number, endorsement and expiry — and no more. Our privacy policy lists exactly what's held and why.
- Cyber liability insurance. Carried, including breach response support.
- A published disclosure policy. Our vulnerability disclosure policy sets out how to report an issue, what we prioritize, and our commitment not to pursue good-faith researchers.
What we don't claim
Every vendor's security page tells you what they have. This is the part that's usually missing, and it's the part worth reading.
- Not SOC 2 certified. Readiness is in progress; no audit completed, no report issued.
- Not ISO 27001 certified, not FedRAMP authorized. Neither is in progress today.
- No dedicated security team. HaulGuard AI is a small, founder-led company. That's precisely why we lean on continuous automated monitoring rather than on someone remembering to check.
- No agency endorsement. We are not affiliated with, endorsed by, or certified by DOT, PHMSA, FMCSA, or CVSA.
- Not "tamper-proof." The audit chain is tamper-evident: it makes alteration detectable. It does not make alteration impossible, and we don't market it as though it does.
Questions, or a security review to run?
Send security questionnaires, diligence requests, or vendor-review paperwork to
security@haulguard.ai — or use the
contact form. To report a vulnerability, follow our
vulnerability disclosure policy and put
[security] in the subject line so it doesn't get triaged with general inbound.