PINs Not Retained

PCI DSS requires that you do not store a customer’s PIN or PIN block after the authorization is finished. To operationalize “PINs Not Retained,” you must prevent PIN data from being written to logs, databases, message queues, analytics tools, crash dumps, or backups, and you must be able to prove it through configuration, testing, and evidence. (PCI DSS v4.0.1 Requirement 3.3.1.3)

Key takeaways:

• PINs and PIN blocks must never persist beyond authorization, including in “accidental storage” locations like logs and backups. (PCI DSS v4.0.1 Requirement 3.3.1.3)
• Scope includes your systems and connected third parties that handle PIN entry, PIN translation, switching, or authorization flows.
• Evidence is technical: data-flow mapping, secure configurations, and test results showing PIN/PIN block absence post-authorization.

“PINs Not Retained” sounds simple, but teams fail it for predictable reasons: they focus on the primary payment application and miss secondary systems that copy or record data. The operational challenge is not just “don’t store it on purpose.” It is preventing PIN or PIN block data from ending up in places you did not intend: debug logs, API traces, APM tools, message payloads, dead-letter queues, screenshots, support tickets, memory dumps, disk swap, and backups.

PCI DSS v4.0.1 Requirement 3.3.1.3 is narrow and strict: after authorization, PIN and PIN block retention is not allowed. (PCI DSS v4.0.1 Requirement 3.3.1.3) That means you need (1) a clean, documented payment data flow, (2) technical controls that make retention hard or impossible, (3) monitoring and testing that can detect regression, and (4) third-party governance so outsourced payment components do not become your blind spot.

This page is written for a Compliance Officer, CCO, or GRC lead who needs to translate the requirement into concrete work for engineering, infrastructure, and payment operations, then collect evidence that stands up in an assessment.

Regulatory text

Requirement statement: “The personal identification number (PIN) and the PIN block are not retained upon completion of the authorization process.” (PCI DSS v4.0.1 Requirement 3.3.1.3)

Operator meaning: Once authorization is complete, your environment must not store a PIN or PIN block anywhere, in any form you can reasonably control. If a system component writes it to disk, ships it to a logging platform, or captures it in backups after authorization, you are out of compliance. (PCI DSS v4.0.1 Requirement 3.3.1.3)

Plain-English interpretation (what “not retained” really means)

“Not retained” includes both:

• Intentional storage (tables/fields designed to store PIN/PIN block).
• Incidental storage (logs, traces, telemetry events, support exports, queue payload persistence, crash dumps, backups).

“Upon completion of the authorization process” is the line in the sand. Your design should treat PIN/PIN block as ephemeral data that exists only long enough to complete the authorization-related function and is never written to persistent storage.

Who it applies to (entity + operational context)

Applies to any organization in PCI scope that handles PIN-based transaction flows, including:

• Merchants that accept PIN debit at POS or through attended/unattended devices and route transactions for authorization. (PCI DSS v4.0.1 Requirement 3.3.1.3)
• Service providers offering POS software, payment gateways, routing, managed infrastructure, or log/monitoring services in the cardholder data environment (CDE) or connected systems. (PCI DSS v4.0.1 Requirement 3.3.1.3)
• Payment processors/switches that perform authorization routing and may handle PIN blocks for translation/processing. (PCI DSS v4.0.1 Requirement 3.3.1.3)

Operational contexts where this requirement commonly shows up:

• POS applications that handle PIN entry devices (PEDs) and send PIN blocks upstream.
• Payment gateways that terminate a connection from POS and forward authorization requests.
• HSM-integrated services that translate or validate PIN blocks.
• Message-driven architectures (queues/streams) carrying authorization payloads.

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

1) Map the PIN/PIN block data flow end-to-end

Create (or update) a payment data-flow diagram that explicitly marks:

• Where PIN entry occurs (device, application component).
• Where the PIN block is formed and where it travels.
• Where authorization begins and ends in your system boundary.
• Every hop where payloads are copied: API gateway, service mesh, queues, APM, WAF, SIEM.

Deliverable: a “PIN/PIN block flow” overlay on your payment data-flow diagram, with system owners.

2) Identify every persistence surface that could capture PIN data

Run a structured inventory across:

• Application logs (including debug-level toggles).
• API gateway/WAF logs and request/response capture settings.
• Observability tooling (APM traces, error reporting, session replay, RUM, mobile crash analytics).
• Message queues/streams (retention settings, dead-letter queues, replay features).
• Databases and caches (including “temporary” tables and key-value stores).
• Backup, snapshots, DR replicas, and log shipping targets.
• Ticketing/support tooling (attachments, HAR files, screenshots).

Outcome: a list of “PIN persistence risks” with owners and remediation tasks.

3) Implement hard prevention controls (design for non-retention)

Make the prevention technical, not policy-only:

• Log redaction/filtering: Ensure PIN-related fields are never logged. Enforce allowlists for logged fields rather than blocklists.
• Telemetry minimization: Disable request/response body capture in gateways/APM for authorization endpoints, or apply field-level scrubbing before emission.
• Queue hygiene: Do not place PIN/PIN block in asynchronous payloads unless strictly required for authorization, and if present, ensure short retention and no replay to non-payment environments. If authorization can be synchronous, keep PIN out of durable messaging.
• No storage by schema: Ensure there are no database fields intended for PIN/PIN block. Build static checks to prevent adding them later.
• Disable “support capture” defaults: Prevent or restrict tools that collect payloads automatically during incidents.

Your technical teams should be able to explain, component by component, why PIN/PIN block cannot end up on disk after authorization. (PCI DSS v4.0.1 Requirement 3.3.1.3)

4) Validate with testing (prove absence, not intent)

Do not rely on “we don’t store it.” Validate.

• Negative testing: Execute a PIN-based authorization in a test environment mirroring production controls, then search for PIN/PIN block patterns in logs, traces, queue payloads, and database storage.
• Configuration validation: Export gateway/APM logging configs showing body capture disabled or redaction enabled for payment endpoints.
• Regression hooks: Add automated tests or pipeline checks that fail builds if sensitive fields are added to logs or analytics events.

The goal is to show assessors that retention is prevented by design and verified in operation. (PCI DSS v4.0.1 Requirement 3.3.1.3)

5) Control third parties and shared responsibility

Where a third party provides any payment component (gateway, POS software, managed logging, managed Kubernetes, etc.), you still need clarity and evidence:

• Contractual language requiring PIN/PIN block non-retention after authorization in services they operate for you.
• An integration diagram that shows whether PIN/PIN block traverses their systems.
• Attestations or technical evidence (where available) that their logging/telemetry does not store PIN/PIN block.

If you cannot get strong evidence, reduce scope by redesign: keep PIN/PIN block within a tightly controlled payment pathway and avoid routing through general-purpose platforms.

6) Operationalize: monitoring + change control

Non-retention fails most often after a change:

• A developer enables debug logging during an outage and forgets to turn it off.
• An APM agent update turns on body capture.
• A gateway policy change starts recording request payloads.

Add controls:

• Change reviews for payment endpoints and logging configuration changes.
• Alerts for logging level changes in payment services.
• Periodic checks that sensitive-field redaction rules still match actual field names.

Required evidence and artifacts to retain

Keep evidence that connects requirement text to real controls:

• PIN/PIN block data-flow diagram and system inventory (include owners and boundaries).
• Logging/telemetry configuration exports for payment services (show redaction/body capture settings).
• Secure coding/logging standard that explicitly prohibits PIN/PIN block logging and storage. (PCI DSS v4.0.1 Requirement 3.3.1.3)
• Test plans and results demonstrating searches across logs/queues/storage show no PIN/PIN block retained after authorization.
• Change management records for payment logging and observability settings.
• Third-party contracts/addenda and due diligence artifacts addressing PIN/PIN block non-retention in their operated components.

Tip: Evidence should show both preventive controls (configs, design) and detective controls (tests, monitoring).

Common exam/audit questions and hangups

Assessors commonly press on:

• “Show me where PIN enters and where it leaves your environment.” Bring the data-flow and integration boundaries.
• “Prove it’s not in logs.” Expect log samples plus config showing redaction/body capture disabled for authorization endpoints.
• “What about your APM tool?” Have explicit settings and a rationale for any captured fields.
• “Do you use queues?” Be ready to show payload schemas and retention settings.
• “What about backups?” Explain how you prevent PIN from landing in persistent storage in the first place; if it’s never stored, it can’t be backed up.

Hangup to avoid: teams produce a policy but no technical verification. The requirement is technical in effect. (PCI DSS v4.0.1 Requirement 3.3.1.3)

Frequent implementation mistakes (and how to avoid them)

1. Relying on “we don’t store PIN” interviews.
   Fix: require negative testing and configuration exports.

2. Redacting the wrong field names.
   Fix: implement log allowlists; add unit tests for log events.

3. Forgetting non-prod environments.
   Fix: apply the same controls to staging and QA if they process real payment traffic or realistic payloads; avoid using production-like PIN data outside controlled test paths.

4. Queue dead-letter retention as a hidden datastore.
   Fix: review DLQ retention and payload; keep PIN/PIN block out of async flows where possible.

5. Incident tooling capturing payloads.
   Fix: restrict who can enable verbose captures; time-box and audit those toggles.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this requirement, so this page does not cite specific enforcement actions.

Operational risk is still clear: retaining PIN or PIN blocks creates high-impact exposure if systems are breached, and it expands PCI scope because more systems become sensitive-data stores. It also creates hard cleanup problems because backups and replicas can preserve prohibited data long after you “delete it” from the primary system.

Practical execution plan (30/60/90-day)

Use this as an execution structure (adjust to your change cadence and assessment date):

First 30 days (Immediate stabilization)

• Build the PIN/PIN block data-flow overlay and confirm system ownership.
• Inventory persistence surfaces: logs, APM, gateways, queues, databases, backups.
• Apply quick wins: disable body capture on authorization endpoints; enforce sensitive-field redaction in log pipelines.
• Define evidence format you will keep for assessment (config exports, test results, diagrams). (PCI DSS v4.0.1 Requirement 3.3.1.3)

By 60 days (Control hardening + validation)

• Implement allowlist-based logging in payment services.
• Remove PIN/PIN block from any async payloads that do not strictly require it for authorization.
• Create repeatable negative testing and artifact retention (runbooks + stored results).
• Update third-party requirements and request supporting evidence for operated components.

By 90 days (Sustained compliance operations)

• Add CI/CD checks for sensitive logging regressions.
• Add monitoring/alerts for logging level or telemetry configuration drift.
• Perform a tabletop “incident debug” scenario to confirm teams can troubleshoot without enabling prohibited logging.
• Centralize evidence collection so you can answer assessor questions quickly.

Where Daydream helps: teams often lose time chasing “where did this payload go?” Daydream can centralize third-party due diligence artifacts, map responsibility boundaries, and keep recurring evidence requests and renewals from turning into a scramble during PCI assessments.

Frequently Asked Questions

Does “PINs not retained” include encrypted PIN blocks?

Yes. The requirement covers both the PIN and the PIN block, and it prohibits retention after authorization. (PCI DSS v4.0.1 Requirement 3.3.1.3)

If we store authorization request/response logs for troubleshooting, is that allowed?

Only if those logs do not contain the PIN or PIN block after authorization. For payment endpoints, configure logging to exclude request bodies and scrub sensitive fields. (PCI DSS v4.0.1 Requirement 3.3.1.3)

Are transient memory buffers considered “retained”?

The requirement targets retention upon completion of authorization, so your design should avoid writing PIN/PIN block to persistent storage and should keep any in-memory handling strictly ephemeral. Your evidence should focus on proving it is not stored in logs, databases, queues, or backups post-authorization. (PCI DSS v4.0.1 Requirement 3.3.1.3)

What’s the fastest way to prove compliance to an assessor?

Provide a PIN/PIN block data-flow diagram, the logging/APM configuration exports for payment services, and test results showing searches across logs and storage return no PIN/PIN block artifacts after authorization. (PCI DSS v4.0.1 Requirement 3.3.1.3)

How do we handle third parties that run part of our payment stack?

Treat them as in-scope for shared responsibility. Contractually require PIN/PIN block non-retention after authorization and collect due diligence evidence that their logging/telemetry and storage controls prevent retention. (PCI DSS v4.0.1 Requirement 3.3.1.3)

What if we discover historical PIN block data in logs or backups?

Escalate immediately: stop further collection, identify all storage locations (including replicas/backups), and execute a controlled purge and retention correction plan with documented evidence. Then add regression controls so the issue cannot recur. (PCI DSS v4.0.1 Requirement 3.3.1.3)