- contact@verticalserve.com
- Continuous compliance, proven every hour
A compliance product holds the keys to your systems and the evidence of your controls. This is how InsightAssure keeps both: tenancy, identity, credentials, integrations, auditors, the device agent, the AI, the Trust Center and where the data lives.
Every table carries the organization and every query a route makes is scoped to the caller’s. A guessed id from another organization answers 404, exactly as a missing one does.
Postgres row-level security on assure.org enforces the same boundary for every product table. Each request’s session is pinned to the caller’s organization; a session with no organization sees nothing.
The API connects as an ordinary role (no superuser, no BYPASSRLS) so the policies bind; setup warns if it does not. Background work uses an explicit system session that only the scheduler and scripts can create.
| Control | Detail |
|---|---|
| Sign-in | The Insight platform identity: OIDC with your identity provider, or local accounts with throttled login |
| Roles | admin (everything), compliance (runs the program), contributor (assigned work), employee (the portal only), auditor (invited audits only), viewer (read); an administrator holds every role |
| Role checks | Read from the user record on every request, not trusted from the token, so a demotion takes effect at once |
| API keys | For scripts and the push API; stored as SHA-256 only, shown once, sent as a bearer token or X-API-Key |
| Audit trail | Sign-ins and user administration in the identity audit log; program changes in the activity feed |
| Signing key | A secret-store reference in production; a deployment refuses to start on a development key outside development |
Secret fields are sealed with the platform’s sealed-secrets module: one secret per connection in your secret store (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, OCI Vault, HashiCorp Vault) when configured, otherwise an AES-256-GCM token bound to that connection’s row.
A value written ref:aws-sm://… points at a secret you already keep; it is resolved when the connector runs and never copied.
The API never returns a credential. Connection views show configuration only, and that a secret is set.
Each connector’s setup guide names the least-privilege, read-only credential it needs: an AWS role with SecurityAudit and ViewOnlyAccess assumed with an external ID, read-only tokens elsewhere.
Every integration call refuses loopback, private, link-local, CGNAT and cloud-metadata addresses; a self-hosted deployment can allow private addresses for an internal Jira or GitLab.
A failed sync records its error and marks nothing deleted, so an expired token never makes resources disappear.
| Detail | |
|---|---|
| Scope | An auditor holds the built-in auditor role and nothing else; they see only the audits they were invited to, and another audit’s id answers 404 |
| Evidence | Only evidence attached to a request of their audit, downloaded through that request |
| Console | Controls, people, vendors, integrations and settings refuse an auditor-only account |
| Changes | Auditors comment, accept or return requests, draw samples and record findings; only the team attaches evidence and only management writes a finding’s response |
| Reproducibility | Samples are drawn with a seed recorded on the audit, so the same draw can be made again |
| Detail | |
|---|---|
| Checks | Disk encryption, screen lock and timeout, firewall, anti-malware, OS updates, password manager; a check it cannot determine is sent as unknown |
| Identity | Serial, hostname, platform, OS version and the agent version; no files, browsing, process lists or user names |
| Read-only | It reads operating-system settings and never changes them |
| Binding | A personal key is an HMAC over organization and email, so a device belongs to the person who enrolled it; an organization key is stored hashed and accepts only owners who are people in the organization |
| Code | One Python file using only the standard library, served by your own deployment, readable before you run it |
Answers are written from your approved answers, published policies and controls. The model is told never to invent a certification, a number or a practice.
The live health of the controls behind each source is given with every question; a failing control is never described as in place, and names from failure reasons are not repeated.
Every drafted answer carries the sources it used, and a person approves it before it leaves.
Bedrock, Azure OpenAI, Vertex AI, OCI or an OpenAI-compatible endpoint in your own account.
With no model, or with AI switched off, every AI feature answers by rule from the same sources, with the same guard.
A model that fails is remembered for five minutes and the rule path answers meanwhile.
| Control | Detail |
|---|---|
| What it shows | Only an enabled Trust Center, and only the frameworks, control status by domain, subprocessors and documents you select |
| NDA | Optional; a request without the NDA accepted is refused |
| Access links | Valid for 30 days; the token is stored only as a SHA-256 hash; denying a request clears it |
| Abuse | Access requests are rate-limited per address, and every request notifies your compliance team |
| Deployment | VerticalServe SaaS, or self-hosted in your cloud account or data centre with Docker Compose |
| Database | Postgres 16 with a schema per product; TLS required to managed databases |
| Evidence store | Your object store: S3, Azure Blob, Google Cloud Storage, OCI Object Storage, or a local volume; every key is prefixed with the organization |
| Uploads | Up to 50 MB per file; executable types refused; downloads served with nosniff |
| Secrets | References to your secret manager in configuration, never values |
| History | Monitor results kept 400 days; evidence, policy versions and acceptances kept until you remove them |
