D6 · 12% · CGRC

C06 — Quản lý bên thứ ba

Third-Party Management — Vendor risk assessment lifecycle, security clauses trong contracts/SLA, SOC 2 / ISO 27001 report review, fourth-party risk, cloud provider due diligence và ongoing monitoring của supplier security posture.

Tools
SOC 2 · BitSight
Platform
PowerShell · Bash
Quarter
Q2/2026
Updated
24/05/2026
Author
Trần Văn Hòa (MCT)
Version
v1.0

Mục tiêu bài học — Learning Objectives

  • Xây dựng Vendor Risk Assessment lifecycle: tiering, questionnaire, scoring, approval, ongoing monitoring
  • Soạn thảo security clauses trong contracts: data processing agreements, SLA security requirements, right-to-audit
  • Đọc và đánh giá SOC 2 Type II report — phân biệt qualified vs. unqualified opinion
  • Quản lý fourth-party risk và chuỗi cung ứng software dependencies
  • Sử dụng security rating tools (BitSight, SecurityScorecard) để monitor vendor posture liên tục

Lý thuyết — Theory

1. Vendor Risk Assessment Lifecycle

Third-party breaches ngày càng phổ biến (SolarWinds, MOVEit, Change Healthcare). Bên thứ ba có thể là entry point vào tổ chức — phải đánh giá họ như đánh giá rủi ro nội bộ.

Tier 1 — Critical
  • • Truy cập vào sensitive data (PII, PHI, PCI)
  • • Business-critical services (uptime dependency)
  • • Kiểm soát vào production systems
  • Review: Annual + event-driven
  • Assurance: SOC 2 Type II hoặc on-site audit
Tier 2 — High
  • • Truy cập internal systems nhưng không sensitive
  • • Tích hợp API với data exchange
  • • Nhà cung cấp dịch vụ quan trọng nhưng có thể thay thế
  • Review: Annual
  • Assurance: Questionnaire + SOC 2 review
Tier 3 — Standard
  • • Không truy cập vào IT systems
  • • Dịch vụ commodity (office supplies, catering)
  • • Tác động tối thiểu nếu gián đoạn
  • Review: Every 3 years
  • Assurance: Standard onboarding checklist
Vendor Assessment Lifecycle — 6 giai đoạn:
1. Vendor Identification & Tiering 2. Security Questionnaire 3. Document Review (SOC 2, ISO cert, pentest) 4. Risk Scoring & Approval 5. Contract Negotiation (security clauses) 6. Ongoing Monitoring & Re-assessment

2. Security Clauses trong Contracts & SLA

Contract là công cụ pháp lý để enforce security requirements với bên thứ ba. Không có security clauses trong contract = không có leverage khi sự cố xảy ra.

Security Requirements trong Contract:
  • • Minimum security standards (ISO 27001, SOC 2)
  • • Data protection obligations (GDPR DPA nếu data processor)
  • • Breach notification: 24-72h notify customer
  • • Right-to-audit: audit vendor annually với notice 30 ngày
  • • Subprocessor restrictions: phải approve trước
  • • Data retention và deletion requirements
  • • Pentest frequency: annual, share results
  • • Background checks cho nhân viên có data access
SLA Security Metrics:
  • • Uptime: 99.9% (8.7h downtime/year) với penalties
  • • Incident response time: Critical ≤ 1h, High ≤ 4h
  • • Patch critical vulnerabilities: ≤ 48h
  • • Vulnerability assessment: quarterly
  • • Security report: monthly/quarterly delivery
  • • Personnel security: background check for all staff with access
  • • Termination clause: secure data return/destruction trong 30 ngày
GDPR DPA (Data Processing Agreement — Art.28): Bắt buộc khi vendor xử lý personal data của EU citizens thay mặt bạn. Phải nêu: subject matter, duration, nature & purpose of processing, type of data, categories of data subjects, obligations và rights of controller.

3. SOC 2 Report Review — Đọc và đánh giá

SOC 2 Type II là "gold standard" để đánh giá security của SaaS/cloud vendors. Biết cách đọc SOC 2 report là kỹ năng quan trọng của GRC professional.

SOC 2 Report Structure:
Section I: Management's Assertion — vendor tự tuyên bố
Section II: Auditor's Opinion — qualified vs. unqualified
Section III: Description of System — controls được implement
Section IV: Trust Services Criteria (TSC) — test results
Section V: Other information — vendor responses to exceptions
Red Flags khi đọc SOC 2:
  • Qualified opinion = auditor không đồng ý với controls
  • Exceptions (deviations) trong test results — nhiều = bad
  • Report >12 tháng tuổi — không còn relevant
  • Type I thay vì Type II — chỉ point-in-time, không test effectiveness
  • Phạm vi (scope) quá hẹp — không bao phủ systems bạn dùng
  • Complementary User Entity Controls — bạn chịu trách nhiệm implement

4. Fourth-Party Risk & Ongoing Monitoring

Fourth-party risk = rủi ro từ vendors của vendors. Khi SolarWinds bị tấn công, mọi khách hàng của SolarWinds (bao gồm US government agencies) đều bị ảnh hưởng dù họ không làm gì sai.

Fourth-Party Risk Management:
  • • Yêu cầu vendors liệt kê key subprocessors
  • • Receive notification khi subprocessors thay đổi
  • • Require vendors flow-down security requirements
  • • SBOM (Software Bill of Materials) cho software vendors
  • • Cloud provider shared responsibility model clarity
  • • Concentration risk: nhiều vendors dùng cùng subprocessor
Continuous Vendor Monitoring Tools:
  • BitSight: Security ratings từ external signals (exposed services, malware, etc.)
  • SecurityScorecard: Letter grade A-F, 10 risk categories
  • UpGuard: Data leak detection + attack surface monitoring
  • RiskRecon (Mastercard): Third-party risk ratings
  • Manual reviews: Annual questionnaire + SOC 2 refresh
  • Threat intelligence: Monitor vendor breaches via news/darkweb

5. Cloud Provider Due Diligence

Cloud providers là vendors đặc biệt quan trọng. Shared Responsibility Model xác định ai chịu trách nhiệm gì — hiểu sai mô hình này là nguyên nhân của nhiều cloud security incidents.

ResponsibilityIaaS (EC2, Azure VM)PaaS (App Service, RDS)SaaS (M365, Salesforce)
Physical infraCloud ProviderCloud ProviderCloud Provider
Hypervisor/NetworkCloud ProviderCloud ProviderCloud Provider
OS & RuntimeCustomerCloud ProviderCloud Provider
ApplicationCustomerCustomerCloud Provider
Data & EncryptionCustomerCustomerCustomer
IAM & Access ControlCustomerCustomerCustomer

Lưu ý: Data luôn là trách nhiệm của Customer — dù ở SaaS. Cloud provider bảo vệ platform, bạn bảo vệ data trong platform đó.

Bài thực hành — Hands-on Labs

LAB 01

Vendor Risk Scorecard — PowerShell tạo vendor assessment & risk scoring

Platform
Windows PowerShell 7
Tools
PowerShell, CSV
Output
Vendor Risk Register
Thời gian
25 phút
# Vendor Risk Scorecard — ISC2 CGRC Third-Party Management
# Scoring: 1 (best) to 5 (worst) per category; lower total = lower risk

$vendors = @(
    @{
        Name           = "CloudPay Processor"; Tier = "Critical"
        DataAccess     = 5   # 5=high sensitive data (PCI)
        SOC2           = 1   # 1=SOC2 Type II current
        ISO27001       = 1   # 1=certified
        PentestRecent  = 2   # 2=pentest within 12mo
        BreachHistory  = 2   # 2=minor incident >3yr ago
        SLACompliance  = 1   # 1=100% SLA met last 12mo
        ContractClause = 1   # 1=full security clauses
        SubprocessorRisk = 2 # 2=known subprocessors
    },
    @{
        Name           = "MarketBot Analytics"; Tier = "High"
        DataAccess     = 3;  SOC2 = 3;  ISO27001 = 4;  PentestRecent = 3
        BreachHistory  = 1;  SLACompliance = 2;  ContractClause = 3;  SubprocessorRisk = 4
    },
    @{
        Name           = "OfficeSupply Co"; Tier = "Standard"
        DataAccess     = 1;  SOC2 = 5;  ISO27001 = 5;  PentestRecent = 5
        BreachHistory  = 1;  SLACompliance = 1;  ContractClause = 2;  SubprocessorRisk = 1
    }
)

$weights = @{
    DataAccess=0.25; SOC2=0.15; ISO27001=0.10; PentestRecent=0.15
    BreachHistory=0.15; SLACompliance=0.10; ContractClause=0.05; SubprocessorRisk=0.05
}

$results = foreach ($v in $vendors) {
    $score = 0
    foreach ($k in $weights.Keys) { $score += $v[$k] * $weights[$k] }
    $risk = switch ([math]::Round($score,1)) {
        { $_ -le 1.5 } { "LOW" }
        { $_ -le 2.5 } { "MEDIUM" }
        { $_ -le 3.5 } { "HIGH" }
        default { "CRITICAL" }
    }
    [PSCustomObject]@{
        Vendor        = $v.Name
        Tier          = $v.Tier
        WeightedScore = [math]::Round($score, 2)
        RiskRating    = $risk
        Action        = switch ($risk) {
            "LOW"      { "Approve — triennial review" }
            "MEDIUM"   { "Approve — annual review + monitoring" }
            "HIGH"     { "Conditional — remediation plan required" }
            "CRITICAL" { "Reject or escalate to CISO" }
        }
    }
}

$results | Sort-Object WeightedScore -Descending | Format-Table -AutoSize
$results | Export-Csv "C:\GRC\vendor-risk-register.csv" -NoTypeInformation
KẾT QUẢ ĐẦU RA (Expected Output)
Vendor                WeightedScore  RiskRating  Action
------                -------------  ----------  ------
MarketBot Analytics   2.95           HIGH        Conditional — remediation plan required
CloudPay Processor    2.20           MEDIUM      Approve — annual review + monitoring
OfficeSupply Co       1.70           MEDIUM      Approve — annual review + monitoring

CSV: C:\GRC\vendor-risk-register.csv
Action: Request SOC 2 Type II and ISO 27001 from MarketBot Analytics within 90 days
LAB 02

Vendor Security Monitoring — Bash kiểm tra TLS/certificate và exposed services

Platform
Linux / macOS
Tools
openssl, curl, nmap
Output
Security Posture Report
Thời gian
20 phút
#!/bin/bash
# Vendor Security Posture Check — kiểm tra TLS, cert, security headers

VENDOR="${1:-example-vendor.com}"
REPORT="/tmp/vendor-check-${VENDOR}-$(date +%Y%m%d).txt"
PASS=0; WARN=0; FAIL=0

log() { echo "[$(date +%H:%M:%S)] $1" | tee -a $REPORT; }
chk()  { printf "  %-40s [%s] %s\n" "$1" "$2" "$3" | tee -a $REPORT
         case $2 in PASS) (( PASS++ ));; WARN) (( WARN++ ));; FAIL) (( FAIL++ ));; esac; }

log "=== Vendor Security Check: $VENDOR ==="

# 1. TLS version check (reject TLS 1.0/1.1)
TLS_VER=$(openssl s_client -connect ${VENDOR}:443 -tls1_2 </dev/null 2>&1 | grep "Protocol" | awk '{print $NF}')
if [ -n "$TLS_VER" ]; then
    chk "TLS version (min TLS 1.2)" "PASS" "Supports TLS 1.2"
else
    chk "TLS version" "FAIL" "TLS 1.2 not available"
fi

# 2. Certificate expiry check
CERT_EXPIRY=$(echo | openssl s_client -connect ${VENDOR}:443 2>/dev/null | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
DAYS_LEFT=$(( ( $(date -d "$CERT_EXPIRY" +%s) - $(date +%s) ) / 86400 ))
if   [ $DAYS_LEFT -gt 30 ]; then chk "Certificate expiry" "PASS" "${DAYS_LEFT} days remaining"
elif [ $DAYS_LEFT -gt 0  ]; then chk "Certificate expiry" "WARN" "Expiring soon: ${DAYS_LEFT} days"
else                               chk "Certificate expiry" "FAIL" "EXPIRED!"
fi

# 3. Security headers check
HEADERS=$(curl -sI https://${VENDOR} --max-time 10 2>/dev/null)
for header in "Strict-Transport-Security" "X-Content-Type-Options" "X-Frame-Options" "Content-Security-Policy"; do
    if echo "$HEADERS" | grep -qi "$header"; then
        chk "Header: $header" "PASS" "Present"
    else
        chk "Header: $header" "WARN" "Missing — security risk"
    fi
done

# 4. HTTP → HTTPS redirect
HTTP_CODE=$(curl -so /dev/null -w "%{http_code}" http://${VENDOR} --max-time 5 2>/dev/null)
if [ "$HTTP_CODE" = "301" ] || [ "$HTTP_CODE" = "308" ]; then
    chk "HTTPS redirect" "PASS" "HTTP redirects to HTTPS (${HTTP_CODE})"
else
    chk "HTTPS redirect" "WARN" "HTTP response: ${HTTP_CODE} — verify redirect"
fi

log ""
log "=== RESULT: PASS=$PASS WARN=$WARN FAIL=$FAIL | Report: $REPORT ==="
KẾT QUẢ ĐẦU RA (Expected Output)
[09:20:00] === Vendor Security Check: cloudpay-vendor.com ===
  TLS version (min TLS 1.2)              [PASS] Supports TLS 1.2
  Certificate expiry                     [PASS] 187 days remaining
  Header: Strict-Transport-Security      [PASS] Present
  Header: X-Content-Type-Options         [PASS] Present
  Header: X-Frame-Options                [PASS] Present
  Header: Content-Security-Policy        [WARN] Missing — security risk
  HTTPS redirect                         [PASS] HTTP redirects to HTTPS (301)

[09:20:05] === RESULT: PASS=6 WARN=1 FAIL=0 | Report: /tmp/vendor-check-...txt ===
Action: Request vendor add Content-Security-Policy header within 30 days

Tình huống doanh nghiệp — Business Scenario

CASE STUDY — Dragon Bank (MOVEit-style Supply Chain Breach)

Dragon Bank sử dụng một vendor HR software bị breach qua zero-day vulnerability trong file transfer tool (tương tự MOVEit 2023). 45,000 bản ghi nhân viên bị exfiltrate gồm: họ tên, CCCD, lương, số tài khoản ngân hàng.

!
Root Cause: Dragon Bank không có right-to-audit trong contract, HR vendor không cần cung cấp pentest reports, và vendor dùng third-party file transfer tool chưa được đánh giá (fourth-party risk gap).
1
Immediate Response: Invoke contract breach notification clause — vendor phải notify trong 24h. Dragon Bank escalate lên NHNN theo quy định; thông báo 45,000 nhân viên bị ảnh hưởng.
2
Remediation: Renegotiate contract với full security clauses: pentest results shared annually, SOC 2 Type II mandatory, subprocessor list với right-to-object, right-to-audit clause, breach penalty $500K.
3
Program Enhancement: Triển khai SecurityScorecard monitoring cho tất cả Tier 1 & 2 vendors. Automated alert khi score giảm >10 points hoặc new critical finding detected.

Tự kiểm tra — Self-Assessment (5 câu)

1. SOC 2 Type II khác SOC 2 Type I ở điểm nào?

A. Type II kiểm tra ít controls hơn Type I
B. Type II test controls qua thời gian (6-12 tháng), Type I chỉ tại một thời điểm ✓
C. Type II do ISACA phát hành, Type I do AICPA
D. Type II bao gồm nhiều Trust Services Criteria hơn

2. Trong SOC 2 review, "Complementary User Entity Controls" (CUECs) có nghĩa là gì?

A. Controls mà vendor thực hiện thêm ngoài scope
B. Controls mà KHÁCH HÀNG (bạn) phải implement để SOC 2 effective ✓
C. Controls do third-party auditor recommend
D. Controls dùng để audit internal team

CUECs rất quan trọng — nếu bạn không implement, SOC 2 của vendor không bảo vệ bạn. Ví dụ: "Customer phải enable MFA" — nếu bạn không bật, vendor không chịu trách nhiệm breach.

3. GDPR Article 28 yêu cầu gì khi sử dụng một vendor xử lý dữ liệu cá nhân EU?

A. Vendor phải có ISO 27001 certification
B. Thực hiện DPIA trước khi hợp tác
C. Ký Data Processing Agreement (DPA) với vendor ✓
D. Vendor phải đặt servers tại EU

4. "Fourth-party risk" đề cập đến rủi ro từ đâu?

A. Bốn loại rủi ro chính trong vendor assessment
B. Vendors ở tầng thứ tư trong tổ chức của bạn
C. Vendors của vendors của bạn (subprocessors, subcontractors) ✓
D. Rủi ro tài chính từ phí vendor

5. Trong Cloud Shared Responsibility Model, thành phần nào luôn là trách nhiệm của KHÁCH HÀNG dù ở IaaS, PaaS hay SaaS?

A. Operating System patching
B. Physical infrastructure security
C. Data protection và Access Management (IAM) ✓
D. Network infrastructure

Quy trình 7 bước — Third-Party Risk Management

7-Step Third-Party Risk Process

1
Identify — Xác định bên thứ ba

Lập danh sách (catalog) toàn bộ bên thứ ba có quyền truy cập dữ liệu hoặc tích hợp hệ thống. Bao gồm: nhà cung cấp SaaS, đối tác tích hợp API, nhà thầu phụ, nhà cung cấp cloud.

2
Classify — Phân loại mức độ rủi ro

Phân tầng theo inherent risk dựa trên độ nhạy dữ liệu và mức độ truy cập:

Tier 1 — Critical: Truy cập PII, hệ thống thanh toán, hạ tầng lõi
Tier 2 — Moderate: Truy cập hạn chế, dữ liệu nội bộ phi nhạy cảm
Tier 3 — Low: Không có truy cập dữ liệu tổ chức, dịch vụ công cộng
3
Assess — Đánh giá bảo mật

Sử dụng bảng câu hỏi chuẩn: SIG Lite (Shared Assessments), VSA (Vendor Security Alliance), hoặc nội bộ. Kết hợp xem xét: SOC 2 Type II report, chứng chỉ ISO 27001, tóm tắt pen test gần nhất, chính sách bảo mật và privacy.

4
Risk Rate — Tính điểm rủi ro

Chấm điểm kết quả bảng câu hỏi, tính residual risk, gắn cờ (flag) các điểm yếu. Kết quả phân loại: Critical / High / Medium / Low gaps. Báo cáo gửi vendor và lãnh đạo nội bộ.

5
Remediate — Khắc phục điểm yếu

Vendor phải khắc phục các điểm yếu Critical trước hoặc trong quá trình onboarding. Theo dõi bằng POA&M. Các gap không thể khắc phục ngay cần được phê duyệt rủi ro (risk acceptance) từ lãnh đạo.

6
Monitor — Giám sát liên tục

Không chỉ đánh giá một lần. Giám sát liên tục bao gồm:

  • Tier 1: Tái đánh giá hàng năm (annual re-assessment)
  • Tier 2–3: Hai năm một lần (biennial)
  • • Theo dõi breach news feeds, CVE liên quan đến vendor
  • • Xem xét thay đổi SOC 2 report, chứng chỉ hết hạn
7
Offboard — Chấm dứt quan hệ an toàn

Khi hợp đồng kết thúc hoặc vendor bị thay thế:

• Xác nhận xóa dữ liệu (data deletion confirmation)
• Thu hồi toàn bộ quyền truy cập (access revocation)
• Thu hồi chứng chỉ (certificate revocation)
• Checklist chấm dứt hợp đồng (contract termination)

POA&M — Tích hợp với Quy trình Vendor

POA&M (Plan of Action & Milestones) theo dõi các cam kết khắc phục của vendor. Mỗi phát hiện chưa giải quyết phải có entry POA&M riêng biệt — không tùy chọn trong đánh giá chính thức.

Trường dữ liệu Nội dung Ví dụ
Weakness Description Mô tả chi tiết điểm yếu được phát hiện Thiếu MFA cho admin portal
Responsible Party Bên chịu trách nhiệm khắc phục Vendor CISO: John Smith
Scheduled Completion Ngày hoàn thành cam kết 2025-09-30
Resources Needed Ngân sách, nhân lực, công cụ cần thiết $15K — MFA platform license
Milestones Các mốc tiến độ cụ thể M1: Pilot 20 users (Aug 1) → M2: Full rollout (Sep 30)
CGRC Exam — POA&M là BẮT BUỘC

POA&M không phải tùy chọn — bất kỳ phát hiện chưa giải quyết nào trong đánh giá chính thức đều phải có POA&M entry. Đây là yêu cầu của FISMA, FedRAMP và hầu hết các framework GRC cấp liên bang Mỹ.

Vòng phản hồi: POA&M → Vendor Risk Rating → Hợp đồng
POA&M open findings
Tăng vendor risk score
Ảnh hưởng quyết định gia hạn hợp đồng
Vendor ưu tiên đóng POA&M
C05: Data Privacy C07: Ethics
Zalo