iShare Cloud Hosted Life-cycle & Compliance Policy – Customer Summary
This summary describes how Astun manages the lifecycle, security and upgrades of the iShare Cloud hosted platform, and what this means for customers using the service.
1. Purpose and Scope
This policy sets out how Astun:
Maintains supported, secure and compliant versions of iShare Cloud and associated services
Manages software versions from introduction through to end of life (EOL)
Handles security vulnerabilities, patches and emergency maintenance
Plans and executes upgrades, including long-term support (LTS) and long-term release (LTR) versions
The policy applies to all Astun-managed iShare Cloud environments and related managed components (for example, supporting databases, operating system images and core dependencies). It is customer-facing and forms part of the service description for hosted iShare Cloud.
2. Shared Responsibility Model
Astun operates iShare Cloud under a shared responsibility model.
Astun is responsible for:
Provisioning, operating and monitoring the iShare Cloud hosting environment
Applying security patches and software updates to the platform and managed components
Defining and enforcing supported versions, lifecycle stages and EOL dates for hosted components
Responding to security vulnerabilities in line with defined service levels
Customers are responsible for:
Using the service in accordance with this lifecycle policy and the relevant terms of service
Planning and testing their own applications, integrations, configurations and data against new versions within the agreed windows
Providing appropriate test contacts, feedback and change approvals within the stated timeframes
3. Versioning and Release Types
Astun uses semantic versioning for iShare Cloud and related components:
Major version (X.y.z): significant changes that may introduce backward-incompatible behaviour and new functionality
Minor version (x.Y.z): new features and improvements that remain broadly backward compatible
Patch version (x.y.Z): bug fixes, security patches and minor improvements with no intentional breaking changes
Releases are categorised as:
Standard releases: regular feature and improvement releases that customers are expected to adopt within the normal upgrade cycle
LTR/LTS releases: designated long-term releases offering a longer support window with a focus on stability and security
4. Lifecycle Stages: LTR, LTS and EOL
Each supported version progresses through defined lifecycle stages.
Active (current) support:
Applies to current standard and LTR/LTS releases
Includes security and bug fixes, performance improvements and feature updates (for non-LTS)
Long-Term Release / Long-Term Support (LTR/LTS):
Designated versions with an extended support period
Primarily receive security and critical bug fixes, not frequent new features
End of Life (EOL):
A version reaches EOL when Astun no longer provides routine support, fixes or security patches for that version
Hosted environments must be upgraded away from EOL versions within the timelines in this policy
Astun will publish which versions are in Active, LTR/LTS and EOL status, and will communicate upcoming EOL milestones in advance.
5. Mandatory Upgrades and EOL Policy
To maintain a secure and supported platform, Astun enforces mandatory upgrades when:
A hosted environment is running a version that is approaching or has passed EOL
Security, compliance or operational requirements necessitate moving to a newer version
Astun will normally provide at least 90 days’ notice of a mandatory upgrade path for non-emergency lifecycle changes, including:
The target version(s) and lifecycle stage (for example, LTS)
Expected impact and required customer actions
If a customer does not cooperate with scheduling within the communicated windows, Astun may implement a forced upgrade to keep the environment in a supported and secure state.
6. Security Vulnerabilities and Patching SLAs
Astun monitors for vulnerabilities in iShare Cloud and its dependencies, assesses severity and applies patches in line with defined response and remediation targets.
Indicative handling includes:
Critical and high-severity vulnerabilities: expedited assessment and patching on an accelerated timescale, which may require emergency maintenance
Medium and low-severity vulnerabilities: scheduled into regular maintenance windows or planned upgrades
Astun strives to align remediation with industry expectations for cloud services and may adjust schedules when a vulnerability has active exploits or regulator expectations.
7. Emergency Maintenance
Where urgent action is required to address a critical vulnerability, service stability issue or compliance obligation, Astun may perform emergency maintenance outside normal change windows.
In such cases:
Astun will provide as much advance notification as is practicable, which may be as short as 48 hours for critical issues
Emergency changes may be applied without full customer testing cycles where risk to security or availability is judged to be higher than the risk of change
8. Upgrade Planning, Staging and Testing
Astun aims to make upgrades predictable, tested and low-risk.
Key elements include:
Pre-upgrade staging: upgrades are normally applied first to non-production or staging environments to allow customer testing
Customer testing window: customers are typically given a defined period (for example, 10 working days) to carry out validation and raise any material issues
Scheduling with customers: Astun will propose dates and times for production upgrades, considering business hours and blackout periods where agreed
If issues are identified in staging that block go-live, Astun will work with the customer to resolve them and, where necessary, reschedule the production upgrade within reasonable bounds.
9. Rescheduling and Forced Upgrades
Astun recognises that customers may occasionally need to reschedule planned upgrades.
Rescheduling is handled as follows:
Customers should request changes to proposed upgrade dates at least 5 working days in advance where possible
Astun will offer alternative dates within the remaining lifecycle or notice window
However, when a version is approaching or has reached EOL, or where security or compliance risk is high, Astun may enforce a forced upgrade by a specified deadline, even if a customer has not explicitly approved the change.
In a forced upgrade scenario, Astun will:
Provide clear written notice of the intended upgrade and target version
Offer at least one staging environment or test window in advance of the forced date, where feasible
10. Key Time Windows and Notice Periods
The policy refers to several standard time windows that guide planning and communication:
90 days: typical minimum notice before mandatory lifecycle-driven upgrades where there is no immediate security pressure
14 days: common notice period for routine maintenance or minor upgrades that do not materially change functionality
48 hours: minimum target notice for emergency maintenance and critical vulnerability remediation where delay would increase risk
10 working days: indicative customer testing window for staged upgrades prior to production deployment
5 working days: indicative minimum lead time for customers to request rescheduling of planned upgrade dates
Actual timeframes may vary depending on the severity of issues, regulatory requirements and agreed service levels. Astun will always balance security, stability and customer impact when applying these windows.
11. Customer Communication and Governance
Astun will communicate lifecycle milestones, upgrade plans and significant security updates through agreed channels, such as service announcements and direct customer notifications.
Customers should ensure that appropriate operational and technical contacts are kept up to date so that they receive and can act on lifecycle and upgrade communications in good time.