Security Model
How Govula protects your data and ensures secure operations.
This section is intended for: Technical Team, Auditor, Management. Unauthorised access is restricted.
Security Principles
Govula is designed for organizations that handle sensitive compliance data. The security model is built on principles of least privilege, defense in depth, and continuous verification.
As a platform that helps organizations demonstrate compliance, we hold ourselves to the same standards we help you achieve.
Data Isolation
Each organization's data is strictly isolated from other organizations. This isolation is enforced at multiple layers:
Database Level
Tenant identifiers are enforced on all data access operations. Every query includes tenant context, preventing accidental or intentional cross-tenant data access. Foreign key relationships ensure referential integrity within tenant boundaries.
Application Level
Middleware validates tenant context on every request. API endpoints verify that requested resources belong to the authenticated user's organization. Attempts to access cross-tenant resources result in authorization failures, not data leakage.
Storage Level
Evidence files and reports are stored with tenant-specific prefixes and access controls. Object storage permissions prevent cross-tenant file access even if object identifiers were known.
Access Control
Access to the platform is controlled through a combination of authentication and authorization mechanisms:
Authentication
- API key authentication for programmatic access
- Session-based authentication for web interface
- JWT tokens for short-lived access (regulator access)
- Support for SSO integration (SAML, OIDC)
Authorization (RBAC)
Role-based access control with five default roles and customizable permissions:
- AdministratorFull system access including user management
- Compliance ManagerManage controls, evidence, and generate reports
- Security AnalystView and update control status and evidence
- ExecutiveView dashboards and executive reports
- AuditorRead-only access to SoA and evidence
Audit Logging
All significant actions are logged to an immutable audit trail. This includes:
- User authentication events (login, logout, failed attempts)
- Data modifications (control status changes, evidence uploads)
- Approval and override decisions
- Report generation and export
- Administrative actions (user management, role changes)
Audit Log Properties
- ImmutableLogs cannot be modified or deleted (enforced via database triggers)
- TimestampedAll entries include server-side UTC timestamp
- AttributedAll entries include actor identification
- ContextualEntries include metadata about the action context
Encryption
Data at Rest
- AES-256 encryption for database storage
- Encrypted object storage for evidence files
- Encrypted backups with separate key management
Data in Transit
- TLS 1.3 for all external communications
- SSL/TLS for database connections
- HTTPS enforced with HSTS
No Cross-Tenant Visibility
Organizations cannot see, access, or infer information about other organizations using the platform. This is a fundamental design principle, not a configuration option.
Cross-tenant isolation is enforced through:
- Mandatory tenant context on all database queries
- No aggregation or benchmarking across tenants
- Separate encryption keys per tenant for sensitive data
- Tenant-scoped API keys and access tokens
Input Validation
All user input is validated and sanitized before processing:
- Type checking and schema validation on all API inputs
- Length limits to prevent buffer and storage attacks
- XSS prevention through output encoding
- SQL injection prevention through parameterized queries
- File upload validation for evidence documents
Security Headers
The platform implements comprehensive HTTP security headers:
- Strict-Transport-SecurityForces HTTPS connections
- Content-Security-PolicyPrevents XSS and injection attacks
- X-Frame-OptionsPrevents clickjacking
- X-Content-Type-OptionsPrevents MIME sniffing
- Referrer-PolicyControls referrer information leakage