As a cloud and infrastructure security engineer, I have worked with engineering teams and auditors for information security assessments, including ISO 27001 and SOC2. In many industries, customers require compliance before even considering purchasing a product. From a customer’s point of view, how can they assess the strength of an vendor’s information security practices? In theory, the customer can rely on a third-party auditor to help verify an organization’s security practices. Unfortunately, in many cases, compliance ends up as a race to the bottom for both engineering teams and third-party auditors.

Compliance-driven Engineering

When management determines that a product needs to meet certain compliance standards, it is understandable that engineering teams receive compliance requirements in the same manner as any other feature. This approach leads to a mindset of finding the gaps between the compliance standard and the system under examination and then determining how to close those gaps as quickly and cheaply as possible. With this approach, engineering teams without strong management dedication to security tend to apply point fixes to meet the minimum requirements in the areas that auditors will examine. I call this approach “compliance-driven engineering”.

Chasing multiple different compliance standards without strong security resourcing, policies, and implemented process is an anti-pattern from both business and security perspectives. Achieving audited compliance with each marginal standard requires a large monetary and time commitment. Engineering teams should consider that this takes resources away from actual security work. Further, most security standards overlap for the vast majority of their controls, so control mapping and paper shuffling occupies much of the time required to complete an audit. Spending time on compliance, especially without a well resourced or mature security program, means engineers cannot work on things that matter, all while technical debt accrues.

Finally, after going through an audit, an astutue engineer will realize that the auditors have close to zero idea about anything technical or security related. During audit walkthroughs, the product team could easily omit discussion of deficient areas of the system or, more likely, auditors will simply not probe deep enough to discover deficiencies. Instead, auditors focus on easily understandable areas such as user access reviews, change management processes, and corporate policies. One tip an auditor told me: do not show anything with red on it because the auditors will ask follow up questions. For an engineer, this really illustrates the minimal value we can derive from an audit; auditors do not have the skills or motivation to dig deeper. Given the cost of an audit by a Big Four accounting firm, I would think they could employ an engineer on the audit team, but the incentives are not there. Auditors instead want to complete their engagement as quickly as possible and work with the customer to make their audit report look favorable, thereby preserving the chances of engagements for future audits. If an auditor does a thorough job and delivers a report with unfavorable findings, the customer can simply find a different auditor who does not dig as deep or is willing to overlook deficiencies. Overall this leads to a system of misaligned incentives (if security is the goal) from both the engineering team and auditors, resulting in devaluing the contents of the audit report.

Engineering-driven Compliance

Instead of compliance-driven engineering, I believe that organizations wanting to prioritize security (not compliance) should just do the right things and then use audits to show off their work. I call this “engineering-driven compliance”. Management should dedicate resources to performing security engineering throughout the software development lifecycle and embed security champions within engineering teams to develop a mature security program.

Securing a modern SaaS is a full time job and security-focused engineers have a wide range of areas they can tackle. If compliance is required (often it is), we should realize that audits are boring and do not generate security value, so audit-related processes should be automated as much as possible. Further, organizations should employ dedicated compliance staff to take on as much of the work as possible and minimize the burden on engineering teams. One of my favorite posts on aligning security and compliance while minimizing wasted effort is The SOC2 Starting Seven.

I realize this section is light on details, but organizations should just let people who care about security do their job and let compliance follow, while minimizing the time it takes away from security engineering. To minimize compliance friction, organizations should employ security engineers to establish best practices and standardized security services that can be reused by multiple teams throughout the organization. Compliance and security teams should work with engineering teams early in the product’s development to build in the best practices that auditors will look for.

Conclusion

Information security is an important part of a product. Engineering teams should consider security throughout the product’s lifecycle, not add it as an afterthought. While compliance may be necessary, I believe all compliance work should be approached with the mindset that time spent on compliance is time not spent protecting systems. An engineering team leveraging standardized security services and patterns should have to do relatively less dedicated compliance work, when compared to a team attempting to wrap compliance around security and process debt, allowing them to maintain feature velocity while working on actually improving security.