When a platform builds your application packages, it is creating assets that matter. Not just to the deployment to your compliance posture, your audit trail, your vendor independence, and in regulated sectors, your legal obligations.
The question of where those packages live is not a technical detail. It is a sovereignty question. And most organisations do not ask it until they have already accepted an answer they would not have chosen.
An application package is not just a compressed installer. By the time ALICE has processed an application through its pipeline, a package contains:
For an enterprise estate with 186 managed application families each potentially across multiple versions these packages represent a significant body of work. They encode enterprise packaging standards, deployment decisions, and configuration that took time and expertise to establish.
The question of who holds custody of those assets is consequential.
When an application management platform stores packages in its own infrastructure, several risk categories emerge that are not immediately visible during procurement.
Access dependency. If access to the platform is interrupted for any reason, including commercial dispute, service outage, or contract termination the packages stored in that infrastructure may not be immediately accessible. For an organisation mid-migration or mid-deployment, that dependency is a programme risk.
Audit limitations. Regulated organisations must be able to demonstrate who has had access to their application assets, under what controls, and in which jurisdictions. When packages are stored in a vendor’s infrastructure, the organisation’s ability to evidence this independently of the vendor is limited.
Data sovereignty exposure. For organisations in Defence, central government, or financial services, the location of application assets matters. Packages may contain proprietary software, licensing artefacts, or configuration that reflects security-sensitive deployment decisions. Vendor-hosted storage may place those assets outside the organisation’s jurisdictional control.
Portability constraint. If the organisation decides to change platforms, the packages stored in a vendor’s infrastructure may not be portable in a format directly usable elsewhere. The decision to leave becomes more expensive than it appeared at the outset.
ALICE takes the opposite approach. Every package created through ALICE’s pipeline is stored in the customer’s own Azure Blob Storage account not in ALICE’s infrastructure.
The configuration is straightforward: a Tenant Administrator provides the storage account name, container name, and connection string through the ALICE settings interface. ALICE validates the connection and stores the configuration at tenant level. From that point, every package ALICE creates PSADT folders, .intunewin files, version artefacts is written to the customer’s own container.
ALICE writes to the customer’s storage. The customer owns what is written.
Full access, always. The customer can access, audit, download, back up, or migrate their packages at any time, independently of ALICE. The packages are in Azure Blob Storage under the customer’s own subscription, subject to the customer’s own access controls and retention policies.
No vendor custody. ALICE does not hold a copy. The customer’s Azure Blob container is the source of truth. If the customer’s ALICE subscription ends, the packages remain in their storage, accessible and usable.
Tenant-consistent. The storage configuration applies at tenant level, meaning all users within the same ALICE tenant write packages to the same container. Packaging work by any team member lands in the same location, under the same access policies.
ISO 27001 requires that information assets are identified, classified, and managed under appropriate controls. Application packages containing proprietary configuration, deployment logic, and licensing artefacts are information assets. Customer-owned Azure Blob storage means these assets are managed under the customer’s own classification and access control framework, not the vendor’s.
For packages that include configuration relevant to the processing of personal data (for example, packaging of data handling software or HR applications), the security of the assets under which that configuration is stored falls within GDPR scope. Customer-controlled storage means the Article 32 security obligations are met within the customer’s own data processing infrastructure.
Organisations operating within the UK defence supply chain and subject to requirements from the Ministry of Defence or aligned frameworks face specific obligations regarding the location and control of sensitive configuration data. Application packages for defence estate software are not categorically outside this scope. Customer-owned storage is the appropriate baseline.
Cyber Essentials requires that organisations maintain an accurate inventory of their assets, including software and configuration. Application packages stored in customer-owned Azure Blob are assets under the customer’s direct inventory and control, not assets held on their behalf by a third party.
One of the practical consequences of customer-owned storage is that audit evidence for application package provenance does not require contacting ALICE’s support team, raising a data access request, or waiting for a vendor response.
Every package in the customer’s Azure Blob container has a timestamp, a version reference, and the configuration applied at time of creation. The audit trail for what was packaged, when, and with what configuration is in the customer’s own infrastructure available on demand, under their own access controls.
For organisations that have experienced the friction of requesting audit evidence from a vendor in the middle of a compliance audit, the difference is significant.
Customer-owned storage means that the decision to change platforms, renegotiate terms, or manage a service interruption does not leave the organisation’s application assets in an uncertain state.
The packages ALICE creates are standard .intunewin files compatible with Intune’s Win32 LOB app upload process, and PSADT packages using the published PSADT v4 framework. They are not proprietary formats. They are deployable directly through Intune without ALICE, by any competent IT operations team.
This is the correct baseline for any platform that creates assets on behalf of regulated enterprise customers.
If your organisation operates in a regulated sector and you want to understand how ALICE’s architecture addresses your sovereignty, audit, and compliance requirements, book a demo.
We will walk through the BYO storage model, the package audit trail, and how ALICE’s multi-tenant architecture supports organisational separation requirements.
ALICE is Camwood‘s platform for Autonomous Application Lifecycle Management. Your application packages are your assets. ALICE keeps them that way.
Back to Blog Start your free 14-day trial In Intune, a deployment is an assignment. Whether that assignment results in……
Back to Blog Start your free 14-day trial Your OS patching is automated. Your application patching is not. That is……
Back to Blog Start your free 14-day trial Most business cases for IT investment fail before they reach the board…….
