If you haven’t yet, you may want to read my previous screed about what compliance is. Much of this blog is predicated on that definition. In this post, we’ll be introducing the concept of “compliance engineering” and comparing it to the traditional practice of security engineering. We’ll also talk about how compliance engineering frees your teams to focus on product priorities, not endless assessments.
From Engineering to Security Engineering
Information Technology falls under the general umbrella of “engineering.” Requirements gathering, modeling, specification, R&D, TEVV, maintenance and support are all concepts within the world of engineering that have been applied to computing since IBM first operationalized accounting machines in the early 1900s. While modern practices attempt to optimize and productize IT, the history of these technologies can always be traced back to core engineering principles.
Cybersecurity, as a domain of practice, has a supporting set of technologies and related processes that we refer to as “security engineering.” These technologies prevent, detect, and respond to attacks against information and computing resources. Security engineers have the responsibility to understand how these security technologies integrate into IT architectures and to ensure they operate as intended. In general, the efficacy of these tools is based on risk management principles.
Cybersecurity risk management is wholly dependent on the organization’s risk appetite, so risk management is a subjective function relative to its context. Regardless of how small or big an organization’s risk appetite. The other part is due to cybersecurity having an inverse value proposition: cybersecurity practices are effective when bad things don’t happen. Hence, cybersecurity value typically increases the more you spend.
When stakeholders ask about the value of their cybersecurity investments, the best answer is typically “business as usual,” but there are plenty of cases of ransomware, unplanned downtime due to DDoS, discovering one of your databases on the dark web, and other bad things that happen with increasing frequency. In my experience, that leads to questions like “what are you doing to prevent X from happening?” The answer is always a maze of frameworks, policies, procedures, assessments, 3rd party services, consultants, scanners, enforcers, software agents, and a myriad of other invasive technologies. It’s an inherently long-winded answer to a simple question. Stakeholders rarely care about the details and the longer the answer, the less convinced they are to invest.
Enter Compliance Engineering
The problem at hand is: how do we, as cybersecurity professionals, communicate the value of security engineering that better aligns with stakeholders’ perspectives of value? Stakeholders that have been burned before by cyberattacks are typically ready to listen to the nuanced justifications for cybersecurity budgets. In my experience, fresh pain makes for a rapt audience.
What do we do for those stakeholders who haven’t felt the pain? We must speak to their core value system of maximizing profits through expanding opportunities and minimizing costs. This is what we’ll call “compliance engineering,” i.e. the practice of engineering products and services that are compliant by design, hence measurable and directly supporting revenue.
Build systems that are secure, auditable, and assessment-ready. Talk to us about Compliance Engineering.
Expanding Opportunities
From my last post, I discussed the idea that compliance is what organizations are forced to do as a condition of a business relationship. There are table stakes (i.e. opportunity costs) for nearly every market and business activity—whether contractual, regulatory, or legal—and compliance must be demonstrated at some point in the organization’s lifetime. For high-value opportunities (U.S. Federal government, financial services, pharmaceuticals, etc.), demonstrating compliance is a pre-condition to contract execution. These customers will want to see a certificate from a 3rd party auditor, or a successful assessment report, before signing on the dotted line.
I’ve had many clients throughout my career who have reached the contract negotiation phase of an opportunity only to panic because they don’t have an ISO 27001 certificate or hadn’t undergone a SOC2 audit. To me, it’s a little silly because those needs have been well established for years: my client just hadn’t considered the table stakes. They scramble to put a compliance program in place, forcing re-work and frustrations throughout the organization because they never designed for it. All that re-work leads to delayed revenue and potentially missed opportunities.
Minimizing Costs
I mentioned the concept of “re-work” above. That’s the situation where you’ve built a product or service and are ready to launch but have to re-do it near the finish line because of all the compliance requirements you should’ve known about sooner. This is point where budgets overrun.
Here’s an example of re-work for a U.S. Federal authorization. The expectation is that the product team could go through all the steps within a year to prepare for assessment and authorization, but because they didn’t consider the nuances of compliance (see previous post), they fail the assessment and go into a re-work cycle until they eventually patch everything up. That gap between expectations and reality is where those additional costs come in, eroding profit margins and, if it carries on long enough, scuttling the whole project.
This is where compliance engineering adds value: by integrating compliance throughout the engineering lifecycle, you eliminate the risk of re-work and missed opportunity. Yes, I do mean “eliminate” since an experienced compliance professional will be focused on the story that will eventually be told to auditors and assessors.
Audit Fatigue and Speed
Assuming you’ve been swayed by my arguments for compliance engineering and have decided to integrate compliance into your engineering practices, what other impacts should you expect?
First of all, audit fatigue. Or, I should say, the antidote to audit fatigue. In every organization I’ve worked, some compliance assessments—and the related market opportunities—have been delayed due to engineering teams being overworked. The overworking doesn’t come from having to work overtime under greuling conditions to respond to audits. “Audit fatigue” is from engineering teams feeling pressure to split their focus between responding to audits and developing new features. Too many audits means too few features, and too many features means too few audits.
While the problem clearly lies with stakeholders imposing too many conflicting expectations (nudge nudge), the situation can be mostly avoided by automating compliance evidence collection. If compliance concerns are integrated into the engineering lifecycle, then evidence will be produced on a regular basis as a normal part of system operation. When assessment time comes, all the technical evidence is ready to go. Ideally, engineering teams won’t even know an assessment is happening.
What happens when engineers can focus on their products? More features, faster. Compliance engineering becomes a competitive advantage.
Whereas cybersecurity is subjective and difficult to measure, compliance is not. Compliance is inherently well defined and measurable. Otherwise, compliance is in the eye of the assessor. Compliance engineering ensures that the compliance targets that are a condition of market opportunity are achieved with minimal cost. Compliance engineering flips cybersecurity from an inverse value proposition to one commensurate with traditional business principles.
Integrate compliance requirements from the start of your engineering lifecycle. Talk to our team today.
About the Author
