Security & Compliance
Compliance is not a feature.
It's the foundation.
Provider data is some of the most sensitive information in healthcare. Every architectural decision, from the database schema to the API gateway, is made against HIPAA, NCQA, URAC and CMS from the start. We are early in our certification journey, and we would rather tell you exactly where we are than let a badge imply something we have not yet earned.
Built into the platform
Certification we are pursuing, not yet held
Framework coverage
Every standard that governs healthcare credentialing
Controls are built into the platform rather than checked at a compliance layer afterwards. Where we hold no certification yet, the card says so.
HIPAA · HITECH
Built toThe Security Rule is implemented in the platform, and a BAA takes effect before any PHI enters the system. HIPAA has no certifying body. It is a posture you maintain and evidence, which is what the audit trail exists for.
- BAA gate enforced at the middleware layer
- Security Rule risk analysis
- Breach notification per 45 CFR § 164.410
- Workforce HIPAA training before PHI access
NCQA · URAC
AlignedCredentialing workflows are structured around NCQA CR standards and URAC accreditation requirements, so an accredited organisation can operate inside them. The accreditation is yours to hold; the platform is built to support it.
- PSV within required timeframes
- Committee decision documentation
- Re-credentialing cycle enforcement
- Evidence export for your surveyors
CMS Interoperability
Built toFHIR R4 APIs built against the CMS Interoperability Rule and the 21st Century Cures Act.
- Patient access API
- Payer-to-payer exchange
- Provider directory endpoints
- No information blocking
OIG / SAM exclusions
AutomatedMandatory monthly checks against OIG LEIE and SAM.gov for every active provider. They cannot be skipped, and they keep running on a past-due account.
- Monthly automated sweeps
- Match alerts within minutes
- Full check history retained
- Supports CMS conditions of participation
SOC 2 Type II
PlannedWe have not completed a SOC 2 audit and have no report to share. We would rather tell you that than imply otherwise. The control set an audit examines is built and running; the independent attestation is what we are working towards.
- Control set implemented
- Continuous control monitoring in place
- Independent audit not yet undertaken
- No report exists. Ask us where we are and we will tell you
HITRUST CSF
PlannedSequenced behind SOC 2. The CSF control mapping is a useful design input today; it is not a certification we hold.
- Control mapping in progress
- Sequenced after SOC 2
- No certification date committed
- Shared responsibility matrix available on request
Technical safeguards
Defence in depth, verified continuously
Encryption
AES-256 at rest with per-tenant AWS KMS keys, never shared across tenants. TLS 1.3 in transit; TLS 1.0/1.1 rejected at the load balancer.
Access control
RBAC enforced at the database layer. MFA mandatory for all platform access with no opt-out.
Audit logging
WORM append-only logs. No UPDATE or DELETE privileges exist for any application role. Six-year retention.
Break-glass
Clarvera staff access to tenant PHI requires break-glass authorisation tied to an open ticket; every access is logged and reported to your admin.
Data residency
PHI stored exclusively in your selected US region. Never transferred internationally.
Testing
Regular penetration testing and continuous vulnerability management across the platform.
Questions from your security team?
We answer security questionnaires, walk your auditors through the audit trail, and share our shared-responsibility matrix and current certification status on request. If you need a SOC 2 report today, we do not have one. Ask us where we are and we will tell you.