Procedure 15 ADMINISTRATIVE
Third-Party / Vendor Management Policy — how Revique implements this rule today, and how an auditor verifies it.
Policy 15 · PCI DSS Req 12.8 · 0 of 4 policy statements fully met · AWS facts collected read-only 2026-08-13
← All 21 procedures
📘← Back to Policy 15 — Third-Party / Vendor Management PolicyThe rule this procedure implements
How Revique implements this today
Revique's largest third party is AWS itself, which processes and stores all CHD/PHI. The AWS shared-responsibility relationship is governed by the AWS Business Associate Addendum and AWS's own PCI DSS Attestation of Compliance, both obtainable through AWS Artifact. Beyond AWS, third-party integrations are visible in the estate as named service identities and integrations — for example an external monitoring user in the UAT account and SES SMTP identities in production — each of which represents a vendor relationship that should carry an agreement.
The rule against the current state
Each row takes a statement from Policy 15 and states what is actually configured. Meets = implemented as written. Partial = implemented, but not everywhere or not to the full standard. Gap = not implemented. N/A = not verifiable from infrastructure configuration.
| The rule | Current state | Verdict |
|---|
| A list of all third parties handling CHD/PHI is maintained | No vendor register document exists. Service identities in IAM hint at the vendor set but are not a substitute for a register. | Gap |
| A written agreement (BAA/TPSP) with each such vendor | The AWS agreement is available through AWS Artifact. Agreements with other vendors are not evidenced. | Partial |
| Vendor security and compliance reviewed at least annually | No review record exists. | Gap |
| Due diligence before engaging a new vendor | Procedural; not evidenced. | Partial |
🔍 Auditor verification — where to log in and what you will see
The AWS agreementsConsole → AWS Artifact → Agreements → the Business Associate Addendum status, and Reports → the current AWS PCI DSS Attestation of Compliance and SOC 2 report. Downloadable directly by an authorised account user.
Third-party identities in the estateConsole → IAM → Users, per account — non-human identities named for monitoring, SMTP and build integrations indicate the vendor surface. Cross-check each against the vendor register.
The vendor registerAsk the Security Officer for the register of third parties handling CHD/PHI and the corresponding signed agreements. Not stored in AWS.
Team process
The Security Officer maintains the vendor register and performs the annual review; management ensures written agreements are executed before a vendor is given access to CHD/PHI. New vendor access is provisioned only after due diligence and agreement, following the same least-privilege rules as any other identity (Procedure 07).
⚠️ Where reality does not meet the policy
- No vendor register exists. The policy's first requirement — maintain a list of all third parties handling CHD/PHI — is unmet, which makes the remaining three requirements unverifiable.
- Third-party service identities exist in the accounts with long-lived access keys, several last rotated in 2019–2022 and unused since (Procedure 07/08), with no corresponding agreement or review evidenced.
- The AWS BAA status should be confirmed and its acceptance recorded — it is obtainable from AWS Artifact but its execution is not currently evidenced in this documentation.
Evidence location. Vendor register, signed BAAs/TPSP agreements and annual review records are held by the Security Officer. AWS agreements are self-service in AWS Artifact.
📘Back to the PolicyPolicy 15 — Third-Party / Vendor Management Policy (PCI DSS Req 12.8)←