Confidential — Shared under NDA · Do Not Distribute
Document Information Security & Cyber — Controls Summary Version 1.1 Date 2026-06-30 Classification Confidential Owner Road Protect — Platform Engineering Intended audience Partner / customer information-security reviewers (vendor due-diligence / tender) Status Approved for NDA distribution Companion to Road Protect Fleet — Architecture & Security Overview v1.0 (2026-06-23)
This document answers the information-security and cyber questions a vendor due-diligence or tender process typically raises about the Road Protect Fleet platform. It is a companion to the Architecture & Security Overview (v1.0): where that document describes the system top-down, this one is organised by the security questionnaire's own structure — security mechanisms, authentication & authorization, audit logging & monitoring, encryption (in transit / at rest / database, files & backups), and availability, resilience & business continuity.
Section cross-references such as "(Overview §5)" point to the companion Architecture & Security Overview.
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, rate-limit thresholds, specific managed-rule identifiers), the document describes the mechanism and the security property it delivers 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.
Confidential — Shared under NDA · Do Not Distribute
Road Protect Fleet is a cloud-native, multi-tenant SaaS platform operated on Google Cloud Platform (europe-west1, EU data residency) under a defense-in-depth model: security is enforced at every layer — network edge, transport, identity, authorization, data, secrets, supply chain, and operations — so that no single control is a single point of failure.
Figure 1.1 — The control layers a request and its data pass through. Each layer is independent.
| 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. | Overview §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. | §2 / Overview §5 |
| Authorization | Per-request RBAC with database-driven roles, account-scoped tenant isolation, resource-ownership guards, separated privileged classes, fully-audited administrative impersonation. | §2.5 / Overview §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. | §4 / Overview §7–8 |
| 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. | Overview §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. | Overview §9 |
| 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. | §3.4 / Overview §10 |
| Audit & monitoring | Immutable, PII-redacted audit trail exported to BigQuery for long-term retention; structured logging, APM, metrics, and alerting-as-code. | §3 / Overview §11 |
| Availability / resilience | Regional high-availability database with automatic failover; stateless, horizontally-autoscaled services; zero-downtime rolling deploys; automated encrypted backups with point-in-time recovery; isolated staging environment. | §5 / Overview §8, §13 |
Confidential — Shared under NDA · Do Not Distribute
Authentication answers "who is calling?"; authorization decides "what may they do?". Both are enforced on every request — the JWT is re-validated against the live user record, and roles, permissions and tenant ownership are resolved server-side per request rather than trusted from the token.
The platform supports three caller classes, each with an appropriate mechanism:
| Caller class | Mechanism |
|---|---|
| Interactive human users | Email/identifier + password over HTTPS, with optional/required 2FA. |
| Administrative / programmatic users | Same credential flow with elevated, separately-handled roles; their actions are audited. |
| Partner / service-to-service integrations | Static API key in the x-api-key header over HTTPS (§2.4). |
Password handling. 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 (bcrypt family) using a per-user salt and an industry-standard cost factor. Stored hashes are transparently upgraded to the current cost factor on successful login. Plaintext passwords are never stored, logged, or recoverable — only verifiable. Login is protected by failed-attempt account lockout, optional CAPTCHA, and rate limiting against credential-stuffing and brute-force. Password-reset and forced-change flows use a separate, short-lived, single-purpose token. (Full detail: Overview §5.1–§5.2.)
Session tokens (JWT). On success the user receives a signed JSON Web Token:
Bearer token or as a hardened cookie — HttpOnly, Secure (HTTPS-only), SameSite=Strict.Two strong, standards-based second factors are available:
2FA is opt-in per user, and administrators can require it for specific users or globally. A trusted-device option allows skipping the second factor on a recognised device for a bounded period; trusted-device tokens are stored only as hashes and are revoked on password change. (Full detail: Overview §5.4.)
The platform implements role-based access control, evaluated per request:
Figure 2.1 — Authentication → authorization → tenant-ownership decision path.
Machine-to-machine integration — the platform↔automation-engine channel and inbound partner webhooks — is authenticated with a static API key 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.
Current state — stated plainly. The platform operates a first-party identity store: users authenticate directly against Road Protect's own credential database. Federated single sign-on via SAML 2.0, OAuth 2.0, or OpenID Connect (OIDC) is not implemented today, and there is no external identity-provider (IdP) integration for end-user login. (The only OAuth in the system is Google service-account OAuth used internally for GCP API access — for example object storage — which is infrastructure authentication, not user sign-in.)
What is standards-based. Within the first-party model the platform already uses established standards: WebAuthn / FIDO2 passkeys for phishing-resistant second-factor (and passwordless-capable) authentication, signed JWT sessions, and standard SMS-OTP. These reflect a deliberate investment in strong, standards-aligned authentication.
Architectural readiness (no commitment). The authentication layer is a guard-based pipeline (NestJS) in which the credential-verification step is isolated behind a well-defined boundary. Adding a federated path — e.g. SAML 2.0 or OIDC against a partner/customer IdP (Azure AD / Entra ID, Okta, Google Workspace) — is therefore an additive integration that does not require re-architecting authorization or session management: the federated assertion would resolve to an existing platform identity, after which the same per-request RBAC and tenant-isolation controls apply unchanged. If a partner requires enterprise SSO, it can be scoped as a roadmap item; this document makes no delivery commitment and reflects current capability only.
Confidential — Shared under NDA · Do Not Distribute
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:
| Field | Captured |
|---|---|
| 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.
Figure 3.1 — Audit data flow: capture → hot store → periodic 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 and is audited. (Full detail: Overview §11.)
| Capability | Implementation |
|---|---|
| Structured logging | Application logs to Cloud Logging, with a sink into BigQuery for analysis. Logs are PII-redacted at the logging choke-point. |
| Application performance monitoring | APM telemetry for latency, error, and throughput tracing. |
| Metrics | Cloud Monitoring for resource and application metrics. |
| Alerting-as-code | Alerting policies are maintained as version-controlled code and route to the operations team's chat channels — covering edge/WAF blocks, certificate expiry, error-rate and resource thresholds, and queue health. |
| 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 (Overview §10). |
PR-gating secret scanning (gitleaks), scheduled dependency vulnerability auditing, a full-history secret-scan baseline, and dynamic application security testing (OWASP ZAP against staging) run continuously; findings are tracked as issues under the vulnerability-management process (§5.4).
Confidential — Shared under NDA · Do Not Distribute
| 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. |
| Service-to-service / partner integration | Authenticated HTTPS with the x-api-key header (§2.4). |
| Document delivery | Documents are served only over HTTPS — via an authenticated streaming proxy or a short-lived signed URL — never from a public bucket (Overview §7.2). |
| Internal cluster traffic | Services communicate on a private VPC; the database is reached over a private connection, not the public internet (Overview §4.2). Only edge-bound services are publicly reachable. |
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.
| 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 transaction logs. Database reached over a private VPC path; administrative access governed by cloud IAM and logged. |
| Automated backups & PITR logs | AES-256, provider-managed — backups inherit the same encryption as the primary. | Scheduled daily backups plus transaction-log retention enabling point-in-time recovery; retained in the EU (europe-west1). |
| 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. |
| Analytics / audit store (BigQuery) | AES-256, provider-managed. | Audit events at rest with restricted, audited access. |
| 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 (Overview §9). |
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.
Confidential — Shared under NDA · Do Not Distribute
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.
| 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 (Overview §10.2). |
| Graceful degradation | Under database overload, requests degrade to 503 + Retry-After rather than cascading into failure (Overview §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 (Overview §2.4). |
Figure 5.1 — Redundancy topology: health-checked edge, multi-zone replicas, HA database with automatic failover, and encrypted backups.
| Aspect | Posture |
|---|---|
| Backups | Automated daily Cloud SQL backups plus transaction-log retention for point-in-time recovery (PITR); 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-backup / PITR to a chosen point before the event. |
| 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 transaction-log/PITR granularity; 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. |
Service uptime SLA — stated plainly. Road Protect does not publish a fixed contractual customer-facing uptime percentage in this document. A specific service-level agreement can be 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 §5.1–§5.2 and continuously monitored with alerting-as-code (§3.3).
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; High/Critical block CI. |
| 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. |
Confidential — Shared under NDA · Do Not Distribute
This document and the Architecture & Security Overview (v1.0) are complementary. The map below points each questionnaire item to its fullest treatment.
| Topic | This document | Architecture & Security Overview |
|---|---|---|
| Information security mechanisms | §1 | §1, §3 (whole document) |
| Authentication & authorization | §2 | §5 (Authentication), §6 (Authorization) |
| SSO / SAML / OAuth / OIDC support | §2.5 | §5.5 (integration auth) |
| Audit logs, monitoring & control | §3 | §11 (Audit & Observability) |
| Encryption in transit (Data in Transit) | §4.1 | §4, §13.2 |
| Encryption at rest (Data at Rest) | §4.2 | §7.1, §8.1, §13.2 |
| Database, files & backups encryption | §4.3 | §7 (documents), §8 (database & backups) |
| Redundancy & resilience | §5.1–§5.2 | §8 (HA database), §10.2, §13.2 |
| Service SLA | §5.3 | §13.2 (resilience / DR) |
Confidential — Shared under NDA · Do Not Distribute Road Protect Fleet — Information Security & Cyber · v1.0 · 2026-06-30 · Companion to Architecture & Security Overview v1.0