TDR Technology Solutions · Updated 8 September 2026

1. Our commitment

TDR uses the CISA Secure by Design principles to guide product decisions: take ownership of customer security outcomes, be transparent about capabilities and limits, and keep security accountability with company leadership. These principles guide our work; they are not a claim of government certification or third-party conformance.

2. District-controlled data handling

SAM is designed around district-controlled processing, data minimization, least privilege, and human review. Student-identifying content is intended to remain on district-managed systems unless an authorized disclosure is approved under district policy and applicable law. Privacy properties must be verified for the applicable release, configuration, and deployment.

Where required privacy processing is unavailable, the intended design is to stop the outbound workflow. The accuracy and coverage of de-identification remain matters for release testing, deployment validation, monitoring, and human review.

3. Secure development practice

Development practices are derived from NIST SP 800-218, the Secure Software Development Framework. TDR has not claimed a third-party SSDF conformance assessment.

  • Primary application code uses Python, C#, and TypeScript, reducing exposure to common memory-corruption classes. Native dependencies and documented exceptions remain subject to component-level review.
  • Dependencies, authentication, authorization, tenant isolation, input handling, logging, and update behavior are reviewed as part of release assurance.
  • Automated tests and security checks support the review process, but their presence does not by itself prove that a release or deployment is free of vulnerabilities.

4. Component inventories and SBOMs

TDR maintains component inventories and is implementing release-specific software bills of materials. SBOM availability, transitive-dependency completeness, versions, suppliers, licenses, hashes, provenance, and customer distribution are stated only for releases whose records verify those elements. A component inventory or generated file should not be read as a blanket security certification.

5. Access control and human authority

SAM is designed to use least-privilege access and auditable human review. Consequential decisions—including credibility, emergency response, disclosure, investigation, charging, and disposition—remain with authorized school or law-enforcement personnel. Supported identity, MFA, logging, retention, and evidence-control capabilities depend on the verified product release and deployment.

6. Evidence, validation, and transparency

Specific claims about build gates, vulnerability scanning, patch delivery, logging, cryptographic timestamps, evidence integrity, and other controls require release-level implementation and test evidence. TDR distinguishes intended design, implemented capability, deployment verification, and independent assessment rather than treating them as interchangeable.

Current assurance boundary

TDR does not claim blanket FERPA, COPPA, PPRA, New York Education Law 2-d, CJIS, 28 CFR Part 23, NIST SSDF, ADA, or WCAG compliance without an applicable documented assessment. District contracts, configuration, policy, legal authority, and release-specific evidence remain part of deployment review.

Report a vulnerability

See our Vulnerability Disclosure Policy or email security@tdrtechnologysolutions.com. For a concise overview of our public security and privacy position, see Security & Compliance.