Representative ImplementationRisk & GRC · Cross-Industry

Cybersecurity Risk & Third-Party Risk Assessment: A Methodology That Survives an Audit

A representative risk and third-party risk methodology — from asset and vendor scoping through inherent risk, control evidence, residual risk, and treatment — aligned to SG2'scompliance and risk practice.

How to read this page: this is a Representative Implementation, not a named-customer case study — a composite example based on common engagement patterns and consulting experience, illustrating how SG2 typically structures a risk and third-party risk assessment methodology. No specific customer is described, and the example metrics further down the page are illustrative, not measured results.

Executive Summary

Most vendor programs collect answers and stop there — no common scoring model, no evidence standard, no clear line from a concerning answer to a treatment. This methodology turns the questionnaire into a decision, and does it the same way every time: score inherent risk before controls, demand evidence not attestations, and track residual risk to an owner and a date — so the results hold up when an auditor or the board asks how a particular vendor got approved.

Business Challenges

Vendors assessed with inconsistent questionnaires and no common scoring model

Answers filed in a folder — no line from "this concerns me" to a treatment, an owner, and a date

Scoring driven by paperwork quality, so low-consequence vendors with polished decks outrank riskier ones

Controls claimed but never evidenced — the questionnaire said yes, nothing was checked

Every vendor reassessed annually regardless of risk, over-burdening the low tier and under-scrutinising the high

No single register — internal risk and third-party risk tracked in separate, incompatible spreadsheets

Reference Workflow

Asset / Vendor Scoping Threat & Vulnerability Likelihood Impact Inherent Risk Controls & Evidence Residual Risk Treatment

Assessment Workflow

Domain & Scope Definition

Asset, process, and vendor risk domains defined — what each vendor touches, and what breaks if they fail or are breached.

Threat, Vulnerability & Likelihood

Realistic threat model per vendor class, plausible weaknesses, and the probability of a material incident.

Impact Assessment

Business consequence scored across regulatory, financial, operational, and reputational dimensions.

Inherent Risk Scoring

Likelihood × impact, before controls — this score sets due-diligence depth, evidence bar, and reassessment cadence.

Control & Evidence Evaluation

Control design plus operating evidence — a current SOC 2 Type II, a pen-test summary, architecture docs — not attestations. Claims without evidence become their own finding class.

Residual Risk

What remains after controls are accounted for — the number that drives the approve / conditions / reject decision.

Treatment & Escalation

Accept, mitigate, transfer, or avoid — each with an owner, a target date, and an escalation threshold if the date slips.

Capabilities

Common Scoring Model

• One inherent/residual scale for internal and vendor risk
• Documented tiers and thresholds
• Consistent across assessors and over time

Evidence Standard

• Evidence required per control, not attestations
• Evidence exceptions tracked as findings
• Expired certifications flagged automatically

Risk Register

• Living register with owners and review dates
• Internal and third-party risk in one place
• Board- and auditor-ready views

Treatment Workflow

• Accept / mitigate / transfer / avoid decisions
• Target dates and escalation thresholds
• Re-attestation and event-driven triggers

Third-Party Due Diligence

• Questionnaire structured to the scoring model
• Risk-tiered assessment depth
• Onboarding and periodic re-review cycles

Reporting

• High-risk vendor tracking
• Assessments-due and overdue views
• Residual-critical items awaiting treatment

Key Deliverables

Risk assessment methodology · risk register · third-party questionnaire structure · control and evidence assessment · residual-risk scoring · treatment and escalation workflow.

Example Management View

Illustrative figures for a mid-size vendor portfolio — not a measured project result.

High-risk vendors9

Assessments due this cycle14

Open evidence exceptions7

Residual-critical items2

Review cadence (critical vendors)Annual / event-driven

Outcomes This Methodology Typically Targets

Representative, not measured — see the note at the top of this page.

A defensible answer to "how did this vendor get approved, and when do we look again"

Priority order driven by inherent risk, not the quality of a vendor’s sales collateral

Evidence exceptions surfaced instead of buried in a folder of unread questionnaires

One risk register and one scoring language for internal and third-party risk

Reassessment cadence matched to risk tier — annual-plus-event for critical, longer for the rest

Works With

ServiceNow GRC / ArcherOneTrust / Vanta / DrataSOC 2 & ISO 27001 evidence intakeMetaSight (data-flow mapping)Procurement / vendor onboardingBoard and audit reporting

Compliance & Risk practice Read the TPRM methodology guide

Frequently Asked Questions

Common questions from enterprise and mid-market teams across India and internationally.

Why score inherent risk before looking at controls?

Because it decides how hard you look. A vendor that processes regulated customer data and integrates with production is high inherent risk whether or not they have a SOC 2 — that score sets the depth of due diligence, the evidence bar, and the reassessment frequency. Skip straight to "do they have certifications" and a low-consequence vendor with great paperwork can outscore a high-consequence vendor with adequate paperwork, which is backwards.

What counts as evidence versus an attestation?

An attestation is the vendor saying "yes, we encrypt data at rest." Evidence is a current SOC 2 Type II covering that control, a penetration test executive summary, an architecture document, or a console screenshot. The methodology tracks an evidence standard per control and flags exceptions — controls claimed but not evidenced — as their own finding class, because that gap is where questionnaire-based programs quietly fail.

How is residual risk different from inherent risk?

Inherent risk is the exposure before considering the vendor’s controls — a function of data sensitivity, integration depth, and business dependency. Residual risk is what is left after evaluating how well those controls actually work. A high-inherent-risk vendor with strong, evidenced controls can land at acceptable residual risk; a medium-inherent-risk vendor with control gaps might not. Residual risk drives the treatment decision.

How often should vendors be reassessed?

Risk-tiered, not calendar-uniform. Critical vendors — those touching regulated data or production — annually plus on any triggering event: a breach disclosure, an acquisition, a material service change, or an expired certification. Lower-tier vendors on a longer cycle or event-driven only. A flat "everyone annually" either over-burdens the low tier or under-scrutinises the high tier, usually both.

Is this a Representative Implementation or a named-client case study?

A Representative Implementation — a composite based on common engagement patterns and consulting experience. It illustrates how SG2 structures a risk and third-party risk assessment methodology. No specific customer is described, and the example metrics shown are illustrative, not measured project results.

Could you explain how your last vendor got approved?

Talk to our GRC team about standing up a repeatable risk and third-party risk methodology.

Request a Consultation