Most of my business's documents are confidential. Which online solutions are right for me?
Online security feels like a fuzzy subject.
The reality is that nothing is 100% secure in the digital or physical world. There's always a code for the safe, a key for the lock, a password for your login, and the human spy you never suspected.
So, security really comes down to what you're willing to forfeit to protect the things you can't bear to lose.
If you want to turn paper documents into digital copies, then your data's durability now depends on the endurance of hard drives. If you want to access your files online, then you run the risk of hackers gaining access. Every freedom you create with your data will have an equal and opposite side-effect, and it's up to you to decide what makes sense for your business.
So how much security is right for your organization? You can get a baseline answer to this question by asking yourself:
- What information of yours is sensitive or confidential?
- Who are you keeping your data away from?
- How would you secure this data if it were all paper copies?
As far as implementation goes, it's easier to conceive of security in physical and practical terms. It just so happens that your real-life understanding will translate nicely into the digital realm.
How the banks do it.
You might be thinking "I'm not a bank! This is silly to compare my business to an institution like that!" Not so fast... There's a lot we can learn from banks and how they handle our money.
First of all, most of us trust our money with banks more than we trust ourselves.
They have vaults and security guards to protect their money against outside threats, and if those measures fail, you still get your money back.
This is the equivalent of using digital services like Google's G-Suite or Microsoft's Office 365. Even though you could keep your sensitive data on your laptop, you know it stands a greater chance of survival in the high-security data-centers of these corporations.
But there's a major difference between money and data.
Money is replaceable, and data is not. Banks know this and use it to their advantage. Instead of securing paper checks in a digital age where we can deposit them with our phones, they simply guarantee your money against fraud. The result is that we get a great user experience without assuming any additional risk.
In this way, banks use a combination of raw security and administrative counter-measures to gain the trust of their customers.
Security comes down to trust.
Since we're talking about digital security here, using things like authentication and encryption are givens, and today's technology lends itself well to their implementation; the problem is knowing who to trust.
If you use a third-party service, how do you know whether they'll respect confidentiality agreements or react accordingly to reverse any mistakes they make? If you self-host, how do you know your custom application doesn't have any technical loop-holes that hackers can jump through?
There's no way around it. You're going to have to trust someone, and that brings us back to thinking about your data as paper copies.
Here are a some comparisons that will help you map your real-world methods to digital equivalents.
US postage & email
Sending confidential information through the mail depends on the integrity of the US Postal Service and anyone who passes your mailbox on the street.
Email is similar in the way that you need to trust that the recipient's mail server has TLS enabled and that each server won't hijack the contents of delivered email.
If you trust snail mail with sensitive business documents, then you should be fine using email. If you personally deliver documents around town, then you're better off transferring data on thumb drives and hard drives.
Vendors & the "cloud"
If you're comfortable having your paper documents housed in a filing cabinet at someone else's office, then you're probably fine putting your data on services like Google Docs, Office 365, Dropbox, etc.
When your data's on cloud services, there's nothing technically stopping that service from being able to see into your account, even if your data is encrypted at-rest or "deleted". This provides a great user experience, but you inherently forfeit your data to the corporation hosting it.
Safe-deposit box & client-side encryption
If you trust a safe-deposit box at a federally-insured bank, this means you're comfortable housing your sensitive information at another physical location but don't trust the location itself to keep its hands away from your documents.
With online data, you can encrypt files before you upload them to achieve the same effect, so that not even service providers housing your data can access it. Only people with your "key" can decrypt the files, keeping them safe in the wilderness of the internet.
With enhanced security, there are inherent downsides: if you lose your "key", then you lose your stuff. The service provider also won't be able to serve you with advanced functionality like keyword search or online previews.
Steel safe & self-hosted
If you keep your files in a safe on your property, then you don't want anyone else to handle your sensitive information at all. It's the best way for you to know that nobody is tampering with your documents without your knowledge or permission.
This also applies if you keep your files in a locked filing cabinet in your office.
The digital equivalent would be to self-host your own servers in your office. This gives you full control over its access, deployment, and maintenance. There's no third-party to "trust", although you'll have to trust that the applications you utilize are properly configured and safe to use.
This option is both the most flexible and most expensive, since you can't leverage existing services and infrastructure to manage your data (including most SaaS platforms).
Examples of trustworthy and untrustworthy behavior.
There have been some big security screw-ups recently that deserve attention because of how they were handled by the agency at fault.
On January 31st, 2017, Gitlab caused their own data loss, leading to hours of downtime for ~5000 projects on their service.
That incident potentially caused a huge financial loss for many companies, cutting them off from their codebases and incurring whatever consequences resulted from that.
They took full ownership of their error.
They posted about the incident a day later and also posted a postmortem detailing the errors within 10 days. Besides allowing them to do everything in their power to reverse the side-effects of their error, they proved that they can be trusted when they mess up.
Even though the breach wasn't detected immediately, their responses left a lot to be desired.
They notified the public over one month after they knew about the breach, blaming a vulnerability that they then claimed to have properly "patched" months prior.
Furthermore, they setup a site separate from their own domain to allow users to check the status of their breached information, which lent itself to phishing attacks.
This might sound unscientific, but my advice is to trust your gut. You're going to have to trust someone with your data, and the best tool to determine trust is you.
Once you determine which security measures you're comfortable with, you can search for those features in privacy policies and feature sets. If the service seems a little wonky or leaves too much unsaid, listen to your gut and bail; your customers will appreciate it.