Governance, Risk, and Third-Party Management
Governance, Risk and Third-Party Management
This domain tests whether compliance runs as a programme with owners, reviews, risk analyses and managed providers.
Requirement 12 requires a security policy reviewed at least annually (12.1), targeted risk analyses for control frequencies not specified by the standard (12.3.1) and for each customized-approach control (12.3.2), defined PCI DSS responsibilities (12.4.1), documented scope with senior management confirmation where segmentation is used (12.5.2, 12.5.3), security awareness training (12.6) and personnel screening (12.7). Third parties are governed by 12.8 - maintained register, written agreements, due diligence, at least annual monitoring of compliance status, and clear statements of which requirements each provider covers - plus 12.9 written acknowledgment.
In cloud, governance means a responsibility matrix per service, contract clauses for breach notification, audit rights, data residency and exit, a register naming the account or service in scope, and a change process that triggers re-scoping when a new managed service is adopted.
Worked example. An annual review finds a payment-fraud vendor that receives CHD has had a lapsed attestation for eight months, and nobody noticed. The contract has no audit rights. Findings: 12.8.4 (monitoring compliance status at least annually) and 12.8.2 (agreements defining provider responsibilities) both fail. Remediation: obtain the current attestation, record risk acceptance at the right level, set a quarterly status check, and amend the contract. Reasoning: third-party risk remains your obligation even when the failure is the provider's.
Traps. Onboarding due diligence done once and never revisited; trusting a marketing compliance badge instead of an AOC; responsibility matrices not updated when a new managed service enters the architecture; provider incidents treated as outside your own incident and governance process.