Gartner reports that 60 percent of organisations hit by a third-party data breach admit they had no real visibility over that provider at the time of the incident. NIS2 and DORA made third-party risk management mandatory for thousands of European entities. Yet most TPRM programmes fail, not for lack of ambition, but for lack of a solid initial map. This article covers the seven most common pitfalls at the start of a third-party mapping exercise, and how to anticipate them before your assessment ends up covering the wrong perimeter.
Why third-party mapping stopped being optional
DORA, in application since January 2025, requires every covered financial entity to document its critical ICT third parties in full, with contractual review aligned to Article 28, a register of third-party incidents, and a risk concentration assessment. NIS2, applicable since October 2024, requires documented digital supply chain management for all essential and important entities. These obligations do not simply layer onto existing practice. They demand an exhaustive inventory, a criticality classification, and recurring assessment.
The problem: many organisations start their TPRM programme under regulatory pressure, without a robust method for the first step, identifying precisely who their third parties are, what they do, and what exposure they carry. Every pitfall below grows from that rush.
The seven pitfalls
1. Confusing "supplier" with "third party at risk"
The first pitfall is starting from the procurement supplier file. The result mixes the cleaning contractor, the critical cloud host and the software development partner into one undifferentiated list. A TPRM map is not a supplier list. It is a list of relationships that expose the organisation to identifiable risk. The question for each entry: if this third party fails, what breaks?
2. Using a binary classification
Critical against non-critical is intuitive and insufficient. It creates an illusion of control: "non-critical" third parties get no monitoring at all, while many of them touch sensitive data or sit inside important processes. Three or four levels, with formal criteria (data volume handled, replaceability, substitution lead time, regulatory exposure) is the minimum for an operational programme.
3. Ignoring your third parties' own subcontractors
DORA explicitly introduces third-party concentration risk and requires visibility into ICT subcontracting chains. A cloud host that subcontracts backups to an unknown provider introduces risk your direct map never sees. The minimum rule: for every critical and important third party, a contractual clause requiring notification of any significant subcontractor change, and access to their own ICT provider list.
4. Opening with a 150-question questionnaire
The most common beginner error. The organisation builds an exhaustive assessment questionnaire, inspired by CSA CAIQ or Shared Assessments SIG, and sends it to every third party from day one. Response rate: often under 40 percent. Time to process the answers: unplanned. The long questionnaire is for deep assessment of critical third parties, not for qualifying an inventory of 200 providers. Start with a short qualification questionnaire, ten to fifteen questions, to identify who needs the full assessment.
5. Leaving the business out of the initial inventory
A map driven only by IT or compliance will always be incomplete. Business functions run their own SaaS tools, their own API integrations, their own outsourced services, often unknown to central IT. The initial inventory needs a collection workshop with each function: ninety minutes, run by the GRC team, with simple questions on tools used, data handled, and access granted to outsiders.
6. Confusing mapping with assessment
Many programmes try to map and assess at once. The result is paralysis: you cannot validate the map until assessment is done, and you cannot assess until the map is stable. Sequence them. Mapping produces a classified inventory. Assessment starts afterwards, on critical third parties first. The two run at different rhythms: the map updates continuously, assessment runs annually or at contract renewal.
7. Not defining the update process on day one
A third-party map goes stale in under six months without a maintenance process defined from the start. Third parties change: acquisitions, scope changes, contract endings, new providers onboarded by the business without GRC sign-off. Design the update process alongside the initial map: who triggers an update, on what event (new third party onboarding, contract renewal, incident, audit), and who owns it. Without it, your map becomes a frozen document that manufactures false assurance.
Assessing your current TPRM maturity
Do you hold an exhaustive third-party inventory with a formal criticality classification? If the answer is "partly" or "no", the priority is mapping, not assessment.
Do your critical third-party contracts include the DORA Article 28 clauses (audit rights, subcontracting, exit, service levels)? If not, any financial entity in scope is non-compliant.
Do you have a formal process to add a new third party to the register before operational onboarding? Without it, your inventory will always lag reality.
Presidio includes a TPRM module built around a classified third-party register, an assessment cycle configurable by criticality level, and full traceability of contractual exchanges. See Presidio →
Conclusion
Third-party mapping is the foundation of any TPRM programme. The seven pitfalls share one root: an understandable rush under regulatory pressure. Taking two extra weeks to define the perimeter, involve the business, and sequence mapping before assessment produces a far more solid programme than six months of work on a bad foundation. With NIS2 and DORA both in force, the question is not whether you need a TPRM programme. It is whether yours rests on reliable ground.