If you’re running a cloud-based app, there’s a decent chance that sooner or later, you’ll end up with a service failure or security issue that impacts your users. Most companies seem to break into one of two camps

A) If you don’t tell them, they can’t complain

Sadly, this is the first impulse of far too many companies. They figure that it’s unlikely that anybody will ever notice in the first place, and even if they do, it’s better to deal with the consequences then instead of antagonizing the unknowing.

B) Transparency is the best defense

This ‘Type B’ approach is being forced into the fore by various regulations that demand customer notifications in the case of security breaches of certain types or magnitudes. But, service degradations are rarely regulated except by contract.

This approach is a combination of taking an ethical stance and the pragmatist attitude that people will react better in the long run if you earn their trust with frankness up front.

A great example

The other day, I got what struck me as a fantastic example of how to do this kind of ‘Type B’ transparency. The social media posting company Buffer had a security related issue with how they were handling login tokens. Check out the message sent out:

Let’s take a look at the elements that make it so good:

• Promptness. The event was discovered on Friday and I received this notification on Tuesday (1)
• Customer clarity: A clear discussion of the magnitude of the problem. In this case, they had it easy because it impacted so few, but being unambiguous helps. Think about the cases where the company says ‘many users’ or ‘only a few users’ (2)
• A clear description of the technical failure aimed at a reasonably intelligent user. This description describes the components impacted and how they failed in words that are specific and technical but not overwhelming to the average user (3)
• Clearly declaring the end state. Successful in this case. But if it were still pending, such could have been said as well (4)
• Pulling the audience in to being part of the solution. We’re all in this together.

More companies could use this as a template instead of, say the Equifax model