In episode 14 of Risk Grustlers, we sit down with Drew Danner, Managing Director at BD Emerson, who brings a refreshing and no-nonsense perspective to the world of governance, risk, and compliance (GRC). With ten years of army experience and a solid reputation in cybersecurity, Drew shares his philosophy of “keeping it stupid and simple” when tackling complex security challenges.
Drew makes a compelling case for bridging the gap between security and compliance, showing us that they’re not opposing forces but two sides of the same coin. His practical approach is built on hard work, attention to detail, and a belief in the power of small, consistent actions to drive meaningful change.
From breaking into GRC as a newcomer to handling intimidating frameworks like ISO 27001, Drew offers actionable advice for both beginners and seasoned professionals. Whether you’re struggling with the basics or looking to refine your program, this conversation will leave you inspired and ready to act.
Watch the full episode here
Let’s explore some highlights from this value-packed episode.
Aayush: Why don’t you tell us a bit about your journey into risk management? How did it all start?
Drew: Honestly, my career in risk management started by accident—a happy series of accidents, actually.
I began in the army, serving in the infantry, but an injury led me to explore other career paths. A smart leader suggested I get a degree, so I went for a bachelor’s in math and computer science, then a master’s in math, and eventually a doctorate in business. The doctorate was less about math and more about figuring out how to make knowledge valuable in the real world.
After leading systems teams in the army for ten years, I transitioned to the intelligence community for two years, then took on digital transformation projects for large public companies. At one point, I was responsible for a $1 billion e-commerce channel, overseeing not just GRC or security, but the technology as a whole. Eventually, a lawyer convinced me that security and privacy could form the foundation of a great company. Fast forward five years, and here we are with BD Emerson—a law firm, cybersecurity consulting firm, and CPA audit firm all rolled into one.
Aayush: One hot topic in the industry is the debate about compliance vs. security. What’s your take on that?
Drew: I think the debate is ridiculous. The idea that compliance isn’t security—or vice versa—comes from a misunderstanding of both. Compliance provides the left and right boundaries for security. It defines the requirements. Security, on the other hand, is the operational execution of those requirements.
Let me give you an example: In the government, we use secure facilities called SCIFs (Sensitive Compartmented Information Facilities) to keep signals out. Why don’t businesses do the same? Because they’re not required to. Compliance creates those requirements. Without it, there’s no framework to guide security efforts.
Take Massachusetts’ WISP law, for instance. It mandates written information security plans for businesses over a certain size. Even companies that don’t care much about security—like staffing agencies—are required to comply. This drives them to hire security experts and integrate security into their operations. Compliance isn’t separate from security—it’s the foundation for it.
Also read: How do security and compliance differ?
Aayush: Certifications like CISSP are often seen as the gold standard in security. What’s your view on them?
Drew: Certifications are just pieces of paper. Don’t get me wrong—they serve a purpose, but they’re not always the best measure of competence. I got my CISSP because it was required for my role in the government. I had a month to prepare, crammed for the test, and passed. Barely, but I passed!
What matters more is real-world experience. Certifications might open doors, but they don’t necessarily make you effective at solving problems or communicating with stakeholders.
Aayush: You keep talking about “the little things.” Why are they so important?
Drew: Oh, the little things are the foundation of everything in GRC. Let me break it down.
When companies are in their early stages, compliance often feels like a “nice-to-have.” Founders are laser-focused on growth, which makes sense, but they often overlook the commitments they’re making in their contracts. For example, they might sign a deal in Europe and agree to a data processing agreement (DPA) or a data security schedule (DSS) without fully understanding the additional requirements those documents impose.
At first, they think, “What are the odds anyone will check?” But as the business grows, those commitments become liabilities. Suddenly, a customer comes back a year later asking for proof, and the company’s scrambling to meet obligations they didn’t even remember agreeing to.
Now, here’s where the little things come in. If you build good habits early—like documenting your commitments, reviewing contracts for compliance impacts, and integrating those commitments into your operations—you avoid that last-minute panic.
It’s not glamorous work, but it’s transformational.
Aayush: What do you think is the minimum viable team for a small to mid-size company just starting to create a good, mature GRC program?
Drew: We’ve worked with clients who hired us as their very first employee, so we’ve seen a lot of different approaches. I remember one case with a VC-backed startup. They knew their target customers, which included banks and other financial institutions, would only buy their product if it was already compliant with SOC 2, or even above that. So, even though they were just getting started and had about $5 to $6 million in funding to build their product, they prioritized security from the very beginning.
Their first hires were part of their security team because they knew they had to meet very specific security requirements to even get into the financial sector. Banks, VCs, and other financial entities have stricter security standards because they deal with sensitive data, and the reviews can be a lot more demanding. They knew that by addressing security first, they’d be in a better position to attract those clients down the line.
Aayush: And if they’re not bringing in consultants early on, what do they usually do?
Drew: When a company doesn’t bring in consultants like us right away, they typically try to find someone internal who can own security and compliance. They might look for a unicorn—someone who’s a software engineer with experience in security. The issue is, those kinds of people are rare and expensive. But if they can find someone like that, they might overpay just to secure that expertise early on.
When a company reaches around 50 employees, that’s when things start to shift. By that point, their revenue is growing, and they’ve probably started selling to larger clients. That means there are going to be more security checkpoints in the sales process. At that point, they may start bringing in external consultants because they’re getting more security requests from customers or partners.
Also read: How Scrut Automation’s expert guidance makes a difference
Aayush: How do you approach tailoring controls to meet specific commitments a company has made? Can you share an example of what that looks like in practice?
Drew: Let’s say you’ve promised to delete customer data when they leave. That’s a standard practice, right? But then you sign a contract with a customer who says, “Actually, for legal reasons, we need you to keep our data for two years after we leave.” That’s not a requirement in SOC 2 or ISO; it’s a contractual commitment.
The problem is, if you don’t account for that promise in your controls, it’s likely to get lost in the shuffle. You’ll forget about it until the customer comes back asking for proof, and by then, you’re in damage control mode.
What we do is ensure those commitments are integrated into your system. For this scenario, we’d create a specific policy or control around data retention tied directly to that contract. It’s not just about compliance—it’s about trust. If you say you’ll do something, your systems and processes need to back that up. That’s how we help companies build credibility and avoid those “uh-oh” moments.
Also read: ISO 42001 Vs ISO 27001: What is the difference?
Aayush: How have security audits changed now that AI is everywhere?
Drew: It’s a big shift. So many SaaS and software companies are building AI into their products—whether through APIs like OpenAI or Anthropic—or using AI internally for tasks like automation. But with that comes new risks. A classic example? Employees uploading sensitive company documents to tools like ChatGPT through their personal accounts to save time. That’s a huge data leakage risk.
Now, audits are starting to reflect these challenges. Companies need controls to prevent unauthorized use of AI, and tools like Unbound Security have popped up to address exactly this issue. But more than tools, organizations need clear policies. A simple step? Create a document that outlines how employees can safely use AI—like “don’t put sensitive data into public AI systems” or “use our enterprise license to ensure security.” It’s all about setting boundaries while still enabling people to do their jobs effectively.
There are also emerging standards to guide this, like OWASP’s security recommendations for AI and ISO 42001, which is specifically for AI systems. On top of that, frameworks like NIST’s AI Risk Management Framework help build trust and security into AI operations.
At the end of the day, audits now focus on things like “least privilege” access—making sure only the right people can use AI tools and that sensitive data stays protected. And here’s the kicker: being upfront with customers about your AI usage can actually help your business. Transparency builds trust, and trust drives sales.
So, if you’re using AI, secure it, govern it, and be honest about it. That’s the new reality for security audits in the age of AI.
Aayush: What’s your advice for companies just starting their compliance journey?
Drew: Start small and scale thoughtfully. You don’t need a full-blown compliance program on day one, but you do need to build good habits. Begin by understanding your commitments. If you’ve signed a contract that includes a data processing agreement, read it carefully. Make sure you know what you’re agreeing to.
From there, leverage tools that make compliance manageable. Platforms like Scrut can give you a head start, and AI can help you break down complex standards. But don’t try to do it all yourself. As your company grows, the demands of compliance will outpace your ability to manage it solo. That’s when it’s time to bring in experts.
Most companies don’t hire a full-time GRC person until they’re nearing 100 employees. Until then, the key is to focus on incremental progress. Document your processes. Review your commitments. Make small, daily improvements. Those little things? They add up, and they’ll save you time, money, and headaches in the long run.
Also read: How small and medium businesses can allocate cybersecurity responsibility
