Access by role
Permissions determine who can view data, change it and make decisions.
Check access and data-handling rules.
Review the safeguards before sharing data.
Choosing a tool requires specific answers about access, processing and recovering your information. Clear roles help you delegate work without involving the leader in every handoff.
Change history
Keep changes and decisions with the relevant item.
Data export
Data export is included in every plan. Download scope depends on permissions.
Named service providers
Review the current list of data processors and the documents covering your selected service.
We describe security through concrete mechanisms, documents, and responsibilities: from sign-in and data access to the audit trail. Nebius Token Factory handles non-RAG AI inference in the EU, with Zero Data Retention (ZDR) for prompts and responses.
Identity & Access
Zero-trust authentication and authorization
External sign-in provider
the identity provider managed by Brillnet handles sign-in. The application does not store local passwords. Identity, membership and roles are tied to the selected organization; MFA is required for owners, administrators, compliance officers, approvers and auditors.
Roles and limited support access
Roles follow permissions assigned within the organization. Brillnet has no permanent support access; exceptional support access requires consent, a defined scope, expiry time and an audit record.
Policy engine
Before an important action is performed, the system checks who is acting, which object is affected, and why. A missing access basis should block the action.
Four-eyes approval workflow
Higher-risk actions can require approval from a second person. The decision, rationale, and approval time remain visible in the process history.
Data Protection
Encryption, classification, and data scope
Data scope and object access
Define which data enters documents and evidence and who may view, change or export it. Read, write and approval permissions are separate. Minimize personal data and material supplied for diagnostics.
Agreed encryption-key model
The encryption-key model is agreed during implementation and documented for the confirmed service scope.
Least-privilege database access
Technical database access is limited to the scope needed by each part of the system. Pre-release tests check that access has not become too broad.
Export approval gate
Exports of confidential or personal data can require an additional approval. If required approvals are missing, the export is blocked and recorded in the history.
Audit Trail
Operation history and integrity checks
Event log with integrity verification
History records time, user, action, object and version. Administrators may view and export it but cannot change or delete entries. Document version integrity is checked using checksums; we do not claim a cryptographic chain for every event.
Evidence package with scope and history
An evidence package includes the list of items, data scope, and operation history. This helps an auditor see what was shown and which period it covers.
Organization data isolation
Each organization has its own data area with a separate database, file store, audit and encryption context. Documents, evidence and AI content are not stored in the shared operational layer or exposed to another organization.
Access log for evidence packages and exports
Every evidence package download, export, or report leaves a trace: who, when, which data scope, and for what purpose.
Infrastructure and releases
Security checks before changes are released
Security gate
Before release, dependencies, known vulnerabilities, and basic security risks are checked. High-risk changes should not be released without a decision from the responsible person.
Library controls
The list of libraries and versions is kept repeatable. Known unsafe versions should be blocked or moved into a fast update path.
Hardened error tracking
Error logs should remove personal data, access tokens, and other sensitive information. The goal is to diagnose problems without exposing customer data.
Sign-in process monitoring
The sign-in process is monitored because it affects evidence access and user accountability. Sign-in issues are treated as an operational risk.
Security update path
Important vulnerabilities have an owner, remediation status, and priority decision. This keeps security updates from disappearing into the regular work queue.
Security package
Materials for people reviewing the service
We are happy to share and discuss materials needed to review the service. We explain security clearly, without technical jargon.
Data processing agreement and providers
We can discuss the data processing agreement template and the list of providers supporting the service.
Data storage and backups
We explain where data is stored, how backups work and how they help protect continuity.
Incident procedure
We describe how to report a problem, who stays in touch and how communication works.
Security rules
We show how we keep order, manage access to data and assign team responsibility.
Using Pulsar alone does not certify your organization or guarantee compliance. Marketing-site and application documents cover different scopes.
Security — FAQ
Where is data hosted?
By default, we assume data hosting in the European Union. Exact location, retention, and infrastructure requirements are confirmed in the implementation agreement.
Can I use my own encryption keys?
Yes, if agreed in the implementation scope. In that case we describe who manages encryption keys, how key rotation works, and who is responsible for access to them.
How is tenant isolation ensured?
Organization data isolation is part of pre-release testing. Backup, restore, and disaster-recovery scope are confirmed in the implementation arrangements.
How is audit-trail integrity verified?
History records time, user, action, object and version. Administrators may view and export it but cannot change or delete entries. Document version integrity is checked using checksums; we do not claim a cryptographic chain for every event.