Built for compliance-sensitive teams. Every control stated, none claimed that we do not hold.
Security, privacy, and acceptable use are core to the product — not an afterthought. Here is how OffenderSearch handles them: what is encrypted, who can read what, how long each class of data is kept, what is logged, and how to get the subprocessor list.
Authentication, keys & security docs ›or support@offendersearch.app with “Security” in the subject
| Area | Status |
|---|---|
| Transport | TLS on every API and dashboard request |
| At rest | AES-256 for stored customer records, reports and backups |
| API keys | Stored as one-way hashes; shown once at creation |
| Tenant isolation | Every request bound to one account; data scoped per tenant |
| Audit log | Account, key, timestamp and endpoint on every request |
| BAA | Available to eligible accounts; signable in the dashboard |
| Hosting | US-based cloud infrastructure |
| Third-party certification | None claimed; controls walked through under NDA |
Security controls for sex offender and criminal screening data
| Control | Implementation | Evidence available |
|---|---|---|
| Encryption everywhere | TLS in transit, encryption at rest, and hashed API keys shown once at creation. | Config walkthrough under NDA |
| Key lifecycle control | An API key is a pure credential — issue as many as you need, scope them by team or environment, and rotate or revoke any one instantly without touching the others. Regular and Live are chosen per request, not per key. | Dashboard › Keys |
| Enterprise security controls | Audit logging on every request, least-privilege internal access, and per-tenant isolation. | Walkthrough under NDA |
| HIPAA-ready + BAA | A BAA path for enterprise customers whose screening touches protected health workflows. | HIPAA & BAA |
| Acceptable use | Use is subject to our acceptable-use terms and applicable law, accepted at onboarding. | Terms |
| Provenance & audit | Every record carries source provenance with a lastCheckedAt timestamp for a defensible audit trail. | Reports |
| Incident response | An incident-response process for security events; where a BAA is in place, breach-notification timelines and responsibilities are contractual. | BAA |
| Secure development lifecycle | Changes go through code review and automated checks before release; third-party dependencies are monitored for known vulnerabilities. | Described under NDA |
| Encrypted backups & resilience | Platform data is backed up on a regular schedule to encrypted storage, so records and reports can be recovered without exposing data at rest. | Described under NDA |
Acceptable use and FCRA boundaries
Our sex-offender data is derived from publicly available records. Use is subject to our acceptable-use terms and applicable law, accepted at onboarding. See our coverage page.
Standard OffenderSearch results are not a consumer report. FCRA-covered decisions run through FCRA Partner Access, a separately enabled regulated service with its own controls, evidence record and consumer file & dispute process. FCRA checks run as orders: consent and disclosure, the check, dispute handling, adverse action.
How screening data is encrypted and stored
Every request to the API and the dashboard travels over TLS. Data the platform stores, including customer records and generated verification reports, is encrypted at rest with AES-256, and backups are encrypted too.
Each customer’s data is isolated per tenant. A search run under one account is never visible to another, and usage records identify the account and key rather than the people being searched.
| Data class | At rest | In transit | Who can read it |
|---|---|---|---|
| Search inputs (name, DOB, location) | AES-256 | TLS | The account; least-privilege staff for support |
| Results and verification reports | AES-256 | TLS | The account |
| API keys | One-way hash only | TLS | Nobody; the raw key is shown once at creation |
| Usage and audit records | AES-256 | TLS | Account owner (dashboard); staff for billing |
Who can access your account: API keys, teams and roles
- API keys are stored only as hashes and shown in full once, at creation.
- Issue as many keys as you need, one per team, service or environment, and rotate or revoke any key without affecting the others.
- Dashboard users are managed on the Team page, and account-admin actions such as signing the BAA or setting a webhook endpoint require an admin.
- Internal access to production data is least-privilege, granted on a need-to-know basis, and administrative actions are logged.
| Key | Name | Created | State |
|---|---|---|---|
| os_live_…4f2a | Admissions · intake service | 2026-06-02 | active |
| os_live_…91cc | HR · onboarding | 2026-07-19 | active |
| os_live_…0b7e | Engineering · staging | 2026-09-30 | active |
| os_live_…e3d1 | Former vendor integration | 2025-12-11 | revoked |
Illustrative key list, as the dashboard’s Keys page shows it.
Data retention and deletion
Search inputs are kept only as long as needed to answer the request, support you and protect against abuse. On written request from the account owner we delete retained search inputs, subject to any legal obligation to keep them.
Usage and audit records outlast an account because they are the evidence behind an invoice. They identify the account and key, not the individuals searched. The full schedule is in our privacy policy.
| Record | Kept for | Then |
|---|---|---|
| Dashboard search history (inputs and stored results) | 14 days | Erased automatically; earlier on written request |
| API search inputs | As needed to serve, support and prevent abuse | Deleted on written request from the account owner |
| Usage and audit records | Beyond account closure | Retained as billing evidence; identify account and key only |
| FCRA order files (Partner Access) | Per the written FCRA agreement | Governed by that agreement and the dispute process |
What the audit log records for every API key and dashboard user
API requests are logged with account, key, timestamp and endpoint so activity can be reviewed and reconciled. Administrative actions are logged too. Usage is visible to account owners in the dashboard.
| Logged on every request | Why a reviewer wants it |
|---|---|
| Account | Ties every call to one tenant |
| API key | Shows which team, service or environment made the call |
| Timestamp | Reconciles activity with your own intake or HR records |
| Endpoint | Separates registry, criminal and report calls on one invoice |
HIPAA and Business Associate Agreements
Screening a patient or resident by name and date of birth inside a referral workflow involves protected health information. For those workflows a Business Associate Agreement is signed before use, and eligible accounts can sign it in the dashboard. The browser extension for referral platforms requires it.
Read how we handle protected data on HIPAA & BAA.
Accurate matching as a safety control
In screening, the costly mistake is the false positive: the wrong label on the wrong person. Every result is built to show why it matched.
| Control | Field | What a reviewer sees |
|---|---|---|
| Match basis on every record | matchState · matchBasis · matchConfidence | Whether the full date of birth, the birth year, the age or only the name lined up, so a reviewer never acts on a namesake. |
| Per-source status | sourceStatus · counts.sourcesComplete | The registries searched and whether each one answered, so an incomplete search never looks like a clean one. |
| Live re-verification | live | A re-check at named registries at the moment of a decision, billed per source. |
How to run a security review with OffenderSearch
- 01
Email the security topic. Send your questionnaire to support@offendersearch.app with “Security” in the subject.
- 02
We answer directly. A person answers each question in writing, with no automated trust-portal gate.
- 03
Subprocessors and residency. We share the current subprocessor list and data-residency details during procurement or under a BAA.
- 04
Sign what you need. BAA in the dashboard; FCRA Partner Access under a written agreement for regulated screening.
Subprocessors and data residency for screening data US-hosted, with the list shared under procurement or a BAA.
All production data is hosted on US-based cloud infrastructure, encrypted in transit and at rest. We keep the subprocessors that handle data on our behalf to a minimum, and share the current list and data-residency details during procurement or under a BAA.
Questions about a specific subprocessor: support@offendersearch.app, subject “Security — subprocessors”.
Security and compliance FAQ
Is OffenderSearch HIPAA-compliant?
How is screening data encrypted?
Can you complete our security questionnaire?
Where is data hosted?
How long do you keep search inputs?
Can we restrict access by team?
Can the data be used for hiring or tenant decisions?
Ready to talk compliance?
Request a BAA or get our security posture in front of your procurement team. A person answers; nothing is gated behind a portal.