Security and trust

Security & Trust Centre.

If you are assessing Klarvant as a supplier, this page is written for you. It sets out how Namespace Command is built, hosted and operated, how your data is protected, and how those controls are tested. The summary below answers the questions that open most assessments; the sections that follow give the detail behind each one.

Built on security-first principles, with enterprise-grade protection.

At a glance

The one-minute assessor summary.

RowValue
HostingGoogle Cloud Platform, independent regional deployments
Data residencyUK (London), EU (Netherlands), US (Iowa); database, backups and derived audio in-region; per-region encryption keys
Encryption at restAES-256 everywhere; dedicated per-region keys in Google Cloud KMS on databases and content stores, automated 90-day rotation
Encryption in transitTLS 1.2+ (modern profile), HTTPS-only, HSTS; hybrid post-quantum key exchange (ML-KEM) on TLS 1.3
AuthenticationPasswordless: Google/Microsoft SSO (OIDC) or single-use email links; no stored passwords
Tenant isolationPostgreSQL row-level security on all customer-data access, plus separate regional databases
Access to customer systemsNone. No agents, no credentials; publicly observable data only
Independent testingAnnual external penetration test (OWASP/PTES); last completed 2025, next September 2026
Availability99.9% target per environment, continuously measured out-of-band, monthly reports; zone-redundant application tier with live database standbys

Klarvant Namespace Command™ is a cloud-hosted platform built on Google Cloud Platform, with security, privacy, and compliance at its core. We maintain transparent security practices and undergo regular independent assessments.

Platform architecture

Enterprise-grade infrastructure, global resilience.

Google Cloud Platform

Hosted on Google Cloud Platform as independent regional deployments in the UK (London), EU (Netherlands) and US (Iowa), so customer data stays in-jurisdiction.

Defence in depth

A global HTTPS load balancer, Google Cloud Armor WAF and VPC firewalls at every layer, with OWASP Core Rule Set inspection, per-IP rate limiting and adaptive Layer-7 DDoS protection.

Zero-integration design

No agents, no API keys, no privileged access required. Assets are discovered from public sources without expanding your attack surface.

Group

Protecting your data.

Data protection and encryption

Encrypted at rest and in transit.

Encryption at rest

  • AES-256 encryption for all data stored on GCP (databases, logs, backups).
  • Customer-managed encryption keys in Google Cloud KMS, held per region so UK and EU key material stays in-jurisdiction, with automated 90-day rotation.
  • Deletion protection on all database hosts, with cryptographic erasure (NIST 800-88 aligned) for decommissioned storage.

Encryption in transit

  • TLS 1.2+ enforced via GCP SSL policy for all external connections.
  • HTTPS-only access through the global load balancer with automatic TLS termination.
  • Internal encryption for traffic between Google Cloud services.
  • Email over TLS for automated notifications.
  • Hybrid post-quantum key exchange (ML-KEM, NIST FIPS 203) on TLS 1.3, protecting customer sessions against harvest-now-decrypt-later attacks: the same migration we help our customers govern.

Data classification and handling

A Data Classification and Handling Policy with three levels:

  • Public: information intended for public distribution.
  • Internal: business information for internal use only.
  • Confidential: sensitive data requiring strict protection controls.

Data lifecycle management

  • Environment separation: customer environments are strictly separated per region.
  • Pre-production data: pre-production environments hold externally observable assessment data used for validation; customer configuration data enters non-production only as part of controlled onboarding, under the same access controls and encryption as production.
  • Secure deletion: cryptographic erasure (NIST 800-88 aligned) for decommissioned storage.

Access control and authentication

Least-privilege access, full audit trails.

Authentication and identity

  • Passwordless authentication: Google or Microsoft single sign-on (OIDC), or short-lived single-use email sign-in links. No passwords are ever stored or managed.
  • Multi-factor and risk-based challenges are inherited from your identity provider; privileged platform-operator actions require additional TOTP step-up verification.
  • Layered sign-in abuse protection: per-IP rate limiting at the WAF and in the application, and strict limits on sign-in link issuance.
  • Hardened session handling: host-locked cookies (Secure, HttpOnly, SameSite=Strict), 256-bit session tokens stored only as hashes, bounded lifetime, per-session device records, and a "sign out everywhere else" control that ends all other sessions.

Access management

  • Role-based, least-privilege access on per-environment service accounts.
  • Infrastructure as code: firewall rules and infrastructure are defined in code and reviewed through change control.
  • Comprehensive audit logging of all access and administrative actions.
  • Restricted physical access via Google Cloud data-centre controls (CCTV, biometrics, guards).

Group

How we build and run.

Secure software development

Security in every phase.

Development

  • OWASP-aligned secure coding standards
  • Mandatory peer code review
  • Static Application Security Testing (SAST)
  • Threat modelling and security requirements

Testing

  • Dynamic Application Security Testing (DAST)
  • Automated vulnerability scanning
  • Input validation and injection prevention
  • Production and non-production segregation

Release

  • CI/CD pipeline with security gates
  • Automated testing before deployment
  • Change management with risk assessment
  • Debug-code removal verification

GitHub security controls

Private repositories with MFA enforcement, role-based access, and audit logging. Source-code access is restricted to authorised developers only.

Network and application security

Multi-layered defence.

Cloud Armor WAF

  • L3/L4/L7 DDoS protection, with Google's global Anycast network absorbing volumetric attacks.
  • Rate limiting and throttling to prevent abuse and resource exhaustion, with stricter limits on authentication endpoints.
  • Layer-7 inspection of HTTP requests against the OWASP Core Rule Set, with adaptive protection that tunes rules to traffic patterns.

Network controls

  • VPC firewall rules with default-deny and least-privilege network access.
  • Network segmentation isolating production, staging, and development.
  • VPC Flow Logs monitored for network-anomaly detection.
  • Change-controlled network rules: firewall configuration is defined as code and reviewed through change control.

Application security

  • Input validation and parameterised queries preventing SQL injection.
  • Output encoding preventing cross-site scripting (XSS).
  • API default-deny: the public API accepts no traffic until you configure an IP allowlist; keys are scope-limited, rate-limited and stored only as hashes.
  • Secure error handling preventing information disclosure.
  • Tenant isolation in the database: all customer-data access is governed by PostgreSQL row-level security policies scoped to your organisation, executed by a restricted database role, on top of fully separate regional databases. Isolation is enforced below the application code.
  • First-party code only: no third-party scripts, styles or fonts anywhere in the application. All executable code and styling is served first-party under a content security policy; the only external content loaded is public map imagery from an explicit allowlist.

Operating-system hardening

  • Ubuntu LTS minimal images on virtual machines; the application tier runs on Google-managed serverless infrastructure.
  • Critical patches applied immediately, with customer notification.

Release and assurance

Discipline at release, continuous under load.

Release integrity

Standard releases soak in pre-production for at least 24 hours, then roll out region by region, each region approved by a named engineer, running the exact artefact that was tested. Images are promoted, never rebuilt. Emergency fixes follow a documented expedited procedure through the same per-region approval gates.

Continuous assurance

Static analysis (CodeQL) and dependency vulnerability scanning run on every change, with weekly automated dependency updates. Synthetic monitoring probes every five minutes, including negative authentication tests.

Monitoring and incident response

Continuous visibility, rapid response.

Continuous monitoring

  • Google Cloud Operations for infrastructure and application performance monitoring.
  • Comprehensive audit logging of all administrative actions and security events.
  • Automated alerting for suspicious activity and threshold violations.
  • Log retention with tamper-proof storage and restricted access.
  • Regular log reviews for security-event analysis.

Incident management

  • Formal incident-response policy with defined roles and procedures.
  • Rapid escalation paths for security incidents.
  • Customer notifications for incidents affecting service availability or data.
  • Post-incident reviews and a continuous-improvement process.
  • Vulnerability disclosure programme via .

Group

Assurance and testing.

Compliance and independent testing

Verified through regular assessment.

Penetration testing

  • Annual independent testing by a third-party security firm using OWASP/PTES methodology, with remediation verified by retest.
  • Most recent engagement completed in 2025. The 2026 engagement is scheduled for September 2026.
  • Summary attestations are available to enterprise customers under NDA.

Internal audits

  • Logging and monitoring reviews covering access and security events.
  • SDLC control audits ensuring secure development practices.

Standards and frameworks

Development

  • OWASP SAMM
  • Secure SDLC
  • SAST / DAST

Architecture

  • CSA best practices
  • Google Cloud Security Reference
  • Defence in depth

Data protection

  • NIST 800-88 (secure deletion)
  • NIST SP 800-57 (key management)
  • GDPR

Group

Resilience.

Business continuity and resilience

Built for availability and recovery.

Regional deployments

Independent regional deployments in the UK, EU and US keep customer data in-jurisdiction. Regional customer environments are never connected to each other.

Backup and recovery

Automated daily and weekly encrypted database snapshots (7-day and 6-month retention), stored in-region to preserve data residency, with deletion protection on all database hosts and restore procedures verified by an automated weekly restore test.

Availability

A 99.9% availability target per environment, continuously measured by out-of-band synthetic monitoring with monthly reports. The application tier runs on zone-redundant managed infrastructure, and each production database maintains a live streaming standby in a second availability zone under a documented failover procedure.

Change management

The Platform Update Policy defines risk-based change categories with appropriate notification windows and rollback procedures:

Patch

Immediate, security-critical fixes

Maintenance

Minor updates, 24h notice

Minor

Feature updates, 72h notice

Major

Breaking changes, two weeks' notice

Security contact.

We welcome security researchers, customers, and collaborators to contact us on security matters. For vulnerability disclosures, please include detail on the issue, steps to reproduce, and any supporting materials. We typically respond within one to two working days.

Security and vulnerability disclosure

Security documentation is available to enterprise customers on request.