How we secure the platform we run on.

Role-based access

Every module in the platform declares its permissions in one registry. Each protected page checks the signed-in person's permission before it loads, and every action that changes data checks again on the server—never trusting that the screen already did.

Audit trail

Changes to sensitive records—roles, permissions, settings, people's details—are written to an audit trail that names who made the change and when. The trail records that a secret changed, never the secret itself.

A fresh sign-in for sensitive actions

Changing bank or integration details, and revealing a full taxpayer ID, need a sign-in within the last 15 minutes. If yours is older, you confirm it's you in place, and what you typed is kept.

Encrypted tax IDs

Social Security numbers and other taxpayer IDs are encrypted field by field with AES-256-GCM before they're stored, under a dedicated key rather than one derived from the platform's sign-in secret. Screens show the last four digits.

Encrypted settings

Integration secrets stored in the platform—passwords and API keys—are also encrypted with AES-256-GCM, under a key reserved for settings, and a tampered value fails to open rather than being used.

Secure connections

HTTPS only, with HTTP Strict Transport Security (one year, including subdomains), plus headers that stop content sniffing and framing by other sites and limit what a link passes on. They're set at the edge and again in the app.

UniCorp's own platform runs on Google Cloud in the United States, in the us-west1 region (Oregon): the application on Compute Engine, uploaded files in Cloud Storage, and our container images in Artifact Registry. Deployments authenticate to Google Cloud with short-lived credentials rather than a stored key.

That's where we run our business. Where software we build for you runs is your call: hosted by us or in your own cloud account, decided by your requirements during the Blueprint.

• Every request gets one ID that joins the edge's access log, the application's log lines and any error report, so a problem can be followed end to end.
• Before anything is written, the edge's access log drops query strings and headers, and the application's logs mask anything shaped like a token or an email address—so sign-in and payment links are redacted rather than recorded.
• Unhandled errors are reported to an error tracker we run ourselves, inside the platform, rather than to an outside service.

• Every change goes through a pull request and runs automated type checks, linting and tests. Our rule is that nothing merges until they pass.
• Releases are promoted to production through a separate release branch, never straight from day-to-day work.
• Any production release can be rolled back to a previous build without rebuilding it.
• Where AI helps write a change, it goes through the same pull request and checks. How we use AI.

If you think you've found a security problem in our website or platform, tell us. Our security.txt lists how to reach us, or use the security contact form. Please give us a reasonable chance to fix it before you share it, and don't access or change data that isn't yours while you look.

Ask. We'll answer your security questionnaire, and say plainly where something isn't in place.