GitPrime is Renaming to Pluralsight Flow Learn more

Surviving your first security audit

Perspectives in Engineering

Surviving your first security audit

software engineering management

Security audits with a third-party are a lot like dates: they get easier as you get comfortable with each other.

But anticipating that first-ever security audit can cause a lot of sweaty palms and lost sleep. We understand that fear of the unknown. After all, we’ve been there ourselves.

That’s why we sat down with Todd Tidwell, our Senior VP of Engineering, to find out what you can expect from your first security audit with a third party. Here’s what he has to say about the process, from start to finish and beyond.

How do we know it’s time for our first security audit?

The manual for starting a company (you did get the manual, right?) doesn’t tell you when you’re ready for your first audit, or when you need one.

And the truth is, there’s no hard and fast rule. But Todd offers some guidelines.

“Conduct a security audit when you feel that you’ve got an architecture you can bring customers onto,” he says.“ Once you have customers, you have real data, and there’s no going back.”

“The moment your product is accessible, it becomes a target – especially if it generates any press or attention.”

Start considering an audit when you have people’s financial information in your hands. Or, if your software is not taking on a lot of money, get started when you begin receiving their personal information.

A first audit makes a lot of sense right after your official public launch. The moment your product is accessible, it becomes a target—especially if it generates any press or attention. That timing is particularly beneficial, because any security audit conducted before you finalize your architecture is a potential waste of your resources.

Okay, it’s time for a third-party audit. But how do we find a good auditor?

The first step in finding a reputable and thorough third party is to ask people you trust for recommendations. If you know anyone who has launched their own software company, or worked for a startup, they’ve already gone through the audit process and have seen how well it worked (or didn’t).

Once you have some recommendations, reach out to the third parties and ask them for references. Then, actually call the references.

“I know that, as engineers, we don’t like to call people,” Todd says, “but make the phone call, talk to a complete stranger, and get some feedback.”

Yes, you can expect positive feedback. Why else would the third party offer you that reference? But most people will gladly give you an honest assessment of what went well, as well as what could have gone better.

Once you settle on a third party, have a conversation about how you can help your audit succeed. Todd suggests asking your auditor: What should we expect? What can we do to prepare? and What can we do to make this audit go smoothly?

“They’re probably going to answer the same way,” he says. “And that is, ‘Be honest with us.’”

Ask “What should we expect? What can we do to prepare? What can we do to make this audit go smoothly?”

What does the audit process like?

Everything up to now is just the groundwork. Actually facing down an audit is where our imaginations run away with us. We might expect a third-party auditor to drop in like a special ops team, tear apart our infrastructure, and leave behind nothing but a scathing report on the boss’s desk.

What they’re really going to do is quite different. “They’re going to come in and talk to everybody,” Todd assures us. “They’re going to do the scans, and they’re going to work to understand every aspect of your system. As they go through the audit, they’re going to ask you questions, point things out, and give you a chance to repair them.”

The trick here is understanding that the audit doesn’t point out what you’ve done wrong. Instead, it points out what you can do better. No one should get fired from an audit (barring extreme neglect or malicious intent). Instead, the process can reward everyone in your company for participating in the audit and working to solve the remaining holes.

Once we survive the process, what results can we expect from our audit?

For starters, there’s your deliverable. That should be written documentation of what exact issues the auditors found in your system, their recommendations for addressing them, and their suggestions for improving your processes.

This documentation gives you the ability to remediate every problem, actual or potential, that surfaced in the audit. You will get the assurance of knowing that your system is secure. And this peace of mind extends to your customers, as well.

“You can stick the vendor’s badge on your website to show you have been audited,” Todd says. “When customers ask about security, you’ve got third-party confirmation to show them.”

“You don’t have to scurry around to invent answers. No jazz hands. You should never be doing jazz hands on security.”

Once you’ve patched the problems, that’s great. Remedying those specific problems is a critical step. But it is not the most impactful one. If you take the audit to heart, it offers you a perfect opportunity to protect your company for the future.

How can we use the audit experience to benefit our company going forward?

Quality third-party auditors will look far deeper than your technical operations. They will also analyze your culture and your day-to-day operations. And the stuff they find in these areas is bound to surprise engineers more than anything they find in the software itself.

“Establishing security procedures is most important while you’re still small. If you develop healthy processes at that stage, they become part of your culture, and stay that way as you scale.”

The everyday operations are the responsibility of everyone on your staff. So by making best practices standard practice, you shift the culture for every employee—now, and in the future.

That goes for every aspect of your operations, from utilizing proactive monitoring software to formalizing your procedures on a wiki, from crafting a protocol for incident handling to ensuring proper off-boarding for departing employees. And it’s not just for your technical staff—ensure that your customer service employees and other non-technical staff practice security, too.

Then when new people come on board, these practices will already be cultural. Background noise. Second nature. They will be the way things are done at your company.

Of course, as your technology changes and your company grows, you will need to undergo more security audits. But your second audit should not be difficult if you integrate the first audit into your culture. Your third security audit will be almost comfortable.

As your company grows, your third-party auditor is an invaluable partner. After all, if security audits are like relationships, your partner will be there to support you and encourage you as you become your best possible self.