Skip to content

Vendor Security Policy

Owner Joshua Curci - CTO
Applies to All third-party vendors, service providers, and contractors with access to Trove systems or data
Last reviewed April 2026
Review cycle Annually, or when a significant change occurs

Purpose

This policy defines how Trove evaluates, approves, and manages third-party vendors and service providers. It ensures that vendors who handle Trove data, access Trove systems, or form part of Trove's operational infrastructure meet an acceptable security standard and that relationships are managed responsibly throughout their lifecycle.


Scope

This policy applies to any third party that:

  • Has access to Trove's systems, infrastructure, or internal tools
  • Processes, stores, or transmits Trove platform data or customer data on behalf of Trove
  • Provides development, engineering, or technical services to Trove
  • Provides operational tooling used by the Trove team

Vendor Categories

Vendors are grouped by criticality and the nature of their access:

Critical vendors — Infrastructure and services that the Trove platform cannot operate without, or that process sensitive customer data directly.

Standard vendors — Tools and integrations used in day-to-day operations that have access to internal data or systems but are not core to platform availability.

Development partners — Third-party engineering teams or contractors with direct access to the Trove codebase, repositories, or infrastructure.


Approved Vendor Register

The following vendors are currently approved and in active use:

Critical Vendors

Vendor Purpose Data Processed
AWS Cloud infrastructure — S3 (file storage), SQS (message queuing), KMS (key management) Platform data, customer files, encrypted credentials
DuploCloud Infrastructure orchestration and environment management Infrastructure configuration, environment secrets
Auth0 Identity and authentication User credentials, authentication tokens
Stripe Payment processing and vendor payouts Payment data (PCI DSS scoped), payout details

Standard Vendors

Vendor Purpose Data Processed
Shopify Ecommerce integration (OAuth + webhooks) Product data, order webhooks
Xero Invoicing and accounting integration Invoice data, financial records
Sentry Error tracking and performance monitoring Error logs, stack traces, request metadata
Microsoft Clarity Session recording and analytics Anonymised session data, user behaviour
Slack Internal team communication and operational notifications Internal messages, operational alerts
Google Workspace Email, documents, and collaboration Internal communications, documents
GitHub Source control and CI/CD Source code, deployment pipelines
Figma Design and UI tooling Design assets
ClickUp Project management and task tracking Internal tasks, project data

Development Partners

Vendor Purpose Access Level
Arcanys Third-party development team Source code repository, development environment

Vendor Assessment

Before a new vendor is approved, the following factors are considered:

  • Security posture — Does the vendor have publicly documented security practices? Do they hold relevant certifications (SOC 2, ISO 27001, PCI DSS, etc.)?
  • Necessity — Is this vendor required for a genuine operational or technical need?
  • Data handling — What data will the vendor access or process? Is that appropriate given their security posture?
  • Cost and sustainability — Is the vendor commercially viable and likely to remain operational?

Currently this assessment is conducted informally by the CTO. As Trove progresses toward SOC 2 and ISO 27001 certification, a more structured vendor assessment process with documented outcomes will be implemented.


Contractual Requirements

Development Partners

Development partners and contractors with access to the Trove codebase or internal systems must sign a non-disclosure agreement (NDA) before being granted access. Arcanys has a signed NDA in place.

Data Processing Agreements

Vendors that process personal data on behalf of Trove (as a data processor) should have a Data Processing Agreement (DPA) in place in accordance with the Australian Privacy Act and GDPR requirements. Establishing DPAs with critical data-processing vendors is part of Trove's compliance roadmap.

Note

This is a known gap in the current compliance posture and will be addressed as part of the ISO 27001 and GDPR certification workstreams. See Compliance Overview for the roadmap.


Access Control for Vendors

Vendors and contractors are granted the minimum level of access required to fulfil their function.

  • Third-party development teams are provisioned with access to specific repositories and environments only - they do not have unrestricted access to production systems
  • API credentials and integration keys issued to vendors are scoped to the permissions required for the integration
  • Vendor access is reviewed when the scope of their engagement changes
  • Vendor accounts are not shared with multiple individuals - access is provisioned per person where the vendor provides user-level accounts

Ongoing Monitoring

Vendor relationships are reviewed when a significant change occurs, including:

  • The vendor experiences a known security incident or data breach
  • The vendor's ownership, product, or pricing changes materially
  • Trove's use of the vendor changes in scope or sensitivity
  • The integration is deprecated or no longer required

An annual review of all active vendors will be incorporated into the Annual Compliance Audit as Trove's compliance programme matures.


Vendor Offboarding

When a vendor relationship ends or access is no longer required:

  1. All user accounts associated with the vendor are deleted or deactivated
  2. API keys, OAuth tokens, and integration credentials are revoked
  3. Payment information stored with the vendor is removed
  4. Any vendor-held data that Trove is entitled to retrieve or delete is requested in accordance with the vendor's data deletion process
  5. The vendor is removed from the approved vendor register

The CTO is responsible for ensuring offboarding is completed promptly when a vendor relationship ends.


Security Incidents Involving Vendors

If a vendor notifies Trove of a security incident that may affect Trove data or systems, or if Trove becomes aware of a vendor breach through other means:

  1. The CTO must be notified immediately
  2. The impact on Trove data and systems must be assessed
  3. If personal data may have been affected, the Breach Response Plan must be activated
  4. Affected credentials or access tokens must be rotated as a precautionary measure
  5. Continued use of the vendor must be reviewed in light of the incident