PCI DSS Requirements: Where Assessors Actually Concentrate

The standard has twelve requirements, and assessors do not spend the same time on each. Knowing where the scrutiny falls helps you prepare where it matters. Your acquirer confirms your level and validation route, and what is tested varies by merchant type. The points below apply to any business that accepts cards, in India or elsewhere.

Where do assessors concentrate across the PCI DSS requirements?

In practice, assessors concentrate on four areas: scope, stored data, logging and monitoring, and the allocation of responsibility between you and your suppliers. Weaknesses in these areas are where compromises tend to start, which is why they draw the most attention.

The other requirements are still tested, usually by sampling. The sections below follow the requirement numbers, with scope first because it shapes everything else.

What do assessors check before any requirement in a PCI DSS assessment?

They validate scope first. The assessor confirms your cardholder data environment, tests whether segmentation works where you rely on it, and looks for card data outside the defined boundary. Scope shapes everything that follows, so a mistake here changes the whole assessment.

Card data discovery scanning across systems is common. If it finds card data outside your defined scope, the assessment stops being about your controls and becomes about your scope. The standard expects scope to be confirmed at least every 12 months and after significant change.

How do assessors test network and configuration controls (Requirements 1 and 2)?

They sample systems and compare them with your own documents. For network security controls, assessors read rulesets and ask why each permissive rule exists. For configurations, they compare builds with your standard, looking for older systems never brought into line.

Requirement 1 covers network security controls. Any rule that allows traffic without a documented business reason is a finding. Where segmentation supports scope reduction, this is where its effectiveness is examined.

Requirement 2 covers secure configurations. Vendor defaults must be changed and unnecessary services disabled. The common failure is a standard that exists, with older systems never brought into line.

Why is stored account data examined so closely in Requirement 3?

Requirement 3 is heavily examined because it asks what you store, why, for how long and how it is protected. Sensitive authentication data must not be stored after authorisation, even if encrypted. That covers card verification codes, full track data and PINs. Finding any of them is a serious result.

Assessors look in application databases, logs, error dumps and call recordings. Retention must be justified by business need, with a defined period and a deletion process that actually runs.

How do assessors check encryption and malware protection (Requirements 4 and 5)?

For encryption, assessors check protocol versions and cipher suites, and look for legacy protocols still enabled. For malware protection, they check that it is deployed, current and generating logs. In both cases they look for coverage gaps rather than the tool itself.

Requirement 4 expects strong cryptography over open networks. Requirement 5 is straightforward, so coverage gaps are what assessors find.

What do assessors expect on patching, development and payment pages?

Assessors check patch currency against your own stated timeframe, which is often where the gap appears. Where you build software that touches card data, they review secure coding, code review and protection against common vulnerability classes. Version 4 added rules for payment page scripts, which are new ground for many merchants.

Patching needs defined timeframes based on risk, plus evidence they are met. The payment page rules ask you to authorise, inventory and justify each script, and to detect changes to them. Both became required on 31 March 2025.

What do assessors look for on access and physical controls?

Assessors sample users and ask why each has the access they hold. They look specifically for shared accounts, including administrative, service and vendor accounts. In card-present settings, they ask for records of device inspections for tampering, which are often missing.

Requirement 7 expects access on a defined need-to-know basis with least privilege. Requirement 8 expects unique IDs, no shared accounts and multi-factor authentication for defined access. Version 4 expanded these expectations, and firms that were assessed earlier may not have caught up. Requirement 9 covers facility controls, media handling and media destruction.

Why is logging and monitoring so often a weak area?

Collecting logs is a technology purchase. Reviewing them is an operational commitment, and that is where firms slip. Logs must capture defined events, be protected from alteration and be kept for a defined period. Assessors then ask for evidence that someone reviewed them.

Requirement 10 expects defined logs to be reviewed at least once daily, with 12 months of history kept and the latest three months ready for immediate analysis. Time synchronisation is also checked, since log correlation depends on it.

Say a Hyderabad billing software firm sends every log to a central tool but has never opened a report from it. The assessor asks who reviewed last Tuesday’s alerts, and nobody can answer.

What do testing, policy and supplier duties involve in Requirements 11 and 12?

Requirement 11 covers internal and external scans, penetration testing, segmentation testing where you rely on it, and change detection. Requirement 12 covers policy, risk assessment, awareness, incident response and third-party management. Assessors give suppliers growing attention, and expect each party’s duties to be documented.

Scans must pass. A quarterly scan with unresolved high-severity findings does not, and firms sometimes file reports without noticing they failed. Segmentation testing is required where segmentation reduces scope, at least every 12 months, and is often missed entirely.

For suppliers, keep a list of providers, their PCI status and a documented split of which requirements each party owns. Incident response must be tested at least every 12 months, not only written.

How do PCI DSS consultants play a main role?

PCI DSS consultants help you prepare where assessors look hardest. They confirm scope, run a gap assessment against the twelve requirements, and help build the evidence an assessor will sample. They do not set your level, and they do not carry out the assessment.

A consultant can walk the logging and supplier evidence the way an assessor would, before the assessor does. If an adviser also acts as one of your ISO certification consultants, ask which PCI DSS tasks they will do and which they leave to an assessor.

How can MSCi help with PCI DSS compliance?

We are a consultancy with 40+ years of experience in ISO consultation, and we prepare companies for assessments and audits. For PCI DSS, we focus on scoping, gap assessment and remediation planning. We do not issue a Report on Compliance or an Attestation of Compliance.

MSCi usually begins by testing scope the way an assessor does, then reviews the four areas above. We then agree a remediation plan with owners and dates, and help you gather evidence through the year.

Frequently Asked Questions

1. Which of the PCI DSS requirements do assessors examine most closely?

Requirement 3, protecting stored account data, is heavily examined. Scope, logging and monitoring, and third-party responsibilities also draw close attention.

2. What happens if card data is found outside the defined scope?

The assessment shifts from your controls to your scope. You either remove the data or bring those systems into the cardholder data environment and secure them.

3. How often must logs be reviewed under the PCI DSS requirements?

Defined logs must be reviewed at least once daily. Audit log history is kept for at least 12 months, with the latest three months available for immediate analysis.

4. Do payment page scripts fall under a PCI DSS assessment?

Yes, where you run payment pages. Requirements 6.4.3 and 11.6.1 cover script authorisation and change detection, and both became required on 31 March 2025.

5. Can MSCi carry out our PCI DSS assessment?

No. MSCi prepares you through scoping, gap assessment and remediation planning, but it is not a Qualified Security Assessor. Your acquirer confirms who must assess you and how.

6. What counts as a passing vulnerability scan?

External scans are run every three months by an Approved Scanning Vendor and must meet its passing criteria. For internal scans, high-risk and critical vulnerabilities must be resolved and confirmed by rescans.