Security Policy#

Last Modified: May 30, 2026 · Version 2026-05-30

This Security Policy describes the technical and organisational measures Clustra Technologies Ltd. ("Clustra", "we", "our") applies to protect the confidentiality, integrity, and availability of customer data processed through the Clustra platform. It is a companion to our Privacy Policy and our Terms of Service.

1. Purpose & Scope

The purpose of this policy is to set out the security controls that govern how Clustra develops, operates, and maintains the Service. It applies to:

• All production systems that process, store, or transmit customer data — the Next.js web application, the NestJS API server, the API builder, the studio application, and their supporting databases, caches, and storage buckets.
• All Clustra personnel, contractors, and any third party we authorise to access those systems.
• All source code, infrastructure-as-code, build pipelines, and operational tooling used to deliver the Service.

Workspace customers are responsible for configuring their workspaces in line with their own internal policies (member roles, sharing settings, retention rules), for the content they upload, and for the security of the credentials they use to sign in. This policy describes Clustra's obligations; the Data Processing Agreement governs the contractual specifics for business customers.

2. Security Ownership

Accountability for the security program sits with Clustra's executive leadership. Day-to-day ownership is distributed as follows:

• Security lead — owns this policy, the risk register, the incident response runbook, and the annual security review cycle. Contact: security@clustra.org.
• Engineering leadership — owns secure-by-default architecture, the secure software development lifecycle (SSDLC), and the technical controls described in this document.
• Data Protection Officer — owns alignment between security controls and our obligations under GDPR, the Nigeria Data Protection Act 2023, CCPA/CPRA, and other applicable privacy laws. Contact: dpo@clustra.org.
• On-call engineers — own first response to security alerts surfaced through our monitoring and alerting pipeline.

The security lead reviews this policy at least annually, on any material change to the architecture, and after every Sev-1 incident.

3. Personnel Security

The people who can touch production are the largest attack surface. We mitigate this with:

• Background checks — pre-employment screening proportionate to the role and to local law, for every employee and contractor with access to production or customer data.
• Confidentiality & acceptable use — every employee and contractor signs a confidentiality agreement and acknowledges an acceptable use policy at onboarding and at each material update.
• Security training — mandatory onboarding training covering phishing, credential hygiene, secure handling of customer data, this Security Policy, and the incident response process. Refresher training is delivered at least annually and after any material policy change.
• Role-based access — production and customer-data access is granted only after a manager-approved request that documents business need, scope, and duration. Access is reviewed quarterly and revoked on role change or termination within one business day.
• Termination & offboarding — on departure we disable identities, revoke device certificates, rotate any shared secrets the individual could have seen, and confirm hardware return.

4. Identity & Access Management

4.1 Customer-facing IAM

• Authentication options — email and password with bcrypt hashing at cost 13, Google OAuth 2.0, and optional time-based one-time password (TOTP) two-factor authentication. The TOTP shared secret is stored in our key management service (Infisical), never alongside the user record.
• Brute-force resistance — five failed attempts on an account triggers a 15-minute lockout. Login uses a timing-neutral comparison against a dummy bcrypt hash on unknown accounts so attackers cannot distinguish "wrong password" from "unknown email".
• Session model — each authenticated session is tracked in Redis with its issue time, last-used time, IP, and user agent so customers can review and revoke active sessions. Idle sessions are pruned nightly after 30 days of inactivity.
• Refresh tokens — single-use; reuse of a previously redeemed refresh token triggers full revocation of the session family on the assumption of compromise.
• Sensitive-change session revocation — password change, 2FA toggle, and OAuth provider link/unlink revoke all other sessions on the account.
• OAuth CSRF defence — the OAuth state parameter is bound to a single-use__Host-oauth-state-binding cookie (HttpOnly, Secure, SameSite=Lax, 10-minute lifetime) to prevent cross-site authorisation attacks.
• Workspace roles — Administrator, Editor, and Viewer roles scope what a member can do inside a workspace. API tokens and helpdesk-portal API keys are minted by administrators, shown in plaintext exactly once, and stored only as SHA-256 hashes with a four-character hint.

4.2 Internal IAM

• SSO with mandatory MFA for every internal account that can reach production tooling, code repositories, the cloud control plane, or customer-data systems.
• Just-in-time, time-bounded elevation for production database access. Standing access is forbidden; every action is logged.
• Least privilege at every layer. Service-to-service traffic uses short-lived credentials issued by our secrets manager (Infisical), not long-lived static keys.
• Quarterly access reviews against the role matrix; deviations are remediated within one business week.

5. Software Development Security

Our secure software development lifecycle is encoded in tooling so it cannot be bypassed by accident.

• Source control — all code lives in a private Git monorepo. Every change reaches production through a pull request that requires at least one independent review and a passing CI pipeline. Direct pushes to protected branches are forbidden.
• Static analysis & linting — ESLint, TypeScript strict mode, and a shared linting config (@clustra/eslint-config) run in CI on every pull request.
• Tests — unit, component, and integration tests run on every pull request; end-to-end tests run against a deployed preview through Playwright before merge.
• Dependency security — automated dependency vulnerability scanning, with high and critical advisories triaged on a fixed schedule (see §13).
• Secrets in source — pre-commit hooks reject obvious secret patterns; secrets only ever live in Infisical and are injected at runtime. Anything that leaks into Git history is rotated and the leak is treated as a Sev-2 incident.
• Secure defaults — DTOs validated with class-validator, parameterised queries everywhere (Drizzle ORM, TypeORM, MongoDB drivers), guard-enforced authorisation at the API layer, and tenant isolation checks at the workspace boundary.
• Threat modelling — any change that crosses a trust boundary, introduces a new data store, or modifies authentication / authorisation requires a brief threat-model review documented in the pull request.

6. Change Management

All production changes follow the same pipeline so that we can reason about, audit, and roll back every release.

• Pull request workflow — code changes require peer review, automated test success, and automated lint and type-check success before merge. Reviewers are independent of the author for any change that touches authentication, authorisation, billing, encryption, or PII storage.
• Infrastructure as code — production infrastructure is defined declaratively and changed through the same review-and-CI pipeline as application code. Out-of-band changes to production infrastructure are forbidden except in declared incident response.
• Database migrations — schema changes are codified in Drizzle migrations, reviewed in pull requests, and applied through automated migration commands in deployment pipelines. Migrations are designed to be backwards-compatible to permit zero-downtime deploys and clean rollbacks.
• Release process — changes flow staging → production with health checks at each stage. Production deploys are progressive where the platform supports it; releases are reversible on failure.
• Emergency changes — incident-driven hotfixes still go through a pull request and CI, even if expedited, and are reviewed post-merge if pre-merge review is impossible.
• Audit trail — Git history, CI logs, deployment records, and the audit-event store in MongoDB provide a complete record of who changed what, when, and from where.

7. Third-Party Vendors / Sub-Processors

We engage third parties only where they are required to deliver the Service and only under a written data processing or services agreement that includes confidentiality, security, and breach-notification obligations. The current sub-processors are:

• Hosting & infrastructure — Vercel (web hosting), DigitalOcean (server hosting), MongoDB Atlas (global user and workspace data), managed PostgreSQL (per-feature application databases), Redis (sessions, OAuth state, cache), Google Cloud Storage (uploaded files).
• Identity & secrets — Google OAuth (sign-in only; Clustra never stores Google refresh tokens), Infisical (key management for 2FA TOTP secrets, per-workspace data encryption keys, and application secrets).
• Email delivery — our transactional email provider.
• Payments — Paystack tokenises payment instruments and manages subscriptions and invoices. Clustra never stores raw card data.
• Error monitoring & product analytics — Sentry (server and browser; payload redactions applied at source for cookies, tokens, secrets, and email addresses) and PostHog (product analytics; fires only with explicit consent).
• Internal security alerting — Slack (private channel for security event alerts; the payload is limited to the event type and the scoping identifier needed for triage).

Before engaging a new sub-processor we evaluate its security posture, certifications, regulatory standing, and the data flows that the engagement will create. The list above is reviewed at least annually and on every onboarding or offboarding. A current list with locations and processed data categories is available on request from security@clustra.org.

8. Data Classification

Every piece of data we process is classified to determine the controls that apply to it. We use four tiers:

• Public — material we intend to publish (marketing pages, public documentation, aggregated and anonymised metrics). No confidentiality controls required; integrity controls apply.
• Internal — operational telemetry that does not identify customers (deploy logs, aggregate performance metrics). Access restricted to authorised personnel.
• Confidential — customer workspace content (documents, notes, calendar entries, chat, helpdesk tickets, custom database records, uploaded files). Encrypted in transit and at rest; accessed only under documented business need with an audit record (see §9).
• Restricted — identity PII (email, name), authentication secrets (password hashes, TOTP secrets, refresh tokens), payment metadata, security event records, and encryption keys. Subject to the strongest controls: envelope encryption at rest, blind indexing for lookups, separate key custody, restricted just-in-time access, and full audit logging.

Any new data store, telemetry stream, or third-party integration is assigned a classification before it ships, and the classification dictates which controls in this policy apply.

9. Employee Access to Customer Data

The default is no employee access to customer data. Specific exceptions are governed as follows:

• Business need only — access is granted only to address a specific support request, investigate a confirmed incident, or fulfil a documented regulatory obligation.
• Customer-initiated support — if resolving your support request requires us to look at workspace content, we ask for your explicit, time-bounded consent before doing so unless the request itself is impossible to address otherwise.
• Just-in-time access — privileged access to production databases or storage is granted for a bounded window, scoped to the smallest data set required, and revoked automatically on expiry.
• Audit — every privileged access is logged with the actor identity, the time window, the systems touched, and the business justification. Audit records are reviewed by the security lead at least monthly.
• No casual browsing — viewing customer content outside an approved access window is a disciplinary matter that can result in termination and notification of affected customers.

10. Encryption

10.1 In transit

All external traffic to Clustra is served over TLS 1.2 or higher. HSTS is enforced on our marketing and application properties and we maintain a strict Content Security Policy. Internal service-to-service traffic in production is authenticated and encrypted.

10.2 At rest

• Identity PII — email address, first name, and last name are stored as AES-256-GCM ciphertext under an envelope-encryption scheme. Data encryption keys are wrapped by a master key held in our key management service. A blind index (HMAC) of email enables authentication lookups without holding plaintext on the query path.
• Workspace free-text content — searchable free-text fields are encrypted under a per-workspace data encryption key wrapped by the same KMS master key. Rotating a workspace key cryptographically shreds the searchable encrypted fields scoped to that workspace.
• Two-factor secrets — TOTP shared secrets are stored in the key management service, segregated from the user record.
• Passwords — stored as bcrypt hashes (cost 13). We never store plaintext passwords and cannot recover them.
• API tokens & reset codes — single-use API tokens, helpdesk-portal API keys, email verification codes, and password reset codes are stored only as hashes (bcrypt or SHA-256 depending on shape) with a short hint for UI display.
• Underlying storage — databases, caches, and object storage that hold any of the above are themselves provisioned on platforms that provide volume-level encryption at rest, so the ciphertext sits on encrypted media.

10.3 Key management

• Keys are managed in Infisical with role-restricted access.
• Master keys are rotated on a defined schedule and immediately on suspected compromise.
• Workspace-scoped data encryption keys can be rotated on demand; rotation crypto-shreds the ciphertext that depended on the previous key.
• Keys are never present in source control, build logs, or client devices.

11. Incident Response

We treat any event that may compromise the confidentiality, integrity, or availability of customer data as a security incident.

• Detection — Sentry surfaces error and crash anomalies in the web and server applications; a sliding-window alerting service surfaces high-rate authentication failures, bulk data export requests, and abnormal member removal patterns to a private Slack channel monitored by on-call engineers; underlying infrastructure metrics page on threshold breaches.
• Triage — the on-call engineer acknowledges the alert, classifies severity (Sev-1 through Sev-4) against our runbook, and opens an incident channel. Sev-1 and Sev-2 incidents escalate to the security lead and engineering leadership immediately.
• Containment — short-term containment focuses on stopping the bleed (revoking sessions, rotating keys, isolating accounts or hosts). Long-term containment targets root cause and permanent remediation.
• Eradication & recovery — remove the underlying cause, restore affected systems from clean state, verify integrity, and only then re-open traffic.
• Notification — if we determine that a personal data breach is likely to result in a risk to the rights and freedoms of individuals we will notify the relevant supervisory authority within 72 hours (GDPR Art. 33 / NDPA s. 40) and, where the risk to individuals is high, notify affected customers and end-users without undue delay (GDPR Art. 34). U.S. state breach-notification requirements are honoured where applicable.
• Post-incident review — every Sev-1 and Sev-2 incident is followed by a written post-incident review covering timeline, root cause, customer impact, and action items, with accountable owners and due dates. Action items are tracked to completion and reviewed at the executive security review.

12. Backups & Recovery

• Backup strategy — production databases (MongoDB Atlas for global data, managed PostgreSQL for feature databases) are backed up using the managed snapshot facilities of their respective platforms. Backups are encrypted at rest using the platform's key management. Storage buckets are versioned so accidental deletes can be recovered within the retention window.
• Frequency & retention — backup frequency and retention are tuned per data store to meet our recovery objectives.
• Recovery testing — restore-from-backup is exercised on a defined cadence so that we test the restore path, not just the backup path. Failed restores trigger a Sev-3 incident.
• Account & workspace recovery — soft-deleted members are recoverable for 30 days; soft-deleted workspace items follow the same window. Hard deletion is irreversible.
• Disaster recovery — production services are hosted on platforms with regional redundancy. Catastrophic-loss scenarios are addressed by the disaster recovery plan, which is exercised on a defined cadence and updated after every drill.
• Separation of duties — backups are stored in accounts segregated from the production cloud account so that a compromise of production cannot delete or tamper with backups.

13. Vulnerability Management

13.1 Internal vulnerability management

• Dependency scanning — every pull request triggers automated dependency vulnerability scanning. Critical and high advisories are remediated to the schedule below; medium and low advisories are batched.
• Container & runtime scanning — production images and runtime configurations are scanned for known vulnerabilities and misconfigurations.
• Static application security testing — TypeScript strict mode, ESLint security rules, and code-review checklists catch entire classes of defect at review time.
• Remediation targets — Critical: within 7 days. High: within 30 days. Medium: within 90 days. Low: tracked and triaged at the next scheduled review.
• Penetration testing — independent penetration tests are commissioned periodically. Findings are tracked through to closure on the same severity SLAs above.

13.2 Coordinated disclosure (security researchers)

We welcome reports of security issues from researchers and customers. Please email security@clustra.org with:

• A description of the issue and the impact you believe it has.
• Steps to reproduce, including any required accounts, requests, or sample payloads.
• Your name or handle if you would like to be credited (optional).

We commit to:

• Acknowledging your report within 2 business days.
• Triage and an initial severity assessment within 5 business days.
• Status updates at least every 14 days until the issue is closed.
• Not pursuing legal action against good-faith researchers who follow this policy, who do not degrade the Service, who do not access, modify, or destroy customer data beyond what is strictly necessary to prove the issue, and who give us reasonable time to remediate before public disclosure.

Out of scope: denial-of-service testing, social engineering of Clustra staff or customers, physical attacks, automated scanning that generates load on production, and any activity that violates the privacy or rights of other users.

Contact

Security issues and questions: security@clustra.org.

Data Protection Officer: dpo@clustra.org.

This Security Policy is provided for informational purposes and does not constitute legal advice. Specific contractual security commitments to a customer are governed by that customer's order form and Data Processing Agreement.