Architectural controls, not assurances.

Every privileged route requires multi-factor authentication. Stale developer and administrative identities are programmatically demoted and offboarded.

Our reverse proxy gates /admin/*, /consultant/*, /agency/*, and /assessor/* surfaces. Any authenticated user with a privileged role who has not enrolled MFA is force-redirected to enrollment before reaching the surface. Offboarded users are sentinel-rewritten (emails replaced with deleted-<uuid>@deleted.invalid) and indefinitely auth-banned; their role flags are simultaneously cleared so any downstream code that joins on role/is_admin without checking auth-ban status still treats them as non-privileged. Bulk audits run periodically to catch drift.

The portal stores documentation about regulated data, not the regulated data itself. Evidence metadata is cryptographically anchored; raw customer data stays within the customer’s own secure perimeter.

We do not handle PHI, CUI, or cardholder data inside the portal. Customers upload evidence of controls (policies, screenshots, configuration exports, log excerpts) — never live regulated data. Each upload is hashed (SHA-256) server-side at ingest; the server-recomputed hash becomes the immutable source of truth for integrity verification. Documents are scoped by RLS so a customer can never read another customer’s evidence, and the boundary holds even under direct PostgREST queries.

External data-fetching connectors (Okta, Microsoft Entra ID, Google Workspace, GitHub, AWS CloudTrail, Vanta) enforce a strict per-vendor destination allowlist. Customer-supplied URLs are validated against the vendor’s known production hosts before any outbound request.

Server-Side Request Forgery is the highest-leverage attack against any platform that lets customers configure outbound integrations. Our connector layer rejects any URL that isn’t HTTPS on the vendor’s known host pattern — Okta tenants must end in .okta.com or .oktapreview.com, Google Workspace token URIs must be Google OAuth hosts, Vanta API base URLs must be on the vanta.com namespace, and so on. Connectors that interpolate customer-controlled values into hardcoded base URLs are inherently safe by construction; ones that accept full URLs run through the allowlist library before fetch().

Security-sensitive code paths are enforced automatically by a CI gating framework before any new code reaches production. The audit chain itself is append-only at the database trigger layer and verified continuously.

Every pull request targeting our main branch passes through a service-role auth-check gate that fails if any new code introduces a server-side admin client without a recognized authentication step in the same file. The audit_events table is hash-chained (each row references the previous row’s hash and embeds its own row hash); updates and deletes are blocked at the trigger layer. The chain tail is timestamped via SSL.com’s RFC 3161 Timestamping Authority on a regular cadence. Recipients of our deliverables can verify the chain independently at the public verify endpoint without any cooperation from us.

Consultants assigned to 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.

For CMMC L2 engagements — which routinely involve CUI categories with ITAR or export-controlled adjacency — the framework_background_requirements table requires a verified U.S. Person attestation against the consultant before a row can be inserted into consultant_assignments. The practitioner-gates trigger blocks the INSERT until the requirement is satisfied. Administrative override is not exposed. This sits alongside our boundary discipline: customers do not upload ITAR-controlled technical data (22 CFR §120.33) into the portal; ITAR-flagged scope keeps the regulated data inside the customer’s domestic perimeter, and our portal carries the documentation that attests to the controls protecting it.