Permissions Power Every Capability Across Your Platform
Security shouldn't work differently depending on which product or feature someone is using.
TeamSync uses a single identity, permissions, encryption, and backup architecture across the entire platform. Whether users access documents, AI, workflows, contracts, eSignatures, or eDiscovery, the same controls apply consistently.
That gives security and compliance teams one architecture to review instead of multiple products with different security models.
Talk to a solutions engineer · Read the permissions-aware AI pillar · Read the crypto-shred pillar
What's Included In RBAC
Sub-capability | What it does |
Identity federation | Supports SAML 2.0, OIDC, and SCIM provisioning; integrates with Okta, Entra ID, Ping, Auth0, Duo, and on-prem AD |
Role-based access control (RBAC) | Roles are defined per tenant and apply across all capabilities |
Attribute-based access control (ABAC) | Access can depend on context — clearance level, project, jurisdiction |
Permission enforcement at retrieval time | Every read is checked against the user's current permissions |
Per-tenant envelope encryption | Each tenant's content is encrypted with its own key |
HSM-backed key custody | Keys are stored in hardware security modules with verified operations |
Customer-controlled keys (CMK) | The customer holds the master key; TeamSync can't decrypt content without their authorisation |
BYOK / HYOK | For workloads where regulations require the customer to control the key |
Crypto-shred | Right-to-erasure is enforced by destroying the encryption key |
File-level backup and restore | Each document is backed up individually, including its permission settings |
Audit chain on every event | Identity, permission, key, and recovery events are all logged and verifiable |
What "One Model Across Every Capability" Means In Practice
Most platforms handle identity differently for each product: one model for records, another for the AI layer, a third for eDiscovery holds. That means a security review has to check each one separately.
Pattern | Standard platform | TeamSync |
Identity federation | Configured separately per product | One identity provider, shared across everything |
Role definition | Defined separately per product | One shared role catalogue |
Permission enforcement | Varies by product | Consistent across the platform |
Encryption model | Varies by product | One encryption model |
Audit trail on permission changes | Separate log per product | One shared audit chain |
Key custody options | Varies | Customer-controlled keys available for any workload |
The question "how do you enforce permissions consistently?" has one answer instead of several.
What Do Customer-Controlled Keys Mean
Customer-controlled keys (CMK) let organisations keep control of their encryption keys, useful for sovereign deployments, heavily regulated industries, or high-stakes contractual requirements.
Pattern | What it does | When to use it |
TeamSync-managed keys | TeamSync generates, rotates, and stores the keys | Default option, suitable for most workloads |
Customer-controlled keys (CMK) | The customer holds the master key; TeamSync's key is wrapped by it | Sovereign deployments, regulatory key-custody requirements |
BYOK (Bring Your Own Key) | The customer generates and provides the key | Useful for managing keys across multiple cloud providers |
HYOK (Hold Your Own Key) | The key never leaves the customer's own HSM | For the strictest sovereignty requirements |
The key point: with CMK or HYOK enabled, TeamSync cannot decrypt customer content without the customer's authorisation. That's the answer to "What happens if TeamSync is compromised?"
What Backup and Recovery Actually Cover
Capability | What it does |
Per-document backup | Every version of every document is backed up, including its permission settings |
Point-in-time recovery | Restore to any earlier point in the audit history |
Permission-preserving restore | Restored documents keep the permissions they had at that recovery point |
Cross-region replication | Configurable for multi-region deployments |
Disaster recovery | RTO and RPO commitments depend on your support tier |
Backup audit chain | Every backup and restore event is logged and verifiable |
Crypto-shred-aware recovery | Content that's been crypto-shredded can't be recovered, by design |
Recovery respects the right-to-erasure model: once content is crypto-shredded, that deletion is permanent, even in backups.
What Changes For Security And Recovery Teams
Activity | Before | With TeamSync |
CISO review across capabilities | Separate review per product | One architectural review |
Auditing permission changes | Separate log per product | One verifiable chain |
Key custody options | Limited per product | Customer-controlled keys across the whole platform |
Backup with permissions preserved | Often incomplete | Built in |
Right-to-erasure across backups | Manual process | Enforced cryptographically |
Cross-region replication | Configured per product | Managed at the platform level |
How TeamSync Compares
The control-surface evaluation is usually part of a broader platform comparison. Common ones:
Microsoft Purview + M365 Compliance Manager: Strong within M365, but weaker on cross-source permission consistency and customer key custody
OpenText Identity & Access: Solid legacy coverage, but permissions are managed per product rather than as one system
In-house IAM + KMS + backup: Most flexible, but building a consistent model across all of it is left to you
For specific comparisons:
Read Further
Why TeamSync — permissions-aware AI — what the permission model enables for AI
Why TeamSync — crypto-shred — what the encryption model enables for right-to-erasure
Why TeamSync — tamper-evident audit — the chain every event anchors to
CISO + Audit Committee page — the executive conversation