Acceptable Use Policies

PCI DSS 4.0.1 Requirement 12.2.1 expects you to document and implement acceptable use policies for end-user technologies, with explicit approval by authorized parties, clear rules for acceptable use, and a list of company-approved products (PCI DSS v4.0.1 Requirement 12.2.1). To operationalize it quickly, publish a controlled policy, tie it to device/software standards, roll it out through access controls and technical enforcement, and retain evidence that people actually follow it.

Key takeaways:

• Write a single acceptable use policy (AUP) that is formally approved, version-controlled, and scoped to end-user technologies (PCI DSS v4.0.1 Requirement 12.2.1).
• Make “acceptable use” enforceable by connecting the AUP to an approved product list, endpoint controls, and exception handling (PCI DSS v4.0.1 Requirement 12.2.1).
• Keep audit-ready proof: approvals, publication, training/attestation, and operational artifacts from endpoint management and access tooling.

“Acceptable Use Policies” often gets treated as a generic HR policy. Under PCI DSS 4.0.1 Requirement 12.2.1, assessors will test it like a security control: documented, explicitly approved, implemented, and aligned to what your workforce actually uses to access systems that can affect cardholder data security (PCI DSS v4.0.1 Requirement 12.2.1; PCI DSS v4.0.1). That means your AUP has to do more than tell employees to “be safe.” It must define what end-user technologies are allowed, how they may be used, and which products are approved so that teams do not introduce unreviewed software, unmanaged endpoints, or risky configurations into the cardholder data environment (CDE) or connected systems.

For a CCO, GRC lead, or security compliance owner, the fastest path is to treat the AUP as a governed policy plus a small operating system: an approver, a review cadence, an inventory-driven approved product list, and enforcement through endpoint management and identity controls. If you already have an AUP, the work is usually in (1) scoping it to “end-user technologies,” (2) making the “approved product list” real and accessible, and (3) collecting evidence that the policy is implemented, not just posted.

Regulatory text

Requirement (excerpt): “Acceptable use policies for end-user technologies are documented and implemented, including explicit approval by authorized parties, acceptable uses of the technology, and a list of company-approved products.” (PCI DSS v4.0.1 Requirement 12.2.1)

Operator interpretation: You need a controlled, approved AUP that applies to the technologies your workforce uses (laptops, desktops, mobile devices, tablets, VDI clients, browsers, collaboration tools, endpoint agents, and other user-facing software). The AUP must define what “acceptable” means in your environment and point to a concrete list of approved products. You must also be able to show that the AUP is implemented in day-to-day operations (PCI DSS v4.0.1 Requirement 12.2.1).

Plain-English interpretation of the requirement

If an employee or contractor can install it, run it, connect with it, or store company data on it, PCI expects you to have rules for it. Those rules must be:

• Written down in a policy you can show an assessor.
• Approved by authorized parties (not an informal wiki page).
• Specific about what users may and may not do.
• Grounded in standardization through a list of approved products (PCI DSS v4.0.1 Requirement 12.2.1).

A strong AUP reduces “shadow IT” and makes your endpoint and access controls defensible during scoping, testing, and remediation.

Who it applies to (entity and operational context)

Entities: Merchants and service providers that store, process, or transmit payment card data, and service providers whose people, processes, or systems can affect the security of the CDE (PCI DSS v4.0.1).

Operational context: This requirement is most relevant anywhere end-user tech touches:

• Administration of CDE systems (admins, engineers, DBAs).
• Customer support or back-office workflows that access systems connected to payment flows.
• Corporate endpoints that can pivot into CDE-connected networks.
• Third-party personnel with access to your environment (managed service providers, contractors, call centers), where you need contractual alignment and access gating.

If you allow BYOD, contractors on personal devices, or unmanaged mobile access, the AUP becomes a front-door control that must align with your access and endpoint security model.

What you actually need to do (step-by-step)

Step 1: Define scope for “end-user technologies”

Create a short scoping statement inside the AUP or an attached standard:

• What device types are covered (company-owned endpoints, mobile, virtual desktops, thin clients).
• What software categories are covered (browsers, password managers, remote access tools, collaboration tools, developer tools where relevant).
• Whether BYOD is allowed and under what conditions.

Execution tip: If you cannot inventory it, you cannot credibly claim it is “approved.” Tie scope to what your endpoint management and identity systems can see.

Step 2: Write enforceable “acceptable use” rules

Your acceptable use section should translate into specific user behaviors you can test. Include topics like:

• Prohibited installation of unapproved software.
• Rules for handling company data on endpoints (storage, syncing, removable media).
• Remote access and network use (public Wi-Fi, VPN requirements if applicable).
• Credential handling (no sharing, no storing in plaintext, use of approved password manager if you have one).
• Security hygiene expectations (patching behavior may be handled technically, but the AUP should prohibit tampering with security agents).
• Restrictions on administrative privileges and circumvention.

Keep the wording concrete: “Users must not disable endpoint protection,” “Only approved remote access tools may be used,” “Only company-approved products may be installed.”

Step 3: Establish the company-approved product list (the part assessors ask for)

Create and maintain a list that is:

• Accessible (intranet page, GRC tool, or IT service portal).
• Owned by a function (IT Security, Enterprise Architecture, or IT Ops).
• Versioned with change history.
• Mapped to categories (endpoint OS versions, browsers, remote access, messaging, file sync, password manager, EDR agent, disk encryption).

Also define how products get added (security review, privacy review if needed, licensing, supportability).

Reality check: A PDF that is never updated fails in practice. A living list tied to procurement and endpoint management passes.

Step 4: Get explicit approval by authorized parties

Document who can approve:

• Policy owner (often CISO or Head of Security).
• Business approver (COO/CIO) if that is your governance model.
• Compliance approval (CCO/GRC) for alignment with PCI obligations.

Keep approval evidence: tickets, e-signature workflow, board/committee minutes, or policy management tool records (PCI DSS v4.0.1 Requirement 12.2.1).

Step 5: Implement the AUP (prove it operates)

Implementation is where most teams fall short. Build a minimum control set:

• Policy publication control: AUP is published in a place employees actually use.
• Acknowledgement/attestation: new hire and annual acknowledgement, and acknowledgement for material changes.
• Endpoint enforcement alignment: MDM/endpoint management restricts installs where feasible, pushes approved software, and detects prohibited software.
• Access control alignment: SSO/conditional access restricts access from non-compliant endpoints where feasible.
• Exception process: a documented way to request non-standard tools with time-bound approvals and compensating controls.

If you need a system to track policy versions, attestations, and exceptions, Daydream can function as the control hub so you can show “documented and implemented” with clean audit exports instead of assembling screenshots at the last minute.

Step 6: Operationalize maintenance

Set a review cadence (for example: on a defined schedule and on trigger events like major OS end-of-life, remote work model changes, or new tooling categories). The critical point is consistency: assign an owner and make review evidence repeatable.

Required evidence and artifacts to retain

Keep artifacts that prove documentation, approval, and implementation (PCI DSS v4.0.1 Requirement 12.2.1):

Policy governance

• Current AUP with version number, effective date, owner, and scope.
• Approval record showing authorized approvers and approval date.
• Version history / change log.

Approved product list

• Current approved product list with categories and supported versions.
• Change history and approval workflow for additions/removals.
• Cross-reference to procurement or software request workflow, if you have it.

Implementation evidence

• Training/attestation completion export (employees and relevant contractors).
• Endpoint management reports showing installed software baselines, prohibited software detections, encryption/EDR posture where applicable.
• Access control/conditional access policy configuration evidence, if used to enforce compliant endpoints.
• Exception register with approvals, expiry dates, and compensating controls.

Testing evidence

• Internal control test results (spot checks, software inventory sampling, joiner/mover/leaver checks tied to access).

Common exam/audit questions and hangups

Expect assessors to ask:

• “Show me the AUP and evidence it was approved.” (PCI DSS v4.0.1 Requirement 12.2.1)
• “What are ‘end-user technologies’ in your environment? Show scope.”
• “Where is the list of company-approved products? How do you keep it updated?” (PCI DSS v4.0.1 Requirement 12.2.1)
• “How do you stop users from installing unapproved products?”
• “How do contractors and third parties acknowledge the policy?”
• “Show exceptions and who approved them.”

Hangups usually occur when the product list is informal, approvals are unclear, or attestations are missing for key populations (IT admins, call center users, contractors).

Frequent implementation mistakes and how to avoid them

1. AUP is too generic to test.
   Fix: write “shall/shall not” rules tied to observable behaviors (install controls, remote access tools, tampering prohibitions).

2. No real approved product list.
   Fix: publish a living list with ownership and change control; connect it to procurement and endpoint management.

3. Approval is assumed, not evidenced.
   Fix: capture explicit approvals through a policy workflow and retain records (PCI DSS v4.0.1 Requirement 12.2.1).

4. Policy exists but is not implemented.
   Fix: add acknowledgement, technical enforcement where feasible, and an exception process with expiration.

5. Third-party access is ignored.
   Fix: extend AUP obligations contractually and enforce via identity/endpoint controls for any third party with access to systems that affect the CDE (PCI DSS v4.0.1).

Enforcement context and risk implications

PCI DSS is an industry security standard administered through assessments rather than a single government regulator (PCI DSS v4.0.1). Practically, failing Requirement 12.2.1 increases the likelihood of inconsistent endpoint controls, uncontrolled software sprawl, and weak audit defensibility during PCI scoping and assessor testing (PCI DSS v4.0.1 Requirement 12.2.1). The operational risk shows up as endpoint-originated incidents, hard-to-explain tool exceptions, and gaps between written policy and actual device posture.

Practical 30/60/90-day execution plan

First 30 days: establish minimum compliance posture

• Assign AUP owner and authorized approvers; set review triggers.
• Draft or revise the AUP so it explicitly covers end-user technologies and defines acceptable uses (PCI DSS v4.0.1 Requirement 12.2.1).
• Stand up an initial approved product list with clear categories and ownership (PCI DSS v4.0.1 Requirement 12.2.1).
• Decide where the policy and product list will live (policy portal, GRC system, intranet).

By 60 days: implement and collect proof

• Roll out policy acknowledgement/attestation for employees and relevant contractors; retain exports.
• Implement a lightweight exception workflow with expiry and approvals.
• Align endpoint management: detect prohibited software, standardize deployment for approved tools, and document enforcement approach.
• Run a pilot internal test: sample endpoints and verify alignment to approved list and AUP rules; log findings and remediation.

By 90 days: stabilize operations for assessor testing

• Expand enforcement to higher-risk groups (admins, engineers, support staff with sensitive access).
• Formalize change control for the approved product list, including security review sign-off.
• Package evidence in an audit-ready folder: policy, approvals, version history, product list, training records, endpoint reports, exceptions.
• If evidence gathering is manual and brittle, centralize it in Daydream so audits pull from a single control record with linked artifacts and test results.

Frequently Asked Questions

Does PCI DSS 12.2.1 require employee signatures on the acceptable use policy?

The requirement calls for the policy to be documented and implemented with explicit approval by authorized parties (PCI DSS v4.0.1 Requirement 12.2.1). Attestations are a common way to prove implementation, but the key is retaining credible evidence that the workforce is governed by the policy.

What counts as “end-user technologies” for this requirement?

Treat it as workforce-accessible devices and software used to access company systems, including laptops, desktops, mobile devices, browsers, remote access tools, and collaboration software. Your scoping statement should reflect what can affect CDE security (PCI DSS v4.0.1).

How detailed must the company-approved product list be?

Detailed enough that a user and an assessor can tell what is allowed without guessing, and that IT can enforce it. Group by category and include approved versions where version risk matters (PCI DSS v4.0.1 Requirement 12.2.1).

Can we meet the requirement if users can still install unapproved software?

You can still be compliant if you can show the policy is implemented through governance, detection, and response, plus an exception process; assessors will test whether the control operates in practice. Where possible, tighten technical controls to reduce reliance on after-the-fact detection.

How should we handle third-party contractors or outsourced teams?

If a third party’s people or systems can affect CDE security, include them in scope through contracts, onboarding, and access controls (PCI DSS v4.0.1). Require acknowledgement and enforce access from compliant endpoints where feasible.

We have multiple AUPs across subsidiaries. Is that a problem?

Multiple documents can work if they are consistent, explicitly approved, and mapped to the same approved product list and enforcement model. Most audit friction comes from conflicting rules or unclear applicability across entities.