Frequently asked questions by our clients working through the Drata Starter program
Why is the Drata Starter framework import failing?
In most cases we see, it's because controls have been de-scoped in your Drata instance that are required by the framework. The import window will flag which rows cause a failure that are linked to those controls that have been de-scoped. For these controls if they do not apply we request an explanation is added for each so we understand the reasons they do not apply; as the 83 controls in the Drata Starter framework are expected to apply for all companies.
What should I put as my audit period?
For Type 2 engagements, you will select an audit period that the SOC 2 report covers. We recommend this commences from the end of the last Type 2 period or the Type 1 report date; depending on which report was last issued. This provides continuous coverage for your enterprise customers and is the default expectation. The length of the period can be between 3-12 months; we typically recommend 6 months minimum to provide a greater period of coverage that enterprise favour. Annual recurring Type 2 reports becomes the norm after your first Type 2 report.
When does AssuranceLab start the audit?
If it's your first Drata Starter audit - ie. before we move into continuous audit - we will start the audit when you tell us you are ready. It's recommended to be 100% complete (at least 90%) on the Drata Starter framework, so we can complete the full audit in one go.
How long does the audit take?
We're working towards an SLA of completing your audit and reporting in a 2-4 week timeframe. This is dependent on whether you've completed all items, the quality of evidence provided, and your team providing timely responses to any audit queries we have. Our AI audit offering fast-tracks the audit results and provides greater insight to assist with clearer audit queries and marking off the controls. We maintain the same SLA timeframe based on the dependency on your team, but we recommend opting into AI audit if timing is critical.
What if some of the controls are not applicable or different in our context?
The intent of our Drata Starter framework is to focus on controls that should apply to all companies. We apply generic control descriptions that are flexible to various ways you might actually operate the controls. If you do come across controls you believe are not applicable, or that do not accurately reflect how you operate, it's best to add a note to the controls for our audit team. This is ideally an attached Word or TXT file with a brief explanation of the circumstances, with a screen shot or other supporting information where applicable. Attaching this will automatically mark the control as "Ready" in Drata for us to review.
What are examples of where the controls may vary?
A common example we see is there's no Board of Directors. The same type of governance and oversight is expected, but it may instead be performed by your Senior Management Team, or co-founders. We see clients have varying ways of defining incidents, the scope of third-party vendors they monitor, or how they assess and manage risks. These types of variances generally do not require adjusting the controls as the purpose of the control is still satisfied in each case.
Do I need to have performed all controls before a Type 1 report?
For a Type 1 report, there is some flexibility in the timing of when controls are conducted. This is particularly relevant for DR/BCP testing, and penetration testing that can be costly and time-consuming exercises. A Type 1 report can be achieved by proving you have plans in place for those, before they are actually conducted. For a BCP/DR test that should include proving its been scheduled, and for a penetration test an executed statement of work that shows the scope, timing and approach agreed with a third-party provider. Other common examples we see are with new joiner and exit checklists, new incident management tracking and employee performance reviews; where they may have new processes setup that haven't been conducted yet.
How do we address failing auto-tests?
It's best to investigate and resolve the cause of the failure in Drata that has guidance for each monitor. In some cases you may find the failure to be appropriate based on the context or nature of your environment. You can adjust the scope of the auto-tests to align to your reporting scope. For example, you may have databases that are public, without encryption, where they do not hold any sensitive data. These can be excluded from the tests with commentary added accordingly, in the Monitoring section of Drata. This may apply to databases, users access, employees, for whatever circumstances apply - please capture comments accordingly so we can understand why they're excluded and sign off the respective controls accordingly with reduced back and forth.
I use a third-party to manage my infrastructure. How does this impact the audit and the evidence I need to provide?
Our audit procedures typically only cover the controls you own or are involved in managing. Where you rely on a third-party to manage your infrastructure, like full service database-as-a-service platforms, we will reference those as sub-service organisation controls. There's no additional evidence required from you unless you play a part in managing controls.
I've added Privacy trust services criteria to my scope. How do I understand some of the terms used in Privacy?
The Privacy trust services criteria refers to specific terms that can be confusing the first time around. Here are some helpful definitions. When in doubt, reach out to your audit team for additional support.
- Data controller: An entity that (alone or jointly with others) determines the purposes for and the means by which personal data is processed. So, if your company/organisation decides ‘why’ and ‘how’ the personal data should be processed it is the data controller.
- Data processor: An entity that processes personal data at the direction of a data controller. In many cases, a service organization may process personal data for its business-to-business (B2B) customers (user entities), which in turn may function as data controllers. In other cases, a service organization may function as a data controller, depending on the facts and circumstances.
- Data subject: The individual about whom personal information is collected.
- Example:
A private company provides software to process healthcare data for patient assessments. Using the software, the company provides tracking and reporting to their healthcare provider customers.
The company’s sole purpose in processing healthcare data is to provide this service to the healthcare providers. The providers set the purpose – to process data for assessments and reporting. The company does not determine the purposes of the processing, it merely provides the processing service. This company is likely to be a processor. The healthcare provider is the data controller. The healthcare provider's patients are the data subjects.
How do I know which policies to prioritise finalising for the audit?
This varies based on which specific policies you document the procedures, requirements or topics in. The policies we typically reference for Drata Starter audits are:
- Access Control Policy
- Incident Management Policy
- Information Security Policy
- Risk Assessment Policy
- Vulnerable Management Policy
- Disaster Recovery Plan
- Change Management Policy
- Acceptable Use Policy
- Code of Conduct
- Network Security Policy
- Password Policy
- Data Classification, Handling, and Retention Policy
- Business Continuity Policy
- Vendor Management Policy
- Backup Policy
- Asset Management Policy