View a markdown version of this page

DSREL02-BP01 Implement continuous third-party risk management (TPRM) processes - Digital Sovereignty Lens
Implementation guidanceResources

DSREL02-BP01 Implement continuous third-party risk management (TPRM) processes

In highly regulated industries, a structured third-party risk management (TPRM) process is essential to mitigate risks associated with third-party vendors and service providers. Vendors can introduce sovereignty risks through data processed in non-approved jurisdictions, operators accessing systems from foreign locations, or sub-processors that don't adhere to data residency requirements.

Desired outcome:

  • Third-party vendor risks are identified, assessed, and mitigated throughout the vendor engagement lifecycle, with specific verification that vendors maintain data within approved jurisdictions and meet jurisdiction-specific compliance requirements.

Common anti-patterns:

  • Conducting one-time vendor assessments without continuous monitoring, failing to adapt evaluations to evolving threats and regulations.

  • Relying on manual tracking processes and lacking clear understanding of data flows and vendor dependencies.

  • Using inconsistent security criteria across vendors and over-relying on vendor self-attestations without independent verification.

  • Allowing unapproved technology usage and lacking proper incident response coordination with vendors.

Benefits of establishing this best practice:

  • Continuous monitoring of vendor risk posture with automated alerting and proactive supply chain risk identification.

  • Systematic evidence collection and documentation demonstrating adherence to industry regulations.

  • Streamlined vendor onboarding and offboarding processes while maintaining security standards and cost optimization.

  • Pre-established communication channels and procedures for coordinating security incidents and protecting operations.

  • Enhanced confidence from auditors, regulators, and customers through demonstrated vendor risk management.

Level of risk exposed if this best practice is not established: Medium

Implementation guidance

A continuous TPRM lifecycle process, integrated with existing risk management, procurement, and compliance functions, provides systematic oversight of vendor risks throughout the engagement lifecycle. For sovereign workloads, TPRM extends beyond standard security assessments to verify that vendors maintain data within approved jurisdictions, that operator access originates from approved locations, and that sub-processors don't introduce unmonitored cross-border data flows.

Regulations such as the EU Digital Operational Resilience Act (EU DORA) include specific requirements for Information and Communication Technology (ICT) TPRM. AWS has been designated as a Critical Third-Party Provider (CTPP) by the European Supervisory Authorities (ESAs), meaning AWS is subject to a formal oversight process under DORA. For financial services customers using AWS, this designation means that there is now joint oversight by the European Banking Authority (EBA), the European Securities and Markets Authority (ESMA), and the European Insurance and Occupational Pensions Authority (EIOPA). While AWS recognizes the significance of this oversight, it doesn't change a financial entity's obligation to maintain its own TPRM processes, including contractual safeguards, exit strategies, and ongoing monitoring of its ICT third-party dependencies.

The depth of TPRM implementation scales with organizational complexity. Organizations with fewer vendors might manage assessments through structured questionnaires and periodic reviews, while larger enterprises with extensive vendor ecosystems benefit from automated risk scoring, continuous monitoring integrations, and dedicated TPRM tooling. Regardless of scale, apply the sovereignty-specific criteria (data residency verification, operator location, and cross-border data flows) to every vendor that handles regulated data.

Implementation steps

  1. Establish governance and ownership: Assign clear ownership for third-party risk management. Define roles, responsibilities, escalation paths, and review cadences.

  2. Implement a sovereignty-aware assessment framework: Develop vendor questionnaires, risk assessment templates, compliance checklists, and evidence collection processes. Consider using governance, risk, and compliance (GRC) solutions available in AWS Marketplace for structured TPRM workflows. Common sovereignty-specific assessment criteria include:

    • Data residency and cross-border transfers: Where does the vendor store and process your data? Does data cross jurisdictional boundaries during processing, and do they use sub-processors in other jurisdictions?

    • Operator location: Are the vendor's operational support staff located in approved jurisdictions? What access do they have to your data?

    • Jurisdiction-specific certifications: Does the vendor hold certifications relevant to your jurisdiction (for example, C5 in Germany, SOC 2, and ISO 27001)?

    • Data portability: Does the vendor support data portability? Can you extract your data in standard formats if you need to change providers?

  3. Configure a vendor management database: Track vendor profiles, risk scores, compliance status, contract details, and sovereignty-specific attributes (data residency, operator locations, and certifications). Schedule regular reviews and re-assessments aligned with vendor risk tiers.

  4. Set up automated monitoring for sovereignty drift: Monitor the resources in your own accounts that connect to vendor services, and alert on changes that could route regulated data to a vendor outside approved boundaries.

    • Use AWS Config to detect drift in vendor-facing connectivity: changes to VPC endpoint (PrivateLink) configurations, VPC peering and Transit Gateway attachments, security group egress rules, and Amazon S3 cross-Region replication. Flag resources created outside approved Regions.

    • Use Amazon EventBridge rules on AWS CloudTrail management events (such as CreateVpcEndpoint, CreateVpcPeeringConnection, AuthorizeSecurityGroupEgress, and Route 53 Resolver rule changes) to alert when a new path to a vendor endpoint is created or modified.

    • Enable VPC Flow Logs and Route 53 Resolver query logging to record egress and DNS resolution to vendor endpoints, so you can confirm traffic matches the vendor's documented data-flow paths.

    • Aggregate these findings in AWS Security Hub CSPM and route alerts through Amazon CloudWatch so a reviewer can confirm the change keeps vendor data within approved jurisdictions.

  5. Establish contractual sovereignty safeguards: Contractual controls complement technical controls by establishing obligations around data handling. Verify that vendor contracts address the following sovereignty-specific areas:

    • Data residency clauses: Approved jurisdictions for data storage and processing.

    • Breach notification timelines: Alignment with your regulatory notification requirements.

    • Data portability and exit provisions: Exit procedures, data formats, and associated charges.

    • Sub-processor usage: Sub-processor locations and purpose.

  6. Validate vendor data residency: Verify that vendor data flows remain within approved jurisdictional boundaries. Where a vendor exposes its service through an endpoint service, use AWS PrivateLink to connect privately without traversing the public internet. Review the vendor's documentation on AWS Region usage and data flow architecture, and monitor network traffic to vendor endpoints to verify that data flows match documented paths.

Resources

Related best practices:

Related documents:

Related videos:

Related examples:

  • AWS Marketplace for discovering vendors with AWS security reviews and relevant certifications

Related services: