Is this data policy sufficient for my nomadic small business?

Question

This might be the wrong place to ask but I thought I would give it a go: I know nothing about data security and I have tried to educate myself over the past couple of weeks and I have come up with a data security policy/protocol for the small business that I am starting. The major hurdle that I have is that I am starting this company without access to a secure network because I am working remotely and traveling for the next few months.

Just a little info about the small business before the policy: its a small business (1-3 employees) that does data analysis, visualization, and data management and processing. The data that we will be working with could be highly sensitive, but it does not need to be HIPAA compliant (at this point).

Here is the draft of the policy...

How you can safely get your data to us

We recommend that you send us your data files via the secure file transfer service we employ. This file transfer service complies with multiple state and federal privacy regulations including HIPAA, PCI-DSS and EU-US Privacy Shield. The system uses 256-bit encryption on SSAE16 and SAS70 certified data centers. All data are deleted from their system after a fixed and short time using a proprietary deletion process. More information can be found at the file transfer service provider’s website (SendThisFile.com).

How we store your data safely

After we receive your data, we temporarily save your files to an encrypted folder on a fully encrypted computer system. This system is then disconnected from the internet and your data are transferred to a highly-secure external hard drive that is protected by 256-bit AES hardware encryption, and a brute force self destruct feature. Next, we permanently delete your files from our servers using overwriting practices to ensure they are truly unrecoverable.

How we keep your data safe during analysis

When it comes time to analyze your data, we disconnect our computer system from the internet before we connect to the encrypted external hard drive. All temporary and permanent data files are directed to the encrypted external hard drive.

How we safely get your data and results back to you

When it comes time to send your results or reformatted data back to you, we save the files from the encrypted external hard drive to an encrypted folder on a fully encrypted computer system. The hard drive is disconnected, our server is reconnected to the internet, and your information is sent via the secure file transfer service. As soon as your data are sent, we permanently delete your data files from our computer system. Once your project is completed, we will retain your data on our encrypted external hard drive for one month, or for a pre-determined period, before we permanently delete your files from our encrypted hard drive.

How we protect our communications

As an added security, all of the emails we send, including email attachments, are protected using end-to-end encryption through Tutanota.

Answer 1

What you've cited probably would have impressed some customers. It certainly wouldn't impress me. I won't delve into implementation details or whether you need security policy or privacy policy, because you've missed the most important item:

You don't give the end users a way to determine if their precious data is safe.

As of now, the added value of your proposition is from user's perspective just a piece of impressive text. A ten-mile-high view of it is "you'll have to trust me and only me". That's it.

For me, a minimal policy is:

Dear customers, your data will be protected from misuse. External auditor will check the implementation (yearly/quarterly/just once). The certificate of compliance will be available to you at https://example.com/current_audit_result .

Expand on that, add the details. But don't remove the audit, because it's of major importance to users. Generally, the goal of security is to decrease the total amount of trust and/or to spread the trust among many parties. That's because "to trust somebody" is a near synonym of "to be vulnerable to somebody". Users want less of that.

For example take all your propositions like "we disconnect our computer system from the internet" and say they cover all probable attack vectors. Rational customers assume that you will actually do as promised 60% of the time. With audit, this estimate is maybe 80%. This factor multiplies every freakin point of your proposition. In scope of such example, lack of audit means twice the risk. That's a lot.

Answer 2

It's quite detailed, but it's focused only on the handling of the data, and isn't a comprehensive security policy. Obvious immediate omissions are timeframes: how long is "temporarily", or "a short time", that you're promising your customers? To you, temporarily could mean a week while you return to the office from a vacation; to your customers, it might mean no more than 5 minutes. It also doesn't say anything about customer isolation: is it possible for client A's data to be processed on the same system as client B's data? Could they get mixed together, such that client A sees some of client B's information?

But what it's really missing are most of the other things that make up a security policy. These are the other considerations your organization promises to give to build a full security picture. This includes details like patching computers, network security and monitoring (including intrusion detection systems and firewalls,) risk-based decision making, audit trails, continuous improvement, incident detection and response, backups and disaster recovery, anti-virus tools, secure configuration management, encryption key lifecycles, roles and responsibilities, identity and access management, secure contract reviews, and the list goes on and on.

When someone is looking to establish a new security policy, I recommend they at least take a look at the NIST Cybersecurity Framework. It's a comprehensive list of things to consider including in a security policy.

You certainly don't need to write every drop of the framework into a policy as you're starting out. And you shouldn't try, because you don't yet know all the systems and architectures you will need to protect, and you don't yet have experience with the risks you will face. But you should at least read through the functional categories listed in Appendix A and pick and choose those bits that make the most sense for dealing with the risks you've initially identified. Probably the most important thing to include in your first draft of a security policy is to schedule an annual review. By this time next year you'll know a lot more about your business and risks, and you can start to add to it thoughtfully at that time.