Security, audits & compliance
In this chapter, “FortisX” refers specifically to the analytics and policy layer described earlier: although it does not by default custody client assets or operate validators on behalf of users, it still handles sensitive data and influences decisions with financial consequences, so its own security posture must treat the platform as critical infrastructure.
This section outlines how FortisX approaches security at the platform level, how independent reviews and audits fit into that approach, and how the system is designed to cooperate with the compliance frameworks of organisations that use it.
Security objectives and threat model
The security model of FortisX is built around a few objectives:
Integrity of analytics and policies — metrics, risk profiles, and policy evaluations must not be altered without detection. Decisions based on FortisX should rely on data and logic that are protected from unauthorised modification.
Confidentiality of sensitive information — any non-public data held by FortisX—such as internal configuration, API keys, integration metadata, or user profiles—must be protected in transit and at rest.
Controlled influence over allocations — because FortisX produces allocation and rebalancing proposals, it must be clear who can influence the models, policies, and configurations that generate those outputs.
Separation from custody and execution — key material and execution rights over client assets remain outside the platform unless explicitly agreed; FortisX is not assumed to be a signing or custody system.
The threat model includes:
attempts to tamper with analytics, risk models, or policy configurations;
unauthorised access to operational interfaces or integration endpoints;
exploitation of software or infrastructure vulnerabilities in the platform;
misuse of legitimate access (for example, misconfigured privileges or weak governance around policy changes).
Separation of duties
A central design principle in FortisX is separation of duties between:
Analytics and data acquisition – ingest and computation of metrics and risk profiles.
Policy definition – configuration of rules and constraints that govern allocations.
Execution systems – external platforms that hold keys, manage validators, or record positions.
This separation is enforced both technically and organisationally:
Components that ingest and store data are isolated from components that manage policy configuration.
Policy configuration interfaces are restricted to users and roles with explicit authorisation.
Execution systems integrate with FortisX through well-defined interfaces and maintain their own approval and control processes.
As a result, a compromise of one area (for example, ingest infrastructure or a specific integration) does not automatically grant the ability to alter policies or move assets.
Access control and authentication
Access to FortisX components and data is controlled through layered mechanisms:
Role-based access control (RBAC)
System functions are grouped into roles (for example, read-only analytics, policy administration, integration management).
Users and service accounts are granted only the permissions required for their tasks.
Strong authentication for privileged access
Administrative and policy-related interfaces require multi-factor authentication where available.
Access from automation or integration services uses scoped credentials (for example, API keys or service identities) with clearly defined privileges.
Segregation of environments
Production environments are separated from development and test environments.
Non-production environments use separate credentials and data, and are not permitted to affect production allocations or configurations.
Changes to access rights are logged and reviewed as part of operational governance.
Data security and privacy
FortisX is not designed to store private keys or client assets. Nevertheless, it handles other categories of data that require protection:
Configuration and integration metadata
Information about network endpoints, providers, and integrations is treated as sensitive.
Secrets such as API keys, database credentials, and integration tokens are stored in dedicated secret management systems, not in code or plain configuration files.
Analytics and operational data
Metrics, logs, and risk profiles are stored in infrastructure that supports encryption at rest and controlled access.
Communication between components and with external systems is protected with transport-level encryption.
User and organisational data
Where the platform stores information about users or client organisations, collection is limited to what is operationally necessary.
Retention and access rules are aligned with those needs and with applicable privacy requirements.
Data handling practices are documented so that client security and compliance teams can review how FortisX fits into their own policies.
Secure development and configuration management
Security considerations are integrated into the software development and configuration lifecycle:
Code and configuration review
Changes to code and critical configuration (including risk models and policy frameworks) are reviewed by more than one person before deployment.
Automated checks (such as static analysis and dependency scanning) are applied to code repositories where practical.
Dependency management
Third-party libraries and tools are monitored for security advisories.
Updates are applied in a controlled manner, with testing in non-production environments before release.
Configuration as data
Risk model definitions, policy templates, and other core behaviours are represented as structured data (for example, configuration or model definitions) rather than ad hoc code changes.
This makes it easier to review, version, and audit changes that affect how allocations and risk assessments are computed.
Infrastructure security
The infrastructure that runs FortisX is secured with standard hardening and isolation practices:
Network segmentation
Internal services are not directly exposed to the public internet unless required.
Administrative interfaces are restricted to controlled networks or VPNs.
System hardening and patching
Operating systems and platform components are kept up to date with security patches.
Default services and ports that are not needed are disabled.
Backups and recovery
Critical data stores are backed up regularly.
Restoration procedures are tested periodically to ensure that data can be recovered in a controlled manner.
Logging and audit trails
Security-relevant events (such as authentication attempts, policy changes, configuration updates, and administrative actions) are logged.
Logs are protected from tampering and retained for periods sufficient to support investigations and compliance reviews.
Independent security assessments and audits
Internal controls are complemented by independent reviews from specialised security firms. Selected components of the FortisX stack have been, and are expected to continue to be, reviewed by external providers such as Certik and Cyberscope, alongside other qualified auditors, with a scope that can include:
Application and infrastructure security reviews
Third-party security firms review components of the platform, including APIs, administrative interfaces, and deployment architecture.
Model and policy auditability
Reviews that focus on how risk models and policies are defined, versioned, and enforced, and whether they can be reliably reconstructed over time.
Operational and process assessments
Evaluations of incident response, change management, and access control processes.
Public artefacts of these reviews are referenced in the legal and documentation bundle, for example:
Security Assessment (Certik) – Audit report
Security Assessment (Cyberscope) – Audit report
The scope, frequency, and findings of such assessments depend on the maturity of the platform and the requirements of its clients. Where appropriate, summaries or attestations (for example, from Certik, Cyberscope, or similar firms) may be shared with users under agreed conditions so they can incorporate them into their own due diligence.
External assessments do not replace internal responsibility for security; they provide an additional layer of scrutiny and feedback.
Compliance alignment
FortisX is designed to be integrated into environments where formal governance and compliance processes are in place, especially for institutional users. While the platform itself is not positioned as a regulatory framework, it supports compliance efforts by:
providing clear audit trails for:
changes to risk models and policies;
allocation evaluations and proposals;
operational incidents and resolutions;
enabling segregation of duties between teams that define policies, operate infrastructure, and approve or execute allocations;
exposing versioned documentation and configuration so that governance bodies can see which assumptions were in effect at a given time.
Regulatory obligations vary between jurisdictions and organisations. FortisX does not attempt to define or satisfy those obligations on behalf of its users; instead, it aims to provide artefacts and controls that can be incorporated into existing frameworks.
Summary
Security in FortisX is approached as a combination of:
architectural decisions (separation of duties, non-custodial design);
technical controls (access control, encryption, hardening, monitoring);
process discipline (review, change management, incident response);
independent review (external security assessments and audits by firms such as Certik, Cyberscope, and other qualified providers where appropriate).
Together, these measures are intended to ensure that analytics, risk models, and policy evaluations can be relied upon as part of a broader staking and governance framework, while keeping control over assets and execution with the organisations that use the platform.
Last updated