Assenture

Third Party Risk Management Policy

Last updated: August 8, 2026

This policy defines how Assenture selects, assesses, contracts with, monitors and offboards third parties that process customer data, support production infrastructure, or otherwise affect the security and availability of the Service. It is enforced through both administrative controls (approval, contracts, review) and technical controls (scoped credentials, network and permission restrictions, logging). It is read together with our Subprocessors list, Data Processing Addendum and Access Controls Policy.

1. Scope

Applies to all cloud and SaaS providers, infrastructure and database platforms, AI model providers, payment processors, financial data aggregators, communications providers, analytics and monitoring tooling, contractors and any code dependency granted access to production data or credentials.

2. Vendor tiering

  • Tier 1 Critical. Processes customer personal data or consumer financial data, or holds production credentials or availability dependency. Examples: infrastructure and database platform, financial data aggregator, payment processor. Full due diligence, executed DPA, annual reassessment.
  • Tier 2 Important. Limited or transient access to data, or material operational reliance. Full due diligence at onboarding, reassessment every 2 years.
  • Tier 3 Low. No access to customer data and no production reach. Lightweight review and approval only.

3. Due diligence before onboarding

No Tier 1 or Tier 2 vendor may be used in production until the following are complete:

  • Documented business justification and named internal owner.
  • Security review: independent attestations where available (SOC 2 Type II, ISO 27001), encryption in transit and at rest, authentication and MFA support, tenant isolation, sub-processor chain, breach notification commitments and incident history.
  • Privacy review: data categories processed, lawful basis, processing locations, international transfer mechanism (Standard Contractual Clauses where applicable), retention and deletion capability.
  • Resilience review: availability track record, published status transparency, backup and recovery posture, and our own fallback if the vendor fails.
  • Approval by engineering leadership. Tier 1 vendors additionally require privacy-lead approval.

4. Contractual controls

  • Every vendor processing personal data on our behalf must execute a data processing agreement with confidentiality obligations, purpose limitation, security requirements, sub-processor controls, audit or assurance rights, breach notification timelines and deletion on termination.
  • International transfers rely on an approved mechanism such as Standard Contractual Clauses with a transfer impact assessment.
  • Tier 1 contracts require prompt breach notification and cooperation with our incident response and regulatory obligations.
  • Vendors are contractually prohibited from using customer data to train their own models unless the customer has explicitly opted in. AI providers are engaged on zero-retention or no-training terms wherever the option exists.

5. Technical enforcement

  • Least privilege. Each integration receives its own scoped, revocable credential. Credentials are never shared between vendors or environments.
  • Secret isolation. Vendor credentials are held in an encrypted secret store, injected at runtime, never present in client bundles or source control, and rotated on schedule and on suspected compromise.
  • Data minimisation. Only the fields required for the function are transmitted. Sensitive identifiers are withheld or tokenised where the vendor does not need them.
  • Boundary controls. Outbound integrations are restricted to known endpoints, server-side request forgery protections are applied to any URL-fetching capability, and inbound webhooks must pass signature or shared-secret verification before any action is taken.
  • Observability. Vendor API calls, failures and anomalous volumes are logged and alerted under our Logging and Monitoring Policy.
  • Dependency control. Code dependencies are pinned by lockfile and continuously scanned for known vulnerabilities and end-of-life status before and after adoption.

6. Ongoing monitoring

  • Tier 1 vendors are reassessed annually; Tier 2 every 2 years. Reassessment refreshes attestations, sub-processor lists and incident history.
  • Vendor security bulletins, status incidents and breach disclosures are monitored; a vendor incident that may affect customer data triggers our own Incident Response Policy.
  • Vendor access credentials are included in our periodic access review cycle and revoked when no longer required.
  • Material changes in a vendor's sub-processors, processing locations or security posture trigger an out-of-cycle review.

7. Customer transparency

Sub-processors that may process customer personal data are published on our Subprocessors page. Customers are given advance notice of new sub-processors and may raise a reasoned objection as set out in the Data Processing Addendum.

8. Offboarding

  • Credentials, API keys and integrations are revoked immediately on termination.
  • Deletion or return of data is requested and confirmed in accordance with the contract and our Data Retention and Disposal Policy.
  • References to the vendor are removed from code, configuration, secret stores and the subprocessor list.

9. Exceptions, ownership and review

Exceptions require documented approval from engineering leadership with a compensating control and an expiry date. This policy is owned by Assenture engineering leadership and is reviewed and approved at least annually. Assurance requests: business@assenture.app.