Security at Every Depth

Security Philosophy & Foundational Principles

Volaxin operates a security programme grounded in the following non-negotiable principles, applied uniformly across every system, process, and human function within the organisation:

The Volaxin Information Security Management System (ISMS) is governed by a dedicated Chief Information Security Officer (CISO) and reviewed quarterly by the executive leadership team. Security objectives are integrated into the annual business plan and resource allocation process.

Cloud Infrastructure Architecture

2.1 Cloud Provider & Regional Deployment

The Volaxin platform is hosted exclusively on enterprise-grade cloud infrastructure operated by a Tier 1 hyperscale cloud provider maintaining ISO/IEC 27001, SOC 1/2/3, and CSA STAR Level 2 certifications. The platform operates across geographically separated primary and secondary availability zones, with client data stored within jurisdictions aligned to client contractual requirements (EU, UK, APAC, and US regions available).

2.2 Architecture Separation

The platform employs a strict multi-tier architecture with physical and logical separation between the following layers:

• Presentation Tier: Web application delivery via globally distributed CDN with DDoS mitigation, WAF filtering, and Bot Management at the edge. All static assets served over HTTPS with HSTS preloading and Content Security Policy headers enforced.
• Application Tier: Containerised microservices deployed on an orchestrated Kubernetes cluster with network policies enforcing pod-to-pod communication whitelisting. Each module runs in an isolated service boundary with its own IAM role.
• Data Tier: Managed relational and document databases deployed in private subnets with no public internet exposure. All database connections are authenticated via short-lived certificates issued by an internal certificate authority. Database superuser access requires MFA and is logged to an immutable audit trail.
• Integration Tier: All third-party API integrations (AIS providers, weather services, class society systems) are mediated through an API gateway with rate limiting, payload validation, and egress filtering. No third-party service has direct access to the data tier.

2.3 Physical Security

Volaxin does not operate its own data centres. All physical infrastructure is hosted in certified cloud provider facilities offering: biometric and card-based multi-factor physical access control; 24/7 on-site security personnel and CCTV with 90-day retention; N+1 redundant power and cooling with UPS and diesel generator backup; and independent third-party physical security audits at a minimum annual frequency.

Encryption Standards & Key Management

Volaxin enforces cryptographic protections at every point where data is stored, transmitted, or processed. The following encryption standards are applied universally across the platform without exception:

3.1 Key Management Infrastructure

All cryptographic keys are managed through a dedicated Hardware Security Module (HSM)-backed key management service. Master keys never leave the HSM boundary. Data Encryption Keys (DEKs) are encrypted under Key Encryption Keys (KEKs) in an envelope encryption model, ensuring that compromise of any single key material layer does not expose plaintext data. Access to key management operations is restricted to automated systems and requires dual human approval for any manual key administrative operation.

3.2 Certificate Management

All TLS certificates are issued by globally trusted Certificate Authorities. Certificate validity periods do not exceed 90 days for externally facing services, with automated renewal via ACME protocol. Certificate Transparency (CT) logs are monitored for unauthorised issuance of certificates for Volaxin domains. HSTS with a minimum max-age of 31,536,000 seconds is enforced with preloading on all production domains. DNSSEC is enabled on all Volaxin-controlled DNS zones.

Identity, Authentication & Access Control

4.1 Multi-Factor Authentication

Multi-factor authentication (MFA) is mandatory for all Volaxin staff accounts without exception. For client Authorised Users, MFA is strongly recommended and can be mandated at the organisational level by client administrators. Supported MFA methods include TOTP authenticator applications (RFC 6238), FIDO2/WebAuthn hardware security keys, and push notification approval via registered mobile device. SMS-based one-time passwords are not offered as an MFA method due to known vulnerabilities in the SS7 telephony protocol.

4.2 Role-Based Access Control (RBAC)

The Platform implements a granular, configurable Role-Based Access Control system with a minimum of the following default roles:

Custom roles can be defined by Fleet Administrators with fine-grained permission matrices at the module, vessel, and data category level. All role assignments and modifications are logged immutably and visible to auditors.

4.3 Privileged Access Management

Volaxin infrastructure and database access by internal personnel is governed by a Privileged Access Management (PAM) system. All privileged sessions are: brokered through a jump server with MFA re-authentication at session initiation; recorded in full (video and keystroke logging); limited to the minimum duration required; and reviewed by the security team on a monthly basis. Privileged access rights are reviewed quarterly and revoked immediately upon role change or departure.

4.4 Session Management

Platform sessions are secured through: short-lived JWT access tokens (15-minute expiry) and longer-lived refresh tokens (24-hour expiry, rotated on each use); automatic session invalidation on password change or MFA change; concurrent session limits configurable per organisation; IP-based anomaly detection triggering re-authentication on significant location change; and absolute session timeout of 8 hours regardless of activity.

4.5 Single Sign-On (SSO)

Enterprise clients may integrate their existing Identity Provider (IdP) with the Platform via SAML 2.0 or OpenID Connect (OIDC), enabling centrally managed authentication and Just-In-Time (JIT) provisioning. SSO integration allows clients to enforce their own MFA policies, session policies, and conditional access rules at the IdP level, providing a single point of governance for all Authorised User access.

Network Security Architecture

5.1 Web Application Firewall (WAF)

All internet-facing endpoints are protected by a managed Web Application Firewall operating at the CDN edge layer. The WAF is configured with rulesets targeting the OWASP Top 10 vulnerability categories, including SQL injection (SQLi), Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), Remote Code Execution (RCE), Server-Side Request Forgery (SSRF), and XML/JSON injection attacks. WAF rules are reviewed and updated on a weekly cadence, with emergency rule deployments available within 2 hours of threat intelligence disclosure.

5.2 DDoS Mitigation

The platform maintains always-on DDoS mitigation at Layers 3, 4, and 7 of the OSI model, capable of absorbing volumetric attacks in excess of 1 Tbps at the network edge. Application-layer (Layer 7) rate limiting is enforced per IP address, per client organisation, and per API endpoint. Automatic traffic scrubbing is activated within seconds of anomaly detection, with manual escalation procedures for prolonged or novel attack patterns.

5.3 Internal Network Segmentation

Internal network architecture employs strict segmentation through Virtual Private Cloud (VPC) isolation, security group rules enforcing default-deny posture, and network policies at the container orchestration layer. East-west traffic between microservices is encrypted via mutual TLS. No internal service communicates directly with the internet; all external requests are routed through explicitly defined egress gateways with traffic logging.

5.4 Intrusion Detection & Prevention

Network Intrusion Detection Systems (NIDS) are deployed at all network boundaries, analysing traffic patterns for indicators of compromise including port scanning, lateral movement signatures, data exfiltration patterns, and known malware command-and-control (C2) communication patterns. Automated blocking rules are applied to confirmed malicious traffic flows within seconds of detection.

5.5 DNS Security

DNS Security Extensions (DNSSEC) are enabled on all Volaxin-controlled DNS zones. DNS query logging is enabled for all internal resolvers, with anomaly detection for DNS tunnelling and DNS rebinding attack patterns. DNS-based blocklists are enforced on all egress traffic to prevent communication with known malicious domains.

Multi-Tenant Data Isolation & Client Data Segregation

Volaxin's multi-tenant architecture implements rigorous data isolation controls to ensure that no client can access, query, or inadvertently receive data belonging to any other client organisation, at any layer of the stack:

6.1 Database-Level Isolation

Client data is segregated at the database level through a combination of schema-level isolation (dedicated schemas per client organisation in the relational database) and row-level security (RLS) policies enforced at the database engine level that prevent any query — regardless of application-level filtering — from returning rows belonging to a different tenant. RLS policies are enforced as a non-bypassable constraint at the PostgreSQL engine level, entirely independent of application code.

6.2 Application-Level Tenant Context

Every authenticated API request carries a cryptographically verified tenant context token. Middleware enforces tenant context validation at the API gateway before any request reaches application logic. All database queries are automatically scoped to the authenticated tenant through the ORM query layer, with a secondary validation step preventing query plan reuse across tenant boundaries.

6.3 Encryption Key Isolation

Each client organisation is assigned a unique set of Data Encryption Keys (DEKs) for the encryption of their data at rest. Client DEKs are themselves encrypted under client-specific Key Encryption Keys (KEKs), ensuring that even in the highly unlikely event of a bulk storage compromise, data belonging to different clients cannot be decrypted using the same key material.

6.4 Audit Log Isolation

Audit logs are written to an immutable, append-only log store with cryptographic hash chaining (each log entry incorporates a hash of the previous entry), ensuring tamper-evidence. Client audit logs are isolated per tenant and are only accessible by: the client's designated Auditor role users; Volaxin's security team under the PAM framework with full logging; and competent authorities under valid legal process.

Endpoint Security & Offline Vessel Operations

7.1 Volaxin Internal Endpoint Standards

All Volaxin staff devices are subject to mandatory endpoint security controls enforced through a Mobile Device Management (MDM) platform:

• Full-disk encryption (BitLocker / FileVault) enforced on all laptops and workstations
• Endpoint Detection and Response (EDR) agent deployed with real-time threat detection and automated threat containment
• Mandatory operating system and application patch deployment within 48 hours of critical security updates
• Strict application whitelisting — only approved applications may execute; all others are blocked by default
• USB and removable media blocked by default; exceptions require CISO approval and are time-limited
• Automatic device lock after 5 minutes of inactivity; remote wipe capability enforced on all devices

7.2 Offshore Vessel Device Security

The Volaxin offline synchronisation module enables full Platform functionality on vessels operating without reliable internet connectivity. The following technical controls are applied to all vessel-side installations:

• Device-Level Encryption: The local data store on all vessel-side devices is encrypted using AES-256-GCM (or ChaCha20-Poly1305 on hardware without AES acceleration). Encryption keys are derived from a device-specific secret and a server-issued ephemeral key using HKDF (HMAC-based Key Derivation Function, RFC 5869).
• Sealed Synchronisation Channels: All data synchronisation between vessel devices and Volaxin's cloud infrastructure occurs exclusively over TLS 1.3-encrypted HTTPS connections, authenticated with a short-lived device certificate issued to the specific vessel installation. Synchronisation is refused if the device certificate has expired or been revoked.
• Offline Data Minimisation: Vessel-side caches contain only the data required for active vessel operations. Payroll data, sensitive HR records, and cross-fleet reporting data are not cached offline and require authenticated cloud connectivity to access.
• Tamper Detection: The local application binary is integrity-checked on each launch against a vendor-signed hash. Any modification to the application files triggers an automatic lockout and alert to the Fleet Administrator and Volaxin security team.
• Conflict Resolution Integrity: The synchronisation engine applies an authenticated conflict resolution protocol — all offline-generated records carry a cryptographically signed timestamp and device identifier, preventing backdating or injection of false records during synchronisation.

Threat Detection, SIEM & Security Monitoring

8.1 Security Information & Event Management (SIEM)

All infrastructure components, application services, and network devices emit structured security event logs to a centralised SIEM platform in real time. Log sources include: cloud provider infrastructure logs (VPC flow logs, IAM activity, storage access); container orchestration audit logs; application-layer authentication and authorisation events; WAF and DDoS mitigation event logs; database query logs (audit mode); and endpoint EDR telemetry from Volaxin staff devices.

The SIEM platform applies a continuously updated library of detection rules and behavioural analytics to identify: brute-force and credential stuffing attacks; account takeover attempts; anomalous data access patterns (volume, time, geography); privilege escalation attempts; lateral movement within the cloud environment; and indicators of compromise associated with known threat actor TTPs (Tactics, Techniques, and Procedures).

8.2 24/7 Security Operations

Critical security alerts generated by the SIEM are triaged by Volaxin's security operations function on a 24/7/365 basis. Mean Time to Detect (MTTD) for critical-priority security events is targeted at under 5 minutes. Automated playbooks execute initial containment actions (account lockout, IP block, session revocation) within 2 minutes of alert confirmation, before human review is completed.

8.3 Anomaly Detection & User Behaviour Analytics

The platform employs machine-learning-based User and Entity Behaviour Analytics (UEBA) to establish baseline behavioural profiles for each Authorised User and flag statistically significant deviations. Anomalies that trigger enhanced monitoring or step-up authentication requirements include: login from a new geographic location or device; access volume significantly exceeding the user's historical baseline; access at unusual hours for the user's registered time zone; bulk data export requests; and successive failed privilege escalation attempts.

8.4 Threat Intelligence Integration

Volaxin's security platform ingests threat intelligence feeds from multiple sources including commercial maritime cyber threat intelligence providers, national CERT/CSIRT organisations, the NCSC (UK), CISA (US), ENISA (EU), and the BIMCO Maritime Cyber Resilience resources. Indicators of compromise (IoCs) from these feeds are automatically propagated to WAF blocking rules, SIEM detection logic, and DNS blocklists within minutes of publication.

Vulnerability Management & Penetration Testing

9.1 Continuous Vulnerability Scanning

Automated vulnerability scanning is executed continuously across the following surfaces:

• Container Images: All container images are scanned for known CVEs at build time using an integrated container security scanner. Images with critical (CVSS ≥ 9.0) or high (CVSS ≥ 7.0) vulnerabilities are blocked from deployment until patched or formally risk-accepted with compensating controls documented.
• Infrastructure Components: All cloud infrastructure resources are assessed against CIS Benchmarks using automated CSPM (Cloud Security Posture Management) tooling, with findings reported to the engineering team in real time.
• Open Source Dependencies: Software composition analysis (SCA) is applied to all third-party libraries and open source dependencies in the Platform codebase. The dependency inventory is continuously monitored against the National Vulnerability Database (NVD) and GitHub Advisory Database.
• Network-Facing Assets: External attack surface management tooling continuously enumerates and assesses all internet-facing assets to identify exposed services, misconfigurations, and newly introduced vulnerabilities.

9.2 Penetration Testing

Penetration test reports are available to clients under NDA upon written request to security@volaxin.com. Executive summaries and remediation status are provided without NDA requirement. All findings rated Critical or High are remediated within 30 days of report issuance; Medium findings within 90 days; Low findings within 6 months or accepted with documented risk rationale.

9.3 Secure Development Lifecycle (SDLC)

Security is integrated into every phase of the Volaxin software development lifecycle:

1. Design Phase: Threat modelling (STRIDE methodology) conducted for all new features and architectural changes. Security requirements documented in the feature specification.
2. Development Phase: Mandatory security training for all engineers. Static Application Security Testing (SAST) integrated into every pull request via automated code scanning. Peer code review with explicit security checklist.
3. Testing Phase: Dynamic Application Security Testing (DAST) executed against staging environments before every production release. Security regression test suite executed on every build.
4. Deployment Phase: Infrastructure changes deployed through immutable infrastructure pipelines. No manual changes to production infrastructure are permitted outside of documented emergency procedures with full audit trail.
5. Operations Phase: Runtime application self-protection (RASP) monitors application behaviour in production. Security metrics tracked and reviewed in weekly engineering security meetings.

Security Incident Response

10.1 Incident Classification

10.2 GDPR Breach Notification Obligations

Where a security incident constitutes a Personal Data Breach as defined under Article 4(12) GDPR, Volaxin will notify affected clients within 72 hours of becoming aware of the breach (or as soon as practically possible thereafter), providing the information required under Article 33(3) GDPR to enable the client (as Data Controller) to fulfil their own supervisory authority notification obligation within the 72-hour regulatory window. Where the breach is unlikely to result in a risk to the rights and freedoms of natural persons, Volaxin will document this assessment and communicate it to the client within the same timeframe.

10.3 Forensic Preservation

Upon declaration of a P1 or P2 security incident, Volaxin's incident response procedures automatically preserve forensic evidence including: affected system memory snapshots and disk images; complete log archives for the affected period; network flow data and packet captures (where available); and a chain-of-custody record for all evidence. Forensic evidence is preserved for a minimum of 24 months or the duration of any legal proceedings, whichever is longer.

10.4 Post-Incident Review

All P1 and P2 incidents are subject to a structured Post-Incident Review (PIR) completed within 14 days of incident resolution. PIR outcomes, including root cause analysis and remediation actions, are shared with affected clients upon request. Lessons learned are incorporated into updated security controls, runbooks, and detection rules within 30 days of PIR completion.

Business Continuity & Disaster Recovery

11.1 Recovery Objectives

11.2 Backup Immutability

All backup data is written to immutable object storage with Object Lock policies that prevent modification or deletion for the defined retention period, even by users with administrative privileges. This protects backup integrity against ransomware attacks targeting backup infrastructure — a recognised attack vector in the maritime sector. Immutability locks are verified on a monthly automated basis, with any lock removal requiring dual approval and generating an immediate security alert.

Third-Party & Supply Chain Security

The security of the Volaxin platform is inextricably linked to the security of its supply chain. Volaxin applies a structured third-party risk management programme to all sub-processors, technology vendors, and professional service providers:

1. Pre-Engagement Assessment: All prospective sub-processors and technology vendors with access to client data or production systems are subject to a mandatory Security Supplier Questionnaire (SSQ) covering the 18 security control domains mapped to ISO/IEC 27001:2022. Only vendors meeting Volaxin's minimum security baseline are approved.
2. Contractual Security Requirements: All sub-processor and vendor contracts include binding security requirements clauses, mandatory breach notification obligations (within 24 hours of discovery), right-to-audit provisions, and explicit data processing limitations.
3. Annual Re-Assessment: All Tier 1 sub-processors (those with access to client data) are reassessed annually via updated SSQ, review of current security certifications (ISO 27001, SOC 2), and where warranted, on-site or remote audit.
4. Software Dependency Security: The Volaxin software build pipeline enforces Software Composition Analysis (SCA) and validates all open-source dependencies against a maintained allowlist. Dependencies with active critical CVEs are remediated within 48 hours. A Software Bill of Materials (SBOM) is maintained and updated on each production release.
5. Code Signing: All software artefacts deployed to production are cryptographically signed using a hardware-backed code signing certificate. The deployment pipeline verifies signatures before any artefact is permitted to execute in production, providing supply chain integrity assurance against tampering in the CI/CD pipeline.

Compliance, Certifications & Regulatory Alignment

Volaxin's security programme is designed to meet and exceed the requirements of the principal international standards and regulatory frameworks applicable to its operations and client base:

Security compliance documentation — including executive summaries of penetration test reports, ISO 27001 certificates, SOC 2 reports (under NDA), and Data Processing Impact Assessments — is available to clients upon written request to security@volaxin.com. Volaxin welcomes client security due diligence questionnaires and responds within 10 business days.

Maritime-Specific Cybersecurity Controls

The maritime industry faces a distinct and evolving cyber threat landscape, including nation-state adversaries targeting critical maritime infrastructure, ransomware groups specialising in shipping logistics disruption, AIS spoofing and GPS jamming threats, and SATCOM interception risks. Volaxin has implemented the following controls specifically designed for the maritime operational context:

14.1 IMO Maritime Cyber Risk Management Alignment

The Platform is designed in alignment with IMO Resolution MSC-FAL.1/Circ.3 (Guidelines on Maritime Cyber Risk Management) and the BIMCO/ICS/INTERCARGO/OCIMF/IUMI Maritime Cyber Security Guidelines (5th Edition). Key implementations include: documented cyber risk register for vessel-connected systems; integration with vessel Safety Management System (SMS) through the SHEQ module; and support for flag state cyber security audit requirements.

14.2 AIS Data Integrity

AIS data ingested from third-party providers is subject to anomaly validation before display or use in compliance calculations. Cross-referencing of AIS position data with vessel voyage plans, satellite imagery sources (where available), and port authority ETA data is performed to detect spoofed or manipulated AIS transmissions. Anomalies are flagged to the assigned Fleet Superintendent with an automated alert and withheld from automated compliance calculations pending human review.

14.3 SATCOM Communication Security

Volaxin's offline synchronisation architecture is specifically engineered for the constraints and vulnerabilities of maritime SATCOM communication links, including: compression and integrity checking of sync payloads to minimise SATCOM bandwidth consumption and detect in-transit manipulation; certificate pinning in the vessel-side application to resist man-in-the-middle attacks over untrusted SATCOM gateways; and graceful handling of intermittent connectivity without data loss or security degradation during reconnection.

14.4 Crew Personal Data Sovereignty

Recognising that seafarers are among the most internationally mobile workers in any industry, with data rights governed by multiple jurisdictions simultaneously, Volaxin implements jurisdiction-aware data handling for crew personal data. The crew module records the nationality, flag state of employment, and port-of-engagement jurisdiction for each seafarer, and applies the most protective data handling standard of all applicable jurisdictions to that individual's data processing.

14.5 Human Factor — Security Awareness

Volaxin conducts monthly security awareness training for all staff and provides optional quarterly security awareness materials for client Authorised Users, specifically addressing maritime cyber threats. Topics include: phishing and social engineering techniques targeting maritime personnel; safe handling of vessel operational data; secure remote access practices for crew ashore; and recognition and reporting of cyber incidents in the maritime context.

Responsible Disclosure Programme

Volaxin operates a public Responsible Disclosure Programme (also known as a Vulnerability Disclosure Programme or VDP) and welcomes reports from independent security researchers, clients, and members of the public who discover potential vulnerabilities in the Volaxin platform or supporting infrastructure.

15.1 Scope

The following assets are within scope for responsible disclosure:

• The Volaxin Platform web application (app.volaxin.com)
• All public-facing APIs (api.volaxin.com)
• The Volaxin corporate website (volaxin.com)
• The Volaxin mobile applications (iOS and Android)
• The offline synchronisation module and vessel-side application

15.2 Rules of Engagement

Researchers are asked to: report findings exclusively to security@volaxin.com using the PGP public key available at volaxin.com/security.asc; not access, modify, or delete client data; not conduct denial-of-service testing; not engage in physical security testing without prior written authorisation; provide sufficient information to reproduce the vulnerability; and allow Volaxin a minimum of 90 days to investigate and remediate before public disclosure.

15.3 Our Commitments to Researchers

Volaxin commits to: acknowledge receipt of all responsible disclosure reports within 2 business days; provide a substantive response confirming or disputing the vulnerability within 10 business days; keep the researcher informed of remediation progress; not initiate legal action against researchers acting in good faith within these guidelines; and provide public acknowledgement of confirmed findings (with researcher consent) in the Volaxin Security Hall of Fame.