Information Security Whitepaper

Tillered Holdings Limited – Version 2.0, December 2025

Last Updated: 30 January 2026

Executive summary

Tillered Holdings Limited provides Layer 4 network acceleration technology compliant with enterprise security frameworks including ISO/IEC 27001:2022, Australian Information Security Manual (ISM), NIST Cyber Security Framework, and Motion Picture Association (MPA) Trusted Partner Network (TPN) best practices.

This whitepaper describes Tillered’s comprehensive security posture, operational controls, and governance model, demonstrating organisational maturity across:

• Governance & Organisational Security – Information Security Management System (ISMS) with executive oversight and quarterly compliance reviews
• Risk Management & Threat Modelling – Systematic threat modelling, formal risk assessments, and Business Impact Analysis (BIA)
• Personnel Security & Culture – Background screening, security awareness training, and segregation of duties
• Business Continuity & Disaster Recovery – Defined RTOs/RPOs, geographic redundancy, and regular DR testing
• Incident Response & Forensics – NIST 800-61 aligned procedures with 48-hour customer notification SLA
• Third-Party & Supply Chain Management – Vendor security assessments and shared responsibility models
• Compliance Framework Alignment – ISO/IEC 27001:2022, ISM, NIST CSF, and TPN Best Practices certification

Tillered operates transparently at OSI Layer 4, preserving end-to-end encryption and maintaining minimal access to customer data. All security controls follow NIST and ISO standards, with continuous monitoring via Vanta compliance platform and regular third-party audits. Tillered’s architecture ensures that Layer 4 network acceleration is delivered without compromising customer security posture or regulatory compliance.

Introduction

Context

Information and cyber security relate to the confidentiality, availability and integrity of information and data that is processed, stored and communicated by electronic or similar means, and protecting it and associated systems from external or internal threat. It is commonly recognised that information and cyber security involve the protection of critical information and ICT infrastructure, including supervisory control and data acquisition (SCADA) systems and industrial control systems (ICS), through the alignment of people, processes and tools.

Information Security (InfoSec) is the strategic effort to protect digital and physical data from unauthorised access, disclosure, alteration, and destruction. In an era defined by remote work, cloud computing, and AI-powered tools, maintaining the integrity and confidentiality of information assets is paramount to individual privacy and institutional trust. This paper examines current frameworks, emerging risks, and proactive strategies to build resilient, secure infrastructures.

Purpose

This document describes the process that commences when Tillered has been engaged within an organisation to provide network acceleration capabilities across the customer’s network. It provides a complete overview of how the Tillered Capability works at what layer of the OSI model and how that translates to a security agnostic engagement. Tillered has internal systems for coordinating response and resolution efforts to prevent or limit damage that may be caused internally to Tillered. The Tillered engagement team will work with the Customer Security and Network Management teams to ensure that all connectivity meets the Customer’s Security Requirements.

Tillered’s internal systems have been developed using the National Institution of Standards and Technology (NIST) Computer Security Incident Handling Guide and aligned with ISO/IEC 27001:2022 best practices.

Authority

This Whitepaper is managed by Tillered Legal Counsel, Chief Security Officer or delegate. This whitepaper has been endorsed by Tillered Senior Management and the Information Security Governance Committee, which are collectively responsible for ensuring that Tillered maintains a dependable and secure ICT environment aligned with industry standards and regulatory requirements.

The Chief Security Officer holds executive authority for information security policy, risk management, compliance monitoring, and incident response coordination across the organisation.

Review

This document will be reviewed annually by Tillered Legal Counsel, Chief Security Officer or delegate, or following any significant security incident or organisational change as deemed necessary by Tillered Senior Management. Additional reviews may be triggered by:

• Material changes to Tillered architecture or deployment model
• New regulatory requirements or compliance frameworks
• Third-party audit findings or penetration test results
• Customer-specific security requirements
• Lessons learned from incident response activities

Review outcomes and recommendations will be documented and tracked to resolution by the Information Security Governance Committee.

The Tillered solution – overview

Tillered is a cutting-edge solution designed to optimise TCP bandwidth through sophisticated routing, congestion control, and TCP session manipulation. Unlike traditional network optimisers that require expensive hardware and consultancy with the aim of increasing bandwidth, Tillered maximises the efficiency of your existing bandwidth, resulting in significantly improved data transfer rates. Tillered optimises TCP bandwidth through sophisticated routing, congestion control, and TCP session manipulation, deploying virtual Entry and Exit nodes in cloud datacentres such as Azure and AWS. At Layer 4, these nodes handle segmentation, error detection, flow control, and congestion management for both TCP and UDP streams.

OSI Transport Layer (Layer 4)

The Transport layer serves as the OSI model’s critical junction between end-systems, orchestrating how data is segmented, delivered, and reassembled across diverse networks. It assigns port numbers to differentiate multiple applications on a single host, multiplexing traffic streams while managing flow control and congestion to optimise throughput. By offering both connection-oriented services (as with TCP’s three-way handshake, sequencing, and retransmission for guaranteed delivery) and connectionless services (via UDP for low-latency or real-time communication), it balances reliability and performance based on application needs. Error detection, recovery mechanisms, and session maintenance are all handled at this layer, ensuring that high-level protocols and applications can exchange data reliably, efficiently, and securely over unreliable physical and network infrastructures. Layer 4 provides for reliable process to process message delivery and error delivery.

Because Layer 4 sits above the Physical, Data Link and Network Layers, information security for Tillered’s Layer 4 (Transport layer) nodes demands a tailored approach that aligns with its high-speed TCP/UDP acceleration and virtual node architecture and fits within the Customer’s Network Security Framework. The Layer 4 nodes (both Entry Node and Exit Node) sit below Session, Presentation and Application Layers. This means that management of network security and application-layer controls remain fully within the customer’s domain. Tillered operates below these layers and integrates without interfering with existing systems.

Layer 4 node architecture

Understanding the architecture of Tillered is crucial for realising its potential in optimising your network’s bandwidth and performance. This section provides a high-level overview of the key components and how they interact to deliver seamless and efficient data transfers. Tillered’s architecture comprises several core components designed to work together to optimise data transfer and network performance:

1. Entry Node
2. Exit Node
3. Tillered Portal

The Tillered solution – technical detail

1. Entry Node

The Entry Node is the initial point of contact within your network. It should be connected to your network, ideally on a separate network from the users or hosts that will benefit from Tillered. For example, in an office setting, you might have a main network for general use and a DMZ (Demilitarised Zone) network for the Tillered Entry Node.

• Role: Manages incoming traffic and optimises data packets before forwarding them to the Exit Node.
• Configuration: Automatically configures routes and provisions itself based on network changes.
• Security Posture: Operates within customer network security boundaries; subject to customer firewall policies and access controls.

2. Exit Node

The Exit Node is positioned as close as possible to your primary data transfer destination. For instance, if most of your data transfers are to the US, you would install an Exit Node on AWS in the us-east-1 region.

• Role: Receives optimised data packets from the Entry Node and routes them to their final destination efficiently.
• Configuration: Works in tandem with the Entry Node to ensure seamless data transfer.
• Geographic Redundancy: Multiple Exit Nodes can be deployed across different AWS/Azure regions to ensure availability and resilience.

3. Tillered Portal

The Tillered Portal is a web-based interface that allows you to manage and monitor your Tillered network.

• Role: Provides a centralised platform for configuring Entry and Exit Nodes, monitoring network performance, and viewing virtual IP assignments.
• Features: Includes dashboards for real-time monitoring, configuration tools, detailed logs for troubleshooting, and audit trails for all administrative actions.
• Access Control: Role-based access control (RBAC) with multi-factor authentication (MFA) for administrative accounts.

Data flow and interaction

1. Initial Connection: User devices initiate data transfers which are routed through the Entry Node by the Firewall.
2. Data Optimisation: The Entry Node optimises the data packets using Tillered’s congestion control and TCP session manipulation techniques.
3. Forwarding: Optimised data packets are forwarded from the Entry Node to the Exit Node over a secure and efficient network path.
4. Final Delivery: The Exit Node receives the optimised data packets and routes them to their original destination.

Routing and security

1. Traffic Routing: The new virtual IP assigned by the Entry node can be used by your company firewall to route selected traffic (via policy routing) or all traffic by setting it as the gateway for your main network.
2. Multiple Exit Nodes: Each Exit node added to your Tillered Network will provide additional virtual IPs on the Entry node, allowing for precise policy routing of traffic to specific destinations.
3. Enhanced Security: For an additional layer of security, you can create a VPN using IPSec on your firewall. Route all traffic from the Tillered Exit node through the IPSec tunnel, ensuring secure data transfers.

Key features

1. Congestion Control: The standard Tillered configuration works well for almost all network conditions, but the system can be adjusted for specific conditions. We continuously tweak and test network performance across various environments, from low-latency, reliable fibre networks to highly lossy and poorly performing satellite connections.
2. TCP Session Manipulation: By fine-tuning TCP sessions using the Linux network stack and adhering to TCP protocols, Tillered forces the TCP ramp-up to be as fast as possible, significantly enhancing initial transfer speeds.

System scope and boundaries

Because Tillered sits within the Customer Network (at whatever level or degree of Security that has been determined by the Customer Security Team):

1. Bandwidth optimisation

Tillered optimises all available bandwidth but cannot exceed the limits of the network connection itself. Bandwidth gains are subject to network topology, congestion levels, packet loss characteristics, and existing infrastructure limitations.

2. Encryption

Tillered does not do encryption. Tillered does not modify or inspect payload data. It is fully compatible with all customer-managed encryption, including TLS and IPSec. Tillered operates at OSI Layer 4 (transport layer) so encryption is implemented at the customer’s discretion, using existing network or application-layer tools. Tillered is fully compatible with these encryption methods and preserves all encrypted traffic end to end. The key to remember is whatever goes IN to a Tillered Entry Node will be DELIVERED to the Tillered Exit Node as is with no interruption.

3. Latency

While Tillered significantly improves data transfer speeds, it does not reduce latency. In some cases, latency might increase slightly due to the nature of our Tillered router in the backend. However, the overall performance gain from the increased transfer speed often outweighs this minor latency addition.

4. Packet inspection

Tillered does not inspect, decrypt, or log packet payloads at any point in transit. The system operates at OSI Layer 4 and interacts only with transport-layer headers (e.g., source IP, destination IP, ports) to support routing and acceleration. This architectural decision is intentional:

• It protects customer privacy.
• Ensures compatibility with encrypted and proprietary protocols.
• Preserves end-to-end data integrity.

No deep packet inspection (DPI), content analysis, or traffic logging occurs. This behaviour is consistent across all Tillered deployments, including public cloud, on-prem, and offline modes.

Governance framework

Information Security Management System (ISMS)

Tillered maintains a comprehensive Information Security Management System (ISMS) aligned with ISO/IEC 27001:2022 standards. The ISMS is designed to:

• Establish strategic security policies and procedures across all organisational functions
• Manage identified risks through systematic assessment and mitigation
• Maintain compliance with regulatory requirements (ISM, Privacy Act, TPN)
• Support continuous improvement through regular review and feedback

Governance structure

Chief Security Officer (CSO) – Executive responsibility for:

• Strategic security policy development and approval
• Risk management oversight and escalation
• Third-party security compliance
• Board-level reporting on security posture and incidents
• Vanta continuous compliance monitoring coordination

Information Security Governance Committee – Quarterly meetings to address:

• Security policy updates and approvals
• Annual risk assessment results and remediation tracking
• Incident response reviews and lessons learned
• Compliance audit findings and corrective actions
• Personnel security policy alignment

Security Operations Team – Ongoing management of:

• Access control administration and user provisioning
• Vulnerability scanning and patch management
• Incident detection, response, and investigation
• SIEM monitoring and alerting
• Security training coordination

Policy framework

Tillered maintains the following information security policies:

• Master Information Security Policy (v2.0 – July 2025)
• Acceptable Usage Policy
• Data & Asset Management Policy
• Access Control & Authentication Policy
• Risk and Crisis Management Policy
• Business Continuity Plan
• Disaster Recovery Plan
• Incident Response & Notification Policy
• Personnel Security (Background Screening, On-boarding, Off-boarding)
• Training & Awareness Program
• Change Control & Configuration Management Policy
• SIEM Security Logging and Monitoring Policy
• Data Management Policy

All policies are reviewed annually or upon significant organisational change, with version control and approval tracking maintained.

Governance review cadence

• Quarterly: Information Security Governance Committee meetings
• Semi-annually: Risk assessment updates and control effectiveness reviews
• Annually: Comprehensive policy review and ISMS assessment
• Post-Incident: Security posture reviews triggered by material incidents

Risk management & threat modelling

Risk management framework

Tillered applies a systematic risk management approach aligned with ISO 31000:2018/ISO 31010:2019 and NIST SP 800-30 (Guide for Conducting Risk Assessments). The risk management lifecycle includes:

1. Risk Identification – Systematic identification of threats, vulnerabilities, and potential impacts
2. Risk Analysis – Qualitative and quantitative assessment of likelihood and impact
3. Risk Evaluation – Prioritisation of risks based on residual risk levels
4. Risk Response – Selection of mitigation strategies (avoid, mitigate, transfer, accept)
5. Monitoring & Reporting – Ongoing tracking of risk status and remediation progress

Threat modelling

Tillered conducts formal threat modelling for critical systems and components. Threat modelling activities:

• Use structured methodologies (STRIDE, Attack Trees, or similar)
• Identify threats to Entry/Exit node architectures, Portal functionality, and cloud infrastructure
• Map controls to identified threats
• Track risk reduction through control implementation
• Update threat models upon significant architectural changes

Scope of threat modelling

• Entry Node compromise scenarios (unauthorised access, data manipulation)
• Portal authentication bypass and privilege escalation risks
• Cloud platform vulnerabilities and shared responsibility gaps
• Data path integrity threats at Layer 4
• Third-party dependency vulnerabilities (AWS, Azure, SaaS components)
• Insider threats and social engineering vectors
• Supply chain and software integrity risks

Business Impact Analysis (BIA)

Tillered conducts annual Business Impact Analysis to:

• Identify critical business functions and supporting infrastructure
• Quantify financial and operational impact of system unavailability
• Define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO)
• Prioritise recovery procedures
• Inform Business Continuity and Disaster Recovery planning

Critical system RTOs/RPOs

Risk assessment cadence

• Annual: Comprehensive formal risk assessment
• Per-Change: Risk analysis for significant architectural or policy changes
• Post-Incident: Risk assessment following material security incidents
• Continuous: Vulnerability scanning and threat intelligence monitoring

Compliance framework alignment

ISO/IEC 27001:2022 compliance

Tillered implements ISO/IEC 27001:2022 control families across organisational, people, physical, and technological domains:

Organisational Controls (A.5)

• A.5.1 Policies for information security – Master Information Security Policy approved by Senior Management
• A.5.2 Information security roles and responsibilities – CSO, Governance Committee, and operational security roles defined
• A.5.3 Segregation of duties – Role-based access control enforces separation of responsibilities
• A.5.4 Management responsibilities – CSO accountability for strategic security and risk management

People Controls (A.6)

• A.6.1 Screening – Background screening applied to all employees, contractors, and consultants
• A.6.2 Terms and conditions of employment – Security requirements incorporated into employment agreements
• A.6.3 Information security awareness, education and training – Annual mandatory training plus role-specific training
• A.6.4 Discipline process – Documented procedures for security policy violations
• A.6.5 Responsibilities after employment termination or change – Off-boarding procedures for access removal

Physical Controls (A.7)

• A.7.1 Physical security perimeters – Access control to data centres (AWS/Azure) verified via shared responsibility agreements
• A.7.2 Physical entry – Electronic access control with logging for facility access
• A.7.3 Securing offices, rooms and facilities – Restricted access to server rooms and operational areas

Technological Controls (A.8)

• A.8.1 User devices – Mobile Device Management (MDM) and endpoint protection for all company devices
• A.8.2 Privileged access rights – Multi-factor authentication and least privilege for administrative accounts
• A.8.3 Information access restriction – Role-based access control (RBAC) enforced across systems
• A.8.4 Access to cryptographic keys – Hardware Security Module (HSM) for key management and protection

Cryptography (A.10)

• A.10.1 Cryptographic controls – AES-256 for data at rest; TLS 1.3 for data in transit
• A.10.2 Cryptographic key management – Formal key lifecycle management with HSM protection

Operations Security (A.12)

• A.12.1 Operational planning and preparation – Change management and security hardening procedures
• A.12.2 Protection against malware – Endpoint Detection & Response (EDR/XDR) deployed across infrastructure
• A.12.3 Backup – Daily encrypted backups with geographic separation
• A.12.4 Logging – Centralised Security Information & Event Management (SIEM) with 1-year log retention
• A.12.5 Installation of software on operational systems – Formal change control for software deployments
• A.12.6 Management of technical vulnerabilities – Automated vulnerability scanning with 48-hour critical patch SLA
• A.12.7 Information systems audit considerations – Audit trails maintained and reviewed for all administrative actions

Australian Information Security Manual (ISM) alignment

ISM-1412: Data and Information Management

• Classification of Tillered metadata according to sensitivity
• Data retention policies aligned with Privacy Act 1988
• Secure handling of credentials and access tokens

ISM-1413: Information and Communication Technology Security

• System hardening per NIST baselines
• Network segmentation between Entry Nodes, production systems, and administrative zones
• Endpoint protection and host-based firewalls

ISM-1647: Access Control

• Role-based access control with least privilege
• Multi-factor authentication for privileged access
• Regular access reviews (quarterly minimum)
• Segregation of duties between development, operations, and security roles

ISM-1650: Encryption

• AES-256 encryption for sensitive data at rest
• TLS 1.3 minimum for data in transit
• Cryptographic key management aligned with NIST SP 800-57
• Transparency regarding encryption scope (Tillered operates at Layer 4; application-layer encryption remains customer responsibility)

NIST Cyber Security Framework (CSF) alignment

Identify

• Asset inventory maintained in CMDB
• Data classification scheme implemented
• Risk assessment conducted annually

Protect

• Access control policies enforced via RBAC and MFA
• Encryption standards for data at rest and in transit
• Security awareness training program
• Change control procedures

Detect

• SIEM continuous monitoring of infrastructure
• Vulnerability scanning and threat intelligence
• File Integrity Monitoring (FIM) for critical systems
• Automated security alerts for suspicious activity

Respond

• Incident Response Team with designated leadership
• Incident classification and escalation procedures
• Root Cause Analysis (RCA) for all incidents
• Customer notification protocol (48-hour SLA for material incidents)

Recover

• Business Continuity and Disaster Recovery plans
• Regular tabletop exercises and full DR tests
• Documented recovery procedures with assigned accountability
• RTO/RPO targets for critical services

TPN Best Practices Framework

Tillered has achieved “Fully Implemented” status for 40+ MPA Content Security Best Practices, including:

Organisational Security

• Information Security Management System (ISMS) with executive governance
• Formal policies for Business Continuity, Disaster Recovery, Risk Management
• Data classification and asset management procedures
• Incident Response with Root Cause Analysis and lessons learned
• Personnel security (background screening, on/off-boarding, training)

Technical Security

• Systems Configuration and hardening per security baselines
• Endpoint Protection with EDR/XDR capabilities
• Data I/O workflows with secure segmentation
• Security Information & Event Management (SIEM) with centralised logging
• Encryption standards for data at rest and in transit
• Vulnerability Management and patch management with defined SLAs

Physical Security

• Electronic Access Control (EAC) with logging and monitoring
• Facility security aligned with data centre provider controls (AWS/Azure)
• Entry/Exit point security for sensitive areas

Personnel security & culture

Background screening

All employees, contractors, consultants, and interns are subject to background screening before access is granted to Tillered systems or facilities. The Background Screening process:

• Applies to full-time employees, part-time employees, consultants, contractors, interns, freelancers, and temporary workers
• Complies with local laws, regulations, agreements, and cultural considerations (Australian context)
• Uses third-party background screening company for independent verification
• Results are retained and periodically reviewed
• Enhanced screening conducted for roles with access to provisioning systems or sensitive data

Roles subject to enhanced screening:

• Chief Security Officer and security team members
• System administrators with privileged access
• Portal administrators
• Development team members with code commit authority

On-boarding process

1. Background Screening Verification – Background check completed and results verified
2. Policy Communication – New employee acknowledges receipt and understanding of security policies
3. Confidentiality Agreements – NDAs and Confidentiality Agreements signed before access grant
4. Access Provisioning – Physical and digital access provisioned based on job role
5. System Access Setup – User accounts created, MFA enrolled, password requirements explained
6. Security Training – Mandatory information security awareness training completed
7. Role-Specific Training – Tailored training for role responsibilities (e.g., developers: secure coding; operations: change management)
8. Audit Trail Creation – Access provisioning recorded with system admin sign-off and date

On-boarding Requirements

• Applied to all full- and part-time employees, consultants, contractors, interns, freelancers, and temporary workers
• Applied on per-project basis where applicable (contractual engagements)
• Applies to third-party IT Service Providers with access limited to specific timeframe and enforced via account lockout

All signed agreements retained, and audit trail maintained for compliance and audit purposes.

Off-boarding process

1. Manager Notification – HR notifies IT Security of pending departure
2. Access Review – All assigned system and facility access reviewed
3. Data Transfer – Ownership of files and documentation transferred to manager
4. Access De-provisioning – Physical and digital access removed immediately upon separation
5. Equipment Return – Keys, fobs, badges, devices, and all company assets returned
6. Confidentiality Agreements – Exit NDAs and final Confidentiality Agreements signed
7. Audit Trail – Access removal recorded with date and system admin sign-off
8. Final Documentation – All signed agreements retained in personnel file

De-provisioning is immediate upon termination to minimise insider risk.

Training & awareness program

Training Requirements

• Frequency: Upon hire and annually thereafter
• Scope: Applied to all full- and part-time employees, consultants, contractors, interns, freelancers, and temporary workers
• Mandatory Topics: Information security policies and procedures, business email compromise, social engineering, ransomware, malware, and phishing threats, authentication best practices, Acceptable Use Policy and data handling requirements, incident response procedures and escalation, restriction of personal devices, project-specific requirements

Role-Specific Training

• Executive Management and Owners: Governance, risk oversight, and incident notification
• Developers: Secure coding practices, code repository security, third-party dependency management
• System Administrators: System hardening, access control administration, patch management, incident response
• Operations Team: Change management, monitoring and alerting, disaster recovery procedures
• All Personnel: Business email compromise and phishing awareness

Training Effectiveness

• Phishing Simulations: Semi-annual simulated phishing campaigns with metrics tracking
• Tabletop Exercises: Annual tabletop exercises for disaster recovery and incident response
• Quizzes and Assessments: Post-training assessments to verify understanding
• Effectiveness Metrics: Reported quarterly to Information Security Governance Committee

Training Records

All training attendance and completion dates maintained in a centralised training management system. Training logs are reviewed during on-boarding, access reviews, and incident investigations.

Segregation of duties

• Development vs. Operations: Developers do not have direct production system access; deployments reviewed by operations team
• Change Approval vs. Implementation: Change requests reviewed and approved by Change Control Board before implementation
• Audit vs. Operations: Security auditors have read-only access; cannot modify audit logs or security configurations
• Access Request vs. Approval: Access requests submitted to manager for approval; IT Security provisions based on approved request
• Backup vs. Recovery: Backup administration separated from recovery operations where feasible

Supply chain & third-party security

Cloud provider management

Tillered utilises Amazon Web Services (AWS) and Microsoft Azure for Entry/Exit Node deployment and core infrastructure. Security responsibility is distributed per the AWS and Azure Shared Responsibility Models.

AWS Shared Responsibility Model

AWS Responsibility (Infrastructure):

• Physical infrastructure security (data centres, HVAC, power, networking)
• Network infrastructure (firewalls, DDoS protection, edge services)
• Hypervisor security and isolation
• Storage infrastructure encryption
• AWS management console security

Tillered Responsibility (Configuration & Operations):

• Secure configuration of EC2 instances (OS hardening, security groups)
• Identity & Access Management (IAM) policies and role assignments
• Application-level encryption and key management
• Vulnerability management and patch deployment
• Security monitoring and log collection
• Access control to AWS management console

Azure Shared Responsibility Model

Azure Responsibility (Infrastructure):

• Physical data centre security and environmental controls
• Network infrastructure and DDoS protection
• Hypervisor security
• Azure management console security

Tillered Responsibility (Configuration & Operations):

• Virtual machine hardening and configuration
• Role-based access control (RBAC) for Azure resources
• Network segmentation (Virtual Networks, Network Security Groups)
• Application and data encryption
• Vulnerability management and patching
• Monitoring and logging

Service Level Agreements (SLAs)

• AWS: 99.99% availability per SLA
• Azure: 99.95% availability per SLA
• Tillered Hub: 99.95% availability target
• Incident response coordinated with cloud provider support teams

Security Control Verification

Tillered verifies cloud provider security controls through:

• Annual review of AWS and Azure security documentation
• Audit reports (SOC 2, ISO 27001 certifications) from cloud providers
• Security assessment questionnaires and attestations
• Periodic penetration testing in coordination with cloud providers

Contractor & consultant management

All contractors, consultants, and temporary workers undergo the same security vetting and on/off-boarding procedures as full-time employees:

Vetting Process

• Background screening via third-party screening company (applicable to role and jurisdiction)
• Execution of Confidentiality Agreements (NDAs) before access
• Role-based access provisioning with defined scope and duration
• Training on security policies and project-specific requirements

Access Management for Third Parties

• Access provisioning includes defined start/end dates and automatic account lockout
• Segregation of duties ensures third parties have only necessary access for assigned tasks
• Privileged access (if required) limited to specific timeframes with additional monitoring
• De-provisioning executed immediately upon contract termination or project completion

Vendor Security Assessment

For technology vendors and service providers (SaaS, infrastructure providers, consultants), Tillered conducts:

• Security questionnaire completion (vendor-specific or industry standard)
• Review of security certifications (ISO 27001, SOC 2, etc.)
• Evaluation of data handling and protection practices
• Assessment of third-party dependencies and supply chain risks

Software supply chain security

Dependency Management

• Cataloguing of all third-party dependencies and open-source libraries
• Software Bill of Materials (SBOM) maintained for all Tillered-developed components
• Tracking of licences and compliance requirements

Vulnerability Scanning

• Automated scanning of third-party libraries for known vulnerabilities
• Integration with security databases (NVD, GitHub Security Advisories, vendor advisories)
• Regular updates to vulnerability detection tools and signatures

Remediation

• Critical vulnerabilities (CVSS >= 9.0) remediated within 48 hours
• High vulnerabilities (CVSS 7.0–8.9) remediated within 1 week
• Medium/Low vulnerabilities addressed in regular maintenance cycles
• Patching validated in test environment before production deployment

Code Repository Security

• All source code maintained in secure, version-controlled repository
• Access to code repository restricted to authorised developers
• Code changes reviewed and approved before merge to main branch
• Encryption applied to code repository (at rest and in transit)
• Audit logs maintained for all repository access and modifications

Business continuity & disaster recovery

Availability commitments

Tillered targets a service availability of 99.95% for Tillered Hub and Entry/Exit Nodes, measured on a quarterly basis. Service availability is calculated as:

Uptime % = (Total Minutes – Downtime Minutes) / Total Minutes × 100%

Downtime excludes scheduled maintenance windows (announced 7 days in advance) and customer-caused outages.

Business Continuity Plan (BCP)

Tillered maintains a formal Business Continuity Plan addressing threats to critical business operations:

Identified Threats & Impacts

• Loss of Cloud Provider Region – Geographic redundancy enables failover to alternative AWS/Azure region
• Data Centre Failure – Multiple data centres and backups ensure service continuity
• Key Personnel Unavailability – Cross-training and documented procedures enable continuity
• Cyber Attack or Ransomware – Incident response procedures and backup integrity monitoring
• Supply Chain Disruption – Alternative vendor relationships and source redundancy

Business Impact Analysis (BIA)

BCP includes Business Impact Analysis defining:

• Critical Assets & Functions – Tillered Hub, Entry Node provisioning, monitoring and logging
• Recovery Time Objectives (RTO) – Maximum acceptable downtime for each function
• Recovery Point Objectives (RPO) – Maximum acceptable data loss
• Interdependencies – How systems and functions depend on each other
• Prioritisation – Recovery sequence based on business criticality

BCP Testing & Validation

• Quarterly Tabletop Exercises – Simulated outage scenarios with response team participation
• Annual Full Validation – Partial or full-scale exercises testing actual failover procedures
• Documentation Updates – BCP reviewed and updated following each exercise
• Lessons Learned – Findings incorporated into continuous improvement

Disaster Recovery Plan

Backup Strategy

Recovery Procedures

• Recovery Time Objective (RTO)
  • Tillered Hub: 4 hours
  • Entry Node provisioning: 1 hour
  • Exit Nodes: 4 hours
  • Full infrastructure: 8 hours
• Recovery Point Objective (RPO)
  • Configuration: 24 hours
  • Transaction data: 1 hour
  • Logs: Real-time (SIEM redundancy)

Restore Testing

• Quarterly: Partial restore tests (selected components)
• Semi-annually: Full environment restore test in isolated test environment
• Post-Incident: Recovery validation following any material incident
• Test results documented with recovery metrics tracked

Geographic redundancy

• Entry Nodes: Can be rapidly reprovisioned in alternative AWS region (< 1 hour)
• Exit Nodes: Deployed across multiple AWS regions (us-east-1, eu-west-1, ap-southeast-2) with automatic health monitoring
• Portal: Deployed in primary and failover regions with database replication
• Failover: Automated health checks trigger failover to standby infrastructure for critical components

DR team

• Designated DR Coordinator with executive authority to activate recovery procedures
• Cross-functional recovery team including IT operations, network engineering, and senior management
• Annual DR plan review and team training
• Current contact information maintained and reviewed quarterly

TPN studio readiness

Tillered serves clients across multiple sectors, including Media and Entertainment workflows where performance and security expectations are especially stringent. Tillered is designed for secure integration into customer-controlled environments and aligns with the expectations of studios operating under the Trusted Partner Network (TPN), governed by the Motion Picture Association (MPA).

While Tillered does not store, process, or inspect production content, studios and content owners require vendors to meet high security standards across personnel, systems, and support processes. Tillered’s architecture and operating model reflect a minimal access posture by design.

Tillered integrates transparently into production and post-production environments without requiring changes to existing tools or workflows. It is designed to coexist alongside file transfer accelerators, remote collaboration platforms, and cloud-based delivery systems commonly used in the Media and Entertainment industry.

TPN compliance evidence

Tillered has undergone formal self-assessment against the TPN Best Practice Questionnaire v5.3.1 and achieved “Fully Implemented” status across 40+ control domains, including:

• Information Security Management System (ISMS)
• Risk Management & Threat Modelling
• Personnel Security (background screening, on/off-boarding, training)
• Incident Response & Forensics
• Business Continuity & Disaster Recovery
• Access Control & Authentication
• Data Classification & Asset Management
• Encryption & Cryptography
• Systems Configuration & Hardening
• Endpoint Protection & Vulnerability Management
• Third-Party & Vendor Management

Formal TPN assessment report available upon request (confidential distribution).

Security controls architecture

Tillered follows a minimal-access, security-conscious approach aligned with ISO/IEC 27001 and NIST principles. While Tillered does not access or manage customer content, we maintain internal controls to safeguard our platform, provisioning interfaces, and operational environment.

Authentication & authorisation

Multi-Factor Authentication (MFA)

• Mandatory for all Tillered Hub administrative access
• Methods: Hardware tokens (FIDO2/WebAuthn) preferred; time-based one-time passwords (TOTP) acceptable; SMS deprecated
• Scope: All Hub administrators, Portal users with elevated privileges
• Enforcement: Account lockout after 5 failed authentication attempts; 15-minute unlock timeout

Role-Based Access Control (RBAC)

• RBAC enforced across all Tillered systems (Portal, infrastructure, code repositories)
• Roles Defined: Administrator, Operator, Auditor, Viewer (read-only)
• Least Privilege: Users assigned minimum required role for job function
• Regular Reviews: Quarterly access reviews to verify role appropriateness
• Privileged Access Management (PAM): Elevated access logged and monitored; session recording for critical activities

Session Management

• Session Timeout: 15 minutes of inactivity triggers automatic logout
• Concurrent Sessions: Limited to one active session per user; new login invalidates previous session
• Secure Tokens: Session tokens generated cryptographically; signed and encrypted
• Token Expiration: Maximum 8-hour session validity; refresh tokens require re-authentication

User Provisioning & De-provisioning

• Provisioning: Initiated by manager request; approved by department head; provisioned by IT Security within 24 hours
• De-provisioning: Immediate upon termination or role change; all access removed within 1 hour
• Audit Trail: All provisioning/de-provisioning actions logged with approver and executor identities
• Compliance: Access reviews conducted quarterly; documented with sign-off

Data protection

Encryption at Rest

• Algorithm: AES-256 encryption for all sensitive data at rest
• Scope: Database encryption, backup encryption, temporary file encryption
• Key Management: Encryption keys stored in Hardware Security Module (HSM); separate from encrypted data
• Key Rotation: Annual encryption key rotation with backward compatibility for decryption

Encryption in Transit

• Protocol: TLS 1.3 minimum for all Tillered Hub API communications
• Certificate Authority: Certificates issued by trusted CA; certificate pinning implemented for critical communications
• Cipher Suites: Only strong cipher suites enabled; weak ciphers (RC4, DES, MD5) disabled
• Perfect Forward Secrecy (PFS): Ephemeral key exchange ensures compromise of long-term keys does not compromise past sessions
• Transport Security: All inter-component communications encrypted (Entry Node to Exit Node, Portal to Infrastructure, etc.)

Cryptographic Key Management

• Key Generation: Cryptographically random key generation per NIST SP 800-133
• Key Storage: Master encryption keys stored in Hardware Security Module (HSM) with tamper detection
• Key Lifecycle: Formal procedures for key generation, rotation, archival, and destruction
• Escrow: No key escrow; loss of master key results in permanent data inaccessibility (intentional design)
• Documentation: Key management procedures documented and reviewed annually

Access control for infrastructure

Network Segmentation

• Tier 1 (Internet-facing): Tillered Portal API exposed to internet with WAF protection
• Tier 2 (Internal Services): Entry/Exit Nodes, backend services behind VPN/VPC
• Tier 3 (Administrative): Internal management networks restricted to authorised personnel VPN
• Access Control Lists (ACLs): Strict layer 2/3 ACLs enforce allowed traffic flows
• Intrusion Detection: Network intrusion detection systems monitor for anomalous traffic patterns

Systems Hardening

• Operating System: Security hardened per NIST SP 800-123 (Linux hardening baselines)
• Only required services enabled; unused ports closed
• Host-based firewalls enabled on all systems; default-deny incoming rules
• Monthly patching cycle; critical patches within 48 hours; testing in pre-production
• Configuration management (Terraform, Ansible) enforces consistent security baselines
• Regular Audits: Configuration compliance audited monthly; deviations remediated immediately

Endpoint Protection

• Anti-Malware: Endpoint Detection & Response (EDR) deployed across all infrastructure
• Threat Intelligence: Real-time threat feeds integrated with EDR for emerging threat detection
• Behavioural Analysis: EDR monitors for suspicious processes, network connections, and file system activities
• Response Capability: Automated response to confirmed threats (process termination, quarantine, isolation)
• Central Management: All endpoints managed from security console with centralised policy enforcement

Monitoring & logging

Security Information & Event Management (SIEM)

• Centralised Logging: All infrastructure components log to central SIEM platform
• Log Sources:
  • Firewalls (network access, blocked connections)
  • Authentication servers (login attempts, MFA events)
  • Network operating systems (routing changes, protocol modifications)
  • Entry/Exit Nodes (traffic patterns, performance anomalies)
  • Virtual machines/servers (system events, error logs)
  • Storage services (access logs, data modifications)
  • Databases (queries, access, data changes)
  • Tillered Hub (API access, configuration changes, administrative actions)

Log Attributes Captured

• Source IP address and identity
• Destination IP address and port
• Username and user role
• Action attempted and result (success/failure)
• Execution path and file identifiers
• Timestamp (synchronised via NTP)
• Event classification (informational, warning, critical)

Alerting & Response

• Automated Alerts for security events:
  • Multiple failed authentication attempts (threshold: 5 failures/15 min)
  • Successful privileged access attempts (all admin login events)
  • Unusual file size or time-of-day data transfers
  • Administrator account creation, modification, or deletion
  • File Integrity Monitoring (FIM) violations on critical binaries
  • Firewall, IDS/IPS, or endpoint protection failures
  • SIEM or logging system failures
• Alert Escalation:
  • Severity-based escalation (Critical > High > Medium > Low)
  • Automatic notification to security operations team
  • On-call engineer paged for Critical/High severity events
  • Management escalation for potential incidents

Log Retention & Protection

• Retention Period: Logs retained for 1 year minimum or maximum time allowed by law
• Protection: Logs encrypted both in transit and at rest
• Access Control: Read/modify/delete access restricted to authorised security personnel only
• Audit Trail: All access to logs logged for non-repudiation
• Dual Authorisation: Deletion of audit logs requires dual approval from CSO and IT Manager

Change management

All changes to production systems, security controls, or configurations follow formal change control:

1. Change Request Submission with business justification and technical details
2. Risk Assessment for potential security, availability, or performance impact
3. Security Review for compliance and control implications
4. Change Control Board (CCB) approval
5. Implementation in test environment first, then production
6. Verification of intended functionality
7. Documentation with approval, implementation details, and verification results

Security-Specific Changes

Changes impacting security controls (firewall rules, authentication policies, encryption settings) require:

• Explicit security team approval
• Senior engineer sign-off (team lead minimum)
• Pre-change security assessment
• Post-change security validation
• Documented rollback procedure
• Executive notification for critical changes

Encryption and transparency

Tillered operates at OSI Layer 4 and is designed to be fully transparent. It does not terminate, decrypt, or modify TCP or UDP payload data. Instead, it preserves all original session parameters – including source IPs, ports, and transport-layer headers – while accelerating delivery across long-haul paths.

Tillered supports all customer-managed encryption methods, including:

• TLS/SSL (e.g., HTTPS, FTPS, SFTP)
• IPSec tunnels
• Application-level encryption
• VPN tunnels (customer-provisioned)

Because Tillered does not modify payloads or terminate sessions, encrypted traffic remains fully intact from source to destination. Customers are responsible for implementing the encryption appropriate to their workflow and threat model. Tillered is compatible with both encrypted and unencrypted traffic.

How Tillered preserves end-to-end encryption

Tillered Entry and Exit Nodes preserve original transport headers and encryption. Payload data remains untouched from end to end. Traffic is not decrypted at any point – it is only accelerated through the Tillered network path.

Incident response and notification

Tillered’s internal incident response procedures are aligned with the NIST 800-61 Computer Security Incident Handling Guide. While Tillered does not store or process customer data, we recognise the importance of quickly identifying and responding to any event that may impact system integrity or customer deployments.

Incident classification

Incident response team

• Incident Commander: Senior engineer designated to lead response
• Security Analysts: Investigates incident, gathers evidence, performs forensics
• Infrastructure Team: Implements containment and recovery actions
• Communications Coordinator: Manages customer notifications and status updates
• Executive Sponsor: CSO or designate providing strategic guidance

Detection and response workflow

1. Detection: SIEM identifies security event; automated alert triggered
2. Triage: On-call engineer assesses alert; determines if incident or false positive
3. Escalation: Incident Commander assigned; response team mobilised
4. Investigation: Evidence collected; root cause identified; impact assessed
5. Containment: Incident isolated to prevent further damage or data exfiltration
6. Eradication: Root cause remediated; attacker access removed; systems hardened
7. Recovery: Affected systems restored from known-good backups; functionality validated
8. Post-Incident: RCA conducted; lessons learned documented; preventive measures implemented

Incident investigation & forensics

• Evidence Preservation: Digital evidence preserved following chain-of-custody procedures
• Forensic Analysis: Logs, system snapshots, memory dumps analysed to determine attack vector and scope
• Timeline Reconstruction: Detailed timeline of attacker actions constructed
• Root Cause Analysis (RCA): Systematic analysis to identify root cause(s)
• Documentation: Incident report prepared with findings, recommendations, and lessons learned

Customer notification

Notification Protocol

Customers will be notified within specified timeframes of any security event that:

• Affects the availability or integrity of the Tillered Hub
• Could interfere with node provisioning or traffic routing
• Requires action or awareness on the customer’s part (e.g., updated credentials, node reprovisioning)
• Involves unauthorised access or data exposure

Notification Content

Initial notification includes:

• Incident Summary: What happened, when it occurred, systems affected
• Impact Assessment: Potential business impact and scope
• Immediate Actions: Actions Tillered is taking to contain and remediate
• Customer Actions: Actions customer should take (if any)
• Contact Information: Incident commander contact and escalation procedures

Update Cadence

• Critical Incidents: Daily updates until resolved; resolution statement upon closure
• High Incidents: Updates every 2–3 days; closure notification upon resolution
• Medium/Low Incidents: As appropriate; summary provided upon closure

Final Incident Report

Delivered within 15 business days of incident closure, including:

• Executive summary
• Incident timeline and progression
• Root cause analysis findings
• Scope and impact assessment
• Remediation actions taken
• Preventive measures to prevent recurrence
• Recommendations for customer security posture

Continuous improvement

• Tabletop Exercises: Quarterly exercises for core incident response team covering simulated breach, ransomware, DDoS, insider threat, and supply chain compromise scenarios
• Annual Penetration Testing: Third-party penetration testing covering application security, network security, physical security, and social engineering
• Security Training Updates: Post-incident training and emerging threat awareness incorporated into training curriculum
• Policy & Process Updates: Incident Response Plan reviewed following each significant incident; lessons learned inform process updates