Innovation Blackout

In the Harvard Business Review Blog Evade an Innovation Blackout, Jordan Cohen points out the difficulty of engaging effort for new ideas when the people with the ability to develop those ideas are up to their asses in aligators.
In a financial downturn, the razor-gangs that decend on the organisation are a big inhibitor of necessary change at just the wrong time. Any innovation is seen as something to be avoided or delayed rather than embraced as a means of getting out of a failing operation.

Backup Google Apps II

Continuing from   Backup Google Apps , I have been taking a look at Backupify.
This product meets a key component of my disaster recovery scenario. I am assuming that the worst that can happen to a Google Account is that users and the administrator lose access to it and, perhaps through the action of a 'bad person', Google cannot be persuaded to restore the account access.
Backupify can be accessed through a login independently of Google Apps which provides an alternative route to the backups if the 'bad person' has locked users out of the primary google apps files. Documents and Mail can be downloaded from Backupify as an alternative to restoring to the apps account so there is a measure of comfort that if the worst happens there will be a recovery path.
However there are some fish-hooks...

• Because Backupify is accessible from Google Apps single sign-on, this convenience would be available to the bad person who could then lock the legitimate user out of Backupify*.
• To support the download capability, Backupify transforms the Google Apps documents (creating xls files for Google Apps spreadsheets for example). This has unfortunate side effects, as there is not a one-one relationship between Google documents and the MSOffice equivalent so the round trip will lose
1. any scripts developed in google apps spreadsheets
2. the effect of google functions in spreadsheets
3. charts in spreadsheets
4. external references to shared or published documents

So there still does not appear to be an equivalent in Google Apps of the conventional off-site backup that will allow a recovery of all information in a disaster situation.
Is losing access to the Google Account a scenario that should be considered? I can think of a few possible events. In no particular order of likelihood or Machiavellian complexity:

• Side effect of law enforcement action in US (eg Megaupload) 
• Destructive action by a Google Apps super administrator 
• A 'bug' in Google Apps

 [Update] * Backupify recognised the issue and responded (sensibly in my opinion)

Currently, we are looking to improve security with an extended identity verification that would allow you to regain access to your account faster in the case that this happened. We do not have this in the product now, but in the meantime if you want to send us a photo of your picture ID then we can store that internally and securely with your account. That way in the future is someone did gain unauthorized access to your Backupify account via Google Apps login and they changed the Backupify password that you set then we could work with you and use the photo ID that you sent to verify your true identity and get you access to your account again.

so we can expect there to be a process that could circumvent the issue of losing access to the backify account.

Backup of Google Apps

I am looking at the need for backup and recovery capability for organisations that manage their information and operations through Google Apps. 

Classically, backup for the unforeseen event comprises a resource remote from the primary information that can be used to support the business operations in the event of the non-availability of the primary source. Analysis of risk and impact of losses can be used to determine how long that you are able to do without the primary source and how much you should be prepared to pay for recovery within that time. Generally, only broad classifications of risk to the primary information is considered (destruction of data centre; denial of service etc).
In “cloud” services, we are buying a measure of protection of our information assets from the provider whether that is Google, Microsoft or Waikikamukau Data Services. The trust we can place in these organisations is related to their competence and also the size of the pain that the organisation will feel when your primary information is unavailable. For example, if Google reported that it could not recover from a failure of just one of its data centres, there would be a massive loss of confidence affecting the viability of the multibillion dollar company.
So we might safely assume that Google will be able to restore your account in event of a catastrophe in their domain, but user mishandling of information is another matter and firmly in the user’s court. For this the user needs a strategy to suit their needs for information assurance.

Implementing some form of backup for Google Apps will require one or more of

• Maintaining an inhouse backup storage server to backup cloud based documents to local hard disk  or another storage supplier like Amazon.
• Use a 3rd party service like Backupify or Spanning to copy and restore Google Apps documents/files.
• Something to confirm that your backup policy is adhered to

In the case of Spanning Backup there are a few issues to be aware of.

• When a document is recovered it is a new Google Apps document. Any references to the original will not be replaced by the restore operation. This will affect Sites that link to Apps documents, shares of the original, and published documents.
• When a shared document is recovered, the new document is retains the shares of the original but the ownership changes to the user that performed the restore.
• When a restore is performed, a folder is created to contain the restored documents. This folder is treated like any other, including taking part in subsequent backup cycles. There are opportunities for confusion about which version of a document is which.
• The backup can only be used to recover to Google Apps and not as a path to another service

There will be good reasons for these issues and the design fits well with organisations where the individual user is responsible for their own environment (like with a personal computer). However, those familiar with IT-managed filestore could be surprised, unpleasantly.

Privacy Watchdog with Teeth?

Lets take computer privacy breaches seriously here in New Zealand. Give the Privacy Commission some teeth and send appropriate messages to the likes of ACC.
A recent case in the UK resulted in a significant fine being levied on a National Health Trust which failed to destroy sensitive data on 1000 hard disks before releasing them. More worrying was that they thought that they could contract out of the responsibility by using a 3rd party to facilitate the disposal.
Here in New Zealand, we get investigations but no sense that responsibility for the protection of sensitive data is sheeted home to senior management. The pressure on organisations that mishandle sensitive data is reduced by the requirement that the “complainant can show that they have suffered harm” rather than that there was a breach. Only “if the harm is significant, a complainant might be able to claim that they are entitled to compensation”. Note that there is no actual entitlement to compensation nor a means of making orders like that made in the UK case. The best we can hope for is a sound drubbing of the Minister by the the capital’s press but even that has been lacklustre.