How to Answer Due Diligence and Security Assessment Questionnaires

Due Diligence Questionnaires (DDQs) and Security Assessment Questionnaires (SAQs) are sets of questions that organizations use to assess a vendor's security posture. If you're a technology vendor, chances are you've filled out one or two (or 50...) of these and know the surprising amount of time and effort required.

Answering DDQs and SAQs can be daunting, especially for small or medium companies without the dedicated staff and internal expertise.

But it doesn't have to be!

Read on to learn how to approach even the most challenging InfoSec questions and complete your DDQs and SAQs with confidence.

What Are DDQs and SAQs?

DDQs and SAQs are technical questionnaires issued by organizations to prospective and current vendors typically during the pre-sale cycle or as part of routine compliance. These usually take the form of an Excel or Word document filled with dozens or hundreds of technical questions from the organization's Information Security team. Some examples include:

Do you have a password complexity policy? If so, are passwords required to be changed every 90 days?

What access control systems are in use that restrict access based on user privileges?

Is access control between office space, shipping and receiving controlled with security guards, CCTV or proximity reader/access control system?

The primary purpose of these questionnaires is to assess a vendor's cybersecurity maturity. With data breaches on the rise, organizations are under increased scrutiny to ensure that customer data is kept safe, including by any vendors they may use.

And it's no surprise - a large portion of data breaches are due to under-secured vendors.

Managing vendor security is a challenging problem. Other than performing a full audit, DDQs and SAQs are one of the only windows an organization has into the security posture of their vendors.

Also, compliance programs such as SSAE 16/18 (SOC2), ISO 27001, PCI-DSS, and others typically require organizations to have a vendor assessment program and maintain due diligence on all vendors. DDQs and SAQs are a common mechanism to achieve this.

Organizations and vendors are increasingly turning to standardized questionnaires such as SIG (opens new window) from Shared Assessments or CAIQ (opens new window) from the Cloud Security Alliance to ease the burden of managing SAQs, and while these make answer reuse much easier, many organizations still prefer to author their own.

DDQ and SAQ Answers That Delight InfoSec

Alright, maybe delight is a bit optimistic. InfoSec folks are like poker players - stoic even if they're smiling on the inside. At the end of the day, they're here to make sure that new vendors don't put their organization's crown jewels at risk.

But these questionnaires can be more than security gates. We like to think of them as another chance at marketing. Just as we expect variance features between vendors provide, there will be variance in security maturity between vendors.

And security is often less negotiable than features.

So having well-developed answers that address the question's true concern, framed for Information Security can be a real differentiator. It's also an opportunity to show off all the great technology underlying your product!

With that in mind, let's go over the strategy we recommend for answering DDQs and SAQs.

Yes Always Wins

Answering "yes" is always preferred. It feels great to say "Of course we do that!" and is the easiest way to remove potential InfoSec blockers.

(When we say "yes" we mean the organization's desired answer)

Many of your SAQ and DDQ answers will be an obvious yes. Great, that was easy, next!

But what if it's not an obvious yes? The first thing to do is consider question intent:

  1. Why did the organization ask this?
  2. What are they guarding against?

We have a favorite example that we see often, which always invokes gritting teeth:

Do you perform daily, weekly, and monthly backups, including incremental backups?

Here at RFPHead, the answer is no - in fact, we don't do any traditional backups at all, but that doesn't mean our data isn't safe and highly durable - we keep it in S3 with versioning enabled which famously has 11 "9s" of durability. This exceeds any durability we would likely achieve if we did our own daily, weekly, and monthly backups.

For this question the intent is obvious: it's likely that the organization doesn't care how we do backups, just that we have them, test them, and can recover data if things go wrong. With this in mind, we have no problem answering yes to this question, highlighting our approach and data durability in the comment.

Sidebar: the reason we have a strong opinion about this type of question is that it implies a specific technical solution instead of asking for what matters. A much better question would be

What is your expected data durability, and what are your Recovery Point Objectives (RPOs) and Recovery Time Objectives (RTOs) in case of data loss or corruption?

When Yes Isn't Possible

Sometimes, answering yes is not possible (or practical). That's OK, there are plenty of acceptable reasons why that might be the case.

A few reasons you might not be able to say yes:

  1. The question assumes a specific technical solution
  2. The question is about a system or topic that doesn't apply to your solution
  3. The question asks about details that the organization doesn't need to worry about
  4. The ask is not practical at your scale

Let's go over each of these in detail.

An SAQ Question Assumes a Specific Technical Solution

The backup question above is one example of this - the organization assuming that you're solving some specific problem a certain way.

Another, less obvious example is:

Are controls in place to prevent sensitive data from being sent via email?

The initial reaction to this question is usually to ask whether any tools or software are in place to prevent this, which is seldom the case. A common alternative is to have a policy control in place, such as a clause in the vendor's employee Acceptable Use Policy to prohibit sending sensitive data via email.

Yes, [vendor] has Acceptable Use policy controls in place prohibiting sensitive data from being sent via email.

While not as strong as a technical control, this approach is handy for smaller vendors and cases where it's just not practical to have a technical control. A control doesn't have to be perfect to be useful, and a partial solution is better than no solution.

An SAQ Question About a System or Topic That Doesn't Apply

Examples of this are questions about a vendor's physical office security when the vendor is fully remote or cloud-based.

Are physical security and environmental controls in the office buildings?

Or questions about PCI-DSS and credit card security for products that never come in contact with credit card PANs.

What controls are in place to protect/mask payment card numbers?

And if your technology happens to be serverless, many questions begin to fall into this category

Does your company have a formal server configuration management and hardening process?

In these cases, we find it best to indicate Not Applicable and explain why. For example: "N/A - [company] is fully remote and does not have central offices"

An SAQ Question about Details That the Organization Doesn't Need to Worry About

This is very common with managed services or SaaS offerings. For example:

What OS, Database, and Storage are required

We frequently see these because an organization will reuse the same SAQ for off the shelf applications as well as managed services. The intent of this question is for an organization to assess whether they already support the required technologies, but in a managed service the organization will not have to worry about installation, upgrades, patching and administration.

A good answer here is something along the lines of "N/A - [product] is a managed service and [vendor] will perform all installation, upgrade, patching, and administration tasks to meet or exceed our contract"

An SAQ Ask That Is Not Practical at Your Scale

This case is the trickiest - the ask, and the intention behind it is valid, but it's not practical for your business to do. For example, questions about compliance programs (SOC2, PCI, ISO) can be tricky for startups as they take time and money to achieve.

Another example of this is a question about the handling of sensitive information like Personally Identifiable Information (PII), requiring high encryption standards, auditing, separation of duties, and more. Many organizations are required by their own (or external) compliance to ensure PII is always kept secure.

If you've contemplated these questions, including their underlying intent, but still don't have a robust answer, consider one of these two paths:

  1. Can you offer a solution that shifts the onus onto the organization? In the case of PII data, could the organization hash or encrypt the data before transferring it to you and decrypt it once it's back on the organization's side? Such solutions will be highly dependent on your product and implementation but do offer a path to explore.
  2. Can you commit to achieving this subject to a signed contract? This can work well for required compliance programs. An answer such as "Will be in place 6 months following contract start" often satisfies the requirement. Of course, you'll need to account for the additional scope in the contract price.

Sometimes It's Just Not Possible, for Now

Finally, sometimes it's just not possible to meet a certain request without putting your business at undue risk. If you've considered the intent, explored all the options, and offered all the alternatives without luck, consider whether the timing is right.

We've seen this in cases where startups go after big government contracts or highly regulated industries which can be notoriously unyielding. It's often not in the startup's best interest to redirect substantial resources to chase compliance and regulatory technicalities, especially if the value doesn't translate to other customers. However, consider adding such requests to your product roadmap as many of these technicalities can provide a great differentiator.

How RFPHead Can Help

Creating well-developed answers to DDQs and SAQs takes time, consideration, and practice. RFPHead (opens new window) helps you reuse these answers by storing them in a knowledge base so you can find them the next time. Use RFPHead to import your previously completed DDQs and SAQs, extract and index the answers, and reuse them on future questionnaires.

At RFPHead (opens new window) we've been on both sides of thousands of DDQs and SAQs for organizations and vendors from startups to governments. If you're looking for additional support with your due diligence, security assurance or audit process, please don't hesitate to reach out to us.