This ex-government framework provider would have us believe that they manually record the date of when they create an individual’s account in their information management system because they don’t have access to a system generated account creation date.
NYS Corporate arrange events, conferences and corporate travel for organisations including O2 and the NHS. In recent years I’ve received a Christmas card e-mail from NYS Corporate (NYS), sent to my work’s e-mail address. As I had no idea at the time why NYS were sending me Christmas card e-mails, and as there was no unsubscribe link in either e-mail, I did what I do for any UK-based company that sends me unsolicited marketing at work; I replied to each e-mail in turn, about a year apart, and asked NYS to stop sending me marketing. It would seem that both of my requests were ignored however, because in April 2015 I received a further marketing e-mail from NYS that said:
Hi EveryoneHope you enjoyed the Easter breakI just wanted to share with you an update on our event logistics and conference services, a handful of major location openings and event trends for 2015, so please click here for our venue newsletter.Please let me know what you think of this first venue newsletter as our NYS Spring Newsletter is coming soon!Many Thanks
At this point I still didn’t know how this company had obtained my information or why they were processing it to send me e-mails to my place of work so it started to wind me up. It’s just the way that it was worded; ‘Hi Everyone” and “I just wanted to share an update with you”. They’re making it appear like they know me yet I didn’t have a clue why they were contacting me.
I replied again and asked NYS Corporate to tell me how they had obtained my work’s e-mail address. This time NYS responded and informed me that they’d had an ongoing relationship with my employer for ten years and had obtained my information as part of that relationship. If that’s the case then why couldn’t they/can’t they put something in the e-mail to inform me that I’m receiving the marketing e-mail because of an ongoing relationship with my employer and perhaps tell me who within our organisation deals with their account? It’s good practice to put a little note at the bottom of the e-mail near the unsubscribe link to advise the recipient why they’re receiving the communication. Yet the e-mails that NYS sent to me did not inform me why I were receiving the e-mail and they did not include an unsubscribe link either. Section 23 of the PECR requires ALL unsolicited marketing e-mails – including those sent to a company (B2B), to include a simple mechanism for unsubscribing.
I asked NYS to clarify how and when they obtained my information and they said:
Just to clarify we only ever contact customers who have used our services in the past or we have been provided their contact details by procurement at [my employer]. A meetings enquiry was made in 2007 with NYS Corporate from our records.
Ah, okay, this sounded about right because the only major event that I’ve had any involvement in at work is one that took place in 2008; where our team invited a number of colleagues from around the world to visit the UK for a week of training. I never contacted NYS Corporate to enquire about their services though; instead it’s likely that a colleague of mine gave my e-mail address to NYS when she made the enquiry in 2007. But this means that they’ve held my information for eight years and I replied to highlight my concerns at their apparent lack of a data retention policy. NYS responded and pointed out that they were in the process of cleaning the data and gave me further assurance:
As a government framework supplier I can assure you we follow very robust data protection processes and [my employer] access our services through this Central Government Framework RM808.
According to NYS Corporate, they operate a very robust data protection process. Let’s see shall we?
We continued to discuss the matter via e-mail for a while but I wasn’t convinced by some of the responses that I received so I submitted a Subject Access Request (SAR). In response to my SAR, NYS Corporate provided a screen shot of my account.
The screen shot above is a section of the much larger screen shot provided by NYS in response to my SAR. Below the screen shot, the Chief Technical Officer at NYS had provided answers to some of my questions, one of his answers read:
When you obtained my information
The email address was saved in our system on the 1/3/2012 (Please see “Private Comments” section above) at which point we were instructed by [my employer] that this email address related to a permanent member of staff.
Err… hang on! While I accept that it was likely that NYS clarified with my employer that I was a permanent member of staff in March 2012 and that this information was manually entered into the Private Comments box, there’s absolutely nothing to suggest that this was the actual date of when NYS obtained my information. Indeed, were I to seek a court order under section 7(9) of the DPA, then NYS would likely be obligated to prove to the court that they obtained my information on this date. How are they going to do this when they’re using a manually updated field to apparently store the date of when they obtained an individual’s information? Anyone with the right permissions could update the Private Comments box with a different date at any time so it doesn’t prove anything. This is why the actual date of when a data controller obtains an individual’s information should be recorded automatically by their system using a database date/time stamp. Thus, whenever a new account is created the date of creation is created automatically in the database record and cannot be changed.
The notion that NYS do not automatically capture the date of when a new account is created is laughable.
Furthermore, if NYS do operate a system that is not automatically recording the date/time of when an account is created, then such a system is unlikely to be fit for purpose. This is highlighted by the Information Commissioner on page 16 of his SAR code of practice:
You will find it difficult to deal with SARs effectively without adequate information management systems and procedures. Given that subject access has been a feature of data protection law since the 1980s, your information management systems should facilitate dealing with SARs. Not only should your systems have the technical capability to search for the information necessary to respond to a SAR, but they should also operate by reference to effective records management policies.
Clearly the Information Commissioner expects data controllers to operate systems that facilitate dealing with SARs and in almost every SAR that I submit, I want to know when the organisation obtained my information.
At this point then, the Chief Technical Officer at NYS was contradicting the earlier response: that my information was obtained in 2007 as part of a meetings enquiry. His view is that my information was obtained in March 2012. I questioned him about this and he said:
My apologies for the date given by my colleague, this was simply a mistake when requesting further information from our operations team. Following a more detailed investigation into your data following your SAR request we were able to ascertain when you were added to the system.
There’s no misunderstanding here. The Chief Technical Officer at NYS is clearly of the view that they obtained my information in March 2012 and not 2007 as earlier advised. Yet because the March 2012 date was entered manually, he cannot prove it. Are we now to believe too that the NYS Operations Team cannot read what’s on the screen before them. If they looked at my account they must have looked at the Private Comments box, so why did they initially tell me that they obtained my information in 2007 when we can clearly see what it says in the comments box. Are we now to believe that they were looking at the wrong account or is it more likely that the NYS Operations Team do have access to the system date information and this is what they gave me? If this is the case then it’s likely that the Chief Technical Officer at NYS deliberately and knowingly misled me to make it appear that they hadn’t held on to my information for eight years.
I also asked the Chief Technical Officer to clarify the steps that were taken to conduct the “detailed investigation” as stated in his response but he refused to do so. Yeah right, detailed investigation… pull the other one!
In light of their response I decided to submit a complaint to the ICO.
The ICO’s makes a mockery of the process – as per usual
I submitted a formal Request for Assessment to the ICO (section 42 DPA) and here’s the time line of events that followed.
On 16 June the case office wrote to NYS to seek clarification on the issues that I had raise.
On 8 July the ICO case officer clarified in her Assessment (RFA0582588), that NYS were not the data controller for my information. Instead it’s my employer that is the data controller and NYS is just the data processor – they processed my information under contract with my employer. As such, the ICO concluded that there was no case against NYS because they simply complied with my SAR in accordance with their contract with my employer. The ICO case officer said:
It is clear from the terms of the contract that NYS has processed your personal data as a data processor on behalf of [your employer].
This came as a bit of as shock as I’d exchanged numerous e-mails with NYS and they’d even carried out an SAR yet this was the first time that I had been made aware that NYS were only acting as a data processor for my information – not the data controller. In other words, this government framework provider had failed to make me aware that they were only acting as a data processor. Were they even aware?
On 9 July I questioned the the case officer’s assessment. My view was that because NYS took it upon themselves to respond to my SAR, they acted as a data controller for my information whether they intended to or not.
On 13 July the case officer replied and said:
NYS are contractually required to comply with SARs as set out in their contract with [your employer], but as a data processor on behalf of [your employer] they are not required to comply with SARs under the Data Protection Act (DPA). They did not “become” a data controller in respect of your data by responding to your SAR and they did not “take it upon themselves” to respond to your SAR. They did so in compliance with the contract with the [your employer].
We cannot make an assessment in respect of a data processor because the DPA does not apply to them
I wasn’t having it. I can see what she’s saying but a data controller is the person or organisation that makes the decisions about the processing. I totally accept that NYS were operating under a data controller/data processor contract but if they took it upon themselves to process my SAR then surely they made the decision to do that so they would become the data controller for that processing?
I asked the case officer to forward me the data controller/data processor contract that NYS had supplied in response to the ICO request for clarification that kicked-off the assessment.
On 15 July the case officer acknowledged that she would provide me with a copy of the data controller/data processor contract and once again asserted that NYS were only a data processor so she could not carry out an assessment.
In the contract it stated that NYS must forward all Subject Access Requests to the data controller within five days. They failed to do this. I contacted the ICO to make them aware.
On 27 July the case officer replied and said:
If you consider that NYS may not have complied with the contract with [your employer] or may have acted outside its role of data processor in relation to your data, then you should raise the matter with the [your employer].
I submitted a complaint to my employer about NYS.
However, I was already aware that the Information Commissioner had published in-depth guidance on the difference between a data controller and data processor: Data controllers and data processors: what the difference is and what the governance implications are. I’d already gone through this guidance briefly but I couldn’t find anything that explained what happens when a data processor breaches the contract with the data controller so I went through again and there it was – section 67:
If a data processor breaks the agreement with its data controller, for example by using the data for its own unauthorised purposes, then it will also take on its own data controller responsibilities. This includes the duty under the first data protection principle to process, including to obtain, personal data fairly and lawfully. Where a data processor takes the personal data the controller has entrusted it with but breaks the terms of its contract by using the data for its own purposes, it is likely to be in breach of the first principle and the ICO could take enforcement action against it. Where an organisation acting as a data processor obtains personal data without the consent of the data controller it could also commit a criminal offence under section 55 of the DPA.
Clearly breaching a data controller/data processor contract is not something that the ICO’s case officers should take lightly.
On the 16 July my employer had concluded its investigation and their view was:
It is evident that the data was validated in 2012, and we believe that the original source was from an event run in 2007, however I think we will have to accept that no record is available of when that record was created on the system. [My employer] should, under the terms of the contract, have been told about the SAR and your complaint about the direct marketing.
We were not informed in a timely fashion, and were not aware that the SAR or complaint had been made until a later stage. NYS now fully understand their contractual obligations here.
Based on this response I submitted a case review to the ICO and included my employer’s response as evidence.
On 22 September the ICO responded as follows (RCC0592682):
As you have identified, our guidance says that, “If a data processor breaks the agreement with its data controller, for example by using the data for its own unauthorised purposes, then it will also take on its own data controller responsibilities.” In this case we do not have evidence that [your employer] considers that NYS has broken the agreement, and thus cannot reach a decision that NYS is a data controller.
But section 43 of the DPA places an obligation on the ICO to seek any information that it reasonably requires for the purpose of determining whether the data controller has complied or is complying with the data protection principles. In my view, the case officer should have sought clarification with me or my employer before concluding his case review. I wrote back and told them that I had previously provided the response from my employer as supporting evidence.
On 27 October the ICO responded as follows:
I note that you forwarded your correspondence [from my employer] of 16 July 2015 where it said that NYS did not meet its contractual obligations. Although you appear to have sent us this email on 7 August, it did not arrive on our servers until 4 September and was not added to your original case. As a result it was not considered in my review.
In other words, the ICO screwed-up.
The case officer continued…
Please accept my apologies that we have asked you for documentation you had already attempted to send. On the basis that [Your employer] has confirmed to you that NYS acted outside its contractual obligations, I consider it unlikely that NYS has met the requirements of the Data Protection Act 1998 (‘the Act’) on this occasion.
Finally, having done their job for them, the ICO concluded that NYS had failed to comply with the DPA. I have have to drag the correct answer out of the ICO’s case officers on a regular basis because they’re just not fit for purpose.
What Crown Commercial had to say
While the ICO were making a mockery of my complaint, I sought clarification from Crown Commercial about NYS and their government framework supplier status, they told me:
NYS Corporate were suppliers to Crown Commercial Service (previously Government Procurement Service) on our RM489 and RM808 frameworks however, these expired in February 2013 and August 2014 respectively. Call-offs (contracts) between the customers and NYS can continue past these expiry dates, and we understand that [my employer has] continued to use NYS for the provision of their meeting and events requirements, though after the expiry there is no formal agreement between Crown Commercial Service and the supplier. In this case NYS.
Thus, when NYS informed me In April 2015 that they were operating as a government framework supplier in accordance with RM808, they were not – their registration had expired in August 2014 and they were carrying out the remainder of the contract with my employer as a normal (call-off) contract. Did NYS try to mislead me or are we to believe that NYS Corporate were unaware that their role as a government framework provided had expired?
Is this company capable of giving me a single straight answer about anything?
NYS Corporate were keen to point out that they are a government framework provider that apparently follows very robust data protection processes. However, I think I’ve demonstrated that the following is likely to be true:
That NYS Corporate were unaware that they were only the data processor for my information. Despite the fact that NYS and I exchanged a number of e-mails prior to me submitting the SAR, at no point did they make me aware that they were not the data controller for my information.
That because NYS Corporate were unaware of their role, they took it upon themselves to comply with my SAR when they should have forwarded my SAR to the data controller and waited to be instructed to proceed – under the terms of the data controller/data processor contract they had with my employer
That by failing to notify the data controller that they had received an SAR, NYS Corporate put the data controller at risk of legal action under section 7(9) of the DPA.
That the manually entered date of 2012 does not prove that NYS obtained my information in 2012. If NYS cannot prove when they obtained my information then again they put the data controller at risk of legal action under section 7(9) of the DPA.
That NYS Corporate is apparently operating an information management system that does not facilitate dealing with SARs. This is because NYS apparently do not have access to the system generated account created date yet this is likely to be an essential aspect for an SAR.
That NYS Corporate failed to include a working unsubscribe link on their marketing e-mails and failed to respond to my two manual attempts to unsubscribe from their Christmas card e-mail. A working unsubscribe link is required on all unsolicited electronic mail marketing in order to comply with section 23 of the PECR.
That the initial response from NYS Corporate – that they obtained my information in 2007, was likely to be correct. My employer also reached this conclusion as a result of their investigation.
That NYS Corporate misled me about operating in accordance with RM808.
That because NYS Corporate didn’t understand their role as a data processor, that they likely panicked when they learned that they had held on to my information for so long so they deliberately and knowingly lied about the date they obtained it.
That NYS Corporate likely lied about conducting a detailed investigation into my complaint.
The right of Subject Access is a fundamental right of a data subject. When acting as a data processor under contract with a data controller, NYS Corporate are likely to be putting the data controller at risk by “apparently” failing to provide a system generated account created date in response to an SAR. This is because the data controller is ultimately responsible for the performance of the contract and thus the failure of their data processor to implement an information management system that facilitates dealing with SARs.
On this occasion I let it go because the data controller was my employer. Had the data controller been another company however, I would be well within my rights to take the data controller to court under section 7(9) of the DPA because their data processor is apparently not able to prove when they obtained my information. The data controller would likely have to explain to the crown court why they’ve chosen to use a data processor that manually records the account creation date instead of using the database date/time-stamp feature to automatically capture this information.
I dealt with three members of staff at NYS Corporate. The first person likely told me the truth that they obtained my information in 2007. Based on the evidence, it’s likely that the other two deliberately and knowingly lied to me and to my employer because I simply don’t accept that they cannot see the system generated account created date. I’ve since offered to pay for an independent database expert to review the NYS systems but NYS didn’t reply to my request. What can I say?
I allowed NYS Corporate to review this article prior to publishing it. However, this was also prior to the ICO’s case review. NYS said:
As NYS Corporate acts as the data processor (which has been confirmed by ICO and [your employer]), we believe the article contains a serious and significant number of factual errors and incorrect and unjustifiable assumptions. We also believe the article to be defamatory. Should you proceed with the publication of this article, we reserve the right to take legal action against you.
NYS did not challenge the ICO’s case review – that they failed to comply with the DPA, so in light of the ICO’s view, I’ve allowed NYS to review the article once again prior to publication. I’ve done everything that I reasonably can do to get to the truth so if NYS don’t take action for libel then it can only mean that they’re unable to prove me wrong.
If you’re in a data controller/data processor contract with NYS Corporate you should be concerned.