Compliance as a By-Product In Software Development

You went for ISO 27001 compliance because it helped you land that big customer. 

Million-dollar question: is your business less at risk now?

I have navigated implementations of ISO 27001 and SOC 2 Type 2 countless times in my career. Here’s the key: a policy doesn’t stop the potential security breach.

It starts higher up than policy. In tandem with an implementation specialist, we constructed an argument that left an immature area out of scope. The easiest way to get certified is to only certify the bits you’re not worried about…

The real key of course is creating a culture that prioritizes good risk management and empowers your team to make smart decisions. As with most regulations, compliance only matters when it’s too late. If nothing goes wrong…why do you comply? If it does go wrong … did you comply? It’s the old insurance logic. With the usual “did you comply” to make claims on the insurance.

Let me break down my approach to compliance in a software team. A story in 3 parts.

Compliance as a By-Product In Your Software Team, Not a Goal

I never asked our teams to “comply”. 

Complying is the wrong incentive. If you’re asked to tick a box, people will tick a box the easiest way possible. 

Case in point: complying with a clean desk policy means writing your passwords on a sticky note and leaving them in an unlocked drawer. Box ticked, no sensitive data on desks.

Instead, I ask “What is this control trying to achieve? Which risk is it looking to address? What are we worried about here?”

This shift in perspective is crucial. It moves you from a checklist mentality to a risk-based approach. You’re not just following rules; you’re understanding and addressing the underlying concerns.

Back to my passwords. We moved to installing a digital password manager for everyone and educating our entire company staff on proper password management. I’m sure there was still a post-it here or there, but overall our risk had significantly gone down.

Do the Right Thing: Empowering Your Team

While a lot of people in the company need access to sensitive information to do their jobs, software engineers tend to be the highest risk. In part because a tiny mistake can do a lot of harm to your product, in part because they often have keys to the (digital) kingdom in smaller companies.

The good news is that most experienced engineers have a practical understanding of how to cover these risks. The key is to tap into this knowledge and create an environment where it can flourish. That’s culture.

In this particular case, I brought a few mandatory items into our product development process. 

We made it a point in architecture reviews to explicitly ask questions about risks. Not a tickbox “Have you thought about X”, but a genuine discussion on “How does this go wrong”.

In our case, we focused heavily on data protection, data access, and scalability. By making these concerns a standard part of our development process, we embedded security thinking into our day-to-day operations. And because we kept notes that documented both what and why; it was easy to demonstrate in an audit.

Here is another example of how I helped the client’s engineering team achieve the compliance required for their B2B deal.

I’m not saying you shouldn’t do a penetration test or get some outside advice (like our health check to get a broader perspective). But it starts by embedding a culture of asking the right questions.

Not Optional, but Commercial

Compliance in an engineering team costs money, that is not in dispute. Neither is that at the end of the day, I work with for-profit businesses. This means that sometimes a risk is worth taking, or a “100%” solution is beaten by an 80% solution or even a 0% solution at times. 

Yes, a 0% solution is a solution too. I have said no to a 150k capex project to have a spare part readily available. The risk: if our main component blew up we would be out of service. With the spare part available for an hour or 2. Without the spare part, 2 hours plus however long our supplier needed.
Cost to the business? Once we crossed the 30-minute mark it didn’t matter how much we overshot. Most customers would get the full day credited.

The crucial part is this: Be explicit about the choice and we own it. 

In practice, that means we document the suggested approach and provide the rationale for why we didn’t go for it. The onus was on me and my team to work hard to not accept a proposed improvement, rather than people having to ask for budget, time, or resources to implement an improvement.

This approach ensures that security decisions are made with a clear understanding of business implications, not in isolation.

A Culture of Continuous Improve Risk Management

It wasn’t instant of course but in the end, we made improving our risk management part of the culture. And then made it the hard path to do the wrong thing.

Of course, we were never short of improvements to make. Most of the time, I ended up being the one putting the brakes on people’s proposals. This is the kind of proactive security culture you want to foster.

What CEOs Need to Know About Tech Compliance

Most of my readers are CEOs. You might be wondering what all this means for you. 

Here’s the bottom line: standards like ISO 27001 and SOC 2 Type 2 are not just checkboxes to tick. 

• You already know there is a commercial incentive.
• There is also an internal incentive. They’re frameworks designed to help you manage risk effectively.

Your role is to foster a culture where security is everyone’s responsibility, not just the IT department’s. It’s about creating an environment where doing the right thing for security is the default, not an afterthought. 

You can start by asking the right questions to your CTO or COO.

CEO-C[T/O]O Compliance in a Software Team Conversation Starters

1. How are we handling CIA data across the business? Under what scenarios do we make compromises?
   • Confidentiality: is the data kept secret or private.
     In practice: do only the right people have access to sensitive data
   • Integrity: is the data authentic, tamper-free, and reliable?
     In practice: can you trust the data?
   • Availability: can those who need it access the data with minimal disruption?
     In practice: How do we maintain access to critical data sources and control access rights?
2. “How do our current compliance efforts align with our actual security risks?”
   • Can we agree on those risks? Both on severity and impact?
   • This question encourages a discussion about the gap between compliance checkboxes and real-world risks.
3. “What’s our approach to SOC 2, ISO 27001, Cyber Essentials, … ? Are we just ticking boxes, or are we addressing the underlying risks for certain controls?”
   • This prompts a conversation about the company’s overall compliance philosophy
   • Sometimes it’s about choosing where to focus your efforts. And ticking boxes might be better than not getting certified. That’s where an improvement plan comes in
4. “How are we empowering our people to make security-conscious decisions in their daily work?”
   • This explores how security is integrated into everyday processes
5. “How do we document and justify our security decisions, especially when we choose not to implement a suggested measure?”
   • This addresses the importance of clear documentation and rationale.
6. “What channels do we have for team members to propose security improvements? How often are these used?”
   • This explores the culture of continuous improvement in security practices.
7. “How do we incorporate security considerations into our development process?”
   • This digs into the practical integration of security into development processes.
8. “What do you see as our biggest security risks right now, and how do they relate to our compliance efforts?”
   • This encourages a risk-based perspective on compliance.
9. “How do we ensure our compliance efforts are improving our security posture, not just ticking boxes?”
   • This addresses the core idea of compliance as a by-product, not a goal.
10. “If we were to shift our approach to make compliance a by-product rather than a goal, what would be the first steps?”
    • This opens a discussion about practical changes to improve the approach to compliance.
11. “How do we balance the need for security with the pace of innovation in our development process?”
    • This addresses the potential tension between security and agility.
12. “What metrics do we use to measure the effectiveness of our security practices beyond compliance checkboxes?”
    • This encourages thinking about meaningful measures of security.
13. “How do we ensure our entire team understands the ‘why’ behind our security practices, not just the ‘what’?”
    • This explores how to build a security-minded culture across the organization.

CTO Action Items: Implementing a Meaningful Compliance Approach

If you are a CTO, here are some thoughts for you to consider. 

1. Where are you exposed? Both in terms of the likelihood that an event will happen and impact. 
2. Reassess your current approach to compliance and security. Are you just ticking boxes, or truly managing risks?
3. Identify key risks specific to your business. What are your crown jewels, and what are the biggest threats?
4. Integrate security questions into your architecture reviews. Make it a standard part of your development process.
5. Empower your team to propose security improvements. Create channels for these suggestions and take them seriously.
6. Establish clear documentation practices for security decisions. This includes documenting why you didn’t implement certain measures.
7. Create a process for balancing security ideals with business realities. Remember, it’s about managing risk, not eliminating it.
8. Set up regular security culture check-ins. Are people thinking about security proactively? If not, why?

Conclusion

Compliance is important, but it shouldn’t be your end goal. By focusing on understanding and managing risks, empowering your team, and creating a culture of continuous improvement, you’ll find that compliance becomes a natural by-product of good practices.

It’s time to rethink how we approach compliance in tech. Are you ready to make the shift? Trust me, your business will be stronger for it.