How does a PCI DSS audit run from scoping to ROC and AOC?
When a payment brand, acquirer or customer requires a Report on Compliance, a Qualified Security Assessor (QSA) leads the assessment, documents the results on the official ROC template, and the Attestation of Compliance (AOC) can only be signed once the ROC is final. The organization owns its controls and its compliance outcome. The QSA's role is to test them and report what it found. Before work starts, confirm which entity is the compliance-accepting entity for your situation, because it decides whether a ROC or an SAQ applies and may limit which requirements must be tested and documented in the ROC. Qualified Security Assessors are listed by the PCI SSC, and the assessor you choose should be checked against that list.
Scope, sampling and evidence maturity drive most of the timeline and effort. The QSA may test a representative sample or 100 percent of a population, but sampling must cover every variant of that population, so a well-defined inventory of systems, data flows and account populations shortens the discovery phase. Onsite testing remains the preferred method. Remote methods can substitute only when onsite work is impractical and the compliance-accepting entity allows it, and they may require a remote assessment addendum to the ROC. Evidence that is already produced on a recurring basis, such as access reviews, log reviews and change records, is faster to sample than evidence assembled for the first time during the assessment. Evidence from another audit, such as a SOC 2 examination, can help, but the QSA must confirm scope, mapping, timing and that the controls operate. The ROC completion date becomes the Date of Report once the QSA company and the assessed entity agree on the final version, and the AOC cannot precede it.
DeployOpen prepares systems, controls and evidence for the assessment, for example by documenting data flows, hardening the self-hosted platforms in the cardholder data environment and organizing logs and records for the QSA. DeployOpen does not issue the ROC or AOC, and it does not act as the QSA. Before you engage a partner, ask for a written scope that separates the preparation work from the assessor's work, and confirm the assessor's independence rules in writing, since consulting and assessment must remain separate. Timelines and fees depend on the written scope and should be confirmed with the QSA and the compliance-accepting entity rather than assumed from this page.
The phases of a PCI DSS ROC assessment and their outputs
A QSA-led ROC moves in a fixed sequence, from confirming who sets the validation requirement through scoping, sampling, evidence review and report drafting, to a final ROC and an AOC that can only be signed once the report is settled. Each phase closes with a defined output that both the assessed entity and the assessor can check.
Confirm the validation requirement with the compliance-accepting entity
Before any testing starts, the organization confirms with the compliance-accepting entity, typically a payment brand or acquirer, whether it must validate with a ROC or an SAQ and whether only a subset of requirements must be tested and documented in a ROC. Your QSA and your acquirer can settle this together, and it should be written down. The output is a confirmed validation type and, where applicable, a list of required requirements. Do not start scoping until this answer is on file, because it determines the depth of every later phase. Ask both parties to confirm timing in writing as well.
Define the cardholder data environment and scope statement
The organization identifies every system, network segment, person and process that stores, processes or transmits cardholder data, or that could affect the security of that environment, and documents the boundaries. The QSA reviews the boundary, data flows and connected systems, and challenges any exclusions. The output is a written scope statement, supported by network and data-flow diagrams and a system inventory. The assessment is only as sound as this document, so treat it as the first deliverable the QSA signs off on.
Agree the sampling approach for each population
For requirements that apply to a population of systems, users, devices or locations, the QSA decides whether to test a representative sample or 100 percent of it. Sampling is optional and must cover all variants of the population, so the assessor and the organization agree on how each population is split, such as by system type, location or configuration. The output is a sample list that names the items selected for each test, along with the rationale for any sample size. Ask your QSA to explain the sampling method before it is applied.
Collect and review evidence onsite or remotely
The QSA tests each in-scope requirement by interviewing staff, observing processes, inspecting configurations and reviewing records. Onsite work remains the preferred approach. Remote methods can replace it only when onsite work is not practical and the compliance-accepting entity allows it, under the PCI SSC remote assessment guidelines, with a remote assessment addendum to the ROC if requested. Evidence from other audits, such as a SOC 2 report, may be used only after the QSA independently confirms scope, mapping, timing and that controls are in place. The output is a set of workpapers that record what was tested, by whom, and what was found.
Draft the ROC and resolve findings
The QSA writes the ROC on the PCI SSC ROC template, recording the result for each tested requirement and the evidence behind it. The organization reviews the draft for factual accuracy, supplies missing evidence, and remediates any gaps the assessor identifies, or documents compensating controls where the standard allows them. The output is a draft ROC and an updated list of open items. The QSA keeps ultimate responsibility for the report and workpapers, even when colleagues at the same firm gathered parts of the evidence.
Finalize the ROC and set the Date of Report
When the QSA company and the assessed entity agree that the report is final, the completion date becomes the Date of Report. This is the point at which the results are settled, not the date the draft was first shared. The output is a final ROC with the Date of Report recorded. Confirm with your QSA how changes after the draft are version-controlled, so the final version is the one the compliance-accepting entity receives.
Sign the AOC once the ROC is final
The Attestation of Compliance declares the results documented in the accompanying ROC, so it cannot be given to the assessed entity until the ROC is finalized. The QSA enters the assessment date in both documents, and the entity signs the AOC as the attestation of its own status. The output is a signed AOC that matches the final ROC. Keep the AOC and ROC as a matched pair for any later sharing with customers or acquirers, and confirm with the compliance-accepting entity what it needs and in what format.
What makes a PCI DSS assessment longer or more expensive
A QSA's effort follows the size of the cardholder data environment and how much of it must be sampled and documented. The drivers below are linked: a wide scope multiplies samples, and weak evidence multiplies the hours spent proving each control. Most of them can be reduced before the assessor arrives.
Size and number of systems in scope
Every system that stores, processes or transmits cardholder data, or could affect its security, falls in scope and must be assessed. Each additional server, database, container cluster or network segment adds configuration checks, log reviews and access reviews. Ask which systems the scoping exercise excluded and why, and confirm that segmentation has been tested. Narrowing scope through tokenization or segmentation usually reduces effort more than any other single change.
Locations and payment channels
Each facility, store, call center or payment channel that accepts card data can add physical security checks, point-of-interaction device inspections and channel-specific data flows. An e-commerce page, a card-present terminal and a phone channel each need their own evidence. Consolidating channels onto one validated payment path, or documenting which locations never see card data, reduces the number of separate walkthroughs the assessor must perform.
Third parties touching cardholder data
Service providers that host, process or manage the environment for you bring their own responsibilities and evidence. The assessor must confirm which requirements the provider meets, which remain yours, and whether the provider's Attestation of Compliance covers the services you use. Maintain a current responsibility matrix and collect each provider's AOC before fieldwork starts, because missing provider evidence often stalls the assessment late in the schedule.
Sample populations and their variants
Where an assessor samples rather than tests every item, the sample must cover all variants of the population, such as different operating system builds, device types or user roles. Each extra variant adds samples to test. Before the assessment, ask the QSA which populations they expect to sample, and keep complete, sortable inventories so the assessor can draw from them without repeated requests.
Documented and repeatable evidence
Controls that run on a schedule and leave records are faster to test than controls that exist only in practice. An access review with a dated export, a signed approval and a follow-up ticket takes minutes to verify. A review done informally in a meeting takes hours to reconstruct. Check that each recurring task has an owner, a calendar entry, a retained output and a sample record the QSA can inspect.
Acceptance of evidence from other audits
A QSA cannot rely on SOC 2 reports directly, but can use their evidence after confirming scope, mapping, timing and that the controls operate. Where another auditor at the same firm collected the evidence, the QSA still owns the ROC and its workpapers. Map your SOC 2 or ISO 27001 control set to PCI DSS requirements in advance, agree with the QSA which evidence will be reused, and confirm the testing dates overlap the PCI assessment period.
Onsite, remote and evidence from other audits
Onsite assessment is the preferred approach under PCI DSS. The QSA works inside the organization's facilities and systems, observes controls operating, interviews staff, walks through the cardholder data environment and inspects configurations, logs and records directly. Assessors favor it because many requirements depend on what people actually do, such as physical access handling, change approvals and log reviews, and a screenshot or a policy document rarely proves that on its own.
- Direct observation: The QSA can watch a control operate, such as a badge check at a data room or a firewall rule change, instead of relying on a description.
- Live system inspection: Configurations, user lists and network paths can be reviewed on the systems themselves, with the assessor controlling what is sampled.
- Staff interviews: Responsible owners can explain their processes, which helps the assessor judge whether the documented procedure matches practice.
- Workpaper quality: Notes taken on site, with timestamps and named participants, form the basis of the ROC and the workpapers the QSA must keep.
Before the visit, confirm with your QSA which locations, data centers and cloud accounts they expect to visit and what access they need.
Remote assessment is allowed only when onsite work is not practical and the compliance-accepting entity permits it. The PCI SSC Remote Assessment Guidelines and Procedures govern how it is run. Permission is not automatic, so the first step is to ask the entity that accepts your validation whether remote methods are acceptable for your situation and which parts of the assessment they cover.
- Eligibility first: Confirm with the compliance-accepting entity before planning any remote testing, since the QSA cannot decide this alone.
- Remote assessment addendum: If requested, the ROC includes an addendum describing the remote methods used, what was tested that way and why onsite work was not practical.
- Evidence transfer: Screen shares, recorded walkthroughs and secure document exchanges must be controlled so that the evidence reviewed is authentic and complete.
- Coverage limits: Some controls, such as physical security, are hard to verify remotely, so expect the QSA to explain which items still need an onsite or alternative approach.
Ask your QSA to put the remote methods, their justification and the approval you obtained in writing before the assessment starts.
A QSA cannot rely on a SOC 2 or SOC 3 report directly as proof of PCI DSS compliance. The QSA can, however, use evidence gathered for those audits after independently confirming that the scope matches the cardholder data environment, that the controls map to PCI DSS requirements, that the timing covers the assessment period and that the controls actually operated. Responsibility stays with the QSA, including the ROC and the workpapers, even when an auditor at the same firm collected the evidence.
- Scope confirmation: The QSA must check that the systems covered by the other report are the same systems in the cardholder data environment.
- Mapping: Each control in the other report needs to be linked to the PCI DSS requirement it supports, with the gaps identified.
- Timing: Evidence must cover the period the PCI DSS assessment requires, and gaps between report periods need separate testing.
- Operating effectiveness: The QSA still confirms that controls ran, using samples and records, rather than accepting the other report's conclusion.
Before sharing reports, agree with your QSA which audit evidence they will accept and how they will document the mapping.
Assessors may test a representative sample of a population or 100 percent of it. Sampling is optional, so the QSA decides whether a full test is more practical for a given control. Whichever method is used, the sample must cover every variant of the population, such as different system types, locations, operating systems or user roles, so that no variant goes untested.
- Full population testing: A small or well-defined population, such as a list of firewall rules or privileged accounts, is often tested in full.
- Representative samples: Larger populations, such as workstations or change tickets, can be sampled if the sample is chosen to reflect the range of variants.
- Variant coverage: A sample of Windows servers that ignores Linux hosts or a remote site will not satisfy the requirement, so inventories must be accurate before sampling begins.
- Documented selection: The QSA records how samples were chosen and why, which the ROC must reflect.
- Complete populations: Give the QSA full, current inventories and logs so that the population they sample from is accurate.
Before the assessment, ask your QSA which populations they plan to sample and whether any will be tested in full.
When the Date of Report and the AOC are set
The Date of Report is the date the QSA company and the assessed entity agree that the ROC is final. It is not the date the assessor finished fieldwork or the date the first draft was sent. Until both parties accept the same version, the ROC is still in review, and the date should not be fixed. Confirm in the engagement letter who holds the final sign-off and what happens if the entity wants wording changed after the assessor has reviewed the evidence. Both sides should also agree how many review rounds are included, because each round adds time to the schedule. The ROC follows the official PCI DSS v4.0.1 ROC Template, which the PCI SSC released in August 2024. The Council revised the template after feedback that the v4.0 version took too long to complete and produced very large reports. Your assessor will still complete every section the template requires, so ask early which parts they will fill in from your evidence and which parts you are expected to draft. Ask for the template version in writing so the report and the AOC refer to the same release.
The Attestation of Compliance cannot be given to the entity before the ROC is final. The AOC declares the results documented in the accompanying ROC, so it must match that document exactly. The assessor enters the assessment date in both the ROC and the AOC, and those dates should be identical. If you receive a signed AOC while the ROC is still being edited, treat it as a document to be corrected before anyone relies on it. Check the dates, the results and the scope statement against the final ROC before you share either one. ROCs and scan results are not sent to PCI SSC by default. The compliance-accepting entity, usually a payment brand or acquirer, is the party that receives validation evidence, so agree in writing what they need, in what form, and by what date. Also agree who may share the ROC with customers, auditors or partners, and what redaction is allowed. Your sharing agreement should be settled before the assessment starts, not when the first customer asks for the report.
ROC or SAQ: which validation path fits
This table compares the two validation paths PCI DSS allows, showing who makes the choice, who signs the result and what each path fits. Read it first to confirm which path your compliance-accepting entity expects, then check the detail rows before you plan the assessment.
| Option | Who decides it | Who signs and what it fits |
|---|---|---|
| Report on Compliance by a QSA | The compliance-accepting entity, typically a payment brand or acquirer, requires a ROC or requires that a subset of requirements be documented in one. | A Qualified Security Assessor leads the assessment and completes the ROC, then the AOC is signed after the Date of Report. Fits entities that must be assessed independently by a QSA. |
| Self-Assessment Questionnaire with AOC | The compliance-accepting entity accepts an SAQ, and the entity's eligibility determines which SAQ type applies. | The organization completes the official SAQ and signs the AOC itself. Fits entities whose environment qualifies for a specific SAQ type. There is no QSA-led ROC. |
| Who completes the work | For a ROC, a QSA company performs the assessment and keeps responsibility for the report and workpapers. | For an SAQ, the organization's own staff answer the questions, and an ISA or QSA may help if the entity uses one. |
| Independent assessor involvement | Set by the compliance-accepting entity and the QSA's independence rules. | A ROC always involves an independent QSA. An SAQ involves an assessor only when the organization chooses to bring one in. |
| Evidence and testing depth | Set by the ROC template and the assessor's sampling and testing decisions. | Set by the SAQ questions. Ask the compliance-accepting entity whether it expects supporting evidence to be retained for review. |
| Signature timing | Governed by the ROC Date of Report, which is agreed by the QSA company and the assessed entity. | The AOC is signed once the SAQ answers are complete and accurate. Confirm the sequence with the compliance-accepting entity. |
| Ask before you start | Confirm in writing which path and which requirements the compliance-accepting entity requires. | Confirm which SAQ type your eligibility supports and whether the acquirer accepts it for your payment channel. |
What usually delays a PCI DSS assessment
Most delays in a PCI DSS assessment come from decisions made late or left unowned: scope, evidence, sampling, remote testing, reliance on other reports and report drafting. Each card names the step that prevents the delay and the party who should own it, so the QSA's time goes to testing rather than to rework.
Scope defined after fieldwork starts
When the cardholder data environment is only mapped once the assessor arrives, systems turn up that were never tested, and the assessment expands mid-stream. Agree a written scope with the QSA before testing begins, covering systems, network segments, third parties and data flows, and confirm it with the compliance-accepting entity where it has a say. The scope owner is the assessed entity's compliance lead, who signs off the data-flow and network diagrams the QSA will test against.
Evidence scattered without an owner
Logs, change tickets, access reviews and vendor attestations often sit with different teams, and nobody knows which one holds the current copy. Assign a named evidence owner for each requirement, keep a single index that points to the location and date of each artifact, and agree a retrieval process before the assessment window opens. The evidence index is owned by the compliance lead, with each control owner responsible for keeping their own artifacts current.
Sampling populations not listed in advance
Assessors may test a representative sample or the full population, but the sample has to cover every variant of that population. If the population list is not ready, the QSA cannot select samples, and each request turns into a new round of questions. Prepare complete populations for items such as user accounts, firewall rules, systems and change records, and show the variants within each (for example, different operating systems or payment channels). The population lists are owned by the control owners who run those systems.
Remote testing assumed without approval
Remote assessment methods can substitute for onsite work only when onsite work is not practical and the compliance-accepting entity allows it, following the PCI SSC remote assessment guidance. Teams that plan remote fieldwork without that approval may find the QSA must travel or the ROC must be reworked. Ask the compliance-accepting entity in writing whether remote methods are permitted, and if so, whether the ROC needs a remote assessment addendum. The approval request is owned by the assessed entity's compliance lead, with the QSA confirming the method in the engagement letter.
Relying on a SOC 2 report unchecked
A QSA cannot rely on a SOC 2 or SOC 3 report as validation, but can use its evidence after confirming the scope, control mapping and timing match the PCI DSS requirements in question. Reports that cover a different system boundary or a period that does not overlap the assessment window cause re-testing. Before sharing a SOC 2 report, map each relevant control to the PCI DSS requirement, note the audit period, and identify any gaps the QSA must test directly. The mapping is owned by the compliance lead, reviewed with the QSA before the evidence is shared.
ROC drafted before scope is agreed
Writing report sections while scope, sampling or compensating control decisions are still open means text must be rewritten when those decisions change. The Date of Report is set when the QSA company and the assessed entity agree on the final version, so a draft built on an unsettled scope delays that agreement. Freeze the scope and key decisions in writing first, then let the QSA draft against them. The final scope sign-off is owned by the assessed entity's executive sponsor, and the QSA owns the drafting and the workpapers.
Who owns each part of the assessment
Your organization owns the PCI DSS controls, the decision about what is in scope, and the evidence that the controls work every day. No outside party can accept that accountability on your behalf. Your team defines the cardholder data environment, confirms which systems, people and third parties can affect it, and maintains the inventories and data-flow diagrams an assessor will ask for. For an SAQ, your team also decides which questionnaire applies and makes the final call on whether to sign the Attestation of Compliance.
- Scope definition: Decide and document which systems, networks, people and service providers are in the CDE or could affect it.
- Populations: Keep current lists of the items an assessor may sample, such as user accounts, firewall rules, change records and personnel.
- Evidence: Generate logs, reviews, tickets and configuration records as part of normal operations, not only for the audit.
- Remediation ownership: Assign named owners and dates for any gaps, and track compensating controls where they are used.
- Signing decisions: For an SAQ, your authorized officer signs the AOC. For a ROC, the AOC is completed alongside the assessor's report.
Before engagement, confirm with your acquirer or the payment brand which validation type applies to you and whether they require a subset of requirements in the ROC.
An implementation partner such as DeployOpen helps prepare the environment and the proof that it meets the requirements. Work is typically scoped in writing before it starts, and the partner works inside your infrastructure. The partner does not test your controls for the assessor, does not decide scope on your behalf, and does not sign or issue any validation document. Its value lies in building and documenting systems so that your team and the assessor can verify them efficiently.
- Systems and configuration: Harden self-hosted platforms, document configurations and set up logging, access control and backups where scoped.
- Documentation: Draft network and data-flow diagrams, runbooks and policy content for your team to review and approve.
- Evidence preparation: Organize logs, scan outputs and change records so that they map to the requirement being tested.
- Security testing: Run penetration tests or vulnerability assessments where they are part of the agreed scope, and report findings to your team.
- Handover: Deliver artifacts your staff can maintain after the engagement closes.
Ask the partner to state in writing what it will not do, including any role in the assessment itself. Confirm that the partner is not also the assessor for the same environment.
A Qualified Security Assessor (QSA) company is the independent party that tests your environment against PCI DSS and documents the results in a Report on Compliance. The QSA decides how to sample populations, which evidence to accept, and whether each requirement is met. The QSA keeps ultimate responsibility for the ROC and its workpapers, even when colleagues at the same firm collect evidence for another attestation. Only the QSA company can issue the ROC and the AOC that accompanies it.
- Testing: Examine configurations, observe processes and interview staff against each requirement in scope.
- Sampling: Choose representative samples or test 100 percent of a population, covering all variants.
- Reporting: Write the ROC on the official template and agree the final version with the assessed entity.
- Date of Report: Set it jointly with the entity when the final version is agreed.
- AOC signature: Complete and sign the AOC only once the ROC is final, entering the assessment date in both documents.
Confirm the QSA's independence before engagement and ask how it will use evidence gathered by any other audit, such as a SOC 2 examination, since the QSA must independently confirm scope, mapping, timing and that controls are in place.
What must be in place before the assessor arrives
A QSA can only test what it can see and trace. The six items below connect scope, inventory, samples, policies, recurring evidence and ownership, and each one should be dry-run with someone outside the team before fieldwork starts.
Agreed scope and current diagrams
Write down which systems store, process or transmit cardholder data, or could affect that environment, and get the scope agreed with the assessor in writing before fieldwork. Pair it with a current network diagram and data-flow diagram that match the scope statement. To check it, trace one payment transaction from entry to storage and confirm every hop appears on both diagrams. The scope sign-off should come from the accountable executive and the assessor, not only from the internal team.
Component and third-party inventory
Maintain an inventory of every system component in scope, along with each third party that hosts, connects to or can affect the cardholder data environment. Record owner, location, function and whether the component is in scope. The dry run is to pick ten random components from the network and confirm each appears in the inventory with a current owner. Security and procurement leads should jointly approve the list each review cycle.
Sample-ready populations
Assessors may test a representative sample or the full population, and any sample must cover all variants of that population (PCI SSC FAQ 1569). Prepare a complete list for each population, such as user accounts, firewall rule sets, cardholder data stores and personnel with access, with the attributes needed to select from it. Ask the assessor which populations they will sample so you can confirm each list is complete before they arrive. Sign-off belongs to the control owner who generated the list.
Policies and procedures mapped to requirements
Each of the 12 principal requirements needs a policy or procedure that someone can find and follow. Map every document to the second-level requirements it supports so the assessor can move from requirement to evidence without guessing. To check it, pick one requirement and confirm the named procedure describes what staff actually do today. Approval should come from the executive who owns the security program, with a dated revision history.
Evidence of recurring tasks
Many requirements depend on activities that repeat, such as log reviews, access reviews, vulnerability scans, penetration tests and security training. Assessors look for records showing each task ran on schedule and that someone acted on the findings. Build a calendar of these tasks and confirm that the last cycle's records are complete. Missed periodic activities cannot be covered by a compensating control, so a gap found during the dry run should be fixed before the assessment, not explained during it.
Named owner for each requirement area
Assign one named contact to each of the 12 requirement areas, with a backup. The contact answers assessor questions, gathers evidence and confirms that the evidence matches the current environment. During the dry run, ask each contact to walk an outsider through their evidence set without help from the team. The compliance lead should sign off the roster, and the list should be reissued whenever a role changes.
PCI DSS assessment questions buyers ask
What does a QSA assessment cost and what drives the price?
A QSA assessment is priced by the assessor, so the figure depends on the quote, not on a standard rate. The cost has three parts: the assessor's time for scoping, testing, interviews and report writing; the number of systems, locations and payment channels in scope; and any remote or onsite travel. Scope is the largest driver. A narrow cardholder data environment with well-documented network diagrams and clear data flows costs less to test than a sprawling estate with stray card data and many third parties. Ask each QSA for a written quote that lists the assessment phases, the number of locations and the assumed sampling approach, and ask whether a pre-assessment readiness review is billed separately. Preparation work done by your team or an implementation partner is a separate cost, and it is usually one-time, while annual revalidation recurs.
How long does a PCI DSS assessment take?
Timing depends on scope, the quality of your evidence and how quickly your team answers assessor requests, so no fixed duration applies to every organization. Assessments tend to move faster when system inventories, network and data-flow diagrams, policies and recurring task records already exist and are current. Delays usually come from unclear scope, missing evidence for periodic activities such as log reviews or access reviews, and late remediation of findings. Ask the QSA to map the phases to calendar dates in writing, including the scoping call, evidence review, testing window, draft ROC, client review and final report. Confirm with the QSA how long the Date of Report and AOC signing take in practice, since the ROC must be finalized before the AOC can be signed.
Can our own team perform the PCI DSS assessment?
Your team can complete an SAQ, but a ROC must be completed by a Qualified Security Assessor. For an SAQ, the entity completes the questionnaire and signs the Attestation of Compliance itself, provided it is eligible for that SAQ type and the compliance-accepting entity accepts it. An employee who holds PCI Internal Security Assessor (ISA) qualification can help prepare an SAQ and, where the program and the compliance-accepting entity allow it, support validation work, but that role has limits and does not replace an independent QSA. Compliance-accepting entities, typically payment brands and acquirers, decide whether you validate with a ROC or an SAQ, so confirm that choice with your acquirer before you start. Internal staff can also run the controls and gather evidence, which is the work most organizations keep in-house.
Can a SOC 2 report replace PCI DSS testing?
No. A SOC 2 report cannot replace PCI DSS testing, but a QSA may use its evidence after doing independent checks. The assessor must first confirm that the SOC 2 scope covers the same systems and cardholder data environment, that the mapping between criteria and PCI DSS requirements holds, that the testing period overlaps the assessment period, and that the controls are actually in place today. Evidence from another auditor at the same firm is still the QSA's responsibility, and the QSA keeps ultimate responsibility for the ROC and its workpapers. To make this work, keep SOC 2 control evidence organized by system and date so the QSA can trace each item to PCI DSS requirements. Agree the reuse approach with the QSA before fieldwork begins.
Is a remote PCI DSS assessment allowed?
A remote assessment is allowed only when onsite work is not practical and the compliance-accepting entity approves it. Onsite assessments remain the preferred approach. When remote methods are used, the assessor follows the PCI SSC Remote Assessment Guidelines and Procedures, and the ROC may need a remote assessment addendum if the compliance-accepting entity requests one. Before agreeing to remote testing, confirm with your acquirer or payment brand that they accept it for your validation. Also agree how screen-sharing, document exchange and interviews will be recorded, since the assessor must still be able to observe configurations and confirm controls. Physical controls, such as those covering facilities and card-present devices, often need in-person observation.
When can the Attestation of Compliance be signed?
The Attestation of Compliance can be signed only after the ROC is final. The AOC declares the results documented in the accompanying ROC, and the assessor enters the assessment date in both documents, so the AOC cannot precede the finished report. The completion point for a ROC is its Date of Report, which is the date the QSA company and the assessed entity agree on the final version. Ask the QSA for a draft AOC alongside the draft ROC so you can review the declared status before the final version is agreed. Do not send an AOC to a customer, acquirer or partner on the strength of a draft, and do not treat an internal checklist or a certificate as a substitute for a signed AOC.
Can an implementation partner issue the ROC?
No. Only the independent QSA company that performed the assessment can complete and sign the ROC, and only the assessor can declare the results. An implementation partner such as DeployOpen can plan and implement self-hosted open-source platforms inside your infrastructure, prepare systems, configurations and evidence for assessment, and support remediation, but it does not issue audit reports, attestations or certifications. Keeping this separation protects your validation: assessors need to test controls that were prepared independently of the assessment. Confirm with your QSA which preparation work they are willing to review and which activities would affect their independence, and record the division of responsibilities in your engagement documents before work starts.
How DeployOpen prepares systems and evidence for your assessment
DeployOpen prepares the systems, controls and evidence that a QSA will test during a PCI DSS assessment, working inside your own infrastructure. DeployOpen does not issue the ROC or AOC; the independent QSA does, and the organization owns its controls and the final scope decision.
How we scope
- Engagements are fixed-scope, with the systems, deliverables and timelines agreed in writing before work starts.
- We document the cardholder data environment boundaries and data flows so your QSA can confirm scope on a shared basis.
- Your QSA or compliance-accepting entity confirms the validation type, so we confirm that before scoping begins.
How we build
- We implement and harden the open-source platforms in scope within your cloud accounts, data centers or air-gapped networks.
- We configure logging, access control and file integrity monitoring so each requirement produces evidence an assessor can sample.
- We run security testing against in-scope applications, APIs and infrastructure, and document findings and remediation status.
How we hand over
- You receive documentation of configurations, data flows, system inventories and the evidence mapped to each requirement tested.
- We prepare evidence packages for the QSA, but the QSA decides what to sample, test and report in the ROC.
- The ROC, its Date of Report and the AOC are issued by your QSA and your organization, not by DeployOpen.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the assessment.
- We help keep the evidence current between assessments, including recurring tasks and changes to the cardholder data environment.
- Ask any provider to confirm in writing which parts of the assessment remain with your team and which are delivered by DeployOpen.
