Credalyst starts from public evidence, raises authority with sensitivity, and separates public, customer, operator, and Recovery contexts. Here we distinguish implemented controls, contractual duties, shared responsibility, and limits that still require verification.
Inspectable trust boundary
The public surface begins with the minimum data. Identity, organization scope, and authority enter only when the workflow requires them.
The access model
The first organizational read should not require the broadest possible access. Each additional boundary exists because the data, workflow, or authority has changed.
What may enter and through which channel.
Public paths begin with published records and limited business contact data. Sensitive evidence belongs only in a separately authorized intake—not a public form, analytics event, or navigation question.
Who may enter, which organization resolves, and who decides.
Protected customer access uses signed, time-bounded sessions and single-use access challenges. The server validates the session again when protected work is requested.
The organization and role come from trusted session context, not an untrusted browser header. Customer-facing access is scoped to the resolved tenant, and undeclared access fails closed.
Server-side role rules and explicit approval boundaries govern protected actions. Recommendations and model output cannot expand a person’s authority or silently execute a customer decision.
Where handling, lifecycle, traceability, and assurance limits become explicit.
Recovery can involve sensitive invoice evidence. Qualification, authority, provider terms, retention, and handling requirements are established before intake.
Authentication outcomes, access denials, cross-tenant operator activity, and governed changes have structured audit paths. Credalyst does not claim that every read or every system event is captured until that coverage is verified.
Data classes and legal holds inform retention. Customer deletion workflows exist for governed evidence, but Credalyst does not claim a universal scheduled purge or universal backup guarantee without deployment-specific proof.
No certification, penetration-test result, audit opinion, regulatory status, or third-party attestation is presented unless it is current, earned, and available for the relevant review.
hello@credalysthealth.comControls reduce risk; they do not make any system perfectly secure. Scope, customer configuration, vendors, people, and deployment conditions remain part of the security result.
The data boundary
These are the facts as they stand in the codebase today — what enters, what cannot, who touches it, and how it moves. Each claim stops where inspectable evidence stops.
Facility records are built from published CMS datasets pulled from data.cms.gov. Business contact details — name, work email, organization, role — arrive only when someone submits an inquiry. The public contact form is not a secure file room: do not send invoice files, credentials, protected health information, or other sensitive records through it.
Survey Command, Continuous Monitoring, and Due Diligence begin with published CMS records and business context. Contract Labor Recovery is different: customer-authorized invoice evidence can be sensitive or regulated, so handling terms, access, retention, and any required agreement are established before intake.
Stripe hosts authorized payment experiences after a signed agreement.
PostHog receives limited public-site measurement only after consent.
Anthropic may classify an unresolved navigation question only after explicit visitor choice. Sensitive document extraction is disabled unless the applicable protected-data agreement gate is affirmatively configured.
Email and messaging providers support approved communications when enabled. Provider access and terms must match the data involved.
Production web endpoints require HTTPS configuration, while local development does not represent the production boundary. Transport encryption reduces interception risk; it is not a promise that every endpoint, device, vendor, or network is risk-free.
Protected sessions are signed, time-limited, and revocable; access challenges are single-use. Role and route rules are enforced server-side with an undeclared-access default of denial. A signed-in session does not, by itself, authorize every record or action.
Customer-facing access resolves organization scope from the trusted session. Production data services are designed for tenant-scoped storage and row-level enforcement; privileged cross-tenant activity is exceptional and auditable, not ambient customer access.
Sensitive authentication artifacts use authenticated encryption and token lookup uses non-reversible digests. Production startup rejects missing required secrets and development storage modes. Credalyst does not represent that every field, backup, or vendor-held copy has identical encryption or key-management controls.
Public and protected routes apply input schemas, request-size limits, origin rules, and route-specific throttling. Current request throttling is process-local, so Credalyst does not describe it as distributed denial-of-service protection or a complete abuse-defense program.
Logs and replay paths remove recognized credentials, contact identifiers, and sensitive payload fields before recording. Redaction lowers exposure; it cannot prove that unexpected free text or a newly introduced field will never contain sensitive data.
Public intent assistance is optional, capped, screened for obvious identifiers, and limited to an approved route; the question is not sent to public-site analytics. In a contracted recovery workflow, model-assisted extraction requires the applicable protected-data agreement gate, must preserve source evidence, and does not independently decide eligibility, recoverability, payment, or outreach.
Credalyst classifies records for retention and supports legal holds and governed deletion paths. Those controls are not presented as a universal automated purge. Contract terms, applicable law, active disputes, security needs, provider capabilities, and backup architecture can affect deletion timing and residual copies.
Critical provider paths use bounded timeouts, retries, idempotency, or fail-closed behavior where implemented. No service is promised to be uninterrupted. Duties to investigate, cooperate, and provide legally required notice depend on the affected data, applicable law, and signed agreement and must be confirmed in the applicable review; this page does not replace an incident-response plan or customer continuity plan.
Customers remain responsible for authorized users, accurate contact information, endpoint and email security, lawful instructions, timely offboarding, and not placing sensitive data into an unapproved channel. Report suspected vulnerabilities with high-level details only; do not access data, disrupt service, or include PHI. We will coordinate a safer channel for supporting material.
hello@credalysthealth.comCurrent architecture answers, subprocessors, data-handling terms, incident obligations, and available assurance materials are provided for the relevant deployment and agreement. No certification, regulatory conclusion, penetration-test result, uptime guarantee, or promise of perfect security is claimed here.
hello@credalysthealth.comCurrent posture only
Credalyst does not borrow credibility from a certification, audit, penetration test, regulatory conclusion, or attestation that has not been earned. Controls reduce risk; they do not eliminate it. Procurement answers should be scope-specific, current, and inspectable.
Continue the inspection
Request the current architecture, access, data, AI, subprocessor, retention, incident, and assurance scope relevant to your organization. Do not email PHI, credentials, or exploit details.
