Strategy & Governance

Managed Security

Cyber Defense

Governance, Risk & Compliance

Operations & People

Talk to us

Governance, Risk & Compliance

PCI DSS v4.0.1, scoped down before it is built up.

A PCI DSS compliance consultant in India earns their fee in the first fortnight, and not by writing policy. They earn it by working out exactly which systems store, process or transmit cardholder data, and how many of them do not need to. Every system you remove from scope is a system you never have to harden, monitor, patch on a clock or evidence for a year.

Worth saying plainly: we are not a Qualified Security Assessor. A Report on Compliance is signed by a QSA, and for most merchants a Self-Assessment Questionnaire is signed by you. Our work is everything on either side of that signature: establishing scope, reducing it, closing the gaps, and building the evidence so the assessment is a review rather than a discovery exercise.

Version 4.0.1 is the standard in force; v3.2.1 was retired in March 2024, and the requirements that were future-dated became mandatory on 31 March 2025. If your last assessment was against v3.2.1, the delta is real, particularly around scripts on payment pages, authenticated scanning and the new targeted risk analyses. Where the same estate also needs penetration testing, PCI DSS mandates it, so the two should be planned together rather than bought twice.

Why you need it

01 / 06

Why scope is the whole argument.

01

Scope is the single biggest cost lever you have.

Requirements apply to the cardholder data environment and to anything connected to it. Tokenising, redirecting payment pages to the provider, and segmenting what remains can move an assessment from hundreds of systems to a handful. Nothing else you do will save as much.

02

Segmentation is a claim you have to prove.

If you assert that a network is out of scope, that assertion is tested: annually for merchants, twice yearly for service providers. A firewall rule you believe in is not evidence. A segmentation test that tries to cross the boundary and fails is.

03

v4.0.1 moved the payment page goalposts.

Requirements 6.4.3 and 11.6.1 mean the scripts loaded on a payment page must be inventoried, authorised and monitored for unauthorised change. This is a direct answer to digital skimming, and it is the requirement most e-commerce teams discover late.

04

Compensating controls are audited harder, not less.

Where a requirement genuinely cannot be met, a compensating control has to meet the intent, exceed the rigour of the original, and be documented in a worksheet the assessor accepts. It is a legitimate route and a slow one. Far better to design the requirement out.

Instrument

02 / 06

Where PCI DSS overlaps what you already run.

Most organisations meeting PCI DSS are already doing two thirds of it for another framework. This shows the overlap before you fund a second programme.

What we deliver

03 / 06

What we deliver.

01

Scope and data-flow mapping

Where card data enters, where it rests, where it leaves, and every system that touches or can reach it. Delivered as a diagram and an asset inventory you can hand an assessor, not a paragraph of description.

02

Scope reduction design

The practical options for your architecture (tokenisation, hosted payment pages or iframes, point-to-point encryption, network segmentation) costed against the assessment effort each one removes. Sometimes the answer is to change the payment flow, and we will say so.

03

Gap analysis against v4.0.1

Every applicable requirement assessed as met, partially met or not met, with what is missing and who owns it. Including the requirements that changed in v4.0 and the targeted risk analyses the standard now expects you to have written.

04

Remediation and control build

Hands-on work on the gaps: logging and retention, access control and MFA, change management, secure configuration standards, key management, and the file-integrity and script-monitoring controls on payment pages.

05

Testing that PCI DSS requires by name

Internal and external vulnerability scanning, segmentation testing, and application and network penetration testing to Requirement 11, run by our own testers, with the reproduction steps and the retest.

06

Assessment support

The evidence pack assembled before the QSA arrives, the SAQ completed correctly for your merchant level and channel, and someone in the room who can answer the assessor without inventing an answer.

How we run it

04 / 06

The engagement, step by step.

  1. 01

    Establish the real scope

    Interviews, network and data-flow discovery, and a review of every payment channel, including the ones nobody mentioned, like phone orders taken on a recorded line.

    Weeks 1-2
  2. 02

    Reduce it

    Present the scope-reduction options with the effort each removes from the assessment, and agree the target architecture before any control work starts.

    Weeks 2-3
  3. 03

    Gap analysis

    Assess the reduced scope against every applicable v4.0.1 requirement and produce the remediation plan, prioritised by assessment risk and by effort.

    Weeks 3-5
  4. 04

    Remediate

    Close the gaps alongside your teams. The long poles are usually logging, key management and the payment-page script controls, so they start first.

    Months 2-4
  5. 05

    Test and evidence

    Run the scans, the segmentation test and the penetration test, fix what they find, retest, and assemble the evidence pack against each requirement.

    Month 4-5
  6. 06

    Assessment and after

    Support the QSA assessment or the SAQ, then set the recurring calendar: quarterly scans, annual testing, and the reviews the standard expects between assessments.

    Month 5, then quarterly

Key benefits

05 / 06

What changes afterwards.

A smaller estate to defend

Scope reduction done properly does not just cut the assessment. It permanently removes cardholder data from systems that never had a good reason to hold it, which is a security outcome long after the certificate is filed.

An assessment with no surprises in it

Because the gaps were found and closed by us rather than by the assessor, the assessment becomes a review of evidence that already exists instead of a negotiation about what might count.

Controls that survive the year

Quarterly scanning, change management and access review run on a calendar with named owners, so the next assessment starts from a working system rather than from a scramble.

Tools we use

06 / 06

Named, and used on your engagement.

No “latest tech tools”. These are the ones your report will cite, alongside the manual work that a tool cannot do for you.

Standard

  • PCI DSS v4.0.1
  • PCI SSC SAQ A through D
  • Prioritised Approach for PCI DSS v4.x

Scanning and testing

  • ASV scanning through an approved vendor
  • Nessus
  • Burp Suite Professional
  • Nmap

Segmentation validation

  • Nmap
  • hping3
  • Custom egress and reachability testing

Evidence and monitoring

  • Wazuh
  • OSSEC file integrity monitoring
  • AphelioNYX Compliance Hub

Mapping

  • PCI SSC mappings to ISO 27001 and NIST
  • AphelioNYX Frameworks Hub

Why Aphelion

Shared

Four things you can check.

01

The work is done by people with names.

Darshap Nayak, formerly of KPMG, holds a master’s degree in cybersecurity and more than seven years in security operations. Jaimin Somani brings fifteen-plus years of academic and hands-on VAPT. Hemang Desai is an ICT network specialist from Australia. You will meet them, not a logo.

Meet the team
02

Evidence, not adjectives.

Every finding arrives with the reproduction steps, the affected asset and the fix, ranked by what it actually reaches in your environment, not by a CVSS number copied from a scanner. You get the report and the raw output, not a summary of a summary.

See how we test
03

Two offices, one practice.

Ahmedabad and Sharjah, working the same methodology on the same tooling. Indian data-residency requirements and UAE delivery are both ordinary here, and the AphelioNYX AD Pen-Test module runs entirely inside your perimeter when regulation says it must.

The platform
04

What we will not do.

Invent a statistic to make a slide land. Publish your name as a client without written permission. Print an award badge nobody awarded. Founded in 2024. We say so, and we attribute experience to the people who have it.

Ask us anything

100+ organizations secured

Across the globe, and across eight industries. We name a client only with their written permission.

  • Finance & Banking
  • Healthcare
  • Retail & E-commerce
  • Technology
  • SaaS
  • Hospitality
  • Manufacturing
  • Pharmaceuticals

AphelioNYX is SOC 2, ISO and GDPR compliant; attestations are available on request under NDA. We would rather hand you the report than print a badge.

Questions

FAQ

Asked often enough to answer here.

Can Aphelion Cyber sign our Report on Compliance?
No. A Report on Compliance is signed by a Qualified Security Assessor, and we are not a QSA company. What we do is everything around that signature: scoping, scope reduction, gap analysis, remediation, the Requirement 11 testing and the evidence pack, so that the QSA assessment is a verification rather than a discovery exercise. If you are completing a Self-Assessment Questionnaire instead, you sign that yourself, and we make sure the answers are accurate and evidenced before you do.
Which SAQ applies to us?
It depends on how you take payments, not on your size. A merchant who has fully outsourced the payment page to a provider and never touches card data may qualify for SAQ A. Taking the card details on your own page, even if you pass them straight to a gateway, usually means SAQ A-EP. Storing card data at all, or taking payments by phone or terminal, moves you further down the list towards SAQ D. Getting this wrong is common and expensive, because the wrong SAQ means either work you did not need or an attestation that does not hold.
What actually changed in v4.0 that affects us?
The changes that catch people are the payment-page script controls in Requirements 6.4.3 and 11.6.1, authenticated internal vulnerability scanning, stronger authentication expectations including MFA for all access into the cardholder data environment, and the targeted risk analyses the standard now expects you to document for several requirements where you set your own frequency. Roles and responsibilities must also be assigned explicitly for each requirement. All of the future-dated requirements became mandatory on 31 March 2025.
Does PCI DSS require a penetration test?
Yes. Requirement 11.4 requires internal and external penetration testing at least annually and after any significant change, covering the network and application layers and the full cardholder data environment perimeter. If you assert segmentation to reduce scope, that segmentation must also be tested, annually for merchants and every six months for service providers. We run this testing ourselves, which means the findings arrive with reproduction steps rather than as a scanner export.
How long does a first PCI DSS engagement take?
For a mid-sized organisation with a reasonably contained payment flow, four to six months from scoping to assessment is realistic. Scoping and gap analysis take four to five weeks. Remediation is the variable, and it is driven almost entirely by how much scope reduction you are willing to do architecturally: an organisation that moves to a hosted payment page finishes far sooner than one that keeps card data in its own database and hardens around it.

Forty-five minutes. Your environment, not a slide deck.

A personalised walkthrough and a free readiness assessment against the frameworks you are actually being asked for. Pick a time that suits you, or write to us. We reply within one business day.