female engineer

The Compliance Debt Factor

There is a business reality that too many startups, and even later-stage companies, fall victim to: not having a clear and well-structured action plan for security and privacy. This security shortfall suddenly comes front and center at quarter end when that must-have enterprise deal slips away due to compliance requirements. This growing deficit is what I refer to as compliance debt.

Whether it’s GDPR or security attestations like SOC 2, my prior startup experience taught me that using a client’s requirements as a way to back into an InfoSec program can lead to costly technology decisions. You need to start now and start small, so it’s achievable. Deferring your compliance debt will cost you so much more in the future.

You might be familiar with the term technical debt in software development where you prioritize speed of a code release over properly structured or regression tested code. With compliance debt, you’re likely not even considering the small steps you can take to address security considerations when architecting your solution delivery or managing privacy reputational risk that exists in your go-to-market strategy. 

Compliance as Code 

Compliance as Code is the process of automating the implementation, verification, remediation, monitoring and reporting of compliance status. This automation comes in the form of code and is the best way to build compliance into development and operations. If you don’t know where to start, however, you don’t need to reinvent the wheel. 

Use standard security frameworks that fit your business

The good news is that GDPR, SOC-2, ISO 27001, and NIST 800 standards are well-documented and transparent. They provide a prescriptive outline in the form and nature of controls, policies and procedures you need to follow to adhere to their standards. When these standards intersect with your product, some fundamental principles can be deployed to a minimum flag where PII (personally identifiable information) and customer-sensitive data might live. Developing a taxonomy of flags or markers for data classification with the corresponding risk assessment for data leakage potential are the first steps to take in helping to mitigate your compliance debt. NIST does a great job outlining techniques to classify PII here

Identify all possible risks

Next, a risk assessment will help you identify what systems, processes and nodes (servers, end points) could serve as vectors for data leakage or compromise in your business. There are standardized risk assessments that could be deployed and even automated, including our own Tugboat Logic Security Assurance Platform.

How to implement Compliance as code

To implement compliance as code, you need to first map new feature development and workflow enhancements. Then, regression test against your compliance taxonomy for the handling of protected customer information. Ways you can address compliance debt is:

  1. Consistency: Define and implement uniform procedures to handle structured PII data. Wherever possible, define the data using the same classification criteria and use that same definition across all nodes that touch data while in transit and at rest.
  2. Reduce data jurisdictions: Move data outside of the extraneous server processing or disparate data centers whenever possible to enable better monitoring, capture, reclamation of sensitive information. Take proactive steps to look at all your commercial applications that collect both employee and customer data and minimize all data capture to their core essentials to enable a process to function. Some big culprits – productivity and sales automation apps that collect PII in a passive listen mode and become giant PII data lakes over time.
  3. API Encapsulation: Ensure that sensitive or regulated data can be accessed via APIs in all nodes and workflows. This ensures complete remediation based on user requests or points of extrusion for data leakage. 

Compliance as Culture

It’s easier than you think to introduce and sustain compliance as a culture in your organization. Engineering leadership can talk about it in their daily stand-up. CEOs can make it a standing request to have product management monitor and report on security and privacy risk measurement and registry in roadmap reviews. In addition, we’ve seen many of our enterprise clients provide promotion tracks for IT developers, program/product managers to seek out the compliance program management role with incentives, professional training and career advancement.

Compliance debt manifests itself as an economic risk for the business as well. To start, many early growth tech companies that process third party consumer data must often demonstrate adoption of CCPA or GDPR guidelines to secure investor funding or even secured lines of bank credit. Anecdotally, venture capital firms’ indications are that financial and corporate due diligence now includes inquiries on compliance debt and assessing the business’s privacy risk. In addition, employees and business partners are starting to hold each other more accountable for protecting sensitive information and requiring documented third-party risk assessments for any vendors that touch PII. You will be judged by the company you keep and how seriously you take the issue of privacy.

Security Compliance is a Win-Win

The good news is that your team can develop a culture of compliance that scales with your business’ and will ultimately enable your ability to drive revenue by demonstrating proof of compliance.  Viewing ‘compliance as code and as culture’ starts at the top by defining InfoSec as a KPI for your business. We’ve already seen that those organizations who prioritize security and privacy as product features shorten their sales cycles by up to 40% and reduce the reputational brand risk that can impact churn or new customer acquisition.

Related Articles

Backup and Recovery Process: Choose It or Lose It

Backup and Recovery Process: Choose It or Lose It

Despite our best efforts, sometimes things go wrong. The best way to handle situations should they arise, is to have a plan to act in advance, and keep that plan updated when threats change. This not only covers risks to your data by bad actors but plans in the event of a server outage or a natural disaster as a few examples.

read more
Change Management Process: Time to Go Deeper

Change Management Process: Time to Go Deeper

Your formal Change Management Process will guide you through the planning and implementation of your changes. Documentation and approval need to cover all the changes in terms of software, enhancements, applications and any other systems or elements the changes will involve or touch.

read more

0 Comments

Submit a Comment

Pin It on Pinterest

Share This