Topics

Category: Compliance

SOC 2 is a phrase that can strike fear and confusion into startups and small businesses, but there’s an easy way to talk about and respond to SOC 2 requests long before you undergo the time and expense of a formal SOC audit.

Most startups and SMBs first encounter the term “SOC 2” during the sales process when a customer asks if you are “SOC 2 compliant” or have a “SOC 2 certification.” In many cases, the customer or prospect doesn’t even know what SOC 2 really is, or what goes into a SOC 2 audit. They’ve just been told by their compliance director or security officer (or the pundit at an industry conference or webinar) that all vendors must “be SOC 2” to do business with their company. SOC 2 is as much a buzzword to many companies as it is an actual policy.

You can win SOC 2-contingent business by showing you understand the point of SOC 2, and that you can deliver SOC 2-style reliability even before you obtain formal compliance. The trick is understanding SOC 2 first.

In this webinar we cover what to do before you have an audit. How do you build trust with customers? What documentation should you have ready to share? Is there ever a time when it makes sense to wait to have an audit performed? What if an audit seems to expensive?

Independent Coin Offerings are called “ICOs” and not “token sales” precisely because they want to appear similar to investor-friendly initial public offerings of stock (IPO) — which raises a catch-22 compliance problem many startups and investors haven’t much thought about. Specifically, ICOs represent a gray area in U.S. Securities Exchange and Commission (SEC) regulations, and that could make investing in an ICO a compliance minefield for many investors.

The main question in any ICO is this: do the tokens in the sale qualify as a financial security?

If so, then the ICO must follow some very specific rules to govern the sale, many of them identical to a conventional stock IPO. If your tokens are securities, your ICO must be registered with the SEC, and must be overseen by a registered broker. This is no small undertaking, but it has the advantage of laying out some clear rules to handle the token sale.

Many times, however, the SEC simply refuses to comment on whether an ICO is actually selling a qualified security. This means that — at some undetermined point in the future — your tokens could be retroactively classified as any of several asset classes, which in turn means that any initial investors are taking a risk beyond just the normal possibility of coins declining in value.

Anyone can buy a publicly traded stock, but if the SEC doesn’t consider your token equivalent to a public stock, it limits who is allowed to buy your coins under U.S. law. In theory, investors could be forced to divest themselves of their coins should the SEC later decide that your ICO sold an asset class that your investors weren’t qualified to buy — even if that divestiture causes a serious financial loss. Your investors could be forced to sell their tokens when their price is at rock bottom, all based on some unforeseen SEC decision.

This limitation applies even to sophisticated investors. For example, while hedge funds and accredited individual investors can buy pretty much anything, many mutual funds or retirement funds can only hold public stocks or bonds, and many venture capital funds can only hold stock in companies that have not yet issued an IPO. (Once a stock goes public, a VC fund usually has a window to divest, but can’t hold the publicly-traded stock for very long.)

Complicating matters further, unless your ICO qualifies as a crowdfunding instrument, it may be impossible for non-accredited investors — which is to say, average people who don’t have high net worth — to buy tokens during your sale. No one has stopped non-accredited investors from buying Bitcoin, but there’s no legal standard to prevent the SEC from treating your ICO differently.

Before issuing an ICO, it’s critical that your organization review the legal structure underpinning your token sale, both to prevent it from running afoul of regulatory guidance, and to protect yourself from investor backlash should the SEC decide to reclassify your tokens as a highly regulated asset class at some point in the future.

When developing a compliance plan for your company one of the first tasks is identifying how your information security management system operates. Below we have provided several internal controls examples to demonstrate the types of polices, procedures, and technical configurations a company may establish to build a strong control environment. Ideally, a pre-cursor to establishing internal controls is a risk analysis.

Controls are a means to mitigate risk. Adding a control could be seen as slowing down business, so it’s necessary to ensure that only the right controls are prioritized and implemented. You may be asking, what are internal controls? It can be anything from a policy that directs what should be done, a procedure which describes how something should be done to reduce risk, a technical configuration to prevent information exposure, or monitoring to detect malicious activity. Controls are generally categorized as preventive or detective.

Below are 9 examples of common internal controls:

Information Security Policy – a foundational document that defines the administrative, technical, and physical security requirements of an organization. It is a document that defines how information confidentiality, integrity, and availability is protected.

Annual Security Policy Review – a procedure to ensure that the information security policy remains up to date. Over time company goals change, there are personnel changes, and new threats emerge. Reviewing your information security policy annually will keep your company current.

Confidentiality Agreement – a legal document that employees typically sign that requires them to keep all company and customer data confidential. The purpose of this is to prevent information leakage.

Encryption Policy – a document that describes how and when a company uses encryption. An example encryption policy may state that all customer data in transit or at rest must be encrypted. Policies typically also specify encryption algorithms and key lengths.

Change Management – a process that enables the secure and structured approach to management changes to system configurations or application code. Change management is a category that often includes controls as testing and QA, source code versioning, peer review, and segregation of duties between developers and production engineers.

Backup and Recovery – a process that ensures that data remains available when needed. Companies often focus a lot on backup but fall short when developing recovery plans. Backups should be tested on a regular basis.

Security Awareness Training – people are often the weakest link in any information security program. Regular security training, reminders, and documentation to prove it occurred goes a long way in keeping auditors happy.

Semi-Annual Review – just as policies and procedures go stale, this control ensures that accounts and configurations on systems remain up to date. New employees are hired, job responsibilities change, and terminations happen. This ensures that system access control remains consistent with the workforce.

Vendor Patching – keeping software such as applications and operating systems up to date is one of the best ways to prevent getting hacked. Software patching should occur on a regular basis for normal updates and immediately for critical updates.

Large organizations typically appoint a Chief Security or Chief Compliance Officer to manage audits from beginning to end. Smaller companies tend to outsource expertise and form a team to prepare for compliance. It is best implemented as a team effort because policies changes will impact everyone in your company. As with any major project, executive buy-in is key. The value of compliance isn’t always apparent and having the right people on board will help immensely.

A SOC 2 report will help your customers trust that you follow security best practices. SOC 2 reports are generally carried out by businesses performing information systems processing or technical services to other business. The SOC 2 report provides third party assurance that an adequate baseline of Information Security controls have been put in place. Businesses of all sizes can have a SOC 2 audit, however, it is most beneficial for businesses looking to sell in the enterprise market.