Security and trust

Canonical artefact metadata

Owner

CyberSec Legal and Trust Office

Approver

CyberSec Executive Governance

Version

1.0.0

Last reviewed

2026-04-20

Next review due

2026-10-20

Security by design

Security controls are built into the first implementation of every privileged action, export path, mutation endpoint, parser flow, and any operation carrying cross-tenant risk. We do not treat security as a layer added after delivery — it is part of the acceptance criteria for every feature.

• Authentication and authorization are validated on every request, including API routes and server-rendered platform pages.
• Inputs crossing trust boundaries are validated with schema enforcement before processing.
• Error responses are sanitized — internal implementation detail and exception messages are never returned to clients.
• State-mutating operations use POST/PATCH/DELETE; GET endpoints are safe and do not produce side effects.

Tenant isolation

Your workspace data is isolated from all other tenants. Every read and write path enforces tenant context. Cross-tenant data joins are not permitted by design — a bug in one customer's workflow cannot expose another's data.

This isolation model is not a runtime policy applied on top of a shared data store — it is enforced at the query and authorization layer, meaning the platform cannot accidentally return data outside your tenant boundary.

Data handling and minimization

We store what is required to operate the platform on your behalf — risk scores, vulnerability records, assessment history, governance snapshots, and operational audit events. We do not collect background telemetry from your environment beyond what you explicitly ingest through a configured integration or upload.

API keys are stored as one-way hashes. Plaintext secrets are presented once at creation time and are not recoverable afterward. This means a database breach does not expose usable API credentials.

Integrity and governance

Board packs and generated reports are produced as point-in-time snapshots. Once created, a snapshot cannot be modified retroactively — the record you share with your board reflects exactly what the platform assessed at that moment, regardless of subsequent changes to the underlying data.

Sensitive platform actions — including status changes, report generation, API key operations, and integration events — are written as append-only audit events. This log cannot be edited or deleted, preserving a verifiable record for governance, compliance reviews, and incident investigations.

Session and access security

Platform sessions are cryptographically signed. Tampering with a session cookie invalidates it immediately — the platform verifies the signature on every authenticated request, including at the edge before any server-side processing begins. Expired or malformed sessions are rejected and cleared without server round-trips.

API key authentication uses a scoped key model. Each key carries an explicit set of permitted operations. Failed authentication attempts are rate-limited per source and recorded as audit events, allowing you to detect and investigate credential abuse.

Encryption and key management

All communication between clients and the platform is encrypted in transit. Production deployments enforce encryption at rest for managed data stores. Credentials and secrets are rotated through approved secret-management workflows, and access is restricted to least-privilege operational policies.

Security-relevant response headers — including strict transport security, content-type options, frame controls, and a restrictive Content Security Policy — are applied to every response.

Security assessments

We conduct periodic internal security reviews and welcome external assessment of the platform. When material findings are identified through internal review or external research, we remediate them and are transparent with affected customers about the nature and scope of any impact.

We do not claim a defect-free platform. We do commit to addressing verified security issues with appropriate urgency and to notifying affected tenants where a confirmed issue could have impacted their data or workflows.

To report a suspected vulnerability, see our responsible disclosure policy.