PCI Policy Template: Security Policy by SAQ Type

A starting point to adapt to your business, not legal advice. Your SAQ form has the final list of questions.

Information security policy

Northside Plumbing & Heating

Policy ownerMaria Lopez, owner

Adopted____________

Next review____________

Payment setupSAQ C-VT, PCI DSS v4.0.1

01Purpose, scope and review

Req. 12.1.1, 12.1.2

This policy sets out how the business protects payment card data. It applies to every owner, employee, contractor and vendor who takes card payments, handles card data, or runs a system that could affect its security.
The policy owner publishes this policy where every staff member can read it, and gives a copy to each vendor and outside firm it concerns.
The policy owner reviews this policy at least once every 12 months, and sooner when the business, its way of taking cards or its risks change.

02Roles and responsibilities

Req. 12.1.3

The policy owner is responsible for information security and for the business's PCI DSS compliance, including the Self-Assessment Questionnaire and Attestation of Compliance our acquirer asks for.
Every person who takes card payments follows this policy and reports anything suspicious to the policy owner straight away.
Each person confirms in writing that they have read this policy and understand their own security duties.

03Security awareness training

Req. 12.6.2, 12.6.3, 12.6.3.1

Staff complete security awareness training when they join and at least once every 12 months.
Training covers phishing and other social engineering: how to spot a fake email, call or visit, and who to tell.
The policy owner reviews the training at least once every 12 months and updates it for new threats.

What the training has to cover

04Card data we keep, and what we never keep

Req. 3.3.1

We never keep the card security code, full magnetic-stripe or chip data, or a PIN after a payment is authorized, even encrypted. That includes a code written on a phone-order note.

What a merchant may keep

05Paper with card data

Req. 9.4.1, 9.4.2, 9.4.3, 9.4.4, 9.4.6

Paper that shows card data (receipts, order forms, authorization forms) is kept in a locked drawer or cabinet.
That paper is marked confidential so everyone knows how to handle it.
It leaves the premises only with the policy owner's approval, by a courier that can track it, and each move is logged.
When it is no longer needed, it is cross-cut shredded, incinerated or pulped, and kept in a locked container until then.

Paper authorization forms

06Logins and passwords

Req. 2.2.2, 7.2.1, 8.2.1, 8.3.6, 8.3.9

Everyone who uses a system that handles card data has their own login. Logins are never shared.
Each person gets only the access their job needs, and no more.
Passwords are at least 12 characters (eight where a system cannot take 12) and contain both letters and numbers.
Where a password is the only factor, it is changed at least once every 90 days.
Vendor default passwords on terminals, routers, payment software and the website's admin are changed before use; default accounts we do not use are removed or disabled.

PCI password and MFA rules

07Systems, updates and logs

Req. 1.3.1, 5.2.1, 6.3.3

Security patches for critical flaws are installed within one month of release; other patches on a timetable set by their risk.
Anti-malware runs on every computer used for card payments.
The firewall or router lets in only the traffic our card setup needs and denies everything else.

08Scans and tests

Req. 11.3.2

The policy owner checks whether our SAQ form includes Requirement 11.3.2 (external scans by an ASV). If it does, an ASV scans at least once every three months and we keep each passing report. If unsure, we ask our acquirer.

How ASV scans work

09Service providers

Req. 12.8.1, 12.8.2, 12.8.3, 12.8.4, 12.8.5

We keep a list of every service provider that handles our card data or could affect its security, with what each one does for us (below).
Each of them has a written agreement acknowledging it is responsible for the security of the card data it handles for us.
Before we take on a new provider, the policy owner checks it can protect card data and asks for its PCI DSS compliance evidence.
At least once every 12 months, the policy owner checks each provider's PCI DSS compliance status. A compliant provider does not make us compliant.
We record which PCI DSS requirements each provider manages, which we manage, and which we share.

Our service providers

10If card data may have been exposed

Req. 12.10.1

Anyone who suspects card data has been exposed, or a terminal or the payment page tampered with, tells the policy owner at once.
The policy owner leads the response: contain the problem (for example, take a suspect terminal out of use), keep the evidence, and notify our acquirer and the card brands as they require.
The plan also covers how we keep trading, how we restore from backups, and which legal reporting duties apply to us.

Who we call

Build the full incident response plan

11Staff acknowledgement

Req. 12.1.3, 12.6.3

I have read and understood this policy and my own security duties under it. I will sign again at least once every 12 months.

Name	Role	Signature	Date

What a PCI policy template is for

Requirement 12 of PCI DSS v4.0.1, the version in force, reads “Support information security with organizational policies and programs.” Its first line, 12.1.1, asks for an information security policy that is “Established. Published. Maintained. Disseminated to all relevant personnel,” and shared with the vendors it concerns too. For a small merchant that means a short document the staff have actually read: who is in charge, what card data you never keep, how you lock away paper, who your providers are, and who you call if something goes wrong.

This template writes that document from your Self-Assessment Questionnaire (SAQ) type, because the SAQ decides which requirements you answer. Each section cites the requirement numbers it covers, so the policy doubles as your evidence when the SAQ asks about them. The wording is ours, written from the requirement text the PCI Security Standards Council publishes in its Prioritized Approach Tool; it is not copied from an SAQ form or a vendor's template. Treat it as a starting point to adapt, not legal advice.

How to use it

Pick your SAQ type. If you do not know it, the SAQ type finder works it out from your terminals, checkout and phone orders. Arriving with ?saq= in the address sets it for you.

Fill in the header. Business name, the person who owns the policy, the day you adopt it and the day you will review it.

Edit every line that is not true for you. Choose Edit lines under a section, change the wording, remove what does not apply and add your own rules. List your real providers and emergency contacts.

Print it, sign it, share it. Print or save a PDF for the binder, or copy the text into Word or Google Docs. Have each person who takes card payments sign the acknowledgement.

Work through the jobs it promises. The PCI compliance checklist turns the same requirements into tick-box tasks for your SAQ.

Worked example: a plumbing firm that takes cards by phone

A plumbing and heating firm with a small office team takes payment over the phone after each job. The office manager types the card details, one payment at a time, into the processor's virtual terminal on one office laptop that has no card reader attached and is used for nothing else. Nothing is stored. That is SAQ C-VT.

Picking SAQ C-VT gives 11 of the template's 14 sections, citing 27 requirement numbers. The owner becomes the policy owner. The sections that matter most here: the card security code is never written on a job sheet, everyone has their own login to the virtual terminal, the laptop gets patches and anti-malware, and the processor appears in the provider list. There is no terminal section, because the firm has no card terminal.

What each SAQ type puts in this template
SAQ type	Sections	Requirements cited	Full policy (12.1.1)
SAQ A	7	18	Not listed
SAQ A-EP	13	36	Listed
SAQ B	5	15	Not listed
SAQ B-IP	8	18	Not listed
SAQ C-VT	11	27	Listed
SAQ C	12	39	Listed
SAQ P2PE	4	14	Not listed
SAQ SPoC	3	11	Not listed
SAQ D	14	49	Listed

What the result means

Policy sections is how many sections your document holds; Requirement numbers cited is how many distinct PCI DSS requirements those sections answer. Both change with your SAQ type, because each SAQ covers a different slice of the standard. The Council counts 14 requirements for an SAQ A merchant with no access to its own webpage, 27 for one that redirects to or embeds the processor's page, and 139 for SAQ A-EP; SAQ D covers them all.

On SAQ A, SAQ B, SAQ B-IP, SAQ P2PE, SAQ SPoC, our reading of each SAQ's scope does not include 12.1.1, so the template gives you the written rules those SAQs do ask about: how you handle paper, who your providers are, and what you do in an incident. Tick “Also add the sections my SAQ type does not list” for a complete policy anyway. Your SAQ form is the final word, and the organization you submit it to (usually your acquirer) can confirm which SAQ you are eligible for.

Where the rule says so

The policy-related requirements of PCI DSS v4.0.1, in the Council's words where quoted. The other sections of the template cite their own numbers (3.3.1 for the security code, 9.4.6 for shredding, 8.3.6 for passwords); the guide to the PCI DSS 4.0 requirements walks through all 12.

Req. 12.1.1An information security policy is “Established. Published. Maintained. Disseminated to all relevant personnel,” and to the vendors it concerns.
Req. 12.1.2The policy is reviewed at least once every 12 months and updated when business objectives or risks change.
Req. 12.1.3The policy defines security roles and responsibilities, and every person acknowledges theirs.
Req. 12.6A formal security awareness program; staff are trained “Upon hire and at least once every 12 months,” acknowledge the security policy at least once every 12 months, and training covers phishing and social engineering (12.6.3.1).
Req. 12.8.1“A list of all third-party service providers (TPSPs) with which account data is shared or that could affect the security of account data is maintained, including a description for each of the services provided.”
Req. 12.8.4“A program is implemented to monitor TPSPs’ PCI DSS compliance status at least once every 12 months.”
Req. 12.8.5“Information is maintained about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between the TPSP and the entity.”
Req. 12.10.1An incident response plan “exists and is ready to be activated,” covering roles and contacts (including notifying the payment brands and acquirers), containment, business recovery, data backups, legal reporting duties, critical systems and the payment brands’ own procedures.

PCI SSC Prioritized Approach Tool for PCI DSS v4.0.1, read on 2026-10-22

If you suspect a breach, the policy points to a fuller plan: the PCI incident response plan template builds the 12.10.1 document step by step, and PCI security awareness training covers what the yearly training under 12.6 has to include.

PCI policy template for small merchants

Build your policy

Your policy