Security
Controls that are enforced, not asserted.
Security claims are easy to write and hard to keep. Ours are enforced in the database and the build pipeline, where they cannot be skipped on a busy day, and this page only claims what the system actually does.
Enforced in the database, not just the screen
Isolation
Row-level security on every table, enforced by the database itself. One customer can never read another's rows, and a test fails the build if a table ships without the policy.
Identity
Two-step sign in, required for owners and admins. Remembered devices expire, resets are self-serve, and roles and seats are enforced in the database, not just the interface.
Encryption
TLS on every hop with HSTS. Sensitive fields are sealed with a key only production holds, so a copy of the database alone does not expose them.
Audit
An append-only log of every change that matters. Downloads are logged. Records are superseded, never erased, so history cannot be rewritten quietly.
Change control
A protected main branch, required checks on every change, and schema changes that travel through a ledgered migration pipeline, never applied by hand.
Recovery
Point-in-time database recovery over seven days plus nightly backups, and a one-step rollback to the last good deploy.
Every click takes the same guarded path
Every request arrives over TLS, with security headers on every response.
The sign-in token is verified against the auth server's public keys, then the role and two-step level the route requires are checked.
One database transaction opens, carrying the caller's identity, so row-level security applies to everything the request touches.
The audit entry is written and the request is timed into a performance log before the response leaves.
NetSuite access uses token-based auth to each customer's own account, over standard REST and SuiteQL. We keep references, not a second ledger: NetSuite holds the money.
How a change reaches production
- —Every change is written against a spec and goes through a pull request with a private preview deploy.
- —Required checks before merge: lint, type checks, API tests against a real Postgres with its security rules enforced, web tests, and a production build.
- —Schema changes run on staging first. The migration ledger records a checksum of each file: an applied migration edited later stops the run, and a failed migration leaves nothing half-applied.
- —Main only moves when every check is green; production deploys only from main.
- —Uptime and scheduled jobs are checked every 15 minutes; dependencies are audited weekly.
SOC 2 readiness, built in
Every customer inherits the program from day one:
- —A policy set, approved and acknowledged by everyone
- —Quarterly access reviews, signed off and recorded
- —Security training with a quiz, tracked yearly
- —Vendor and secret registers: names, never values
- —Sensitive fields encrypted; exports logged
- —A controls register computed from the records themselves
Honestly stated: this is a readiness program, not a completed audit. SOC 2 Type II is a year-one milestone, and this page will say "audited" only when the report exists. For healthcare customers, a HIPAA tier adds the required controls, and we sign business associate agreements before any protected health information is processed.
Reporting a vulnerability
If you believe you have found a security issue in YouConnext or any Connext platform, email hello@youconnext.com with "Security" in the subject. We read every report, respond quickly, and will not pursue good-faith research conducted without harm to customers or data.