Security

1. How the platform is built

A waiver is only worth keeping if it is still there, still readable, and still provably unchanged years after it was signed. Everything below follows from that one requirement.

Waiver.com runs on DigitalOcean droplets in the San Francisco region. We run our own PostgreSQL database and our own Redis, on a dedicated volume and a private network, rather than exposing them to the internet. In front of the application sits nginx, terminating TLS with certificates from Let’s Encrypt and redirecting every plain HTTP request to HTTPS. A host firewall allows only SSH and nginx; the database and the cache answer on the private network and on loopback, and have no public address.

Each customer’s data is separated by organization at the query layer, and every request carries the organization it belongs to, so a bug in one screen cannot return another customer’s rows.

2. Encryption

• In transit.TLS on every connection — the dashboard, the signing pages, the kiosk, and the API — using certificates issued by Let’s Encrypt and renewed automatically. The browser-facing hosts also send HTTP Strict Transport Security, so a browser will not fall back to an unencrypted request.
• At rest. The database and file storage sit on DigitalOcean volumes, which are encrypted at rest. Files in object storage are encrypted again with a key of our own, bound to the object.
• At the field.Answers a customer marks sensitive — health conditions, medications, allergies — along with a signer’s date of birth and every authentication secret, are encrypted individually with AES-256-GCM before they are written, above and beyond the volume encryption, so a copy of the database alone does not reveal them.
• Credentials. Passwords are stored only as salted hashes using a modern, deliberately slow algorithm. We cannot read your password, and neither can anyone who takes the database.
• Secrets.Keys and credentials live in the server’s environment configuration, never in the repository.

3. The record chain

A signed record is written once and is never updated. Each record is hashed together with the hash of the record before it, so the store is a chain: altering an old record changes its hash, which breaks every link after it, which is detectable by anyone who re-walks the chain.

The stored record includes the exact document text as it was presented, the version, every answer, the signature, the timestamp to the second, and the IP address the signature came from. The hash covers all of it, including the digest of every attached file.

A signed record cannot be edited through the product, and the database itself refuses the change— a trigger rejects any update to the columns that make up the record. A correction is made by signing a fresh record; the original is retained, and can be voided with a reason, but it is never altered; it is removed only at the customer’s request or when its retention period ends.

4. Who can see what

Your side. Access is role-based. An owner decides which staff can view records, which can only check people in, and which can change templates or settings. Two-factor authentication is available to every user and we recommend turning it on for anyone who can open a record; we do not force it, because locking a business out of its own waivers at the front desk is its own kind of harm.

Sessions expire and idle sessions time out. A user can see their signed-in devices and end their own sessions on any of them. An owner can remove a member, which ends that person’s access to the organization. A password reset invalidates every existing session.

Our side. Production access is least-privilege and granted by role to the few people whose work requires it. Two-factor authentication is mandatory for our own administrative access, enforced in the admin application itself. Support staff do not browse customer records; when a support request requires opening one, that access is written to the same log as any other read.

5. Logging

Every human read of a signer’s record is written to an access log — who read it, when, and which record. That log is the raw material for the accounting of disclosures a HIPAA customer owes its patients. There is no customer-facing view of it yet; until there is, we produce it for you on request.

Alongside it we keep ordinary application and infrastructure logs for availability, faults, and abuse: authentication attempts, administrative actions, rate limiting, and errors.

6. How we build and ship

• Code is reviewed before it ships, and the pipeline runs lint, type checks, and an automated test suite on every change.
• Dependencies are pinned and watched for known vulnerabilities; security updates are prioritized over feature work.
• Deployments are scripted and recorded, and can be rolled back.
• Test and development environments never contain real customer records.

7. Hosting and physical security

The platform runs in DigitalOcean data centers in the United States, in the San Francisco region, which maintain SOC 2 audited physical and environmental controls: staffed perimeters, badge and biometric entry, camera coverage, redundant power and cooling, and audit trails for every visit. We hold no customer data on our own premises — there is no server in our office and no drive in a desk. Staff reach production only through logged, access-controlled paths.

8. Our security program

We are a small company and we would rather tell you what our program is than imply a compliance department we do not have. It consists of:

• Incident response. A written plan, in place before the first customer BAA is countersigned, naming who is called, how an incident is contained and investigated, how evidence is preserved, who talks to customers, and what is recorded afterwards.
• Risk assessment. A review of the risks to the confidentiality, integrity, and availability of the data we hold, completed before the first customer BAA is countersigned and revisited after any material change to the architecture.
• Workforce training. Anyone who could encounter protected health information is trained before they are given access.
• Access review. Production access is reviewed and removed when someone leaves or changes roles.
• Vendor review. No vendor receives customer data before it is reviewed, and none receives protected health information before it has signed a business associate agreement with us.

Where one of these is an obligation rather than a description, it is written into the business associate agreement, which is the document that binds us.

9. Retention and deletion

Signed records are retained for 7 years by default, adjustable on request. You can ask us to delete a record, a signer, or an entire account by writing to help@waiver.com, and we complete the deletion within 30 days unless a legal hold applies. The Privacy Policy sets this out in full.

10. Reporting a vulnerability

If you have found a security problem, tell us at help@waiver.comwith “security” in the subject. Include what you found, how to reproduce it, and what you think the impact is. We will come back to you and keep you updated until it is closed.

We will not pursue legal action against anyone who reports in good faith, stays within their own test account, does not access, alter, or exfiltrate anyone else’s data, does not degrade the service, and gives us a reasonable chance to fix the issue before publishing. We do not run a paid bounty program today, and we will credit you when a fix ships if you would like us to.

11. Sub-processors

We keep the vendor list short on purpose, and publish it: hosting, DNS, transactional email, analytics on the marketing site, and — when they launch — payments and SMS. Each is reviewed before it touches customer data, and no vendor receives protected health information before it has signed a business associate agreement with us. Nothing third-party runs on the signing pages. The current list, with what each one receives, whether it is active, and where it runs, is at waiver.com/subprocessors.

12. What you control

Security is shared. The parts that sit with you:

• who you invite, what role you give them, and how quickly you remove someone who leaves;
• whether your staff turn on two-factor authentication;
• what your forms ask for — the safest data is the data you never collect;
• the physical security of a kiosk tablet sitting on your counter;
• where you send exports, and what any integration or webhook you configure does with the data once it arrives.

13. Contact

Security reports, security questionnaires, diligence requests, and everything else go to help@waiver.com. A person answers.