Due Diligence, Questionnaires, and Monitoring

Due Diligence Is Risk-Based, Not One-Size-Fits-All

Due diligence is the investigation performed before trusting a third party with credentials, facilities, or data. It is not a single form — it asks, "What happens if this vendor fails, is breached, mishandles data, or cannot perform?" The answer drives an inherent risk rating that scales the review. A furniture supplier and a cloud provider storing customer records do not get the same scrutiny.

The first step is scoping. Common intake questions:

• What business process will the vendor support, and is it business-critical?
• What data types will it access, process, store, or transmit (PII, PHI, cardholder data)?
• Will it hold network, cloud, API, or privileged access?
• Will it use subprocessors (fourth parties)?
• Which countries or regions will host or process the data (data sovereignty)?
• Do regulatory or contractual obligations (HIPAA, PCI DSS, GDPR) apply?

Scoping answers feed a tier: a high-risk vendor gets deep evidence review and frequent monitoring; a low-risk supplier may get a short questionnaire.

The goal of scoping is to set an inherent risk rating that drives the depth of due diligence. A vendor that stores protected health information and holds privileged production access is high-inherent-risk and earns an independent audit review, a right-to-audit clause, and quarterly monitoring. A vendor that ships branded coffee mugs is low risk and may pass with a one-page questionnaire. Spending equal effort on both wastes the budget that should protect the data that matters — and on the exam, the correct answer matches the rigor of the review to the sensitivity of the data and the level of access being granted.

Questionnaires and the Evidence Behind Them

Standardized questionnaires speed comparison: the SIG (Standardized Information Gathering) questionnaire and the Cloud Security Alliance CAIQ (Consensus Assessments Initiative Questionnaire) are common. But a questionnaire is self-attested — it proves intent, not operation. Strong programs validate answers against independent evidence.

Independent assurance beats self-attestation

• SOC 2 Type II — tests whether controls operated over a period (3–12 months); a Type I only describes design at a point in time.
• ISO/IEC 27001 — certified ISMS scope.
• PCI DSS AOC (Attestation of Compliance) — for cardholder data.
• A right-to-audit clause lets you verify directly when reports fall short.

When reviewing a SOC 2, do not stop at the opinion page. Read the scope (which systems and trust-service criteria are covered), the report period, the auditor's opinion type (unqualified is clean; qualified means exceptions), and the complementary user-entity controls — the things you must do for the vendor's controls to work. A clean report with a scope that excludes the very system holding your data proves nothing. This is why the exam distinguishes a self-attested questionnaire answer from an independent attestation: the questionnaire states intent, the attestation tests reality.

Continuous Monitoring Scenario

A retailer uses a third-party marketing-analytics platform. During due diligence the vendor states it stores no payment data — only pseudonymous customer IDs, email addresses, campaign events, and consent flags — so it is approved as medium risk.

Six months later the vendor announces an integration that enriches profiles through a new subprocessor. That is a material change: it may alter data sharing and privacy exposure. The retailer updates the vendor risk record, reviews the new subprocessor, confirms consent language still matches actual processing, and requires a contract amendment before enabling the feature.

Monitoring is broader than technical controls. Mature TPRM watches SLA misses, breach notifications, audit-report exceptions, negative news, financial distress, ownership/merger changes, expiring attestations, and missed remediation dates. Many programs subscribe to a security-ratings feed for an external signal.

Vendor Risk Register

Common Traps

• Asking every vendor identical questions regardless of risk tier.
• Accepting "yes" answers with no evidence for high-risk services.
• Reviewing a vendor once and never re-assessing.
• Ignoring material changes (new data types, regions, subprocessors).
• Treating a SOC 2 or ISO cert as proof that every contract requirement is met.

The risk register is the heartbeat of monitoring. Every finding needs an owner, a due date, and a status, and the program lead reviews aging items so nothing sits open indefinitely. When a risk cannot be fixed by the deadline, the right move is a documented compensating control plus a formal risk acceptance signed at the appropriate level — never a silent expiry. On the exam, when a material change appears (a new subprocessor, a new region, a fresh breach disclosure), the best answer triggers a re-assessment and contract amendment, not an immediate technical reflex like deleting logs or disabling consent records.