3.3 Sensitive authentication data after authorization

What PCI DSS 3.3 asks for and why encryption does not change the answer

If your team has found card data in logs, databases or support tools, the short answer is that PCI DSS Requirement 3.3 forbids keeping sensitive authentication data after authorization, even if it is encrypted. Sensitive authentication data (SAD) is the security-related information used to authenticate cardholders or authorize card transactions, and the PCI SSC glossary names card verification codes, full track data, PINs and PIN blocks. A finding of stored SAD is a finding regardless of where the data sits or how it is protected, so the first job is to establish what was stored, where, and for how long.

Requirement 3.3 has three sub-requirements. Sub-requirement 3.3.1, with 3.3.1.1 to 3.3.1.3 covering full track data, card verification codes, and PINs and PIN blocks, bars retaining each element of SAD once authorization completes. Sub-requirement 3.3.2 applies to SAD stored electronically before authorization, which must be encrypted with strong cryptography, and it became a required control rather than a best practice on 31 March 2025. Sub-requirement 3.3.3 adds rules for issuers and the businesses that support issuing. The reason for the rule is fraud: SAD such as a card verification code or a track dump is enough to create counterfeit cards or make card-not-present purchases, and encryption only delays that use until someone obtains the key. Confirm with your acquirer or the relevant payment brand whether any pre-authorization storage is permitted at all, because PCI DSS sets no time limit for holding SAD before authorization and the brands decide that question.

Teams find this hard because SAD rarely sits in one place. Application logs capture request bodies during an error, debug dumps and crash reports include memory contents, and backups preserve data that was deleted from the live system. Support tools, call recording and ticketing attachments, and third-party analytics or fraud-screening integrations can all receive the same payload. Start by searching logs, backup sets, message queues and vendor-held copies for the specific fields, then trace the code path that wrote them. Each copy needs an owner and a deletion or redaction step, and the fix should include a control that stops the data being written again, not only a one-time clean-up.

Which systems, data and teams fall under 3.3

Sensitive authentication data rarely sits in one obvious place. It shows up wherever a transaction is authorized, investigated, supported or tested, so the scoping work starts by listing those places. The cards below cover the common locations and the classification decisions that change the work.

Authorization and fraud tools

Authorization engines, fraud scoring platforms and 3-D Secure components often receive card data during a transaction. Check whether any of them write CVV2 or CVC values, full track data or PIN blocks to queues, caches, retry buffers or debug output after the authorization response returns. Requirement 3.3.1 applies to anything retained after authorization, so an unexpected cache is a finding even when it is encrypted. Confirm the exact fields each tool receives and how long it keeps them.

Issuer processing systems

Issuers carry extra obligations under Requirement 3.3.3, which sets rules beyond those for merchants and acquirers. Systems that personalize cards, manage PIN data or support issuing workflows need a documented inventory of where sensitive authentication data may exist before and after authorization. Teams should confirm with their payment brands and assessor which issuer rules apply to their product set, because the brands decide whether SAD may be held before authorization at all.

Logs and monitoring pipelines

Application logs, APM traces, web server access logs and message broker payloads are a frequent source of stray SAD. A verbose logging setting, a failed request dump or a copied payload in an error ticket can capture CVV2 values or track data even when the main database is clean. Search log stores and monitoring indexes with the same rigor as production databases, and confirm that log filters remove SAD before data is written.

Support and call-center tooling

Agents who take card details over the phone or resolve chargebacks may use ticketing systems, call recording platforms and screen capture tools. Each can hold a CVV2 typed during a call or a note that repeats it. Map every channel where an agent can enter or view card data, decide whether those channels may store SAD at all, and confirm that recordings and notes are reviewed or redacted according to the policy set under Requirement 3.2.

Backups, test data and copies

Backups, database snapshots, disaster recovery replicas and copies made for analytics or troubleshooting can preserve SAD long after the production record has been cleared. Test and staging environments are a common gap when teams restore production data to reproduce a defect. Ask who can create copies, where they land and whether the retention schedule for those copies matches the schedule for the source system.

Third-party platforms and 3DS values

Outsourced processors, hosted checkout providers and SaaS tools in the payment flow may hold SAD on your behalf, and their responsibilities must be written down. Classify 3-D Secure authentication values carefully: PCI SSC FAQ 1603 states that these values are not sensitive authentication data for PCI DSS purposes, and PCI DSS does not prohibit storing them after authorization. Label each data element by what it is, not by which system stores it, and record that classification in your data-flow inventory.

How an assessor tests 3.3 and what evidence they request

This table compares how an assessor tests each part of Requirement 3.3, the evidence they ask for, and the findings that most often cause failures. Read each row as a question the assessor will put to your environment, then gather the matching evidence before the assessment starts. The main takeaway is that assessors test where SAD actually lands, not only whether a policy forbids storing it.

Requirement	Test approach and evidence requested	Common findings
3.3.1 (with 3.3.1.1 to 3.3.1.3): no SAD after authorization	Sample authorization records, databases, transaction logs, application logs, debug output and backups, then confirm no full track data, card verification codes, or PINs and PIN blocks remain. Request data discovery scan results, deletion job records, and screenshots or query output showing the sampled stores are empty of SAD.	SAD in application logs or debug output; SAD left in database fields or archive tables; backups holding SAD after authorization with no documented handling.
3.3.2: SAD held before authorization	Review the authorization flow design to confirm where SAD is held and for how long, then verify encryption with strong cryptography on the stored values. Request data flow diagrams, encryption configuration, key references, and the brand rules the organization relies on for pre-authorization storage.	Pre-authorization SAD stored in plaintext in queues, caches or temporary files; encryption configured on one store but not on message brokers or retry queues.
3.3.3: issuer-specific rules	Confirm whether the entity issues cards. If so, review how SAD is handled in issuing and authorization systems, including any retention for issuing operations, and request documented justification and the controls applied to it. If not applicable, request the documented rationale.	Issuer SAD retention with no documented business basis; issuing platforms that retain SAD in support or migration datasets.
Support tickets, call recordings and exports (cross-cutting)	Sample support tickets, chat transcripts, call recording metadata and CSV exports. Confirm staff and support tools cannot capture CVV or PIN values and that any incidental capture is deleted under the documented process.	Card verification codes pasted into support tickets; CVV captured in chat or help desk attachments; exports containing SAD.
Encryption used as a substitute for deletion (cross-cutting)	Test whether stored SAD is removed, not just encrypted. Request evidence that the deletion or purge runs and that encrypted SAD values no longer exist in the sampled stores.	Encrypted SAD retained after authorization on the basis that it is protected; key rotation treated as a reason to keep old SAD.

How to implement 3.3 in a live payment environment

This sequence takes a live payment environment from unknown SAD exposure to a state where no sensitive authentication data is kept after authorization, with each step leaving a record an assessor can test. Your organization owns the work and the decisions, while an implementation partner or internal team prepares the maps, changes and records.

Confirm the brand rules for SAD before authorization
Before touching any system, confirm with each payment brand and acquirer whether SAD may be held before authorization at all, and under what conditions. PCI DSS sets no time limit for holding SAD before authorization, so the brand rules decide what is allowed (see PCI SSC FAQ 1154 for the reasoning). Record the answer per brand and per flow, with the contact and date. This step is done when the written position is signed off by the people who own the payment acceptance relationship.
Map every point where SAD can arrive
Inventory every channel that can deliver card data to your systems: checkout pages, point-of-sale terminals, call center tools, mobile apps, batch files, fraud and dispute feeds, and support tickets. For each channel, record whether SAD (full track data, card verification codes, PINs or PIN blocks) can appear, and where it flows next. The output is a SAD data map tied to your network and data-flow diagrams. It is complete when every channel has an owner and a stated answer on SAD.
Find and classify existing copies
Search the environment for SAD that has already been stored. Cover application logs, error traces, caches, message queues, databases, backups, memory and crash dumps, screenshots, and developer or test copies. Use scanning tools on the systems you control and manual review where tooling cannot reach. Classify each finding by system, owner, and whether it was stored before or after authorization, because the rules for each case differ. The output is a findings register that the purge step works from.
Stop capture at the source
Change the code, configuration or integration that writes SAD so that it no longer does so. Remove logging of request bodies on payment endpoints, disable debug output that echoes card fields, and adjust integrations so that authorization responses are not written to disk after the transaction completes. Route any still-required flow through a path that does not persist SAD. Change records, peer review approvals and test results show this step is done, and a repeat run of the find step should return no new SAD.
Delete existing copies and keep proof
Purge each copy listed in the findings register, starting with the most exposed systems such as logs, caches and backups. Where backups hold SAD, confirm with your backup owner how restoration would reintroduce it and whether those sets need removal or rebuilding. For each deletion, record the system, the method, the operator, the date and an independent check that the data is gone. The purge record is the evidence an assessor will ask for, so keep it with the change tickets it relates to.
Add controls that prevent recurrence
Put checks in place so SAD does not come back. Require code review for changes to payment logging and data handling, and protect the main branches of payment repositories so that changes cannot be pushed directly and must pass review. Run static analysis in the build pipeline with rules that flag card-field names being written to logs or storage, and add log filters that mask patterns before they leave the application. Document each control with its owner. The output is a set of pipeline configurations and review settings that can be shown on request.
Set up recurring verification
Schedule repeated searches for SAD across the systems in the data map, with results sent to the owner of each system, and review any new findings through the same purge and change process. Repeat the mapping when a new payment channel, vendor or integration is added. Keep the scan reports, the purge records and the change history together so the evidence for each cycle can be produced without rebuilding it. Confirm with your assessor, a QSA or the team that will validate your environment, which evidence format they expect for this requirement.

Evidence that satisfies an assessor for 3.3

An assessor testing 3.3 wants proof that sensitive authentication data is absent after authorization, not just a policy saying so. The cards below cover the artifacts that show where SAD was found, how it was removed, and how absence is checked over time. Each artifact needs a named owner and a refresh trigger, so the evidence stays current between assessments.

SAD data map

A data map lists every location where card verification codes, PIN data or full track data was found, including logs, caches, message queues, backups and support exports. For each location it records how the element was removed or prevented from being written, and who verified the fix. Refresh it after every new integration, change to a payment flow or new third-party tool, and have the payment owner and the security lead sign it off. Ask the assessor how they want locations grouped before you build it.

Purge and deletion records

Purge records prove that SAD held before or during processing was deleted, with timestamps, the system or job that ran the deletion, and the scope covered. Check that the records match the data map, and that deletions reach backups and replicas as your documented process says they do. Operations management should review a sample of records each cycle and sign off, and the process owner should note any deletion that failed and how it was fixed.

Logging and capture filter configuration

Configuration exports for application logs, web application firewalls, APM agents and debugging tools show that filters block SAD from being captured. Keep the exported settings under version control and compare them against the deployed state. Platform engineering should own the configuration, and the security team should review changes before they reach production. Test the filters with known dummy values so you can show they actually drop data.

Code review and scan results

Code review records and static analysis output show that new code does not persist SAD. Custom rules can flag variables or fields that hold card verification codes, PINs or track data before they reach a storage call or log statement. Retain the scan reports, the rule set version and the triage decisions for each finding. The application owner should close each finding with a reason, and the security engineer should sign off on rule changes.

Documented brand rules on pre-authorization storage

Where SAD must be held before authorization, the rules come from each payment brand and acquirer, not from the standard alone. Keep a written record of the brand or acquirer rules that apply to your business, the date you last confirmed them, and the specific data elements and flows they cover. The compliance lead should own this record, and legal or the acquirer relationship owner should confirm it whenever a brand publishes a change.

Recurring verification output

Recurring checks, such as scheduled searches of storage, logs and backups for SAD patterns, produce dated output that shows absence over time. Review each run for false positives and missed patterns, and record the result. The security operations lead should own the schedule, and the compliance lead should sign off on the review record before each assessment. Document the search patterns used so the assessor can see what the check covers.

What meeting 3.3 costs in money and effort

This table compares the main cost components of meeting Requirement 3.3, who is paid for each, whether the cost is one-time or recurring, and what drives it up or down. Read it as a checklist for requesting a written scope and quote, since no figures are published here. The main takeaway is that open-source tooling can reduce license spend, but the largest cost is usually engineering time to remove sensitive authentication data from systems.

Cost component	One-time or recurring, and who is paid	What drives it up or down and how to keep it down
Data discovery and classification tooling or licenses	Licenses recur if commercial. Open-source tools cost staff time to deploy, tune and run. The organization pays its vendor or its internal team, or a partner if scoped.	Driven by the number of systems, logs, databases and file shares searched. Keep it down by scoping discovery to in-scope systems and recording results in the data map.
Engineering time to remove capture and purge copies	One-time for the removal work, with some recurring checks. The organization's developers or a partner are paid, usually as fixed-scope work.	Driven by how many applications, logs and debug paths capture SAD, and by how much legacy code must change. Keep it down by fixing capture at the source, such as disabling CVV or track logging, before cleaning historical copies.
Code and pipeline controls	Mostly one-time setup, then recurring maintenance of rules and pipeline jobs. Internal engineers or a partner are paid.	Driven by the number of repositories and languages scanned and the number of custom rules needed. Keep it down by using existing CI/CD stages and community rules first, then adding custom rules only where a gap is found.
Evidence upkeep	Recurring. Internal compliance staff, system owners or a partner are paid to collect and retain scan results, purge logs and sign-offs.	Driven by how often systems change and how many people must produce records. Keep it down by automating evidence export from tooling and assigning one owner per system.
External testing or review of the data map	Recurring or periodic. A qualified outside reviewer is paid under a written scope. Independent assessors do not design the controls they later test.	Driven by the number of data flows and storage locations in scope. Keep it down by maintaining an accurate data-flow diagram so reviewers spend less time reconstructing the environment. Ask for the reviewer's scope and deliverables in writing.
Assessor sampling during the QSA audit	Recurring with each assessment. The organization pays its Qualified Security Assessor under its contract, and the QSA decides what to sample.	Driven by the number of systems and data stores the QSA samples and how many exceptions appear. Keep it down by providing complete, consistent evidence for each sampled system and by confirming scope before the audit begins.
Open-source tooling licenses	Open-source licenses carry no license fee, but deployment, hosting and support are paid to staff or a partner, and are often recurring.	Driven by hosting size, upgrade frequency and the depth of support needed. Open-source tooling can remove license spend but does not remove engineering time, which remains the main cost of meeting 3.3.

Where self-hosted open-source tools help with 3.3, and where they do not

Open-source tools can support Requirement 3.3, but none of them removes the need to stop SAD from being stored after authorization. The control is a set of decisions about what your systems keep, and tools only help with the parts that can be built, changed and checked. Start by deciding which tool covers which job. OpenBao's transit secrets engine can encrypt and decrypt application data without storing the data itself, and it supports versioned encryption keys with key rotation. That makes it a candidate for protecting SAD in the narrow case where your payment brand rules allow it to be held before authorization (3.3.2 requires strong cryptography in that case). Confirm with your acquirer or brand that the holding is permitted at all, because the standard sets no time limit and the brands decide whether pre-authorization storage is allowed.

Two other tools help keep new persistence paths from appearing. Semgrep Community Edition scans code in a range of languages, including Java, Python, Go, JavaScript and TypeScript, with community or custom rules, and it can run in CI/CD pipelines. A custom rule can flag code that writes a card verification code, track data or PIN to logs, files, databases or message queues, which is a common way SAD ends up stored by accident. GitLab Community Edition protected branches let you limit which roles can push or merge changes to repositories that handle payment flows, block direct pushes, and keep force pushes disabled. Confirm with your assessor how they will review rule coverage and branch settings as evidence, because a scanner only finds the patterns its rules describe.

Nextcloud server-side encryption should not be counted as a 3.3 control. It protects file contents at rest on local and external storage, but it does not encrypt file names or folder structure, and it does not decide whether SAD may be stored. If a file contains SAD after authorization, encryption does not change the outcome under 3.3.1. Treat the platform as a place where you must prove that no SAD is kept, using data discovery and retention checks, and confirm with your QSA how each tool fits your environment and how its configuration will be documented as evidence.

Who owns 3.3: your team, an implementation partner and the QSA

Your organization owns the outcome of Requirement 3.3. Nobody else can decide what your business needs to receive, authorize and store, and the standard holds the entity responsible for proving that no sensitive authentication data remains after authorization. Your internal owners set the policy, approve exceptions and sign off each deletion.

Data map ownership: Your team maintains the inventory of every location where card verification codes, PINs, PIN blocks or full track data could appear, including logs, support tickets, call recordings, message queues, backups and test data.
Pre-authorization decision: Whether any SAD may be held before authorization, and for how long, is a business and brand decision. Confirm with your acquirer and the relevant payment brands before designing the flow.
Deletion sign-off: A named owner should approve purge jobs, confirm the scope of each deletion and keep the record of what was removed and when.
Issuer obligations: If you issue cards, your team owns the additional rules in 3.3.3 and must decide how those are applied to your issuing platform.

Before engaging anyone, ask your internal owners to confirm the data map is current, because every later step depends on it.

Where 3.3 programs usually fall short and how to close each gap

Most gaps under Requirement 3.3 are not about missing encryption. They come from SAD that was never removed, that spread into places nobody reviewed, or that was never checked again after the first assessment. The cards below pair each gap with the fix and the evidence an assessor will ask to see.

Encryption used in place of deletion

Teams often encrypt stored CVVs or PINs and treat the job as done. Requirement 3.3.1 bars keeping SAD after authorization in any form, so encrypted copies still fail. The fix is to delete SAD at authorization, or to confirm it was never written to storage in the first place. Evidence is a data-flow diagram showing where SAD stops, plus a test that searches the datastore after a transaction and finds nothing.

SAD captured in logs and debug output

After go-live, verbose logging, error traces and debug flags often write request bodies that contain card verification codes or track data. Developers rarely review these paths once payments are live. The fix is to strip SAD fields at the logging layer and disable debug output in production. Evidence is a log sample from production showing no SAD, plus a code scan in the pipeline that flags logging of payment fields.

Copies in backups and disaster recovery

Backups, snapshots and disaster recovery sites often capture databases and queues that held SAD during a transaction window. Those copies are usually outside the team's normal review. The fix is to confirm which backup sources can contain SAD, exclude or purge those fields before backup, and test restores against the same search used for live systems. Evidence is a documented backup inventory and restore test results showing no SAD in restored data.

Call center and support recordings

Agents who take card details by phone may be recorded, and agents reading a CVV aloud can leave it in ticket notes or chat transcripts. Recording platforms and ticketing tools are often not in the payment scope review. The fix is to pause recording during card capture, use DTMF masking or agent-side payment flows, and block SAD fields in notes. Evidence is a configuration record for the recording and ticketing tools plus sampled transcripts with no SAD.

Third-party tools that capture SAD

Analytics scripts, session replay tools, customer support widgets and browser extensions can capture form fields, including CVV inputs, and send them to outside services. The organization still owns the exposure even when the vendor holds the data. The fix is to inventory every script and SDK on payment pages and exclude payment fields from capture. Evidence is the script inventory, the field-exclusion settings, and a test showing the vendor receives no SAD.

No recurring check after the first audit

Many programs pass one assessment and then drift as new features, logs and vendors are added. Requirement 3.3 has no exception for systems that were clean last year. The fix is a recurring SAD search across datastores, logs, backups and recordings, tied to change review so new components are checked before release. Evidence is dated search results, change tickets showing SAD review, and a named owner who signs off each cycle.

Common questions about PCI DSS 3.3 cost, effort and outside help

Can we ever keep sensitive authentication data after authorization under PCI DSS?

No. Requirement 3.3.1 bars retaining sensitive authentication data after authorization, and that covers full track data, card verification codes, and PINs and PIN blocks. The bar applies to every copy you hold, including copies in logs, support tickets, databases, backups and analytics stores. Your practical question is therefore where SAD could be written during the transaction flow and how fast it is removed or never persisted. Ask your assessor and your payment brand to confirm how they read any edge case before you design around it. For context on storage before authorization, see PCI SSC FAQ 1154.

Does encrypting sensitive authentication data make it acceptable to keep?

No. Encryption does not make retained SAD compliant with Requirement 3.3.1, because that rule forbids keeping SAD after authorization whether or not it is encrypted. Encryption does matter for SAD held before authorization: Requirement 3.3.2 requires strong cryptography for electronically stored SAD, and that rule now applies even where no PAN is present. Encryption protects the data before authorization; it does not replace deletion afterward. Confirm with your QSA how your key management and purge steps will be evidenced.

How much effort does a discovery and purge of stored SAD usually take?

The effort depends on how many places SAD can land, and no duration figure is supplied for this work, so ask for one in writing. The main drivers are the number of systems in the cardholder data environment, the number of log, cache, queue and backup stores, whether developers have ever logged raw request bodies, and how many third-party tools receive payment traffic. A quote should separate discovery (locating SAD across code, data stores and logs), remediation (changing code and configuration), and verification (showing that the fix holds over time). Ask whether the partner will deliver evidence for each store and whether retesting is included.

Can our team handle Requirement 3.3 without an outside partner?

Often yes, if you have engineers who know the payment flow and a compliance lead who can document it. A team can run discovery, change logging configuration, and build a purge routine on its own. Outside help makes most sense when the scope is large, when logs or backups are hard to inspect, or when no one internally has time for evidence collection. The organization always owns its controls. A partner such as DeployOpen prepares systems and evidence under a written, fixed scope, but only an independent QSA issues the Report on Compliance or the Attestation of Compliance.

What do our engineers and compliance lead need to contribute?

Engineers need to map every code path that handles card transactions, identify where request and response data is logged or cached, and confirm which fields are removed or never written. The compliance lead needs to own the written policy on SAD, define who approves exceptions, and keep dated evidence such as configuration exports, test results and purge job records. Both roles should agree on the data-flow diagram, because assessors test against it. Ask any partner to name the deliverables each role receives and the sign-off points before work starts.

How do payment brand rules change what we may store before authorization?

PCI DSS sets no time limit for holding SAD before authorization, and the individual payment brands decide whether SAD may be stored before authorization at all. That means your brand agreements can be stricter than the standard, and the standard alone does not settle the question. Check your acquirer or processor documentation and get written confirmation before you design a pre-authorization buffer. If a brand permits storage, Requirement 3.3.2 still applies to the encryption of that data.

Can our implementation partner also act as our PCI DSS assessor?

No. The partner can prepare systems, configuration, code changes and evidence, but only an independent Qualified Security Assessor can complete a Report on Compliance for the assessment. Using the same firm to design the controls and then judge them creates an independence problem that assessors and payment brands will question. DeployOpen states that it prepares systems and evidence for compliance assessments and does not issue audit reports, attestations or certifications. Ask any vendor to confirm in writing who signs each document and how the QSA's independence is protected.

How DeployOpen scopes and prepares 3.3 evidence

DeployOpen works on requirement 3.3 as an implementation partner: we map where sensitive authentication data could appear in your systems, prepare the technical controls and records an assessor will ask for, and leave your organization in charge of the control. Your independent QSA or assessor decides whether the requirement is met and issues the report.

How we scope

Map every flow where full track data, card verification codes, PINs or PIN blocks could be received, held or logged.
Confirm with your payment brands whether any SAD may be stored before authorization and for how long.
Agree the scope, deliverables and timeline in writing before any work starts, as all engagements are fixed-scope.

How we build

Configure application and database settings so SAD is discarded after authorization and never written to logs or caches.
Where SAD must be held before authorization, prepare encryption with strong cryptography using keys managed in your key infrastructure.
Test the configuration against your own data flows and record the results for review by your assessor.

How we hand over

Provide documented configurations, data flow notes and test results that show how each 3.3 sub-requirement is addressed.
Document the evidence your team must keep current, such as periodic checks that no SAD appears in storage or logs.
Walk your team and assessor through the evidence set so responsibilities for each control are clear.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Review changes to payment flows, logging or storage that could reintroduce SAD into your environment.
Ask us to confirm scope and evidence again before each assessment cycle, with the final attestation still issued by your assessor.