Road Protect Fleet — Architecture & Security Overview


Document	Architecture & Security Overview
Version	2.0
Date	2026-06-30
Classification	Confidential
Owner	Road Protect — Platform Engineering
Intended audience	Partner / external integrator security & architecture reviewers
Status	Approved for NDA distribution
Supersedes	v1.0 (2026-06-23) and the Information Security & Cyber companion — both are consolidated into this single document

0. Document Control

This document describes the production architecture and security posture of the Road Protect Fleet platform for an external organisation evaluating a partnership or integration. It is written for a technical audience — security reviewers, solution architects, and engineering leads — and is intended to answer the questions a vendor due-diligence, information-security, or onboarding process typically raises.

What this document is. A faithful, high-level description of how the system is built and protected: where it runs, how clients authenticate and are authorized, how data and documents are stored and encrypted, how the database is managed, how secrets are handled, how software is built and shipped, how activity is audited, how the service stays available, and how a request flows end-to-end.

What this document is not. It contains no secrets, credentials, private keys, connection strings, or exploitable configuration values. Where a control has a tunable parameter (token lifetimes, cryptographic cost factors, specific managed-rule identifiers, rate-limit thresholds, exact recovery objectives), the document describes the mechanism and its security property rather than the exact value, in line with responsible-disclosure practice for externally shared material. Exact figures and configuration evidence are available to the partner's security team under NDA.

How to read the diagrams. Diagrams follow the C4 model convention — System Context first, then Containers (deployable units), supported by data-flow and sequence diagrams. Trust boundaries are drawn as dashed groupings. Every diagram is rendered in Mermaid and is reproducible from the source of this document.

1. Executive Summary

Road Protect Fleet is a cloud-native, multi-tenant SaaS platform that helps fleet operators and their partners manage traffic infringements end-to-end: ingesting and normalising fines onto a canonical data model, attributing them to vehicles, drivers and contracts, and driving downstream workflows such as nomination, appeal and payment automation.

The platform runs entirely on Google Cloud Platform (GCP) in the europe-west1 region (EU data residency), on a managed Kubernetes foundation (Google Kubernetes Engine) for the core microservices and the current web UI, and on Cloud Run for the new web UI. It is delivered through a GitOps continuous-delivery pipeline and operated under a defense-in-depth security model.

Security highlights covered in this document:

Edge protection by a Google Cloud Armor Web Application Firewall (WAF) with OWASP Core Rule Set managed rules, Layer-7 DDoS defense, and per-client rate limiting, fronted by a global Layer-7 load balancer and managed TLS.
Strong authentication: salted, adaptively-hashed passwords; time-boxed, server-revocable session tokens; and two-factor authentication via WebAuthn passkeys and SMS one-time passwords.
Least-privilege authorization with role-based access control and account-scoped tenant isolation.
Encryption everywhere that matters to an external party: TLS 1.2+ for all external traffic and provider-managed AES-256 encryption at rest for the database, object storage, and backups.
Fully managed data services: Cloud SQL for PostgreSQL with regional high availability and automated backups, and Cloud Storage for documents with private, IAM-governed access.
Secret hygiene: no secrets in source code or container images — all secrets are sourced from Google Secret Manager through the External Secrets Operator using Workload Identity.
Auditability: security-relevant actions are recorded to an immutable audit trail and exported to a BigQuery analytics store with PII redaction.

1.1 Defense-in-depth at a glance

A request — and the data behind it — passes through independent control layers, so that no single control is a single point of failure:

[Diagram]

Figure 1.1 — The control layers a request and its data pass through. Each layer is independent.

1.2 Security control summary

Domain	Mechanism (summary)	Detail
Network / edge	Single hardened edge: global L7 load balancer, Google-managed TLS, Cloud Armor WAF with OWASP Core Rule Set, adaptive L7 DDoS protection, per-source rate limiting. Private GKE node pools; database over private VPC.	§4
Authentication	First-party password auth (client-side pre-hash + server-side salted adaptive hash), account lockout, CAPTCHA, rate limiting; signed, time-boxed, server-revocable JWT sessions; 2FA via WebAuthn passkeys and SMS OTP.	§5
Authorization	Per-request RBAC with database-driven roles, account-scoped tenant isolation, resource-ownership guards, separated privileged classes, fully-audited administrative impersonation.	§6
Encryption	TLS 1.2+ for all external traffic; AES-256 at rest (provider-managed) for database, object storage, and backups; internal traffic on a private VPC.	§9
Data & document security	Private, IAM-governed Cloud Storage buckets (uniform bucket-level access, public-access prevention); documents served only via authenticated proxy or short-lived signed URLs; upload type/size validation; checksum-verified writes.	§7
Secrets	No secret in source, image, or manifest — all secrets in Google Secret Manager, delivered via the External Secrets Operator using key-less Workload Identity.	§10
Supply chain / CI-CD	GitOps (Argo CD) delivery; PR-gating secret scanning (gitleaks); weekly dependency vulnerability audit and DAST (OWASP ZAP); gated, reversible database migrations; immutable, commit-traceable artifacts.	§11
Audit & monitoring	Immutable, PII-redacted audit trail exported to BigQuery for long-term retention; structured logging, metrics, and alerting-as-code.	§12
Availability / resilience	Regional high-availability database with automatic failover; stateless, horizontally-autoscaled services; zero-downtime rolling deploys; automated encrypted backups; isolated staging environment.	§13

The remainder of the document walks the system top-down (Context → Containers), then through each control domain, and closes with a shared-responsibility matrix and compliance posture.

2. System Overview & Hosting

2.1 What the platform does

Road Protect Fleet is the core platform that manages infringements and fleets. It is complemented by an automation engine — an internal integration service that automates submission and payment workflows and returns their results to the platform asynchronously. The two communicate over authenticated HTTPS using a shared API key (see §5.5).

2.2 Where it runs

Dimension	Detail
Cloud provider	Google Cloud Platform (GCP)
Region	`europe-west1` (EU — single-region residency for primary data)
Core compute	Google Kubernetes Engine (GKE) — managed Kubernetes, private node pools, autoscaling
Web UI	GKE for the current UI; Cloud Run (fully managed, serverless containers) for the new UI
Primary database	Cloud SQL for PostgreSQL 15 (regional, high-availability)
Object storage	Google Cloud Storage (private buckets)
Analytics store	BigQuery (audit & reporting)

2.3 Public entry points (domains)

The platform exposes its user-facing surface over HTTPS, TLS-terminated by Google-managed certificates. Two web-UI hostnames are served today — the established production UI and a new UI being rolled out alongside it:

Surface	Domain	Hosting	Status
Web UI — current	`fleet.roadprotect.co.il`	GKE, behind the global L7 ALB + Cloud Armor WAF	Current production UI
Web UI — next	`fleet-v2.roadprotect.co.il`	Cloud Run	New UI — in progressive rollout

Both UIs call the platform API over HTTPS. The API is fronted by the managed edge described in §4 (global load balancer + Cloud Armor WAF), and its CORS policy allowlists exactly these UI origins.

2.4 Environment separation

The platform runs as fully isolated environments — a production environment and a staging environment — on separate Kubernetes clusters, with separate databases, separate secrets, separate edge load balancers, and separate WAF policies. Code is promoted to production only after passing through staging. This separation is enforced structurally by the GitOps delivery model (§11), not by convention.

2.5 Tenancy model

The platform is multi-tenant. Each customer (a Partner, and the Accounts/companies beneath it) is a logical tenant. Tenant isolation is enforced at the application layer: every authenticated request carries the caller's account context, and data-access queries are scoped to that context (see §6). Administrative roles that legitimately cross tenant boundaries are themselves audited (see §12).

[Diagram]

Figure 2.1 — C4 System Context. Who and what interacts with the platform, and where it runs.

3. High-Level Architecture

3.1 Architectural style

The platform follows a containerized microservices architecture orchestrated by Kubernetes. Each service is a single-purpose, independently deployable unit with a well-defined interface; services communicate over the cluster's private network, and only a curated subset is exposed publicly through the edge. State is externalised to managed services (database, object storage, cache), so application containers are stateless and horizontally scalable.

3.2 Container inventory

Container (role)	Responsibility	Exposure
API service	Core REST API and business logic (NestJS)	Public, via WAF
Slow-query API	Isolated pool for heavy/long-running queries and exports	Public, via WAF
Web UI	Web front end — current UI (GKE) and new UI (Cloud Run)	Public
Queue workers	Asynchronous background jobs (queue-driven)	Internal only
Scheduler	Time-based jobs (scheduled exports, maintenance)	Internal only
Messaging gateway	Outbound SMS / one-time-password delivery	Internal only
Document services	Document storage, rendering and OCR	Internal only
Analytics	Self-service reporting (Metabase)	Public, via WAF
Integration/automation engine	Browser-based workflow automation	Internal
Cache & queue backing store	In-cluster cache and job-queue state (Redis)	Internal only

Managed GCP services underpin the containers: Cloud SQL (PostgreSQL) for transactional data, Cloud Storage for documents, BigQuery for audit/analytics, Secret Manager for secrets, and Artifact Registry for container images.

[Diagram]

Figure 3.1 — C4 Container view. Deployable units, their exposure, and the managed services they depend on.

4. Network & Edge Security

All external traffic enters through a single, hardened edge. The platform uses the Kubernetes Gateway API with Google's global external Application Load Balancer, fronted by Google Cloud Armor as the Web Application Firewall.

4.1 Layered edge controls

[Diagram]

Figure 4.1 — Edge request path. Each stage is an independent control.

TLS everywhere at the edge. All public hostnames are served over HTTPS with Google-managed certificates that auto-renew; plain HTTP is permanently redirected to HTTPS. Standard browser security headers (HSTS, anti-clickjacking, no-sniff) are applied.
Web Application Firewall. Cloud Armor enforces the OWASP Core Rule Set managed rules (SQL-injection and cross-site-scripting families among them), tuned to production traffic to minimise false positives while keeping genuine-attack detectors active. The WAF policy is attached to every public backend, not just the API.
DDoS protection. Cloud Armor Adaptive Protection provides automatic Layer-7 volumetric-attack detection and mitigation at Google's network edge.
Rate limiting. The edge applies per-source rate limiting; the application layer adds a second, action-aware rate-limiting tier (see §5.6) — defense in depth against brute-force and abuse.
Managed-rules-as-code. The WAF policy is maintained as version-controlled infrastructure with a documented change/runbook process, so edge security is reviewable and reproducible rather than ad hoc.

4.2 Private networking

GKE runs with private node pools inside a dedicated Virtual Private Cloud (VPC). The database is reached over private VPC networking, not the public internet. Only services explicitly bound to an edge route are publicly reachable; all other services (workers, scheduler, messaging gateway, document/OCR services, cache) are cluster-internal only and have no public address.

4.3 Session affinity & long-lived connections

Real-time features use WebSocket connections; the load balancer applies session affinity so a client's socket pins to a single backend instance for its lifetime, and WebSocket frames bypass payload inspection that would otherwise break the protocol — a deliberate, scoped carve-out rather than a blanket exception.

5. Authentication

Authentication answers "who is calling?" The platform supports three caller classes — interactive human users, administrative/programmatic users, and partner integrations — each with an appropriate mechanism.

5.1 Login flow

Users authenticate with an email/identifier and password over HTTPS. To avoid ever transmitting a plaintext password, the client hashes the password before it leaves the browser; the server then re-hashes that value with a salted, adaptive algorithm before comparison. Failed-attempt account lockout, optional CAPTCHA, and rate limiting protect the login endpoint against credential-stuffing and brute-force attacks.

5.2 Password storage

Property	Approach
In transit	TLS 1.2+, plus a client-side hash so the raw password is never sent
At rest	Salted, adaptively-hashed (bcrypt family) with a per-user salt and an industry-standard cost factor
Rehashing	Stored hashes are transparently upgraded to the current cost factor on successful login
Rotation	Password-age policy with proactive reminders before expiry
Reuse	The current password cannot be re-set to itself
Recovery	Password-reset and forced-change flows use a separate, short-lived, single-purpose token

Plaintext passwords are never stored, never logged, and never recoverable — only verifiable.

5.3 Session tokens (JWT)

Once authenticated, the user receives a signed JSON Web Token (JWT) that represents their session.

Signing. Tokens are signed with a server-held secret (sourced from Secret Manager, §10) and verified on every request.
Transport. The token is accepted either as a Bearer token (Authorization header) or as a hardened cookie — HttpOnly, Secure (HTTPS-only), and SameSite=Lax, which mitigates cross-site request forgery on the cookie path.
Time-boxed. Sessions are valid for a bounded window and then require re-authentication; the lifetime is configurable and treated as a security parameter (value omitted here by policy).
Server-side revocation. Crucially, the platform does not rely on expiry alone. Each user carries a "tokens-valid-from" marker; logout, password change, or an administrative action advances it, instantly invalidating all previously issued tokens for that user. Every request re-validates the token against the live user record — so a stolen token cannot outlive a revocation event.
Minimal claims. Tokens carry identity references only; roles and permissions are resolved from the database per request, never trusted from the token itself.

[Diagram]

Figure 5.1 — Login + 2FA sequence.

5.4 Two-factor authentication (2FA)

The platform provides two strong second factors, both standards-based:

WebAuthn passkeys (FIDO2) — hardware-backed, phishing-resistant public-key credentials. The server stores only the public key and a signature counter (for replay detection); the private key never leaves the user's authenticator. Registration and authentication use the standard WebAuthn ceremonies with short-lived, server-issued challenges.
SMS one-time passwords (OTP) — numeric codes delivered through the internal messaging gateway. Codes are hashed at rest, single-use, short-lived, and subject to send-cooldown and per-hour caps to prevent flooding.

2FA is opt-in per user, with the ability for administrators to require it for specific users or globally. A trusted-device option lets a user skip the second factor on a recognised device for a bounded period; trusted-device tokens are stored only as hashes and are revoked automatically on password change. The 2FA challenge itself is carried by a scoped, short-lived token that cannot be used as a full session token.

5.5 Integration authentication (partner & service-to-service)

Machine-to-machine integration — including the platform↔automation-engine channel and inbound partner webhooks — is authenticated with a static API key presented in the x-api-key header over HTTPS. The key is a shared secret managed exclusively through Secret Manager (never in code or images), validated server-side on every integration request, and scoped to the specific integration endpoints. This is the integration mechanism for external systems working with the platform.

5.6 Application-layer rate limiting

Beyond the edge rate limiter, the API enforces action-aware rate limits (e.g. stricter limits on login, password-reset, and OTP endpoints than on ordinary reads), keyed by authenticated user or source IP, returning standard 429 responses with rate-limit headers. This is a defense-in-depth complement to the WAF.

6. Authorization & RBAC

Where authentication establishes who is calling, authorization decides what they may do.

6.1 Role-based access control

The platform implements role-based access control (RBAC) with database-driven roles and granular permissions, evaluated per request:

Each route declares the permission(s) it requires.
A user's effective permissions are resolved from their roles within the relevant account context — authorization is therefore both role-based and tenant-scoped.
Privileged user classes (administrators/developers) are handled explicitly and separately, and their elevated actions are audited.
A dedicated guard prevents purely-programmatic (API) identities from reaching human-only routes, and partner integrations are constrained to their own route set.

6.2 Tenant isolation

Multi-tenant isolation is enforced in the application's data-access layer: every query is scoped to the caller's account context derived from the validated session, and resource-ownership guards verify that a requested object belongs to the caller's tenant before it is returned or mutated. Cross-tenant access is possible only for explicitly privileged administrative roles, and every such access is recorded in the audit trail.

6.3 Administrative impersonation

Support and administrative workflows may impersonate a user to reproduce an issue. Impersonation is first-class and fully audited: the acting administrator's identity is embedded in the session and carried into every audit record produced during the impersonated session, so the real actor behind every action is always attributable.

[Diagram]

Figure 6.1 — Authorization decision path: authenticate → permission → tenant ownership.

7. Data Storage & Document Security

The platform handles two broad data categories: structured transactional data (in PostgreSQL, §8) and unstructured documents — infringement images, appeal PDFs, identity/licence uploads, payment receipts, and nomination documents — in Google Cloud Storage (GCS). Encryption of both categories is consolidated in §9.

7.1 Why GCS is secure for this system

Control	How it is applied
Private by default	Document buckets are private — no anonymous or public access.
Uniform bucket-level access	Access is governed purely by IAM (no per-object ACLs), giving one consistent, auditable access model.
Public Access Prevention	Enforced on document buckets, so a misconfiguration cannot accidentally expose objects to the internet.
Encryption at rest	All objects are encrypted at rest with Google-managed AES-256 keys (§9).
Least-privilege identities	Each workload uses a dedicated service-account identity granted only the storage role it needs (e.g. read-only for receipt consumers).
No direct browser access	Buckets are never exposed to browsers directly.

7.2 How documents are served

Documents reach authorised users through two controlled paths, never by exposing a bucket:

Authenticated streaming proxy — the API streams a document to the user only after authenticating and authorising the request, applying safe content-type handling and Content-Disposition/no-sniff headers to prevent content-type confusion.
Short-lived signed URLs — where a document must be handed to a downstream automated process, the platform issues a time-limited, signed URL that grants temporary, scoped access to that single object and then expires.

Object keys are randomised (UUID-based) and sanitised to prevent path-traversal; the receipt-fetch path is locked to a single, explicitly-allowlisted bucket.

7.3 Upload safety

User uploads are subject to type and size validation on the endpoints that accept them. Bulk/spreadsheet uploads are processed through validated, idempotent pipelines with per-row error handling.

7.4 Integrity-verified storage

When documents were migrated to GCS, each object was uploaded with server-side checksum validation, then re-read and verified for both checksum and byte-size match against the source before the record was switched over — an integrity guarantee that remains the pattern for document writes.

[Diagram]

Figure 7.1 — Document upload and controlled serving. The bucket is never public.

8. Managed Database & Built-in Safety

The system of record is Cloud SQL for PostgreSQL 15 — a fully managed relational database. Choosing a managed service means a large class of security and reliability controls are provided out of the box by the cloud provider, under a shared-responsibility model (§15).

8.1 What "managed" gives us out of the box

Capability	Benefit
Encryption at rest	All data and backups encrypted with Google-managed AES-256 keys, automatically (§9).
Regional high availability	A synchronous standby in a second zone with automatic failover — no single-zone outage takes the database down (§13).
Automated backups	Scheduled daily backups with multi-day retention, managed by the platform (§13.2).
Automatic patching	The provider applies minor-version patches and security fixes during maintenance windows — no unpatched database drift.
Private networking	The database is reached over a private VPC path from the application cluster.
IAM-governed administration	Administrative access is governed by cloud IAM and logged in cloud audit logs.
Monitoring & insights	Built-in metrics, query insights, and alerting integrate with the platform's observability stack.

8.2 How the application uses it

Migration-driven schema. The schema is never mutated by the application at runtime; all changes are applied as versioned, reviewed migrations through the delivery pipeline (§11), each of which must define a reversible down-migration and is tested up and down in CI.
Least-privilege database roles. Distinct roles separate schema ownership, migration (DDL), and runtime read/write privileges, so the running application cannot perform schema-altering operations.
Connection-pool resilience. The API protects the database under load: pool-exhaustion, lock, and statement-timeout conditions are caught and translated into graceful 503 + Retry-After responses rather than cascading failures.

[Diagram]

Figure 8.1 — Managed PostgreSQL: HA topology, private connectivity, role separation, and backups.

9. Cryptography & Encryption

This section consolidates the platform's encryption posture across all tiers — in transit, at rest, and key management — for reviewers who need a single, authoritative view.

9.1 Data in transit

Path	Protection
Client ↔ platform (public)	TLS 1.2+ on all public hostnames, with Google-managed certificates that auto-renew. Plain HTTP is permanently redirected to HTTPS; HSTS and standard browser security headers are applied.
Password submission	In addition to TLS, the password is client-side pre-hashed so the raw password is never transmitted (§5.1).
Service-to-service / partner integration	Authenticated HTTPS with the `x-api-key` header (§5.5).
Document delivery	Documents are served only over HTTPS — via an authenticated streaming proxy or a short-lived signed URL — never from a public bucket (§7.2).
Internal cluster traffic	Services communicate on a private VPC; the database is reached over a private connection, not the public internet (§4.2). Only edge-bound services are publicly reachable.

9.2 Data at rest

All persistent data is encrypted at rest with provider-managed AES-256 keys (Google's default envelope encryption backed by Cloud KMS), applied automatically and transparently across every storage tier. This covers structured data, documents, backups, analytics data, and secrets — with no unencrypted persistence path.

In addition to encryption, several classes of sensitive value are stored as one-way hashes rather than reversibly-encrypted data, so they are verifiable but not recoverable even by the platform: passwords (salted adaptive hash), SMS OTP codes, and trusted-device tokens.

9.3 Database, files & backups

Asset	Encryption at rest	Notes
Database (Cloud SQL for PostgreSQL 15)	AES-256, provider-managed (envelope encryption via Cloud KMS).	Applies automatically to all data, indexes, and automated backups. Database reached over a private VPC path; administrative access governed by cloud IAM and logged.
Automated backups	AES-256, provider-managed — backups inherit the same encryption as the primary.	Scheduled daily backups with multi-day retention; retained in the EU (`europe-west1`). See §13.2.
Documents / files (Cloud Storage)	AES-256, provider-managed, on private buckets.	Uniform bucket-level access (IAM-only, no per-object ACLs) and Public Access Prevention enforced; object keys randomised (UUID) and path-traversal-sanitised (§7).
Analytics / audit store (BigQuery)	AES-256, provider-managed.	Audit events at rest with restricted, audited access (§12).
Secrets (Secret Manager)	AES-256, provider-managed; envelope-encrypted and versioned.	Delivered to workloads via key-less Workload Identity; never in code, images, or manifests (§10).

9.4 Key management

The platform uses Google-managed encryption keys (the default envelope-encryption hierarchy backed by Cloud KMS) for all tiers above, which removes operational key-handling risk. Customer-managed encryption keys (CMEK) are supported by the underlying GCP services and can be discussed with the partner's security team under NDA if a contractual requirement exists; the current production posture uses provider-managed keys.

10. Secrets Management

The platform's guiding rule is simple: no secret ever lives in source code, in a container image, or in a manifest. All secrets are centralised in Google Secret Manager and delivered to workloads at runtime.

10.1 How secrets flow

[Diagram]

Figure 10.1 — Secret delivery: Secret Manager → External Secrets Operator → Kubernetes Secret → pod.

Single source of truth. Secrets are stored and versioned in Secret Manager.
Pull, don't embed. The External Secrets Operator (ESO) runs in-cluster and reconciles secrets from Secret Manager into Kubernetes Secrets on a schedule, which are then mounted into pods as environment variables at boot.
Workload Identity. ESO authenticates to Secret Manager via GKE Workload Identity — a short-lived, federated identity — so there are no long-lived service-account key files to leak.
Declarative & auditable. Which secret maps to which workload is declared in version-controlled manifests (referencing secret names, never values), so the wiring is reviewable while the values stay private.
Rotation. Because consumers read from Secret Manager, a secret can be rotated centrally; shared integration keys are rotated under a documented procedure.

This model means a leaked manifest, repository, or container image yields no usable secret.

11. CI/CD & GitOps

The platform is built and shipped through an automated, auditable pipeline combining GitHub Actions (continuous integration) and Argo CD (GitOps continuous delivery). The defining property is that the desired state of production is whatever is committed to Git — deployments are reconciliations toward a reviewed, version-controlled state, not imperative pushes.

11.1 Pipeline stages

[Diagram]

Figure 11.1 — CI → image build → GitOps reconciliation → migrate → rollout → verify.

11.2 Key properties

Separation of duties / environment promotion. Staging and production are driven by separate branches and separate clusters; production is deliberately set to manual sync, so a human operator authorises each production reconciliation.
Immutable, traceable artifacts. Every deployment is an immutable image tagged with the exact source commit, and Argo CD reconciles the cluster toward that committed state; rollout status is monitored until it converges.
Database migrations as a gated pre-step. Schema migrations run as a pre-sync job before the new code rolls out, in a transaction-per-migration model, and are tested both forward and backward in CI.
Zero-downtime rollouts. Deployments use rolling updates with health checks, pod-disruption budgets, and graceful draining of in-flight work.
Supply-chain security scanning. Every pull request is gated by automated secret scanning (gitleaks); scheduled jobs run dependency vulnerability auditing, a full-history secret-scan baseline, and dynamic application security testing (OWASP ZAP) against staging. Findings are tracked as issues under the vulnerability-management SLA (§13.3).
GitOps audit trail. Because all state lives in Git, every change to production — application and infrastructure alike — is a reviewable, attributable commit.

12. Audit Logging & Observability

12.1 Audit trail

Security- and business-sensitive actions are recorded to an immutable audit trail. Auditing is applied deliberately to the endpoints that matter — authentication and 2FA events, user/account changes, bulk uploads, contract/vehicle/infringement/payment/nomination mutations, partner webhooks, and administrative actions — capturing:

Who — the acting user/identity (including the real actor behind any impersonation) and source IP/user-agent.
What — a semantic action name plus the affected resource.
When — a precise, server-stamped timestamp.
Outcome — success or failure, including the error on failure.

Audit records are written on a non-blocking path so auditing never degrades request latency, and personally-identifiable information is redacted from captured payloads before persistence, with the redaction explicitly recorded.

12.2 Export & retention

[Diagram]

Figure 12.1 — Audit data flow: capture → hot store → 5-minute export → analytics store.

The hot tier (PostgreSQL) keeps recent records for fast operational queries; a scheduled job exports new records to BigQuery every few minutes for long-term, queryable retention, after which aged hot-tier rows are pruned. Access to the audit data is itself restricted to authorised administrators.

12.3 Observability

The platform emits structured logs to Cloud Logging (with a sink into BigQuery for analysis) and metrics and application-performance telemetry to Cloud Monitoring. Alerting policies are maintained as code and route to the operations team's chat channels — covering edge/WAF blocks, certificate expiry, error-rate and resource thresholds, and queue health.

12.4 Cloud-platform & change audit

Layer	Mechanism
Cloud-platform audit	GCP Cloud Audit Logs record IAM and administrative operations against managed resources (database, storage, secrets) independently of the application.
Change audit (GitOps)	Because deployed state lives in Git, every production change — application and infrastructure alike — is a reviewable, attributable, reversible commit (§11).

13. Availability, Resilience & Business Continuity

The platform is designed so that no single component is a single point of failure, building on managed-service redundancy plus stateless, horizontally-scalable application tiers.

13.1 Redundancy & resilience mechanisms

Layer	Redundancy / resilience
Database	Cloud SQL regional High Availability — a synchronous standby in a second zone with automatic failover; no single-zone outage takes the database down.
Application services	Stateless containers that scale horizontally; production runs multiple replicas with autoscaling (a minimum of two per critical service so a pod or node loss is absorbed), scheduled across a multi-zone node pool.
Web UI	Cloud Run — fully managed, multi-instance autoscaling.
Edge	Global L7 load balancer with health-checked backends that automatically remove unhealthy instances from rotation.
Deployments	Zero-downtime rolling updates with health checks, pod-disruption budgets, and graceful draining of in-flight work (§11.2).
Graceful degradation	Under database overload, requests degrade to `503 + Retry-After` rather than cascading into failure (§8.2).
State externalised	All state lives in managed, redundant services (database, object storage, cache), so compute can be rescheduled freely.
Environment isolation	Production and staging run on separate clusters with separate data, secrets, and edge — code is promoted to production only after staging, limiting blast radius (§2.4).

[Diagram]

Figure 13.1 — Redundancy topology: health-checked edge, multi-zone replicas, HA database with automatic failover, and encrypted backups.

13.2 Backups & disaster recovery

Aspect	Posture
Backups	Automated daily Cloud SQL backups with multi-day retention (multiple retained backups); encrypted at rest (AES-256) and retained in the EU.
Zone-failure recovery	Handled automatically by regional HA — the standby is promoted without manual intervention.
Data-corruption / accidental-deletion recovery	Restore from the most recent daily backup.
Document durability	Cloud Storage provides high object durability with provider-managed redundancy.
Configuration / infrastructure recovery	All deployed state is declared in Git (GitOps) — the environment is reproducible from version control, so infrastructure and application configuration can be reconstructed by reconciliation.
RPO / RTO	Recovery-point is bounded by the most recent daily backup; recovery-time for zone failure is the automatic-failover window, and for full restore is the restore duration. Specific target figures are provided to the partner's security team under NDA.

13.3 Service-level commitments (SLA)

Service uptime SLA. A service-level agreement is defined and agreed contractually with the partner as part of the engagement. The platform's availability is engineered through the redundancy and DR mechanisms in §13.1–§13.2 and continuously monitored with alerting-as-code (§12.3), with the inherited managed-service SLAs below as its foundation.

Inherited infrastructure SLAs. The platform is built on managed GCP components that carry the provider's own published monthly uptime SLAs at the infrastructure layer — for example, regional/HA Cloud SQL, GKE, and Cloud Run are each published at approximately 99.95%, and Cloud Storage at approximately 99.9–99.95% (per Google's then-current public SLA terms). These are provider commitments the platform inherits; they are cited for reference and are not a composite Road Protect service SLA.

Security SLAs that are already defined. Independent of an uptime SLA, the platform operates documented security service levels:

Policy	Commitment
Vulnerability remediation SLA	Critical ≤ 24 hours, High < 3 days, Medium ≤ 7 days, Low best-effort / next cycle — fed by Dependabot, CI dependency audit, CodeQL, gitleaks, ZAP, and pen-test findings; tracked and prioritised by severity.
Penetration-testing cadence	Application penetration test at least annually, and before GA of any significant feature or material change; Critical/High findings retested before close.

14. Request Lifecycle (End-to-End)

This section ties the controls together by following a single authenticated API request from the client to the database and back, naming the security checkpoint at each hop.

[Diagram]

Figure 14.1 — End-to-end request lifecycle with security checkpoints and the trust boundary.

Walkthrough.

Edge. The request is TLS-terminated, inspected by the WAF, rate-limited, and screened for L7 DDoS. Only clean traffic proceeds.
Gateway/middleware. Security headers, CORS allowlist enforcement, and request-size limits are applied; a request-scoped identity context is established.
Authentication. The JWT is validated — signature, scope, and revocation against the live user record. Integration requests are instead validated by API key at this stage.
Authorization. RBAC permission checks, tenant-ownership checks, and action-aware rate limits run before any business logic.
Validation. The request body is validated against a strict schema; unknown fields are stripped.
Service & data. Business logic executes within database transactions, using a least-privilege runtime role, with queries scoped to the caller's tenant; documents are read/written through the controlled GCS paths (§7).
Audit & response. Sensitive actions are recorded to the audit trail (PII-redacted, non-blocking); the response is sanitised and returned over HTTPS. Database-overload conditions degrade gracefully to 503 + Retry-After.

15. Compliance, Certifications & Data Governance

15.1 Shared-responsibility model

Running on a managed cloud means security is a shared responsibility. The matrix below makes the boundary explicit — the single most important thing for a partner to understand.

Layer	Google Cloud (provider)	Road Protect (vendor)	Partner / customer
Physical data centres, hardware	✅
Hypervisor, managed-service internals	✅
Network backbone, DDoS scrubbing	✅	(configures Cloud Armor)
Database engine patching, encryption-at-rest, backups	✅	(configures HA, retention)
OS / container runtime (GKE-managed)	✅ (node OS)	(workloads)
Application code & business logic		✅
Authentication, RBAC, tenant isolation		✅
Data classification & secrets configuration		✅
IAM, network & WAF configuration		✅
End-user / integration credentials		(enforces policy)	✅
Their data & how it is used		(processes per agreement)	✅
2FA enrolment for their users		(provides capability)	✅

15.2 Security standards, certifications & audit reports

Road Protect's compliance posture has two layers: the organisation's own information-security management programme, and the certified infrastructure it inherits from Google Cloud.

Organisational certification — in progress. Road Protect is undergoing ISO/IEC 27001 certification, working with Cleargate — an independent information-security and compliance firm — to implement and audit its Information Security Management System (ISMS). As part of this programme an independent penetration test is being carried out. The certificate and the penetration-test report will be shared with the partner's security team under NDA on completion.

Inherited infrastructure attestations. The platform runs entirely on Google Cloud Platform, which maintains independently-audited attestations at the infrastructure layer — including SOC 1 / 2 / 3, ISO/IEC 27001, ISO/IEC 27017 (cloud-services security), ISO/IEC 27018 (cloud privacy), and PCI DSS. These cover the physical, network, and managed-service layers on which Road Protect's own controls (described throughout this document) are built. The underlying provider's current SOC 2 report and certificate set can be made available under NDA on request.

Standard / report	Scope	Status
ISO/IEC 27001	Road Protect ISMS	In progress — implementation & audit with Cleargate
Penetration test	Road Protect application	In progress (independent)
SOC 1 / 2 / 3	Cloud infrastructure	Inherited (Google Cloud) — report under NDA
ISO/IEC 27001 / 27017 / 27018	Cloud infrastructure	Inherited (Google Cloud)
PCI DSS	Cloud infrastructure	Inherited (Google Cloud)

15.3 Compliance posture summary

The table below summarises the platform's posture across the control areas a security review typically covers; each row links to its detailed treatment.

Area	Posture
Data residency	Primary data, processing and backups in the EU (`europe-west1`) — see §15.4.
Encryption in transit	TLS 1.2+ for all external traffic; internal traffic on a private VPC (§9.1).
Encryption at rest	Google-managed AES-256 for database, object storage, and backups (§9.2–§9.3).
Vulnerability management	Weekly dependency auditing and DAST against staging; PR-gating secret scanning; container-image vulnerability scanning; remediation SLA (§13.3).
Secrets	Centralised in Secret Manager; no secrets in code/images; federated (key-less) access.
Access control	RBAC, least-privilege roles, account-scoped tenant isolation, audited admin access.
Auditability	Immutable, PII-redacted audit trail with multi-year retention in BigQuery.
Resilience / DR	Regional HA database with automatic failover; automated backups; zero-downtime rolling deploys; isolated staging environment (§13).
Change management	GitOps — every production change is a reviewed, attributable, reversible commit.

15.4 Data storage & processing location

All primary data is stored and processed within the European Union, in Google Cloud's europe-west1 region. Single-region EU residency applies to the transactional database, document object storage, the analytics/audit store, secrets, and automated backups. Application compute — the GKE cluster and the Cloud Run web UI — runs in the same EU region, so data is processed where it resides.

The one routine flow that leaves this boundary is outbound SMS (one-time passwords and notifications), which is handed to a telephony subprocessor for delivery (§15.6); no database or document content is sent over that channel.

15.5 Data retention & deletion

Data is retained only as long as it is needed to deliver the service and to meet legal and contractual obligations, then deleted or returned:

Operational data (infringements, vehicles, contracts, documents) is retained for the life of the customer relationship and any period required by applicable regulatory and contractual obligations.
Audit events are retained long-term in the analytics store (BigQuery) for security and forensic purposes (§12.2); hot-tier records are pruned after export.
Backups follow a defined retention window — daily backups, multiple retained — and age out automatically (§13.2).
Secrets are versioned in Secret Manager; superseded versions are retired on rotation.

On termination of the engagement, customer data is deleted or returned in line with the data-processing agreement (DPA) and customer contract. Specific retention schedules and the deletion/return procedure are defined contractually and available to the partner's security team under NDA.

15.6 Subprocessors

The platform's primary subprocessor is Google Cloud Platform (hosting, database, storage, analytics, secrets), operating in the EU (europe-west1). Outbound SMS delivery uses a telephony provider via the internal messaging gateway. A current subprocessor list and the underlying cloud provider's SOC 2 report can be made available under NDA on request.

16. Appendix

16.1 Technology stack at a glance

Concern	Technology
Core API	NestJS (Node.js / TypeScript)
Web UI	Angular (current UI) on GKE; React / Next.js (new UI) on Cloud Run
Database	Cloud SQL for PostgreSQL 15 (regional HA), TypeORM
Object storage	Google Cloud Storage
Analytics / audit store	BigQuery
Cache & job queue	Redis (in-cluster)
Orchestration	Google Kubernetes Engine (GKE)
Serverless UI runtime	Cloud Run
Edge / WAF	Gateway API + global L7 ALB + Cloud Armor
TLS	Google Certificate Manager (managed certs)
Secrets	Secret Manager + External Secrets Operator + Workload Identity
CI	GitHub Actions
CD / GitOps	Argo CD
Container registry	Artifact Registry
2FA	WebAuthn passkeys + SMS OTP
Observability	Cloud Logging, Cloud Monitoring (metrics + alerting-as-code)

16.2 Glossary

Term	Meaning
GKE	Google Kubernetes Engine — managed Kubernetes.
Cloud Run	GCP serverless container runtime.
Cloud SQL	GCP managed relational database.
GCS	Google Cloud Storage — object storage.
WAF	Web Application Firewall (Cloud Armor).
OWASP CRS	OWASP Core Rule Set — managed WAF rules.
JWT	JSON Web Token — signed session token.
WebAuthn / passkey	FIDO2 phishing-resistant public-key authentication.
OTP	One-time password.
RBAC	Role-based access control.
GitOps	Git as the source of truth for deployed state (Argo CD).
ESO	External Secrets Operator.
Workload Identity	Key-less federated identity for GKE workloads.
CMEK	Customer-managed encryption keys.
HA / failover	High availability with automatic standby promotion.
RPO / RTO	Recovery point / recovery time objective.
DAST	Dynamic Application Security Testing.
PII	Personally Identifiable Information.
SOC 1/2/3	Service Organization Control — independent audit reports on a service provider's controls.
ISO/IEC 27001	Certifiable information-security management standard (the ISMS standard).
ISO/IEC 27017 / 27018	Cloud-services security and cloud-privacy control standards.
ISMS	Information Security Management System — the ISO 27001 programme.
DPA	Data Processing Agreement.

16.3 Diagram legend

Solid arrows — request/data flow. Dashed arrows — boot-time or out-of-band relationships.
Cylinders — data stores. Subgraph boxes — trust/deployment boundaries.

16.4 Contact & further information

Detailed evidence — the underlying cloud provider's SOC 2 report, a current subprocessor list, and environment-specific configuration — is available to the partner's security team under NDA through the Road Protect engineering contact.