How I Learned to Stop Worrying and Love Compliance

Early in my career, I saw compliance as a tax on moving quickly that a small, growing engineering team couldn’t afford. I’m still not a hardcore compliance guy, but I have come to see the value of building compliance into a product early.
​
Engineering teams need to work differently to meet requirements around compliance. If you put the right things in place early on, the technical debt imposed by compliance is not very significant, whereas if you have to play catch up later, you’ll have a lot of work to do at the expense of other things you could accomplish.

​The Cost of Delaying Compliance

Some argue that companies shouldn’t focus on compliance right away, that a team building out a new product should focus on security. I believe compliance and security should go hand-in-hand or teams will find themselves in a place where they have to back engineer the whole thing - a huge cost in terms of time.

At Microsoft, the Bing platform was built with security in mind and not compliance. This worked okay, but made it so the massive investment made in the technology couldn’t easily be reused for Microsoft Office. The power of a search engine for email, documents, and other corporate data is incredibly important, but the technology didn’t meet the compliance requirements. Even some of the most basic infrastructure, such as the content delivery network  (CDN) I worked on were not reusable, because the compliance controls were not in place. It was a two year effort to get compliance in after the fact.
​
When I worked at Edgecast (a CDN that was acquired by Verizon), we were packaging our software to be able to deploy it onto the network of telecommunications companies. We had to change all of our production authentication, rebuild our build systems, and redesign our organization. For a small company with less than 250 employees at the time, this was a huge tax to pay.
​

​Compliance as an Asset, Not a Tax

How did I as an engineer learn the importance of building in compliance? I spent five years working at Experian after they acquired my startup. As soon as we started working together, they educated us on how to think about how we engineered our systems. Taking advantage of the massive experience that a credit bureau puts on compliance made me realize that for Experian compliance was an asset, not a tax.

Given the huge lift required by engineering teams to build in compliance after the fact, I came to appreciate the significant difference it makes if you decide to set up the process up front. I am convinced that is a good way to begin building an app. If you build in compliance early, it’s a much smaller burden on your team, especially when you’re talking about operations systems.

If you are new to the compliance game, spend some time learning how to build an audit trail that is easily accessible, figuring out how to separate duties between two people so a developer isn’t touching their own code in production, documenting how data enters and leaves your system, and cataloging the security controls you are building.  Many compliance controls are about the processes you have put in place to manage security and handle data. Learning the basics when you are architecting your system could save you a lot of headache in the long run.
​

​As Standards Change, We Can Comply

Here at Smartsheet, we’re undergoing the process of becoming compliant for the new European standard under the General Data Protection Regulation (GDPR). Since Smartsheet was built with security and compliance in mind, this new standard doesn’t require my team to implement new operational procedures, nor does it add additional overhead for us.
In our case, our challenges are less around the efforts to become compliant and more about answering questions, how we state in contracts that we’re compliant and ensuring that people understand how to request the controls provided by the compliance standard.

When compliance is built in from the beginning, rather than an afterthought, meeting new compliance standards isn’t a huge burden. We’re all set up to demonstrate how our security meets a specific set of security requirements, even as standards change.
​
Source: Smartsheet Blog