SAQ A · SAQ A-EP
PCI compliance without the panic.
Hardened, TLS-only hosting for small merchants and the agencies who look after them — built around SAQ A and SAQ A-EP. Answer five questions and find out which questionnaire is actually yours.
Shared hosting plans from €12/month — TLS-only, patched, logged. Real pricing lives on the order page.
Guidance, not a QSA opinion. Your acquirer has the final word.
What PCI DSS actually asks of your host
PCI DSS is a contractual security standard set by the payment card networks — not a government law — and every organisation that stores, processes or transmits cardholder data agrees to follow it as a condition of accepting cards. For a hosting provider, that obligation is narrower than for a merchant: it covers the servers, the network and the software stack underneath your site — TLS everywhere, hardened configurations, timely patching, logging, and support for the scans your acquiring bank asks you to run.
It does not cover your shopping-cart logic, your staff's laptops, or the copy on your payment page. That half of the questionnaire is still yours — the responsibility matrix in §3 draws the exact line.
Which SAQ type do you need?
Five questions, real SAQ decision logic, one plain-English answer — SAQ A, SAQ A-EP, SAQ D, or out of scope for card data.
| Control | Your host (us) | You |
|---|---|---|
| TLS configuration | ✓ TLS 1.2+/1.3 only, HSTS enforced | ● Keep forms & assets off plain HTTP¹ |
| Patching | ✓ OS & server stack, patch SLA | ● Your CMS, plugins & themes |
| Logging | ✓ System & access logs, retained | ● Application-level audit logs |
| File integrity monitoring | ✓ Host-layer FIM | ● Your CMS core & plugin files² |
| Network segmentation | ✓ Hosting environments isolated | ● Your own additional systems, if any |
| Backups | ✓ Automated environment backups | ● Your product & order data exports³ |
| Access control | ✓ Server, SSH & panel access | ● Your admin panel & staff accounts |
| ASV scanning | ✓ We never block your scanning vendor | ● You commission & remediate⁴ |
- ¹ Mixed-content payment forms can fail SAQ eligibility outright — check every checkout path, not just the main one.
- ² Required in practice for SAQ A-EP, where your own code can affect the payment page.
- ³ Your backups still need a restore test on your side — ours cover the server they sit on.
- ⁴ Required for SAQ A-EP and SAQ D; often, not always, waived for pure SAQ A. Confirm with your acquirer.
What we run, every day, on every plan
TLS 1.2+ and 1.3 only
No legacy protocol downgrade path.
HSTS by default
Browsers refuse to fall back to plain HTTP.
Patch SLA
A defined window for OS & stack security patches.
Log retention
Access & system logs kept for audit and review.
File integrity monitoring
Host-layer FIM watches for unexpected change.
Segmented networks
Hosting environments isolated from one another.
ASV-scan support
We don't block your Approved Scanning Vendor.
Need a dedicated certificate for a legacy integration? See SSL options.
What we do not do
- We are not a Qualified Security Assessor (QSA).
- We do not issue Attestations of Compliance (AOCs).
- We never touch, see or store your customers' card numbers — that's the point of keeping them on a validated processor's page.
- If your business takes card data outside your website (a call centre, paper forms), that scope is entirely yours to manage.
Frequently asked
Which SAQ type do I need?
It depends on how your payment page is built, not on which host you use. Run the SAQ Wizard above: if your form lives entirely on your processor's hosted page or iframe, you're likely SAQ A; if your own page's code can influence that payment page (a JS SDK, custom fields), you're likely SAQ A-EP; if you store card numbers anywhere, it's SAQ D. Your acquirer makes the final call.
Does compliant hosting make me PCI compliant?
No. Hosting is one control domain among many. Even on hardened, TLS-only infrastructure, you're still responsible for your own SAQ, your staff's access habits, your plugins, and your payment page's code. A validated host narrows your workload — it doesn't complete it.
Do I need an ASV scan?
Usually yes if you're SAQ A-EP or SAQ D — quarterly external vulnerability scans by an Approved Scanning Vendor are a standard requirement for those questionnaires. Pure SAQ A merchants are often, but not always, exempt — check your SAQ A eligibility criteria or ask your acquirer directly.
What changed with PCI DSS 4.0.1?
4.0.1 is a clarifying update to 4.0, not a new standard. The headline changes for e-commerce sites are requirements 6.4.3 (managing and monitoring every script on your payment pages) and 11.6.1 (tamper detection for those pages) — both aimed at skimming attacks like Magecart. If you run SAQ A-EP, these apply to you directly.
What's the difference between SAQ A and SAQ A-EP?
SAQ A is for merchants whose website never touches the payment page at all — it just redirects or embeds a hosted iframe from a validated processor. SAQ A-EP is for merchants whose website code can still influence that payment page — for example, a JavaScript SDK or custom fields — even though the card number itself never reaches your server. SAQ A is roughly 24 questions; SAQ A-EP is closer to 139.
Can a hosting company call itself 'PCI compliant'?
A hosting provider can be validated as a compliant service provider for the infrastructure it controls — but that status doesn't transfer to you. Each merchant still completes their own SAQ. We say 'PCI-ready hosting', never 'automatically compliant', because the second claim isn't true for anyone.