3.1 Stored account data processes and roles

What PCI DSS 3.1 asks for and why stored data policies fail audits

Requirement 3.1 is a documentation and accountability requirement with two sub-requirements. Requirement 3.1.1 asks for the security policies and operational procedures that govern Requirement 3 to be documented, kept up to date, in use and known to everyone they affect. Requirement 3.1.2 asks for the roles and responsibilities for those activities to be documented, assigned and understood. A QSA or ISA will test both by reading the written policy set and interviewing the people who are supposed to run it. The risk behind these sub-requirements is inconsistent handling of stored account data: one team keeps a card number for thirteen months because nobody told it the retention rule, another encrypts a database while the key custodian has left and nobody updated the assignment. Technical controls under 3.2 to 3.7 can work well and still fail an audit if the paperwork does not describe them or the people cannot explain them.

Policies usually fail for three reasons. They are written once for an assessment and then left alone, so they describe a system that no longer exists. They have no named owner, so when a retention period or disposal method needs changing, nobody is accountable for the change. And they do not match the actual environment, which means the stated key custodians, storage locations and disposal steps differ from what the systems and tickets show. Assessors look for these gaps by comparing the policy against architecture diagrams, data inventories and interview answers. A practical first check is to pick three stored data locations from your inventory and ask the person listed as responsible to walk through their procedure. If the answer differs from the document, the policy is not yet 3.1 ready.

Before the next assessment, confirm three things with your QSA: which policy documents they expect to see for Requirement 3, the format they accept for roles records such as a RACI matrix, and how they want evidence of awareness, such as acknowledgment records or training completion. Assign each policy an owner with a review date tied to changes in the cardholder data environment, not only to the calendar. The requirement text itself and the self-assessment testing approach are available from the PCI SSC PCI DSS page, which is the authoritative reference for the exact expectations.

Which teams, systems and third parties PCI DSS 3.1 covers

Requirement 3.1 applies to every location where stored account data sits inside the scope your team has already validated. The cards below cover the parallel decisions that determine who must follow the policies, where the data lives, which outside parties must be reconciled, and where the cardholder data environment boundary is drawn. The boundary itself comes from the scoping work under Requirement 12 and the PCI DSS scope reduction guides.

Owners of retention and disposal

Identify the people who set and enforce retention periods, approve deletion and answer for stored data that outlives its business purpose. In many organizations this sits across finance, operations and legal, so no single team holds the whole picture. Check that each named owner can point to the retention rule they enforce and the disposal record that proves it ran. Where ownership is implied rather than written down, 3.1.2 will be hard to evidence.

Owners of encryption and key management

Name the individuals or teams who operate encryption for stored PAN and who custody the keys that protect it. Their duties, including key generation, rotation approvals and access to key stores, must be written down and understood by those people. Confirm that the same individuals are not quietly performing both encryption administration and independent key oversight without a documented decision to allow it.

Systems and data stores holding account data

Build a current inventory of every database, file share, backup, log store, analytics platform, ticketing system and removable media location where account data may appear. The procedures written under 3.1.1 must reference these stores, because a policy that omits one of them describes a process nobody runs. Ask engineering to search for unexpected copies, including exports, spreadsheets and support attachments, before the inventory is treated as complete.

Third parties whose documents must match

List hosting providers, payment processors, backup vendors, managed service providers and any SaaS platform that stores or processes account data for you. Their responsibility matrices and attestations describe who holds which duty, and your policies must agree with them on retention, encryption and key handling. Request the current version of each document and reconcile every conflict in writing. Where a provider's document is silent on a duty, record that gap as an open item.

Cardholder data environment boundary

Document the boundary of the cardholder data environment (CDE) in a form that the policies can reference, including the connected systems and the people with access to them. The procedures under 3.1 only apply correctly if the boundary is accurate, so confirm it against current network and data-flow diagrams before drafting. If the boundary is still being reduced through tokenization or point-to-point encryption, state which version of the boundary the policies describe and when that will change.

How a QSA tests PCI DSS 3.1 policies and roles

This table compares how a Qualified Security Assessor examines sub-requirements 3.1.1 and 3.1.2, the evidence they ask for, and the gaps that most often appear. Read each row as a test the assessor will run, then check your own records against the evidence column before the assessment starts. The main takeaway is that a current, approved policy is not enough on its own; the documents must match the live environment and the people named in them must answer for their duties.

Sub-requirement	Test approach	Evidence requested	Common findings
3.1.1 Policies and procedures	Examine the Requirement 3 policy and operational procedures, then interview staff who run them to confirm they know and follow them	Written stored account data protection policy and procedures, version history, approval records with dates and approvers, and proof of distribution to affected staff	Documents past their review date, procedures that describe a retired system or an earlier data flow, and no record of who received the updated version
3.1.2 Roles and responsibilities	Examine the roles record for retention, encryption and key management duties, then interview the named owners to confirm they understand what they are accountable for	Roles and responsibilities record such as a RACI matrix, assignment records showing who holds each duty, and any deputies or backups named for each role	Roles that are listed but unassigned, owners who have left the organization, and staff who cannot describe their Requirement 3 tasks when asked
Interview consistency	Compare what the policy says with what interviewees describe, and note any conflicts between documents and practice	Interview notes gathered by the assessor, plus the operational records (retention runs, key rotation logs) that show the procedures in use	Two teams describing the same retention step differently, or a procedure that exists on paper but has no matching operational record
Review cycle	Confirm the policy and procedures are reviewed on a defined cycle and after significant change to the cardholder data environment	Review log, change tickets that triggered updates, and the most recent approved revision	No review after a platform migration, cloud move or change in payment flow, leaving the documents describing an earlier environment

How to build the PCI DSS 3.1 policy set step by step

This sequence turns scattered practices for stored account data into a documented, approved and communicated policy set with clear owners, which is the evidence an assessor examines for Requirement 3.1.

Inventory where stored account data lives
Start by listing every system, database, file share, backup, log store and report where cardholder data or sensitive authentication data may be kept. Involve engineering, finance, customer support and whoever runs backups, because stray copies often sit outside the systems IT documents. The output is a data location inventory that names each store, its owner and the data elements it holds. You know this step is done when the people who run each system have confirmed their entries.
Draft the Requirement 3 policy and procedures
Write the top-level stored account data protection policy, then the operational procedures it depends on: data retention and disposal, encryption and key handling, and how sensitive authentication data is kept out of storage. Map each procedure to the inventory so every store has a rule that governs it. The output is a draft policy and a set of procedures, each with a named scope and a reference to the systems they cover. Confirm the drafts match how the environment actually runs before moving on.
Assign owners and write the roles record
Name a accountable owner for each Requirement 3 activity, including retention decisions, encryption configuration, key custodianship and disposal verification. Record who is responsible, who approves and who must be consulted or informed, typically in a RACI matrix. Check that each named person accepts the role and understands what it covers. The output is a roles and responsibilities record that aligns with the policy, and you know it is complete when every activity in the procedures has exactly one accountable owner.
Approve and version the documents
Route the policy and procedures to the executive or committee that has authority over information security for formal approval, and record the approver and approval date on each document. Store the documents in a system that keeps version history, so changes are traceable to a date and author and earlier versions can be restored. The output is an approved policy set with a visible version history. Confirm that only the current approved version is linked from the places staff use.
Publish the documents and record acknowledgment
Distribute the approved policy set to every person affected by it, including engineering, operations, finance, support and third parties with access to stored data. Ask each recipient to acknowledge that they have read and understood the documents, and keep the record with names, dates and document versions. Assessors interview responsible personnel, so staff should be able to explain their part. The output is a staff acknowledgment log, and you know this step is done when gaps in acknowledgment have been followed up.
Set a review trigger tied to change
Define the events that require the policy set to be reviewed and updated, such as a new payment channel, a new storage location, a change in the encryption or key management approach, or a change in the people who own a role. Add a periodic review as a backstop and assign the reviewer. The output is a review procedure with a documented trigger list and a log of past reviews. Confirm that the inventory from the first step is updated as part of each review so the documents stay tied to the systems they describe.

How 3.1 differs from the technical sub-requirements that follow it

Requirement 3.1 is the governing layer for Requirements 3.2 through 3.7. It does not protect any stored account data by itself. Instead, it requires the organization to document the policies and operational procedures for Requirement 3 and to assign roles for retention, encryption and key management. Assessors test both layers because they fail independently. A policy can be complete and current while the retention job, masking rule or key rotation it describes is missing or disabled. A control can work well while no document explains what it does, who owns it or what happens when it breaks. In a review, you should expect an assessor to take one control from the policy and trace it into a live system, then take one system from the environment and ask which written procedure governs it.

The evidence for the two layers looks different, and teams often prepare for only one. Evidence for 3.1 is mostly prose and records: the stored account data protection policy, the operational procedures that staff follow, and a roles and responsibilities record such as a RACI matrix with named owners. Evidence for 3.2 through 3.7 is technical: retention and disposal job configurations, deletion logs, key inventories, key custodian records and encryption settings. A wiki with version history can hold the 3.1 documents, but it cannot prove that a purge job ran. Ask each control owner to name the record that shows the control operating, and confirm that record is retained where the assessor can sample it.

The policy has to describe the systems you actually run, and this is where most reviews stall. Before the assessment, confirm the storage locations for account data, including backups, logs, analytics stores and support exports, and check that the procedures name the real tools, teams and key custodians for each one. A policy that refers to a retired database or a departed role will fail in the first interview, even when the underlying controls are sound. Treat the 3.1 documents as a living record that changes whenever the environment changes, and schedule a review that compares each procedure with the current configuration before a Report on Compliance or Self-Assessment Questionnaire is prepared.

Evidence that passes PCI DSS 3.1 and how to keep it current

An assessor testing 3.1 looks for two things: written documents that are current and actually in use, and records that show people know their roles. The cards below cover the artifacts that carry that proof and the routines that keep them accurate between assessments. Confirm with your QSA which version history and approval records they accept before you rely on any tool.

Approved Requirement 3 policy

This is the top-level document stating how your organization protects stored account data, including retention limits, prohibition of stored sensitive authentication data, PAN masking and unreadability, and key management. It should name an owner, an approver, an effective date and a review date. Check that the policy text matches what your systems actually do, because assessors compare the document with live configuration during interviews. Keep the approved copy separate from drafts so the assessor can see which version was in force.

Operational procedures for each activity

Each Requirement 3 activity needs a procedure that tells staff how to do the work: how data is discarded at end of retention, how encryption keys are rotated, how masked displays are configured and checked. Write them as step lists tied to a named system or team, so they can be followed without the author present. Walk through each procedure with the people who run it, then record that the walkthrough happened. Stale procedures that describe retired tools are a common finding.

Roles and responsibilities record

A RACI matrix maps each Requirement 3 activity to who is responsible, accountable, consulted and informed, including backups for each role. It shows an assessor that retention, encryption and key management have owners rather than shared assumptions. Review it when people move teams, when a system changes hands, and at least at each assessment cycle. Confirm that every named role is held by a person who can actually perform the duty.

Staff acknowledgment records

Policies and procedures only count if the affected people know they exist and have read the parts that apply to them. Keep dated acknowledgments from each role holder, and record when a document changes and who needed to re-acknowledge it. Tie acknowledgments to onboarding so new staff sign before they receive access to systems that hold account data. Export the list of acknowledgments regularly so gaps are visible before an assessor finds them.

Version history and approvals

Assessors ask who changed a policy, what changed, when, and who approved it. Wiki platforms such as XWiki keep version control on every page, recording what changed, when and by whom, with the ability to compare two versions and roll back to an earlier one. Use the approval step of your own workflow for sign-off, and store the approver's name with each version. Confirm that this history, along with any approval records, meets the evidence standard your assessor applies.

Access that matches the RACI

Document access should follow the same roles as the RACI, so that only people with a Requirement 3 duty can edit the procedures that govern it. BookStack assigns abilities through roles, and those permissions can be overridden per role at the shelf, book, chapter or page level. Set up a restricted shelf for Requirement 3 documents and review the role assignments on the same schedule as the RACI. Test the setup by checking that a user outside the listed roles cannot edit the content.

What meeting PCI DSS 3.1 costs in money and effort

This table compares the main cost components of meeting requirement 3.1, showing who carries each cost, whether it is one-time or recurring, what pushes it up and how to keep it down. Read it as a checklist for building a quote, since no dollar figures or durations are supplied here, and most of the spend is internal effort plus any outside help you choose to buy.

Cost component	One-time or recurring	What drives it up	How to keep it down
Policy and procedure writing	One-time drafting, then recurring updates	Many systems, data stores and teams that each need their own procedures	Write one policy set that covers all in-scope environments and reference it from team-level procedures
Roles design and interviews	One-time design, recurring when people change	Many teams, shared responsibilities and third parties holding part of the data	Map owners to existing job roles and record them in a single RACI matrix
Tooling for document control	Recurring hosting and administration; license spend may be zero	Large document estate, complex approval chains and many reviewers	Use a self-hosted wiki with built-in version history and role-based permissions instead of separate document tools
Staff training and acknowledgment	Recurring, tied to annual cycles and joiners	Large headcount, frequent turnover and multiple sites or time zones	Add policy acknowledgment to existing onboarding and security awareness sessions
Recurring review of policies and roles	Recurring, typically on a fixed calendar and after changes	Frequent environment changes, new payment channels and new service providers	Trigger reviews from change management and third-party onboarding rather than relying only on calendar dates
Assessor time testing 3.1	Recurring at each assessment cycle	Poor document quality, missing version history and unclear owners that force extra questions	Prepare a ready evidence folder with current documents, change history and named owners before the assessor starts
Outside help (consultants or implementation partner)	Optional, usually fixed-scope and one-time, with possible retainers	Scope size, gaps in existing documents and the number of teams to interview	Request a written scope, deliverables and quote from each provider so you can compare like for like

Who writes, approves and tests PCI DSS 3.1 evidence

Requirement 3.1 asks for policies, operational procedures and role definitions for stored account data, and those belong to the organization that holds the data. Your team decides what the retention, encryption and key management rules say, approves them through the people accountable for the cardholder data environment, and names the individuals who own each procedure. No outside party can make those decisions for you, and an assessor will ask who approved the documents and when.

Policy content: Your security, payments and data owners write the rules that reflect how your business actually stores and deletes account data.
Approval: A named executive or governance body signs off each version and records the date.
Named owners: Each procedure and each role has a person, not only a team name, who is answerable for it.
Staff acknowledgment: Affected staff confirm they have read and understood the documents, and you keep those records.
Review cadence: Your team sets how often the documents are checked and updated, and who triggers an update after a system or process change.

Before any outside work begins, confirm internally who will sign the policy, who will answer assessor questions and who keeps the acknowledgment records.

Common gaps in PCI DSS 3.1 documentation

Assessors reviewing Requirement 3.1 usually find the same weaknesses: documents that look finished but cannot show approval, currency or ownership. Each gap below is easy to fix once it is named, and each fix produces the policy, procedure and roles record that the examination of documentation and staff interviews will request.

Policies without approval or dates

A stored account data policy with no version number, approval date or approver cannot show that management reviewed it. Assessors look for evidence that the document is current, so an undated draft in a shared folder carries little weight. Add a document control block with version, owner, approver, approval date and next review date, then record the approval in the change history of your documentation system.

Procedures describing retired systems

Procedures written before a migration often name databases, key stores or backup tools that no longer exist. Staff following them may perform steps that do not match the live cardholder data environment. Walk each procedure against the current architecture and data-flow diagram, then update the steps and the version history together so the document matches what staff actually do.

Roles listed only as job titles

A document that assigns retention decisions to the Head of Payments or the Security Manager leaves the work unowned when people change roles. Assessors check that roles are assigned and understood, which requires a named person or a named backup for each duty. Record the current holder for every role, with a deputy, and tie the record to your access review process so it stays accurate.

Staff who were never told

A policy that sits in a repository nobody opens does not meet the requirement that the procedures be known to all affected parties. Interviews often reveal engineers and support staff who have never seen the document. Keep a distribution list of affected roles, collect acknowledgments, and ask a sample of staff to explain their retention and key handling tasks during the review.

RACI that does not match practice

A RACI matrix that names the security lead as approver for key changes can conflict with the change tickets, where a platform engineer actually approved the last rotation. This gap is among the first an assessor notices because it contradicts the documentation. Compare the RACI against recent change records and key management logs, then correct whichever source is wrong.

No trigger for review

Policies reviewed only on a calendar date miss changes made between cycles, such as a new payment channel, a new cloud account or a new third party handling card data. Define explicit triggers, including scope changes, system migrations, incidents and staff changes in the roles, and require a documented review each time one occurs. Ask your assessor which triggers they expect to see in your records.

PCI DSS 3.1 questions buyers ask before hiring help

How much effort does requirement 3.1 take compared with the technical requirements?

Requirement 3.1 usually takes less hands-on engineering effort than the controls that encrypt, mask or delete data, but it takes more coordination. Its two sub-requirements ask for documented policies and procedures and for documented roles, so most of the work is writing, reviewing and getting people to follow them. The effort rises with the number of teams that touch stored account data, such as payments, support, finance, data engineering and hosting. Ask any partner to size the work by listing the documents to produce, the people to interview and the approvals to obtain, then put that list in the written scope.

Can our team write the stored account data policy in-house?

Yes, in most organizations the internal team can write it, provided the people who own the data flows and key management are involved. The policy must reflect how your environment actually stores, retains and protects account data, so generic templates need local detail before they are useful. A partner can help by drafting procedures, mapping them to the Requirement 3 sub-requirements and checking gaps, while your staff keep ownership of the content. Whichever route you choose, confirm the final wording with your assessor early, because they will test the documents against your real operations.

What does requirement 3.1 need from management?

It needs a formal approval and named owners. Senior management should review and approve the stored account data protection policy and the procedures under it, and each procedure should name the role responsible for carrying it out. Management also needs to fund the review cycle, since the documents must stay current and reflect changes to systems and data flows. Expect to ask leaders to confirm who owns retention, encryption and key management decisions, because those roles appear in the responsibility record that assessors examine.

How long does it take to get requirement 3.1 in place?

The duration depends on the size and complexity of your cardholder data environment, the number of teams involved and how many documents already exist. No standard timeline applies to every organization, so the figure should come from a written plan agreed before work starts. Ask for milestones covering drafting, review, approval, staff briefings and a dated evidence pack. A partner should also state what it depends on from your side, such as access to interviewees and timely sign-off.

Can an implementation partner issue the evidence that proves 3.1 is met?

No. An implementation partner can prepare the policy, procedures and roles record and help staff understand them, but only an independent assessor can validate that the requirement is met. For a Report on Compliance, a Qualified Security Assessor examines the documents and interviews personnel. For a Self-Assessment Questionnaire, your organization completes the questionnaire and signs the Attestation of Compliance. Confirm with your acquirer or the relevant payment brand which route applies to you before you start.

How does the 3.1 policy relate to the ROC or SAQ and the Attestation of Compliance?

The policy and roles record are evidence that your assessment reviews under requirement 3.1. In a Report on Compliance, a Qualified Security Assessor documents what they examined and what they found, then the assessment supports an Attestation of Compliance. In a Self-Assessment Questionnaire, your organization answers the 3.1 questions and the answers must be supported by the same documents. Either way, the attestation reflects the assessment result, so an out-of-date or unapproved policy can make an answer inaccurate. Certificates are not accepted as validation, so keep the signed documents and the attestation together.

What happens if our policy and actual practice do not match?

A gap between documented procedure and real behavior is one of the most common findings for this requirement. An assessor interviews the people responsible and compares what they say with the written procedures, so inconsistencies are visible. Before the assessment, run a short walkthrough of each procedure with the staff who perform it, then either update the document or change the practice. Record the review date and approver so the evidence shows the policy is current and in use.

How DeployOpen prepares PCI DSS 3.1 evidence

DeployOpen helps organizations build the policies, procedures and roles record that Requirement 3.1 asks them to keep current and in use. We prepare the documentation and the systems that hold it, while the organization owns its controls and an independent QSA or assessor tests them.

How we scope

We agree in writing which Requirement 3 processes, systems and document repositories the engagement covers.
We confirm which teams handle retention, encryption and key management, so the roles record reflects actual responsibilities.
Engagements are fixed-scope, with deliverables and timelines agreed before work starts; ongoing support is available as a retainer.

How we build

We set up a version-controlled documentation space where the stored account data policy and operational procedures are maintained.
We configure role-based permissions so owners can edit procedures while affected staff can read and acknowledge them.
We draft a roles and responsibilities matrix for Requirement 3 activities, which your organization reviews and approves.

How we hand over

We deliver the policy set, procedures and roles record in a form your assessor can examine, with change history visible.
We document how each procedure is communicated and how staff acknowledgment is recorded for assessor interviews.
We confirm with your QSA which artifacts they expect, since the assessor, not DeployOpen, decides what satisfies the requirement.

How we support

We schedule periodic reviews of the policy and roles record so documentation stays current after the assessment.
We update procedures when retention, encryption or key management practices change in your environment.
We can support ongoing documentation maintenance under a retainer, with the scope and duration agreed in writing.