Security overview
The controls behind the Trust Center, written so a reviewer can use them.
A public description of access, encryption, logging, change, vendors, people, development, incidents, and availability. It is not the internal policy binder and it is not a SOC 2 report.
01 / Section
Access control.
Workspace and admin access require an invitation bound to a named email, and optionally a named mobile number. Magic links expire in minutes. SMS one-time codes expire in minutes. There is no public registration, no password database for marketing visitors, and no shared generic login.
Operators and clients are separated by grant role. Access is revoked by disabling the grant. Session cookies are HttpOnly, first-party, and scoped to the authentication hosts.
02 / Section
Encryption and secrets.
Traffic to the public site, workspace, and auth is served over TLS by the host. Neon encrypts data at rest. Application secrets live in the host environment, not in the repository. Intake URLs are credentials: only their hashes are stored.
03 / Section
Logging, monitoring, and backups.
We log authentication events, intake issuance, and operator actions needed to run the system. Session IP addresses and user agents are scrubbed after 90 days. Backups follow a rolling 30-day window. Restore tests are recorded as evidence.
04 / Section
Change and secure development.
Production changes go through version control. Schema changes are applied with migrations, not by reseeding. Secrets are not committed. Dependencies are reviewed when they are added. The marketing site does not load analytics or advertising scripts.
05 / Section
Vendor management.
Processors that handle customer data are listed on the subprocessors page, with purpose, data classes, and location. New material processors get a review before they receive data. Internal governance tools that do not receive customer content are not listed as subprocessors.
06 / Section
People and devices.
People with access to client information use unique accounts, screen locks, and disk encryption on the devices that handle that information. Security training is part of onboarding. Background checks are used where they are lawful and proportionate for a small LLC.
07 / Section
Incidents.
Report a suspected incident to security@xpancom.com. We investigate, contain, and notify affected clients without undue delay when client-controlled personal data is involved, as described in the Data Processing Addendum.
We do not publish a guaranteed response-time credit on this page. Managed operations hours and escalation are written in the statement of work. Public uptime percentages with service credits are not part of the standard offering.
08 / Section
Availability and recovery.
The hosted workspace is designed to be available during ordinary US business use. It is not a promised 24/7 control room unless a statement of work says so. Recovery relies on infrastructure-as-code, database backups, and a documented fallback for client operations that we implement: pause the automation, return to the previous process, export the records.
09 / Section
Data classification.
- Public
- Intended for the open web, such as this marketing site.
- Internal
- Xpancom operating information that is not published.
- Confidential
- Client and prospect information, including intake answers and workspace records. Default classification.
- Restricted
- Credentials, payment card data, protected health information, and raw employee files. Prohibited in Xpancom systems including intake free text.