They’ve got 99 million problems and a glitch ain’t one! by Source Code Control

But quite possibly not.

The acquisition came in the middle of a 4-year sustained syphoning of 339m customer records from the Starwood membership system. This was not a simple glitch and two world-class companies didn’t find it.

So, on the 9th July, the Information Commissioner’s Office (ICO) flexed its GDPR muscles with an intention to fine the Hotel £99m, they took the unprecedented step of calling out the issue of poor technical due diligence:

“The GDPR makes it clear that organisations must be accountable for the personal data they hold. This can include carrying out proper due diligence when making a corporate acquisition, and putting in place proper accountability measures to assess not only what personal data has been acquired, but also how it is protected.”

I wouldn’t go so far as to say I feel sympathetic. But I do understand how this happens. I regularly present on the importance of technical due diligence and I genuinely see the fear in people’s eyes as we discuss known security vulnerabilities, the precautions necessary for outsourced development and digital supply chains.

I collect business cards by the dozen and diligently follow-up and then… nothing.

THIS is not a whinge! I honestly get it. Business priorities take precedence – like spending $13bn on a hotel chain. Demands to release are relentless. Feature requests and bug fixes come with irritated users. Who has time to stop and look at what has already shipped?

So, maybe the $99m problem will help to focus the mind. Or, if nothing else maybe the advisors will insist on greater technical due diligence next time around. If not, here are my top 3 tips for technical due diligence:

1. Know what you are buying. Would you buy a house without a survey? (And if you do get a survey.. don’t you use it to assist with negotiations anyway?) Nearly every company has a software component these days and very, very few of them are experienced software companies. Don’t just accept what is written on the disclosure, this is important stuff now. The worst that can happen is that you get validation of your decision to buy! We fully recommend either creating or insisting your suppliers create a Bill of Materials for each piece of custom software.
2. Get a supply chain mentality. This isn’t an outdated 1990’s manufacturing model. Quite simply, the problems you bake into your software are passed down the line to your customers, partners or acquirers! Where are your software components coming from? Are they updated? What are you doing with them? Where do they go next?
3. Have a policy. Boring! Yes, well it may be, but there are good reasons:
   • It provides an approach, a process, something to aim for. Don’t be reliant on someone just saying “well, I was thinking… maybe we should look at the code of that company we are buying”.
   • ICO have clearly stated they will be much more lenient if you have taken (and documented) steps to prevent a problem.

Written by: Paul McAdam – Director, Source Code Control Limited

If you have any questions for Source Code Control then feel free to request a call via the Whitespace Marketplace.

Source Code control provides software assessment services, including mergers and acquisitions. They have provided consulting, Bill of Materials and detailed analysis of software composition for a range of companies from FTSE 100 to SMB.

© 2019 Source Code Control Ltd