Not another vendor security PDF. This is the actual posture of our portal — enforcement at the code, database, and integration layers — with recipient-verifiable proof for each claim.
Every privileged route requires multi-factor authentication. Stale identities are programmatically demoted and offboarded.
The proxy gates /admin, /consultant, /agency, and /assessor. Any privileged user without enrolled MFA is force-redirected to enrollment before reaching the surface. Offboarded users are sentinel-rewritten and indefinitely auth-banned, with role flags cleared. Bulk audits catch drift.
The portal stores documentation about regulated data — never the regulated data itself. Evidence metadata is cryptographically anchored; raw data stays in the customer’s perimeter.
No PHI, CUI, or other regulated data lives in the portal. Customers upload evidence of controls — policies, screenshots, config exports, log excerpts. Each upload is SHA-256 hashed server-side at ingest, and that hash becomes the immutable source of truth. RLS scopes documents per customer, and the boundary holds even under direct PostgREST queries.
Connectors (Okta, Entra ID, Google Workspace, GitHub, AWS CloudTrail, Vanta) enforce a strict per-vendor destination allowlist. Customer URLs are validated against known production hosts before any outbound request.
SSRF is the highest-leverage attack against any platform with customer-configured integrations. The connector layer rejects any URL that isn’t HTTPS on the vendor’s known host pattern — Okta must end in .okta.com, Vanta on the vanta.com namespace, and so on. Full-URL connectors run through the allowlist library before fetch().
Security-sensitive code paths are enforced by a CI gating framework before any code reaches production. The audit chain is append-only at the trigger layer and verified continuously.
Every pull request passes a service-role auth-check gate that fails if new code introduces a server-side admin client without a recognized auth step in the same file. The audit_events table is hash-chained — each row references the prior row’s hash; updates and deletes are blocked at the trigger layer. The chain tail is RFC 3161 timestamped via SSL.com’s TSA, and recipients verify it independently with no cooperation from us.
Consultants on a CMMC Level 2 engagement must complete a U.S. Person attestation before any assignment is permitted. Enforced at the database trigger layer, not the application layer.
CMMC L2 engagements routinely touch CUI with ITAR or export-controlled adjacency. The practitioner-gates trigger blocks an INSERT into consultant_assignments until a verified U.S. Person attestation exists for the consultant. No administrative override is exposed. ITAR-flagged scope (22 CFR §120.33) keeps the regulated data inside the customer’s domestic perimeter; the portal carries only the documentation attesting to the controls.
A deliberately small set of established infrastructure providers. Data residency is the United States, and the list is reviewed on a recurring cadence — no silent additions. These are our own subprocessors, distinct from the customer-configured connectors above.
| Provider | Purpose | Data region |
|---|---|---|
| Supabase | Managed PostgreSQL database, authentication, and file storage | United States |
| Vercel | Application hosting, compute, and web application firewall | United States |
| Stripe | Payment processing — billing and payment details are handled by Stripe and never stored by us | United States |
| Resend | Transactional email delivery (notifications, invitations) | United States |
| Anthropic | AI assistant for advisory drafting, under the data-minimization boundary | United States |
| Upstash | Rate limiting and ephemeral cache | United States |
| SSL.com | RFC 3161 trusted timestamping (audit-chain anchoring) | United States |
Evidence and documentation are submitted over an encrypted connection.
Hashed SHA-256 at ingest; privileged routes require MFA. No regulated data is retained here.
Documentation and evidence, encrypted at rest and isolated per customer by row-level security.
The portal carries documentation about regulated data — policies, evidence, hashes — never the PHI, CUI, or other regulated data itself. That regulated data stays inside the customer's perimeter. Each evidence hash is anchored to an RFC 3161 timestamp so a recipient can verify integrity independently.
We maintain a documented incident-response playbook for our own platform — aligned to CMMC practice IR.L2-3.6.1 (operational incident handling), distinct from the incident response we deliver for clients.
Suspected incidents — credential exposure, service disruption, data-integrity events — are triaged against defined severity criteria and contained first.
Affected parties are notified per the disclosure commitments below; the append-only audit chain preserves an evidentiary record of the timeline.
Production secrets live in a dedicated secrets manager, never in source, and are rotated on suspected exposure.
We thank researchers who responsibly disclose vulnerabilities in our portal or marketing site. We acknowledge reports within 2 business days, pursue no legal action against good-faith researchers, and credit you (with permission). Full policy at the RFC 9116 standard path.
We maintain pre-formatted CAIQ, SIG Lite, and mid-market vendor questionnaire responses — each answer linking to the underlying enforcement code, policy, or verifiable artifact. Reach out for the current revision.
