Security & Trust

What actually protects your firm's data on Deadline-Radar, in plain language -- not a compliance-theater checklist. Every claim on this page describes something actually shipped in this product's code, not a policy aspiration.

Data handling

We collect only what the reminder and license-tracking service actually needs to work -- see the full breakdown on our Privacy Policy.

• Scoped by firm. Roster data (staff names, emails, license states, CPE hours, any documents uploaded) is filtered by the requesting firm's own account id on every storage query -- not just checked once at the door.
• Never sold or shared. No third-party data sales, no advertising, no cross-site tracking of any kind (see our cookie disclosure).

Encryption

• HTTPS-only, always. Every connection sends an HTTP Strict-Transport-Security header instructing browsers to never downgrade to plain HTTP.
• Passwords never stored in plain text. Hashed with PBKDF2-HMAC-SHA256 at 100,000 iterations, each with its own random salt -- the standard the U.S. federal government's own NIST password guidance describes.
• Session and login tokens are stored as one-way SHA-256 hashes, not the raw value a stolen database dump could reuse to sign in.
• Uploaded documents (license and CPE certificates) are served back only with Content-Disposition: attachment and X-Content-Type-Options: nosniff on every response, so a maliciously crafted file can never be interpreted as an inline webpage by a browser.

Access control

• Sign-in cookies are marked HttpOnly (invisible to any page script, including a successful XSS payload), Secure (HTTPS-only transmission), and scoped with SameSite.
• Cross-site forgery protection: every request that changes data -- adding staff, editing a record, changing a password -- is checked against the Origin header the browser itself sends, rejected before it reaches the database.
• Rate limiting on every write endpoint -- keyed to your account where one exists, or your IP address for the handful of actions (like signing out) that happen before a session exists -- so a compromised session or a scripting bug can't be abused to hammer the system.
• Independent header layers: Content-Security-Policy, X-Frame-Options, and X-Content-Type-Options on every response, as additional protection against the same class of attack.

Incident response

We're a small, hands-on team, not a large enterprise with a dedicated security operations center -- we won't claim otherwise. What that means in practice:

• A real person reviews this system regularly, and security-relevant code changes go through the same scrutiny as everything else we ship.
• If something ever goes wrong, we will tell affected firms directly and promptly -- not bury it in a changelog.
• We do not currently hold a formal security certification (SOC 2, ISO 27001) or run a paid bug-bounty program. If that changes, this page will say so, not before.

Found something?

If you believe you've found a security issue, email us directly at [email protected] with what you found and how to reproduce it. A real person reads every message here -- see our Contact page for more. Machine-readable contact details are also published at /.well-known/security.txt per RFC 9116.

See also our Privacy Policy and Terms of Service.