
Right-Sized Third-Party Security for SMB Organizations
Vendor risk doesn’t require a giant GRC machine—just clear tiers, minimum controls, and repeatable evidence.
By Aaron Gilmore — Intergalactic SEM Consultant (humans only so far).
Human Lead, Automation-Enhanced. SEM-Artificium
QuickScan
Most vendor risk concentrates in a few high-impact third parties (MSPs, SaaS with sensitive data, critical operational partners).
“Right-sized” starts with fast tiering (data + access + criticality + physical access), then scales requirements by tier.
The biggest risk-reduction wins are access controls (MFA, least privilege), clear incident notification expectations, and reliable offboarding.
Keep procurement moving by making requirements predictable: minimum controls + minimum evidence by tier.
For Who
Primary audience: Non-DoD / Non-Federal supply chain organizations (SMB/mid-market)
Best for roles: Procurement/Supply Chain, IT/Security, Operations, Legal/Contracts, Finance, Facilities/Site leadership, Compliance/Risk (if present)
What You’ll Get
You will learn: A practical, tiered third-party security model that fits SMB staffing and budget reality.
You will be able to do: Stand up a minimum viable vendor-risk program (tiers + minimum controls + usable evidence + review cadence).
Time & Effort
Read time: 6 minutes
Do time (optional): 60–120 minutes
Difficulty: Beginner
Right-size third-party security by tiering vendors, applying minimum controls, collecting evidence, and revoking access when the work ends.
Quick Brief Snapshot (Read This First)
A right-sized third-party security program tiers vendors by impact, applies minimum controls per tier, collects only usable evidence, and reviews vendor access on a cadence. (NIST, 2022)
Why you should care:
Most SMB/mid-market risk isn’t “all vendors”—it’s a handful of vendors with sensitive data access, privileged access, or operational criticality. Right-sizing keeps procurement moving while still reducing your biggest exposure: outside pathways into your systems, data, and facilities. (NIST, 2022)
Key takeaways:
Don’t start with a giant vendor questionnaire—start with tiering based on impact (data, access, criticality, physical access).
Tier 1 vendors need must-have controls (MFA, least privilege, incident notification expectations, and reliable offboarding). (NIST, 2020)
Evidence should be lightweight and reviewable (a short questionnaire, a SOC 2/ISO summary, and named incident/security contacts).
Put the program on rails: a repeatable intake flow + quarterly Tier 1 access reviews.
If you can’t name an owner for a vendor decision, you can’t defend the decision.
The Concept (Plain English)
Definition
Right-sized third-party security is a tiered approach to vendor risk where you apply minimum controls and evidence requirements based on how much a vendor could realistically impact confidentiality, integrity, availability, or safety. (NIST, 2022)
What it is / isn’t
It is: predictable tiers + minimums that scale with vendor impact.
It is: access control + contract expectations + a review cadence you can actually maintain. (NIST, 2020)
It is not: treating every vendor like a Tier 1 MSP.
It is not: collecting a 200-question spreadsheet you’ll never read.
Why this concept exists
SMBs don’t have the staff or tooling for heavyweight third-party risk programs—but they still inherit risk through vendors that touch critical systems and sensitive data. The goal is to reduce the biggest risk pathways first by setting clear expectations, collecting minimal evidence, and monitoring over time. This aligns with cyber supply chain risk management principles focused on understanding dependencies and managing risk across the vendor lifecycle. (NIST, 2022)
Tiering triggers
Data: Do they store/process sensitive data (PII, financial, customer, IP)?
Access: Do they have privileged/admin access or remote access into your environment?
Criticality: Would vendor downtime stop billing, shipping, manufacturing, safety, or customer service?
Physical: Do they have recurring unsupervised site access?
Regulatory/contract: Do you have flow-down obligations?
Rule of thumb
Tier 1: “Yes” to any 2+ triggers
Tier 2: “Yes” to 1 trigger
Tier 3: “No” to all triggers

Figure 1 - "Right-Sized Vendor Tiers (Filtering & Minimums)" [Aaron Gilmore] {Graphic showing vendor tiering and the minimum controls and evidence expected for Tier 1, Tier 2, and Tier 3 vendors.}
A Simple Example
Scenario
A 220-person manufacturing company uses a local MSP for IT support and remote administration. Procurement wants to add a new payroll/HR SaaS platform quickly, and Operations relies on a logistics partner that has portal access for shipping schedules. Historically, vendors got “whatever access they needed” and nobody tracked who had admin rights. The company builds a simple vendor list and tiers the top 20 vendors. The MSP and payroll/HR SaaS land in Tier 1 (privileged access + sensitive data). The logistics portal vendor becomes Tier 2 (business access, limited sensitive data). A small office supply vendor becomes Tier 3 (no access, low impact). The team applies minimum Tier 1 controls: MFA, named accounts (no shared admin), least privilege scopes, an incident notification contact, and a quarterly access review calendar hold. (NIST, 2020)
Where teams usually go wrong
They tier everything as “high” (procurement slows to a crawl).
They collect “security paperwork” but never tighten vendor access (the real pathway).
They forget offboarding, so access persists long after the relationship ends. (NIST, 2020)
What “good” looks like
“Good” is a predictable intake: the business owner justifies the vendor, the team tiers it in minutes, Tier 1 gets a short set of non-negotiables (MFA, named accounts, least privilege, incident contact), and the org captures a simple decision record and review cadence. It’s not perfect security—it’s repeatable risk reduction that fits real staffing and time constraints. (NIST, 2022)
The Practical Checklist (Do This)
Do this today (15–30 minutes)
Pull a quick vendor list from Accounts Payable + IT/SaaS admin consoles (start with top 20).
Mark each vendor with two flags: “Touches sensitive data?” and “Has remote/privileged access?”
Identify your first Tier 1 shortlist (anything with sensitive data and/or privileged access).
Assign a single named business owner for each Tier 1 vendor (who can justify the risk).
Do this this week (1–3 hours)
Define Tier 1/2/3 using the triggers above and write a one-page “minimums by tier” table.
For Tier 1 vendors, require (at minimum):
MFA + named accounts (no shared credentials)
Least privilege (scope access to what’s needed)
Incident/security contact + notification expectation in writing
Offboarding expectation (revoke access + confirm data disposition) (NIST, 2020)
Put a quarterly calendar reminder for Tier 1 access review (owners confirm access is still needed).
Build a lightweight intake flow your team can repeat every time.
Evidence to capture (so it sticks)
A simple vendor inventory sheet with tier, owner, data/access flags, and review date.
A Tier 1 “minimums met” record (checkboxes are fine) plus the vendor security/incident contact.
Proof of access controls for Tier 1 (e.g., MFA enabled, named accounts, scope notes). (NIST, 2020)

Figure 2 - "Right-Sized Third-Party Intake Flow" [Aaron Gilmore] {Flowchart showing the steps for third-party intake from request through tiering, evidence, contract terms, access provisioning, monitoring, and offboarding.}
Common Pitfalls (Avoid These)
Pitfall: “We treat every vendor like Tier 1.”
Fix: Tier vendors fast using simple triggers, then apply minimums by tier so procurement stays fast.
Pitfall: “We collect lots of evidence but don’t change access.”
Fix: Prioritize controls that shrink the pathway (MFA, named accounts, least privilege, logging expectations, offboarding). (NIST, 2020)
Pitfall (optional): “Nobody owns the decision.”
Fix: Require a named business owner for Tier 1 vendors and schedule recurring access reviews.
Note From the Author
Most of the messes I’ve been pulled into didn’t start with a “mysterious attacker”, they started with a trusted vendor pathway that nobody was actively managing (an applicable "insider threat"). Right-sizing is how you keep the program real: focus on impact, lock down Tier 1 access, and make the process repeatable enough that your team will actually run it. A good default choice to "what tier do they belong in?" is to follow the concept of "ZERO TRUST", where you start at NO-Trust and you give only the explicit/specific "exemptions" to that non-trust based on ONYL what you must allow for that activity. Another way to think about this is similar to the concept of a White-List in network security, where everyone is blocked by default but only the devices/users you list HAVE a specific permission/access that list pertains to. Overall, organizations need to make sure they properly address risk management, as IMPACT (what this article focuses on for easy understanding) and PROBABILITY are super critical to how to asses how much damage can be done (impact) and how likely that damage could occur (probability).
References
International Organization for Standardization. (2022). ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements. ISO. https://www.iso.org/standard/27001.html
National Institute of Standards and Technology. (2020). Security and privacy controls for information systems and organizations (NIST SP 800-53 Rev. 5). NIST Computer Security Resource Center. https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
National Institute of Standards and Technology. (2022). Cybersecurity supply chain risk management practices for systems and organizations (NIST SP 800-161 Rev. 1). NIST Computer Security Resource Center. https://csrc.nist.gov/publications/detail/sp/800-161/rev-1/final







