What is a security questionnaire?
- Term
- Security questionnaire
- Meaning
- A security questionnaire is a set of written questions you send a vendor to learn how it protects your data and systems, before signing and during the contract.
A security questionnaire is a set of written questions a company sends a vendor to learn how the vendor protects the company’s data and systems. It’s a business term, and the rules below don’t define it. This page is about sending one to a vendor that works in your company’s systems.
Why do companies send one?
Some rules require companies to check a vendor before and during the work. The FTC Safeguards Rule requires covered financial institutions to take reasonable steps to select service providers capable of appropriate safeguards (16 CFR 314.4(f)(1)). It also requires periodic assessment of providers based on their risk (314.4(f)(3)). The NIST Cybersecurity Framework (CSF) 2.0 describes the same steps for any organization. It calls for due diligence before a supplier relationship starts (GV.SC-06) and monitoring of supplier risk while it lasts (GV.SC-07). A questionnaire is one way to do this in writing. Neither source requires that form. The broader duty is covered in What is vendor oversight?
Are there standard forms?
Yes, for some vendors. The Cloud Security Alliance’s CAIQ is a set of yes/no questions that document the security controls in a cloud provider’s service. It’s now built into the alliance’s Cloud Controls Matrix, version 4.1. Its questions are about the provider’s own service, so they don’t name the accounts a vendor’s staff use in your systems. For those, you’ll need your own questions, like the ones below.
Where does a SOC 2 report fit?
Some vendors answer with a SOC 2 report instead of a questionnaire. The AICPA describes it as a CPA’s examination of how a service organization describes its system, and of the controls in it. Customers often ask for one, the AICPA notes, and the report covers the vendor’s own system. If the vendor’s people work in your accounts, you may still need to ask how those accounts are handled.
What should the account questions ask?
For accounts in your systems, ask questions the vendor has to answer in its own words:
- Who on your team has access, and why does each person need it?
- Which usernames and passwords, if any, are shared by several people?
- Where is the list of who holds access to each system, and who keeps it current?
- When someone leaves or changes roles, who removes their access, and by when?
- Where is the record of who signed in and when?
- Which parts of the work, if any, go to another firm or person, and which accounts do they use?
Questions get clearer answers when they name the account, as in “who on your team uses the user account we created for you”. Sample wording for 10 questions is in How to write the account questions in a vendor security questionnaire.
How do you read the answers?
A column of “yes” answers doesn’t help you choose a vendor or check one later. Ask for a note on each answer: who checks it, how often, and against what record. If a vendor says a login is shared, ask four things. Which account is it? Who knows the password? How does it change when people leave? How is each use tied to a person? If you handed over that login yourself, you can change how the vendor gets in, for example by giving each person their own user account. The ways to hand over access are compared in Letting a vendor use your company’s accounts.
Frequently asked questions
Does any US law require a security questionnaire?
Not the form itself. Rules such as the FTC Safeguards Rule, for financial institutions under the FTC, require selecting capable vendors and assessing them periodically. A questionnaire is one common way to do that in writing.
What should the account questions ask?
Ask who has access and why, which logins are shared, and where the access list is kept. Then ask how access ends when people leave, where sign-ins are recorded, and who else does the work.
Is a vendor that shares a login an automatic fail?
Look at how the shared login is managed rather than whether one exists. If you handed over that login, you can change how the vendor gets in, for example by giving each person their own user account.
Can a vendor send its SOC 2 report instead?
It can answer general questions about the vendor's controls. It describes the vendor's own system and controls, so you may still need to ask how your accounts are handled.
How Junify handles this
- Doing this by hand
- You keep a list of which vendor staff use which of your accounts, shut off access every time a contract ends or a person changes, and keep checking how the vendor uses them.
- With Junify
- With Junify, the vendor's staff use your company's accounts without getting the password. For those accounts, your own records show who used each one, person by person, so you don't have to rely on the vendor's answer. When the contract ends, you remove their access in Junify.
Sources
- 16 CFR Part 314, Standards for Safeguarding Customer Information (FTC Safeguards Rule), eCFR
- NIST CSWP 29, The NIST Cybersecurity Framework (CSF) 2.0 (February 26, 2024)
- Cloud Security Alliance, STAR Level 1: Security Questionnaire (CAIQ v4)
- Cloud Security Alliance, Cloud Controls Matrix and CAIQ
- AICPA, SOC 2 Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy (guide, updated as of October 15, 2022)
-
Checklist for taking back access when a vendor contract ends
Work in this order. List the vendor's accounts, disable its users, change shared passwords, check the login records, and get written confirmation of deletion.
-
How to write the account questions in a vendor security questionnaire
Name the accounts you gave the vendor and ask who checks each answer, how often and against what record. Tie each question to a rule and check the answers.
-
What your vendor contract should say about accounts
Write four account clauses: who may use your accounts, no sharing beyond named staff, records and incident notice, and shutdown and deletion at the end.