Security & Trust
Security built into the platform architecture
Sentinel Unity is pre-launch. This page describes how the platform is designed and operated, not certifications we hold today. For regulated enterprises across the Gulf, tenancy, access control, auditability, and data handling are first-class engineering concerns, not marketing add-ons.
Architecture
How security is structured on the platform
A single GRC data model still requires strong boundaries between customers, entities, and roles. These pillars reflect what is built into the product today.
Multi-tenant segregation
Customer organizations operate in separate tenant boundaries, with entity-scoped data inside each tenant.
Role-based access
Granular permissions by module and action, plus module-level access aligned to GRC team responsibilities.
Audit logging
Platform activity is logged so teams can answer who changed what, when, and in which context.
Authentication controls
Configurable password policy and authentication settings to match your security baseline.
Data handling
Encryption in transit and at rest as design intent, with backup and retention practices for operational resilience.
Engagement-specific residency
GCC deployment and data-location requirements are scoped and documented per customer engagement.
Multi-tenant design
Data segregation by tenant and entity
Each customer organization runs in its own tenant. Within a tenant, legal entities, locations, and departments define how risks, assessments, and evidence are scoped, which is essential for groups with subsidiaries in Bahrain, Kuwait, Oman, Qatar, Saudi Arabia, and the UAE.
- Dedicated tenant boundary per customer organization
- Legal entities, locations, and departments scoped within a tenant
- Users see only data their role and entity mandate allow
- Designed for holding groups operating across multiple GCC markets
Tenant boundaries (illustrative)
Customer data scoped per tenant; entity-level boundaries within a tenant.
Access control
RBAC with granular and module-level permissions
The Access Control module defines roles, assigns permissions by module and action, and enforces module access so CISO, risk, compliance, and audit teams work in the same platform without over-privileged accounts.
- Predefined and custom roles for risk, compliance, audit, and administration
- Permissions at module level and per operation (view, edit, approve, etc.)
- Module access toggles for teams that need subset capabilities
- Supports segregation of duties on sensitive workflows
Authentication
Password policy and auth controls
Administrators configure password rules and authentication settings to match organizational policy, a baseline expectation for regulated environments, without claiming third-party certification of the platform itself.
- Configurable password complexity, expiry, and lockout rules
- Authentication settings aligned to your organization's policy
- No shared credentials; individual accounts with role assignment
- Consistent access model across all GRC modules on the platform
Example policy settings
- Minimum length
- 12 characters
- Complexity
- Upper, lower, number, symbol
- Session timeout
- Configurable
- Failed attempts
- Lockout threshold
Illustrative defaults; actual configuration is set per tenant.
Auditability
Full platform audit logging
GRC work must be defensible under examination. Platform-wide logging records material changes alongside module-specific histories in findings, policies, and assessments.
- Immutable-style logging of user and configuration changes
- Context preserved for assessments, findings, and administrative actions
- Supports internal audit and regulatory examination workflows
- Complements module-level audit trails in findings and remediation
Platform audit log
- 14:02
Role updated
Admin
- 11:47
Assessment submitted
Compliance
- 09:15
Evidence uploaded
Risk Owner
Who changed what, when, retained for accountability.
Data handling
Encryption and backups as design intent
We design for protection in transit and at rest, with backup practices for recovery. We do not publish fabricated audit reports or penetration-test summaries on this site. Those are shared under NDA when appropriate for your evaluation.
- TLS for data in transit between clients and platform services
- Encryption at rest for stored application and customer data
- Scheduled backups with retention aligned to operational requirements
- Cloud region, subprocessors, and retention schedules confirmed per engagement
Data protection layers
In transit
TLS for client and API traffic
At rest
Encryption applied to stored data
Backups
Scheduled backups with retention policy
Design intent; deployment specifics are agreed per engagement.
Data residency
Your GRC data stays in the region
Sentinel Unity is designed to run on AWS infrastructure in the Middle East, keeping your organization's GRC data within GCC borders. For regulated enterprises in Saudi Arabia and across the Gulf, in-region hosting is a baseline requirement — not a configuration option.
- Hosted on AWS Middle East infrastructure — data does not leave GCC borders
- Backup and retention within the same region, not routed internationally
- No cross-border data transfer by default
- Exact region code, subprocessors, and contractual data-location schedule confirmed per engagement
Whether you operate in one GCC market or run a multi-entity group spanning several, the specific region code, subprocessor list, and contractual data-location schedule are documented and agreed with you during evaluation — not left to assumption.
Framework alignment & certifications
Supports GCC mandatory frameworks; formal certifications on the roadmap
The platform is built to help regulated organizations manage their obligations under GCC frameworks: NCA ECC, SAMA CSF, and PDPL — mapping controls, tracking assessments, and maintaining evidence for these regimes. Platform security practices are being aligned with the control objectives of ISO/IEC 27001 and the NIST Cybersecurity Framework.
We do not claim ISO 27001 certification, SOC 2 attestation, or any other formal third-party certification of the platform at this stage.
Formal certifications remain on our roadmap. When achieved, this page will be updated with accurate scope and validity — not before.
Responsible disclosure
Report a security concern
If you believe you have found a security vulnerability in Sentinel Unity, we welcome responsible disclosure. Please provide enough detail for us to reproduce the issue, and allow reasonable time for investigation before public discussion.
Email security@sentinelunity.com with a description of the issue, affected component, and steps to reproduce. We will acknowledge receipt and coordinate on next steps.
Questions about security for your evaluation?
Request a demo or contact our team to walk through tenancy, access control, logging, and data handling in the context of your GCC entities and frameworks.