SOC 2 compliance for startups and first-timers (part 4)

How to operate and improve your compliance program after a first SOC 2 audit

If you’re reading this while your customers are reviewing that first SOC 2 report, then congratulations. You’re now getting maximum credit for good security practices! 

Celebrate quickly, though, because the work continues. Especially if you’ve achieved SOC 2 compliance sooner than your competitors, make sure every prospective customer in the market knows there is a SOC 2-compliant option now. Position yourself as the mature competitor with a serious security program. Equip your sales and support teams to field easy questions about SOC 2 compliance and escalate hard ones to control owners.

Use your newly attested maturity to target larger, more conservative customers. Now is the time to get back in touch with anyone who deferred earlier, whether based on genuine security concerns or merely your lack of SOC 2 report.

And make sure your website has a security page that speaks to CIOs, Risk & Compliance, and Security teams. It should tout your SOC 2 compliance and any other bona fides you can offer.

Accept, too, that the day your first audit period ended, your next audit period began. With a company still growing and changing, you would be right to wonder: How do you evolve your SOC 2 compliance program without creating gaps in your controls or risking exceptions during your next audit?

Substrate: The Right Way to AWS
Substrate is a CLI tool that helps teams build and operate secure, compliant, isolated AWS infrastructure. From developers who have been there.

Step 1: Make the SOC 2 compliance program more efficient

Eventually, if not immediately, others in your market will also be SOC 2 compliant, yet your compliance program can still be a competitive advantage by being more efficient than theirs.

A first audit will naturally require more effort than any future audit, even if you don’t change anything, just through practice and familiarity. Still, you will no doubt notice things you can improve. Focus especially on reducing or removing the risk of any repeat exceptions.

Commit engineering time to building tools, especially if you had any exceptions or only avoided an exception through sheer luck:

  • Automate population sampling. It’s often frustratingly difficult to enumerate a population. Process changes and supporting automation can often take the uncertainty and manual labor out of this process.
  • Automate evidence gathering. For sufficiently complex processes, showing evidence that a control operated effectively 25 times may require hundreds of screenshots. Perhaps there’s an opportunity to automate reporting on the samples your auditors select.
  • Enforce a control through technology. Especially when population sampling and evidence gathering are tedious, try to enforce the control so you can demonstrate enforcement as evidence instead of going through population sampling. The classic example here is enforcing pre-merge code review and testing.
  • Polish up something you live-coded during your last audit. Turn the commands you ran in an ad hoc demonstration to your auditors into a properly maintained tool, standing at the ready for your next audit. Expect to be asked for the source code for tools like this, since it will no longer be clear what they’re doing when abstracted behind a command name or URL.

You may also want to change control ownership between audits. Two controls with different owners and similar evidence should probably be consolidated under one owner. Likewise two controls with the same owner but drastically different evidence might be an opportunity to distribute control ownership, aligning even more folks at your company with your compliance program.

Step 2: Change SOC 2 controls with the next audit in mind

You can change your SOC 2 controls any time you want. You’re in charge, you own your controls. All you have to do is ensure you have continuous coverage of every SOC 2 criteria on every day of every audit period.

Note that it’s the criteria that must be continuously covered, not your controls. There are several strategies you can use to provide continuous coverage of the criteria when changing your controls.

Suppose you change your control that meets criteria CC6.6 halfway through an audit period. When it comes time for your next audit, you’ll need to provide evidence that the old control was operating effectively until the date the new control began operating, as well as evidence that the new control operated effectively ever since. If you’re able to make the effective date of the new control the first day of your audit period, then you can get away with only auditing the new control.

It can feel risky to go into an audit with only an untested new control covering one of the criteria. In such situations, the right move may be to operate both the new and the old controls for a full audit period. If the new control malfunctions or you can’t show evidence that satisfies your auditor, you can always fall back to the old control to avoid exceptions in their report.

Step 3: Review what’s changed since the last SOC 2 audit

If your company’s doing about the same things for about the same customers with about the same employees in six months (or one year), and you received an unqualified opinion with no exceptions, expect your next audit to be very boring.

Before you let yourself off the hook, though, make an honest assessment of whether you got lucky during your first audit. Would there have been any exceptions if different samples were chosen from some population? If so, there’s no time to lose on improving that control. Did any controls take clever live-coding or unexpected evidence? If so, can you make changes either to your control or how you provide evidence to make it more robust?

Even if your audit required no luck and felt very efficient, when you make big architectural or organizational changes, you need to ensure your controls remain effective and auditable. Growing headcount, for example, may render previously acceptable controls too cumbersome. Talk to your auditor about what’s changed, and get their advice on where to focus your effort.

Do you need a SOC 3 report?

SOC 2 reports contain lots of details and are intended to be protected by an NDA. Sometimes the back-and-forth required to get an NDA in place is too costly to be worthwhile for a small potential customer. However, smaller and smaller companies are becoming SOC 2 compliant and asking their vendors for NDAs and SOC 2 reports. 

The solution here is a SOC 3 report. These reports elide the details that motivate folks to put their SOC 2 reports behind an NDA. They’re specifically designed to be posted publicly. For example, AWS links to their SOC 3 report on their main SOC information page.

A SOC 3 report will cost extra, so wait until managing NDAs and SOC 2 distribution becomes burdensome enough to justify the cost for your auditor to deliver both a SOC 2 and a SOC 3 report.

Why European customers ask for ISO 27001 

The SOC 2 criteria come from the American Institute of Certified Public Accountants. Internationally, the ISO 27001 standard is what most customers will expect. SOC 2 will be a fine substitute for many. Eventually, though, you may find enough customers who prefer ISO 27001 to justify adding it to your compliance program.

SOC 2 and ISO 27001 are very similar. Most auditors will be able to audit both simultaneously. Adding ISO 27001 on top of SOC 2 results in relatively few additional criteria and controls.

Recapping your startup’s path to SOC 2 compliance

This series has taken you through SOC 2 compliance from before the beginning through to your second audit and beyond.

  1. How to delay an audit without sabotaging your business
  2. Reading the criteria, writing controls, and preparing for your first SOC 2 audit
  3. What to know going into your first SOC 2 audit
  4. How to operate and improve your compliance program after a first SOC 2 audit (you are here)

No matter where you are on your SOC 2 compliance journey — filling out infosec questionnaires before you commit to SOC 2 or having your fourth combined SOC 2 and ISO 27001 audit — good security practices are the foundation of your customers’ trust in you. Compliance is how you get credit for good security.

Check out Substrate for managing AWS accounts and IAM roles to get a head start on meeting the SOC 2 criteria concerning access control, change management, and reliability.