"the salient points, in my opinion are: (1) Having examined the web site it is clear that Drupal was used. As you say, this is very inappropriate for the design of a site that will be handling very sensitive personal information. It does by default use an underlying database(typically MySQL – another free/open source licence), with the delivery of page content (HTML and JavaScript) controlled using PHP. As such, it’s architecture and vulnerabilities are widely known and the security of its sites are frequently breeched. Indeed in the past year Drupal have rolled out significant security fixes five times – but this doesn’t account for the many minor ‘hacks’ that are common place and frequent. (2) The reason for the loss of data given is both confusing and misleading. In the first part of the statement it claims that “due to a change in our website address … the data was instantly and permanently deleted”. I have issues with several parts of this statement. a. How does a change of website address loose data? The simple answer is : it is highly unlikely. The website address (it’s URL) is just a shorthand, easy-to-remember way of directing you to the physical computer on which the website is located. Each computer on the web has a unique IP address (of the form nnn.nnn.nnn.nnn). The link between the easy-to-remember URL and the physical IP address is not permanent, and can be changed (via the DNS records) at any time. This type of switch is common place and the end user is usually unaware of the change if it is carried out properly, and data integrity is maintained by copying the old database to the new location prior to the switch. b. Anyone using the CSA website prior to the change would have been directed to a database on the original server – there data would have been stored there (but see point (c) below). After the “change of website address” user will have been directed to a new server - with a different IP address. So here is my first “theory” : the original data was never copied across to the new server prior to the switch, hence the new server appears to have “lost” the original data. Actually it isn’t lost, it is still sitting on the original server – but is inaccessible via the website front end. If true then the data certainly wasn’t “instantly and permanently deleted” – it is still sitting on an unsupervised server somewhere on the planet. Which opens up a whole new can of worms relating to data security. Anyone with physical access to the original server, or remote access via RDC can access the old database and retrieve the information. c. The statement says it was “instantly and permanently deleted” due to changes in server. This clearly implies that prior to the server change, the data was successfully stored. Hence we can dismiss the possibility that there was some basic bug in the system that prevented the data being saved onto the server. This is, I think, supported by the fact that users entering the information believed it was processed successfully as they never received any error messages on submission. A bug in the system causing data loss between web form and database would inevitably result in an error message being displayed. Thus, we can conclude that this statement about instant and permanent deletion is false and misleading. It was not instantly deleted as it may have been stored on the original server for up to two weeks prior to the switch (see point (d)); it is highly unlikely that it is irretrievable (see points (e) and (f)). d. We have established that the concept of ‘instantly deleted’ is misleading. It is very likely that the data was stored on the server prior to the switch. It may be trying to say that ‘because of inadequate procedures, the original data was not available on the new server as soon as the switch was made’. This would give an outward appearance of ‘instant deletion’ … but this is not the reality. It is possible that shortly after (but not instantly) the original server was decommissioned, and maybe the database was deleted. But see points (e) and (f)). e. We have also established, I believe, that the original data was most definitely stored on the first server for up to 2 weeks before the switch. During this time it is inconceivable that there was no backup process put in place. Even “free” online services offer automatic backups and snapshots of database and server. Not to have implemented the most basic of backup procedures is incompetent and negligent given the sensitive nature of this enquiry. It is a fundamental principle of the data protection act to keep personal data “safe and secure”. f. It is common place to recover deleted information from hard disks. Even after someone hits the “delete button” there are many tried and tested ways to recover data .. even after a significant length of time. The police, security services and numerous data recover companies routinely restore lost data dues to accidental deletion or physical disk crash. So even if there were no backups, and if it is to be believed that immediately after the switch someone took the deliberate step of deleting the original database (which I doubt), then the data is still there and with a bit of effort can be reconverted. Security experts will tell you the only sure way of “permanently” deleting data is to remove the hard drive, crush it and incinerate it. (3) So, in conclusion I do not believe the data was instantly deleted nor is it unrecoverable. It just requires a bit of effort. But, given the obvious lack of commitment, professionalism and due diligence exercised by the Inquiry to date, no one has the will to pursue this. The fact that Drupal was used in the first place is reprehensible – no risk assessment, no appreciation of the sensitive nature of the information, and attempt at proving a professional, fit-for-purpose system. Finally, post switch-over- there seems to have been no attempt to analyse the problem and seek a reasonable recover solution – just an inaccurate and confusing statement inviting people to re-enter sensitive and distressing information. Are they REALLY taking this seriously ???