Security & trust
Built to be audited, not just to pass one
This platform holds your risk register, your evidence, and your audit trail. What follows is how tenancy, access, and auditability actually work, stated plainly, including what is not in place yet.
Deployment and residency
Where your data lives is your decision
Sentinel Unity supports two deployment modes. Single-tenant on-premise runs entirely on infrastructure you control, which makes data location a fact about your environment rather than a commitment you have to take on trust.
Multi-tenant SaaS is hosted, with the same row-level isolation model. Region, subprocessors, and the contractual data-location schedule are agreed per engagement.
Single-tenant, on-premise
One organisation, one deployment, in your environment. No dependency on shared hosted infrastructure.
Multi-tenant SaaS
Hosted, with strict per-company isolation and explicit company selection before any tenant data is reachable.
Tenancy
Isolation at row level
- Every tenant-scoped record carries a company foreign key; isolation is enforced at row level
- Company access is validated per request, and the active company must be explicitly selected
- No default-company or first-company fallback in critical paths
- Single-tenant deployments run the same isolation model with one company record
Active company
One context at a time
Every tenant-scoped row carries a company foreign key. Access is validated per request, and the active company is selected explicitly, so there is no default-company fallback to fall through.
Access control
Bundles, not tiers
- Permissions are individual codenames, composed into role bundles
- Bundles operate on specific lifecycle transitions, not broad CRUD tiers
- Module access granted separately at company and user level
- Per-user overrides where a standard bundle does not fit
- Configurable password policy
| Action | asset-viewer | asset-coordinator | asset-approver | asset-admin |
|---|---|---|---|---|
| View | Allowed | Allowed | Allowed | Allowed |
| Create and edit | Not allowed | Allowed | Not allowed | Allowed |
| Submit for intake | Not allowed | Allowed | Not allowed | Allowed |
| Send to review | Not allowed | Allowed | Not allowed | Allowed |
| Send back | Not allowed | Allowed | Allowed | Allowed |
| Approve | Not allowed | Not allowed | Allowed | Allowed |
| Activate | Not allowed | Not allowed | Allowed | Allowed |
| Module settings | Not allowed | Not allowed | Not allowed | Allowed |
Every module ships bundles at this granularity. Segregation-of-duties conflicts are declared as rules, with logged exceptions.
Auditability
A log that cannot be rewritten
- Append-only platform audit log that cannot be edited in place
- Module-specific audit trails alongside it for policy, findings, assets, and field assessments
- Evidence passes an explicit review step rather than being accepted on upload
- Segregation-of-duties conflicts declared as rules, with exceptions recorded rather than silently granted
Content integrity
Test content cannot reach production
- Control library releases stage a validated snapshot before publication
- Content tiers separate internal test material from production content
- A system check blocks production start-up if internal-test content is present
- Imports are refused in production-like environments
Where we are
What we do not claim
Sentinel Unity is pre-launch. We hold no third-party security certifications today, and we are not going to imply otherwise on a page about trust.
What we can do is show you the tenancy model, the permission bundles, and the audit log in a live environment, and answer specific questions from your security team in writing during evaluation. Certification work is planned; when it is complete it will be stated here with dates and scope.
Send us your security questionnaire
We will answer it against the product as it exists today, and flag anything that is roadmap rather than shipped.
Pre-launch. No third-party certifications held at this time.