The India Compliance Reference 2026

An accurate network diagram and a separate account-data-flow diagram, kept current. The first artefacts an assessor opens; stale diagrams cascade into scoping findings.

Every permitted service and port needs an identified business need and approval. "Any-any" rules are indefensible under this control.

Rulesets and security-group configurations are reviewed at least once every six months to confirm relevance and tightness.

Traffic to and from the CDE is limited to what is necessary — and everything else is denied, not just "not configured".

Direct inbound traffic from untrusted networks to the CDE is prohibited; connections terminate in a controlled boundary first.

Computing devices that connect to untrusted networks AND the CDE (laptops, jump hosts) need their own security controls — the control that catches split-tunnel VPNs.

Documented hardening standards covering every system type in scope, consistent with industry benchmarks (CIS, vendor guides) and kept current as vulnerabilities emerge.

Default accounts and passwords are changed, disabled or removed before deployment — on servers, network devices, POS terminals, HSMs and appliances alike.

Everything not required for the component’s function is removed or disabled — the control behind "reduce the attack surface".

Where an insecure service must run, the business justification and additional mitigations are documented.

All non-console administrative access uses strong cryptography — SSH and HTTPS, never telnet or plain HTTP, including appliance web consoles.

Wireless environments connected to the CDE change all wireless vendor defaults — keys, SNMP strings, passwords, firmware defaults.

Account data storage is kept to the minimum required, with defined retention and a quarterly (or risk-based) process that finds and securely deletes data past retention.

Full track data, card verification codes and PINs/PIN blocks must not be retained after authorisation — even encrypted (3.3.1.1–3.3.1.3). Issuers have a narrow, justified exception.

Displayed PAN shows at most BIN + last four; only roles with documented need see more.

One-way keyed cryptographic hashes, truncation, tokens or strong encryption. v4.0.1 note: hashes must be KEYED (3.5.1.1) — an unsalted/unkeyed SHA-256 of PAN fails.

Full-disk/transparent encryption alone renders PAN unreadable only on removable media; on servers it must be supplemented by another 3.5.1 method.

Documented key-management: generation, distribution, storage (fewest custodians, split knowledge/dual control for clear-text components), rotation at cryptoperiod end, and retirement.

PAN transmissions over open networks use strong cryptography with trusted keys and certificates, accepting no downgrade to insecure versions (TLS 1.2+ in practice).

A maintained inventory of the keys and certs protecting PAN in transit — issuer, expiry, strength. New in v4, fully effective 31 March 2025.

Wireless networks carrying PAN use industry best-practice authentication and transmission encryption — WEP/WPA legacy modes are automatic findings.

PAN sent via email, chat or SMS must be protected with strong cryptography — in practice: blocked by DLP and replaced with secure channels.

Every system component commonly affected by malware runs an anti-malware solution.

Components deemed "not commonly affected" are listed and re-evaluated at a frequency set by targeted risk analysis — the exemption must be earned repeatedly, not inherited.

The solution performs real-time protection, continuous behavioural analysis, or periodic scans at a TRA-defined frequency (5.3.2.1).

Removable media gets scanned or continuously protected when connected — USB remains a live infection path in POS and warehouse environments.

Anti-malware cannot be disabled or altered by users except case-by-case with management authorisation for a limited period.

Processes and automated mechanisms detect and protect personnel against phishing attacks — DMARC/SPF/DKIM, link/attachment filtering, plus the awareness side in 12.6.3.1. Fully effective 31 March 2025.

Bespoke software is built to a documented secure SDLC; developers train in secure coding annually (6.2.2); code is reviewed before release (6.2.3); engineering techniques address common attack classes (6.2.4).

New vulnerabilities are identified via industry sources and risk-ranked — the feed that drives both patching and scanning.

Critical/high security patches installed within one month of release; all others within a TRA-defined window.

Public-facing web applications sit behind an automated technical solution that detects and prevents web attacks (in practice a WAF in blocking mode) — mandatory since 31 March 2025, replacing the old "review or WAF" choice.

Every script on payment pages is authorised, integrity-assured and inventoried with written justification — the anti-Magecart control, new in v4.

Changes follow documented procedures: impact, approval, testing, rollback — and pre-production data/accounts never travel to production.

An access-control model defines access needs per role; assignments grant the least privilege necessary for the job.

Required privileges are approved by authorised personnel — the paper trail behind every grant.

New in v4: every user account and its privileges reviewed at least semi-annually, with remediation of inappropriate access. Fully effective 31 March 2025.

Service-account privileges are assigned least-privilege and reviewed at a TRA-defined frequency (7.2.5.1) — new in v4.

An access-control system covers all components, enforces per-role permissions, and is set to deny-all by default.

All users get a unique ID before access to system components or cardholder data. Shared/generic accounts are the first thing an assessor greps for.

Sessions idle for more than 15 minutes require re-authentication. Applies to consoles, jump hosts and admin panels inside the CDE.

Invalid attempts limited to 10 or fewer; lockout for at least 30 minutes or until identity is confirmed.

Passwords/passphrases require at least 12 characters (or 8 if the system cannot support 12 — document why), with both letters and numbers.

If passwords are the only factor, change every 90 days — or analyse account security posture dynamically in real time. MFA everywhere removes this treadmill.

New teeth in v4: MFA applies to all access into the cardholder data environment, not just remote or admin. Fully effective as a future-dated requirement since 31 March 2025.

Every remote access session originating outside the entity network — staff, admins and third parties alike.

MFA systems must not be susceptible to replay, cannot be bypassed by any user without documented management exception, and use at least two different factor types.

Application and service accounts that can be used interactively need management approval, individual accountability and protection of embedded passwords/keys.

Physical access to CDE areas is controlled and monitored — badge systems or equivalent, video or access-control mechanisms retained 90 days, console access in sensitive areas restricted.

Physical access is authorised per role, revoked on termination; visitors are approved, escorted, identified and logged, with logs retained at least 90 days.

Physical media is secured, classified, sent only by trackable methods, approved for movement, stored securely and destroyed when no longer needed (cross-cut shred, incinerate, or secure-wipe).

An up-to-date list of all point-of-interaction devices: make, model, location, serial number.

Devices are periodically inspected for tampering and substitution, at a frequency justified by targeted risk analysis (9.5.1.2.1).

Personnel in device environments are trained to verify technician identity, recognise tampering and report suspicious behaviour.

Individual user access to cardholder data, all admin actions, access to audit logs, invalid attempts, authentication changes, log initialisation/stops, and creation/deletion of system objects.

Audit logs readable only by need, protected from modification, backed up promptly to a central/secured location, with integrity monitoring on log files.

Security events, CDE component logs and critical-system logs reviewed daily using automated mechanisms (fully effective 31 March 2025); other logs periodically per TRA.

Audit log history retained at least 12 months, with the most recent three months immediately available for analysis.

System clocks synchronised via time-synchronisation technology from industry-accepted sources; time data protected from unauthorised change.

Failures of critical security control systems (NSCs, IDS, FIM, anti-malware, the SIEM itself) are detected, alerted and responded to promptly with documented process.

Authorised and unauthorised wireless access points identified at least quarterly — rogue-AP detection even where "we have no wireless".

Internal vulnerability scans at least every three months, resolving high/critical findings with rescans; scans must be authenticated (credentialled) as of 31 March 2025. Non-high/critical vulns are managed per TRA (11.3.1.1).

External scans by a PCI SSC Approved Scanning Vendor every three months, with passing results and rescans after failures.

Penetration testing per a documented methodology at least annually and after significant change — application and network layer.

Where segmentation isolates the CDE, its effectiveness is penetration-tested at least annually — every six months for service providers.

A mechanism detects unauthorised changes to payment-page HTTP headers and script contents, alerting within a TRA-defined frequency (at least weekly). New in v4, effective 31 March 2025.

An information-security policy established, published, reviewed annually, with security responsibility formally assigned to a CISO or equivalent.

Every control that says "per TRA" (POI inspections, scan frequencies, training cadence…) needs a documented analysis — new v4 machinery that assessors collect as a set.

PCI DSS scope documented and confirmed at least annually and on significant change — every six months for service providers (12.5.2.1). The written exercise, not an assumption.

Security awareness reviewed annually, delivered on hire and at least annually, with acknowledgement — and must address phishing/social engineering (12.6.3.1).

TPSP list, written agreements with responsibility acknowledgements, due diligence before engagement, annual monitoring of their PCI status, and a responsibility matrix per provider.

An IR plan covering roles, communication, regulators and card brands; tested at least annually; personnel trained; and procedures for PAN discovered where it should not be (12.10.7).

A policy set approved by management, published, reviewed at planned intervals — the artefact every other control hangs from.

Information about threats collected and analysed to produce actionable intelligence — feeds, advisories (e.g. CERT-In), and evidence it changed a decision.

Security in supplier agreements, managing supplier service delivery, and monitoring/review/change management across the supply chain.

Processes for acquiring, using, managing and exiting cloud services — selection criteria, shared-responsibility mapping, exit strategy.

Planning, assessment, response, learning and evidence collection for information security incidents.

ICT continuity planned, implemented and TESTED against BC objectives — the control that links the ISMS to real DR exercises.

Identifying legal/regulatory requirements (DPDP for Indian entities), protecting records and PII, and independent review of the ISMS.

Background verification proportional to business requirements, data classification and perceived risks — before joining AND on role change.

Contracts state information-security responsibilities that survive employment where relevant (confidentiality, IP, return of assets).

Role-appropriate security awareness on joining and at planned intervals, with effectiveness evaluated — not just attendance captured.

A formalised, communicated process for security violations — the control that makes policy enforceable.

Duties that remain valid after exit are defined, communicated and enforced — paired with asset return and access revocation.

NDAs for personnel and interested parties, reviewed at planned intervals.

Security measures for remote work: device controls, home-network expectations, physical protections — post-2020 this is verified, not assumed.

Personnel report observed or suspected events through an easily reachable channel, in good time — the human sensor network.

Defined security perimeters protecting areas with information assets; entry controlled and monitored appropriately.

Physical security designed and applied for offices and server/network rooms.

Premises continuously monitored for unauthorised access — CCTV, intruder detection, guard processes — with retention and review defined.

Rules for working inside secure areas: supervision, no unauthorised recording, vacant-area lockdown.

The rule interviews and walkthroughs test — papers, removable media and unlocked screens in shared spaces.

Devices and media used outside the premises protected — travel rules, home-office expectations.

Media managed through its lifecycle: acquisition, use, transport and secure disposal.

Storage verified wiped or destroyed before disposal/reuse — with records that prove it.

Privileged rights restricted and managed; access to information limited per the access-control policy — least privilege, provable.

Vulnerabilities identified, exposure evaluated, and remediated with measured timelines — scans plus SLA evidence.

Configurations — including security configurations — established, documented, implemented, monitored and reviewed. Hardening baselines with drift detection.

Information deleted when no longer required — the control that pairs with DPDP s.8(7) erasure duties for Indian entities.

Masking per policy for sensitive data; data-leakage prevention applied to systems and channels carrying sensitive information.

Logs produced, protected and analysed; networks/systems/applications monitored for anomalous behaviour with response.

Access to external websites managed to reduce exposure to malicious content.

Secure SDLC rules, requirements, architecture/engineering principles, secure coding (8.28 new), testing and environment separation.

Changes to information processing facilities follow the change-management procedure — with samples that prove it.

Integrity, board oversight, structure, competence and accountability — the COSO layer auditors verify through governance artefacts, org charts and HR practices.

Internal and external communication of security commitments and responsibilities — policies published, customers informed, incidents communicated.

Objectives specified, risks identified and analysed (including fraud risk), significant change considered — a living risk register, not an annual PDF.

Ongoing and separate evaluations of controls, with deficiencies communicated and tracked to closure.

Controls selected and deployed to mitigate risks, including over technology — the bridge from risk register to actual safeguards.

The largest block: access provisioning/deprovisioning, authentication, least privilege, physical access, media disposal, and protection against outside access and malware.

Vulnerability monitoring, anomaly detection, incident evaluation, response and recovery — with evidence the loop has actually run.

Infrastructure, data and software changes authorised, designed, tested, approved and implemented — sampled end to end across the period.

Business-disruption risk mitigation and vendor/business-partner risk management — assessments, agreements, monitoring.

Current processing capacity monitored and future demand forecast, with action when thresholds approach — dashboards, alerts and scaling decisions on record.

The resilience stack: environmental safeguards (largely inherited from cloud providers), backup configuration and recovery infrastructure authorised, designed and operated.

Recovery plan procedures TESTED — restore drills and DR exercises with results and lessons, not a plan that has never fired.

Definitions of the data processed and processing specifications communicated — what "correct" means, written down.

System inputs complete and accurate — validation, rejection handling, reconciliation at the point of entry.

System processing complete, valid, accurate, timely and authorised — job monitoring, error queues, exception handling with evidence of resolution.

Outputs complete, accurate, distributed only to intended recipients — reconciliations and delivery controls.

Items stored during processing protected and retained per specification, supporting reprocessing where needed.

Confidential information identified (classification) and protected through its lifecycle — access limits, encryption, handling rules tied to the classification.

Confidential information disposed of when retention ends — executed deletion with records, including at contract termination when customers ask for it.

Notice to data subjects about privacy practices — what is collected, why, how used and retained.

Choices communicated and consent obtained for collection, use and disclosure — the DPDP s.6 twin.

Personal information collected consistent with objectives; explicit consent where required for sensitive data.

Use limited to purposes; retention limited; disposal executed — the criteria that pair with DPDP s.8(7) erasure duties.

Data subjects can access and correct their personal information.

Disclosures with consent, processor commitments, breach notification obligations — the largest P-block.

Personal information kept accurate, complete and relevant.

Complaints and disputes addressed; compliance monitored.

Mission, stakeholder expectations, legal and regulatory requirements understood — the inputs that make the rest of the profile YOURS rather than generic.

Risk appetite and tolerance established, communicated and used in decisions — the artefact examiners and boards actually ask for.

Cybersecurity roles defined, resourced and communicated — including leadership accountability.

Cybersecurity policy established, communicated and enforced, refreshed as risks and requirements change.

Risk-management performance reviewed and used to adjust strategy — metrics with a feedback loop, not a dashboard nobody reads.

Supplier cyber risk integrated into wider risk management: criteria, contracts, monitoring, incident coordination — heavily expanded in 2.0.

Hardware, software, services, data and their flows inventoried and prioritised by criticality — including the cloud and SaaS estate that shadow IT grows.

Vulnerabilities and threats identified, likelihood and impact analysed, risk responses chosen and tracked — with intelligence feeding it.

Lessons from assessments, tests, incidents and exercises drive improvement plans — the category that turns findings into change.

Identities managed lifecycle-wide, authenticated proportionally to risk (MFA), access granted least-privilege and reviewed.

Personnel and privileged/specialised roles trained for their responsibilities — role-based, refreshed, measured.

Data-at-rest and in-transit protected, backups created, protected and tested — confidentiality, integrity and availability together.

Configuration management, software maintenance/patching, logging enabled, software integrity — the hardening category (new arrangement in 2.0).

Networks and environments protected and built to resist and recover — segmentation, capacity, resilience mechanisms.

Networks, computing environments, personnel activity and external service providers monitored to find adverse events — coverage matched to the asset inventory.

Anomalies analysed, correlated across sources, impact estimated, incidents declared against defined criteria — the pipeline from alert to declaration.

Response executed per plan once an incident is declared: triage, categorisation, prioritisation, escalation.

Investigation to establish what happened and what is affected; evidence collected and preserved to support decisions and any legal process.

Internal and external stakeholders informed per obligations — for India: CERT-In within 6 hours for notified incident types, plus RBI/SEBI/IRDAI and DPDP breach duties as applicable.

Incidents contained and eradicated — with the actions recorded as they happen, not reconstructed later.

Recovery executed per plan: restoration priority by criticality, integrity of backups verified BEFORE restoration, systems confirmed clean and operational.

Restoration progress communicated to internal and external stakeholders — customers, regulators, partners — with consistent messaging.