# Vendor Security Questionnaire

**Obfuscation Hub Toolkit — starter template (Release 0.1)**

> Adapt to your organization before use: adjust tiers, add industry-specific
> requirements, and have significant vendor decisions reviewed by the access
> owner and, where warranted, counsel. Educational template — not legal advice.

---

## How to use this questionnaire

Scrutiny should match access. Classify the vendor first, then send only the
applicable sections — a proportionate questionnaire gets honest, timely answers;
a 300-question wall gets copy-paste.

| Tier | Definition | Sections to send |
| --- | --- | --- |
| **T1 — Privileged** | Can administer your systems or access regulated/confidential data (MSPs, developers, payroll, EHR) | A–F |
| **T2 — Connected** | Holds company data or integrates via API, without admin rights (CRM, analytics, storage) | A–D |
| **T3 — Peripheral** | No meaningful system or data access (newsletter tool, swag vendor) | A only |

Record for every vendor: name, service, tier, business owner, data involved,
access granted, review date, decision (approve / approve with conditions /
reject), and next review date.

---

## Section A — Company and program basics (all tiers)

1. Describe your organization: years operating, headcount, and where our data
   would be stored and processed (regions/subprocessors).
2. Do you have a named individual accountable for information security? (Role, not name, is fine.)
3. Do you maintain written security policies reviewed within the last year?
4. Have you undergone any independent security assessment (SOC 2, ISO/IEC
   27001, penetration test) in the last 18 months? Provide the report or summary under NDA.
5. Have you experienced a security incident affecting customer data in the
   last 3 years? If yes: nature, impact, and changes made.
6. Do you carry cyber liability insurance? (Coverage level optional.)

## Section B — Identity and access (T1–T2)

7. Is multifactor authentication enforced for all staff access to systems that
   touch customer data or administration?
8. How is staff access to customer environments granted, reviewed, and removed?
   What is your deprovisioning timeframe on departure?
9. Will your staff use individually named accounts in OUR environment? (Shared
   accounts require written justification and our explicit acceptance.)
10. Can your access to our environment be scoped (least privilege, time-bound,
    IP-restricted)? Describe options.
11. Do you log and retain access to customer environments? Retention period?

## Section C — Data handling (T1–T2)

12. What data of ours will you collect, store, or process? Where, and encrypted
    how (at rest and in transit)?
13. What is your data retention and deletion practice at contract end? Will you
    certify deletion on request?
14. Which subprocessors will touch our data? How do you assess them?
15. How would you support us in meeting our own customer/regulatory
    obligations (e.g., breach notification timelines, data residency)?

## Section D — Incident response (T1–T2)

16. Do you have a documented incident response process? When was it last tested?
17. **Within what timeframe will you notify us of an incident affecting our
    data or our environment's access?** (We require a contractual commitment —
    commonly 24–72 hours; set your own.)
18. Who is our named security contact during an incident (role + channel)?

## Section E — For privileged vendors only (T1)

19. Describe controls on the workstations/tools your technicians use to access
    customer environments (endpoint protection, patching, encryption).
20. Is access to customer environments protected by MFA *at your side* with no
    exceptions? How is this verified?
21. Do you support or operate session recording / activity logging for
    administrative work in customer environments? Can we obtain logs on request?
22. How do you separate customers from one another in your tooling (RMM,
    credential vaults)? Has this separation been independently tested?
23. What happens to our credentials/keys held by you at offboarding of your
    staff, and at termination of our contract?

## Section F — Continuity (T1)

24. What are your recovery objectives for the service you provide us, and when
    did you last test them?
25. If you ceased operations, what is the plan for returning our data,
    credentials, and documentation?

---

## Reviewing answers — starter red flags

- MFA "available" rather than **enforced** (questions 7, 20)
- No committed incident notification window (question 17)
- Shared accounts presented as standard practice (question 9)
- "We have never had an incident" from a mature vendor with no assessment to
  show — absence of detection is not absence of incidents (questions 4, 5)
- Inability to name a security-accountable role (question 2)

A red flag is a conversation starter, not an automatic rejection — document the
compensating controls you agree on, and the named internal owner accepting the
residual risk.

---

*Source: Obfuscation Hub Toolkit. Align final wording with your contracts and
any framework obligations (e.g., SOC 2 vendor-management criteria, CIS Control 15).*