Contract Compliance Trust But Verify Part I: Compliance Data


Today’s post is from Eric Strovink, the spend slayer of spendata. real savings. real simple. Eric was previously CEO of BIQ; before that, he led the implementation of Zeborg’s ExpenseMap, which was acquired by Emptoris and became its spend analysis solution.

If you have a contract with a vendor, that’s good news — you’re not paying list prices any more. At least, that’s what should be happening.

It’s fascinating what can really happen. We’ve recently seen a vendor raise prices in a distant region while maintaining contract prices in the headquarters region. This and similar disparities aren’t necessarily deliberate — mistakes can be made by anyone. Even items purchased through an e-procurement system can fall off the price-compliance applecart as a result of exception-handling processes. The lesson is that “Trust but Verify” is a necessity, not a nicety. And, since manual inspection of a large volume of items and invoices is impossible, this process must be mechanized.

The good news is that many goods and services can be standardized with a fixed price. These items can easily constitute 25-30% of spending. For these goods and services, contract compliance is (at least conceptually) straightforward. Examples include physical items, such as computers, office supplies, phones, furniture, MRO parts, facilities supplies, vending items, security equipment, mobile phone plans, stationery and forms, promotional items — even some types of software. Services examples can include cleaning, appraisals, training classes, recruiting, records management, armored car, overnight mail, hotel, and car rentals (when they are for a fixed unit of time or work).

If contract compliance for these goods and services is straightforward, why doesn’t everyone do it? As usual, the devil is in the details.

  1. Who builds the (usually spreadsheet) compliance model?
  2. Does the model show who is buying off-contract items from the vendor? Which items? When?
  3. Who loads next month’s data into the model, and adapts it accordingly? What’s the cost of this, versus the payback?

For these questions, invoice data, aka Price X Quantity (PxQ) data, is required.¹

Acquiring Data

PxQ data is best acquired directly from the vendor. It’s your data; you have a right to it; and you’ve a right to ask for it. Many vendors will supply it in a reasonable format, such as in an Excel spreadsheet, or as a CSV or DSV file. Some vendors, though, will attempt to discourage you by providing data in an unreasonable format — for example, by supplying every invoice they’ve sent, in PDF format, as an individual file (don’t laugh; we’ve seen this). You may want to consider whether doing business with that vendor is in your best interest moving forward. Certainly you should write into any future contract that the vendor must provide PxQ data in a reasonable format.

But, you also need contract data — that is, contract price by item. That data is probably already in a reasonable format, for example as an addendum to the contract. At worst, it can be keyed in manually or minimally edited into shape.

So, there are two datasets to consider. The first, consisting of invoice level PxQ data, comes from the vendor and resembles this:

Click to enlarge

The contract pricing, which you should already have, resembles this:

Click to enlarge

Once you have the data in this form, you can easily figure out whether the contract is leaky or solid. We’ll continue this discussion in Part II, Monitoring the vendor.

Thanks, Eric!

¹Accounts Payable-based spend analysis can help to determine what spend is definitely not under contract. But it is helpless to address contract compliance issues.

GDPR 8 – Security

Today’s guest post is from Tony Bridger, an experienced provider of Procurement Consulting and Spend Analysis services across the Commonwealth (as well as a Lean Six Sigma Black Belt) who has been delivering value across continents for two decades. He is currently President of UK-based TrainingWorx Ltd, a provider of a wide range of Procurement and Analytic business training programs (inc. GDPR, spend analysis, project management, process improvement, etc.) and focussed short-term consulting solutions. Tony can be contacted at tony.bridger@data-trainingworx.co.uk.

One of the key changes in the GDPR is around the clauses and legal framework that surrounds the processing of personal data.

We will cover this in some detail in the next post (although we did hint at this one!). However, please bear with us as we also have to address cyber security to complete the background for displaying the processing requirements. Security will be a key component of the overall legal framework.

One of the key requirements in processing data is the cyber security that surrounds managing this type of information. The UK Supervisory Authority, the ICO (Information Commissioners Office) issues a wide ranging, practical advice for companies on their website. Given that many procurement analytics providers are now mature IT companies, many will have little to do cyber security wise. Many companies (including high volume email suppliers) have certified to the EU-U.S. Privacy Shield Framework and the Swiss-U.S Privacy Shield Framework. This is an excellent start as we have mentioned previously. The cost of doing this is comparatively small – and we understand that many small US companies have managed to achieve this – around 3000 software enterprises.

On a broader security level, the ICO recommends that companies implement at least the ten steps to Cyber Security model. This can be found on their website. For much smaller UK based data companies, they can achieve Cyber Security Essentials plus certification. This is around $400 USD.

However, it is highly likely that many web analytics provider security arrangements are already in place and exceed the basics. Logically, it may be worth pursuing ISO 27001 accreditation or higher. Like most certification, it can become an expensive and a time-consuming exercise. Many large suppliers may already have CCMv3 (Cloud Controls Matrix), NIST CSF (National Institute of Standards and Technology Cyber Security Framework) or PAS 555.

Is it really worth it? If we had a crystal ball, companies both within and outside of the European arena will come under increasing pressure to prove these controls are in place – and standards are likely to become a key selling point for winning European business. To that end – it is going to be part of the cost of doing business. The alternative is a breach and investigation. Cyber criminals have all the key attack elements in their favour – a confirmed breach could become a costly and damaging PR disaster.

Once vendors combine cyber controls and certification with the extensive legal requirements, it is likely to become a major differentiation point between suppliers. Question is … are vendors ready?

GDPR: What is Required of Processors / Controllers? (Part VII)

Today’s guest post is from Tony Bridger, an experienced provider of Procurement Consulting and Spend Analysis services across the Commonwealth (as well as a Lean Six Sigma Black Belt) who has been delivering value across continents for two decades. He is currently President of UK-based TrainingWorx Ltd, a provider of a wide range of Procurement and Analytic business training programs (inc. GDPR, spend analysis, project management, process improvement, etc.) and focussed short-term consulting solutions. Tony can be contacted at tony.bridger@data-trainingworx.co.uk.

In our last article we noted that a key concept under GDPR (with respect to any data that potentially contains data that could identify an individual person) is the difference between a controller and processor, and what requirements are placed on each. Generally speaking, a spend analytics (service) provider will be a processor and may meet the requirements of a controller (and may not). [It all depends upon whether the customer provides them an ability to determine the purpose and/or means of data processing. In most cases, the provider will have some leeway and will be a controller as well.]

So, what does the regulation require of a processor/controller?

The first fundamental change is around where either the controller or the processor is not established within the Union.

In this case, suppliers will need to designate in writing a representative within the European Union.

“The representative shall be mandated to be addressed by supervisory authorities and data subjects for the purposes of the Regulation. Designation of a representative does not absolve controller or processor from legal liabilities”.

Simply, it means if you are outside of the EU, and you process any personal data that originates from within the EU area, you must have a representative within Europe.

This creates a range of issues as it may well imply that any provider that services data from multiple countries may require multiple representatives. It is likely that multiple representatives may be required as each supervisory authority within each European Country may require a representative.

However, given the volume of suppliers that are involved in managing and processing personal data outside of the European Union for EU clients, how well Supervisory Authorities can manage and track these volumes of suppliers is questionable. However, the fundamental shift in the regulation is that legally, suppliers must now declare that presence. If there are data breach problems later, and an investigation is required, it may well generate a much wide range of breach elements. Like unpicking the thread on a sweater, the Supervisory Authority has wide ranging investigative powers.

For those that opt to process or control personal data from the European-Union, the new Regulations contain a suite of additional procedural requirements. We will start to cover these elements in the next article. However, if you are unsure around the legal elements, as we have said on several occasions, we suggest you consult a Legal firm who specialises in the Regulations.

Thanks, Tony.

GDPR: Are you a Controller or a Processor (Part VI)

Today’s guest post is from Tony Bridger, an experienced provider of Procurement Consulting and Spend Analysis services across the Commonwealth (as well as a Lean Six Sigma Black Belt) who has been delivering value across continents for two decades. He is currently President of UK-based TrainingWorx Ltd, a provider of a wide range of Procurement and Analytic business training programs (inc. GDPR, spend analysis, project management, process improvement, etc.) and focussed short-term consulting solutions. Tony can be contacted at tony.bridger@data-trainingworx.co.uk.

It was Glen Hoddle (English Soccer player) that wrote:

“I have a number of alternatives, and each one gives me something different”.

For many spend analysis providers (or other procurement tools providers) and their clients that manage personal data, the alternative may be simply to change nothing technically – and keep going with the status quo. In effect, implement the requirements of the GDPR regulations.

Like most alternatives there are trade-offs. If eliminating personal data is practicable – then that may be the first viable alternative for suppliers. However, leaving the process as-is and implementing the EU required controls may be the better option longer term.

However, there are several key changes required by 25th May. To be GDPR compliant requires those controls to be in place prior to that date.

The key concept in this article is ensuring that analytics suppliers understand the difference between a controller and processor. For commercial data that contains no personal data, this concept is inapplicable and no further action is required.

Under GDPR, the controller means:

“ … the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data.”

In most cases, the controller will simply be the client.

After all, they will supply the data and direct what they want to happen with those transactions.

The processor is defined as:

“ … a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller.”

To all intents and purposes, most spend analytics providers within (and external) to the EU may be either a controller or provider (or both).

For companies that use serviced systems outside of the EU, providers are therefore processors. Being outside of the EU creates a number of key criteria that need to be met for compliance.

There is also a very clear definition in the Regulation about what constitutes processing:

“ … It means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction.”

Therefore, by default, any serviced analytics provider generically meets the definition.

So, what does this mean? Come back tomorrow for out next installment!

Thanks, Tony.