Otaka Cloud Security

Physical Security

• Otaka Cloud’s colocated servers are housed at NorwichDC, a facility providing controlled physical access
• All physical maintenance is performed exclusively by the director
• NorwichDC engineers are not permitted physical access or remote hands to any Otaka Cloud server

Chassis Intrusion Detection

Each colocated server has Chassis Intrusion Detection (CID) enabled. Restrictions are permanently enabled on all out-of-band management interfaces, preventing any remote clearance of intrusion events.

• Any intrusion event immediately pages Otaka with P1 urgency and places the server into a fail-closed state, preventing boot until the notification is cleared
• Clearing a CID notification requires physical presence at the server, as no remote clearance path exists
• CID notifications are cleared locally using a strong password held exclusively by the director, only after all physical verification checks have been completed

For unexpected intrusion events, CCTV footage is requested from NorwichDC for the relevant time window before clearance is granted. All physical security checks are then performed on-site: part serial numbers, internal seals, and drive bay locks are verified against the expected state on record. The internal server state is photographically documented at each access event using high-resolution imaging, providing a reference baseline against which any subsequent access can be visually compared to detect minute physical changes. The access register is updated and cryptographically signed by the director upon completion.

Physical Security Seals and Part Registry

Tamper evident security seals are applied to all servers and drive bays. Seal serial numbers are recorded and verified at every physical access event, with the new expected state logged in the access register.

All hardware part serial numbers are recorded, including drive serial numbers given their role in the data destruction and custody chain.

Drive End-of-Life and Data Destruction

When a drive reaches end of life (EoL), Otaka Cloud follows a strict destruction procedure:

• The drive is securely erased prior to removal using tools that both issue Block Erase and discard the on-controller encryption key
  • This step serves as a transit security measure as in the event the drive is lost or stolen before the formal certificated erase, the data remains in an unrecoverable state
• The retired drive is physically removed and the serial number matched against the relevant logs
  • A tamper evident security seal is applied to physically secure the drive in transit
• The drive is cryptographically erased via the built in Secure Erase function, discarding the on controller encryption key
• ATA Secure Erase issues the drive controller's Block Erase command, applying voltage across all NAND cells to reset them to factory state
  • Otaka does not operate drives that do not support these erasure primitives
• The erased drive serial number is matched against the initial removal log, and the outputted Certificate of Erasure is recorded on the drive register
• The director personally records photographic evidence including the erased drive serial number and the serial number of its replacement in the registry
• The drive is transferred to a certified destruction partner operating at BS EN 15713 standards, with full chain of custody. The partner issues a Certificate of Destruction upon completion, which is logged on the drive register alongside the Certificate of Erasure
  • The destruction partner is documented in Otaka Cloud's internal compliance records and is available upon request

Customers may request a Certificate of Erasure at any time. Customers may also subscribe to the drive-array mailing list, through which certificates are automatically issued whenever a drive change occurs in the array hosting their data.

Chain of Custody for Parts

Any server part leaving NorwichDC is subject to a full chain of custody audit log entry, signed off by the director, recording the reason for removal, the recipient, date and time of transfer, and the method of transport. If the part contains or has contained customer data, all erasure procedures are completed and recorded on the drive register prior to external transfer, regardless of destination, for compliance reasons and data safety.

Data Redundancy

Otaka Cloud operates a geographically redundant backup architecture. All customer data is backed up to a secondary server, physically separated from the primary datacenter located in North East United Kingdom. In the event of a physical disaster affecting either region, data remains recoverable from the unaffected site.

Backup Encryption

All backup data is encrypted client-side prior to transmission using AES-256-GCM. As encryption occurs before data leaves the client, the backup server receives and stores only encrypted chunks and never has access to plaintext data. In transit, backup traffic is further protected by TLS at the application layer, providing independently redundant transport encryption. Dataset encryption keys are held exclusively by Otaka Cloud and are never transmitted to or stored on the backup server.

Key Hygiene

Backup encryption keys are themselves protected by a master key pair. The RSA private key is held exclusively in offline physical storage, entirely air-gapped from any digital system, ensuring no remote attack path exists against the key material. Key rotation, time and date, and reason is recorded in a key hygiene register.

Backup Integrity

Each backup produces a manifest file containing a SHA-256 checksum for every backup file alongside its size. This manifest is used to verify the integrity of each backup independently of any restore operation. Scheduled verification jobs run against all backup datastores to detect silent corruption and bit rot.

Customer environments have no access path to the backup infrastructure, ensuring that a compromised environment cannot tamper with, encrypt, or destroy its own backup data.

An automated weekly test pulls a randomly selected customer environment and performs a smoke test restore, verifying that data is recoverable and intact under a full disaster recovery scenario. Results are logged and reviewed as part of Otaka Cloud's routine audit process.

Backup Network Isolation

The backup server is accessible exclusively over a private encrypted mesh network. All tunnels are direct peer-to-peer connections with no external infrastructure dependencies during transport. The backup server has no exposure to the public internet.

Backup Interval

The backup interval for your environment is defined by your hosting agreement with Otaka Cloud. The minimum offsite backup interval across all agreements is every 72 hours.

Drive Redundancy

Customer data is stored on a storage pool comprised of mirrored drive pairs, ensuring any single drive failure results in zero data loss and uninterrupted service. Drive failures are paged as P2 to ensure prompt replacement before redundancy is degraded. This drive-level redundancy operates independently of the offsite backup architecture.

Operational Security

Platform Integrity

All server firmware is cryptographically verified at boot. Secure Boot is enabled by default on all servers, with a dedicated virtual TPM for each guest, extending the root of trust into every customer environment.

All storage pools are encrypted, with each customer environment encrypted using a key sealed to its virtual TPM. If Secure Boot integrity within a customer environment is violated, the affected environment remains in a fail-closed state and will not boot, preventing access to encrypted data under a compromised boot chain.

Network Segmentation

Each customer is provisioned with a dedicated private subnet in which all of their servers operate. Servers within the same customer environment are isolated from one another by default, with only the minimum necessary ports and protocols opened for required cross-server communication.

Threat Detection

Otaka Cloud operates a security monitoring platform providing automated threat detection, response, and paging across all customer environments.

• All servers undergo automated vulnerability scanning by default, identifying components requiring patches
• Real-time policy monitoring and file integrity monitoring continuously examine endpoints for indicators of compromise, including hidden ports, unexpected files or permission changes, covert processes, and software malfunctions
• Automated ransomware detection identifies and responds to ransomware behaviour on protected endpoints using behavioural detection techniques, covering both known and emerging threats
• Application and system logs from customer environments are continuously analysed for anomalies
• A security configuration assessment runs periodically against all infrastructure to identify deviations from security best practices and established policy
• Vulnerability assessment is performed against all monitored endpoints using continuously updated vulnerability intelligence feeds, providing live visibility into vulnerable OS components and applications
• Perimeter network monitoring continuously inspects traffic across all customer environments, automatically blocking and reporting malicious connections using an intrusion detection and prevention system

System Hardening

All servers are deployed with a defined set of Otaka Cloud's custom kernel and OS-level hardening parameters applied by default as part of provisioning. These include network stack hardening, memory protection measures, and kernel-level restrictions.

Critical system directories are additionally protected by default, preventing persistent modification to core OS components. This ensures that even under active compromise, an attacker cannot make lasting changes to system binaries, libraries, or boot components.

Management Access Control

All management access to Otaka Cloud infrastructure requires device enrolment into a private management network prior to any access being possible.

Enrolled devices are subject to continuous endpoint security monitoring, with automated isolation triggered immediately upon detection of any indicator of compromise. Once enrolled, all management access requires hardware-backed keypair authentication.

All management traffic operates exclusively over a private encrypted mesh network, established as direct peer-to-peer tunnels with no reliance on external infrastructure during transport. No management interface is exposed to the public internet.

Out of band access via jumpbox is restricted exclusively to the director’s hardware-backed keypair, scoped to a single authorised device.

Access to individual customer environments follows the same enrolment, endpoint security, and hardware-backed keypair requirements as the broader management network. Each access event to a customer’s environment is logged in the access register along with reasoning.

All management access events are logged and retained within Otaka Cloud’s standard log retention window, can be requested at any time by customers, and are reviewed as part of Otaka Cloud's internal audit process.

Hypervisor Isolation

Each customer environment runs in a fully isolated virtual machine with dedicated vCPUs, memory, and storage allocation. No customer workload shares a kernel with another customer's workload. Hypervisor-level isolation ensures that compromise of one customer environment cannot affect another.

Incident Response

Otaka Cloud operates a structured incident response process designed to ensure rapid detection and thorough resolution of security and service incidents. All incidents are logged, cryptographically timestamped, and retained as part of Otaka Cloud's audit record.

Incident Classification

Incidents are classified into three severity tiers based on customer impact, service availability, and security posture. Classification is assessed at the time of detection and may be escalated or de-escalated as an incident develops.

• P1 (Critical)
  • Incidents with immediate or confirmed impact on service availability, data integrity, or security posture
  • Examples include total service loss, confirmed intrusion, malware or ransomware detection, chassis intrusion events, and suspected or confirmed data exfiltration
• P2 (High)
  • Incidents with partial or potential impact on service availability or redundancy
  • Examples include drive failure, degraded redundancy, customer observable performance degradation, and partial service failures
• P3 (Low)
  • Incidents with no immediate customer impact
  • Examples include infrastructure-level anomalies, non-critical configuration deviations, and performance regressions not yet visible to customer environments

Otaka Cloud reclassifies incidents as new information emerges during investigation.

Response Process

All incidents are detected through automated monitoring and paged immediately to the director with relevant context. Each incident is assigned a unique identifier at the point of detection, referenced consistently across all internal logs, customer communications, and post-incident documentation.

Upon receipt, the director triages the incident, assigns or confirms the severity classification, and logs initial findings with reasoning. All triage decisions are cryptographically timestamped at the point of entry, providing a tamper-evident audit record of the response process from first contact.

The response process follows:

• Detection
  • Automated monitoring detects and pages the incident with contextual information
• Triage
  • Severity classification is assigned, with initial findings logged and timestamped
• Containment
  • Affected systems are isolated to prevent further impact
  • For suspected breach events, the affected customer environment is snapshotted, cloned, and preserved in an air gapped forensic network, ensuring raw environment state is available for forensic analysis while recovery proceeds on the primary environment
• Eradication
  • The root cause is identified and resolved
• Recovery
  • Services are restored and their state is verified
• Closure
  • Incident closed, a post-incident review is conducted and shared with the affected customers

Customer Notification

Otaka Cloud operates a continuous transparency model. Customers are kept informed at every stage of an incident response, with updates pushed in real time as findings are confirmed.

Upon detection of a P1 or P2 incident, an automated notification is immediately dispatched to affected customers. For P3 incidents, a notification is provided upon resolution.

An incident timeline is maintained throughout the response process and updated in real time as the investigation progresses. This timeline provides a structured, cryptographically attested account of confirmed developments, and is made available to affected customers throughout the incident.

A dedicated live incident status page is maintained and updated at each significant milestone, allowing customers to check current status at any time.

Where an incident constitutes a personal data breach, Otaka Cloud will notify affected customers without undue delay in accordance with its obligations as a data processor under UK GDPR. An initial assessment of reportability is provided within 8 hours of a P1 incident being classified, ensuring customers retain sufficient time to meet their own notification obligations to the ICO under Article 33. Notification will provide sufficient information to enable customers, as data controllers, to meet their own regulatory notification obligations.

Post Incident Review

A post-incident review is conducted following resolution of all P1 and P2 incidents.

For service incidents, the review produces a structured postmortem covering the incident timeline, a structured account of internal response activity, identified root cause, remediation actions taken, and controls implemented or updated to prevent recurrence.

For P1 and P2 vulnerability patching events, a patch completion report is issued covering the incident timeline, a structured account of internal response activity, the CVE reference and affected component, and mitigations applied. Before patch application, a check for indicators of compromise is conducted to determine whether the vulnerability was exploited prior to remediation. Where indicators of compromise are identified, the event is escalated to a service-level P1 or P2 incident.

All reports are delivered to affected customers within 72 hours of incident resolution, with internal implementation details removed where appropriate.

Where suitable, and where no customer-identifying information or sensitive operational detail is present, Otaka Cloud publishes postmortems to Otaka Labs. This supports transparency, contributes to the wider security community, and provides an auditable public record of Otaka Cloud's operational standards.

P3 incidents are reviewed internally, as they have no immediate customer impact. Postmortems and internal response logs are retained as part of Otaka Cloud's internal audit record but are not shared with customers unless requested.