Security
Last updated 28 September 2026
WearableDocs is built to protect medical directives, emergency contacts, personal documents, and the evidence of every time a record is viewed. This overview describes the security architecture, encryption practices, and operational controls that protect the platform and our customers’ information.
SOC 2 Alignment
WearableDocs’ security program is mapped to the AICPA SOC 2 Trust Services Criteria for Security (Common Criteria CC1 to CC9), with selected controls also supporting Availability and Confidentiality. We are preparing for an independent SOC 2 examination.
| Criteria | WearableDocs controls |
|---|---|
| Logical access CC6.1–CC6.3 | Salted one-way credential hashing, sign-in rate limiting, session expiry, host-locked session cookies, session revocation on credential change, and multi-factor, Zero Trust access for staff. |
| Boundary protection CC6.6–CC6.7 | HTTPS only over TLS 1.2 or higher, strict content security policy, an isolated record service, a separate administrative network address, and card data held only by Stripe. |
| Monitoring CC7.1–CC7.2 | Automated dependency alerts, nightly integrity checks with alerting, hourly external monitoring of the record service, a hash-chained access log, and logging of authentication and administrative events. |
| Change management CC8.1 | Version control, automated testing of every change, and validation in a separate staging environment before production release. |
| Availability A1 | Point-in-time database recovery, encrypted off-site backups with tested restores, durable queued processing with automatic retries, and a record service isolated from other systems. |
| Confidentiality C1 | AES-256-GCM encryption at rest, minimal data shared with service providers, and no sale of customer information. |
Physical and environmental controls are inherited from Cloudflare, which maintains its own SOC 2 Type II report. WearableDocs operates the application, identity, access, development, monitoring, and customer-data controls described here.
Security Architecture
- Cloudflare global network: Application hosting, database, document storage, and scheduled operations run on Cloudflare’s global edge network. There is no single origin server to fail, patch, or target.
- Isolated record service: The page a reader sees when a code is scanned is served by a dedicated service, isolated from account, billing, and administrative systems. A change to one cannot affect the availability of the other.
- Zero Trust administration: Administrative systems run on a separate address, protected by Cloudflare Access identity verification at the network edge and by multi-factor authentication.
- Payment processing: Payments are handled by Stripe, a PCI DSS Level 1 certified provider. WearableDocs never receives or stores card numbers.
- Independent sealing: Evidence of every view is countersigned and timestamped by Let’s Seal, an independent sealing service.
Encryption & Key Management
WearableDocs protects data in transit, at rest, and at the application layer.
| Layer | Protection |
|---|---|
| Data in transit | HTTPS over TLS 1.2 or higher on every connection. Legacy protocols are refused. |
| Database | AES-256-GCM encryption at rest, covering live and inactive data and metadata. |
| Document storage | AES-256-GCM encryption at rest for every uploaded document and every archived page. |
| Document vault | A second layer of AES-256-GCM encryption, applied by our application before a file reaches storage, under a key held only by the application service. |
| Record pages | AES-256-GCM encryption at rest for every published record page. |
| Account credentials | Salted, one-way cryptographic hashing. Passwords are never stored. |
| Access evidence | SHA-256 fingerprints, hash-chained per record, signed daily by an independent authority and anchored to the Bitcoin blockchain. |
| Off-site backups | AES-256-GCM encryption before the data leaves Cloudflare, with keys held separately from the backups. |
| Keys and secrets | Held in Cloudflare’s encrypted secret storage, separate from source code and customer data. |
Identity & Access Control
- Credential protection: We never store your password. We store only a salted, one-way cryptographic fingerprint of it.
- Enumeration resistance: Sign-in returns the same response, in the same time, whether or not an account exists. The sign-in form cannot be used to discover who has an account.
- Brute-force protection: Repeated failed sign-in attempts are rate limited per account.
- Session security: Sessions expire after 30 minutes of inactivity and 24 hours after sign-in, whichever comes first. Session cookies are secure, locked to our domain, and unavailable to page scripts.
- Credential changes: Changing a password requires the current password and ends every other active session.
- Privileged access: Staff access requires identity verification at the network edge and a second factor. Administrative record deletions are logged.
Record Page Protection
- Pre-rendered delivery: Record pages are built in advance and served from storage. A scan never queries the database or touches a login.
- No third-party exposure: Record pages run no scripts and load nothing from any outside company. No fonts, analytics, or trackers.
- Strict content security policy: Browsers are instructed to refuse any content the page does not declare.
- No referrer leakage: A site reached from a record page is not told where the reader came from.
- Private by default: Record pages are excluded from search engines, there is no directory of records, and record codes cannot be guessed at any practical scale.
Document Vault Protection
- Encrypted before storage: Every file in the vault is encrypted with AES-256-GCM by the WearableDocs application before it is written to storage. That’s in addition to the encryption at rest that covers all stored documents. Storage holds only ciphertext.
- Separately held key: The vault key is held only by the application service. The record service, which serves scanned pages, holds no keys and cannot read vault files.
- Tamper-proof files: Each encrypted file is bound to its storage location. A file copied or moved elsewhere will not open, and any altered byte is detected and refused.
- Private by default: Only the account holder can see vault files. A file appears on the public record only when the holder chooses to show it.
- Expiring share links: Share links expire after one day, one week, or one month, and the holder can stop one at any time. Each link is generated from 256 random bits and stored only as a one-way fingerprint.
- Optional passcode: The holder can require a six-digit passcode, sent to the recipient separately. After five incorrect attempts the link locks and the holder is notified by email.
- Every open recorded: Each time a shared file is opened, the view is added to the holder’s access history. The holder can also turn on an email for each open.
- Timestamped on arrival: Each file is fingerprinted when uploaded and timestamped by Let’s Seal, an independent sealing service.
- Never cached or indexed: Vault files are served with instructions that forbid caching and search engine indexing.
- Backed up encrypted: Vault files are included in off-site backups and stay encrypted under both layers.
- Permanent deletion: Deleting a file removes it from storage. Closing an account removes every vault file.
Evidence Integrity & Auditability
- Access logging: Every view is logged with a cryptographic fingerprint of exactly what the reader was shown.
- Tamper evidence: Each log entry is chained to the one before it. Altering or removing an entry breaks the chain.
- Independent sealing: Each day’s log is sealed into a single fingerprint, signed by Let’s Seal, and anchored to the Bitcoin blockchain. Only that fingerprint leaves our system. No page, name, document, or log entry is ever sent.
- Verifiable by anyone: Seals can be verified with standard, free tools, with no involvement from WearableDocs or Let’s Seal:
openssl cms -verify -inform DER -in root.sig -content root.bin \
-binary -CAfile letsseal-root.crt
ots verify root.ots
- Document integrity: Uploaded documents are stored byte for byte, exactly as received, and fingerprinted on arrival. Any alteration would be detectable.
- Upload validation: Every upload is inspected to confirm it is the file type it claims to be.
- On-device scanning: Photographs of signed forms are processed in the customer’s own browser before anything is sent.
How this evidence protects you if your directive is ignored.
Secure Development
- Automated testing: More than 1,400 automated checks run on every change, including a sweep that requests every address in the application without credentials to confirm private pages stay private.
- Staged releases: Changes are deployed to a separate staging environment, with its own database and storage, and validated before production.
- Minimal supply chain: Security-critical components, including multi-factor codes, password hashing, and QR encoding, are built in house rather than imported. Record pages depend on a single outside library.
- Security reviews: Application code, response headers, and infrastructure configuration are reviewed for vulnerabilities, and findings are fixed through the same controlled release process.
Monitoring & Resilience
- Automated integrity checks: Every night the platform verifies that each day’s seal is present, that every stored document is accounted for, and that billing matches published prices. Any failure raises an alert.
- Point-in-time recovery: The database can be restored to any minute within Cloudflare’s recovery window.
- Off-site backups: Every stored document and archived page is copied to a second provider outside Cloudflare within hours, and the database every night. Backups are encrypted with AES-256-GCM before they leave, so the backup provider holds only ciphertext. Restores are tested.
- External monitoring: The record service is checked every hour from outside Cloudflare: that its address resolves and validates, that its certificate is current, and that it answers.
- Durable processing: Scan logging and alerts run on a durable queue with automatic retries, so a temporary failure does not lose the record of a view.
- Verified payment events: Every payment message is cryptographically verified, rejected if stale, and processed exactly once.
Privacy & Confidentiality
- WearableDocs does not sell customer information to advertisers, data brokers, or any other third party.
- There is no advertising and no third-party analytics on the site, the application, or record pages.
- Service providers receive only what they need to perform their function: Cloudflare (hosting and storage), Stripe (payments), Telnyx (text alerts), Resend (email), and Let’s Seal (a fingerprint only).
- Record pages show only what the customer chose to display. Read the privacy policy.
Responsible Disclosure
To report a security concern, email hello@wearabledocs.com.