Security & Trust

How does CredentialTrack Pro protect provider data?

Provider credentialing data is protected through layered safeguards: AES-256 encryption at rest for the database, object storage, and backups; TLS 1.2 or higher in transit; column-level field encryption for NPI, DEA, license numbers, SSN, and uploaded ID documents; role-based access control enforced server-side; an append-only audit log of every read, write, and verification event; private-network isolation of the database tier; and annually reviewed sub-processor agreements. These controls map to the administrative, physical, and technical safeguards described in NIST guidance for implementing the HIPAA Security Rule.

Sources: NIST FIPS 197 (Advanced Encryption Standard); NIST SP 800-66 Rev. 2 (Implementing the HIPAA Security Rule).

Controls in production today

• Encryption at rest: AES-256 (FIPS 197) for the primary database, object storage, and automated backups.
• Encryption in transit: TLS 1.2 or higher for every public endpoint; HTTP traffic is redirected to HTTPS.
• Field-level encryption: Sensitive identifiers — NPI, DEA registration, license numbers, Social Security numbers, and uploaded identification documents — are encrypted at the column level above and beyond the disk-level encryption.
• Role-based access control (RBAC): Org owner, admin, coordinator, provider, and auditor roles are enforced server-side on every request. Cross-organization access is structurally impossible.
• Audit logging: Every authentication event, record read, write, verification call, and administrative action is recorded to an append-only audit log.
• Network isolation: Application and database tiers run inside a private network. The database is not reachable from the public internet.
• Vendor management: Sub-processors are bound by data-processing agreements; the list is reviewed at least annually.

Healthcare-specific threat guidance from CISA's Healthcare and Public Health Sector page and the joint HHS / HSCC HHS 405(d) Health Industry Cybersecurity Practices program inform how we prioritize controls for a healthcare workforce platform.

"Hacking and ransomware are the most common types of large breaches reported to OCR. Failure to conduct a HIPAA Security Rule risk analysis leaves health care entities vulnerable to cyberattacks, such as ransomware. Knowing where your ePHI is held and the security measures in place to protect that information is essential for compliance with HIPAA."

Is CredentialTrack Pro HIPAA compliant?

CredentialTrack Pro is designed to align with the administrative, physical, and technical safeguards of the HHS HIPAA Security Rule (45 CFR Part 164, Subpart C), using NIST SP 800-66r2 as the implementation reference. The platform manages provider credentialing records — licenses, NPI, DEA, board certifications, CEU/CME, hospital privileges, payer enrollment, and malpractice coverage — and is not intended for patient PHI such as treatment, diagnosis, or billing records. We will sign a Business Associate Agreement (BAA) with covered entities and business associates that need one for credentialing workflows; email security@credentialtrackpro.com to request a BAA.

Sources: HHS HIPAA Security Rule (45 CFR Part 164, Subpart C); NIST SP 800-66r2.

Is CredentialTrack Pro SOC 2 certified?

Not yet. We operate against the AICPA SOC 2 Trust Services Criteria and are pursuing a SOC 2 Type II attestation, but the audit has not been completed. When the site or footer says "SOC 2 Ready," it means our controls are aligned with the SOC 2 criteria — not that an attestation report has been issued. Our security questionnaire responses, sub-processor list, and current controls overview are available under NDA from security@credentialtrackpro.com.

Sources: AICPA SOC 2 Trust Services Criteria.

How does CredentialTrack Pro align with Texas DPSA / HB 300?

For Texas-based customers, CredentialTrack Pro is built to align with the Texas Medical Records Privacy Act (Tex. Health & Safety Code Ch. 181), often called the Texas DPSA or HB 300, and the broader Texas Data Privacy and Security Act enforced by the Texas Attorney General. This includes employee training on protected health information handling, breach-notification procedures consistent with state timelines, and the access and correction request workflow described in our Privacy Policy.

Sources: Texas Medical Records Privacy Act (Tex. Health & Safety Code Ch. 181); Texas Data Privacy and Security Act (Texas AG).

See our Privacy Policy for the full access and correction request workflow.

How are passwords and MFA handled?

Authentication controls follow NIST SP 800-63B (Digital Identity Guidelines — Authentication). Passwords are never stored in plaintext; we use an adaptive, salted password hash (bcrypt-family) with per-user salts. Minimum length is 8 characters with complexity requirements, and common and breached passwords are rejected at signup. TOTP-based multi-factor authentication (Google Authenticator, 1Password, Authy, and similar) is supported on every account and required for administrative roles. Trusted devices reduce MFA prompts on familiar hardware and can be revoked from account settings. Password reset links are single-use, expire within 60 minutes, and invalidate all existing sessions on use.

Sources: NIST SP 800-63B (Digital Identity Guidelines — Authentication).

At a glance

• Password storage: Passwords are never stored in plaintext. We use an adaptive, salted password hash (bcrypt-family) with per-user salts.
• Password policy: Minimum 8 characters with complexity requirements; common and breached passwords are rejected at signup.
• Multi-factor authentication: TOTP-based MFA (compatible with Google Authenticator, 1Password, Authy, and similar apps) is supported for every account and required for administrative roles.
• Trusted devices: Users may mark devices as trusted to reduce MFA prompts on familiar hardware; trusted devices can be revoked at any time from account settings.
• Password reset: Reset links are single-use, expire within 60 minutes, and invalidate all existing sessions when used.

How are sessions and access tokens managed?

Session controls follow NIST SP 800-63C (Federation and Assertions) and the broader access-management practice in NIST SP 800-63-4. Sessions are bound to HTTP-only, Secure, SameSite cookies and rotated on privilege changes. Idle sessions expire automatically and absolute session lifetime is capped regardless of activity. Users can view active sessions and revoke them from account settings. Cross-site request forgery (CSRF) is mitigated through SameSite cookies and origin checks on state-changing requests.

Sources: NIST SP 800-63C (Federation and Assertions); NIST SP 800-63-4.

At a glance

• Sessions are bound to HTTP-only, Secure, SameSite cookies and rotated on privilege changes.
• Idle sessions expire automatically; absolute session lifetime is capped regardless of activity.
• Users can view active sessions and revoke them from account settings.
• Cross-site request forgery (CSRF) is mitigated through SameSite cookies and origin checks on state-changing requests.

What does the audit log capture?

Audit logging follows the HIPAA Security Rule audit-controls standard (45 CFR § 164.312(b)) and the log-management practices in NIST SP 800-92. The append-only log captures authentication events (login, MFA, password change, session revocation); reads of credential records, document downloads, and exports; creation, update, and deletion of credentials, providers, and organizations; primary source verification calls — NPI registry, OIG/SAM exclusion checks, license boards — with request and response metadata; role changes, invitations, and administrative actions; and billing and subscription changes. Org admins and auditors can review their organization's audit log from the dashboard. Logs are retained for the life of the account and are available on request after account closure for the period required by applicable law.

Sources: NIST SP 800-92 (Guide to Computer Security Log Management).

Captured at minimum

• Authentication events (login, MFA, password change, session revocation)
• Reads of credential records, document downloads, and exports
• Creation, update, and deletion of credentials, providers, and organizations
• Primary source verification (PSV) calls — NPI registry, OIG/SAM exclusion checks, license boards — with request and response metadata
• Role changes, invitations, and administrative actions
• Billing and subscription changes

Where is customer data stored?

Customer data is stored in production infrastructure located in the United States. Automated database backups are encrypted with AES-256 (NIST FIPS 197) and retained in the same region. We do not transfer customer credentialing data outside the United States in the ordinary course of operating the Service.

Sources: NIST FIPS 197 (Advanced Encryption Standard).

How are backups and disaster recovery handled?

Continuity and recovery practices are modeled on NIST SP 800-34 Rev. 1 (Contingency Planning Guide for Federal Information Systems). Automated daily database backups are encrypted at rest and retained for at least 7 days. Point-in-time recovery is available for the primary database within the backup retention window. Recovery procedures are documented and reviewed at least annually.

Sources: NIST SP 800-34 Rev. 1 (Contingency Planning Guide).

At a glance

• Automated daily database backups, encrypted at rest, retained for at least 7 days.
• Point-in-time recovery for the primary database within the backup retention window.
• Recovery procedures are documented and reviewed at least annually.

How does CredentialTrack Pro handle payment data?

All card payments are handled by Stripe, a PCI DSS Level 1 service provider, under the PCI Security Standards Council PCI DSS framework. CredentialTrack Pro never sees or stores raw card numbers; we store only the non-sensitive customer and subscription identifiers Stripe returns. Webhook callbacks from Stripe are verified by signature on every request.

Sources: Stripe security and PCI DSS Level 1 status; PCI Security Standards Council — PCI DSS.

How can I report a security issue?

Our intake process follows the coordinated vulnerability disclosure model described by CISA's Coordinated Vulnerability Disclosure Process. If you believe you have found a security vulnerability in CredentialTrack Pro, email security@credentialtrackpro.com and please do not publicly disclose the issue until we have had a reasonable opportunity to investigate and remediate. We aim to acknowledge reports within two business days. We do not currently operate a paid bug bounty program, but we will publicly credit researchers who report valid issues responsibly, if they wish.

Sources: CISA Coordinated Vulnerability Disclosure Process.

How can you contact CredentialTrack Pro about security?

Questions about this page or our security program may be sent to security@credentialtrackpro.com. Privacy questions go to privacy@credentialtrackpro.com and legal questions go to legal@credentialtrackpro.com. The legal entity is CredentialTrack Pro, Inc.