Trust
Security
Last updated August 25, 2026
Credentialing runs on a provider's most sensitive identifiers. Their license, their DEA registration, their Social Security number. Before you hand those to a vendor you should know exactly what that vendor holds, who can see it, and what happens when something changes. This page answers that.
Everything described here is in place today. Where we are still building, we say so plainly rather than describing a plan in the present tense.
We do not hold patient records
Credentialing is about the provider, not their patients. Enrolling a clinician with TMHP, CAQH, and the Texas Medicaid MCOs requires the clinician's own credentials and history. It does not require a single patient chart, claim, or encounter record, so none enter the TrueEnroll platform.
This is a deliberate boundary, not an accident of our current stage. It means the credentialing service does not involve protected health information, and it keeps the blast radius of any incident limited to data the provider has already submitted to a payer.
What we hold
Only what a payer application actually asks for:
- • Identity and contact details, including date of birth and Social Security number where TMHP or CAQH requires it
- • NPI, taxonomy and specialty, and practice and billing addresses
- • State license, DEA registration, and board certification details
- • Education, training, and work history
- • Malpractice coverage and claims history
- • Payer enrollment status and correspondence
We do not sell this data, share it for marketing, or send it to any third party except the payer or verification source the enrollment requires.
Controls in place today
Multi-factor authentication is mandatory
Every TrueEnroll staff account requires a time-based one-time code at login, in addition to a password. There is no way to reach a provider record with a password alone, and the requirement cannot be turned off per user.
Every look at a record is logged
An append-only access log records each authenticated request to a provider, credential, review, enrollment, or intake record: which account, what role, which record, what action, when, and from which IP address. The log is written on the request path, so it captures reads, not just edits.
Every field carries its source
This is the product itself, not a bolt-on. Each field on a provider record stores where the value came from, when it was verified, and its current status. Nothing is a bare value with no history behind it.
Every change is attributed
Field changes, review decisions, and approvals are written to an event log with a timestamp and the account responsible. Each event is signed with a keyed hash, so an altered or fabricated entry fails verification, and sequence numbers are audited for gaps. We would rather be precise than impressive here: this makes tampering detectable, not impossible. Someone with direct database access could still delete the most recent entry for a record without leaving a trace, which is why database-level write restrictions are part of the infrastructure work below.
Software drafts, a person approves and submits
Applications are drafted from the verified provider record rather than re-keyed by hand, which is what makes turnaround fast. Nothing is submitted on that basis alone: a named TrueEnroll coordinator reviews the finished application against the source record and submits it themselves. The approval and the submission are both recorded against that person's account, so every filing traces back to a human being.
Backups are encrypted before they leave the server
The daily backup is encrypted on our own infrastructure before upload, so the storage provider only ever holds ciphertext. The encryption keys are deliberately excluded from the archive, so a copy of the backup is not sufficient to read it.
Least privilege by role
Accounts are scoped by role. Providers using the read-only portal can see their own status and nothing else.
Transport and browser hardening
HTTPS is enforced with HSTS across the domain and subdomains. Responses set clickjacking and MIME-sniffing protections.
How we use AI, and where the limits are
We draft applications with AI rather than re-keying them by hand. That is the reason a complete intake becomes a submitted application in 12 to 48 hours instead of days. Because it is a fair question to ask a vendor holding your providers' identifiers, here is exactly how that works.
- • One provider. Anthropic is the only AI provider we use. Your providers' data is not spread across a collection of AI tools.
- • Drafting only. AI produces a draft application from the record you have already given us. It does not decide what is true, and it does not submit anything.
- • A person is always the last step. A named coordinator reads the draft against the source record and submits it under their own account. That approval is logged.
- • No patient data is involved, because none enters the platform at all.
Under Anthropic's commercial API terms, data sent through the API is not used to train their models. If your practice needs that in writing as part of an agreement with us, ask and we will put it in the engagement rather than pointing at a policy page.
What we are still building
We would rather you read this from us than discover it in diligence.
TrueEnroll is moving to infrastructure that adds encryption at rest, a managed database in a private network, and encrypted document storage with defined retention. That migration is underway now. We are not publishing a target date, because we would rather move it when it is genuinely ready than hit a date we announced.
We have not completed a formal third-party audit. We are not SOC 2 certified, and we will say so directly rather than gesture at being “enterprise-grade.” If your practice requires a specific certification before working with a vendor, tell us early and we will be straight with you about whether we can meet it.
If your engagement will eventually involve patient data, through billing or revenue cycle work rather than credentialing, that requires a Business Associate Agreement and infrastructure covered by one. Raise it with us before any patient data moves, and we will tell you honestly where that stands at the time.
Reporting a problem
If you believe you have found a vulnerability or that provider data has been exposed, email contact@trueenroll.com with the details. We will confirm receipt within one business day.
We are a two-person team in the Rio Grande Valley. That means you can reach the people who built the system rather than a support queue, and it means we answer these questions ourselves.
Questions about how your practice's data would be handled? Talk to us and ask directly.