Security built into the governance control plane.

1. Security approach

Civerent treats customer security as a core product requirement. Security controls are designed around organization isolation, least privilege, controlled data operations, traceability, and secure defaults.

This page describes controls currently represented in the Civerent architecture. It does not claim that any control eliminates risk or that Civerent has obtained an independent certification that is not expressly listed.

2. Identity and access

• Authenticated sessions are handled through the configured identity and database platform.
• Protected dashboard routes require validated authentication claims.
• Workspace access is based on organization membership and defined roles.
• Sensitive management operations enforce owner, administrator, member, or viewer authority according to the operation.
• Server-side operations independently validate authentication and authorization rather than relying only on the interface.

3. Tenant and data isolation

• Organization identifiers scope governed records and database operations.
• Row-level security policies restrict authenticated access according to workspace membership.
• Organization-scoped foreign keys protect Evidence Graph relationships from cross-workspace linking.
• Controlled database functions validate target ownership before performing sensitive operations.
• Private helper functions and locked search paths reduce unintended database-function exposure.

4. Integrity and traceability

• Governance activity records provide traceability for supported operations.
• Evidence versions and evidence activity records are protected against ordinary mutation.
• Optimistic concurrency checks reduce silent overwriting of evidence updates.
• Report exports use private, no-store responses and protect CSV cells against spreadsheet formula interpretation.
• Public server errors avoid returning internal database and connection details.

5. Secure development controls

• Linting and TypeScript checks are enforced before checkpoints.
• Security-sensitive server modules are covered by automated tests.
• The enforced application coverage boundary currently requires complete statement, branch, function, and line coverage for included modules.
• Dependency vulnerability scans and production builds are run as release checks.
• Database changes are forward-only migrations with static security checks and production verification.

6. Infrastructure and providers

Civerent relies on service providers for capabilities such as hosting, authentication, databases, and network delivery. Provider controls form part of, but do not replace, Civerent security responsibilities.

Specific subprocessors, deployment regions, contractual safeguards, backup commitments, and enterprise security terms should be confirmed during procurement before relying on them for a regulated workload.

7. Security events

Suspected security events are evaluated according to their scope, affected information, service impact, and applicable contractual or legal requirements.

Civerent will communicate with affected customers when notification is required. Response timing and contractual commitments may be defined in an applicable enterprise agreement.

8. Responsible disclosure

• Report the affected URL, feature, or service area.
• Describe the observed behavior and potential impact without accessing information that does not belong to you.
• Use test accounts and minimal proof necessary to explain the issue.
• Do not conduct denial-of-service testing, destructive testing, social engineering, or physical attacks.
• Allow reasonable time for investigation and remediation before public disclosure.

9. Current assurance position

Civerent is an early-stage platform and does not currently claim SOC 2, ISO 27001, FedRAMP, StateRAMP, or other independent certification unless a later written statement explicitly confirms it.

Architecture, automated tests, database controls, and internal verification are not substitutes for an independent audit. Enterprise and government buyers should evaluate current evidence during procurement and define any required assurance roadmap contractually.