Learning Lessons

By Daragh O Brien
January 10, 2011
28min read

W. Edwards Deming famously admonished managers that:

You can’t inspect quality into a product; It’s already there!”.

In other words, you can’t create a good product, experience, or brand by reaction to errors, defects or flaws once your product, process, system, or website goes to market. You need to proactively take steps to ensure that your organisation is building quality in. This applies just as much to Data Protection considerations as it does to Information Quality concerns. In a Data Protection context it is known as “Privacy By Design”.

Failing to design privacy in means that your organisation is inviting the risks of non-compliance with relevant legislation, security breaches and the compromising of personal data (and the ensuing costs and concerns), regulatory penalties, and ultimately damage to your organisation’s brand.

While I want to avoid pointing fingers, the ongoing saga of Fine Gael’s election website woes is a salutory tale for organisations working with Personal Data, in particular Sensitive Personal Data which contains a lot of lessons to be learned. And as the old saying goes, those who fail to learn the lessons of history will inevitably repeat those mistakes. So, I compiled the following list of lessons.

I’d also wholeheartedly recommend the comments of Brian Honan of BHConsulting regarding the Information Security aspects of this issue.

  • Plan

Failing to plan means you are planning to fail. This needs to go beyond the Baldrick-like “I’ve got a cunning plan” desire to get a new web-based engagement tool for your organisation. Factors you need to consider include:

  • What are you intending to do with the information? What might your primary and secondary purposes be?
  • What type of information are you likely to be capturing (e.g. personal data, sensitive personal data, financial data)?
  • Who are you likely to share it with, and on what basis?
  • Where you will storing the data and in what format?
  • How long will you need to keep the information for to achieve your goals?
  • What risks might be posed to the information from a security or quality perspective? How secure is the website code, filesystem, database etc.? Can copies of the data be taken by staff on memory keys? Does the data have to conform to specific format/quality requirements to be of usable quality (e.g. requiring “N/A” in a postcode field that is mandatory)?
  • Are there fields that are mandatory? (i.e. will you require particular data from respondents in order to achieve your purpose – e-mail address, postal address, mobile phone number, etc)?
  • Do you have any way of validating mandatory data?
  • What is your plan if things go horribly wrong and data is lost or stolen? Who is in charge? Do you have a backup & recovery plan? What is your media/communications plan?
  • What is your plan if data is not of sufficient quality to meet your goals or satisfy your legitimate partners’ needs if you are sharing it? How do you fix the data? How do you fix the relationship with your partner organisation? How do you handle any media issues? Who is in charge of actually managing the issue?
  • How will you gather evidence of the effectiveness and operation of controls and governance?
  • What is your plan for testing the site and what level of testing is needed before you ‘go live’?

It is at this stage that the organisation should be assessing the suitability (or otherwise) of its Information Governance structures to make sure that there are clear lines of responsibility and that the processes, policies practices, culture and system capabilities are all in place to ensure a high-quality outcome. This helps ensure what I call TRUST3 – quality (trustworthy) data from a reliable (trusted) source by way of a formal arrangement, processed using tried and tested (trusted) processes).

Unsurprisingly, the strong recommendation is that organisations seek the impartial advice and assistance of a 3rd party specialist to facilitate the workshops and work plan in relation to this planning phase. The reason for this is simple – an independent 3rd party can ask the questions and challenge the assumptions, beliefs and internal politics that often hamper the efforts of mid-management to get these issues on the agenda. We can ask the “Why” and “Why not” questions. We can also provide unbiased assessments of your plans and approach and bring in other expertise (e.g. InfoSec advisors, Communications and Recovery Management advisors) as required to ensure your plan is ROBUST.

  • Do & Check

Once you have a plan, you need to DO and Check it. Make sure you are familiar with the relevant legislation (don’t rely on “Chinese whispers” for your education – invest in training and professional advice). Put the policies and procedures in place, ensure your staff are trained. Make sure you have the contracts in place and the due diligence you should have done done. Have the evidence of all of that to hand (that should be part of your response plan), build your website But (and here’s the bit that people often miss)… don’t DO it in production. You need to make sure you’ve tested all of this prior to launch.

  • Check that the Privacy Statement on your website matches how the site features and ancilliary processes actually work.
  • Check that the wording of privacy statements and your policies are consistent and, equally important, intelligible – don’t assume levels of literacy. The guidance in Financial Services it to aim for a reading age of 12 on important documents. NALA have some great resources
  • Make sure that poor quality data can’t be input or you have controls to detect and correct the error(e.g data that doesn’t match the requirements of the field such as numbers in a name field etc, or the contribution from “Ef Ef” in “EffEff” from the Fine Gael website) .. In freetext fields on webforms, one check might be to look for javascript tags or php tags in the text which can indicate an attack vector from an IT security perspective)
  • Get the various contracts you need in place and do verify claims of Safe Harbor or ISO accreditation.
  • Do test the site in an environment that models “live”. Get a Info Sec consultant to do a white-hat hack attack on your test environment, check what happens if components of the site get knocked out, get your Data Protection consultant to do a “health check” assessment (a dry-run audit). Heck,why not proactively invite the DPC in to inspect your homework if you want (now that is belt and braces, but we’d recommend having an exhaustive run through from expert advisors first to make sure your homework is correct).
  • Do make the importance and value of the data and the need to respect it an care for it a key element of your organisation culture (again, being mercenary we can help with that through management and facilitation of culture change and the delivery of training programmes).
  • Have a “fire drill” to test your ability to respond to a crisis – whether with the quality of your data, the security of your information systems, or a competitor’s challenge that might try to attack the credibility of your brand – test your readiness to bring out the big guns if the circumstances demand it. This will be a validation of your planning and preparation.

It is only by actually testing your product that you will know how well it will respond. By testing the ability of the site to produce data you can use, with functioning levels of security protection (addressing both system and person issues), and with a functioning response plan that allows your organisation to respond appropriately to issues as they arise you can get some comfort that you have a governance framework in place that will provide some protection, should you have to do it for real.

  • Act

There is no point testing the site, your Data Protection processes and controls, and your Data Quality controls if you don’t actually do anything about it. Before going live you need to address the concerns identified in the testing and verification. Fixing them is not the issue. Considering them and making an informed risk assessment of the cost/benefit trade off of fixing them is the question.

Some issues you will have no choice but to fix immediately as they are either Critical errors or missed regulatory requirements or a total failure of culture and processes. Others you might defer but you should make sure your Governance team are doing so with a clear understanding of the legal or brand impacts of not addressing the problem. This is a Standard Operation Procedure in any Risk Evaluation exercise.


Once your site or system is live you need to keep your plan under review (is it being followed? is it working?) and monitor the effectiveness of security measures and the operation of your Data Protection processes and protocols and the usability of the data being generated for your purposes.

Stakeholder feedback, whether from site users/visitors or from your own “back room” teams should be welcomed and listened to. If there are alarm bells being raised, you should have a PLAN to run the issue through a triage and assessment to see if it is a real concern or something that has already been dealt with in your plan, or is a distracting but irrelevant red herring. Ignoring concerns and dismissing them because of where they come from is a serious error.

Error logs from data quality processes or system operations and from web server logs are also valuable sources of information about what is happening and whether you are properly managing risks to and from data on your site.

It is not a good strategy to ignore the problems if you have them. Identifying them, assessing them, and prioritising them mean that you will be better placed to proactively manage risks and more directly deal with the impact, and to deal proactively with them should the event materialise.

No plan is ever perfect or complete,and there is no such thing as “absolute security”.

Related Insights


Keep up to date with all our latest insights, podcast, training sessions, and webinars.

This field is for validation purposes and should be left unchanged.