If you're managing payment page security under PCI DSS v4.x, or building client-side controls for SOC 2 or ISO/IEC 27001, you need a defensible script inventory. This isn't just a spreadsheet you update once and forget. It's a living document that auditors can validate and your detection mechanisms can reference.
This template offers a structured approach to cataloging scripts, documenting justifications, and maintaining the reconciliation trail that requirement 6.4.3 demands. You can adapt it for PCI DSS compliance or use it as a foundation for CC6.1 (logical and physical access controls) in SOC 2 Type II or ISO/IEC 27001 Annex A.8.2 (privileged access rights).
Purpose of This Template
This inventory serves three main purposes:
Compliance documentation. PCI DSS 6.4.3 requires maintaining an inventory of scripts on payment pages, including technical justification for each. While SOC 2 and ISO/IEC 27001 don't require this level of detail for client-side scripts, if you're processing cardholder data or building a trust services criterion around system boundaries, you'll need comparable rigor.
Change reconciliation. Your tamper-detection mechanism (requirement 11.6.1) needs a source of truth. When a script hash changes or a new script appears, your detection tool compares production against this inventory. Without it, you're just collecting alerts you can't triage.
Authorization trail. Auditors will ask: how do you know this script is approved? The inventory becomes your audit evidence, not just a list of filenames, but a record of who authorized it, why it's there, and when it was reviewed.
Prerequisites
Before populating this template:
- Define your payment page scope. If you're using iFrames, include scripts on the underlying page as well, per PCI DSS 4.0.1.
- Establish a review process. Document your approval workflow. Whether it's multiple reviewers, a change ticket, or a pull request, make sure it's auditable.
- Choose your integrity validation method. Options include Subresource Integrity (SRI), Content Security Policy (CSP) with hash enforcement, or a third-party monitoring tool. Reference this in the "Validation Method" column.
The Template
Copy this table structure into your repository, wiki, or GRC platform. Store it where your change management process can reference it and your detection mechanism can pull from it programmatically.
| Script Name / URL | Purpose | Technical Justification | Authorized By | Authorization Date | Validation Method | Hash (SHA-384) | Last Reviewed | Notes |
|-------------------|---------|-------------------------|---------------|--------------------|--------------------|----------------|---------------|-------|
| jquery-3.6.0.min.js | DOM manipulation for form validation | Required for client-side validation of card number format before submission | Jane Doe (Engineering Manager) | 2024-02-15 | SRI | sha384-KyZXEAg3QhqLMpG8r+8fhAXLRk2vvoC2f3B09zVXn8CA5QIVfZOJ3BCsw2P0p/We | 2024-11-10 | Loaded from CDN; SRI enforced in CSP |
| payment-gateway.js | Tokenization library from payment processor | Handles secure tokenization of card data; provided by PCI-compliant processor | John Smith (Security Lead) | 2024-01-20 | Vendor-provided hash validation | sha384-... | 2024-11-10 | Processor: ExamplePay; contract requires notification of updates |
| analytics-tracker.js | User behavior analytics | Tracks conversion funnel; does not access payment fields | Jane Doe | 2024-03-01 | CSP nonce + hash check | sha384-... | 2024-11-10 | Restricted via CSP to prevent DOM access to #card-number |
Column definitions:
- Script Name / URL: Exact filename or CDN path as it appears in production HTML.
- Purpose: One-sentence functional description.
- Technical Justification: Why this script is necessary for payment processing or page functionality.
- Authorized By: Name and role of the approver. If you use a multi-reviewer process, list all reviewers or reference the change ticket.
- Authorization Date: When the script was approved for production use.
- Validation Method: SRI, CSP hash, vendor-provided validation, or third-party monitoring tool.
- Hash (SHA-384): Current production hash. Update this whenever the script changes.
- Last Reviewed: Date of most recent inventory reconciliation.
- Notes: Relevant information for auditors or incident response, vendor contracts, CSP restrictions, false positive history.
Customizing the Template
For repository-based systems: Maintain this inventory as a JSON or YAML file in your deployment repository. Ensure your CI/CD pipeline enforces that only scripts in this file can be deployed. Add a pre-commit hook to validate script hashes before merging.
For third-party scripts: Add columns for vendor name, contract terms, and notification requirements. PCI DSS doesn't exempt third-party scripts from inventory requirements, and SOC 2's CC9.2 (vendor management) expects documentation on how you monitor vendor-supplied code.
For ISO/IEC 27001: Map each script to a control objective. For example, scripts handling authentication might reference A.9.4.2 (secure log-on procedures); scripts processing data might reference A.8.2.3 (handling of assets). This simplifies your Statement of Applicability.
For multiple frameworks: Add a "Compliance Mapping" column. Tag each script with the requirements it satisfies, PCI DSS 6.4.3, SOC 2 CC6.1, ISO/IEC 27001 A.8.2, so you build evidence once and reuse it across audits.
Validation Steps
Once the template is populated, validate it against production:
1. Reconcile production scripts. Use browser DevTools or a headless browser script to pull every script tag from your payment page. Compare the list to your inventory. Any script in production that's not in the inventory is a nonconformity.
2. Verify hash accuracy. Calculate the SHA-384 hash for each script and confirm it matches the inventory. If using SRI, your browser will do this automatically; if not, script the check.
3. Test your detection mechanism. Modify a script hash in your test environment and confirm that your tamper-detection tool flags it. Document the test results.
4. Confirm the authorization trail. For a sample of scripts, trace the approval from the inventory back to the change ticket or pull request.
5. Schedule recurring reviews. Set a quarterly review cadence to re-validate the inventory against production, update hashes for legitimate changes, and confirm that authorization records are complete.
What Auditors Will Look For
During a SOC 2 or PCI DSS assessment, auditors will ask:
- Can you show the approval record for this script?
- How do you ensure production scripts match this inventory?
- What happens when a script changes without authorization?
- Where's the evidence that you reviewed this inventory in the last quarter?
If you can answer these questions by pointing to specific rows in this template, change tickets, and detection logs, you're in a strong position. If you're scrambling to reconstruct approvals or guessing at script purposes, you're not ready.
Build this inventory now, before your next audit. It's not just a PCI DSS checkbox, it's the foundation for client-side security controls that work across every framework you're managing.
