The timeline, the steps, and what’s involved for compliance

When planning for your compliance goals, you'll want to understand the timeline, steps, and actual activities before diving right in.

These three topics go hand-in-hand. We often hear audit firms and platforms claiming it will take you (insert unrealistic expectation) to achieve SOC 2. This article will help you understand how they work in practice.

The timeline

We spent 80 hours on our own SOC 2. That’s not including time spent on related activities that weren’t performed specifically for compliance, eg. Implementing our infrastructure security and employee performance review process. That 80 hours could theoretically be done in a week or two, but there are practical reasons it doesn’t work like that.

1. Compliance is never the top business priority. It often takes a back seat, which slows progress.

2. It touches lots of different business activities, often with multiple people and lead times involved.

3. The audits require back and forth. Even with our agile and collaborative audits to optimise the back and forth, it’s dependent on your team providing the right evidence and clarifications.

4. Your compliance implementation is the best opportunity to get things set up right. You may be able to box-tick for the sake of compliance, but a little extra time goes a long way for real business benefits, AND ensuring it will actually pass the audit.

We spent 80 hours over 3 months, after some initial planning and “starting” it 3 months earlier. The median timeframe we see for our clients is 3 months; ranging from 3 weeks to 18 months. Sure you can do it in a week if you don’t sleep, make it the top priority, and forgo the opportunity to get real benefits from it, but we don’t recommend that!

The steps

The below steps were traditionally performed sequentially. In modern compliance they are often all going on in parallel. That’s the purpose of our agile and collaborative audit process that gives more timely feedback, end-to-end guidance, and all stakeholders a clear view of progress. The steps involved are:
  • Planning: Which standards will you target? Which audit firm will you use? Will you use a compliance platform? What resources are required? What timeline will you target?
  • Readiness Assessment: You can use a compliance platform like Drata, or a free tool like our readiness assessment software, to see where you do and don’t comply with your chosen standards.
  • Implementation: You put in place the necessary activities to meet the compliance standards (ie. close any gaps), and ensure you can prove those to your auditor.
  • Evidence gathering: You collect and provide the evidence of those activities to your auditor to independently verify.
  • Audit: The auditor reviews and provides feedback, asks additional questions, and ultimately signs off on your compliance.
  • Reporting: The report (SOC 2) or certification (ISO 27001) is issued to share with your customers.
  • Maintenance: You manage your compliance activities in business-as-usual, until the next audit, or as part of a continuous audit process that follows.

There's more work initially achieving compliance, and it can then become much easier to maintain over time (if you set it up well, in a way that fits your company). 

What’s involved?

The activities covered for your compliance can vary greatly. That’s a good thing; although it can make it harder to understand compliance and what’s required, it means you can do things in a way that makes sense for your company with optionality of which activities you do and don’t want to perform. This is where some companies opt for the generic strategy to compliance - to keep it simpler and take out the guesswork.

Compliance activities include the following types:

Systematic controls (10-35%)

Systematically configured functions are tested with automation or screen shots. These include:
  • Infrastructure (eg. AWS): encryption, firewalls, system monitoring and logging.
  • Enterprise software (eg. Google Workspace): tracking your people, information assets, and enforcing MFA for logins.
  • Code repository: restricting access, enforcing peer reviews, and oversight of the code changes for software development.
  • Mobile device manager: enforced policies on user devices like operating system updates, anti-virus software, device firewalls and encryption, screen timeout.

Policies, procedures and plans (20-35%)

Documented responsibilities, business requirements and the design of processes and plans that support your compliance requirements.

Event-driven activities (15-30%)

When events occur, managing those events in accordance with defined policies, procedures and plans. For example, when new joiners are onboarded, conducting background checks, employment contracts, and security awareness training. This also includes when incidents occur, changes are released, vulnerabilities are identified, and assets are disposed of, to ensure they are managed effectively.

Periodic meetings and reviews (20-30%)

Board and management meetings, risk assessments and vendor governance reviews, are conducted periodically (quarterly, annually) to maintain oversight of the organisation. There’s also penetration tests, business continuity and disaster recovery exercises, and other periodic tests to check the compliance activities are effective.

Other ad-hoc items (~10%)

This category is here for completeness. There’s a few things that may not fall into the above, like having a documented architecture diagram, customer contracts or terms of service, and cyber insurance.
Some additional information in one line