We’re excited to announce that we have recently completed an examination of our internal controls and data security practices relative to the standards set forth in the System and Organization Controls (SOC) criteria as established by the American Institute of Certified Public Accountants (AICPA), and that our auditor has determined that the design of our internal controls provides reasonable assurance that Juniper Square achieves our service commitments based on the Security and Availability trust services criteria.
Phew, that was a mouthful!
This news represents the culmination of a yearlong effort to come into compliance with these important security standards, and is a significant milestone for Juniper Square and our customers. We believe we are the first dedicated real estate investment management software provider to undergo an audit based on these standards.
At Juniper Square, we take data security seriously. From day one at the company, we knew that our software vision depended on a foundation of customer trust.
In this post we wanted to share some thoughts on what SOC is, why it’s important, and what data security means to us here at Juniper Square.
We also wanted to help shed some light on a common software marketing practice that can be confusing to customers. Many vendors will substitute their data center’s SOC compliance for their own SOC compliance. While it’s good that Amazon Web Services, for example, is SOC-compliant, that has nothing to do with whether your vendor is SOC-compliant. It makes a world of difference, so be sure to know whether it’s your vendor, or their datacenter, who is SOC-compliant.
Demystifying SOC and its many acronyms
With acronyms like SOC 1, SOC 2, SOC 3, SSAE 16, SAS 70, ISO 27001, NIST 853, and many others floating around, we thought we should spend a moment to help the real estate industry decode what these standards mean.
At their core, these standards are sets of principles and business practices defined by independent standards bodies such as the AICPA. Vendors agree to follow these types of standards to ensure they are taking reasonable steps to safeguard sensitive data, and to provide other assurances such as around availability. While not designed for software-as-a-service (SaaS) vendors in particular, they do represent an objective standard against which you can evaluate a potential software provider, and thus a shorthand way for prospective clients to evaluate that provider’s level of focus on data security.
In the U.S., the SOC standards have become dominant for business-to-business software, while NIST 853 is most common for vendors who deal with government entities as clients, and ISO 27001 is the standard of choice in Europe.
Confusing things further, there are three different classes of SOC certification a vendor can attest to, and two different types within those classes.
The three classes of SOC
SOC 1 is focused on evaluating the controls at a vendor that may be relevant to their clients’ internal control over financial reporting. The SOC 1 report was issued under the SSAE 16 auditing standard for service organizations, which superseded the earlier SAS 70 auditing standard, so if you hear references to those auditing standards, they may be referring to a SOC 1 report. (The SSAE 16 standard has itself now been superseded by SSAE 18.)
SOC 2 is a more recent type of report, also performed under the SSAE 18 auditing standard. The SOC 2 report assesses a vendor’s internal controls and policies as they relate to security and other related areas, which are called the “trust services principles”. There are five trust services principles in total: Security, Availability, Processing Integrity, Confidentiality, and Privacy. A vendor like Juniper Square can choose which principles to be evaluated against, although all SOC 2 reports must include the Security principle unless they are focused only on Privacy. In a world without constraints you’d choose all five, but each additional principle increases compliance and audit costs, so companies typically pick the principles that are most relevant to their operations and customers. In Juniper Square’s case, we chose Security and Availability, which is common for B2B software providers. The SOC 2 attestation process yields a detailed report, but the report can only be made available to current and prospective customers and their auditors, and only under NDA, which brings us to…
SOC 3 is similar to SOC 2 in terms of the trust principles and the process, but the output is different in that you don’t get a detailed report on the vendor’s internal controls and policies; you get a brief auditor’s report attesting that the vendor maintains effective controls over its systems. Because the report lacks confidential details, it can be freely distributed, but it is not as useful for customers who like to understand vendor controls more deeply. Because we wanted to be able to provide more detailed information on controls, SOC 2 was the best approach for us and our customers.
The two types within each SOC class
SOC 1 and SOC 2 can have two levels of attestation: Type 1 and Type 2 (SOC 3 reports are always of Type 2).
Type 1 – In this level, the auditor assesses the design of the vendor’s controls relative to the trust principles, but does not track operation of the controls over time. Think of it this way: if the standard says there has to be locks on all of the doors, then the auditor checks all of the doors for locks, and then attests to what they have found.
Type 2 – This designation focuses on whether the vendor is appropriately and consistently using the controls as defined. If Type 1 is about establishing that there are locks on the doors, then Type 2 is focused on assessing whether people are actually using the locks to keep the doors secured. Often, a vendor starts with Type 1 to get their initial audit accomplished in fewer calendar months, and can then elect to move to Type 2 in future audits when there is more calendar time available to observe the controls over the long term.
At Juniper Square we selected SOC 2 given the nature of our software, and started with Type 1, which is the designation we’re announcing today. But our work here continues, and we expect to secure a Type 2 designation in our next annual audit.
My vendor says their datacenter is SOC 2 compliant; what’s the difference?
In a word: HUGE! Smaller SaaS vendors often lack the resources to undergo security and control audits. To compensate, they may draft off of the security designations of their own vendors, such as their data center provider. Large data center providers like Amazon Web Services (AWS) are audited against virtually every major standard in use, and so your vendor might tell you that they are “SOC 1, 2, and 3 compliant”, or PCI compliant, etc.–and they may well be–but you need to read the fine print to assess whether they are making a claim about their own practices, or the practices of their data center provider, which is usually a huge company like Amazon.
Think about it this way: what difference does it make if a datacenter is audited against SOC 2 if your SaaS vendor allows employees to process your data on their computers, and then those computers get lost or stolen and your data gets breached? This risk has nothing to do with the fact that the datacenter is audited, and the datacenter’s controls are not adequate to protect against this type of risk. The point is this: your vendor itself should be audited against the SOC standards; their datacenter’s certifications alone cover only a small slice of the risk.
The best way you can test for this is to ask to see a copy of the vendor’s SOC report. You’ll be able to tell right away if it’s Amazon’s logo or the vendor’s on the front cover. Note that SOC 2 reports cannot be freely distributed, so auditors will require you to execute an NDA to get access to the report, and you may be provided view-only access with no ability to print or save the document. These documents spell out—in great detail—a vendor’s security controls, so it’s in everyone’s interest to ensure that the sensitive material stays protected. It’s not exactly scintillating reading, but it will give you confidence in your vendor. If you don’t want to deal with NDAs, just ask your vendor to represent their SOC compliance in your agreement with them.
Our view is that data security shouldn’t be an upgrade, or an upsell, or something that your vendor will get to down the road. It should be the #1 priority from the get-go.
Data security at Juniper Square
At Juniper Square, we take data security seriously. From day one at the company, we knew that our software vision depended on a foundation of customer trust. If we didn’t have the trust of our customers, then none of the features we planned to build would matter. As any employee who has been through our information security seminar will tell you (and every employee has to go through it), this is not a topic we take lightly, and we feel an immense responsibility to ensure we are good stewards of our customers’ most sensitive data.
It’s why we hire vendors to continually test our systems, and it’s why we’ve invested a significant amount of time in this SOC 2 designation. Our view is that data security shouldn’t be an upgrade, or an upsell, or something that your vendor will get to down the road. It should be the #1 priority from the get-go. At Juniper Square security is our top priority, and we’re excited to continue to invest in data security to ensure that we are at the frontier for our customers in the months and years ahead.
– Adam Ginsburg, Co-founder and VP of Product
To learn more about Juniper Square, schedule a demo.