What 12.4 PCI DSS compliance management asks service providers to run
Requirement 12.4 applies only to service providers. Merchants and most other entities that take card payments do not carry it, although they still have their own program obligations elsewhere in Requirement 12. If you are a service provider, the requirement asks for a managed compliance program with named executive ownership, a written charter, and a recurring check that the security work is actually happening. The first part is executive management formally taking responsibility for protecting cardholder data and for the PCI DSS compliance program, with that responsibility captured in a charter. Confirm who signs that charter, what it says about scope and authority, and whether the named executive has the budget and the access needed to act on findings.
The second part is the quarterly confirmation. At least every three months, someone other than the people doing the work must confirm that tasks such as daily log reviews, network security control configuration reviews, configuration standard application, alert response and change management are being performed. The third part is documentation. Each review must record its results, the remediation actions it triggered, and sign-off by the personnel responsible for the compliance program. Check whether your reviewers are independent of the teams they review, and whether your quarterly records would let an assessor follow a finding from discovery to closure.
A compliance program that exists only on paper is a common failure point. A charter can be signed and a review template can be filled in while log reviews lapse and change tickets skip approval, and the gap usually surfaces during an assessment or after an incident. Teams find the quarterly confirmation hard to sustain because it depends on evidence scattered across ticketing, logging, configuration and HR systems, and because reviewers must understand technical work they did not perform. A practical starting point is to ask, for each listed task, which system produces the evidence, who reviews it, and how a missed cycle would be detected. Those answers define the work before any tooling or outside help is chosen.
Which service providers, teams and tasks 12.4 PCI DSS compliance management touches
Requirement 12.4 applies only when the organization is a service provider for PCI DSS purposes, so the first decision is whether that role applies at all. The remaining decisions determine which business units, operational tasks and people the quarterly review must cover, and who signs off on the results.
Service provider status for PCI DSS
Requirement 12.4 applies only to service providers, so confirm first whether your organization falls in that category for the services you sell. Hosting, processing, managing or otherwise affecting another organization's cardholder data environment usually brings you in scope. Document the reasoning in writing, because assessors will ask how you reached the conclusion. If you are an internal function serving only your own card payments, check with your payment brand or acquirer how the requirement applies to you before building the program.
In-scope business units and services
Map which business units run services that touch the cardholder data environment, such as hosting, payment processing, customer support tools or managed infrastructure. Each unit that operates in-scope services needs a named owner who reports into the compliance program. Units that appear out of scope on an org chart often hold administrative access to in-scope systems, so verify access paths, not just reporting lines. Ask each unit lead to confirm which services they operate for customers.
Log review and NSC configuration checks
The quarterly review must sample daily log reviews and network security control configuration reviews, confirming the tasks happened as documented. Reviewers should pick real examples from the period, such as a sample of log review records and recent firewall or security group rule reviews, rather than accept a summary. Confirm that the logs and review records are retained in a form the reviewer can access independently of the people who performed the work.
Configuration standards and alert response
The review also tests whether configuration standards are applied to in-scope systems and whether security alerts are responded to as the program requires. Pick a sample of recent builds or hardening records and compare them with the approved standard. For alert response, trace a few alerts from detection through triage, escalation and closure, and check that the handling matches the documented procedure. Gaps here often show up as undocumented exceptions, so record each exception with its approver.
Change management and approvals
Change management is one of the tasks the quarterly reviewers must confirm is performed. Sample recent changes to in-scope systems and check each one for a request, documented testing, approval and a post-change verification step. Changes made outside the ticketing process, including emergency fixes, are the most common gap. Confirm that the reviewer is not the same person who made or approved the change, so the review remains independent.
Executive, security and operations responsibilities
Executive management must establish responsibility for protecting cardholder data and the compliance program, and the charter should name the accountable executive. The security team owns the program design and quarterly review process, while operations teams perform the daily tasks being reviewed. Keep reviewers separate from performers and record sign-off by the personnel responsible for the program. Ask who approves the charter, who receives review results and who decides on remediation when a review fails.
How a QSA tests 12.4.1, 12.4.2 and 12.4.2.1
This table compares how an assessor approaches each sub-requirement of 12.4, what evidence it asks for, and where service providers most often fall short. Read it as a checklist of what to prepare before a ROC or AOC review, since the specific sampling steps sit in the assessor's own testing template. The main takeaway is that 12.4 is tested on recurring records over time, not on a single policy document.
| Sub-requirement | Test approach | Evidence requested | Common findings |
|---|---|---|---|
| 12.4.1 Executive responsibility and charter | Confirm a named executive owns cardholder data protection and the PCI DSS program, and that a charter defines its scope and authority | Signed charter, executive appointment or board minutes, current organization chart, program governance terms | Charter is undated or out of date, or responsibility sits with a role lacking authority over budget and staffing |
| 12.4.2 Quarterly reviews by independent reviewers | Check that reviews occur at least every three months, that the reviewer is not the person performing the task, and that the reviews cover the listed operational tasks | Review calendar and completed review records for the assessed period, reviewer identity and separation from task owners, sample of reviewed tasks such as log reviews and change management | Reviews are scheduled but skipped in some quarters, or the reviewer also performs the tasks being reviewed |
| 12.4.2.1 Documented review results and sign-off | Inspect each quarterly review record for results, remediation actions and sign-off by the responsible program personnel | Written review reports, findings log with remediation owners and due dates, sign-off records, evidence that open items were tracked to closure | Reports list issues without remediation actions, or sign-off is missing, undated or given by someone outside the program |
Building the quarterly review cycle step by step
This sequence turns Requirement 12.4 from a policy statement into a standing program: an approved executive charter, named owners, a defined task list, independent reviewers, a calendar and a review record that proves each quarterly check happened.
Obtain the executive charter
Start with executive management. Requirement 12.4.1 expects senior leadership to take formal responsibility for protecting cardholder data and for a PCI DSS compliance program that is governed by a charter. Draft the charter with your CISO or compliance lead, define scope and purpose, and get it formally approved by the accountable executive. The output is a signed charter, dated and stored with your policy documents, that assessors can read alongside your security policy.
Name the program owners
Record who is personally responsible for the PCI DSS compliance program. Requirement 12.4.2.1 requires that each quarterly review is signed off by these personnel, so the names must be explicit, not a team alias. Document their roles, reporting line and deputies for absence cover. The output is a roles register that lists each owner, their responsibilities and their contact route to the executive sponsor named in the charter.
Build the operational task register
List every daily, weekly, monthly or other recurring security task that the quarterly review must confirm. The requirement names examples such as daily log reviews, network security control configuration reviews, applying configuration standards, responding to alerts and change management, but your register should cover every task your environment depends on. For each task, record the owner, the frequency, the evidence source and the system it applies to. The output is a task register that your assessor can trace back to the requirements it supports.
Assign independent reviewers
Assign a reviewer for each task who does not perform that task. Requirement 12.4.2 expects the confirmation to come from reviewers other than those doing the work, so a log analyst should not review their own log reviews. Where teams are small, document how independence is achieved, for example through a peer on another team or a manager with no operational role in the task. The output is a reviewer map that pairs every task in the register with an independent reviewer and a named backup.
Set the quarterly review calendar
Fix the review dates for the year so each quarter has a defined window, and confirm the reviews fall at intervals no longer than three months, as Requirement 12.4.2 requires. Align the calendar with change freezes, audit preparation and scope validation under Requirement 12.5 so reviews do not coincide with a gap. The output is a published calendar with reminders, owners and escalation contacts for a missed review.
Define the review record template
Create a standard template for each quarterly review. Requirement 12.4.2.1 expects the record to show the results of the review, any remediation actions raised and the sign-off by the responsible program personnel. Include fields for task, reviewer, date, evidence reviewed, finding, remediation owner and due date, and a sign-off block. Store completed records in a version-controlled location so changes and approvals are traceable. The output is a template and one completed example kept as a reference, labeled as illustrative.
Run the first review and confirm the cycle
Perform the first quarterly review using the calendar, register, reviewer map and template. Each reviewer checks the evidence for their tasks, records findings and raises remediation actions where a task was missed. The program owners then sign off the completed record. Check that the cycle is closed before the next quarter begins. The output is a signed first review record, a remediation log with open items tracked to closure, and a short note on any gaps to correct before the assessor visit.
Evidence that passes a 12.4 review and how to keep it current
A 12.4 review is judged on records, not intentions. The artifacts below show that executive accountability exists, that reviewers check the work each quarter, and that gaps lead to tracked fixes. Keeping them versioned and linked to the tasks they describe is what lets a reviewer follow the program over time.
Signed executive charter
The charter is the document that establishes executive management's responsibility for protecting cardholder data and for the PCI DSS compliance program, as 12.4.1 requires. Keep the signed version, the named executive, the scope of the program and the date it took effect. Check that the signatory actually holds the authority the charter describes, and that the charter names the people who report to that executive. An unsigned draft in a shared folder will not satisfy a reviewer.
Responsibility assignments
Reviewers want to see who owns each PCI DSS task, not just who owns the program. Maintain a matrix that maps each recurring security task to a primary owner and to an independent reviewer. The reviewer must not be the person who performed the work. Record changes when staff move roles, so the matrix matches the people who signed the most recent quarterly reviews.
Quarterly review records
Each review must confirm, through reviewers other than those doing the work, that the listed operational tasks are being performed. Record the date, the reviewer, the tasks checked, the results and any exceptions. A review that reads "all good" with no task-level detail gives an assessor nothing to test. Confirm that the review cadence has no gaps across the assessment period.
Remediation and sign-off
Under 12.4.2.1, each review must record its results, the remediation actions it triggered and sign-off by the personnel responsible for the compliance program. Link every finding to a ticket with an owner, a due date and a closure note. Sign-off should come from the people named in the charter. Ask the team to show one finding carried from identification through closure, because that trail is what an assessor will sample first.
Task samples behind each review
A review is only as credible as the records it points to. Keep samples of the underlying work: log review records, network security control configuration reviews, alert responses and change tickets with approvals. Pull a sample from each quarter so a reviewer can trace a claim in the review back to evidence. Store these in systems that already hold audit trails, and confirm that the logs themselves are protected from unauthorized change.
Version history and self-hosted records
Reviewers need to see what changed in a charter or review record, when and by whom. Self-hosted wikis can hold these documents under version control. XWiki keeps a history of every page change and allows comparison and rollback. BookStack allows permissions by role at the shelf, book, chapter or page level, which helps restrict edits to the compliance team. Confirm both tools against your own access and retention requirements before relying on them.
GRC tracking with CISO Assistant
CISO Assistant, licensed under AGPL-3.0-only, includes PCI DSS among its frameworks and can run assessments and track their status against it. It can help the program owner see which requirements have evidence and which are open. It does not replace the review records or sign-offs, and it does not validate compliance. Confirm that its framework content matches the PCI DSS version your assessor uses before relying on its mappings.
What 12.4 costs in money and effort
This table breaks down what a PCI DSS 12.4 program costs in people time and tooling, and whether each cost is one-time or recurring. Use it to see which costs fall on your team, which can go to a partner, and what to request in a quote. No prices or durations are stated because none are supplied for this requirement; confirm them in writing for your environment.
| Cost component | Who carries it and one-time or recurring | What drives it up or down |
|---|---|---|
| Executive time to approve and oversee the charter | Executive management. Recurring at each review cycle, with a one-time charter drafting effort | Number of service lines in scope and how many executives must sign. Clear existing governance keeps it low |
| Compliance program staff time for quarterly reviews | Internal PCI DSS program owners. Recurring every three months | Number of tasks reviewed, such as log reviews, NSC configuration reviews and change management. Fewer, well-defined tasks reduce effort |
| Reviewer time from people independent of the work | Staff not performing the tasks under review. Recurring every three months | Headcount available outside each operational team. Small teams may need a partner or a cross-team reviewer rotation |
| Tooling or licenses for records and assessment tracking | Software vendor or internal platform owner. Recurring license fees for commercial tools, or one-time setup for self-hosted tools | Number of users and whether records live in a central system. Self-hosted open-source wikis and GRC tools can remove license spend but add hosting and upkeep |
| Remediation effort from review findings | Engineering and operations teams. Variable, arising from each review cycle | Maturity of existing records and how many tasks lack evidence. Mature, consistently performed tasks produce fewer findings |
| Assessor time sampling review records | Qualified Security Assessor or assessor firm, billed under the assessment engagement. Recurring with each assessment | Volume and completeness of quarterly review records, including results, remediation actions and sign-off. Ask the assessor for its sampling approach in writing |
| Implementation partner setup of templates and review calendars | Outside partner under a fixed-scope written agreement. One-time, with optional recurring retainer support | Number of in-scope service providers and the state of current procedures. Request a fixed-scope quote listing deliverables and timelines |
Who runs 12.4 in-house, who a partner helps with, and what the assessor checks
Requirement 12.4 applies only to service providers, and the organization owns every part of it. Executive management must establish responsibility for protecting cardholder data and sign a charter for the PCI DSS compliance program. Compliance staff then run the program day to day, scheduling the quarterly reviews and collecting the evidence behind them. The people who perform the tasks under review, such as log reviews and change approvals, must not be the ones who confirm those tasks were done.
- Executive charter: A named executive owns the charter, approves the program's scope and funds the work. Ask who signs it and how often leadership sees the results.
- Compliance staff: Staff run the quarterly review cycle, track remediation items and keep the reviews on a fixed calendar.
- Independent reviewers: Reviewers come from outside the team doing the work, such as a security lead reviewing platform operations. Document who is independent and why.
- Sign-off records: Each review records its results, remediation actions and sign-off by the personnel responsible for the program.
- Recurring cost: The internal cost is mostly staff time for reviews, evidence collection and remediation, which recurs every quarter.
Before engaging anyone outside, confirm that your executives have actually signed the charter and that your reviewers are not reviewing their own work.
An implementation partner helps you build the program and its record-keeping. DeployOpen prepares systems and evidence in your own infrastructure, but it does not issue reports, attestations or certifications, and it does not validate the controls it helps design. The partner's work is preparation: drafting, configuring and rehearsing, with your organization approving every document and owning every decision.
- Charter and templates: The partner can draft a charter and quarterly review templates for your executives and compliance staff to review, amend and adopt.
- Record-keeping setup: Configure self-hosted tools so reviews, results, remediation items and sign-offs are stored with version history and access control.
- Sample evidence: Prepare sample review records and a clear evidence index so your team can show what each review produced.
- Review rehearsal: Run a mock quarterly review with your reviewers to test whether the templates capture what an assessor will ask for.
- Fixed scope: Agree the deliverables in writing before work starts, and do not let the partner's design work become the assessor's test.
Ask the partner which of these outputs it will produce, and confirm in writing that it will not sign off on the program or on any reviewer's conclusions.
The QSA or other independent assessor tests whether the program works as written. For a service provider, the assessment result is documented on the Report on Compliance and the Attestation of Compliance, which only the assessor completes. The assessor reviews the charter, the quarterly review records, the remediation tracking and the evidence behind each sign-off, then forms its own conclusion. The assessor may not design the controls it is testing, which is the line that separates it from the partner.
- Charter review: The assessor checks that executive responsibility is documented and that the charter is current.
- Review sampling: The assessor selects quarterly reviews and checks that reviewers were independent and that results, remediation and sign-off were recorded.
- Evidence testing: The assessor traces a sample of tasks, such as log reviews and change records, back to the review that confirmed them.
- Report output: The assessor issues the Report on Compliance and Attestation of Compliance. A certificate from anyone else is not recognized as validation.
- Independence: The assessor's findings rest on its own testing, so preparation work by a partner can support the evidence but cannot replace it.
Before the assessment, ask the assessor how it will sample reviews and what evidence format it accepts.
Where service providers fall short on 12.4 and how to close each gap
Requirement 12.4 applies only to service providers, and assessors usually find the same weaknesses: a charter that never reached executive management, reviews that lack independence, and records that cannot prove what happened. The cards below pair each gap with the action that closes it before the assessor arrives.
Charter exists but lacks executive approval
A compliance charter written by the security team and filed in a folder does not satisfy 12.4.1, which expects executive management to establish responsibility for protecting cardholder data and the compliance program. Assessors ask who approved the charter, when, and whether that person's role is named in it. Close the gap by taking the charter to a named executive, recording the approval with a date, and confirming the document states the program's scope, owners and reporting line. Re-approve it when responsibilities change.
Reviewers are the people doing the work
Requirement 12.4.2 calls for the quarterly confirmation to be performed by reviewers other than those carrying out the tasks. When the engineer who reviews firewall rules also approved the change, the review proves nothing to an assessor. Assign reviewers from a separate line, such as a security or compliance lead, and document why each reviewer is independent of the activity they check. Where staffing is thin, agree the reviewer arrangement in writing before the first quarter closes.
Quarterly reviews skip the task list
Many programs run a generic quarterly meeting that never walks through the specific tasks 12.4.2 names: daily log reviews, network security control configuration reviews, configuration standards, alert responses and change management. Build a checklist that maps each task to an owner, an evidence source and a sample to inspect. Confirm each item during the review, not from memory, and note any task that did not happen. Assessors look for evidence that each named task was checked, not a summary statement.
Review records lack sign-off and remediation
Requirement 12.4.2.1 expects each review to record its results, the remediation actions raised, and sign-off by the personnel responsible for the compliance program. A review that lists no findings is also suspicious to an assessor. Use a standard template with fields for results, each open action, its owner and due date, and the signature of the responsible executive or compliance lead. Track remediation items to closure in the next review so the record shows follow-through.
Records cannot show their history
Reviews that are overwritten in place or stored as loose files cannot demonstrate that quarterly reviews happened on schedule or what changed between them. Assessors commonly ask for the prior quarters and for proof that a record was not edited after sign-off. Store review records in a system that keeps every version with its author and timestamp, and that allows any two versions to be compared. Confirm that access to edit closed records is restricted to the compliance owner.
Compliance program lacks an owner in the tooling
When assessments, evidence and reviews live in separate spreadsheets, quarterly sign-offs and scope status drift apart. A self-hosted compliance platform can hold the PCI DSS requirements, assign owners and track review tasks against them. CISO Assistant, for example, ships PCI DSS among its frameworks and supports audits and assessments against them. Confirm the platform's PCI DSS content matches the v4.0.1 requirement text before relying on it for 12.4 evidence.
Questions buyers ask about 12.4 PCI DSS compliance management
Does requirement 12.4 apply to merchants?
No. Requirement 12.4 applies only to service providers. Merchants and other entities that are not service providers do not carry the 12.4 sub-requirements, although they still must meet the rest of PCI DSS, including the policy and program duties in the other 12.x requirements. Whether your organization counts as a service provider depends on whether it stores, processes or transmits cardholder data for others, or manages payment-related systems on their behalf. The payment brands decide which entities must validate, so confirm your validation obligation with your acquirer or the brand programs before you scope this work. The official PCI DSS self-assessment questionnaire for service providers lists the 12.4 sub-requirements in its own wording.
How much effort do the quarterly 12.4 reviews take?
The effort depends on how many tasks fall under review, how many systems and teams they cover, and whether the evidence is already organized. Each quarterly review has to confirm, through a reviewer who did not perform the work, that tasks such as daily log reviews, network security control configuration reviews, configuration standard application, alert response and change management are actually happening. It then has to record the results, remediation actions and sign-off by the people responsible for the compliance program. Effort rises when evidence lives in ticket systems, chat logs and personal folders, and falls when the tasks produce consistent, timestamped records. No duration is supplied for this work, so ask your partner or assessor to estimate the hours per quarter against your written scope.
Can our team run 12.4 without an outside partner?
Yes, a service provider can run 12.4 internally, provided it has enough independent reviewers, a named compliance owner and records that hold up on inspection. The hard part is the independence rule: the person who confirms a task was performed cannot be the person who performed it. Small teams often struggle to meet that rule without borrowing staff from another function. An implementation partner can help you design the review calendar, the evidence trail and the sign-off workflow, and can build self-hosted tooling that produces the records. The organization still owns the controls and the reviews. Only an independent assessor can validate the outcome in a report.
What does 12.4 require from executives?
Executive management must formally take responsibility for protecting cardholder data and for the PCI DSS compliance program, and that responsibility must be set out in a charter. In practice, this means a named executive owner, a written charter that describes the program's purpose and authority, and a visible channel for reporting results and remediation decisions upward. Executives also need to approve resources, because quarterly reviews only work when the reviewers have time and the findings get funded. Ask your team to show the charter, the approval record and the executive sign-off on the most recent review cycle, since those are the items an assessor is likely to request.
How long does it take to start the first 12.4 review cycle?
No duration is supplied for this work, so no timeline can be given here. The time to the first complete review cycle depends on how mature your charter, owners, task inventory and evidence records already are, and on how many services fall in scope. Before you accept a timeline, ask the partner to break the work into written phases: charter and ownership, task mapping, reviewer assignment, evidence design, a dry-run quarter and handover. Ask which phases your staff must complete, which the partner completes, and what the partner needs from you to avoid delays. Fixed-scope engagements agree deliverables and timelines in writing before work starts, so request those terms in the proposal.
Can a consultant sign the quarterly 12.4 review?
No. The quarterly review must be confirmed by the organization's own personnel, and the sign-off must come from the people responsible for the compliance program. A consultant can prepare the review pack, draft the findings, check the evidence and help track remediation, but signing the review as the reviewer or as the accountable owner is the organization's job. Only an independent QSA or other qualified assessor can validate compliance and issue the Report on Compliance or the Attestation of Compliance. Keep the roles separate in your contract, so that the consultant who helps build the program is not also the party that validates it.
What will the assessor request for 12.4?
The assessor will typically ask for evidence that the charter exists and was approved by executive management, that the compliance owner is named, and that a review occurred at least every three months. For each review, expect requests for the list of tasks reviewed, the records showing those tasks were performed, the identity of the reviewer and confirmation that the reviewer was not the performer, the recorded results, remediation actions and the sign-off by the responsible personnel. Assessors will also sample several periods to test consistency. Prepare these records as you go, not at audit time, and keep them in a system that shows who changed what and when. Confirm the exact testing approach with your assessor, because the test procedures are set by the standard and the assessor's own method.
Which tools can hold 12.4 review evidence?
Self-hosted tools can hold the policies, charter, review records and remediation trail, provided they keep versions and permissions. XWiki keeps every change to a page under version control, recording what changed, when and by whom, and it lets users compare versions and roll back. BookStack assigns abilities through roles, which can be overridden at the shelf, book, chapter or page level, so access to review records can be limited to reviewers and sign-off owners. CISO Assistant can run assessments against PCI DSS and map its requirements to other frameworks, which can help track review status. Confirm each tool's fit against your own evidence requirements before you adopt it, because a tool supports the process but does not make the review compliant.
How DeployOpen scopes and prepares 12.4 evidence
DeployOpen helps organizations that need to show PCI DSS 12.4 compliance management is running in practice, not just written down. We prepare the systems, records and review cadence that a QSA will test, while your organization keeps ownership of the program and the assessor issues any report.
How we scope
- Agree in writing which service provider functions, systems and personnel fall under the 12.4 program before work starts.
- Confirm which quarterly review tasks apply to your environment, such as log reviews, configuration reviews and change management.
- Identify who will act as executive owner and which reviewers are independent of the personnel doing the work.
How we build
- Set up a quarterly review workflow with defined reviewers, checklists and a record of results and remediation actions.
- Draft a compliance program charter template for executive management to review, amend and approve.
- Configure ticketing, logging and document version control so each review leaves a traceable, dated record.
How we hand over
- Deliver the charter, review procedures, review records and sign-off templates as documents your team owns.
- Walk your assessor and internal reviewers through where each piece of 12.4 evidence is stored and how to retrieve it.
- Document open gaps and remediation owners so your organization can track them after the engagement closes.
How we support
- Offer ongoing support and retainers to run quarterly reviews, update records and adjust the program after environment changes.
- Review evidence before each assessment cycle so gaps are found by your team, not by the assessor.
- Confirm with your QSA which artifacts they expect for 12.4.2.1 sign-off before the first review cycle begins.
Sources and further reading
- PCI DSS v4.0 Self-Assessment Questionnaire D for Service Providers ↗
- PCI Data Security Standard ↗
- Just Published: PCI DSS v4.0.1 ↗
- Now is the Time for Organizations to Adopt the Future-Dated Requirements of PCI DSS v4.x ↗
- PCI SSC FAQ 1220: compliance certificates ↗
- PCI DSS v4.0: Compensating Controls vs Customized Approach ↗

