Third Party Index

Snapshot 36253

Document
Security page
URL
https://www.ezappeal.com/security
Fetched
HTTP status
200
Content type
text/html; charset=utf-8
Fetch mode
browser
Size
52514 bytes
SHA-256 (raw)
29d9f6b83e9e017dfbdbe05f845adff6eaa6c768294ee1ef7728f839d7d1bd79
SHA-256 (normalized text)
6d75d2c8fc1bd72855dd50e877672332c105979044eb513eacb36218ed9ebd47

Normalized text

Scripts and page chrome removed; this is what change detection compares.

EZAppeal
Security & Compliance
How EZAppeal protects your patient data.
Architected from day one with a zero-PHI design. We don't store what we don't need, and we document exactly how PHI is handled, including which vendors a BAA covers, for your compliance team to review.
Certifications & Public Listings
Don't take our word for it. Every claim below links to a third-party-verifiable source.
CSA STAR Registry
Active
Listed in the Cloud Security Alliance STAR Registry at Level 1 (Self-Assessment), alongside Stripe, AWS, and Google Workspace.
Verify in CSA Registry →
CISA Secure by Design
Active
Confirmed signatory of CISA's Secure by Design Pledge, committed to seven measurable security practices including MFA, vulnerability disclosure, and CVE transparency. Joins 200+ technology companies including Microsoft, Google, AWS, and Cloudflare.
View signers list →
HIPAA Architecture
Compliant
Zero-PHI persistence design, audit logging per § 164.312(b), and an executed BAA with AWS Bedrock, which performs the AI processing of clinical data.
See "HIPAA Compliance" below ↓
Vulnerability Disclosure
Published
RFC 9116-formatted security.txt published. Researchers can report findings via the standard mechanism without legal risk.
View security.txt →
SOC 2 Type II
Planned
Pursuing SOC 2 Type II certification. Audit preparation underway with CSA STAR Level 2 bundled to share evidence and reduce cost.
In progress
PCI DSS
SAQ A
Payment processing fully delegated to Stripe (PCI DSS Level 1). EZAppeal qualifies for SAQ A scope: we never see card data.
Stripe security →
Zero-PHI Architecture
Unlike consumer-facing appeal tools that collect and store patient data on their servers, EZAppeal uses a zero-PHI (Protected Health Information) architecture. This means:
No patient data is stored
Clinical notes, patient names, dates of birth, insurance IDs, and diagnosis information are processed in real-time memory only. Nothing is written to disk or database.
No generated letters are retained
Appeal letters and prior authorization requests are generated, delivered to your browser, and discarded from our servers immediately.
Only a short activity record is saved
For each document we keep the payer, procedure code and name, denial code, billed amount, criteria-match counts, document type, and time, plus the date you mark it sent and the payer’s decision and any paid amount you record. Never a patient name, member ID, date of service, or any document text. A usage record also notes that a document was drafted, by kind, with no document content. Our data retention policy, available on request, describes each stored field.
No training on your data
AWS Bedrock does not use your inputs or outputs to train AI models. Your clinical information is never incorporated into any machine learning pipeline.
HIPAA Compliance
EZAppeal's AI processing is powered by AWS Bedrock, which is covered under a Business Associate Agreement (BAA) with Amazon Web Services. PHI is processed only transiently, in memory, and is never persisted.
Your BAA with EZAppeal
Every EZAppeal account signs our Business Associate Agreement before it can use the dashboard. The full agreement is shown before it is accepted, a state addendum is attached for organizations in California, New York and Texas, and a copy is emailed when it is accepted. To review it before you sign up, email contact@ezappeal.com and we will send you a copy.
Our BAA with AWS
AWS Bedrock is a HIPAA-eligible service, and our BAA with AWS covers the AI processing of clinical data, so PHI sent to the model is handled under a HIPAA-compliant agreement. Your documents reach our API server, hosted on Railway, which processes them in memory only and stores none of them; AWS Bedrock is the only vendor that performs AI processing on them. Supabase hosts our database, which stores no document content; Stripe, Resend, and DocuSeal receive business data only.
Encryption in transit
All data transmitted between your browser and our servers, and between our servers and AWS Bedrock, is encrypted using TLS 1.2+. No clinical data travels unencrypted at any point.
Encryption at rest
No document text is ever written to disk. Our database, hosted by Supabase, is encrypted at rest at the infrastructure level. It holds account data, the activity record described above and a usage record (event names, counts and labels, no document content).
Access controls
User accounts are authenticated via JWT tokens. Each user can only access their own account data and document history. Administrative access is restricted and logged.
How Your Data Flows
1
You enter clinical details
Payer name, procedure/CPT code, clinical notes, and denial reason are entered in your browser.
2
Encrypted transmission
Data is sent to our API over TLS 1.2+. Our server receives it in memory only.
3
AI processing via AWS Bedrock
Clinical data is sent to AWS Bedrock (Claude) in an AWS US region under BAA protection. Bedrock processes the request and returns the generated letter. Per AWS, Bedrock does not retain your prompts or use them to train models.
4
Letter delivered to your browser
The generated appeal or prior auth letter is sent back to your browser for review, editing, and download.
5
Clinical data discarded
After the response is delivered, all clinical data is purged from server memory. No patient information persists anywhere in our infrastructure.
Infrastructure and Subprocessors
AWS Bedrock
SOC 2 Type II certified. HIPAA eligible. FedRAMP authorized. All AI processing of clinical content runs on AWS Bedrock in United States regions, under our BAA with AWS. Non-PHI coverage research (payer, procedure, and drug names only) uses Anthropic's API.
Vercel (Frontend)
SOC 2 Type II certified. Global CDN with automatic HTTPS. No PHI touches the frontend infrastructure.
Railway (Backend)
Runs the API server in isolated compute environments. Holds no database; PHI is processed in memory only.
Supabase (Database)
Managed PostgreSQL, encrypted at rest. Stores account data, the activity record and a usage record, never document text.
Stripe (Payments)
PCI DSS Level 1 certified. EZAppeal never sees or stores credit card numbers.
These are the services that run EZAppeal. The complete list of service providers that process data for us, including email and e-signature, is in section 4 of our Privacy Policy.
What We Never Do
Store patient names, DOBs, or insurance IDs
Retain clinical notes after processing
Save generated appeal or prior auth letters
Share data with third parties for marketing
Use your data to train AI models
Allow unauthenticated access to any user data
Store PHI outside the United States
Send clinical content to an AI model without a BAA
Questions to Ask Any Appeal Tool Vendor
Before uploading patient data to any AI-powered tool, your compliance team should verify:
1.Does the vendor maintain a Business Associate Agreement (BAA) with their AI/cloud provider?
2.Where is patient data stored, and for how long? Is any PHI written to disk?
3.Does the AI provider use submitted data to train or improve their models?
4.Is data processed within the United States?
5.Can the vendor provide documentation of their security architecture for your compliance review?
6.Is the tool operated by a US-based entity subject to HIPAA enforcement?
EZAppeal's answer to all of the above: Yes. We maintain an executed BAA with AWS (Bedrock), operate a zero-PHI architecture with no persistent storage of clinical data, process data in AWS US regions, and AWS Bedrock does not retain or train on your inputs. Contact us for full compliance documentation.
Accessibility Statement
EZAppeal is committed to making our service usable by everyone, including people with disabilities. We treat accessibility as an ongoing engineering priority, not a one-time checklist.
Conformance target
Web Content Accessibility Guidelines (WCAG) 2.1 Level AA
Current status
Partially conformant. Known issues are tracked internally; substantive improvements ship continuously.
Technologies relied upon
HTML5, CSS3, JavaScript (React), WAI-ARIA, lucide SVG icons.
Built for
Current versions of Chrome, Safari, Firefox, and Edge, with screen readers such as NVDA, JAWS, VoiceOver, and TalkBack.
Features in place today
Skip-to-content link for keyboard users
Semantic HTML with ARIA landmark roles where appropriate
Visible focus indicators on interactive elements
Primary buttons and form fields sized at 44px or larger
prefers-reduced-motion respected for animations
Modal dialogs with role="dialog": focus moves into the dialog and stays there, Escape closes it, and focus returns to where you were
Live-region announcements for asynchronous status changes
Visible labels, not placeholder text alone, on the sign-up, profile, account, appeal and prior-authorization forms
Found a barrier? We want to fix it.
If you encounter any content or functionality that is not accessible to you, please reach out. We aim to acknowledge accessibility feedback within 5 business days and to provide a remediation plan or alternative access path.
contact@ezappeal.com
Last reviewed: September 18, 2026. This statement is reviewed and updated each time material changes ship to the production frontend.
Responsible Disclosure
If you've found a security vulnerability in EZAppeal, we want to hear about it. We follow Coordinated Vulnerability Disclosure best practices and will not pursue legal action against researchers acting in good faith.
How to report
Email us at the address below with a detailed description. We'll acknowledge receipt within 3 business days.
contact@ezappeal.com
security.txt
Machine-readable disclosure policy following RFC 9116. Includes contact details, expiry, and policy URL.
View security.txt →
Scope: ezappeal.com and its subdomains, and our API at ezappeal-backend-production.up.railway.app, all operated by EZ Appeal LLC.
Out of scope: Third-party infrastructure (AWS, Railway, Vercel, Supabase, Stripe, DocuSeal). Please report those directly to the respective vendor.
Do not publicly disclose vulnerabilities before we've had a reasonable opportunity to address them (typically 90 days).
Need compliance documentation?
We're happy to provide detailed security documentation for your organization's compliance review.
Contact Us
Our public pages use Google Analytics, Google Ads, Microsoft Clarity, and Microsoft Advertising cookies to measure visits and ad clicks and to show our ads to past visitors. None of them load inside your account. Privacy Policy