Compliance should own the evidence trail for script justification, approvals and testing, while security should own monitoring, alerting and investigation. The control fails when ownership is split in theory but no one maintains the live state of the payment page.
How to divide ownership between compliance and security
For e-skimming controls, the clean split is between governance evidence and operational defence. Compliance owns the policy side of the control, which means documenting why scripts are allowed, who approved them, what testing was performed, and how exceptions are justified. Security owns the live control environment, meaning monitoring changes, investigating anomalies, and responding when the payment page behaves unexpectedly.
The most important boundary is not who “cares” about the page, but who can prove the control is working today. E-skimming breaks in the gap between paper approval and runtime reality, so the handoff has to preserve both traceability and active oversight.
What each team must maintain day to day
Compliance should maintain the approval record for third-party scripts, the business justification for each script, evidence of periodic review, and test results that show the control is still effective. That evidence needs to be current enough to survive audit and useful enough to explain why a script remains on the page.
Security should maintain script monitoring, page integrity checks, alert triage, and investigation workflows. If a payment page changes, the security team needs to know whether the change was expected, whether the source is trusted, and whether the new behaviour matches the approved inventory. CSA Cloud Controls Matrix is a useful external reference point for control ownership patterns, even though the control problem here is specifically web payment-page integrity.
When this split works well, compliance does not become a document warehouse and security does not become a detective function with no control authority. Each team owns the part it can actually keep current.
Where e-skimming controls fail in practice
The failure mode is usually drift. A script is approved once, but the page later accumulates new tags, new vendors, new endpoints, or altered logic without the evidence trail being updated. In that state, compliance can still show an approval packet while security sees a page that no longer matches it.
That is why e-skimming ownership should include a shared reconciliation point. Compliance should be able to explain why each script exists, and security should be able to show that the live page still matches that explanation. The strongest external control references for this kind of evidence-and-monitoring model are PCI DSS v4.0, CIS Controls v8, and ISO/IEC 27001:2022 Information Security Management, because they all reinforce the need for controlled change, logging, and accountable review.
Another common failure is assuming one team’s artifact is enough. An approval log without runtime monitoring will miss malicious injection. Monitoring without documented ownership will generate alerts no one is formally responsible for closing. Either gap leaves the control incomplete.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 sets the technical controls, while PCI DSS v4.0 and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| PCI DSS v4.0 | 7 — Restrict access to system components and cardholder data by business need to know | E-skimming controls require tightly limiting who can change payment-page scripts. |
| 6 — Develop and maintain secure systems and software | Script integrity and page-change control are central to preventing payment-page skimming. | |
| 10 — Log and monitor all access to system components and cardholder data | Runtime monitoring and investigation are essential when payment-page scripts can change. | |
| Recommendation — Restrict payment-page script access to approved business need and review every exception. Apply change control and validation to payment-page scripts before deployment. Log and monitor payment-page changes and investigate unexpected script activity promptly. | ||
| CIS Controls v8 | 5 — Account Management | Ownership and review of script access depends on clear account accountability. |
| 8 — Audit Log Management | E-skimming detection relies on logging page and script changes for investigation. | |
| Recommendation — Review and remove unnecessary access that could alter payment-page scripts. Collect and review logs that show when payment-page scripts change. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Approved scripts and live page state must stay aligned under controlled change. |
| A.8.15 — Logging | Detection of unauthorized page changes depends on recorded activity and alerts. | |
| A.5.36 — Compliance with policies, rules and standards for information security | Compliance ownership of approvals and evidence trails maps directly to policy adherence. | |
| Recommendation — Control and review configuration changes to payment-page scripts before release. Enable logging for payment-page changes and retain records for investigation. Maintain evidence that script approvals and reviews follow the control policy. | ||
Practitioner Guidance
Decision rule: If the issue is proving why a script is allowed, treated as approved, or retained after review, compliance should own it. If the issue is detecting unauthorized script behaviour, page tampering, or suspicious change, security should own it. Shared responsibility should mean one team writes the evidence and the other watches the live state, not both teams assuming the other is doing both jobs.
What to verify: The approved script list must match the deployed page, and there must be a defined owner for every exception, alert and remediation decision. If no one can answer “who would notice a new script today?” the control is already weak.
Practitioner takeaway: E-skimming control ownership works only when compliance manages provable authorization and security manages provable detection, with a formal reconciliation between the two.
Related resources from NHI Mgmt Group
- How should security teams govern non-human identities for compliance?
- How should security teams govern non-human identities for SOC 2 compliance?
- How should security and compliance teams share responsibility for CSRD evidence?
- Who should own ISO 27001 compliance when security, GRC, and cloud teams all share responsibility?