Security & Vulnerability Disclosure

TDR Technology Solutions
Effective 13 August 2026 · Updated 19 August 2026

We build software that protects children. If you have found a way to break it, we would
rather hear it from you than from an incident.

Good-faith security research on the products in scope below is authorised under this
policy. You do not need to ask our permission first: test our software — the publicly
reachable services and your own installation of the on-premise components — within the scope
and rules set out here.

We will not sue you, threaten you, or report you to law enforcement for security
research conducted in good faith under this policy. Those terms are set out under
Safe harbour below, and they are a commitment we make to you — not a courtesy we may
withdraw.

How to report

Email security@tdrtechnologysolutions.com.

Please include:

• what you found, and what an attacker could do with it
• the steps to reproduce it — the more precise, the faster we can act
• the product, version, and configuration involved
• anything you think we would otherwise miss

If you need to send sensitive material encrypted, say so in your first message and we will
arrange a secure channel. We would rather set one up on request than publish a key we might
not maintain.

Reports in any language are welcome; our working language is English.

What we will do

We are a small company, and these are commitments we can actually keep rather than numbers
that look good on a page.

For vulnerabilities in software we distribute, we will request a CVE and
credit you in the advisory unless you would rather stay anonymous. Our CVE policy: every
confirmed critical or high-impact vulnerability that requires customer action, or that is
being exploited, receives a CVE record with accurate CWE and CPE fields — issued with the fix
and no later than 45 days after confirmation. After the 90-day window (or
earlier, once a fix is released and we agree the window can close), you may publish your
findings; if we need longer for a hard fix we will ask before the window ends, with the
reason.

If we disagree that something is a vulnerability, we will tell you why rather than going
quiet.

Scope

In scope

• tdrtechnologysolutions.com and its subdomains
• the SAM school agent and SAM cloud services as we distribute them
• the SAM-Voice recorder and connectors
• the LE-Intelligence platform

Out of scope

• Live school deployments. These are operated by school districts, not by
  us, and they contain real student records. Testing against them risks children’s data and
  is not something we can authorise on a district’s behalf. Test against your own instance,
  or ask us for access to a test environment.
• Live law-enforcement deployments, for the same reason under 28 CFR Part 23
  and CJIS.
• Social engineering of TDR staff, school staff, or law-enforcement personnel.
• Physical attacks against any premises.
• Denial-of-service and volumetric testing.
• Third-party services we consume but do not control — report those to their owners.
• Findings from automated scanners with no demonstrated impact.

If you encounter student or personal data

This is the part we ask you to take most seriously. If your testing exposes student records,
personally identifiable information, or law-enforcement data:

1. Stop. Do not continue to probe that path.
2. Do not download, copy, retain, or share it — not as evidence, not in a
   screenshot, not in your report.
3. Tell us immediately, and describe what was exposed without reproducing
   it.

Accessing student records is a FERPA matter, with obligations that fall on us and on the
district. Reporting it promptly is what lets us meet them. A researcher who stops and
reports has our gratitude and the full protection of the safe harbour below — that
protection is not weakened by having stumbled into data, only by continuing after you
knew.

Safe harbour

If you follow this policy, we will treat your research as authorised conduct. Specifically,
we will not initiate or support legal action against you under the Computer Fraud and Abuse
Act, the anti-circumvention provisions of the DMCA, or equivalent state law — and we will say
so in writing to anyone who asks, including if a third party raises a complaint about research
you conducted within this policy.

This protection applies while you:

• stay within the scope above
• access only as much data as is needed to demonstrate the issue, and stop at that point
• do not degrade, disrupt, or damage any system or anyone’s use of it
• do not extort, and do not condition disclosure on payment
• report promptly, and give us a reasonable window before going public

We cannot waive the rights of third parties. If your research reaches a school district’s own
systems or a law-enforcement agency’s, that is outside what we are able to authorise — which
is why live deployments are out of scope.

If you are unsure whether something is in scope, ask first. We would rather
answer a question than argue about it afterwards.

What we do not offer

We do not pay bug bounties. We would rather be straight about that than let
anyone spend serious time expecting one. We do offer public credit, a CVE where applicable,
and a real conversation with the people who wrote the code.

Not a security vulnerability?

Suspected abuse of SAM, a privacy concern, or a question about how we handle student data is
not a security vulnerability, and security@ is not the fastest route. Use the
contact address on this site, or email privacy@ for data-protection matters.

If a child is in immediate danger, contact your local emergency services. Do not wait
for us.

Our Secure by Design roadmap — how we eliminate classes of vulnerability, what we know is still open, and what we are improving next — is published at tdrtechnologysolutions.com/secure-by-design/.