Compliance, Governance & Quản lý rủi roCompliance, Governance & Risk Management
Thuộc bộ kiến thức DevSecOps Roadmap.
Tổng quan
Compliance, governance và quản lý rủi ro (thường viết tắt là GRC) là chất keo tổ chức kết nối công việc kỹ thuật security với thực tế kinh doanh, pháp lý và hợp đồng. Một đội có thể ship phần mềm được scan, ký (sign), và hardening hoàn hảo nhưng vẫn trượt audit, mất hợp đồng khách hàng, hoặc bị phạt vì không thể chứng minh — bằng bằng chứng (evidence) — rằng các control của mình tồn tại và vận hành nhất quán theo thời gian.
Trong một tổ chức truyền thống, compliance là một đợt “chữa cháy” một năm một lần: bảng tính bị bỏ xó được lôi ra, screenshot được thu thập thủ công, auditor phỏng vấn kỹ sư trong hai tuần, rồi mọi thứ trở lại “bình thường” khi chứng chỉ được cấp. Mô hình này không sống sót nổi trước tốc độ delivery của DevSecOps, nơi hạ tầng thay đổi từng giờ, deployment diễn ra hàng chục lần một ngày, và “môi trường” đang bị audit không còn đứng yên đủ lâu để một snapshot còn đúng.
Câu trả lời của DevSecOps là compliance as code: mã hóa các yêu cầu control thành policy có thể đọc bằng máy, liên tục đánh giá hạ tầng và pipeline theo các policy đó, và tự động sinh ra bằng chứng audit như một sản phẩm phụ của công việc kỹ thuật hằng ngày thay vì một dự án riêng biệt, gây gián đoạn.
Vì sao compliance quan trọng
| Động lực | Mô tả | Ví dụ |
|---|---|---|
| Nghĩa vụ pháp lý / regulatory | Luật và quy định bắt buộc các control cụ thể | GDPR (dữ liệu cá nhân EU), HIPAA (dữ liệu y tế Mỹ), PCI DSS (thanh toán thẻ) |
| Nghĩa vụ hợp đồng | Khách hàng/đối tác yêu cầu bằng chứng control trước khi ký | Khách hàng doanh nghiệp yêu cầu báo cáo SOC 2 trước khi mua hàng |
| Niềm tin thị trường / khách hàng | Chứng chỉ đóng vai trò tín hiệu tin cậy và công cụ bán hàng | Chứng chỉ ISO 27001 cần thiết để đấu thầu hợp đồng doanh nghiệp/chính phủ |
| Giảm rủi ro | Framework hệ thống hóa việc nhận diện và xử lý rủi ro | NIST CSF giảm khả năng/tác động của breach |
| Khả năng bảo hiểm | Nhà bảo hiểm cyber-insurance yêu cầu bằng chứng chương trình security | Phí bảo hiểm thấp hơn khi chứng minh có MFA, backup, kế hoạch incident response |
Từ “chữa cháy hàng năm” đến continuous compliance
| Compliance truyền thống | Continuous compliance (DevSecOps) |
|---|---|
| Audit tại một thời điểm, mỗi năm một lần | Giám sát control liên tục, tự động |
| Thu thập evidence thủ công (screenshot, spreadsheet) | Evidence tự động thu thập từ API/log/pipeline |
| Compliance chỉ do đội GRC/legal sở hữu | Đồng sở hữu giữa engineering, security và GRC |
| Control chỉ được ghi trong Word/Confluence | Control mã hóa thành policy-as-code, versioned trong git |
| Chữa cháy audit làm gián đoạn engineering hàng tuần | Auditor được cấp quyền đọc trực tiếp vào dashboard/evidence repo |
| Lệch pha giữa trạng thái tài liệu và thực tế rất phổ biến | Drift được phát hiện tự động và cảnh báo |
Kiến thức nền tảng
Ba trụ cột của GRC
- Governance (quản trị) — các cấu trúc, chính sách và quyền ra quyết định định hướng cách tổ chức quản lý security và rủi ro (ai quyết định gì, ai chịu trách nhiệm, ngoại lệ được phê duyệt ra sao).
- Risk management (quản lý rủi ro) — kỷ luật nhận diện, phân tích và xử lý rủi ro sao cho rủi ro còn lại (residual risk) nằm trong khẩu vị rủi ro (risk appetite) của tổ chức.
- Compliance — chứng minh, bằng bằng chứng, rằng tổ chức đáp ứng các yêu cầu cụ thể của luật, quy định, hợp đồng và các framework tự nguyện mà tổ chức đã cam kết.
Ba yếu tố này phụ thuộc lẫn nhau: governance định nghĩa cách quyết định về rủi ro được đưa ra; risk management quyết định cái gì cần được kiểm soát và ở mức độ nào; compliance chứng minh rằng các control đã chọn thực sự được triển khai và vận hành.
Các loại framework
| Loại | Mục đích | Ví dụ |
|---|---|---|
| Risk management framework | Cấu trúc cách nhận diện/đánh giá/xử lý rủi ro | NIST CSF, NIST RMF (SP 800-37), ISO 31000 |
| Management-system standard (có thể certify) | Định nghĩa hệ thống chính sách/quy trình tổ chức vận hành, được audit độc lập | ISO/IEC 27001, ISO 22301 (BCM), ISO 9001 |
| Attestation report | Ý kiến độc lập của auditor về control trong một khoảng thời gian | SOC 2, SOC 1 |
| Regulation / luật | Bắt buộc theo luật, được cơ quan quản lý/tòa án thực thi | GDPR, HIPAA, SOX |
| Industry mandate | Yêu cầu bởi tổ chức ngành/thanh toán, không phải luật | PCI DSS |
| Control catalog | Danh sách control chi tiết dùng làm baseline/tham chiếu | NIST SP 800-53, CIS Controls |
NIST Cybersecurity Framework (CSF)
NIST CSF (phiên bản hiện tại 2.0) là một framework tự nguyện, hướng theo kết quả (outcome-based), tổ chức quanh sáu Function cốt lõi (CSF 2.0 bổ sung Govern vào năm function ban đầu):
| Function | Mục đích | Hoạt động tiêu biểu |
|---|---|---|
| Govern (mới trong CSF 2.0) | Thiết lập và giám sát chiến lược quản lý rủi ro, vai trò và chính sách của tổ chức | Xác định risk appetite, phân công vai trò, đặt chính sách rủi ro chuỗi cung ứng |
| Identify | Hiểu asset, rủi ro và bối cảnh kinh doanh | Kiểm kê asset, đánh giá rủi ro, phân loại dữ liệu |
| Protect | Triển khai biện pháp bảo vệ để giới hạn/ngăn chặn tác động | Access control, mã hóa, đào tạo security, secure SDLC |
| Detect | Phát hiện sự kiện security kịp thời | Logging/monitoring, phát hiện bất thường, quét vulnerability |
| Respond | Hành động khi phát hiện incident | Kế hoạch incident response, truyền thông, giảm nhẹ |
| Recover | Khôi phục năng lực/dịch vụ bị ảnh hưởng bởi incident | Backup/restore, disaster recovery, review sau incident |
CSF không phải là checklist để “pass” — tổ chức dùng Tiers (Partial → Risk Informed → Repeatable → Adaptive) để mô tả độ trưởng thành của chương trình và Profiles (Current vs. Target) để lập kế hoạch cải tiến, khiến nó phù hợp tự nhiên với cải tiến lặp lại kiểu DevSecOps hơn là một cuộc audit một lần.
NIST SP 800-53 nhìn tổng quan
SP 800-53 là một catalog chi tiết các control về security và privacy, tổ chức thành các họ control (control family), được sử dụng nhiều bởi các cơ quan liên bang Mỹ (qua FedRAMP/FISMA) và được áp dụng rộng rãi như một baseline control ở nơi khác.
| Họ control (ví dụ) | Trọng tâm |
|---|---|
| AC — Access Control | Least privilege, quản lý tài khoản, kiểm soát session |
| AU — Audit and Accountability | Logging, review log, lưu trữ audit record |
| CM — Configuration Management | Baseline config, kiểm soát thay đổi, drift của IaC |
| IA — Identification and Authentication | MFA, xác minh danh tính |
| IR — Incident Response | Lập kế hoạch, xử lý, báo cáo incident |
| RA — Risk Assessment | Quét vulnerability, tần suất đánh giá rủi ro |
| SA — System and Services Acquisition | Secure SDLC, chuỗi cung ứng, rủi ro bên thứ ba |
| SC — System and Communications Protection | Mã hóa in-transit/at-rest, phân đoạn mạng |
| SI — System and Information Integrity | Quản lý patch, chống mã độc, kiểm tra SBOM/integrity |
Control được tùy chỉnh thành các baseline (Low/Moderate/High impact) dựa trên tác động tiềm tàng của một vụ breach (theo FIPS 199), nên một trang web marketing công khai và một hệ thống chứa dữ liệu y tế được quản lý sẽ dùng bộ control rất khác nhau dù cùng dựa trên một catalog.
ISO/IEC 27001 và ISMS
ISO/IEC 27001 chứng nhận không phải một phần mềm mà là một Information Security Management System (ISMS): quy trình quản lý liên tục, có tài liệu mà tổ chức vận hành để nhận diện rủi ro bảo mật thông tin và xử lý chúng.
Chu trình PDCA (động cơ cải tiến liên tục kinh điển làm nền cho ISMS, vẫn là mô hình tư duy thực tiễn dù bản sửa đổi 2022 ánh xạ nó vào các điều khoản “cấu trúc bậc cao” hài hòa của ISO):
| Giai đoạn | Hoạt động |
|---|---|
| Plan (Lập kế hoạch) | Xác định phạm vi ISMS, phương pháp đánh giá rủi ro, kế hoạch xử lý rủi ro, Statement of Applicability (SoA) |
| Do (Thực hiện) | Triển khai control, đào tạo/nâng cao nhận thức, vận hành ISMS hàng ngày |
| Check (Kiểm tra) | Audit nội bộ, review của ban lãnh đạo, giám sát/đo lường hiệu quả control |
| Act (Hành động) | Hành động khắc phục, cải tiến liên tục, cập nhật xử lý rủi ro dựa trên phát hiện |
Annex A controls: Annex A của ISO/IEC 27001:2022 tái cấu trúc 14 domain trước đó thành 4 chủ đề (theme) và 93 control:
| Theme | Control ví dụ |
|---|---|
| Organizational (37 control) | Chính sách bảo mật thông tin, quan hệ nhà cung cấp, ICT continuity, threat intelligence |
| People (8 control) | Sàng lọc nhân sự, điều khoản lao động, nâng cao nhận thức security, quy trình kỷ luật |
| Physical (14 control) | Kiểm soát ra vào vật lý, bảo trì thiết bị, tiêu hủy an toàn |
| Technological (34 control) | Access control, mã hóa, secure coding, logging, DLP, backup |
Quy trình chứng nhận nhìn tổng quan:
- Gap analysis — đánh giá trạng thái hiện tại so với yêu cầu Annex A / ISMS.
- Xác định phạm vi (scope) — quyết định các đơn vị kinh doanh, hệ thống và địa điểm nào ISMS bao phủ.
- Đánh giá & xử lý rủi ro — nhận diện rủi ro, chọn phương án xử lý, tạo SoA (control nào áp dụng/loại trừ và tại sao).
- Triển khai — rollout chính sách, control, đào tạo trong một khoảng thời gian (thường 3–12 tháng).
- Audit nội bộ & review lãnh đạo — tự kiểm tra mức độ sẵn sàng trước audit bên ngoài.
- Stage 1 audit (bên ngoài) — review tài liệu; auditor xác nhận ISMS được thiết kế đúng.
- Stage 2 audit (bên ngoài) — audit dựa trên bằng chứng rằng ISMS vận hành hiệu quả trong thực tế.
- Chứng nhận — có hiệu lực 3 năm, kèm surveillance audit hàng năm và recertification audit vào năm thứ 3.
SOC 2
SOC 2 (“System and Organization Controls 2”) là một báo cáo attestation được định nghĩa bởi AICPA, cực kỳ phổ biến trong giới B2B SaaS bán cho doanh nghiệp. Khác với ISO 27001 (chứng nhận theo một standard), SOC 2 là ý kiến của một auditor độc lập, dựa trên Trust Services Criteria (TSC) của AICPA.
Trust Services Criteria:
| Tiêu chí | Bắt buộc? | Trọng tâm |
|---|---|---|
| Security (the “Common Criteria”) | Luôn bắt buộc | Bảo vệ chống truy cập trái phép — baseline cho mọi báo cáo SOC 2 |
| Availability | Tùy chọn | Hệ thống sẵn sàng vận hành/sử dụng như cam kết |
| Confidentiality | Tùy chọn | Thông tin được đánh dấu là bảo mật được bảo vệ |
| Processing Integrity | Tùy chọn | Xử lý của hệ thống hoàn chỉnh, hợp lệ, chính xác, kịp thời, được phê duyệt |
| Privacy | Tùy chọn | Thông tin cá nhân được thu thập/sử dụng/lưu trữ/tiết lộ theo cam kết |
Hầu hết công ty theo đuổi Security cộng với Availability và/hoặc Confidentiality; Privacy ít được đưa vào hơn vì tuân thủ GDPR/CCPA thường được xử lý riêng.
Type I vs. Type II:
| Type I | Type II | |
|---|---|---|
| Đánh giá gì | Thiết kế của control tại một thời điểm | Thiết kế và hiệu quả vận hành của control trong một khoảng thời gian |
| Khoảng thời gian điển hình | Snapshot (tại một ngày) | 3–12 tháng (thường 6 hoặc 12) |
| Nỗ lực | Thấp hơn — “control có được thiết kế đúng không” | Cao hơn — auditor lấy mẫu evidence xuyên suốt kỳ |
| Cảm nhận của khách hàng | Tín hiệu yếu hơn — thường là bước đệm | Tín hiệu mạnh — thứ enterprise procurement thường yêu cầu |
| Dùng phổ biến | Báo cáo lần đầu cho công ty giai đoạn đầu | Báo cáo thường niên khi chương trình đã trưởng thành |
Vì sao công ty SaaS theo đuổi SOC 2: khách hàng doanh nghiệp gần như luôn yêu cầu nó (hoặc ISO 27001) trong quá trình review security khi mua hàng; nó thay thế việc khách hàng tự audit vendor; và khác với ISO 27001, nó khớp tự nhiên với các quy trình bán hàng doanh nghiệp mang tính Mỹ hóa.
Khái niệm chính
Ánh xạ control (control mapping) và sự chồng lấn framework
Các tổ chức thực tế hiếm khi chỉ tuân thủ một framework — một công ty SaaS bán cho doanh nghiệp và chính phủ có thể cần đồng thời SOC 2, ISO 27001, và NIST 800-53 (qua FedRAMP), cộng thêm PCI DSS nếu xử lý thanh toán thẻ. Xây dựng lại một bộ control và quy trình evidence riêng cho mỗi framework là lãng phí và thiếu nhất quán.
Control mapping tận dụng thực tế rằng hầu hết các framework mô tả cùng những thực hành security cơ bản bằng ngôn từ và mức độ chi tiết khác nhau. Một control kỹ thuật có thể thỏa mãn nhiều yêu cầu framework cùng lúc:
| Control kỹ thuật | NIST 800-53 | ISO 27001 Annex A | SOC 2 TSC |
|---|---|---|---|
| Bắt buộc MFA cho truy cập đặc quyền | IA-2 | 8.5 (Secure authentication) | CC6.1 |
| Audit logging tập trung, chống giả mạo | AU-2, AU-6 | 8.15 (Logging) | CC7.2 |
| Quét vulnerability tự động | RA-5 | 8.8 (Management of technical vulnerabilities) | CC7.1 |
| Kế hoạch incident response có tài liệu + diễn tập | IR-4, IR-8 | 5.24–5.26 (Incident management) | CC7.3, CC7.4 |
| Mã hóa dữ liệu at-rest và in-transit | SC-13, SC-28 | 8.24 (Cryptography) | CC6.7 |
| Review quyền truy cập least-privilege (hàng quý) | AC-2, AC-6 | 5.15, 5.18 (Access control) | CC6.2, CC6.3 |
Các tổ chức chính thức hóa điều này bằng một unified control framework (UCF) hoặc common control framework (CCF): một ID control nội bộ cho mỗi thực hành, được ánh xạ (“mapped”) chéo tới điều khoản/số control của từng framework bên ngoài. Công cụ GRC (Vanta, Drata, Secureframe, OneTrust, ServiceNow GRC, hoặc một spreadsheet/mô hình OSCAL tự xây dựng) duy trì mapping này để một mẩu evidence duy nhất — ví dụ, một bản export chính sách IAM cho thấy MFA được bắt buộc — được tái sử dụng cho mọi audit cần nó, thay vì phải thu thập N lần.
Tự động hóa thu thập evidence
Thu thập evidence thủ công (ai đó chụp screenshot IAM console mỗi quý một lần) chậm, dễ sai và đã lỗi thời ngay khi được chụp. Continuous compliance tự động hóa việc này:
- Kéo evidence qua API: các job được lập lịch truy vấn API của cloud provider (AWS Config, Azure Policy, GCP Security Command Center), API của IdP (Okta, Azure AD), hệ thống ticketing (Jira), và hệ thống CI/CD để lấy evidence trạng thái hiện tại (ví dụ: “liệt kê tất cả IAM user chưa bật MFA”) theo chu kỳ định kỳ.
- Policy-as-code check: các công cụ như Open Policy Agent (OPA)/Rego, HashiCorp Sentinel, AWS Config Rules, hoặc Checkov đánh giá Infrastructure-as-Code và cấu hình cloud thực tế theo phiên bản máy-đọc-được của yêu cầu control, làm fail pipeline hoặc phát cảnh báo khi vi phạm.
- Evidence từ pipeline CI/CD: sinh SBOM, kết quả scan SAST/DAST/SCA, artifact/provenance đã ký (xem supply-chain security), và bản ghi phê duyệt deployment được thu thập tự động dưới dạng artifact của pipeline, tạo ra một audit trail liên tục, có timestamp mà không cần thêm công sức thủ công.
- Kho evidence bất biến (immutable): evidence được lưu trữ tập trung (thường kèm bảo đảm về retention và integrity) để auditor có thể được cấp quyền truy cập đọc, giới hạn thời gian, thay vì kỹ sư phải thủ công tổng hợp thư mục trong mùa audit.
- Dashboard compliance: view thời gian thực cho thấy trạng thái pass/fail của mọi control đã mapping, để cả stakeholder nội bộ và auditor bên ngoài có thể thấy tình trạng compliance hiện tại thay vì chờ một báo cáo.
Chương trình quản lý rủi ro
Quản lý rủi ro là xương sống phân tích quyết định control nào quan trọng và đầu tư bao nhiêu công sức cho chúng; xem thêm ./06-threat-modeling-and-risk-assessment.md cho khía cạnh kỹ thuật, cấp hệ thống của cùng kỷ luật này.
Các thành phần cốt lõi:
- Risk register (sổ đăng ký rủi ro) — một kho lưu trữ sống các rủi ro đã nhận diện, mỗi rủi ro có owner, mô tả, khả năng xảy ra (likelihood), tác động (impact), control hiện tại, quyết định xử lý, ngày mục tiêu, và mức đánh giá residual risk. Đây là nguồn dữ liệu tin cậy duy nhất được dùng trong các buổi review governance và audit.
- Risk appetite (khẩu vị rủi ro) — mức độ và loại rủi ro mà tổ chức sẵn sàng theo đuổi hoặc chấp nhận để đạt được mục tiêu (một tuyên bố chiến lược, cấp hội đồng quản trị, ví dụ: “chúng tôi không chấp nhận rủi ro dữ liệu PII khách hàng không mã hóa khi lưu trữ”).
- Risk tolerance (mức chịu đựng rủi ro) — biên độ chấp nhận được xung quanh appetite cho một rủi ro/chỉ số cụ thể (chi tiết và mang tính vận hành hơn, ví dụ: “vulnerability nghiêm trọng phải được xử lý trong vòng 7 ngày; chấp nhận trễ tối đa 5%”).
- Rủi ro vốn có (inherent) vs. rủi ro còn lại (residual) — inherent risk là mức phơi nhiễm trước khi áp dụng bất kỳ control nào; residual risk là phần còn lại sau khi control được triển khai. Quyết định xử lý rủi ro nhắm vào residual risk so với mức tolerance của tổ chức.
Các phương án xử lý rủi ro (“4 chữ T”):
| Xử lý | Mô tả | Ví dụ |
|---|---|---|
| Accept (chấp nhận) | Ghi nhận rủi ro và không hành động thêm (có tài liệu, có phê duyệt) vì chi phí xử lý vượt lợi ích hoặc tác động nhỏ | Chấp nhận một finding mức độ thấp trên một công cụ nội bộ, không nhạy cảm |
| Mitigate (giảm thiểu) | Triển khai control để giảm khả năng xảy ra và/hoặc tác động | Thêm rule WAF và rate limiting để giảm rủi ro DoS |
| Transfer (chuyển giao) | Chuyển một phần tác động tài chính/vận hành cho bên thứ ba | Bảo hiểm cyber-insurance, outsource cho vendor có trách nhiệm hợp đồng |
| Avoid (né tránh) | Loại bỏ rủi ro bằng cách không thực hiện hoạt động rủi ro đó | Từ chối lưu trữ dữ liệu thẻ, dùng payment processor tokenized thay thế |
Đánh giá rủi ro vừa mang tính định kỳ (ví dụ: đánh giá rủi ro doanh nghiệp hàng năm, threat modeling theo từng dự án) vừa liên tục trong DevSecOps: mỗi service, dependency, hoặc thay đổi kiến trúc mới nên kích hoạt một đợt đánh giá lại rủi ro nhẹ, cập nhật lại risk register thay vì chờ chu kỳ hàng năm tiếp theo.
Cấu trúc governance
- Policy (chính sách) — tuyên bố ý định bắt buộc, cấp cao được lãnh đạo phê duyệt (ví dụ: “Toàn bộ dữ liệu production phải được mã hóa at-rest và in-transit”). Policy hiếm khi thay đổi và cần phê duyệt chính thức để sửa đổi.
- Standard (tiêu chuẩn) — yêu cầu kỹ thuật bắt buộc, cụ thể, hiện thực hóa một policy (ví dụ: “AES-256 cho dữ liệu at-rest; TLS 1.2+ cho dữ liệu in-transit”). Standard thay đổi thường xuyên hơn policy khi công nghệ tiến hóa.
- Guideline (hướng dẫn) — thực hành được khuyến nghị, không bắt buộc, giúp đội đáp ứng standard (ví dụ: “thư viện được khuyến nghị để triển khai envelope encryption”). Lệch khỏi guideline tự nó không phải là vi phạm compliance.
- Procedure/runbook (quy trình) — hướng dẫn từng bước để thực hiện một standard (ví dụ: “cách xoay vòng một KMS key”).
| Cấp độ | Bắt buộc? | Chủ sở hữu | Tần suất thay đổi |
|---|---|---|---|
| Policy | Có | Ban lãnh đạo điều hành / CISO | Hiếm (review hàng năm) |
| Standard | Có | Đội security/architecture | Thỉnh thoảng (khi công nghệ đổi) |
| Guideline | Không (khuyến nghị) | Đội security/engineering | Thường xuyên |
| Procedure/runbook | Có (cho task nó bao phủ) | Đội vận hành | Thường xuyên |
Security steering committee (ban chỉ đạo security): một nhóm chức năng chéo, họp định kỳ (thường gồm CISO/trưởng security, lãnh đạo engineering, legal/privacy, và stakeholder kinh doanh) review risk register, phê duyệt thay đổi policy, ưu tiên đầu tư security, và phê duyệt các risk acceptance vượt ngưỡng ủy quyền. Đây là diễn đàn nơi các quyết định governance thực sự được đưa ra và ghi nhận.
Vai trò và trách nhiệm (RACI) làm rõ ai Responsible (thực hiện), Accountable (chịu trách nhiệm cuối), Consulted (được tham vấn), và Informed (được thông báo) cho mỗi control/hoạt động — thiết yếu một khi “ai cũng sở hữu security” va chạm với thực tế rằng quyền sở hữu không rõ ràng đồng nghĩa không việc gì được hoàn thành.
| Hoạt động | Engineering | Security/DevSecOps | GRC/Compliance | Điều hành/CISO |
|---|---|---|---|---|
| Triển khai control kỹ thuật (vd MFA) | R | A | I | I |
| Định nghĩa yêu cầu control/standard | C | R/A | C | I |
| Thu thập & xác thực evidence audit | C | R | A | I |
| Chấp nhận rủi ro (vượt ngưỡng) | I | C | C | A/R |
| Đầu mối liên hệ audit bên ngoài | I | C | R/A | I |
| Phê duyệt policy | I | C | C | A/R |
| Thực thi incident response | R | A | I | I |
(R = Responsible, A = Accountable, C = Consulted, I = Informed)
Best Practices
Xây dựng pipeline compliance-as-code
- Bắt đầu từ một control mapping, không phải danh sách framework. Xây một catalog control nội bộ và map mọi điều khoản framework áp dụng vào đó, để framework mới chỉ là bổ sung, không phải xây lại từ đầu.
- Mã hóa control thành policy-as-code khi có thể. Dùng OPA/Rego, Sentinel, hoặc policy engine gốc của cloud để việc kiểm tra control được tự động hóa, versioned và test được như bất kỳ code nào khác.
- Kết nối thu thập evidence vào pipeline hiện có. Tái sử dụng dữ liệu SBOM, SAST/DAST/SCA, và phê duyệt deployment mà CI/CD đã sinh ra sẵn (xem
./12-cicd-and-supply-chain-security.md) thay vì tạo ra một quy trình evidence song song. - Fail nhanh khi có drift. Xử lý một vi phạm control compliance (vd một S3 bucket mất mã hóa) giống như một test fail: cảnh báo ngay lập tức, đừng chờ đến chu kỳ audit tiếp theo mới phát hiện ra.
- Duy trì một kho evidence sẵn sàng audit quanh năm. Cấp cho auditor quyền truy cập đọc, giới hạn phạm vi và thời gian vào dashboard/kho evidence thay vì một đợt “chạy nước rút” thu thập evidence thủ công trước mỗi audit.
- Version và diff policy như code. Lưu policy-as-code và định nghĩa control trong git, yêu cầu review khi thay đổi, và giữ changelog — bản thân điều này trở thành evidence cho change management.
- Gắn item trong risk register với công việc backlog. Mỗi rủi ro được chấp nhận/giảm thiểu nên có ticket, owner và ngày đến hạn tương ứng được theo dõi trong cùng hệ thống mà kỹ sư đã dùng, không phải một spreadsheet riêng không ai mở.
- Tự động hóa các review định kỳ. Review quyền truy cập hàng quý, đánh giá lại rủi ro vendor, và chu kỳ review policy nên được lên lịch và theo dõi bằng nhắc nhở/tự động hóa, không phải dựa vào trí nhớ.
- Chọn đúng số lượng framework cần thiết. Đừng theo đuổi mọi chứng chỉ có sẵn — chọn framework dựa trên yêu cầu thực tế của khách hàng/pháp lý, và sắp xếp thứ tự (ví dụ: SOC 2 Type I → Type II → ISO 27001) thay vì cố làm mọi thứ cùng lúc.
- Làm cho quyết định governance minh bạch và truy vết được. Ghi lại quyết định của steering committee, chấp nhận rủi ro, và ngoại lệ policy kèm owner, lý do, và ngày hết hạn — ngoại lệ không được ghi chép là một trong những finding audit phổ biến nhất.
- Xử lý compliance ở quy mô lớn một cách chủ động. Khi tổ chức và dấu chân cloud phát triển, công cụ compliance và quy trình governance cũng phải mở rộng theo — xem
./17-enterprise-security-at-scale.mdđể biết GRC tiến hóa thế nào qua nhiều đội, đơn vị kinh doanh, và tài khoản cloud. - Đừng nhầm lẫn “compliant” với “an toàn”. Vượt qua một audit chứng minh sự tuân thủ với một baseline đã chọn, không phải sự vắng mặt của rủi ro — đưa threat intelligence thực tế và bài học từ incident quay trở lại cả risk register lẫn bộ control.
So sánh NIST CSF vs. ISO/IEC 27001 vs. SOC 2
| Khía cạnh | NIST CSF | ISO/IEC 27001 | SOC 2 |
|---|---|---|---|
| Loại | Framework/hướng dẫn tự nguyện | Standard hệ thống quản lý có thể certify | Báo cáo attestation của auditor độc lập |
| Cơ quan ban hành | NIST (chính phủ Mỹ) | ISO/IEC (quốc tế) | AICPA (Mỹ) |
| Có thể certify? | Không — tự đánh giá độ trưởng thành (Tiers) | Có — tổ chức chứng nhận được công nhận cấp chứng chỉ | Không có chứng chỉ — phát hành một báo cáo audit (ý kiến) |
| Phạm vi | Quản lý rủi ro cybersecurity toàn tổ chức | Phạm vi ISMS do tổ chức tự định nghĩa (có thể là một phần) | Hệ thống/dịch vụ cụ thể trong phạm vi, theo Trust Services Criteria đã chọn |
| Cấu trúc cốt lõi | 6 Function (Govern, Identify, Protect, Detect, Respond, Recover) | Chu trình PDCA + Annex A (93 control, 4 theme) | Trust Services Criteria (Security bắt buộc + các hạng mục tùy chọn) |
| Hiệu lực | Không áp dụng (mô hình tự cải tiến liên tục) | 3 năm, kèm surveillance audit hàng năm | Báo cáo bao phủ một khoảng thời gian (Type II) hoặc một ngày (Type I); tái phát hành hàng năm |
| Đối tượng điển hình | Cơ quan liên bang Mỹ, hạ tầng trọng yếu, mọi tổ chức muốn có baseline quản lý rủi ro | Doanh nghiệp toàn cầu, đặc biệt cần công nhận quốc tế | B2B SaaS mang tính Mỹ hóa bán cho khách hàng doanh nghiệp |
| Use case chính | Cấu trúc hóa và truyền đạt một chương trình quản lý rủi ro cybersecurity | Chứng nhận chính thức chứng minh một ISMS đang vận hành | Chứng minh cho khách hàng rằng các control cụ thể vận hành hiệu quả |
| Chi phí/nỗ lực tương đối | Thấp đến trung bình (tự thực hiện) | Cao (audit + vận hành ISMS liên tục) | Trung bình đến cao (Type II cần evidence liên tục) |
Tài liệu tham khảo
- NIST Cybersecurity Framework 2.0
- NIST SP 800-53 Rev. 5 — Security and Privacy Controls
- NIST SP 800-37 — Risk Management Framework
- ISO/IEC 27001:2022 — Information Security Management Systems
- ISO 31000 — Risk Management Guidelines
- AICPA SOC 2 — Trust Services Criteria
- OWASP SAMM — Software Assurance Maturity Model (governance dimension)
- roadmap.sh — DevSecOps Roadmap
Part of the DevSecOps Roadmap knowledge base.
Overview
Compliance, governance, and risk management (often abbreviated GRC) are the organizational glue that connects security engineering work to business, legal, and contractual reality. A team can ship perfectly scanned, signed, and hardened software and still fail an audit, lose a customer contract, or face regulatory fines if it cannot prove — with evidence — that its controls exist and operate consistently over time.
In a traditional organization, compliance is a once-a-year fire drill: a spreadsheet is dusted off, screenshots are manually collected, auditors interview engineers for two weeks, and everyone goes back to “normal” once the certificate is issued. This model does not survive contact with DevSecOps-speed delivery, where infrastructure changes hourly, deployments happen dozens of times a day, and the “environment” being audited no longer sits still long enough for a snapshot to remain true.
The DevSecOps answer is compliance as code: encode control requirements as machine-readable policies, continuously evaluate infrastructure and pipelines against them, and generate audit evidence automatically as a byproduct of normal engineering work rather than as a separate, disruptive project.
Why compliance matters
| Driver | Description | Example |
|---|---|---|
| Legal / regulatory obligation | Laws and regulations mandate specific controls | GDPR (EU personal data), HIPAA (US health data), PCI DSS (card payments) |
| Contractual obligation | Customers/partners require proof of controls before signing | Enterprise customers demanding a SOC 2 report before procurement |
| Customer trust / market access | Certifications act as a trust signal and sales enabler | ISO 27001 certificate required to bid on enterprise or government contracts |
| Risk reduction | Frameworks systematize the identification and treatment of risk | NIST CSF reducing likelihood/impact of breaches |
| Insurability | Cyber-insurance underwriters require evidence of a security program | Lower premiums with demonstrated MFA, backups, incident response plan |
From annual scramble to continuous compliance
| Traditional compliance | Continuous compliance (DevSecOps) |
|---|---|
| Annual point-in-time audit | Continuous, automated control monitoring |
| Manual evidence collection (screenshots, spreadsheets) | Evidence auto-collected from APIs/logs/pipelines |
| Compliance owned solely by GRC/legal team | Shared ownership between engineering, security, and GRC |
| Controls documented in Word/Confluence only | Controls encoded as policy-as-code, versioned in git |
| Audit fire-drill disrupts engineering for weeks | Auditors get read access to live dashboards/evidence repos |
| Drift between documented and actual state is common | Drift detected automatically and alerted on |
Fundamentals
The three pillars of GRC
- Governance — the structures, policies, and decision rights that direct how an organization manages security and risk (who decides what, who is accountable, how exceptions are approved).
- Risk management — the discipline of identifying, analyzing, and treating risks so that residual risk stays within the organization’s risk appetite.
- Compliance — demonstrating, with evidence, that the organization meets the specific requirements of laws, regulations, contracts, and voluntary frameworks it has committed to.
These three are interdependent: governance defines how decisions about risk are made; risk management decides what needs to be controlled and to what degree; compliance proves that the controls chosen are actually implemented and operating.
Types of frameworks
| Type | Purpose | Examples |
|---|---|---|
| Risk management framework | Structures how to identify/assess/treat risk | NIST CSF, NIST RMF (SP 800-37), ISO 31000 |
| Management-system standard (certifiable) | Defines a system of policies/processes an organization runs, independently audited | ISO/IEC 27001, ISO 22301 (BCM), ISO 9001 |
| Attestation report | Independent auditor opinion on controls over a period | SOC 2, SOC 1 |
| Regulation / law | Legally mandated, enforced by regulators/courts | GDPR, HIPAA, SOX |
| Industry mandate | Required by a payment/industry body, not a law | PCI DSS |
| Control catalog | A detailed list of controls used as a baseline/reference | NIST SP 800-53, CIS Controls |
NIST Cybersecurity Framework (CSF)
The NIST CSF (current version 2.0) is a voluntary, outcome-based framework organized around six core Functions (2.0 added Govern to the original five):
| Function | Purpose | Representative activities |
|---|---|---|
| Govern (new in CSF 2.0) | Establish and monitor the organization’s risk management strategy, roles, and policy | Define risk appetite, assign roles, set supply-chain risk policy |
| Identify | Understand assets, risks, and business context | Asset inventory, risk assessment, data classification |
| Protect | Implement safeguards to limit/contain impact | Access control, encryption, security training, secure SDLC |
| Detect | Discover security events in a timely manner | Logging/monitoring, anomaly detection, vulnerability scanning |
| Respond | Take action on a detected incident | Incident response plan, communications, mitigation |
| Recover | Restore capabilities/services impaired by an incident | Backup/restore, disaster recovery, post-incident review |
The CSF is not a checklist to “pass” — organizations use Tiers (Partial → Risk Informed → Repeatable → Adaptive) to describe program maturity and Profiles (Current vs. Target) to plan improvement, making it a natural fit for iterative, DevSecOps-style improvement rather than a one-time audit.
NIST SP 800-53 at a glance
SP 800-53 is a detailed catalog of security and privacy controls, organized into control families, used heavily by US federal agencies (via FedRAMP/FISMA) and widely adopted as a control baseline elsewhere.
| Control family (examples) | Focus |
|---|---|
| AC — Access Control | Least privilege, account management, session control |
| AU — Audit and Accountability | Logging, log review, audit record retention |
| CM — Configuration Management | Baseline configs, change control, IaC drift |
| IA — Identification and Authentication | MFA, identity proofing |
| IR — Incident Response | IR planning, handling, reporting |
| RA — Risk Assessment | Vulnerability scanning, risk assessment cadence |
| SA — System and Services Acquisition | Secure SDLC, supply chain, third-party risk |
| SC — System and Communications Protection | Encryption in transit/at rest, network segmentation |
| SI — System and Information Integrity | Patch management, malware protection, SBOM/integrity checks |
Controls are tailored into baselines (Low/Moderate/High impact) based on the potential impact of a breach (per FIPS 199), so a public marketing site and a system holding regulated health data will draw from very different control sets even under the same catalog.
ISO/IEC 27001 and the ISMS
ISO/IEC 27001 certifies not a piece of software but an Information Security Management System (ISMS): the ongoing, documented management process an organization runs to identify information security risks and treat them.
PDCA cycle (the classic continual-improvement engine underlying the ISMS, still the practical mental model even though the 2022 revision maps it onto ISO’s harmonized “high-level structure” clauses):
| Phase | Activities |
|---|---|
| Plan | Define ISMS scope, risk assessment methodology, risk treatment plan, Statement of Applicability (SoA) |
| Do | Implement controls, run training/awareness, operate the ISMS day to day |
| Check | Internal audits, management review, monitoring/measurement of control effectiveness |
| Act | Corrective actions, continual improvement, update risk treatment based on findings |
Annex A controls: ISO/IEC 27001:2022’s Annex A restructured the previous 14 domains into 4 themes and 93 controls:
| Theme | Example controls |
|---|---|
| Organizational (37 controls) | Policies for information security, supplier relationships, ICT continuity, threat intelligence |
| People (8 controls) | Screening, terms of employment, security awareness, disciplinary process |
| Physical (14 controls) | Physical entry, equipment maintenance, secure disposal |
| Technological (34 controls) | Access control, cryptography, secure coding, logging, DLP, backup |
Certification process at a glance:
- Gap analysis — assess current state vs. Annex A / ISMS requirements.
- Scope definition — decide which business units, systems, and locations the ISMS covers.
- Risk assessment & treatment — identify risks, choose treatments, produce the SoA (which controls are applicable/excluded and why).
- Implementation — roll out policies, controls, training over a period (commonly 3–12 months).
- Internal audit & management review — self-check readiness before the external audit.
- Stage 1 audit (external) — documentation review; auditor confirms the ISMS is designed correctly.
- Stage 2 audit (external) — evidence-based audit that the ISMS operates effectively in practice.
- Certification — valid 3 years, with annual surveillance audits and a recertification audit in year 3.
SOC 2
SOC 2 (“System and Organization Controls 2”) is an attestation report defined by the AICPA, extremely common among B2B SaaS vendors selling to enterprises. Unlike ISO 27001 (a certification against a standard), SOC 2 is an independent auditor’s opinion, based on the AICPA’s Trust Services Criteria (TSC).
Trust Services Criteria:
| Criterion | Mandatory? | Focus |
|---|---|---|
| Security (the “Common Criteria”) | Always required | Protection against unauthorized access — baseline for all SOC 2 reports |
| Availability | Optional | System is available for operation/use as committed |
| Confidentiality | Optional | Information designated confidential is protected |
| Processing Integrity | Optional | System processing is complete, valid, accurate, timely, authorized |
| Privacy | Optional | Personal information is collected/used/retained/disclosed per commitments |
Most companies pursue Security plus Availability and/or Confidentiality; Privacy is less commonly included since GDPR/CCPA compliance is usually handled separately.
Type I vs. Type II:
| Type I | Type II | |
|---|---|---|
| What it assesses | Design of controls at a single point in time | Design and operating effectiveness of controls over a period |
| Typical period | Snapshot (as of a date) | 3–12 months (commonly 6 or 12) |
| Effort | Lower — “were controls designed correctly” | Higher — auditor samples evidence throughout the period |
| Customer perception | Weaker signal — often a stepping stone | Strong signal — what enterprise procurement usually requires |
| Common use | First-time report for an early-stage company | Ongoing annual report once program matures |
Why SaaS companies pursue SOC 2: enterprise customers almost universally require it (or ISO 27001) during procurement/security review; it substitutes for customers running their own audits of a vendor; and, unlike ISO 27001, it maps naturally onto US-centric enterprise sales motions.
Key Concepts
Control mapping and framework overlap
Real organizations rarely comply with only one framework — a SaaS company selling into enterprise and government might simultaneously need SOC 2, ISO 27001, and NIST 800-53 (via FedRAMP), plus PCI DSS if it touches card payments. Rebuilding a separate control set and evidence process for each is wasteful and inconsistent.
Control mapping exploits the fact that most frameworks describe the same underlying security practices in different words and different levels of granularity. A single technical control can satisfy multiple framework requirements simultaneously:
| Technical control | NIST 800-53 | ISO 27001 Annex A | SOC 2 TSC |
|---|---|---|---|
| Enforce MFA for privileged access | IA-2 | 8.5 (Secure authentication) | CC6.1 |
| Centralized, tamper-evident audit logging | AU-2, AU-6 | 8.15 (Logging) | CC7.2 |
| Automated vulnerability scanning | RA-5 | 8.8 (Management of technical vulnerabilities) | CC7.1 |
| Documented incident response plan + drills | IR-4, IR-8 | 5.24–5.26 (Incident management) | CC7.3, CC7.4 |
| Encrypt data at rest and in transit | SC-13, SC-28 | 8.24 (Cryptography) | CC6.7 |
| Least-privilege access review (quarterly) | AC-2, AC-6 | 5.15, 5.18 (Access control) | CC6.2, CC6.3 |
Organizations formalize this with a unified control framework (UCF) or common control framework (CCF): one internal control ID per practice, cross-referenced (“mapped”) to every external framework’s clause/control number. GRC tooling (Vanta, Drata, Secureframe, OneTrust, ServiceNow GRC, or a home-grown spreadsheet/OSCAL model) maintains this mapping so a single piece of evidence — e.g., an IAM policy export showing MFA enforcement — gets reused across every audit that needs it, instead of being collected N times.
Evidence collection automation
Manual evidence collection (someone taking a screenshot of an IAM console once a quarter) is slow, error-prone, and stale the moment it’s captured. Continuous compliance automates this:
- API-based evidence pulls: scheduled jobs query cloud provider APIs (AWS Config, Azure Policy, GCP Security Command Center), IdP APIs (Okta, Azure AD), ticketing systems (Jira), and CI/CD systems to pull current-state evidence (e.g., “list all IAM users with MFA disabled”) on a recurring basis.
- Policy-as-code checks: tools like Open Policy Agent (OPA)/Rego, HashiCorp Sentinel, AWS Config Rules, or Checkov evaluate Infrastructure-as-Code and live cloud configuration against machine-readable versions of control requirements, failing a pipeline or raising an alert on violation.
- CI/CD pipeline evidence: SBOM generation, SAST/DAST/SCA scan results, signed artifacts/provenance (see supply-chain security), and deployment approval records are captured automatically as pipeline artifacts, providing a running, timestamped audit trail with no extra human effort.
- Immutable evidence repository: evidence is stored centrally (often with retention and integrity guarantees) so auditors can be given time-boxed, read-only access instead of engineers manually assembling folders during audit season.
- Compliance dashboards: real-time views showing the pass/fail status of every mapped control, so both internal stakeholders and external auditors can see current-state compliance rather than waiting for a report.
Risk management program
Risk management is the analytical backbone that decides which controls matter and how much effort to invest in them; see also ./06-threat-modeling-and-risk-assessment.md for the technical, system-level side of this same discipline.
Core building blocks:
- Risk register — a living inventory of identified risks, each with owner, description, likelihood, impact, current controls, treatment decision, target date, and residual risk rating. It is the single source of truth used in governance reviews and audits.
- Risk appetite — the amount and type of risk an organization is willing to pursue or retain in order to achieve its objectives (a strategic, board-level statement, e.g., “we accept no risk of unencrypted customer PII at rest”).
- Risk tolerance — the acceptable variation around the appetite for a specific risk/metric (more granular and operational, e.g., “critical vulnerabilities must be remediated within 7 days; we tolerate up to 5% slippage”).
- Inherent vs. residual risk — inherent risk is the exposure before any controls are applied; residual risk is what remains after controls are in place. Risk treatment decisions target residual risk against the organization’s tolerance.
Risk treatment options (“the four T’s”):
| Treatment | Description | Example |
|---|---|---|
| Accept | Acknowledge the risk and take no further action (documented, with sign-off) because cost of treatment exceeds benefit or impact is minor | Accepting a low-severity finding on an internal, non-sensitive tool |
| Mitigate (reduce) | Implement controls to lower likelihood and/or impact | Adding WAF rules and rate limiting to reduce DoS risk |
| Transfer (share) | Shift some financial/operational impact to a third party | Cyber insurance, outsourcing to a vendor with contractual liability |
| Avoid | Eliminate the risk by not performing the risky activity | Declining to store card data at all, using a tokenized payment processor instead |
Risk assessments are periodic (e.g., annual enterprise risk assessment, per-project threat modeling) and continuous in DevSecOps: every new service, dependency, or architecture change should trigger a lightweight risk re-evaluation, feeding back into the risk register rather than waiting for the next annual cycle.
Governance structures
- Policies — mandatory, high-level statements of intent approved by leadership (e.g., “All production data must be encrypted at rest and in transit”). Policies rarely change and require formal approval to amend.
- Standards — mandatory, specific technical requirements that implement a policy (e.g., “AES-256 for data at rest; TLS 1.2+ for data in transit”). Standards change more often than policies as technology evolves.
- Guidelines — recommended, non-mandatory practices that help teams meet standards (e.g., “recommended libraries for implementing envelope encryption”). Deviating from a guideline does not itself constitute non-compliance.
- Procedures/runbooks — step-by-step instructions for executing a standard (e.g., “how to rotate a KMS key”).
| Level | Mandatory? | Owner | Change frequency |
|---|---|---|---|
| Policy | Yes | Executive leadership / CISO | Rare (annual review) |
| Standard | Yes | Security/architecture teams | Occasional (as tech changes) |
| Guideline | No (recommended) | Security/engineering teams | Frequent |
| Procedure/runbook | Yes (for the task it covers) | Operational teams | Frequent |
Security steering committee: a recurring, cross-functional body (typically including the CISO/security lead, engineering leadership, legal/privacy, and business stakeholders) that reviews the risk register, approves policy changes, prioritizes security investment, and approves risk acceptances above a delegated authority threshold. It is the forum where governance decisions actually get made and recorded.
Roles and responsibilities (RACI) clarify who is Responsible, Accountable, Consulted, and Informed for each control/activity — essential once “everyone owns security” collides with the reality that unclear ownership means nothing gets done.
| Activity | Engineering | Security/DevSecOps | GRC/Compliance | Executive/CISO |
|---|---|---|---|---|
| Implement technical control (e.g., MFA) | R | A | I | I |
| Define control requirement/standard | C | R/A | C | I |
| Collect & validate audit evidence | C | R | A | I |
| Risk acceptance (above threshold) | I | C | C | A/R |
| External audit liaison | I | C | R/A | I |
| Policy approval | I | C | C | A/R |
| Incident response execution | R | A | I | I |
(R = Responsible, A = Accountable, C = Consulted, I = Informed)
Best Practices
Building a compliance-as-code pipeline
- Start from a control mapping, not a framework list. Build one internal control catalog and map every applicable framework’s clauses onto it, so new frameworks are additive, not a rebuild.
- Encode controls as policy-as-code where possible. Use OPA/Rego, Sentinel, or native cloud policy engines to make control checks automated, versioned, and testable like any other code.
- Wire evidence collection into existing pipelines. Reuse SBOM, SAST/DAST/SCA, and deployment-approval data that CI/CD already produces (see
./12-cicd-and-supply-chain-security.md) rather than inventing a parallel evidence process. - Fail fast on drift. Treat a compliance control violation (e.g., an S3 bucket losing encryption) the same way as a failed test: alert immediately, do not wait for the next audit cycle to discover it.
- Keep an audit-ready evidence repository year-round. Give auditors scoped, read-only, time-boxed access to dashboards/evidence stores instead of a manual evidence-gathering sprint before each audit.
- Version and diff policies like code. Store policy-as-code and control definitions in git, require review for changes, and keep a changelog — this itself becomes evidence of change management.
- Tie risk register items to backlog work. Every accepted/mitigated risk should have a corresponding ticket, owner, and due date tracked in the same system engineers already use, not a separate spreadsheet nobody opens.
- Automate recurring reviews. Quarterly access reviews, vendor risk reassessments, and policy review cycles should be scheduled and tracked with reminders/automation, not left to memory.
- Right-size the framework set. Don’t pursue every certification available — choose frameworks driven by actual customer/regulatory/legal requirements, and sequence them (e.g., SOC 2 Type I → Type II → ISO 27001) rather than attempting everything simultaneously.
- Make governance decisions visible and traceable. Record steering committee decisions, risk acceptances, and policy exceptions with owner, rationale, and expiry date — undocumented exceptions are one of the most common audit findings.
- Treat compliance for scale deliberately. As the organization and its cloud footprint grow, compliance tooling and governance processes must scale too — see
./17-enterprise-security-at-scale.mdfor how GRC evolves across many teams, business units, and cloud accounts. - Don’t confuse compliant with secure. Passing an audit demonstrates conformance to a chosen baseline, not the absence of risk — feed real threat intelligence and incident learnings back into both the risk register and the control set.
NIST CSF vs. ISO/IEC 27001 vs. SOC 2 — comparison
| Aspect | NIST CSF | ISO/IEC 27001 | SOC 2 |
|---|---|---|---|
| Type | Voluntary framework/guidance | Certifiable management-system standard | Independent auditor attestation report |
| Issuing body | NIST (US government) | ISO/IEC (international) | AICPA (US) |
| Certifiable? | No — self-assessed maturity (Tiers) | Yes — accredited certification body issues certificate | No certificate — issues an audit report (opinion) |
| Scope | Organization-wide cybersecurity risk management | ISMS scope defined by the organization (can be a subset) | Specific system/service in scope, per selected Trust Services Criteria |
| Core structure | 6 Functions (Govern, Identify, Protect, Detect, Respond, Recover) | PDCA cycle + Annex A (93 controls, 4 themes) | Trust Services Criteria (Security mandatory + optional categories) |
| Validity | N/A (continuous self-improvement model) | 3 years, with annual surveillance audits | Report covers a period (Type II) or a date (Type I); reissued annually |
| Typical audience | US federal agencies, critical infrastructure, any org wanting a risk-management baseline | Global enterprises, especially those needing international recognition | US-centric B2B SaaS selling to enterprise customers |
| Primary use case | Structuring and communicating a cybersecurity risk program | Formal certification proving an operating ISMS | Proving to customers that specific controls operate effectively |
| Relative cost/effort | Low-to-moderate (self-driven) | High (audit + ongoing ISMS operation) | Moderate-to-high (Type II requires sustained evidence) |
References
- NIST Cybersecurity Framework 2.0
- NIST SP 800-53 Rev. 5 — Security and Privacy Controls
- NIST SP 800-37 — Risk Management Framework
- ISO/IEC 27001:2022 — Information Security Management Systems
- ISO 31000 — Risk Management Guidelines
- AICPA SOC 2 — Trust Services Criteria
- OWASP SAMM — Software Assurance Maturity Model (governance dimension)
- roadmap.sh — DevSecOps Roadmap