The short version. PHI is encrypted in transit and at rest. Each practice's data is isolated by an authorization guard that an automated build check enforces on every code change. Everything that touches a chart is written to an append-only audit log. Every vendor that can reach patient data is under a Business Associate Agreement scoped to that specific data type. A designated Security Officer owns a written incident response plan, and we notify an affected practice within ten business days of discovering a reportable event.
Who is accountable
Penna Health LLC has designated, in writing, a Security Officer under 45 C.F.R. § 164.308(a)(2) and a Privacy Officer under 45 C.F.R. § 164.530(a)(1). Both roles are reachable at the addresses below and correspondence is answered by the designated officer.
- Security Officer — security@penna.health. Owns the incident response plan, the incident log, breach risk assessments, vendor security review, and the annual review of both.
- Privacy Officer — privacy@penna.health. Owns this policy, privacy rights requests, and the handling of PHI under our Business Associate Agreement.
Penna Health is an early-stage company and we are not going to describe ourselves as a security organization we are not. What we can tell you is who is responsible, what is written down, and how quickly you will hear from us.
Reporting a security issue
Report a suspected vulnerability or security issue to security@penna.health. We acknowledge every report within one business day.
We will not pursue legal action against good-faith security researchers who report through that address, avoid accessing, altering or exfiltrating patient data, avoid degrading the service for others, and give us reasonable time to remediate before disclosing publicly. If you are a customer and suspect a compromised account, a lost device, or an account you no longer recognize, write to security@penna.health or support@penna.health and we will disable the affected access promptly.
If an incident occurs
We maintain a written Security Incident Response Plan satisfying 45 C.F.R. § 164.308(a)(6). It is not a paragraph in a contract; it is a procedure with owners, deadlines and a retained record. In outline:
- Recorded first. An incident log entry is opened at discovery, with the discovery time in UTC, before investigation begins. That timestamp starts every regulatory clock, so it is captured before anything else.
- Contained before diagnosed. We revoke the affected credential, disable the affected identity, or switch off the affected module. Penna's integrations are built to fail closed, so disabling one stops data flow rather than re-routing it.
- Investigated against evidence. Our audit log is append-only and ships inside every backup, so the record of what was accessed cannot be edited after the fact — including by us.
- Assessed on the record. For any incident involving PHI we complete and retain a documented four-factor risk assessment under 45 C.F.R. § 164.402, including when we conclude no breach occurred, because the burden of proof sits with us.
- Reported to you. We notify the affected practice without unreasonable delay and no later than ten (10) business days after discovery — deliberately stricter than the sixty days permitted by § 164.410. The notice tells you what happened, when, whose PHI was involved, what types, and what we are doing, and is supplemented as we learn more rather than withheld until complete.
- Reviewed afterwards. Serious incidents get a written post-incident review within ten business days of closure, with corrective actions assigned an owner and a date.
You remain responsible, as the covered entity, for notifying individuals, HHS, and where required the media. Our job is to give you everything you need to do that, fast enough that you can.
Technical safeguards
Encrypted throughout
PHI is encrypted in transit and at rest. The web front end serves no patient data of its own — the browser talks directly to the backend under the customer's session.
Practice isolation, proven on every build
Every patient-data record carries its owning practice, checked on every access through one shared authorization guard. An automated check fails the build if any function reaches the database without that guard, or accepts a record identifier from the client without scoping it to the practice. Isolation is proven on each change, not assumed.
Staff and patients cannot be confused
Clinician and patient sign-ins are issued by two separate identity providers and verified against different issuers, so a patient credential can never satisfy a staff check, or the reverse.
Append-only audit log
Creates, chart views, changes, signatures, approvals and exports — with who, what, when and from where. Denied attempts are recorded too, so probing is visible. No code path edits or deletes these records.
Roles enforced on the server
Clinical, billing and administrative roles resolve to different data, checked server-side rather than hidden in the interface. Unique user identification; ten-minute automatic logoff with a warning at eight, on every surface.
Signed notes are immutable
A signed clinical note cannot be rewritten. Corrections are recorded as addenda in a visible chain, so the chart shows what was written and when it changed.
Uploads scanned on our own infrastructure
Every uploaded document and inbound fax is scanned for malware inside our own cloud account under our BAA. We do not use public scanning services, which would mean sharing the file itself.
Nothing leaks from the front door
Public-facing endpoints are rate limited and answer identically regardless of outcome, so no response reveals whether a given person is a patient. PHI never appears in a URL.
Backed up offsite, retained six years
Data is backed up to versioned offsite storage in our own cloud account. Audit records are retained for six years as HIPAA requires.
Subprocessors and BAAs
The rule we hold ourselves to is that a vendor touching PHI needs a Business Associate Agreement whose scope covers that specific data type — not merely a signed agreement with that company. We once removed a fax and transcription vendor entirely rather than keep it as a fallback, because it claimed conduit status that excluded transcription. There are no silent fallbacks anywhere in Penna: if a covered vendor is misconfigured, the feature turns off with a named error rather than routing your data somewhere that is not covered.
| Subprocessor | What it powers | Data it receives | BAA |
|---|---|---|---|
| Convex | Database, file storage, application backend | PHI | Signed |
| Amazon Web Services | AI note assistance, dictation, malware scanning, offsite backup | PHI | Signed |
| WorkOS | Sign-in for staff and patients | Names, e-mail addresses, login identities | Signed; scope verification in progress |
| Stedi | Insurance eligibility, claims, remittances | PHI | Signed |
| Notifyre | Fax and SMS | PHI | Signed |
| Paubox | Transactional e-mail | E-mail addresses and message content | Signed |
| Whereby | Telehealth video | Visit media only — rooms carry no patient information | Signed |
| DoseSpot | Electronic prescribing | Demographics and medications | Verification in progress; module off by default |
| Vercel | Web hosting for the application shell | No PHI | Signed |
| Stripe | Our invoicing of the practice | No patient data | Not applicable |
Every feature module is off until a practice enables it, so a subprocessor you do not use receives nothing at all.
AI, dictation and telehealth
- AI note assistance is suggestion-only. It drafts; a clinician reviews and signs. It runs on a model hosted inside our own cloud account under our BAA, and every call writes an audit record of the disclosure. We do not use PHI to train general-purpose AI models, and no patient data is sent to a consumer AI service.
- Dictation audio is deleted the moment a transcript exists, on every outcome including failure.
- Telehealth rooms carry no patient information. Room identifiers are random, and recording and transcription are disabled at the moment each room is created rather than by policy afterwards.
- Credentials are treated as radioactive. Video host links, payment links and password-reset links never appear in logs, audit records or exports. Where a DEA number is held, only its last four digits exist in Penna at all.
- Substance-use records. Records a practice designates under 42 C.F.R. Part 2 are gated by a dedicated check before outbound disclosure. Full release-of-information workflow is future work, and we treat that as a limit on which practices we onboard rather than a detail to discover later.
What we are working on
A security page that claims everything is finished should not be believed. These are the items currently open and owned:
Durable six-year audit log streaming
Authorization-denial records are retained in the platform log buffer today. Streaming them to write-once storage with a six-year lock is designed and being enabled per deployment.
Backup restore drill
Offsite backups are live and verified on both deployments. Exercising a full restore end to end, and the written disaster recovery plan around it, is scheduled.
Workforce security training programme
Formal security awareness training with retained records, under § 164.308(a)(5), is being stood up alongside a documented workforce termination checklist.
Server-side read logging
Chart views are logged by the application. Routing the most sensitive reads through a server-side logging step, so that the log cannot be bypassed by a direct API call, is built and running in observe mode ahead of enforcement.
Documentation for reviewers
If you are evaluating Penna Health — as a prospective practice, a partner, or a vendor running a security review — we will provide the following under NDA on request to security@penna.health:
- Security Incident Response Plan
- Vendor and BAA verification matrix, feature by feature
- Technical security overview
- Backup and retention policy
- Our standard Business Associate Agreement
- Completed security questionnaires, and answers to yours
We would rather hand you the open items than have you find them.