How to Overcome the Biggest Data Governance Mistakes in Startups
In the rapid-growth world of a startup, there is no time for data governance - and until you start getting users, there’s little data to govern! But as your prototypes start to go into production and users start appearing, important data starts to fill your databases, and suddenly you need to think about regulations and backups. How can you make the transition from building an MVP (minimum viable product) to scaling your business, without making costly and embarrassing data mistakes along the way?
Previously we explored What is Data Governance and Why is it Important? and also 7 Key Benefits of Data Governance.
In this article we focus on some of the common issues that we’ve seen appear specifically in startup organisations. Here are our 4 top tips on how to overcome the biggest data governance mistakes startups often make:
1. Know the regulations
Understanding the data protection laws you will be operating under are table stakes for any business. Make sure everyone in your team knows them - in the UK, GDPR (General Data Protection Regulation) and the Data Protection Act are the main ones to know. Also look out for industry-specific regulations that your suppliers or partners may require you to meet, such as PCI DSS for handling card payments. These kinds of regulations impose obligations across nearly every activity your organisation does that involves the relevant kinds of data - so compliance with them can’t just be an afterthought.
2. Treat customer data with respect
While complying with the rules is a requirement, your customers and partners will be disappointed if you only do the bare minimum. As well as the legal obligations, think about how the users would like you to use their data. Thanks to repeated high-profile news stories, consumers and businesses are pretty cynical about corporate abuse of their data - so if they think you will abuse their data for creepy marketing purposes, sell it to dodgy data brokers, or let it be leaked by hackers, you will quickly lose their confidence. The regulations let you do creepy things with user data if you get their permission, but users will be much happier if you don’t - even if that request for permission is buried somewhere in a wordy privacy policy they won’t read. And while regulations may place requirements on security practices used to protect user data, and even impose penalties for security breaches, it’s much better to build data security into the entire architecture of your system, doing everything you practically can to keep customer data safe.
3. Keep production data safe
When building a prototype, you will be creating development databases and destroying them tens of times a day. Your automated test system will probably create a fresh database, fill it with test data, test your app against it, then destroy it again. If you are to maintain any kind of reasonable pace of development, you will need tools to spin up and tear down the database underlying your application with single commands.
All too often, when they first deploy a production instance, startups use the same infrastructure to manage the production database - and just make a mental note not to run “rake reset-db“ or “terraform destroy” on the production system. But with all the developers in the company usually able to log into production to fix bugs and deploy updates, it’s all too easy to type a command in the wrong window and wipe out production - not to mention the fact that any developer who can log into production could read private user data, and abuse or leak it.
Production instances of the application should have a “safety interlock”: some flag in the configuration that marks it as a production instance and disables all the dangerous commands.
Deployment shouldn’t be done by developers logging into the production system and updating it, but through a managed process such as Github Actions so developers can trigger a deploy without needing production login credentials.
Developers going into production systems to diagnose bugs should be avoided wherever possible by having decent logging and other instrumentation built into your app (and their outputs put somewhere developers can read them). It also makes diagnosing problems significantly easier, and helps meet your obligation to find the cause and extent of any security breaches that do occur.
But when all else fails and somebody still needs to log into production to investigate something weird, pair on it with a colleague so you can spot each other’s mistakes and it’s harder for an untrustworthy colleague to abuse user data.
Do we need to remind you to have regular, automatic, tested, securely stored backups of all production databases? But don’t get complacent - restoring from a nightly snapshot still means downtime, and any user data entered since the snapshot will still be lost.
4. Prepare for a culture shock
Going from development prototypes filled with dummy test data to a production operation handling real user data is a big leap, but technically production is just another instance. If you’re using the cloud for development, the technical difference is even less than if you’re developing on your laptop and then deploying to a server. But the legal and business importance of the data is vastly different between development and production.
The most important thing to do, before starting your soft launch and letting external people onto your production instance, is to sit everyone involved down to discuss the new requirements for production data and plan for what to do to protect it. This meeting will produce a concrete plan to avoid pitfalls - but most importantly, it will prepare everyone for the cultural change required to bring your product out into the real world!
We hope that you find these 4 top tips helpful in establishing good data governance in your business startup. It can also be helpful to talk through some of your challenges with a Data Governance expert. Feel free to contact us to discuss your specific situation or see more information here: Data Governance strategy and implementation
If you’d like more support around harnessing your data to stay ahead of the competition and building your data capability more generally, you may find our CDO as a service helpful. You can also contact us for a free, no obligation chat to discuss your specific situation and needs.
For further reading see:
Author
Tags: