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 cardholder 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.
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.
