Controls
Each control's status is one of implemented, partial or planned, with the date it was last verified. Framework references are to the SOC 2 Trust Services Criteria and the HIPAA Security Rule. Sign in or request access to see the evidence behind each control.
Access control
Staff sign in with a passkey (WebAuthn) or TOTP; the platform can verify every active employee has one enrolled.
Employees hold explicit roles (operator, admin, leadership, …); pages and actions require a role, never just a login.
Each application connects with a role granted only the schemas and tables it needs; the public API gateway's role cannot read acknowledgements, training or drafts and cannot write core operational tables beyond its own.
Developer, Stock and Trust portal access is granted by staff to a named person for one company, may carry an expiry, and is verified on every request so a revocation takes effect immediately.
Partner API keys are 160-bit secrets stored as SHA-256 hashes, scoped to a company and to approved endpoints, revocable, with test and live environments enforced.
Staff roles, portal grants and API keys are reviewed on a schedule and the review is recorded.
Availability & continuity
The production database can be restored to any point in the last 6 hours.
All services deploy from the main branch with no manual configuration on the host; a lost service is redeployed, not rebuilt by hand.
Documented recovery objectives and continuity steps for printers, stock, the facility and staff.
Data protection
All traffic to the platform, its database and its object store is TLS; there is no plaintext path.
The database and object store encrypt data at rest by provider default.
Passwords are hashed; API keys are stored as hashes; sessions are signed JWTs; webhook secrets are 192-bit and rotate with a 24-hour overlap.
Personal artifacts are never on a public URL; they are read through the platform with authorization and served via short-lived signed URLs.
A binding commitment in the Terms and the Privacy Policy: client content is never used to train models.
API request logs store names, addresses, photos and credentials as [redacted]; live request bodies are kept only on failure and only redacted.
Secure development & change
Every change is a described commit; the public API contract is snapshotted and a breaking change fails the check; migrations apply before code; apps are built before push.
Post-launch: feature branch → pull request → review → squash merge; direct writes to main are disabled.
A four-track audit (security, surface, sandbox/observability, webhooks) was run and its findings closed before the first partner key.
Runtime, framework and dependency updates are applied on a defined schedule and tracked.
Governance
A published, version-pinned policy set with an owner and an approver per policy and an annual review date; staff acknowledge each published version.
Every active employee is assigned the security courses on hire and each year; completion requires passing a short quiz and is recorded per employee.
Counsel-drafted terms and privacy policy (v2) are acknowledged by clickwrap, version-pinned, before a client-portal user can proceed.
A severity ladder, a 30-minute containment sequence, evidence preservation (suspending the purge), and notification to affected clients within 72 hours.
Logging & monitoring
Every status transition, hold, queue, print dispatch, ship and customer cancellation writes an audit event naming the actor, the action and the record.
One row per /v1 request: key, company, endpoint, status, latency, request id; partners can read their own slice.
Failing webhook endpoints, provider failures and other conditions raise a deduplicated alert on the staff rail.
Physical security
Badges and shipping documents carrying personal data are produced in a controlled area; misprints are destroyed; card stock is counted.
PrintNode workstations run only the print client, are screen-locked, and hold no personal data at rest.
Retention & deletion
Badge assets 30 days after shipping, shipping documents 90 days, carrier labels 30 days, a one-year ceiling on all cardholder data; a nightly job deletes the objects and nulls the references, and writes an audit row.
Request-log metadata 30 days, bodies 7 days (live) / 30 days (test), idempotency records 24 hours; sandbox orders 30 days.
The object store has no versioning; a delete leaves no non-current copy. The database keeps a 6-hour point-in-time window and no long-lived snapshots.
Vendor management
Every third party that touches client data is listed publicly with purpose, region and data categories; subscribers are notified 30 days before a change.
A DPA or equivalent terms is on file for each subprocessor that receives personal data.