Hi everyone. Welcome to season two of Risk Grustlers, where we bring you stories from the trenches from folks who’ve navigated risk, compliance, and security across various stages and situations. We keep it very real and dive deep into their experiences and journeys, exchanging valuable notes along the way.

Today, we have a very interesting guest with us. Kevin has spent his career working in security at tech startups, and he and I share a lot in common. 

Kevin transitioned from working at a Big Four consulting firm with very large enterprises to working with smaller tech startups and medium-sized companies. His journey offers a unique perspective on the challenges and opportunities in the world of security.

Ayush: Kevin, let’s start with understanding how your career has shaped up. What made you transition from Big Four consulting to small startups? What prompted you to make that change?

Kevin: I began my career right after college, where I studied engineering but wasn’t quite sure what path to take. Consulting seemed like an appealing option because it offered a chance to explore different fields and figure things out along the way. I was placed in the security group, which was a high-growth area then and still is today. Compared to my software engineering internships, consulting wasn’t very technical; it focused more on meetings, slides, and organizing tasks.

With my engineering background, I found that I preferred being more hands-on, actually building systems and working directly with technology. Although I enjoyed creating PowerPoints and still use those skills, I wanted to work with computers in a more practical way. This led me to break into the tech world, where I could engage with new technology, write software, and have a greater impact.

As a consultant at a Big Four firm, you’re just a small piece of a massive machine, and your impact feels fairly limited. In contrast, joining a startup as an early security hire allows you to contribute significantly to the business. The startups I’ve worked in have varied, from e-commerce to B2B SaaS and B2C, and I’ve also consulted for and worked at a security vendor. I know some of our listeners might not love vendors, but having been on that side, I can say it’s a challenging job—so cut them some slack.

For me, being on the tech side is much more interesting. I was a software engineer in a past life, and security engineering is the perfect blend of risk management and technical work.

Ayush: Kevin, during our earlier conversation, you mentioned that you utilized your bench time during your consulting days to ramp up on skills for a career in security engineering. Could you talk more about that? What resources did you tap into, and how did you determine what would be relevant for you?

Kevin: In Big Four consulting, the CISSP is a standard many strive for, though I never got mine. During my bench time between projects, I read the entire CISSP study guide by Shawn Harris to get a broad understanding of security concepts. I wanted to have a comprehensive knowledge base, which is crucial for a security professional.

I also did a lot of practical labs using resources like Forum Hub, where you can download VMs with intentional vulnerabilities. Additionally, I read “Security Engineering” by a Cambridge professor, a fantastic resource that he generously released for free online.

These free resources were incredibly valuable. The CISSP book cost about $30, but the self-study I did taught me more than my actual projects. While my consulting projects taught me about business operations and interpersonal interactions, most of my security knowledge came from these online resources and hands-on practice.

Ayush: When you transitioned from consulting for large enterprises to working in small to medium companies, what were some unexpected challenges you faced?

Kevin: At large enterprises, security infrastructure is usually well-established. You have no local admin rights, need IT approval to install software, and have access to enterprise-grade tools and specialized teams.

In startups, especially as the first security hire, you’re the go-to person for everything. There’s no one else to consult when issues arise, so you need to be adaptable and learn quickly. For instance, if the company uses Azure, you’ll be googling a lot and possibly taking courses after work.

At a large company, you might specialize deeply in one area, like application security. In a startup, your focus might be on broader tasks, like getting through SOC 2 compliance, rather than deep technical details. You handle high-level tasks, such as organizing a PEN test or updating dependencies, but you can’t dive into every detail due to time constraints and business needs.

Ayush: Many of our viewers are junior to mid-level professionals at large companies looking to transition to smaller ones for more agency, while others want to move to larger companies for deeper specialization. So, how should mid-sized companies start building a security program that balances breadth and depth?

Kevin: For B2B organizations, using a compliance framework like SOC 2 or ISO 27001 is a great starting point. Compliance can drive your security efforts because these frameworks include fundamental controls that overlap and provide a solid foundation.

For example, implementing multi-factor authentication (MFA) and basic vendor review processes are essential steps. Compliance frameworks give security and non-security professionals a clear starting point. If you’re a startup founder with limited security experience, these frameworks guide you on essential practices, especially if you aim to sell to large enterprises.

This approach doesn’t mean stopping at compliance, but it ensures you have a strong foundation compared to ten years ago when such practices were less common.

Ayush: Some people argue that compliance doesn’t equal security or risk management. They say compliance is just ticking boxes, while security is about real protection. Why do you think this notion exists? Is it poor execution?

Kevin: Partly, it’s because the auditors aren’t always engineers; they’re often accountants following rules, making the process very black and white. Additionally, compliance standards like SOC 2 may not cover all security aspects, such as newer practices like passwordless authentication, which can enhance security but aren’t always included in compliance checks.

High-profile breaches involving companies with SOC 2 reports also fuel this perception. People think those reports were flawed, but without SOC 2, those companies would likely be in worse shape. Security isn’t usually the primary focus of businesses; they need to balance security with making money and serving users.

Overinvesting in security can hinder business operations. Compliance frameworks like SOC 2 and PCI provide necessary baselines. Without them, we’d face much greater risks, like handling credit cards irresponsibly. It’s similar to driving licenses—they don’t make you a perfect driver, but they ensure a basic level of competence. Compliance sets a necessary baseline for security.

Ayush: For mid-market companies starting with a GRC program, what are the four or five essential areas to focus on?

Kevin: 

• Start with third-party risk management (TPRM). Early-stage startups often rely on many third-party tools rather than building everything in-house. You can’t always do full reviews of all vendors, but at least list all the vendors you’re using.
• Knowing your vendors is crucial. If a vendor is breached and you didn’t even know your team used them, you’re in big trouble. 
• Documenting all tools and vendors from the beginning—like Gmail, GCP, Salesforce—will save you headaches later on.

Ayush: Where should accountability lie in small to medium-sized companies for assessing and onboarding vendors?

Kevin: Early on, security is very engineering-oriented. Your CTO or a senior engineering leader should take the lead since they understand how data flows and how tools integrate with your app. They typically know the tech stack and can decide which vendors are safe to use. The CTO often becomes the de facto security person, making it logical for them to set the example and handle these responsibilities.

Ayush: After third-party risk management, what’s the next important area to focus on?

Todd: Access management is crucial. Initially, everyone might have access to everything, but as your team grows, you should start restricting access. For example, if your CEO no longer writes code, they shouldn’t have AWS access. This not only enhances security but also saves money on SaaS subscriptions. Avoid shared accounts or, if necessary, use a password manager like 1Password to manage shared credentials. It’s best to give everyone individual accounts to prevent access issues and miscommunications.

Another key area is vulnerability management. For small companies, regularly updating JavaScript dependencies can prevent technical debt from piling up. Tools like GitHub’s Dependabot can notify you of necessary updates, helping you maintain security without major disruptions.

Lastly, utilize your cloud provider’s basic security tools. For instance, Azure’s Security Center can highlight simple fixes like closing open RDP ports. These built-in checks are often straightforward and cost-effective, helping maintain security without the need for extensive expertise.

Ayush: For mid-market companies without a risk management program, where should they start, and what pitfalls should they avoid?

Kevin: Start by focusing on your company’s mission and identifying risks that could disrupt it. For instance, if your mission is to sell software and make money, think about what could prevent that—like not delivering features customers want or choosing an unreliable cloud provider. You don’t need to be a security expert to identify these risks.

Avoid going too deep too soon. For example, lengthy tabletop exercises on hypothetical scenarios can be overkill. Instead, consider practical risks, like potential breaches and their impact. Small companies might not recover from a breach as easily as large ones.

Rather than using complex frameworks, think about your specific risks. What could disrupt your mission? For example, if your business handles healthcare data, a breach exposing PHI could be devastating. To mitigate such risks, consider basic controls or cyber insurance.

Ultimately, understanding your business and its vulnerabilities is key. Focus on practical steps to protect your mission rather than overcomplicating the process.