Illustrative scenario: this practical guide uses a fictional Philippine BPO and client account. It is not a report of a CyberVantage360 client project or an achieved compliance outcome.
Assume a Philippine delivery team already handles order enquiries for an overseas retailer. The retailer now wants agents to help customers complete telephone payments. Existing call recording, quality review, support tickets and remote administration were designed around enquiries. The launch team must determine what changes when payment information enters that operation.
The useful question is not whether the BPO can obtain a generic certificate before the launch. It is whether the intended service, operating controls and evidence support the assessment and reporting arrangements required for that relationship. The following decisions show how to structure that work.
Write a launch brief that separates facts from assumptions
Describe what agents will actually do. Will the customer enter payment details into a separate payment service, speak them to an agent, or move between those paths? Identify who owns the payment account, who controls the agent workstation and who can change the telephony or payment configuration.
List the locations and working arrangements intended for the account. A delivery floor, a temporary training room and home working can have different access and oversight arrangements. Treat a proposed remote-working option as a design decision to assess, not an automatic extension of a site-based process.
Record the retailer’s request, the expected submission recipient and the launch dependencies. Separate a contractual target from a confirmed assessment timetable. Our PCI DSS scope guide provides a broader method for documenting boundaries and unresolved assumptions.
Follow one payment through the ordinary and exception paths
Map the conversation from the incoming call to payment completion and the agent’s closing note. Include the telephony platform, payment application, workstation, recordings, screen capture, transcripts, quality-review access and any exports. A diagram should show where information may appear, not only where the system designer intended it to go.
Then examine an interrupted call, a transfer to a supervisor, a rejected payment and a customer who starts reading card details before being directed to the approved process. These situations often expose a path that a successful demonstration misses.
In this scenario, a supervisor requests a screenshot to troubleshoot an agent’s problem. The team asks what the image could contain, where it would be stored and who could retrieve it. A support workflow can create a new copy even when the payment system itself is well controlled.
PCI SSC’s VoIP guidance treats relevant account-data traffic within an organisation’s infrastructure as part of the scoping question. Calling a platform “voice” or “cloud” does not remove the need to examine the actual systems, connections and responsibilities.
Resolve the recording design before training the agents
The retailer wants recordings for quality review. The launch team must reconcile that objective with how payment details are handled. PCI SSC FAQ 1210 explains that card verification values must not remain in digital audio after authorisation, even when encrypted. Its guidance addresses prevention, deletion and tightly controlled handling of exceptional technical constraints; those constraints are not a general permission to retain the data.
Evaluate the actual recording and payment design with the appropriate specialists. Test interruptions, transfers, failed transactions and changes to the recorder’s configuration. A written instruction to pause recording is insufficient evidence that every relevant path behaves as intended.
Use authorised test data and an agreed test plan. Do not introduce real card details into support tickets or demonstration recordings to prove that the process works. If evidence of inappropriate capture is discovered, use the established incident process and agree the handling of the material with the responsible teams.
Keep recording-retention obligations and PCI DSS requirements distinct. Any legal retention question needs its own review; do not assume a commercial preference for keeping calls resolves the payment-data issue.
Agree who operates each control and who checks it
Turn the shared operating model into a practical responsibility record. For each significant task, identify the performer, approver, evidence owner and escalation contact. In the fictional account, that discussion could cover:
- Retailer account owner: agrees the payment service and recipient requirements, approves changes to the customer journey and resolves commercial decisions.
- BPO operations: manages agent instructions, shift handovers, exceptions and role changes within its assigned scope.
- Technology owners: control the relevant workstations, access, integrations, recording settings and change records.
- External providers: supply evidence for the services and responsibilities they actually cover.
- Assessment participants: resolve scope and reporting questions within their appointed roles.
These are illustrative allocations, not fixed assignments for every contract. Confirm the real arrangement. A provider’s evidence is useful only if it covers the service being used and the responsibilities on which the customer relies. The third-party responsibility guide explains how to investigate those boundaries.
Prepare the people who work across queues and shifts
Agents may move between a non-payment enquiry queue and the new payment-enabled account. Decide how authorisation, instructions and supervision change with that move. Do not let access persist merely because a person remains employed by the same BPO.
Use role-based practice. An agent should know how to redirect a customer who starts providing data through an unsuitable channel. A supervisor should know how to handle an exception without requesting sensitive information in a chat message. A quality reviewer should understand the approved evidence available for review.
Make escalation workable across the actual client and delivery-team time zones. Name a route for urgent decisions when the usual account manager is unavailable; distinguish that internal arrangement from any externally promised response time. Record the agreed coverage rather than implying around-the-clock technical support.
Check understanding using realistic exercises and observed decisions. Attendance alone says little about whether a person can recognise an unusual payment request. Retain proportionate training and authorisation evidence without reproducing sensitive customer information.
Build a remediation plan around dependencies
Classify findings clearly. A missing diagram is an information gap; an inappropriate recording path is a design or operating problem. Each needs a different owner, output and completion test. A roadmap that groups both as “documentation” can conceal work that affects the launch decision.
Sequence the dependencies. The payment journey should be agreed before final agent scripts are written. Recording controls should be tested before quality-review instructions are approved. Provider responsibilities should be understood before the team assumes another organisation performs a required activity.
For each action, state the affected workflow, owner, target date, evidence expected and unresolved dependency. Use the PCI DSS gap-assessment guide to structure findings and closure criteria. A readiness plan should preserve uncertainty honestly rather than convert it into an unsupported promise of completion.
Rehearse the account without declaring a validation result
Conduct a controlled rehearsal after the necessary design and implementation work. Include an authorised agent, supervisor, technology owner and customer-side representative where appropriate. Follow the agreed normal and exception scenarios and retain the relevant results.
Consider a failed transfer during the payment step. The useful result is a clear account of what happened: which system handled the call, whether the intended safeguards operated, what the agent could see and which records were produced. If behaviour differs from the design, investigate it before repeating the exercise.
A launch review can then distinguish demonstrated controls, open work, exclusions from the rehearsal and decisions still needed from another party. Record the people authorised to make those decisions. A successful rehearsal is implementation evidence; it does not replace formal assessment or the required reporting.
Confirm the reporting route for this specific service
PCI SSC assigns validation and reporting-method decisions to compliance-accepting entities, typically payment brands and acquirers. The BPO and retailer should resolve the requirements for their respective roles and relationships. Do not copy a merchant questionnaire selection into a service-provider engagement without examining the applicable conditions.
Review any existing BPO validation evidence against the proposed account. The new service, technologies, locations or responsibilities may differ from the assessed scope. Neither a familiar provider name nor a previous report title establishes that the new arrangement is covered.
Where a QSA or other qualified provider is required, confirm that role and its engagement separately. Consulting deliverables and formal assessment responsibilities should be clear before scheduling. Our SAQ, ROC and AOC guide explains the reporting documents and the evidence behind their selection.
Keep the account boundary current after launch
Give changes an operating owner. A new dialler, a different payment provider, a quality-review export or permission to work from another location can change the facts behind earlier decisions. Put review triggers into the account’s change and onboarding processes.
Agree how the retailer and BPO will exchange relevant evidence and raise unresolved concerns. Use a record of actual service changes and actions, not a standing assertion that the account remains compliant forever. A completed project plan does not eliminate recurring responsibilities.
For the fictional retailer account, a useful follow-up would compare current access, workflow and provider arrangements with the approved launch baseline. The purpose is to find meaningful changes while there is still time to address them, rather than reconstruct the history only when a customer requests evidence.
Commission a bounded advisory engagement
A useful brief includes the proposed payment journey, client request, provider list, available scope evidence and the decisions delaying progress. CyberVantage360’s PCI DSS advisory service covers scoped discovery, remediation planning, responsibility and evidence workflows, and readiness preparation as agreed in the proposal.
Identify technical implementation, specialist testing, formal assessment and scanning that need separate arrangements. Agree deliverables, access to evidence, owners and acceptance conditions. This gives a Philippine BPO and its client a concrete work programme without treating the contract signature as proof of validation.
Reference basis
The following public PCI SSC FAQs were checked on 13 October 2026. They support the payment-security distinctions in this guide; the fictional launch scenario and practical planning suggestions are CyberVantage360’s original illustration.
- PCI SSC FAQ 1153: How does PCI DSS apply to VoIP?
- PCI SSC FAQ 1210: Are audio/voice recordings permitted to contain sensitive authentication data?
- PCI SSC FAQ 1312: How is an entity’s PCI DSS compliance impacted by using third-party service providers?
- PCI SSC FAQ 1473: roles of compliance-accepting entities and assessors in determining applicability.
Questions and answers
Does a BPO’s existing PCI DSS assessment automatically cover a new client account?
No. Compare the proposed service, technologies, locations and responsibilities with the actual assessed scope and supporting evidence. Resolve material differences and confirm the reporting expectations for the new relationship.
Can we keep card verification codes in encrypted call recordings?
PCI SSC FAQ 1210 explains that encryption does not make post-authorisation storage of those codes in digital audio permissible. Design the payment and recording process to avoid that capture and obtain specialist review of any exceptional constraints.
Does outsourcing the payment platform remove the BPO’s responsibilities?
No automatic conclusion follows. Determine which services and controls the provider covers and which responsibilities remain with the BPO and client. Relevant provider evidence and the actual operating arrangement need to support that allocation.
Is a readiness rehearsal the same as a PCI DSS assessment?
No. A rehearsal can produce useful implementation evidence and expose problems. It does not replace the applicable assessment, reporting documents or submission requirements set through the relevant compliance programme.
What should we share in an initial advisory enquiry?
Provide a high-level description of the payment journey, locations, providers, client request and unresolved decisions. Keep cardholder data, recordings and credentials out of the initial message; agree a suitable method for any later evidence review.
Define the account before committing to the launch
Share the proposed payment workflow and the client decision you need to support. Discuss a scoped PCI DSS readiness engagement with clear responsibilities, evidence needs and assessment dependencies.