Blog Posts

What NOT to Say During a Security Audit of Your Startup

What NOT to Say During a Security Audit of Your Startup

Founders and CTOs often say or do terrible things in security audits. Over the last three years, I have personally played a role in over 100 vendor security audits as both the auditor and the audited. I’ve worked with 100s more startup founders and CTOs as they navigate through enterprise vendor security audits. Many of these were security audits of a startup trying to land a big sales deal with a potential Fortune 500 customer. Data protection is a top priority as enterprise and government organizations closely scrutinize all their vendors.

During a security audit, there are great, smart answers that you can give that show you as a vendor are on top of your game. On the other hand, there are no-good, terrible answers to say or write when you’re responding to a security audit.

6 Statements you should never make during vendor security audits

1. “My CTO (or some other person on our team) is pretty good with security and I know he does a bunch of stuff.”

Yes, it is absolutely a good thing to have someone on your team with security knowledge and experience. However, there are two significant problems with this common statement.

First off, if the person you are referring to is the most knowledgeable and is actually doing the security work for your company… why is that person not on the call? At this point, if I am the auditor, I will end the call and ask that we schedule another with the security person on hand.

The next issue here is that the business leaders who say this are outright admitting that they have no idea what things the security person is doing. That means they are not mandating security from the top down. They are not seeing reports on security operations. This is like telling the auditors that you don’t know and generally don’t care. If you aren’t aware of your own security procedures, that’s a sign that you need to start building a new cybersecurity program.

2. “We are in AWS and all of our email is in Google.”

This is the most common statement we hear. Allow me to translate this to what it means to a security professional: “I am completely naive and don’t know anything about securing my company or your data. I genuinely believe that because we are in the cloud, using industry-leading cloud applications and infrastructure, I can rest easy and not worry or even think about security.”

Let me clarify. Yes. Cloud-based services like Amazon Web Services (AWS), Asure, Microsoft 365, and Google all have world-class security programs to protect their customers and their data centers. But you can’t rely exclusively on their security to protect your data, your web application, or your customers’ data. On over 100 pen tests conducted last year on AWS-hosted web applications, our affiliate pen testers were able to take control of the application and download entire customer databases 40% of the time. AWS wasn’t at fault: it was always the fault of the startups that were tested.

Yes, it is critical that you work with secure web apps and hosting companies. However, it is just as critical that you implement proper secure coding, testing, access control, and auditing practices. At the very minimum. Without that, your web application is at an increased risk of a cyber attack. When you get asked about the security of your application by a security professional conducting an audit on your security posture and you spit out an answer like this, your risk profile goes through the roof. A poor cybersecurity posture can quickly damage relationships with existing customers or new sales.

3. “We are a startup and don’t have the time or money to deal with antiquated policies and procedures.”

I hear founders say this with surprising arrogance. Sort of like, “We are cool and move fast and creatively, so we are not a bogged-down, red-tape-induced slug like your organization.”

The auditor probably won’t find your attitude very amusing, but that is not the worst part. This statement demonstrates that your primary concern is running out of money and going out of business. From the auditor’s perspective that introduces another risk that may need to be focused on: What happens to users’ data if this startup goes belly up?

You have to make the time. You need to find some money. You can also access our list of free resources to secure your business. Even with free resources, you also have to be proactive and care about your security to use them effectively.

4. “We have some policy documents in a folder so I will dig them up and see if we have what you are looking for.”

Generally, when I hear this statement, this is how I interpret it: “We don’t have anything, but if you really need something we will pull a late-nighter and put something together using some templates from the internet. We don’t care much about security.”

If you actually are not lying, then you are at the very minimum saying that you are not aware of what policies you have. You don’t even know where they are stored. You are showing that you do not really care about them. That means nobody else in your company cares, which means these policies are not being followed and serve no functional purpose. They’re probably in desperate need of an update.

If you actually had policies and you actually cared about security and you actually followed them, then you would be able to respond to this question. Be ready for this question. You should have a reasonable and informative answer about your security policies. Maybe it sounds boring, but policies and procedures are foundational for your security.

5. “We do some internal pen testing on our application.”

This is usually a response to a question around penetration testing. When auditors ask you about pen tests, they are likely referring to an actual pen test conducted by an experienced and certified third-party pen tester.

There are three key concepts that are critical to a pen test being considered valid from an auditor’s perspective.

  • First: Is it a real pen test? Unfortunately, the term pen test is often misused referring to a vulnerability scan. They are not the same. Running a vulnerability scanning tool like Nessus on your application, although good practice, is not a penetration test. That is simply a scan that looks for known vulnerabilities.
  • Second: Is it a professional pen test? Pen testing is not the type of thing where you read a few blogs and then you are a qualified pen tester. It is a career, and there are people who are really good at it. They get this way by reading, studying, and, most importantly, practicing.
  • Third: Is it a third-party pen test? A pen test conducted by the same person or people who are building your software is very biased. Can you trust them to honestly disclose a major security vulnerability in the report they send to you, their prospective customer?

A third-party pen tester’s reputation and career depend on the credibility of their pen tests. A CEO’s career depends primarily on the company’s ability to close business and hit revenue targets. If your company can’t pass pen tests and a security audit, those are troubling signs you won’t be able to close deals with enterprise-level customers.

6. “We don’t store any confidential information.”

Now, if this is actually 100% true, then this may be a good answer. However, what we see over and over is people saying this, but then as we dig deeper, we realize that they store personally identifiable information, user habits, insinuated data, and data that is regulated by one or more privacy or security regulations.

When you say that you don’t store confidential or sensitive information as an answer (or excuse) for your lack of security and then the auditor figures out that you actually do, you are in a really bad spot. Basically, you are completely lying to try to get through this audit, you are not aware of the data your company stores or processes, or you are completely unaware of what is actually considered regulated or sensitive data. OR All OF THE ABOVE! Whatever the case, this attitude rapidly erodes trust and will likely kill a deal with any security- and privacy-conscious customer.

Conclusion

You should have better security policies and procedures than this.

In the end, you can’t act stupid or cavalier. You have to show that you and your employees are paying attention and care about security. CEOs, CTOs, and others in the executive team should know where the security policies are and have read all of them. You need to know what confidential information you are collecting.

If you’re in the middle of a security audit — now you know. Don’t say any of these six stupid statements.

Do your policies need an update?

Share