TPRM Series: Good practice preparation for Third-Party Risk Management

The way any organisation does what it does is as unique as a human fingerprint. This is true even when it does exactly the same things as many other organisations working in the same field under the same operating conditions. Maybe even using the same third-parties.

Certainly, some things will be done virtually if not actually identically here and there, but never everything.

That’s because different people with different experiences and different ways of thinking are involved in each organisation. Different technologies are used, different levels of resources are available, different attitudes to and levels of risk management maturity exist, different regulations can be applicable.

The risks an organisation faces from its third-parties individually and in total will also be different.

The point is that context is everything. The sum of all those differences delivers the unique context in which third-party risk management (TPRM) needs to operate for each organisation that does it.

Context drives the practices an organisation needs to let it manage its third-party risk in a way that suits it, its third-parties, and any applicable regulators.

This article discusses some useful good practices involved in establishing that context. It highlights the myriad micro-level settings of needs and options that must be figured out upfront when planning to implement third-party risk management in an organisation.

A sample of these preparatory activities, in alphabetic order for ease of location, includes:

• Aligning, interfacing and integrating TPRM with Contract Lifecycle Management
• Cataloguing all applicable third-party-related regulatory regimes
• Cataloguing the organisation’s data exposure opportunities
• Cataloguing the organisation’s use of third-party software
• Choosing your battles
• Comprehending the organisation’s risk boundaries
• Establishing a set of generic TPRM-related contract clauses
• Identifying the organisation’s TPRM stakeholders
• Managing third-party risk issues
• Measuring the organisation’s TPRM performance
• Preparing a third-party risk rating methodology and a risk assessment approach
• Setting up TPRM categorisation schemes
• Sizing the TPRM problem
• Some other matters to consider.

Aligning, interfacing and integrating TPRM with Contract Lifecycle Management (CLM)

Implementing TPRM or vendor risk management is the process of establishing a new team or business function in an organisation. That will likely involve transferring certain risk management activities from CLM, sharing responsibility for other activities, and taking on new activities that haven’t been done to date.

At a high level, this might entail a structured process to cover at least the following:

• Identify all risk-related activities currently performed by CLM that should remain with CLM, be taken over by TPRM or be performed jointly by TPRM and CLM
• Identify all risk-related activities not currently being performed at all that should be taken on by either TPRM or CLM, or performed jointly by TPRM and CLM
• Set priorities for transfer or development of such activities
• Configure relevant software solutions to support all the risk-related activities identified.
• Assign boundaries and responsibilities within and around all third-party-risk-related activities for avoidance of doubt about who does what, when and under what circumstances, and methods for handling differences of opinion and establishing risk ownership
• Establish methods for allowing TPRM and CLM to work together when necessary. Examples might be to develop approaches for new risks, modify approaches for known risks, coordinate changes required to third-party contracts to help achieve improved risk management and so on
• Design the workflows needed to allow effective, more mature TPRM
• Document everything needed for training purposes when managing vendors and compliance risk

Detailed planning will be required to manage this process, to include at least:

• A timetable for completing all the elements of the work
• A list of all key stakeholders who should be involved
• The documentation requirements
• A summary of all other resources likely to be needed.

Cataloguing all applicable third-party-related regulatory regimes

Increasingly, regulations are making organisations responsible for the missteps and misdeeds of the third-party vendors they have relationships with.

The penalties for non-compliance with all sorts of regulations can be eye-watering, and as ever, ignorance of the law is never taken as a valid reason for failing to obey it.

What this means then is that a very deep and very current understanding of all the regulations applicable to the organisation must be established. With that in hand, approaches can be developed for achieving the required compliance, measuring the level of compliance achieved, and proving it to the regulators.

There are many ways for the organisation to do this, from completely in-house to completely outsourced, with varying mixes of the two approaches available.

Any understanding of the compliance landscape itself relies on a thorough familiarity with the organisation’s complete inventory of third-parties, not just those identified as needing risk management, because that situation could change daily.

New regulations are being released all the time, and changes can be made from time-to-time to existing regulations. A close watch on all such activity is required to determine relevance and applicability to the organisation. If necessary, changes required by the organisation for ongoing compliance can be developed and implemented in accordance with any timetable set by the regulators.

Cataloguing the organisation’s data exposure opportunities

Every organisation creates and consumes an enormous amount of data about everything to do with what it does. That data ranges in sensitivity from the highly secret to the totally mundane, and is both vital and valuable to the organisation.

Increasingly, elements of an organisation’s data are voluntarily provided to specific third-parties for certain business purposes. This can be done by directly transferring the data to third-parties using various types of media, or by granting them some level of access to the organisation’s IT systems containing the relevant data.

Records should be maintained in some form by the organisation to capture details of all the different data made available to third-parties:

• The name of the data
• The exact nature of the data
• The sensitivity level of the data
• The source of the data in the organisation
• Details of the third-parties receiving or accessing each type of data:
• The identity of the third-party
• Why the data is made available
• How the data is made available
• How often the data is made available
• How the data is used
• How and where the data is stored
• How the data is protected
• Where the data is forwarded on to
• How the data is forwarded on
• If, how and when the data is disposed of
• Anything else relevant.

These details are crucial for assessing the risks associated with the provision of organisational data to each third-party involved. Much of that information has to be obtained from the involved third-parties, and they need to be contractually obliged to do so.

Close monitoring of third-parties granted these access rights is required. Such access has been proven time and again to be misused through exploitation of unaddressed vulnerabilities in software used by the organisation and the third-parties given system access, through social engineering efforts designed to obtain access passwords, and when there are no need-to-know limits on what can be accessed at a third-party’s end.

Cataloguing the organisation’s use of third-party software

All organisations, even those that create some of their own software, rely on a vast range of third-party software to run their operations. That means staggering amounts of an organisation’s data with varying degrees of confidentiality is processed and accessed by such software.

All software has a chance of containing vulnerabilities that can be and all too frequently are exploited to cause harm to the organisations using it, such as:

• Theft, disclosure, corruption or misuse of the data accessible via the software
• Denial of access by the organisation itself to its software and data
• Use of the software as a conduit to other organisations for these purposes and many other nefarious acts.

Every organisation should maintain a register of all the third-party software used anywhere within its operations. Such software can be self-contained, embedded within or forming part of other externally-produced software or that developed by the organisation.

The IT function in the organisation is likely to maintain such a register containing details of most if not all software used, and could be requested to find and fill any gaps.

For TPRM purposes, this register provides a view on the potential scale of cybersecurity risk facing the organisation. It can be used to ensure the appropriate risk assessment and mitigation measures are applied by the third-party providers of each piece of software used, as well as by the organisation itself with respect to the timely application of software updates.

Choosing your battles

Some, maybe many, third-parties that an organisation has or wants to start a relationship with will demand that things are done their way. That’s likely due to them having hundreds of thousands or millions of such relationships in place already.

Third-parties with such scale simply can’t and won’t entertain dealing in a possibly unique way with each relationship, particularly concerning risk assessment and due diligence exercises."

In such cases, dealing with just a handful of similar but different versions of each would be a nightmare, testing the limits of practicality. Having thousands to tens of thousands of variations on a theme just isn’t going to happen, so most organisations have no options other than to accept what they’re given or take their business elsewhere. Size matters here.

Any organisation would prefer to standardise operating processes as much as possible, exactly like those large-scale third-parties are doing, for expediency and efficiency. Things will always happen outside the boundaries of its standardised processes that must be accommodated by the organisation.

Every organisation needs to be prepared for dealing with such third-parties well before it needs to, because it will happen. This commonly is the case when obtaining licences for any piece of software from one of the giants. The main problem in these cases is figuring out how to incorporate the risk-related details such third-parties provide into the records the organisation needs to keep.

Comprehending the organisation’s risk boundaries

Certain boundaries need to be established by every organisation to allow it to:

• Understand its current risk profile
• Determine if any corrective action needs to be taken to either increase or decrease its risk, or reassess and reset its risk boundaries.

Risk capacity is the maximum level of risk in which an organisation can operate. For a financial institution, capacity might be determined by regulatory capital and liquidity needs. For others there can be non-financial dimensions like infrastructure capacity, people available or knowledge recorded.

Risk appetite is the amount of risk an organisation is willing to accept to achieve its strategic objectives, which could be financial, reputational and so on. Any breach of this limit should result in attention to bring it back into line or change the appetite level."

A risk appetite example might be: no acceptance of risk that could result in a significant loss of revenue.

Risk tolerance is the specific maximum amount of exposure by individual risk or risk category that the organisation is willing to bear. Upper and lower tolerance triggers can be set to indicate that attention is required in case a tolerance limit is hit.

A risk tolerance example might be: no acceptance of risk that would cause more than x% revenue drop from the top five customers.

Those parts of an organisation responsible for managing its general risk environment can be expected to be very familiar with these boundary settings. This is a necessity when the organisation determines the measures it needs to take to deal with those risks.

The same expectation will apply to everyone involved in TPRM, for the same reasons.

These risk boundaries might need to be varied in response to changes occurring inside and outside the organisation.

If and when that happens, a pre-developed process should be ready for use to determine the effect of any boundary changes on the ongoing relevance and suitability of existing TPRM approaches. Any necessary updates to those approaches would then be developed and applied, and the details disseminated.

Establishing a set of generic TPRM-related contract clauses

Many of the third-parties that it will establish a relationship with will need to play a part in the organisation’s efforts to manage the risk they pose to it. Some of those efforts will begin even before a relationship is formed, to check that it can be.

Most effort though will be required during the operational life of the relationship, with varying depth and frequency that depends on its perceived level of risk to the organisation."

Some examples of third-party contributions include participating in risk assessment and due diligence exercises, notifying the organisation when a risk occurs that could have consequences for it, or advising the organisation about changes to their use of its data.

A set of boilerplate contract clauses should be prepared to enshrine the nature of fairly common activities that any third-party might typically be required to do.

There might also be a need for extensions for some specific activities that are only required from third-parties posing certain levels of risk. Other clauses may be required to refer to regulations and obligations that must be complied with.

Examples of clauses relevant for TPRM matters include:

• Assignment: the third-party shouldn’t be able to assign its rights, responsibilities and liabilities to another party that might be unknown to the organisation or never risk-assessed by it, without the organisation’s prior written consent
• Compliance: the third-party must be required to comply with all applicable regulations and international acts and standards, all local laws and regulations, and the binding laws of jurisdictions that the organisation is in any way related to. This clause becomes more of an issue when the organisation operates in a regulated area
• Contract disengagement: the organisation and the third-party should agree on a planned sequence of offboarding activities to be triggered by termination of the contract to bring it to a conclusion. It should cover matters like the return or destruction of each side’s confidential information, disabling of any access granted to each other’s IT systems, finalisation of any monies owed, and so on
• Contract variation: the organisation should be able to request a change to the contract with a third-party when necessary. This could be to formalise any new arrangements specifying how the parties will deal with particular scope changes identified as a result of a due diligence exercise, the occurrence of an unexpected third-party risk, or for any other reason
• Data breach: the third-party must be required to promptly notify the organisation about any unauthorised access to, use or disclosure of any of the organisation’s data that it stores irrespective of the method or media used, and to eliminate the causes of any such data breach, as quickly as possible
• Data jurisdiction: the organisation should be able to specify the country where any of its data that is hosted or processed by the third-party will reside at rest and for fallback purposes, and require that it not be relocated from there without the organisation’s express prior written approval
• Data protection: the third-party must be required to take all necessary measures to protect any of the organisation’s data that it has received or been given access to, including in accordance with any and all applicable laws and regulations
• Indemnification and liability: the third-party must be held responsible for the consequences of its negligence or failure to meet its contractual obligations, including penalties designed to dissuade it from breaching the contract, and to set limits around losses sustained
• Insurance coverage: the organisation should be able to consider the adequacy of certain insurance coverage it requires the third-party to obtain initially and annually thereafter. The third-party must be required to maintain its insurance cover accordingly
• Notices: the third-party must be required to provide prompt notice to the organisation about any risks it sustains that it hasn’t been able to deal with effectively, to the point where its services to the organisation might or will be affected in some obvious fashion, or if any other agreed criteria are met
• Right to audit: the organisation should be able to request that the third-party promptly provides detailed information about specific matters that might pose a risk for the organisation or affect the future of the relationship. This might include details about the third-party’s business continuity and disaster recovery approaches, level of compliance with regulatory obligations, lawsuits in effect against it, change of control and so on. Onsite visits by the organisation should also be allowed for such auditing purposes as applicable
• Right to terminate or renew: the organisation must be able to terminate for cause, with or without notice depending on specific circumstances, and with or without a cure period to remedy any condition that has triggered the termination right. Automatic renewal at end of term should be avoided, but the right should be available to renew and renegotiate or to terminate
• Service level agreement: a statement is required about the level of performance the third-party agrees to deliver, how its performance will be measured and reported and how often, and each party’s rights in the event of the third-party’s failure to meet performance expectations
• Subcontracting: the third-party must be required to remain responsible for any of its contractual obligations that are performed by its subcontractors, who must be held to the contracted performance standards.

It’s likely that other generic clauses covering activities the organisation and its third-party might need to do in respect of managing third-party risks will also be required.

Some level of negotiability of the content of these clauses should be expected. To allow for this, the organisation might prepare preferred, alternative and drop-dead versions, or just negotiate agreed positions as required. The more clause consistency can be obtained across third-parties, the better.

Identifying the organisation’s TPRM stakeholders

Many areas of an organisation will have a vested interest in the intended outcomes of TPRM, and a contribution to make to their achievement. These stakeholders are likely to have different reasons for their interest.

Some of these reasons will be related to how a third-party risk could affect them if it gets out of hand, others will concern what they might have to do to prevent, contain or recover from it.

In most cases, there will be worries about the costs in terms of time and resources needed to deal with third-party risks if they’re not handled properly once TPRM goes into full operation.

All such stakeholders need to be identified to allow their:

• TPRM concerns and requirements to be discovered
• Recent past, current and potential issues with any third-parties to be logged
• Proposed role in any preparatory TPRM-related activities to be decided
• Ongoing role in any TPRM-related activities, as representatives of their business function or as individuals, to be agreed.

Managing third-party risk issues

At some point, it’s likely that any one of its third-parties will encounter a risk-related issue and let the organisation know. Alternatively, the organisation can find this out the hard way.

The purpose of third-party issue management is to understand the reported problem and its causes, determine how it can be resolved, work to eliminate or at least minimise the effects, and prevent escalation into undesirable territory."

Almost inevitably, some type of risk at some time is bound to break, sneak or blithely wander through the defences of one of an organisation’s third-parties, or otherwise pose some kind of threat to it.

The organisation needs to know when such issues arise, as soon as they do. Unaddressed issues can quickly turn into incidents, and that could lead to all sorts of consequences.

To deal with the possibility, a process for managing third-party risk issues is needed to, at a minimum:

• Ensure that an organisation’s third-parties promptly and officially notify it about the occurrence of any risks they have not successfully dealt with
• Allow the organisation to review the situation and determine if it has any approaches in place to deal with it
• Provide an escalation path within the organisation to report on the situation, obtain approval for any proposed mitigation approaches, or receive advice about what actions should be taken
• Maintain a register of all such issues to detect trends, determine if any standard issue management approaches should be added, modified or retired, and provide reports about the arrival rate of issues, lessons learned and so on.
• Centralised oversight of this process is necessary, because an inappropriate or unsanctioned option for dealing with the situation could be made at a localised level in the organisation. That might lead to runaway risk or violation of established risk boundaries due to a lack of awareness or misunderstanding of the bigger picture consequences.
• Details of this approach should be rolled out widely across the organisation, to everybody having some type of operational or management interactions with its third-parties.

Measuring the organisation’s TPRM performance

Anything worth doing, like TPRM, warrants measurement to check if the effort is delivering the desired returns. Benchmarks for success are required for determining if that is the case or not.

Measurement drives focus by providing early warning signs. Focus determines if the warning signs are valid and should be heeded, or indicate that established limits and triggers are no longer completely fit for purpose or fit for use."

Measurability depends on the availability or derivability of the information needed to allow reporting about TPRM performance.

There is always a tension in measurement concerning what should or must be measured to provide meaning, and what can be reasonably achieved. Getting this as close to right as possible from the beginning is the aim.

Bear in mind that different audiences often need to see different details reported. It’s important to determine just who those audiences are and where their interests lie to ensure trust in the focus of TPRM."

Some of the measures to be reported monthly for TPRM that might be considered useful for raising organisational awareness about third-party risk or are a regulatory requirement include:

• General inventory-type reporting about numbers of third-parties, third-party risk types, risk assessment types and so on, showing changes from the previous reporting month, with selectable details and filterable by whatever attributes have been recorded
• A calendar of important upcoming TPRM-related activities for anyone who might need to be involved in some way with those activities
• Risk management performance stats, such as proportion of third-parties being actively risk-managed, numbers of assessments scheduled vs delayed / in progress / completed, risk assessment outcomes, third-party risks that have occurred but remain unmitigated or have impacted the organisation on occurrence and so on, filterable by whatever attributes have been recorded
• Important events or issues detected that might need follow-up, such as planned or emerging changes in applicable regulatory environments or geopolitical risks, adjustments to the organisation’s risk policies or boundaries, concerns arising with critical third-parties and so on
• Trend information can also prove very useful as proof of performance improvements or failures.

Note that there may be some demand for quarterly and yearly reporting to give rolled-up views of the TPRM program, so the capability needs to be available.

Gatekeeper is a solution designed to help businesses to manage their third-party risks by providing repeatability in process, particularly during onboarding, and then with ongoing monitoring, reminders and alerts for key activities or changes in circumstances.

Preparing a third-party risk rating methodology and a risk assessment approach

An organisation’s existing general risk rating methodology covering likelihood, impact, overall rating and attention priority level should probably be suitable for rating third-party risks as well.

If not, whatever adjustments are needed to accommodate the extra risks without disturbing the methodology for currently handled risks must be considered and applied.

When it comes to developing a third-party risk assessment approach there are three main sources available for providing guidance:

• Templates for risk assessment questionnaires are available in some TPRM frameworks but others can be obtained from TPRM consultants, advisors and system providers
• If an organisation itself is a third-party to other organisations, and has been required to complete risk assessments in the course of those relationships, it will have insights into the good and bad of such assessments to help with development of its own approaches
• Some third-parties an organisation deals with may undergo regular risk assessments from other organisations they deal with. That experience may have allowed those third-parties to rationalise the different risk assessments down to the fundamental elements that are relevant for them, and that they now prefer to use with all the organisations they deal with. Obtaining such assessments from those third-parties can also prove useful to organisations beginning their TPRM journey.

Setting up TPRM categorisation schemes

A categorisation scheme is used for grouping things based on the value of some attribute they have. Those attributes can be based on something inherent to the thing, assigned to it, calculated about it or whatever.

Grouping reveals volume via search for specified values of specified attributes of the thing of interest, allowing concentration on just the things found matching the search criteria.

Categorisations are an important aspect of TPRM, allowing segregation of different items that need different levels of attention.

There are many different attributes, their settings and rules for determining those settings that can be associated with key elements of TPRM and need to make sense to the organisation, such as:

Third-party attributes

• Type, eg supplier, partner
• Risk assessment target type, eg financial services, pharma
• Risk assessment scope eg simple, complex, N/A
• Date of last risk assessment
• Risk assessment outcome, eg in progress, unsatisfactory, satisfactory
• Importance, eg critical, important, everyday
• Reasons for importance, eg sole supplier, preferred supplier, spend level
• General risk rating, eg low, medium, high, extreme
• Date of general risk rating
• Risk management needed, eg yes, no
• Risk assessment frequency, eg monthly, quarterly, biannually, annually, N/A
• Receives sensitive organisational data, eg yes, no
• Accesses the organisation’s systems, eg yes, no
• Provides software, eg yes, no
• Relationship owner, eg business function, role

Third-party risk attributes

• Type, eg supply disruption, modern slavery, cybersecurity
• Effect, eg operational, regulatory non-compliance, data breach
• Treatment, eg avoid, mitigate, tolerate, transfer
• Likelihood, eg low, medium, high
• Potential impact on organisation, eg low, medium, high, extreme
• Priority, eg low, medium, high
• Risk owner, eg Finance, GRC

Third-party risk occurrence attributes

• Date of occurrence
• Impact on third-party, eg low, medium, high, extreme
• Impact on organisation, eg low, medium, high, extreme
• Activity status, eg active, inactive

Risk assessment attributes

• Target, eg financial services, pharma
• Basis, eg ISO27001, SIG Core

Here again, Gatekeeper is the ideal solution for monitoring all the above data-points, with the ability to mandate their capture and create automated rules around their maintenance and trigger actions where any unexpected changes might occur. Integrated third party risk management is available in the form of risk intelligence feeds and escalation actions. 

Sizing the TPRM problem

An organisation can have arrangements with tens to tens of thousands of third-parties. The degree of risk management attention each warrants will range from nil to continuous. Determining that requires a deep understanding of each third party’s potential risk to the organisation.

The minimum requirement for sizing the TPRM problem then is to:

• Prepare an inventory of all active third-parties
• Prepare an inventory of all the potential risks to the organisation those third-parties present
• Create a linkage associating active third-parties with their potential risks
• Assign a risk-management level to each third-party based on the cumulative level of risk accruing from its associated potential risks.

Analysis of this information will reveal the number of third-party relationships in each level of risk management need. That will allow estimation of resources needed to conduct the relevant risk management activities.

These details will inform risk management approaches, and indicate the nature of any TPRM tools and systems that might be useful immediately or in the near future to handle existing and envisaged workloads.

The criteria used to determine if a third-party needs risk management should be guided by the organisation’s internal risk boundaries and the external expertise wrapped up in the various TPRM frameworks, whether adopted or not. Where it’s line-ball, it’s better to be safe than sorry by applying risk management until it’s clear that it isn’t needed.

Some other matters to consider

An organisation has a lot of ground to cover to decide what it must, should and might do or not do to manage the risks it is exposed to from its third-party relationships. Some other activities not covered in this article that might prove useful in that effort include:

• Consider the need to risk-assess any levels of the organisation’s third-parties’ own supply chains, the so-called 4th to nth parties
• Scope requirements for a suitable software solution to help manage TPRM
• Identify and investigate options and costs for self-operating an internal IT system for TPRM or outsourcing all or part of any TPRM solution
• Consider how to achieve the continuous risk-monitoring of key third-parties and the development of tailored rather than generic risk-assessment questionnaires
• Identify ownership of and resourcing requirements for TPRM activities
• Develop a watchlist of key third-party risks likely to be most impactful on the organisation should a third-party’s approach to dealing with such risks fail
• Prepare a generic incident response playbook for dealing with the failure of a third-party’s mitigation approach to a key third-party risk
• Develop a strategy for dealing with the effects of changes to the organisation’s risk boundaries on any TPRM approaches being used
• Identify areas where the speed, visibility and efficiency of automation are critical for successful TPRM
• Align due diligence risk assessment questionnaires with a third-party’s industry and risk profile
• Create a roadmap for maturing TPRM in the organisation
• Determine the nature of third-party-related reporting required by the organisation and any applicable regulators to show what needs to be dealt with, provide proof of how it’s going, and ensure it can be produced as easily as possible.

With these matters covered in addition to the others presented earlier, the organisation can start work on how to do TPRM, how much of that to do itself, and how much it might outsource.

Irrespective of the work-breakdown decision and how much external help is eventually obtained, the organisation will still have a lot to do to ensure it gets on top of its TPRM situation and, critically, stays there.

Wrap-up

Like a lot of risk these days, the cost of a single far-reaching third-party risk event that affects an organisation can massively exceed the cost of being well prepared to deal with it.

If that’s not incentive enough to manage its third-party risk properly, thoroughly and professionally, there’s also the actions of any applicable regulators to consider.

They will readily penalise the organisation for not only its own failure to deal effectively with that risk but also the failure of the relevant third-parties to manage it in the first place.

This guilt-by-association, rubbing-salt-in-the-wounds approach by the regulators is growing in popularity and expanding in coverage, so be warned.

Solid preparation for doing any job is critical. Understanding the overall problem to be dealt with allows development of an appropriate solution. It can help ensure that nothing important gets overlooked, that the solution will be achievable and effective, and that no downstream problems will be introduced as a result.

Clearly, managing third-party risk is complicated. There are a lot of moving parts to wrangle in doing it, and they all need to be considered upfront to provide the best chance that they’ll all mesh together nicely in operation. Building-in is preferable to bolting-on."

Adoption of the preparatory good practices discussed above can help an organisation get well set up for implementing TPRM by having ‘all the right junk in all the right places’, as Haley Reinhart once sang.

Establishing those foundations goes a long way to doing all the right things in TPRM and doing them right.

Whether or not it’s a mandatory regulatory requirement, TPRM is one of those activities that just should be done by an organisation. Doing it properly is the only option when there’s so much at risk, and as ever, you only get out of it what you put into it.

Over 50 years ago, a Bell Helmets advertising campaign targeted at motorcyclists exclaimed “If you’ve got a $10 head, wear a $10 helmet!”. Good advice back then, still good advice today, and worth bearing in mind at the beginning of the road trip that is TPRM.

If you would like more information about how to prepare for implementing a TPRM program, or how Gatekeeper can assist with that activity, then contact us today.