Over the course of the last decade, software development has matured significantly as an industry. Increased news coverage and regulatory scrutiny resulting from high-profile supply chain attacks like SolarWinds(opens in a new tab), nightmarish security flaws like Heartbleed(opens in a new tab), and industry-spanning component vulnerabilities like Log4Shell(opens in a new tab) have forced our industry to rethink itself at a rapid pace. The short of it is that the public cares about security more than ever, and that’s a good thing.

Security posture refers to how prepared an organization is to identify and appropriately respond to security risks it may face. At Nutrient, we’ve evolved our own security posture over the years, diligently working to set the example in our market for achieving compliance certification in our digital document SDK products.

In a way, it goes without saying how we got to where we are today. Robust information security practices have gone from a value-add to an expected minimum for enterprise software consumers, and it has become more important than ever for organizations to have a method to verify the soundness of their supply chain. Compliance frameworks such as SOC 2 and ISO 27001 are exceedingly popular tools for communicating both operational guarantees and baseline organizational security competence.

So, given the obvious assurance benefits that a strong compliance posture brings to the table, why doesn’t every organization place a strong focus on compliance issues? Well, the reality is that adopting a comprehensive compliance model is incredibly challenging, especially for smaller organizations.

Compliance is expensive, both in fixed audit costs and in the highly variable implementation costs for meeting necessary controls. It’s incredibly difficult to quantify intangibles, and many organizations are extremely hesitant about pouring a significant investment into a prospect that may or may not have a direct sales advantage associated with it.

It’s easy for sales to become the driving factor when it comes to implementing compliance auditing. As a way to rationalize and offset the high cost of implementation, many organizations see compliance purely as a way of opening the door to sell to larger enterprise customers who require it. And it makes sense to think this way — many enterprises will no longer even consider purchasing products that don’t carry a compliance label of some kind to meet their policy requirements. But this isn’t the whole story of where a robust compliance effort can help an organization.

I believe that the real reward to be reaped from adopting a strong compliance posture lies in the incidental structural improvements that stem from such an effort, so in this post, I’d like to consider the often undersold and intangible operational benefits of SOC 2.

The importance of organizational security

In an engineering-focused company, it’s easy to focus on the technical security measures of the products we design.

Granted, that’s not to say we shouldn’t build our products with robust security models in mind. Given the vast automated dragnets that probe for known exploits around the web, it’s self-evident that customer-facing products need strong security precautions that liberally utilize secure-by-design principles and defense in depth. But that’s a topic for a different blog post.

The reality is that the impacts of security stretch much further than just the engineering department and product design at any given organization.

There are massive implications to the operational decisions and processes that a given company implements. Top risks that modern enterprises face — such as supply chain attacks and social engineering — prey on organizational weak links to circumvent technical controls and access key assets.

For just a moment, let’s step into the mind of a sophisticated advanced persistent threat (APT(opens in a new tab)) targeting a specific software organization. Why waste the time trying to craft a specialized exploit to crack the robust infrastructure of a SaaS platform when you can just phish one of the principal engineers to grab the juicy administrative credentials you’re looking for?

As technological security mechanisms increase, sophisticated attackers have pivoted to focus more on individuals and business processes rather than technical infrastructure. It’s a shift that has proven fruitful time and time again, even against huge security-focused industry players. It worked against Okta(opens in a new tab). It worked against LastPass(opens in a new tab). It will work again against countless other victims.

The only way to secure such operational weaknesses is with the implementation of consistent and unwavering processes. And how do we ensure that the processes and procedures we follow are in fact consistent and unwavering? We audit our ability to comply with them.

It isn’t just a buzzword term — the act of verifying one’s ability to comply with matters of policy is what the very term compliance refers to. The point I’m trying to make is that security is a multifaceted problem that extends beyond just the technical engineering problems we encounter. Compliance exists to address the human aspect of security, and internal business processes are easily just as important to formally document and secure as our engineering products are.

The reason we pour all this investment into compliance improvements isn’t so that we can sell our products better. It’s so that we can quantify our own ability to operate in a consistent manner as mandated by our policies. That’s the real value of any compliance exercise.

How SOC 2 has improved Nutrient

Thus far, this post has discussed the value of SOC 2 in philosophical generalities, but I’d like to conclude by highlighting some of the real tangible improvements that the journey through SOC 2 compliance has resulted in for our company.

Slashing the knowledge silos

Policies that are fit for SOC 2 must be fit for consumption by external parties, including both auditors and customers. This is fantastic, because a key requirement for policies written with such a broad target audience is that they must be understandable in a vacuum by laymen.

The easily overlooked side effect of the implicitly required writing style is that policies and procedures for key business processes become more digestible to an internal audience as well as an external one.

Representatives from all different parts of the business are brought together to collaborate on defining how Nutrient operates and turn siloed institutional knowledge into shared written documents.

Cross-team process improvements

By centralizing company policies and procedures as part of the SOC 2 process, we’ve been able to improve how we communicate cross-team internal business processes that are critical to the operation of our business.

To give a couple examples, through the implementation of our SOC 2 policies, we’ve:

• Made significant improvements in standardizing our access review practices across different internal company groups to improve our internal audit processes.
• Built out automation in our compliance monitoring platform that helps act as an additional check to notify us when assets aren’t configured according to best practices.
• Significantly improved our vendor management process, adding increased standardization to how we onboard and track vendors. This has become particularly valuable with the rise of mass availability of AI tooling and the data implications of the usage of such tools.
• Expanded our internal SDLC handbook to more comprehensively document engineering process knowledge that was previously tacit, which has helped significantly in unifying our development processes across lines of business.
• Centralized documentation regarding our incident response process to more effectively communicate resolution steps and maintain preparedness and investigate in the event of a security incident.
• Built out a comprehensive knowledge base of policy information to more effectively respond to customer security questions.

Streamlined communication for customer trust

In the modern security landscape, there’s an increased focus on supply chain and vendor security. Customers are more concerned than ever about gaining assurances that their vendors are following industry best practices around security.

As a software vendor, having SOC 2 compliance reporting provides an entry point for discussions with our customers surrounding organizational security. When we lay our security posture on the table for our customers, it helps allay individual concerns and makes opportunities for more in-depth conversations about any given items that are more specific than our report has answers for.

Conclusion

SOC 2 and similar standards are nowhere near perfect, but no individual security practice ever will be. SOC 2 and other compliance frameworks cannot and will never provide anything close to an automatic guarantee that a company can’t be affected by security incidents, nor will they ever preempt all security questions from customers.

However, by implementing a compliance framework, we create strict, quantifiable, organization-wide standards for how we should approach the documentation of security practices. We use our compliance framework to strive to be more consistent and more effective for communication with outside stakeholders like auditors and customers.

When we document policies for our compliance activities, it creates a mirror for ourselves where we have to honestly look at what we’re doing as a company and reflect upon how it makes the security posture of our company look to our auditors and to our customers.

If we see something we don’t like in our reflection, it forces us to take ownership and implement changes. It allows us to hold ourselves to a cycle of regular and proactive improvement rather than aimlessly meandering until a breach happens and shines a spotlight on our limitations for us.

Beyond any kind of quantifiable sales value-add or revenue appreciation, the true value of implementing SOC 2 or other compliance reporting frameworks is that it fortifies the formal foundation of our internal security efforts, providing a framework for self-reflection and continuous improvement upon our organizational security posture.