Who must own PCI DSS roles and responsibilities, and how an assessor checks them
The organization owns every PCI DSS role and responsibility, and the assessor verifies the written records rather than accepting job titles. When a payment brand, acquirer or customer asks who is accountable for PCI DSS, the answer must be a documented assignment that names a person or function for each activity, plus evidence that those people understand their part. Requirement 1.1.2 expects roles for Requirement 1 activities to be documented, assigned and understood. Requirement 12.1.3 expects security roles and responsibilities to be defined for all personnel, and Requirement 12.1.4 expects responsibility to be assigned to a CISO or another knowledgeable executive. A RACI matrix is a practical way to show this, but the assessor will test whether the matrix matches what staff actually do.
An implementation partner can help prepare the RACI, draft role descriptions and gather the evidence that roles are in use, such as signed acknowledgments and meeting records. The partner cannot assign the roles for you or sign off on them as compliant. Only the Qualified Security Assessor (QSA) or other independent assessor issues the Report on Compliance (ROC) or Attestation of Compliance (AOC). Confirm early with your assessor which format of roles evidence they will accept, because some ask for the RACI as a standalone document and others review it within the policy set.
The PCI Security Standards Council does not enforce compliance or impose penalties. The individual payment brands decide which entities must validate and run any enforcement programs, so the first step is to confirm your validation requirements with your acquirer or the relevant brand before you assign roles. Ask those parties which validation level and reporting type applies to you, and record their answer in your compliance file so the scope of the role assignments is clear from the start.
Which roles PCI DSS expects you to name
PCI DSS does not give you one job title to fill. It expects named owners at several levels, from the executive accountable for cardholder data protection to the reviewers who confirm routine tasks happened. Each card below covers one role, what an assessor will ask to see, and the record that proves the assignment.
Executive with security responsibility
Requirement 12.1.4 expects responsibility for information security to be assigned to a chief information security officer or another knowledgeable executive. Assessors will ask who holds that role and whether the assignment is written down, approved and known to the people it affects. Check that the named person has the authority and budget to act, and that the assignment appears in the information security policy or an equivalent governance document. Record the appointment in board or executive minutes, and keep it current when the role changes hands.
Personnel with defined security roles
Requirement 12.1.3 expects security responsibilities to be defined for all personnel, not only the security team. Assessors will sample staff from operations, development, support and facilities and ask what each person is expected to do for cardholder data protection. A job description, a role matrix or an acknowledgment signed during onboarding can each serve as evidence. Check that the role descriptions match how work is actually done, because a mismatch is the usual reason this item fails sampling.
Requirement 1 role owners
Requirement 1.1.2 expects roles and responsibilities for the network security control activities to be documented, assigned and understood. In practice this means naming who approves firewall and network security control rule changes, who reviews them, and who maintains the network and data-flow diagrams. Assessors will ask for the documented assignments and then test whether the named people perform the work. Record each owner in a responsibility matrix that maps every Requirement 1 activity to one accountable person and one or more responsible people.
Key custodians
Requirement 3.7 covers key management and includes a sub-requirement for custodian acknowledgment, meaning people who hold key components or manage keys must formally accept that responsibility. Assessors will ask for a list of custodians, their signed acknowledgments and evidence of split knowledge and dual control for manual key operations. Check that custodians are named individuals rather than shared teams, and that the list is updated when someone leaves or changes duties. Keep the signed acknowledgments with the key management records so an assessor can trace each key to its custodians.
Compliance program owners for service providers
Requirement 12.4.1 applies only to service providers and expects executive management to establish responsibility for protecting cardholder data and a PCI DSS compliance program with a charter. Assessors will ask for the charter, the named executive sponsor and the program owner who runs day-to-day activity. Check that the charter states the scope of the program and the escalation path, and that executive management has formally approved it. The charter is the primary record that proves this role exists.
Independent reviewers of routine tasks
Requirement 12.4.2 requires service providers to confirm, at least every three months, that daily and recurring security tasks are performed, such as log reviews, network security control configuration reviews and change management. The reviewer must be someone other than the person doing the work. Assessors will ask who the reviewers are, how the confirmations are documented under Requirement 12.4.2.1, and how independence is ensured. Check that reviewers have access to the evidence they are confirming, and that each review produces a dated record with findings and follow-up actions.
Building a RACI record an assessor can test
A RACI record is only useful to an assessor if every PCI DSS task in it names a specific person or role as responsible and a single accountable owner, with a date showing when someone approved the assignment. Start from the requirement level: for each requirement, list the policies and procedures, the recurring tasks and the records they produce, then assign one row per item. Where a task is performed by a team, name the role and the person who holds it at the time of assessment, and keep the consulted and informed columns for the reviewers and recipients the task depends on. The organization chooses the format, whether a spreadsheet, a governance tool or a document register, but the assessor will judge whether the record is complete, current and matches what staff actually do.
Three elements make a RACI verifiable. The first is a dated approval, signed or recorded by the executive who holds accountability for the program, so the assignments can be shown to be in force on the assessment date. The second is an evidence location for each task, meaning the system, folder or ticket queue where the output sits, such as a log review record or a change approval. Without that pointer, the assessor cannot test the task. The third is alignment with the information security policy review cycle required by Requirement 12.1.2, which calls for the policy to be reviewed at least every 12 months. Schedule the RACI review in the same cycle so ownership changes trigger an update before the next review, not after an assessor finds a departed owner.
Confirm three things before you finalize the record. Check that no task has a responsible party who lacks the access or authority to perform it, since assessors test whether the named person actually does the work. Check that every role listed exists in your organizational chart or contracts, including third parties where a provider performs a task. Finally, ask your QSA or internal assessor which evidence format they expect for the roles in scope, because acceptable formats for approval and location records vary by engagement. Treat the RACI as a living control: when staff change, when a system moves into or out of scope, or when a significant change occurs, update the matrix and retain the prior version.
How service providers run the compliance program and quarterly reviews
Requirement 12.4.1 applies only to service providers. It asks that executive management formally take responsibility for protecting cardholder data and that the organization run a PCI DSS compliance program backed by a charter. The charter is the document that makes the program real: it names the program owner, states the scope of the program, and gives the program authority to set expectations across teams. An assessor will look for the executive's name, the approval date and evidence that the charter has been reviewed and kept current. In practice, the program owner is often the CISO or a compliance lead who reports to an executive, but the standard expects the accountability to sit at executive level.
- Named executive owner: Record which executive is accountable for cardholder data protection and confirm that the name appears in the charter and in the minutes or sign-off record.
- Charter contents: Cover purpose, scope of the compliance program, authority of the program owner, and the reporting line to executive management.
- Approval evidence: Keep a signed or recorded approval from executive management, with a date that matches the current charter version.
- Review cycle: Set how often the charter is reviewed and document each review, including changes to scope after significant changes in the environment.
- Resourcing statement: Record who funds and staffs the program, so the charter is not only a paper commitment.
Before an assessment, confirm that the charter's named owner and the approval record match the current org chart and that the scope statement still reflects the cardholder data environment.
Requirement 12.4.2 requires service providers to confirm, at least every three months, that defined security tasks are performed as intended. The confirmation must come from reviewers who are not the people doing the work. This separation is the core of the requirement: the operator cannot grade its own homework. The tasks named in the requirement include daily log reviews, reviews of network security control configurations, application of configuration standards, response to security alerts and change management. Each quarter, the reviewer checks a sample of those activities against the expected outcome and records the result.
- Daily log reviews: Confirm that logs were reviewed each day, that exceptions were investigated, and that the reviewer did not perform the review being checked.
- Network security control reviews: Check that firewall and similar rule sets were reviewed and that unexpected changes were identified.
- Configuration standards: Confirm that new and changed systems were built to the approved standard and that deviations were approved.
- Alert response: Sample alerts and confirm they were triaged, escalated where needed and closed with a documented outcome.
- Change management: Check that changes followed the approved process, with testing and approval recorded before deployment.
Set the reviewer roster so that each quarter's reviewer is independent of the task owner, and confirm that the roster is kept with the review records.
Requirement 12.4.2.1 requires documentation of the quarterly reviews. A confirmation that exists only in someone's memory does not satisfy the requirement. The documentation should show what was reviewed, the period covered, the sample selected, the findings, who performed the review, who was independent of the work, and what was done about any exceptions. An assessor will select several quarters and check that the records exist, are complete and show follow-up on problems. Records should be stored where the reviewer and the assessor can retrieve them, and their integrity should be protected like other security records.
- Review record fields: Capture the review period, the tasks covered, the sample size and selection method, and the reviewer's name and role.
- Independence statement: Note on each record that the reviewer did not perform the work under review.
- Exception tracking: Log every failed check with an owner, a remediation date and a closure note.
- Consistent cadence: Show a review for each three-month period across the year, with no gaps that an assessor could sample.
- Retention and access: Store records in a controlled location with access limited to those who need it, and confirm the retention period with your assessor.
When preparing for assessment, pull the last four quarterly records and check that each one names an independent reviewer and closes every exception it raised.
Requirement 12.4 does not apply to every organization that handles card data. It applies to service providers, so the first question is whether the organization meets that definition for the service it delivers. An entity that only accepts card payments for its own goods or services, without managing payment environments for others, usually sits outside this requirement. Confirm the status with the payment brands or your acquirer and with your assessor, because the classification determines which sub-requirements appear in the Report on Compliance or the service provider self-assessment questionnaire.
- Classification check: Document whether the organization is a service provider for each service line, not only at the company level.
- Shared responsibility: Where a customer relies on your services, record which tasks in this section you perform and which the customer performs.
- Illustrative example: A managed hosting provider that runs firewalls for customer payment systems would normally be expected to run this program, while a merchant that outsources only its checkout page may not.
- Scope alignment: Make sure the quarterly reviews cover the systems in the scope confirmed for the service you deliver.
- Questions for your assessor: Ask which service provider SAQ or report template applies and how sampled review records will be requested.
Before committing resources, confirm the service provider classification in writing with your acquirer or assessor, since it decides whether this entire program is required.
Key custodian acknowledgments and split knowledge
Requirement 3.7 governs the people who hold cryptographic keys that protect stored account data. The cards below cover the roles those people must accept in writing, how key-handling duties are split so no single person controls a key, and what a service provider owes its customers about key handling.
What a custodian acknowledgment contains
Requirement 3.7.8 expects each key custodian to formally acknowledge, in writing or electronically, that they understand and accept the responsibilities for the keys they handle. A useful acknowledgment names the custodian, the key or key component, the custodian's duties, the date, and the signing authority's approval. It should reference the key management procedures the custodian must follow. Check that each acknowledgment is signed before the custodian receives key material, and that the wording matches the procedures currently in force.
Keeping the custodian list current
The custodian list is the document an assessor compares against key logs and access records, so it must change when people change. Build a departure step into offboarding: revoke the custodian's key access, reassign or re-split the key components they held, and record the change with a date. Ask your team how a custodian who leaves at short notice is replaced without a single person holding a full key. Stale lists are a common finding because the list and the access system drift apart.
Split knowledge and dual control
Requirement 3.7.6 requires that where manual cleartext key operations occur, they use split knowledge and dual control, so that no single person can access or use the full key. Document which operations are manual, which people hold each component, and how the two-person rule is enforced in the tooling. Confirm with your assessor and key management vendor whether any operation in your environment qualifies as manual. Keep the cryptographic design details for the Requirement 3 pages.
Assigning split-knowledge roles
Each key component should have a named holder, and the holders should not share a reporting line that would let one manager gather all components. Record the role assignment in the RACI, showing who generates, distributes, stores and reconstructs each key. Illustrative example: a small team might assign the two components to a payments engineer and a security lead who report to different executives. Review the assignments whenever team membership changes.
Service provider customer guidance
Requirement 3.7.9 applies to service providers, who must give customers written guidance on how to store, distribute and change keys that the provider does not manage. Confirm the guidance covers what the customer is responsible for and what the provider handles, and that it is kept current with the provider's key procedures. Ask whether customer guidance is versioned and how customers are notified of changes.
What the assessor samples
An assessor typically samples a set of custodians and asks for their signed acknowledgments, the current custodian list, evidence of split knowledge for manual operations, and records of any custodian change. Gather these together before the assessment so the samples match. Confirm with your QSA which samples they will request and how far back the records must go.
Separating duties when the team is small
The SAQ D note to Requirement 6.5.4 lets a small team meet role separation through procedural controls instead of separate people. Requirement 6.5.4 expects the people who build and deploy changes to be separated from the people who approve them and from production, so one person cannot push an unreviewed change into the cardholder data environment. When a team is too small to staff that split, the note allows a documented procedure to do the work instead. The common example is a developer who holds a separate user-level account for production work, distinct from the account used for development, with production activity logged and reviewed. Treat this as an allowance the assessor may accept, not a waiver. The requirement still applies, and the organization must show the separation is operating on the day it is tested.
Document the procedural control in the RACI record and in the policy or procedure that governs change management, not in a side email. The entry should name the roles involved, the specific accounts or privileges that are separated, the compensating review (for example, who reviews production change logs and how often), and the approver of the arrangement. The approver should be a person with authority over the change process, typically the executive with security responsibility or the change board chair, and the approval should be dated and reviewed when the team composition changes. Ask your assessor early which evidence they expect, since acceptance depends on how the procedure is worded and how it runs.
An assessor tests this by sampling real changes, not by reading the policy. Expect them to pick recent production changes and trace each one from request to development to review to deployment, checking that the developer's production activity used the separate account, that the review was performed by someone other than the author, and that the logs for the review exist. They will also check that the procedure matches what engineers actually do, including emergency changes made outside the normal path. Confirm with your assessor how they plan to sample, and run this trace yourself before the assessment so that any gap is found by your team first.
Assigning and evidencing roles step by step
This sequence turns PCI DSS responsibilities from informal understanding into named owners, approved records and recurring reviews that an assessor can test. Each phase ends with a document or sign-off that the next phase depends on.
Confirm scope and the applicable requirements
Start by fixing which systems, people and third parties fall inside the cardholder data environment and which validation path applies, either a Self-Assessment Questionnaire or a Report on Compliance completed by a Qualified Security Assessor. Requirement 12.4 applies only to service providers, so the path decides which role records you must produce. The output is a short scope statement with the validation path named, reviewed by the people who own payment systems. Ask your acquirer or payment brand which validation level and path applies to you, because the brands, not the Council, decide that.
Name the security executive and control owners
Executive management assigns responsibility for information security to a CISO or another knowledgeable executive, as Requirement 12.1.4 requires. Then assign an accountable owner for each requirement area, such as network security, access management, logging and vulnerability management, using the names of people rather than team labels. The output is a written assignment signed or approved by an executive, plus a list of owners and their backups. Confirm that every owner accepts the role in writing before the next phase starts.
Draft the RACI matrix and compliance charter
Build a RACI matrix that maps each responsibility under Requirements 1 to 12 to one accountable person, the people responsible for doing the work, those consulted and those informed. Service providers also document an executive-approved charter for the PCI DSS compliance program under Requirement 12.4.1. Check that each activity has exactly one accountable owner and that the reviewers named for oversight are not the people doing the work. The output is a draft matrix and charter with a version number and an owner for the document itself.
Obtain approvals and key custodian acknowledgments
Route the RACI matrix and charter to executive management for formal approval, and record the date and approver. Where cryptographic keys are in scope, collect written acknowledgments from each key custodian confirming they understand and accept their responsibilities under Requirement 3.7. Store signed copies in a controlled repository. The output is an approved, versioned document set and a custodian acknowledgment file that an assessor can sample directly.
Train staff on their assigned roles
Brief each named owner, custodian and responsible team on the specific duties assigned to them, and make sure the relevant policies and procedures are available to them. Training should describe what each person must do, what evidence they produce and whom they escalate to. Record attendance and the materials used. The output is a training record for each role holder that links to the approved matrix. Where a small team has one person covering several roles, document that person's separated duties and any procedural controls used to keep them apart.
Schedule recurring reviews and oversight checks
Put the reviews that confirm roles are being performed on the compliance calendar. Service providers schedule reviews at least every three months by reviewers other than those doing the work, and the information security policy is reviewed at least every 12 months. Record the reviewer, the date, the findings and any corrective action in a standing log. Assign an owner for keeping the matrix current when staff change or systems are added. The output is a calendar entry for each review and a review log that shows the reviews actually happened.
Who owns the roles, who prepares the evidence, and who assesses it
Your organization owns PCI DSS. Named individuals on your side must decide who is responsible for each requirement, approve the responsibility assignment matrix (RACI), and sign off on the policies that describe those duties. Requirement 12.1.4 expects responsibility for security to be assigned to a CISO or another knowledgeable executive, and an assessor will look for that person by name in your records, not in a generic team mailbox. Your team also keeps the program running after the assessment is over.
- Executive accountability: Record the executive with security responsibility, the reporting line to senior management, and the charter or terms of reference that give the role authority.
- Approved RACI: Confirm that each Requirement 1 to 12 activity has one accountable owner, a responsible operator, and a reviewer who is not the person doing the work.
- Key custodian acknowledgments: Collect signed acknowledgments from anyone holding cryptographic key components, as Requirement 3.7 expects, and store them with the key records.
- Personnel awareness: Confirm that role descriptions reach the people who perform the duties and that they can explain them.
- Ongoing reviews: Schedule and sign the periodic reviews of roles, especially after staff changes.
Before the assessment, check that every named person can state their duties and point to the record that assigns them.
An implementation partner such as DeployOpen can draft the RACI, the role descriptions and the procedures that support them, then prepare the evidence folders an assessor will request. This work is preparation. The partner does not decide which roles your organization assigns, does not sign acknowledgments on behalf of your staff, and does not attest to compliance. Where service providers need a formal compliance program, the partner can help configure the records for the quarterly reviews, but your executives must own and sign them.
- RACI and role drafts: Map each PCI DSS activity to a proposed owner, then revise the draft with your leadership before anything is approved.
- Evidence folders: Assemble the approved charter, policies, RACI versions, acknowledgment forms and review logs in a consistent structure with dates.
- Recurring review records: Set up templates and reminders for the quarterly reviews that Requirement 12.4.2 expects service providers to perform, with a reviewer other than the person doing the work.
- Separation of duties in small teams: Document the procedural controls that the SAQ D note to Requirement 6.5.4 allows, such as developers using separate user-level accounts in production.
- Gap review: Compare the records against the requirement list and report what is missing, so your team can close the gaps.
Confirm in the written scope which of these tasks are included, who signs each record, and which items remain with your team.
Only an independent assessor issues validation. A Qualified Security Assessor (QSA) completes a Report on Compliance (ROC) for entities that require one, and entities that complete a Self-Assessment Questionnaire (SAQ) submit an Attestation of Compliance (AOC) on the official template. A certificate from any other party is not recognized as validation. The assessor tests your roles against the evidence, interviews the people named in the RACI, and decides whether the responsibilities are documented, assigned and understood.
- Independent testing: The assessor samples RACI entries, acknowledgments and review logs, and checks that the people named can perform their duties.
- Interviews: Expect questions to the executive with security responsibility and to individual custodians about what they do and when.
- Report or attestation: The QSA issues the ROC or your organization signs the AOC, based on the assessor's findings.
- Independence rules: A QSA that wrote your RACI or ran the quarterly reviews may face conflict-of-interest limits, so confirm these boundaries before engaging anyone.
- Payment brand decisions: The payment brands, not the PCI SSC, decide which entities must validate and how any enforcement applies.
Ask your assessor early which evidence formats it accepts and whether it needs the roles tested in a specific period.
Common gaps that fail role testing
Assessors rarely fail a role because nobody has one. They fail it because the assignment cannot be proven, is out of date, or depends on someone's memory. The six gaps below are the ones that most often turn a workable team structure into an open finding.
Responsibilities never written down
Teams often assume that whoever runs the firewall or the access reviews is understood to own it. Under Requirement 1.1.2 and Requirement 12.1.3, the roles must be documented, assigned and understood, and an assessor will ask to see the document, not hear the explanation. Fix: write a role statement for each Requirement 1 and Requirement 12 activity, name a person or a named team, and get the owner to confirm it in writing.
Reviewer checks their own work
Where one engineer makes a change, approves it and then signs off the quarterly review of that change, the review proves nothing. Requirement 12.4.2 requires confirmation through reviewers other than those performing the tasks, and that applies to service providers. Fix: assign each recurring review to someone outside the performing role, and record the reviewer's name against each review date.
RACI not updated after staff change
A RACI chart that still lists a manager who left, or a deputy who moved teams, shows an assessor that the program is not maintained. Responsibilities drift quietly after reorganizations, and the gap appears only when the records are compared with the current org chart. Fix: tie RACI review to the joiner, mover and leaver process, and check the chart against the directory at each quarterly review.
Key custodian list without acknowledgments
Naming custodians for cryptographic keys is not enough. Requirement 3.7 includes custodian acknowledgment, meaning each person must formally accept the responsibilities for the keys they hold. A list of names with no signed or recorded acceptance is a common finding. Fix: keep a custodian register that records each acknowledgment, its date, the keys covered and the replacement process when a custodian leaves.
Quarterly reviews not documented
Service providers may perform the right checks but leave no record that the review happened, who conducted it or what it found. Requirement 12.4.2.1 requires documentation of those reviews, so an undocumented review is treated as no review. Fix: use a standard review template that captures the tasks checked, the reviewer, the date, exceptions and the follow-up owner.
Procedural separation not written down
Small teams often rely on developers using separate user-level accounts in production instead of shared admin access. The SAQ D note to Requirement 6.5.4 accepts procedural controls for role separation, but only if the procedure exists and staff follow it. Fix: write the procedure, state which accounts and duties it covers, and keep evidence that it runs, such as access logs showing individual accounts used for production changes.
Questions buyers ask about PCI DSS roles and assessor evidence
How much internal effort do PCI DSS roles and responsibilities take to set up?
Assigning roles is a small task compared with the controls they govern, but it touches several people and needs sign-off from executive management. Expect the work to fall into two parts: a one-time pass to map every Requirement 1 and Requirement 12 activity to a named role, and a recurring effort to keep those assignments current as staff change. The effort rises with the number of teams that touch the cardholder data environment, the number of third parties involved, and how many roles are still implied rather than written down. Ask any implementation partner to state in the written scope which roles they will draft, which your team must approve, and which records you must keep yourselves. Your internal effort is the largest share of this work because only your organization can confirm who actually performs each task.
Can a consultant assign PCI DSS roles on behalf of our company?
No. Your organization owns its controls, so accountability for roles must be assigned by your own management. A consultant or implementation partner can draft a proposed RACI record, explain what each requirement expects, and point out gaps, but the named people and their acceptance must come from inside the organization. DeployOpen prepares systems, controls and evidence for assessments, and it does not issue reports or attestations. The independent Qualified Security Assessor (QSA) then tests whether the assignments are documented, understood and actually followed. If a consultant also performs the assessment, independence is compromised, so keep those two roles with separate firms.
What does a QSA sample when testing PCI DSS roles and responsibilities?
A QSA tests the roles against real work, not against the document alone. Typically the assessor reviews the written roles for Requirement 1.1.2 and Requirement 12.1.3, then selects people and teams from the sample and asks them to explain their responsibilities in their own words. They also check that the named individuals performed the assigned tasks during the assessment period, such as reviewing firewall rules, approving changes, or responding to alerts. For service providers, the assessor will also review the Requirement 12.4 compliance program, the executive charter, and the quarterly review records. Your sample is determined by the assessor, so the practical preparation is to make sure every named role has a traceable record of activity.
Can one person hold several PCI DSS roles at once?
Often yes, but only where the combination does not defeat a control. Small teams commonly combine roles such as security lead and compliance contact. The risk comes when one person both performs a task and reviews it, for example making a change and approving it, or writing code and deploying it to production. For those cases, the SAQ D note to Requirement 6.5.4 allows small teams to meet role separation with procedural controls, such as a developer using separate user-level accounts in production. Record every combined role, state the compensating procedure in writing, and confirm with your assessor that the arrangement is acceptable for your validation type before relying on it.
How often should PCI DSS RACI records be reviewed?
Review them at least every 12 months, in line with the review cycle for the overall information security policy under Requirement 12.1.2. Treat the annual review as the minimum, and update the records sooner after a reorganization, a new payment channel, a change of service provider, or a significant change to the cardholder data environment. Service providers have a shorter cadence for their compliance program: the Requirement 12.4.2 review of task performance happens at least every three months, and the reviews themselves must be documented under Requirement 12.4.2.1. Keep the dated version history, because an assessor will ask which version was in force during the assessment period.
Will a QSA accept a RACI chart as proof of PCI DSS role compliance on its own?
No. A RACI chart shows what should happen, but a QSA needs evidence that the assigned roles were understood and performed. Expect to supply the approved role document, evidence that the people named have acknowledged their responsibilities, and records of the work they did, such as change approvals, access reviews, log reviews and incident tickets. For service providers, add the executive charter and the quarterly review records. The assessor decides what is sufficient for each requirement, and the report is issued only by the QSA. Ask your QSA early which records they expect to see for your validation type so that evidence is collected throughout the year, not assembled at the end.
Where DeployOpen fits in the roles work
DeployOpen prepares the systems, RACI drafts and evidence that your organization then owns, reviews and approves. Under a written fixed scope, we can draft a responsibility matrix for Requirement 1.1.2 and Requirement 12.1.3, map each role to the people who actually perform the work, and assemble the records an assessor will ask for, such as the charter for the compliance program, the appointment letter for the executive responsible under Requirement 12.1.4, and the custodian acknowledgments under Requirement 3.7. Each artifact is a draft until your executive sponsor and the named individuals accept it. Who signs, who reviews and who holds each responsibility remains a decision for your organization, and that decision should be made before any drafting begins.
DeployOpen does not issue Reports on Compliance, Attestations of Compliance or certificates. Only a Qualified Security Assessor or the appropriate validation body can assess your environment and issue those documents, and the PCI SSC states that certificates are not recognized as validation. The scope of our work, deliverables and timelines are agreed in writing before work starts, and any fees follow from that written scope. Ask any provider, including us, to state in writing which artifacts they will produce, which will be produced by your staff, and which will be reviewed independently.
Engaging an implementation partner does not guarantee a passing result or a particular validation outcome. An assessor may find that a role is documented but not understood, or that a quarterly review was performed by the same person who did the work, and those gaps remain your responsibility to close. Before engaging anyone, confirm with your assessor which role records they expect to see, check the current version of the standard at the PCI Security Standards Council's PCI DSS page, and plan for the people time needed to keep the matrix current after the initial work.
How DeployOpen scopes and prepares PCI DSS role evidence
DeployOpen helps organizations assign PCI DSS responsibilities in a form an assessor can verify, then prepares the documents, records and reviews that show those roles are working. We own none of the controls: the organization assigns the roles, and only an independent assessor issues the Report on Compliance or Attestation of Compliance.
How we scope
- We agree a written scope listing which requirements, teams and service provider duties the role records must cover before work starts.
- We confirm which entities are in the cardholder data environment and which roles touch each in-scope requirement.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work begins.
How we build
- We draft role assignments per requirement, mapping each responsibility under Requirement 1.1.2 and Requirement 12.1.3 to a named function.
- For service providers, we set up the compliance program charter, review cadence and reviewer assignments that Requirement 12.4 expects.
- We test the role records by walking through sample tasks with the named owners to confirm they know what they are accountable for.
How we hand over
- We deliver the RACI matrix, role descriptions, review logs and key custodian acknowledgment records in formats your assessor can inspect.
- We document the small-team separation approach, including any procedural controls used under the SAQ D note to Requirement 6.5.4.
- We walk your compliance lead and assessor through the evidence trail so the records can be verified without further explanation.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so role records stay current after the initial handover.
- We help update roles when staff change, systems change significantly or the standard moves to its next version.
- Assessor selection and the formal assessment remain with your organization and an independent QSA, which DeployOpen does not replace.
