What is PCI-DSS? — Explained Like You’re 5
Why every Fintech PM must care about payment security standards. (Even if nobody told you this in your interview prep.)
Diksha Sengar8 min read·Just now--
You’re building a payment feature.
Users will enter their card details. You’ll charge them. Money moves. Feature ships. Everyone’s happy.
Your engineer says: “We need to make sure we’re PCI-DSS compliant.”
You say: “Absolutely. 100%. Let’s make sure of that.”
And then you Google it on the side. This one’s for you. 😅 No shame. I’ve been there too. Let’s fix that today — with a hotel analogy.
🏨 First, Why Does PCI-DSS Even Exist?
Imagine you’re a five-star hotel.
Guests hand you their credit cards every day. For room bookings. For the restaurant. For the spa. Now imagine one of your hotel staff writes down card numbers on a napkin. Or a hacker breaks into your billing system. Or someone photographs cards at the front desk. Thousands of guests. Their card data. Stolen.
That’s the nightmare PCI-DSS was created to prevent.
In the early 2000s, card fraud was exploding. Visa, Mastercard, Amex, Discover, and JCB — the five big card networks — looked at each other and said: “We need one set of rules. For everyone. Everywhere.”
In 2004, they formed the PCI SSC (Payment Card Industry Security Standards Council) and published PCI-DSS — the Payment Card Industry Data Security Standard.
PCI-DSS = The rulebook for anyone who touches card data.
And “touches” means: stores, processes, or transmits cardholder information. That includes you. If you’re building a product where users pay by card — this is your problem.
🃏 What Exactly is “Cardholder Data”?
Before we go further — let’s be precise about what PCI-DSS is actually protecting.
When a user enters their card details, here’s what exists:
The PAN — the 16-digit card number — is the crown jewel. Everything PCI-DSS does is fundamentally about protecting that number.
If you store, process, or transmit even one of these — PCI-DSS applies to you.
📋 The 12 Requirements — But Make It Human
PCI-DSS v4.0 (the latest version) has 12 core requirements.
Don’t panic. You don’t need to memorize them. But you absolutely need to understand what they’re doing as a group.
Think of it as six layers of protection around card data:
🔒 Layer 1: Build and Maintain a Secure Network
Requirements 1 & 2.
Install firewalls. Don’t use default passwords (yes, people still deploy systems with admin/admin). Control who can even reach the systems where card data lives.
PM Translation: “Does our network have walls? Are the doors locked with real keys — not the default ones that came in the box?”
🛡️ Layer 2: Protect Cardholder Data
Requirements 3 & 4.
If you store card data — encrypt it. If you transmit it (from user’s browser to your server, for example) — encrypt it in transit using TLS.
And the golden rule: Never. Store. CVV. Ever. Not in your database. Not in logs. Not in a temp file. Nowhere. It’s a hard violation.
PM Translation: “Is card data locked in a vault, and is the path to that vault encrypted?”
🔍 Layer 3: Maintain a Vulnerability Management Program
Requirements 5 & 6.
Use antivirus. Keep software updated. Regularly scan for vulnerabilities. Have a process for when security patches are released.
PM Translation: “Are we patching things? Is someone watching for holes in the walls?”
👁️ Layer 4: Implement Strong Access Control
Requirements 7, 8 & 9.
Only people who need card data should have access to it. Every person should have a unique ID (no shared logins). Physical access to servers should be restricted too.
PM Translation: “Who can see the card data? Can we prove it’s only the people who absolutely need to?”
📡 Layer 5: Regularly Monitor and Test Networks
Requirements 10 & 11.
Log everything. Track who accessed what and when. Regularly test your own security (penetration testing).
PM Translation: “Are we keeping a diary of who did what? And are we trying to break our own system before someone else does?”
📜 Layer 6: Maintain an Information Security Policy
Requirement 12.
Have a written security policy. Train your employees. Know your risks.
PM Translation: “Is security written down, communicated, and taken seriously — not just a PDF nobody reads?”
🎯 The Levels Nobody Tells You About
Here’s where it gets very relevant for PMs specifically.
PCI-DSS has four compliance levels — based on how many card transactions you process per year.
Why does this matter for you as a PM?
Because the compliance requirements — and the cost and effort — scale with your level.
A startup doing 5,000 card transactions a month? Level 4. Relatively manageable.
A fintech platform processing millions of transactions? Level 1. You’re getting audited by an external expert who will check everything.
When you’re planning a new payment feature, you need to ask: “Does this change our transaction volume enough to bump us to the next level?”
That changes engineering timelines, security budgets, and launch plans.
🤔 “But We Use Razorpay / Stripe. We’re Fine, Right?”
This is the most common PM misconception about PCI-DSS.
“We don’t handle card data ourselves. Our payment gateway does. So it’s their problem.”
Partially true. Mostly dangerous.
Here’s the nuance:
If you use a fully hosted payment page — like a Stripe Checkout or Razorpay Payment Page where the user leaves your app and enters card details on their page — your PCI scope is massively reduced. You’re barely in scope.
But the moment you customize the payment flow — embed the card form in your own app, collect card details on your own page, pass card data through your own servers even for a millisecond — you’re in scope.
And “in scope” means: you are responsible for meeting PCI-DSS requirements for every system that card data touched.
PM Translation: “How card data flows through your product determines how much of PCI-DSS is your problem.”
This is why your engineering team will sometimes push back on seemingly simple UI requests — like “can we collect the card number in our own checkout form?” The answer isn’t just a CSS change. It might be a compliance scope change.
💸 What Happens If You’re Non-Compliant?
Let’s be real about the stakes.
Fines from card networks: Visa and Mastercard can fine acquiring banks (and pass the cost to you) anywhere from $5,000 to $100,000 per month for non-compliance.
Breach liability: If card data is stolen from your systems and you weren’t compliant — you can be held liable for the cost of reissuing every card affected. That’s ₹200–₹500 per card. Multiply by thousands of users.
Loss of ability to accept cards: In serious cases, card networks can revoke your ability to process card payments entirely. For a fintech, that’s existential.
Reputational damage: A data breach headline featuring your product’s name is not recoverable for early-stage startups.
The fines are painful. The reputational damage is fatal.
😰 Why PCI-DSS is a PM’s Problem (Not Just Engineering’s)
Let me be direct here.
Most PMs treat PCI-DSS as “the security team’s thing.” They learn about it when something breaks.
That’s the wrong approach. Here’s why PCI-DSS should live in your brain:
Every payment feature you spec affects compliance scope.
Want to build a saved cards feature? You just entered the business of storing PANs. Now you need tokenization. Now you have a much larger PCI footprint.
Want to show the last 4 digits of a card? Fine — that’s allowed. The full number? Absolutely not in plaintext.
Compliance timelines will delay your launches.
If a new feature expands your PCI scope — engineering needs to build new security controls before it can go live. That’s not just a “nice to have.” That’s a hard requirement.
When you’re writing a PRD for a payment feature — add a line: “Does this change our PCI scope? What’s the compliance delta?”
Third-party integrations are your risk too.
You’re integrating with a new lending partner. They’ll receive card data from your users.
Are they PCI compliant? Do you have a contract that specifies it? If they get breached — your users’ data is involved.
Due diligence on third-party compliance is a PM responsibility, not just a legal one.
Your logging decisions have compliance implications.
Engineers sometimes log request/response payloads for debugging. If those logs accidentally capture a card number — you just violated PCI-DSS.
As a PM, when you’re reviewing engineering designs for payment features, ask: “What are we logging, and does any of it touch card data?”
🧠 What a Fintech PM Needs to Know About PCI-DSS
You don’t need to pass the PCI audit yourself. But you need to know:
→ What your PCI scope is — which systems and flows are in scope, and which aren’t
→ Your compliance level — and when growing transaction volume might push you to the next level
→ The “never store CVV” rule — it’s absolute. No exceptions. No “just temporarily.”
→ How your payment gateway integration affects scope — hosted pages vs embedded forms is a massive difference
→ What tokenization is — storing a token (like tok_abc123) instead of the real card number. It's how you enable saved cards without storing actual PANs
→ What your third-party vendors’ compliance status is — and whether your contracts require it
→ What your logging policy is for payment flows — no card data in logs. Ever.
🎯 Quick Quiz Before You Go
Test yourself 👇
Scenario A: Your product team wants to build a “quick recharge” feature where users save their card for one-tap payments. What compliance questions do you ask before writing the PRD?
Scenario B: A new engineer joins the team and accidentally logs full API request payloads — which includes card numbers — to your debugging tool for 3 days. What’s the risk, and what do you do?
Scenario C: Your startup is processing 50,000 card transactions per month and growing. What PCI level are you at, and when should you start preparing for the next level?
Drop your answers in the comments. 👇
Answers:
A — Will we store the card data ourselves or use a tokenization service? If we store, what’s our encryption approach? Does this change our PCI level? Who is our QSA or compliance advisor for this feature?
B — This is a potential PCI breach. You need to immediately rotate/purge those logs, assess how many card numbers were exposed, check if the logging tool had external access, notify your compliance team, and depending on the scale — potentially notify affected users and card networks.
C — 50,000/month = 600,000/year. That’s Level 3 (20K–1M/year). At current growth, if you cross 1M/year you move to Level 2, which requires a more rigorous SAQ and quarterly scans. Start the Level 2 prep before you hit the threshold — not after.
Liked this breakdown? I write about fintech and product concepts that every PM should know — no jargon, no fluff.
This is part of my ongoing series — “Product, Plain English”. Check out my other posts on KYC, UPI Under the Hood, A/B Testing, and Webhooks vs APIs.
If you’re building something interesting — let’s talk. 🚀
Go visit my Portfolio: https://diksha-sengar-portfolio.vercel.app/
