PCI DSS Service Provider: A Guide for Modern Tech Stacks

You launch a mobile app on Firebase. Checkout is outsourced to Stripe. Card numbers never touch your code, so you assume PCI DSS is mostly your processor's problem.

That assumption breaks fast in real assessments.

For modern stacks, the hard part isn't usually storage of card data. It's security influence. If your Supabase instance, Firebase Functions, hosting layer, CI/CD pipeline, support tooling, or cloud identity setup can affect the security of the cardholder data environment, you may have service provider obligations even if you never persist a PAN. That's where a lot of startup teams get caught. They've built something operationally clean, but architecturally in scope.

In the UK, that matters more than many founders expect. Regulatory attention on PCI DSS service providers has intensified, and the definition widened under PCI DSS 4.0 to include entities that can impact cardholder data security, including cloud hosting providers without direct access. That shift followed fraud data showing service providers were involved in 28% of reported payment card fraud incidents in the UK, according to SecurityMetrics' summary of UK service provider requirements.

Are You a PCI DSS Service Provider?

A common startup pattern looks like this. The app runs on Supabase or Firebase. Payments flow through a hosted gateway. Product, engineering, and compliance all say some version of, “We're not storing cards, so we're probably out of scope.”

Sometimes that's true for part of the stack. It's often false for the business overall.

The question that changes everything

The useful question isn't “Do we store card data?”

It's “Can our systems or services affect the security of cardholder data?”

If the answer is yes, you need to look at service provider scoping seriously. That includes cases where your backend controls authentication, session handling, access policy enforcement, logging, or privileged administration around payment-adjacent systems.

Practical rule: If an attacker could abuse your platform to weaken controls around payment data, your platform is not safely “out of scope” just because PANs live somewhere else.

A few examples make this clearer:

• Supabase with weak RLS controls can expose records or permit lateral movement that affects a payment workflow.
• Firebase Functions with excessive privileges can become a bridge into more sensitive systems.
• A mobile app build pipeline that leaks secrets can expose keys used to administer payment-adjacent infrastructure.
• A cloud admin console with poor MFA hygiene can become the main attack path, even when the card form itself is hosted elsewhere.

Why startups misclassify themselves

Traditional PCI guidance was written with more obvious environments in mind. Web server, database, segmented network, defined perimeter. Modern BaaS and serverless deployments blur those boundaries.

That's why founders and CTOs often miss where the pci dss service provider label applies. They think in terms of direct data handling. Assessors think in terms of control impact, access paths, and shared responsibility.

A startup can also be both a merchant and a service provider. If you accept payments for your own product and also operate technology that supports, transmits, secures, or influences cardholder data for customers or internal payment flows, you may sit in both roles at once.

The practical takeaway is simple. Don't scope from invoices, vendor logos, or assumptions about hosted checkout. Scope from real control paths.

Service Provider or Merchant What's the Difference?

The cleanest way to explain this is with a physical analogy.

A merchant is the shop taking payment from the customer. A service provider is the armoured transport company, the alarm installer, the managed vault operator, or the building access contractor. The merchant is selling. The service provider is enabling, processing, or securing the payment environment.

In software, those lines blur because platforms often do both.

The core distinction

A merchant accepts payment cards for its own goods or services. A service provider provides a service that stores, processes, transmits, or affects the security of cardholder data on behalf of another entity.

That means your company can be:

• Only a merchant, if you just sell your own product and don't provide in-scope services to others.
• Only a service provider, if you support payment security functions for customers but don't accept card payments for your own sales.
• Both, which is common in SaaS, fintech, embedded payments, and platform businesses.

PCI DSS Roles Merchant vs. Service Provider

| Aspect | Merchant | Service Provider | |---|---|---| | Primary role | Accepts card payments for its own products or services | Provides services that handle or affect payment data security for another entity | | Typical example | An e-commerce app selling subscriptions | A cloud host, managed platform, backend operator, scanner provider, or payment support vendor | | Main scope question | How does the business accept payments? | How does the service influence storage, processing, transmission, or security of card data? | | Relationship to customers | End seller | Vendor, platform, processor, infrastructure or security provider | | Validation approach | Depends on merchant channel and acquiring requirements | Depends on service provider status, transaction volume, and customer requirements | | Typical evidence customers ask for | Merchant compliance documents relevant to their acquiring setup | AOC, responsibility matrix, testing evidence, and details of shared controls | | Common mistake | Assuming outsourced checkout removes all responsibility | Assuming no direct PAN access means no PCI obligations |

What this means in practice

If you run a platform on Firebase and sell subscriptions, you're a merchant. If that same platform also provides hosted account logic, admin tooling, logging, or backend services that support a payment environment for another entity, you may also be a service provider.

That's why I tell CTOs not to ask, “Which bucket are we in?” Ask, “Which functions are we performing?”

A lot of painful PCI projects start with the wrong noun. Teams label themselves a merchant, then discover they operate like a service provider in key parts of the stack.

Documents people confuse

Teams also mix up the paperwork:

• ROC is the detailed assessment report used for more formal validation.
• SAQ-D for Service Providers is the self-assessment path some smaller service providers use.
• AOC is the attestation customers and partners often ask to see.

Those aren't interchangeable. If you're acting as a service provider, sending a merchant document to a customer usually creates more questions, not fewer.

How Modern Cloud Stacks Change PCI Scope

Cloud-native stacks break old PCI instincts.

In an on-prem environment, scope often followed network boundaries. In Supabase, Firebase, Vercel, Cloud Run, edge functions, GitHub Actions, mobile build systems, and managed identity providers, scope follows trust relationships and security impact.

Supabase is not “out of scope” by default

I see this one a lot. A team uses Stripe-hosted checkout and keeps card fields off their app. Then they assume Supabase is just product infrastructure and irrelevant to PCI.

That can be wrong for several reasons:

• Supabase may hold customer identities tied to payment state.
• RLS policies may govern access to records that influence who can trigger billing actions, refunds, exports, or support operations.
• RPC functions may expose administrative actions if auth checks are weak.
• Edge functions may bridge into payment-adjacent services using privileged credentials.

If a misconfiguration in that stack could undermine the security of the cardholder data environment, auditors may treat it as in scope or connected-to.

Firebase creates the same problem in a different shape

Firebase often looks safer because everything feels managed. But managed doesn't mean irrelevant.

Cloud Functions, Firestore rules, service accounts, app configuration, remote config, and mobile API key handling can all affect how securely the broader payment ecosystem operates. A function that validates a purchase, provisions access after payment, or writes payment-linked records can become a pivot point. An over-permissive rule can turn a “data app” into a compliance problem.

The UK-specific guidance gap is real here. The FCA's 2025 PCI Compliance Review found 25% of UK assessments fail due to incomplete service provider inventories, including unlisted Supabase or Firebase instances where misconfigurations such as RLS leakage could affect the security of the cardholder data environment, as noted by Auditwerx on PCI DSS service provider scoping.

What actually pulls these systems into scope

Three patterns matter more than almost anything else:

Security-impacting access

If the system controls authentication, authorisation, secrets, or administrative access related to the payment environment, it's relevant.

Connected-to architecture

If compromise of one service creates a realistic path into more sensitive systems, don't pretend the line is clean.

Shared control reality

If your cloud vendor secures the platform, but your team configures access rules, functions, schemas, and deployment permissions, both sides matter. “Managed” only narrows some responsibilities. It doesn't erase yours.

For a practical cloud view, this guide on securing sensitive data in cloud environments is useful because it mirrors the way modern teams deploy and expose services.

The test I use is simple. If a breach in this component would force you to explain to an assessor how payment security was still preserved, it belongs in the scoping conversation.

Scope is now architectural, not just network-based

That's the shift founders need to internalise. In older environments, teams asked where the card database lived. In modern environments, the better question is who can alter access decisions, invoke privileged functions, leak credentials, or weaken monitoring around systems that matter to payment security.

If you only map data flow, you'll miss scope. If you map control flow, you'll usually find it.

Navigating Your PCI DSS Assessment

Once you realise you may be operating as a pci dss service provider, the next problem is procedural. What assessment path applies, and what evidence do you need?

The answer depends on how you're classified and how your customers or acquirer expect you to validate. The mistake is treating all PCI paperwork as equivalent. It isn't.

ROC, SAQ-D and AOC are different things

A ROC is the detailed Report on Compliance. It's the heavyweight document. In practice, this is what formal validation looks like for larger or more heavily scrutinised service providers.

A SAQ-D for Service Providers is a self-assessment route used by smaller service providers in some situations. It's still substantial. It does not mean “lightweight PCI”.

An AOC is the Attestation of Compliance. Think of it as the summary document customers, partners, and auditors often ask for first. It states the validation outcome, but it is not a substitute for having the controls or the supporting evidence.

Testing is where modern teams struggle

In BaaS and serverless setups, testing evidence often lags behind architecture reality. Teams can describe their controls, but they can't show enough proof that those controls resist abuse.

For UK service providers, Req. 11 requires quarterly penetration tests for Level 1 providers processing over 300,000 transactions a year, validated via a ROC. For tools that scan RLS leakage, evidence should include fuzzing for read and write exploits. The same guidance notes that weak MFA in vendor remote access caused the 2024 UK CloudBreach affecting 150K cards, summarised in the PCI SSC connected-to service providers guidance.

What assessors usually want to see

A practical assessment pack usually includes:

• Documented scope showing which systems, vendors, and services are in or connected to the CDE
• Control ownership so it's clear what your team manages versus what a provider manages
• Testing records including scans, pentest results, remediation evidence, and retest outcomes
• Access control evidence for admin paths, MFA, privileged access, and service accounts
• Logging and monitoring evidence that shows you can detect misuse, not just configure a dashboard
• Current attestation material that matches the actual services being reviewed

If your environment changes frequently, continuous evidence matters more than annual screenshots. That's one reason teams building on serverless platforms benefit from tighter scanning discipline. A practical reference point is this overview of PCI DSS scanning for modern app environments.

Don't treat the assessment as a document exercise. It's an evidence exercise. If your controls are real, you should be able to show them operating.

The useful mindset

The best preparation is to think like an assessor. They won't start with your architecture diagram. They'll start with trust boundaries, admin access, vendors, and proof of control operation. Your job is to make those answers boring.

Your Practical Service Provider Compliance Checklist

This is the working checklist I'd give a startup CTO running a modern stack. It's designed to reduce avoidable scoping mistakes and make an eventual assessment less painful.

Start with inventory, not policy

You can't secure what you haven't listed properly.

• Map every service that can influence payment security. Include Supabase projects, Firebase projects, cloud functions, CI/CD systems, mobile build services, secrets managers, logging platforms, support tooling, and identity providers.
• Record why each item is in scope, connected-to, or out of scope. If you can't justify exclusion in plain English, expect trouble later.
• Tie each item to an owner. Unowned infrastructure becomes unmaintained infrastructure.

If you work in high-risk online payment environments, this primer on PCI compliance for high-risk e-commerce is worth reading because it frames scope and control pressure in commercially realistic terms.

Reduce blast radius aggressively

The easiest PCI environment to defend is the one with fewer paths into it.

Segment by function

Keep payment-adjacent admin operations separated from general product workloads where possible. Separate projects, roles, secrets, and operational accounts. Don't let convenience collapse your boundaries.

Shrink privileges

Review service accounts, deployment tokens, support access, and break-glass roles. If a mobile developer can alter production functions that influence payment logic, your access model is too loose.

Harden remote access

MFA failures are still a common way environments unravel. Pay close attention to vendor and contractor access, not just employee SSO.

Fix the mistakes that actually create findings

Most real findings aren't exotic. They're configuration failures that stayed invisible because no one tested them properly.

Here are examples I'd prioritise in Supabase and similar stacks:

• Public or weakly protected RPCs that perform sensitive reads or writes
• Over-broad RLS policies that trust client-supplied values
• Hardcoded secrets in mobile bundles, frontend config, or CI variables
• Excessive service-role use in application paths
• Missing audit coverage for admin actions and sensitive function calls

Example RLS remediation pattern

A weak policy often looks “logical” at first glance.

Before

create policy "users can read their company invoices"
on invoices
for select
using (
  company_id = current_setting('request.jwt.claims', true)::json->>'company_id'
);

The problem is trust. If your claim handling or token issuance is flawed, that policy may expose more than intended.

After

create policy "users can read only invoices they are assigned to"
on invoices
for select
using (
  exists (
    select 1
    from user_invoice_access uia
    where uia.invoice_id = invoices.id
      and uia.user_id = auth.uid()
  )
);

This pattern is usually stronger because it binds access to a server-controlled relationship instead of a looser tenant claim. The exact design varies, but the principle holds. Don't make security decisions from client-controlled context when a server-side authorisation table can do the job.

Field note: The fastest way to cut noise from a PCI remediation project is to fix access logic first. Weak authorisation creates downstream mess in logging, monitoring, incident response, and vendor conversations.

Build evidence as you fix

Every remediation should leave an audit trail:

1. Capture the finding
2. Record the affected component
3. Apply the change
4. Retest the exact abuse path
5. Store the result where your assessor can consume it

That turns security work into compliance evidence without running two separate programmes.

Choosing Vendors and Preparing for Your Audit

Your PCI position is only partly about your own controls. The rest sits with vendors you rely on, and the proof that you've checked them properly.

That matters a lot in cloud-first stacks because your architecture is a chain of providers. Cloud host, identity platform, logging vendor, payment processor, CI/CD service, support tooling, analytics scripts, mobile distribution workflow. If those relationships aren't documented and reviewed, your assessment gets shaky fast.

Requirement 12.8 is not paperwork theatre

PCI DSS v4.0 Requirement 12.8.1 requires a detailed inventory of third-party service providers. In the UK, that's not a minor administrative task. A 2023 report cited 28% of payment disruptions linked to unmonitored TPSPs, the FCA requires quarterly TPSP risk reviews, and non-compliance led to £1.2M fines in 2024 for two fintechs with unpatched vendor APIs, as described in Mitratech's review of PCI third-party service provider requirements.

What to get from each vendor

For each vendor that touches or can affect your in-scope environment, ask for:

• A current AOC that clearly covers the service you use
• A responsibility matrix showing what they own, what you own, and what's shared
• Details on admin access and support access, especially if they can reach your environment remotely
• Breach notification expectations written into the contract
• Evidence that their compliance scope matches your implementation

A vendor can be “PCI compliant” in the abstract and still not cover the product tier, region, workflow, or configuration you use. That gap catches teams every year.

Prepare your side before the QSA asks

A good audit prep folder usually includes:

| Evidence type | What it should show | |---|---| | System inventory | In-scope services, connected systems, owners, and rationale | | Vendor records | AOCs, contracts, responsibility matrices, review notes | | Testing artefacts | Scan outputs, pentest reports, remediation and retest evidence | | Access records | MFA enforcement, privileged access reviews, joiner/mover/leaver controls | | Logging material | What is logged, where it goes, who reviews it, and response actions | | Policies and procedures | Current operating practice, not shelfware |

For teams tightening authentication around cloud consoles, support tooling, and privileged workflows, a focused resource on authentication for developers can help frame implementation choices without turning access control into a product blocker.

The vendor conversation should answer one thing clearly. If this provider fails, can you explain exactly which controls break, who responds, and what evidence you have of due diligence?

Continuous monitoring beats audit panic

The worst time to discover a regression is during evidence collection. Modern stacks change too fast for annual compliance snapshots to be reliable. Build a routine for rechecking exposed functions, policy changes, secret leaks, and vendor posture after releases and infrastructure changes.

That's how you make the audit a review of operating practice, not a scramble to reconstruct it.

Embedding Security into Your Service

The main lesson is straightforward. In a modern stack, pci dss service provider status often turns on security impact, not direct card storage. If your Supabase project, Firebase deployment, functions, identities, or vendors can influence the protection of payment data, you need to scope and manage them accordingly.

The teams that handle this well don't treat PCI as an annual form-filling exercise. They treat it as part of product engineering. Scope is architecture. Evidence is generated by real operations. Vendor management is part of platform ownership. Testing is continuous, not ceremonial.

That mindset does more than satisfy assessors. It makes your service easier to trust. Customers care whether your controls hold up when things change, not whether you passed a one-off review last quarter. Resources like Constructive-IT's security report are a useful reminder that credential theft, weak access control, and operational drift still create very practical business risk.

If you want the cleanest path, push security into delivery early. Build reviews around releases, privileges, secrets, and auth flows. Tie that work into a real secure software development life cycle so compliance evidence is a by-product of disciplined engineering, not a separate annual project.

---

If you're building on Supabase, Firebase, or mobile backends and want a faster way to spot the kinds of misconfigurations that expand PCI scope, AuditYour.App helps you scan for exposed RLS rules, public RPCs, leaked secrets, and other modern stack risks before an assessor or attacker finds them. It's a practical way to turn cloud-native security issues into concrete remediation work and audit-ready evidence.