The India Compliance Reference 2026
Every dated obligation an Indian organisation answers to — DPDP, CERT-In, RBI, SEBI — sourced to the Gazette or the regulator, plus the four global frameworks decoded control-by-control. Compiled from the open registry and the framework series, so the report and the site can never disagree.
Updated 2026-08-11 · reads ~150 printed pages · use your browser’s Print → Save as PDF for the full document
Executive overview
India’s compliance landscape stopped being advisory in this decade. The DPDP Act put a ₹250-crore ceiling on data-protection failure, CERT-In put a six-hour clock on incident reporting, RBI moved technology governance from circular to Master Direction, and SEBI gave the securities market a CSF-shaped framework with hard dates. At the same time, the global frameworks that Indian companies sell against — PCI DSS v4.0.1, ISO/IEC 27001:2022, SOC 2, NIST CSF 2.0 — all went through their largest revisions in a decade, and their transition windows have now closed. An organisation operating in India in 2026 is not choosing whether to build a compliance programme; it is choosing whether to build one programme or five.
This reference exists to make that choice with facts rather than folklore. Part one (chapters 2–3) is the dated, sourced obligation base: what commenced when, under which Gazette notification or regulator publication, with a last-verified date on every entry. Part two (chapters 4–7) decodes the four global frameworks at the level where audits are actually decided — requirement, theme, criterion and function — including where programmes fail and the evidence assessors accept. Part three (chapter 8) is the argument the data supports: controls built once, evidenced once, and mapped many times.
A note on integrity: this document is compiled from CyberSigma’s open India Compliance Registry and framework series data. Nothing in it is a survey we did not run or a statistic we cannot source. Where authoritative sources disagree — and on one DPDP commencement date they do — the disagreement is stated, not smoothed over. The method is chapter 9; the registry’s changelog is public; corrections are appended, never silently made.
The dated obligations, in order
Dates decide budgets. This chapter lists every dated obligation in the registry, most recent first, each with its primary source. 9 obligations are still ahead as of publication — those are the planning horizon.
Still ahead
Section 6(9) (verifiable parental consent) and section 27(1)(d) (publication duty) commence one year from notification — November 2026.
Source: DPDP Rules 2025 (phased commencement) · verified 2026-08-01
Rule 4 of the Digital Personal Data Protection Rules, 2025 establishes the registration and oversight framework for Consent Managers and comes into force on 13 November 2026. A Consent Manager is registered with the Data Protection Board of India and acts as a single point of contact through which a Data Principal can give, manage, review and withdraw consent via an accessible, transparent and interoperable platform.
Source: MeitY - Digital Personal Data Protection Rules, 2025 (official page) · verified 2026-08-08
Note: MeitY returns HTTP 403 to automated retrieval for both the Rules page and its own FAQ PDF, so this is corroborated across independent legal analyses rather than read from the primary text. Verify against the notified Rules before relying on it in a deliverable.
Part A of the First Schedule sets the conditions the Board must be satisfied of before registering a Consent Manager. They include incorporation in India, a minimum net worth of INR 2 crore (adjusted for inflation), sound financial condition and general character of management, and sufficient technical, operational and financial capacity to discharge the role. Directors, key managerial personnel and senior management must be persons of general reputation and record of fairness and integrity.
Source: MeitY - Digital Personal Data Protection Rules, 2025, First Schedule Part A · verified 2026-08-08
Note: MeitY returns HTTP 403 to automated retrieval for both the Rules page and its own FAQ PDF, so this is corroborated across independent legal analyses rather than read from the primary text. Verify against the notified Rules before relying on it in a deliverable.
A Consent Manager acts in a fiduciary capacity toward the Data Principal. It must not act as Data Fiduciary or Data Processor for the same Data Principal whose consent it manages, must route personal data in a form it cannot itself read, must treat all Data Fiduciaries neutrally without preferential access, and must retain consent records for at least seven years.
Source: MeitY - Digital Personal Data Protection Rules, 2025, First Schedule Part B · verified 2026-08-08
Note: MeitY returns HTTP 403 to automated retrieval for both the Rules page and its own FAQ PDF, so this is corroborated across independent legal analyses rather than read from the primary text. Verify against the notified Rules before relying on it in a deliverable. The conflict rule is the commercially significant one: an organisation cannot register as a Consent Manager for data subjects it also serves as a Data Fiduciary.
NPCI's volume-cap guidelines for Third-Party Application Providers in UPI (referencing circular NPCI/UPI/OC-97/2020-21) were originally to bite from 31 December 2024. The compliance timeline for existing TPAPs exceeding the cap was extended by two years, to 31 December 2026. Separately, NPCI issued Guidelines on usage of UPI APIs (OC 215 series, May 2025) requiring PSPs and acquiring banks to monitor and control API usage, with non-compliance exposing them to API restriction, penalties or suspension of new customer onboarding.
Source: NPCI UPI circulars (official listing) · verified 2026-08-07
Note: npci.org.in returns HTTP 403 to automated retrieval, so circular text could not be read directly. Circular references, the two-year extension to 31 December 2026 and the OC 215 API guidelines are corroborated across independent regulatory-tracking services. Confirm clause wording against the PDFs before relying on this in a deliverable.
Notice and consent standards, data fiduciary duties, children's data and data principal rights commence eighteen months from notification — May 2027. Published analyses split on 12 vs 13 May; confirm the exact day with counsel before relying on it.
Source: DPDP Rules 2025 (phased commencement) · verified 2026-08-01
The Schedule to the Act caps monetary penalties at up to ₹250 crore per instance for the highest tier (failure to take reasonable security safeguards to prevent a personal data breach), with lower tiers at ₹200 crore, ₹150 crore and below; the Data Protection Board determines penalties on the facts.
Source: DPDP Act 2023, the Schedule (official Gazette text) · verified 2026-08-01
Note: Amount verified directly against the Gazette PDF text ('may extend to two hundred and fifty crore rupees'). Enforcement follows the phased commencement (see dpdp-phase-3).
Under Rule 7 of the DPDP Rules 2025, a data fiduciary must intimate the Data Protection Board of a personal data breach without delay on becoming aware, follow with a detailed report within 72 hours (extendable by the Board), and notify affected data principals of the breach in plain language.
Source: DPDP Rules 2025, Rule 7 · verified 2026-08-01
Note: Timelines corroborated across multiple legal publishers. Enforcement follows the phased commencement (see dpdp-phase-3). Runs in parallel with CERT-In’s 6-hour incident reporting — the same incident triggers both.
Every consent request must be accompanied or preceded by a notice informing the data principal of: (i) the personal data and the purpose of processing; (ii) the manner of exercising rights under s.6(4) (withdrawal) and s.13 (grievance redressal); and (iii) the manner of making a complaint to the Data Protection Board. For consents given before commencement, notice must follow as soon as reasonably practicable.
Source: DPDP Act 2023, section 5 (official Gazette text) · verified 2026-08-01
Note: Contents verified directly against the Gazette PDF text. Notice must be available in English or any Eighth Schedule language.
In force
Article 111 gives longer runways to AI already in service. Providers of general-purpose AI models placed on the market before 2 August 2025 must comply by 2 August 2027. High-risk systems placed on the market before 2 August 2026 are caught only if subject to significant design changes after that date — but providers and deployers of high-risk systems intended for use by public authorities must comply by 2 August 2030 regardless. AI systems that are components of the large-scale IT systems listed in Annex X and placed on the market before 2 August 2027 must be brought into compliance by 31 December 2030.
Source: EUR-Lex — Regulation (EU) 2024/1689 (Artificial Intelligence Act), Official Journal · verified 2026-08-07
Note: Article 111 read verbatim. These transitions are the reason an organisation can be lawfully operating non-conforming AI today and still face a hard compliance date. AMENDED: the 2 August 2026 pivot date for high-risk systems was moved by Regulation (EU) 2026/1744; read alongside the Digital Omnibus entry before applying these transitions to a client estate.
Article 113 provides that the Regulation applies from 2 August 2026, with three exceptions: Chapters I and II (general provisions and prohibited AI practices) applied from 2 February 2025; Chapter III Section 4, Chapter V, Chapter VII, Chapter XII and Article 78 (notifying authorities, general-purpose AI models, governance, penalties and confidentiality) applied from 2 August 2025, with the exception of Article 101; and Article 6(1), covering high-risk classification for AI as a safety component of products already regulated under Union law, applies from 2 August 2027.
Source: EUR-Lex — Regulation (EU) 2024/1689 (Artificial Intelligence Act), Official Journal · verified 2026-08-07
Note: Article 113 read verbatim from the Official Journal text. The Regulation was done at Brussels on 13 June 2024 and entered into force on the twentieth day following publication. AMENDED: Regulation (EU) 2026/1744 (in force 27 July 2026) postponed the Annex III high-risk obligations to 2 December 2027 and the Annex I embedded-product obligations to 2 August 2028. This entry records Article 113 as originally enacted and must not be read on its own as the current position.
Regulation (EU) 2026/1744 of 8 July 2026 (the Digital Omnibus on AI) amends Regulation (EU) 2024/1689 and was published in the Official Journal on 24 July 2026, entering into force on 27 July 2026. It postpones the obligations for high-risk AI systems designated under Article 6(2) and Annex III from 2 August 2026 to 2 December 2027, and for AI embedded in products regulated under Annex I sectoral legislation to 2 August 2028. It also adds prohibitions to Article 5 covering AI that generates or manipulates realistic non-consensual intimate imagery of identifiable individuals. The Article 50 transparency duties applying from 2 August 2026 are unaffected.
Source: Regulation (EU) 2026/1744 (Digital Omnibus on AI) - EUR-Lex · verified 2026-08-07
Note: EUR-Lex returned an empty document to automated retrieval, so the amended dates are corroborated across multiple independent legal analyses rather than read from the primary text. The regulation number, adoption date, OJ publication date and entry into force are consistent across every source checked. Confirm article-level wording against the Official Journal before relying on this in a deliverable. The staggered application dates were subsequently amended by Regulation (EU) 2026/1744 (Digital Omnibus on AI); GPAI obligations themselves were not postponed.
Control 2.3 System Hardening now names Windows Management Instrumentation and PowerShell as native OS features to consider when shielding a Windows system. Control 2.9 Transaction Business Controls recognises Swift Universal Confirmation as a validation or reconciliation option alongside MT 900/910 and MT 940/950. Control 4.2 requires multi-factor authentication on one authentication stage for external privileged access managing firewalls, and Alliance Left and Right Security Officer accounts are now named as privileged accounts. Control 6.1 Malware Protection advises protecting non-Windows systems inside a secure zone or hosting a customer client connector. Control 7.2 Security Training and Awareness adds deepfakes as an example of AI-based threats.
Source: Swift — Customer Security Controls Framework v2026, Detailed Description (1 July 2025) · verified 2026-08-11
Note: Swift states that at publication there is no specific guidance on using AI-based tools to support CSP controls, and that the same care applies to any tool handling the confidentiality, integrity and availability of processed data. Alliance Access Integration Platform (IPLA) and Swift Integration Layer (SIL) are expected to reach end of life in 2026 but remain in scope until then. Read directly from the document named above. The Swift CSP Document Centre sits behind myswift authentication, so the citation points at the document centre rather than a file URL.
CSCF v2025 introduced the customer client connector — an endpoint consuming APIs, a middleware or a file transfer client — as an advisory in-scope component. In v2026 it becomes a mandatory in-scope component of fourteen basic cyber-hygiene controls: 1.2, 1.3, 1.4, 2.2, 2.3, 2.6, 2.7, 3.1, 4.1, 4.2, 5.1, 5.4, 6.1 and 6.4. All user endpoints that connect to Swift indirectly through a service provider sharing resources are progressively treated as customer connectors, whether server or client.
Source: Swift — Customer Security Controls Framework v2026, Detailed Description (1 July 2025) · verified 2026-08-11
Note: The document states the consequence plainly: this change “requires some users who previously attested as Architecture type B, to attest as A4 when using a customer client connector.” Architecture B is the narrowest scope and A4 is materially wider, so affected users face a larger assessment this cycle. Read directly from the document named above. The Swift CSP Document Centre sits behind myswift authentication, so the citation points at the document centre rather than a file URL.
As announced in the previous version, control 2.4 Back Office Data Flow Security is mandatory in CSCF v2026, activating the phased approach in Appendix H. At minimum a user must now protect the bridging servers guarding flows between its secure zone and the back-office first hops where the exchange is not end-to-end protected, the flows between bridging servers and between bridging servers and the secure zone in the same circumstances, and the new direct flows between the secure zone and the back-office first hop.
Source: Swift — Customer Security Controls Framework v2026, Detailed Description (1 July 2025) · verified 2026-08-11
Note: Security of the legacy direct exchanges — between back-office first hops and bridging servers, or between first hops and the secure zone — remains advisory, with 2028 given as the tentative date for making those flows mandatory and completing control 2.4’s journey. Read directly from the document named above. The Swift CSP Document Centre sits behind myswift authentication, so the citation points at the document centre rather than a file URL.
Swift users must attest their compliance through the KYC Security Attestation (KYC-SA) application by the end of each year, against the CSCF in effect at that time. A new CSCF version is published each July and becomes the attestation basis from July of the following year. The document states the position for this cycle directly: users must attest between July 2026 and December 2026 against the controls listed in CSCF v2026, which was published in mid-2025.
Source: Swift — Customer Security Controls Framework v2026, Detailed Description (1 July 2025) · verified 2026-08-11
Note: The v2026 attestation window is therefore open now and closes at the end of December 2026. Users control their own attestation data and may grant counterparties access to view it, which is what makes a weak attestation a commercial problem and not only a compliance one. Read directly from the document named above. The Swift CSP Document Centre sits behind myswift authentication, so the citation points at the document centre rather than a file URL.
IRDAI issued Version 2.0 of its Information and Cyber Security Guidelines in April 2026, replacing the Information and Cyber Security Guidelines, 2023 dated 24 April 2023. They apply to all Insurers including Foreign Re-Insurance Branches (FRBs) and Insurance Intermediaries regulated by IRDAI, and to all data created, received or maintained by Regulated Entities in any form. Insurance Agents, Micro-Insurance Agents, Point of Sale Persons and Individual Surveyors are expressly outside their purview, though Insurers remain responsible for ensuring those entities follow a minimum security framework under the Insurer’s Board-approved policy.
Source: IRDAI - Information and Cybersecurity Guidelines, 2026 (official document portal) · verified 2026-08-07
Note: Read from the guidelines document itself (VER 2.0, April 2026, 175 pages) rather than from secondary analyses. The covering circular reference number does not appear in the guidelines body and remains unconfirmed, so it is still not cited. An earlier version of this entry listed brokers, corporate agents, web aggregators, TPAs, ISNPs and IIB as in-scope; that enumeration came from secondary summaries and is not how the guidelines define scope.
Certification under these guidelines may not rest on management representation or on reliance upon the work of other auditors, because the auditor is appointed by regulated entities that must protect policyholder and public data. The auditor is required to perform the work through interviews, document verification, compliance checks and adequate testing of controls.
Source: IRDAI Information and Cybersecurity Guidelines, 2026 — Annexure IV clause 3 · verified 2026-08-08
Note: Read from the guidelines document itself (VER 2.0, April 2026, 175 pages) rather than from secondary analyses. The covering circular reference number does not appear in the guidelines body and remains unconfirmed, so it is still not cited.
Insurers must submit the Audit Report (Annexure III), signed by the auditor and accompanied by the comments of the Board, to IRDAI within 90 days from the end of the financial year OR within 30 days of completion of the audit, whichever is earlier. Foreign Reinsurance Branches whose IT systems interface with overseas parent companies must comply and have the auditor certify per Annexure VI, submitted at the end of every financial year.
Source: IRDAI Information and Cybersecurity Guidelines, 2026 — clause on audit submission · verified 2026-08-08
Note: Read from the guidelines document itself (VER 2.0, April 2026, 175 pages) rather than from secondary analyses. The covering circular reference number does not appear in the guidelines body and remains unconfirmed, so it is still not cited. The “whichever is earlier” limb is the one commonly missed: completing an audit early shortens the deadline rather than extending it.
Annexure IV sets two alternative routes. Either a Chartered Accountant firm registered with ICAI (partnership or LLP) with at least five years of continuous practice and four partners, including one CISA/DISA holder, one ICAI Fellow, one with three years of cyber or information security audit experience in insurance companies, banks or mutual funds, and one with IT-environment and remote-audit experience — OR, in the guidelines’ own words, a “Cert-In empanelled external systems Auditor holding CISA / DISA certifications”. The auditor must not have been debarred or declared ineligible for corrupt or fraudulent practices by the Government of India, a State Government, IRDAI, SEBI, RBI, ICAI, CERT-In or SFIO.
Source: IRDAI Information and Cybersecurity Guidelines, 2026 — Annexure IV · verified 2026-08-08
Note: Read from the guidelines document itself (VER 2.0, April 2026, 175 pages) rather than from secondary analyses. The covering circular reference number does not appear in the guidelines body and remains unconfirmed, so it is still not cited. CyberSigma qualifies under the second route as a CERT-In empanelled auditor, without needing to meet the four-partner CA-firm test.
Provisions constituting and empowering the Data Protection Board (ss.18–26), definitions, and procedural rules took effect on 13 November 2025.
Source: DPDP Rules 2025 (phased commencement) · verified 2026-08-01
Digital Personal Data Protection Rules, 2025 notified 13 November 2025 as G.S.R. 843(E), Gazette of India Extraordinary Part II s.3(i).
Source: MeitY / PIB — DPDP Rules 2025 · verified 2026-08-01
Note: Gazette date corroborated across multiple law-firm analyses; the PIB document filename carries the press-release date (17 Nov), not the notification date.
The CMMC Program rule (32 CFR Part 170) was published 15 October 2024 and took effect 16 December 2024. The acquisition rule (48 CFR) took effect 10 November 2025, starting a phased rollout that adds CMMC requirements to DoD contracts in four annual phases.
Source: US Federal Register — CMMC Program rule (32 CFR 170) · verified 2026-08-01
Note: 48 CFR effective date corroborated across defence-contracting counsel and assessor publications.
CMMC requirements enter DoD contracts through the DFARS acquisition rule (48 CFR) on a phased schedule. Phase 1 began 10 November 2025, with Level 1 and Level 2 self-assessment requirements appearing in select solicitations at the CMMC Program Office's discretion. From 10 November 2026, CMMC Level 2 certification (C3PAO-assessed) is added to new and renewing contracts involving CUI, with further phases extending coverage over the following period.
Source: CMMC Program - 32 CFR Part 170 and the DFARS 48 CFR acquisition rule (eCFR) · verified 2026-08-11
Note: Phase dates current as of 11 August 2026; DoD has adjusted this timeline before.
The IAF three-year transition window for ISO/IEC 27001:2013 certificates ended 31 October 2025 — certificates not transitioned to the 2022 revision by that date lapsed.
Source: ISO/IEC 27001 (iso.org) · verified 2026-08-11
Note: Deadline corroborated across accredited certification bodies (BSI, SGS, LRQA); iso.org blocks automated verification.
SEBI issued the Cybersecurity and Cyber Resilience Framework vide circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113 dated 20 August 2024 (Version 1.0, 205 pages). The compliance timeline was extended twice: circular 2025/45 of 28 March 2025 moved it by three months to 30 June 2025, and circular 2025/96 of 30 June 2025 moved it by a further two months to 31 August 2025. Both extensions applied to all regulated entities except Market Infrastructure Institutions (MIIs), KYC Registration Agencies (KRAs) and Qualified Registrars to an Issue and Share Transfer Agents (QRTAs), which stayed on the original timeline. That final date has passed, so CSCRF is fully in force.
Source: SEBI — extension circular 2025/96 (official PDF, 30 June 2025) · verified 2026-08-04
Note: Upgraded to a primary source: this entry previously rested on the June 2025 FAQ plus independent legal analyses. The extension chain has now been read directly from the SEBI circulars themselves. The most recent CSCRF amendment is circular 2025/119 of 28 August 2025; no later CSCRF circular has issued as at 2026-08-04.
Circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2025/119 dated 28 August 2025 issues technical clarifications in four parts: Part A, principles for REs under multiple regulators' purview, introducing a Principle of Exclusivity and a Principle of Equivalence so an RE regulated by both SEBI and (for example) RBI can demonstrate compliance without duplicating work; Part B, technical clarifications; Part C, re-categorisation of Portfolio Managers and Merchant Bankers; and Part D, Cyber Security Audit Policy Guidelines from CERT-In.
Source: SEBI — technical clarifications circular 2025/119 (official PDF, 28 August 2025) · verified 2026-08-04
Note: This is the most recent CSCRF circular as at 2026-08-04.
Infringement of the Article 5 prohibited-practices rules is subject to administrative fines of up to EUR 35 000 000 or 7 % of total worldwide annual turnover for the preceding financial year, whichever is higher. Breach of most other operator obligations attracts up to EUR 15 000 000 or 3 %. Supplying incorrect, incomplete or misleading information to notified bodies or national authorities attracts up to EUR 7 500 000 or 1 %. For SMEs including start-ups, each ceiling is the lower rather than the higher of the two figures.
Source: EUR-Lex — Regulation (EU) 2024/1689 (Artificial Intelligence Act), Official Journal · verified 2026-08-04
Note: Article 99. Penalties applied from 2 August 2025 under Article 113(b); Member States set the detailed rules and notify the Commission.
Regulation (EU) 2024/1689 entered into force on 1 August 2024. Governance rules and obligations for general-purpose AI (GPAI) model providers apply from 2 August 2025 (with transition for models already on the market).
Source: EU AI Act — official text (EUR-Lex 2024/1689) · verified 2026-08-07
Each user must identify which of five reference architecture types most closely matches its deployment, because scope and applicable controls follow from that choice. The types are A1 (user owns the communication interface, and generally the messaging interface), A2, A3, A4 and B. Component or licence ownership is the key differentiator, and where more than one could apply the most comprehensive architecture must be chosen. Swift publishes a CSP architecture decision tree to support the determination.
Source: Swift — Customer Security Controls Framework v2026, Detailed Description (1 July 2025) · verified 2026-08-11
Note: Users owning only a communication interface and no messaging interface still fall under A1. Read directly from the document named above. The Swift CSP Document Centre sits behind myswift authentication, so the citation points at the document centre rather than a file URL.
The framework sets out 32 security controls, of which 26 are mandatory and 6 advisory, resting on three overarching objectives supported by seven security principles. Mandatory controls establish a security baseline for the entire Swift user community; advisory controls are optional best practices Swift recommends. The six advisory controls are 2.5A External Transmission Data Protection, 2.11A RMA Business Controls, 5.3A Staff Screening Process, 6.5A Intrusion Detection, 7.3A Penetration Testing and 7.4A Scenario-based Risk Assessment.
Source: Swift — Customer Security Controls Framework v2026, Detailed Description (1 July 2025) · verified 2026-08-11
Note: The 26/6 split is stated in the document and independently confirmed by counting control identifiers: 32 unique IDs, of which 6 carry the A suffix denoting advisory. Read directly from the document named above. The Swift CSP Document Centre sits behind myswift authentication, so the citation points at the document centre rather than a file URL.
OWASP Application Security Verification Standard v5.0.0 (May 2025): ~350 requirements across 17 chapters, three verification levels (L1–L3).
Source: OWASP ASVS project · verified 2026-08-01
SAQ A covers e-commerce or mail/telephone-order merchants who outsource all processing of account data to PCI DSS compliant third parties, store, process and transmit no account data electronically on their own systems or premises, have confirmed those third parties are compliant for the services used, and retain any account data only on paper not received electronically. E-commerce merchants must additionally confirm that every element of the payment page delivered to the customer’s browser originates only and directly from a compliant third-party processor, and that their site is not susceptible to script-based attacks affecting their e-commerce systems. SAQ A does not apply to face-to-face channels or to service providers.
Source: PCI SSC — SAQ Instructions and Guidelines, v4.0.1 r1 (April 2025) · verified 2026-08-04
Note: The two e-commerce criteria were ADDED by revision r1 in April 2025 — the document’s revision history records them as new eligibility criteria, not a clarification. A merchant that qualified for SAQ A before April 2025 may no longer qualify. Read directly from the document named above. PCI SSC distributes it under a licence acceptance that blocks automated retrieval, so the citation points at the document library.
PCI DSS v3.2.1 retired 31 March 2024. v4.0.1 (a limited revision — no requirements added or removed) was published 11 June 2024, and v4.0 retired 31 December 2024, leaving v4.0.1 the only active version. The 51 future-dated v4.x requirements became mandatory in assessments from 31 March 2025.
Source: PCI Security Standards Council (official blog) · verified 2026-08-01
OWASP ASVS 5.0 reorganises its requirements into 17 chapters (V1-V17): V1 Encoding and Sanitization, V2 Validation and Business Logic, V3 Web Frontend Security, V4 API and Web Service, V5 File Handling, V6 Authentication, V7 Session Management, V8 Authorization, V9 Self-contained Tokens, V10 OAuth and OIDC, V11 Cryptography, V12 Secure Communication, V13 Configuration, V14 Data Protection, V15 Secure Coding and Architecture, V16 Security Logging and Error Handling, V17 WebRTC. This is a substantial restructure from the v4.0.x chapter layout - a mapping is needed when moving an assessment from 4.0 to 5.0.
Source: OWASP Application Security Verification Standard 5.0 repository (CC BY-SA) · verified 2026-08-11
CMMC applies to DoD contractors and subcontractors across the Defense Industrial Base that process, store or transmit Federal Contract Information (FCI) or Controlled Unclassified Information (CUI). The required level flows down through the supply chain by the nature of the information handled: FCI-only work maps to Level 1, CUI to Level 2, and the most sensitive CUI to Level 3. An affirming senior official must attest to compliance in SPRS, and assessments carry a validity period (self-assessments affirmed annually; C3PAO certifications on a three-year cycle).
Source: 32 CFR Part 170 - CMMC Program scope and assessment (eCFR) · verified 2026-08-11
The Cybersecurity Maturity Model Certification (CMMC) Program final rule is codified at 32 CFR Part 170 and took effect on 16 December 2024. It defines three levels: Level 1 (Foundational) - 17 practices protecting Federal Contract Information (FCI), verified by annual self-assessment; Level 2 (Advanced) - the 110 security requirements of NIST SP 800-171 Revision 2, protecting Controlled Unclassified Information (CUI), most requiring a third-party assessment by a Certified Third-Party Assessment Organization (C3PAO); Level 3 (Expert) - Level 2 plus a subset of NIST SP 800-172 requirements for the highest-value CUI, assessed by the Defense Industrial Base Cybersecurity Assessment Center (DIBCAC).
Source: 32 CFR Part 170 - CMMC Program (eCFR) · verified 2026-08-11
Note: Level/assessment structure current-verified 11 August 2026; CMMC rule timelines have shifted repeatedly, so re-check against 32 CFR Part 170 before relying on dates.
The Cyber Capability Index (CCI) applies only to MIIs and Qualified REs. MIIs must have their cyber resilience assessed against the CCI by a third party on a half-yearly basis; Qualified REs self-assess their cyber resilience using the CCI on a yearly basis.
Source: SEBI — CSCRF circular 2024/113 (official PDF, 20 August 2024) · verified 2026-08-04
Note: Page 14 of 205; the index itself is set out at Annexure-K, page 163.
CSCRF mandates a SOC for all REs except client-based stock brokers with fewer than 100 clients. An RE may use its own or group SOC, any third-party managed SOC, or the Market SOC. Small-size and Self-certification category REs are required to onboard the Market SOC, which NSE and BSE must set up and which NSDL and/or CDSL may set up optionally.
Source: SEBI — CSCRF circular 2024/113 (official PDF, 20 August 2024) · verified 2026-08-04
Note: Box Item 11, page 69. For small- and mid-size REs the Market SOC is also to provide VAPT and cyber audit services.
The VAPT report must be submitted within one month of completing the VAPT activity, after approval from the RE's IT Committee. Findings must be closed within three months of report submission, following a graded approach based on the criticality of the observations. Revalidation of the VAPT must be completed within five months of its completion.
Source: SEBI — CSCRF circular 2024/113 (official PDF, 20 August 2024) · verified 2026-08-04
Note: Table 19, page 49. Vulnerabilities still open after three months require IT Committee approval and must be closed before the next VAPT exercise begins.
REs identified as “Protected systems” and/or Critical Information Infrastructure by NCIIPC must complete at least two VAPT activities each year — one in each half of the financial year (April to September, October to March), each including report submission, closure and revalidation. All other REs must complete at least one, with the activity commencing in the first quarter of the financial year.
Source: SEBI — CSCRF circular 2024/113 (official PDF, 20 August 2024) · verified 2026-08-04
Note: Table 18, page 48. REs must plan VAPT at the start of the financial year, and no audit cycle may be left unaudited because of a change in category.
The framework states: “Unless otherwise specified, all audits mentioned in CSCRF have to be conducted by CERT-In empanelled IS auditing organization.” The same requirement is restated for the VAPT and cyber audit that the Market SOC is to provide to small- and mid-size REs at affordable cost.
Source: SEBI — CSCRF circular 2024/113 (official PDF, 20 August 2024) · verified 2026-08-04
Note: Quoted verbatim from footnote 16, page 48 of 205.
CSCRF applies proportionately by category: (i) Market Infrastructure Institutions (MIIs), (ii) Qualified REs, (iii) Mid-size REs, (iv) Small-size REs and (v) Self-certification REs. Entity-wise thresholds that determine which category an RE falls into are set out in the framework's “Thresholds for REs’ categorization” section.
Source: SEBI — CSCRF circular 2024/113 (official PDF, 20 August 2024) · verified 2026-08-04
Note: Portfolio Managers and Merchant Bankers were re-categorised by circular 2025/119 of 28 August 2025 (Part C).
Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices (RBI/DoS/2023-24/107) issued 7 November 2023; effective 1 April 2024. Requires an IT governance framework, information/cyber security policies and periodic IT risk assurance for regulated entities.
Source: Reserve Bank of India (Master Direction RBI/DoS/2023-24/107) · verified 2026-08-01
Note: Direction number cited for retrieval via RBI notification search; RBI deep links are session-bound.
NIST states that the CSF “offers a taxonomy of high-level cybersecurity outcomes that can be used by any organization — regardless of its size, sector, or maturity”, and that it “does not prescribe how outcomes should be achieved”, instead linking to online resources describing practices and controls. This is why the CSF is not certifiable and why an organisation cannot be audited as “CSF compliant” the way it can against ISO/IEC 27001 or PCI DSS.
Source: NIST — Cybersecurity Framework (CSF) 2.0, NIST CSWP 29 · verified 2026-08-04
Note: Quoted from the Abstract of NIST CSWP 29.
The framework defines four Tiers, quoted from the document: “Partial (Tier 1), Risk Informed (Tier 2), Repeatable (Tier 3), and Adaptive (Tier 4).” Tiers characterise the rigour of an organisation’s cybersecurity risk governance and management practices; they are not maturity levels and reaching Tier 4 is not a goal for every organisation.
Source: NIST — Cybersecurity Framework (CSF) 2.0, NIST CSWP 29 · verified 2026-08-04
Note: Tier names quoted verbatim from NIST CSWP 29.
Beneath the six Functions, the CSF 2.0 Core is organised into 22 Categories and 106 Subcategories. Subcategories state outcomes, not controls, and are the level at which an organisation assesses and communicates its current and target state.
Source: NIST — Cybersecurity Framework (CSF) 2.0, NIST CSWP 29 · verified 2026-08-04
Note: Counted from the unique Category and Subcategory identifiers (for example GV.OC, GV.OC-01) appearing in NIST CSWP 29 itself.
CSF 2.0 organises cybersecurity outcomes under six Functions: GOVERN (GV), IDENTIFY (ID), PROTECT (PR), DETECT (DE), RESPOND (RS) and RECOVER (RC). GOVERN is new in 2.0 and covers how an organisation establishes and monitors its cybersecurity risk management strategy, expectations and policy.
Source: NIST — Cybersecurity Framework (CSF) 2.0, NIST CSWP 29 · verified 2026-08-04
Note: Function identifiers counted directly in NIST CSWP 29.
NIST released Cybersecurity Framework 2.0 on 26 February 2024 — the first major revision since 2014, adding the Govern function and broadening applicability beyond critical infrastructure.
Source: NIST (official release announcement) · verified 2026-08-01
ISO published ISO 22301:2019/Amd 1:2024 in February 2024, adding consideration of climate change to the management system requirements. ISO 22301:2019 remains the current edition - the amendment supplements it rather than replacing it, and a next edition is in development with no confirmed publication date.
Source: ISO 22301:2019/Amd 1:2024 (iso.org) · verified 2026-08-07
Note: iso.org blocks automated verification; the amendment number, scope and date are corroborated across certification bodies and ISO's own catalogue listing.
Under Article 10(3) of the NCA Statute and High Order No. 57231 (10/11/1439H), in-scope entities must ensure ongoing continuous compliance with the ECC. The NCA evaluates compliance through self-assessments, periodic reports of its compliance tool, and/or field auditing visits, and issues an ECC-2:2024 Assessment and Compliance Tool to organise assessment. Controls under Subdomain 4-2 (Cloud Computing and Hosting Cybersecurity) are binding on entities currently using or planning to use cloud computing and hosting services.
Source: NCA - Essential Cybersecurity Controls ECC - 2 : 2024 (English), Implementation and Compliance section · verified 2026-08-11
Note: Read from the official ECC-2:2024 document (classification Public, TLP:White) on 11 August 2026.
Saudi Arabia's National Cybersecurity Authority first issued the Essential Cybersecurity Controls as ECC-1:2018. ECC-2:2024 consists of 4 cybersecurity main domains (Cybersecurity Governance, Cybersecurity Defense, Cybersecurity Resilience, and Third-Party & Cloud Computing Cybersecurity), 28 subdomains, 108 main controls and 92 subcontrols. The Controls apply to government agencies in the Kingdom (including ministries, authorities and establishments) and their affiliated companies and entities inside and outside the Kingdom, and to all private-sector entities owning, operating or hosting Critical National Infrastructure; each entity must comply with all controls applicable to it.
Source: NCA — Essential Cybersecurity Controls ECC – 2 : 2024 (English) · verified 2026-08-11
Note: Counts and scope read directly from the ECC – 2 : 2024 document. NCA's canonical index sits at nca.gov.sa/en/regulatory-documents/controls-list/ecc/, which is unreachable from outside the region; this CDN copy is NCA's own published file and does resolve. Compliance is mandated by Article 10(3) of the NCA Statute and High Order No. 57231 dated 10/11/1439H.
ECC-2:2024 decodes as Essential Cybersecurity Controls, version 2, year of issuance 2024. Individual control codes are four-part: Main-domain . Subdomain . Main-control . Sub-control (for example 2-3-2-6). The methodological structure gives each subdomain an objective and a set of numbered control clauses.
Source: NCA - ECC-2:2024 (English), Figures 3-4 and Table 1 · verified 2026-08-11
Under Cybersecurity Governance, ECC-2:2024 requires that a cybersecurity department be established that is INDEPENDENT of the IT/Communications department (control 1-2-1, per High Order No. 37140 dated 14/08/1438H), reporting to the head of the entity or their delegate; that ALL cybersecurity positions be filled with full-time, qualified SAUDI cybersecurity professionals (control 1-2-2); and that a cybersecurity supervisory committee be established (control 1-2-3). The cybersecurity strategy must be documented and approved by the Authorized Official and reviewed at planned intervals (subdomain 1-1).
Source: NCA - ECC-2:2024 (English), Cybersecurity Governance controls 1-1 and 1-2 · verified 2026-08-11
Note: The Saudi-nationals staffing requirement is a distinctive ECC obligation with direct bearing on how a foreign firm supports a Saudi engagement. Read from the document 11 August 2026.
ECC-2:2024 organises its controls under 4 main domains and 28 subdomains: (1) Cybersecurity Governance - 10 subdomains (Strategy; Management; Policies and Procedures; Roles and Responsibilities; Risk Management; Cybersecurity in IT Project Management; Compliance with Standards, Laws and Regulations; Periodical Review and Audit; Cybersecurity in Human Resources; Awareness and Training Program). (2) Cybersecurity Defense - 15 subdomains (Asset Management; Identity and Access Management; Information Systems and Information Processing Facilities Protection; Email Protection; Network Security Management; Mobile Devices Security; Data and Information Protection; Cryptography; Backup and Recovery Management; Vulnerability Management; Penetration Testing; Cybersecurity Event Logs and Monitoring Management; Cybersecurity Incident and Threat Management; Physical Security; Web Application Security). (3) Cybersecurity Resilience - 1 subdomain (Resilience Aspects of Business Continuity Management). (4) Third-Party and Cloud Computing Cybersecurity - 2 subdomains (Third-Party Cybersecurity; Cloud Computing and Hosting Cybersecurity).
Source: NCA - Essential Cybersecurity Controls ECC - 2 : 2024 (English), Figures 1-2 · verified 2026-08-11
Note: Read from the official ECC-2:2024 document (Public, TLP:White) on 11 August 2026; subdomain counts (10+15+1+2) sum to the stated 28.
ISO/IEC 42001:2023 — the first AI management system (AIMS) standard — was published in December 2023 by ISO/IEC.
Source: ISO/IEC 42001 (iso.org) · verified 2026-08-11
Note: iso.org blocks automated verification; publication corroborated across accredited bodies and major assurance firms.
Master Direction on Outsourcing of Information Technology Services (RBI/2023-24/102) issued 10 April 2023; effective 1 October 2023. Governs material IT outsourcing by regulated entities, including vendor risk, audit rights and concentration risk.
Source: Reserve Bank of India (Master Direction RBI/2023-24/102) · verified 2026-08-01
Note: Direction number cited for retrieval via RBI notification search.
Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023); Presidential assent 11 August 2023; Gazette ID CG-DL-E-12082023-248045.
Source: Official Gazette text (MeitY PDF) · verified 2026-07-31
Qatar's National Cyber Security Agency mandates the National Information Assurance Policy for government entities and critical infrastructure; the current revision is v2.1 (May 2023), superseding v2.0.
Source: NCSA Qatar (official portal) · verified 2026-08-01
Note: Version and date corroborated across Qatar-focused GRC publishers; the NCSA portal hosts the controlled document.
IRDAI issued the Information and Cyber Security Guidelines, 2023 on 24 April 2023 (ref IRDAI/GA&HR/GDL/MISC/88/04/2023), superseding the 2017 guidelines (IRDA/IT/GDL/MISC/082/04/2017) and three subsequent circulars. These were themselves superseded on 6 April 2026 by the IRDAI Information and Cybersecurity Guidelines, 2026 (Version 2.0) - the 2023 text is retained here as the previous baseline, not as the current requirement.
Source: IRDAI - Information and Cyber Security Guidelines, 2023 (official document portal) · verified 2026-08-07
The current edition is ISO/IEC 27001:2022, the third edition, published October 2022, titled “Information security, cybersecurity and privacy protection — Information security management systems — Requirements”. It specifies requirements for establishing, implementing, maintaining and continually improving an information security management system, and is the standard against which organisations are certified.
Source: ISO — ISO/IEC 27001:2022 catalogue entry · verified 2026-08-08
Note: Bibliographic identity only — title, edition and publication date. The standard is copyright-protected and its terms forbid reproduction or utilisation without permission, so no clause structure, Annex A control counts or requirement text are recorded here. Deeper coverage requires a copy licensed to CyberSigma; a copy licensed to another organisation is not a basis for a public registry. iso.org also returns HTTP 403 to automated retrieval.
Data centres, VPS, cloud and VPN providers must register and retain accurate subscriber/customer records for 5 years after cancellation or withdrawal of service.
Source: CERT-In Directions (official PDF) · verified 2026-07-31
System clocks must be synchronised to NIC or NPL time sources.
Source: CERT-In Directions (official PDF) · verified 2026-07-31
ICT system logs must be maintained for a rolling 180 days, within Indian jurisdiction.
Source: CERT-In Directions (official PDF) · verified 2026-07-31
Specified cyber incidents must be reported to CERT-In within 6 hours of noticing.
Source: CERT-In Directions (official PDF) · verified 2026-07-31
Directions under Section 70B(6), IT Act 2000 issued 28 April 2022; effective 28 June 2022. Apply to service providers, intermediaries, data centres, body corporates and government organisations.
Source: CERT-In Directions (official PDF) · verified 2026-07-31
UAE Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data was issued on 20 September 2021, published in Official Gazette No. 712 (supplement) on 26 September 2021, and came into effect on 2 January 2022; the legislation portal lists it as Active. The DIFC and ADGM financial free zones run their own data-protection regimes in place of the federal law.
Source: UAE Legislation portal - Federal Decree-Law on Protection of Personal Data (official) · verified 2026-08-11
Note: OPEN QUESTION - do not treat as settled. Multiple secondary sources report that the Executive Regulations to Federal Decree-Law 45/2021 have been issued, which would activate full enforcement, but they conflict on the instrument and date (one cites Cabinet Decision No. 33 of 2024, others simply say 2026) and none cite a Cabinet Decision number against a primary UAE government source. Not recorded as fact until confirmed from the official gazette or the UAE Data Office.
Federal Decree-Law 45/2021 requires controllers and processors to meet general obligations (Articles 7-8), report personal data breaches (Article 9), appoint a Data Protection Officer with defined roles (Articles 10-12), honour data-subject rights to information, portability, correction/erasure, restriction and objection (Articles 13-18), secure personal data (Article 20), run data protection impact assessments (Article 21) and control cross-border transfer and sharing (Articles 22-23).
Source: UAE Legislation portal - Federal Decree-Law on Protection of Personal Data (official) · verified 2026-08-11
Note: Article map read from the official portal's English index on 11 August 2026. The portal's own disclaimer states the Arabic text prevails for interpretation; clause-level wording should be checked against the Arabic original.
The law provides an enforcement structure: data subjects may file complaints with the UAE Data Office (Article 24), grievances against the Office's decisions are provided for (Article 25), and administrative penalties for violations are established (Article 26). Article 28 provides for an Executive Regulation to be issued to detail the law's implementation. The Decree-Law thus contemplates its own detailed regulations - whether that Executive Regulation has yet been issued is tracked separately and remains unresolved in public sources.
Source: UAE Legislation portal - Federal Decree-Law 45/2021, Articles 24-28 (official) · verified 2026-08-11
Note: Article index read from the official portal 11 August 2026. This entry records that Article 28 PROVIDES FOR an Executive Regulation; it does NOT assert that the Regulation has been issued - that is the open question tracked on the uae-pdpl entry.
Federal Decree-Law 45/2021 makes consent the default basis for processing personal data, and Article 4 sets out the cases where personal data may be processed WITHOUT the owner's consent (including where necessary to protect the public interest, for legal proceedings, to protect the data subject's interests, or for the controller's legitimate purposes without prejudice to the data subject's rights). Article 5 fixes the personal-data processing controls (fair, transparent and lawful processing; specified purpose; accuracy; minimisation; and secure retention), and Article 6 sets the terms a valid consent must meet.
Source: UAE Legislation portal - Federal Decree-Law 45/2021, Articles 4-6 (official) · verified 2026-08-11
Note: Article structure read from the official portal index 11 August 2026; the portal states the Arabic text prevails for interpretation, so clause-level conditions should be checked against the Arabic.
The criteria for a SOC 2 examination are set out in TSP Section 100, “2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (With Revised Points of Focus — 2022)”, established by the AICPA’s Assurance Services Executive Committee (ASEC). They cover five categories: Security, Availability, Processing Integrity, Confidentiality and Privacy. The 2022 revision updated the points of focus rather than the criteria themselves, which is why the document is still titled as the 2017 criteria.
Source: AICPA - 2017 Trust Services Criteria (With Revised Points of Focus - 2022) · verified 2026-08-08
Note: Read from TSP Section 100 itself rather than from secondary summaries. The TSP Section 100 numbering, previously omitted because AICPA’s public page did not confirm it, is stated on the document’s own title page.
The common criteria are the criteria shared by all five trust services categories. They comprise 33 individual criteria organised across nine series, CC1 to CC9. Points of focus sit beneath the criteria and describe characteristics that may be considered when evaluating whether a criterion is met; the concept is drawn from COSO’s Internal Control — Integrated Framework, and points of focus are not themselves requirements to be met one by one.
Source: AICPA TSP Section 100 — common criteria and points of focus · verified 2026-08-08
Note: Read from TSP Section 100 itself rather than from secondary summaries. Criterion count derived by enumerating the distinct CC references in the document.
TSP Section 100 paragraph .14 states that the security category “is addressed in most trust services engagements”, and paragraph .15 adds that “although uncommon, there may be circumstances in which the security category is not addressed by a trust services examination”. Where security IS included, ASEC has determined the common criteria alone are suitable and no additional control activity criteria are needed. Where availability, processing integrity, confidentiality or privacy are included, a complete set consists of the common criteria plus the control activity criteria for that category.
Source: AICPA TSP Section 100, paragraphs .14 and .15 · verified 2026-08-08
Note: Read from TSP Section 100 itself rather than from secondary summaries. This corrects a claim repeated almost universally in secondary sources, which state that Security is mandatory in every SOC 2. The criteria say it is addressed in most engagements and expressly contemplate examinations where it is not.
The CKYCR live run began on 15 July 2016, phased, starting with new individual accounts. Scheduled Commercial Banks were required to upload KYC data for all new individual accounts opened on or after 1 January 2017 (with an initial allowance to 1 February 2017 for accounts opened during January 2017). Regulated entities other than SCBs were required to start uploading for new individual accounts opened on or after 1 April 2017. KYC records for accounts of Legal Entities opened on or after 1 April 2021 must also be uploaded.
Source: RBI — Master Direction, Know Your Customer (KYC) Direction, 2016 (updated 14 August 2025) · verified 2026-08-07
Note: The Legal Entity obligation is the most recently added and the one most often missing from older CKYC programmes built around individual onboarding.
Issued 18 February 2021: minimum security standards for digital payment channels — internet banking, mobile payments and card payments — binding scheduled commercial banks, small finance banks, payments banks and card-issuing NBFCs.
Source: Reserve Bank of India (Master Direction, 18 Feb 2021) · verified 2026-08-01
Note: Direction cited by title and date for retrieval via RBI notification search.
SWIFT launched the Customer Security Programme in 2016. Connected organisations attest annually against the Customer Security Controls Framework (CSCF, revised yearly), and from 2021 an independent assessment became mandatory for attestations rather than pure self-attestation.
Source: SWIFT — Customer Security Programme (official) · verified 2026-08-11
ISO 22301:2019 (business continuity management systems) was published 30 October 2019, replacing the 2012 first edition.
Source: ISO 22301:2019 (iso.org) · verified 2026-08-11
Note: iso.org blocks automated verification; date corroborated across certification bodies.
RBI circular DPSS.CO.OD No.2785/06.08.005/2017-2018 (6 April 2018) requires payment system providers to store the entire data relating to their payment systems only in India, with compliance within six months (by October 2018). End-to-end transaction data is covered.
Source: Reserve Bank of India (circular DPSS.CO.OD No.2785/06.08.005/2017-2018) · verified 2026-08-01
Note: Circular number cited for retrieval via RBI's notification search; we deliberately avoid deep-linking RBI's session-bound URLs.
The lower tier is up to 10 000 000 EUR or, for an undertaking, up to 2 % of total worldwide annual turnover of the preceding financial year, whichever is higher — covering obligations of controllers and processors such as security of processing, records and breach notification. The higher tier is up to 20 000 000 EUR or 4 % of total worldwide annual turnover, whichever is higher — covering the basic principles for processing, conditions for consent, data-subject rights, and transfers to third countries.
Source: EUR-Lex — Regulation (EU) 2016/679 (GDPR), consolidated text · verified 2026-08-04
Note: Article 83(4) and 83(5). “Undertaking” is read in the competition-law sense, so turnover can be assessed across a corporate group rather than the single legal entity fined.
A controller must notify a personal data breach to the supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of it, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where notification is not made within 72 hours it must be accompanied by reasons for the delay.
Source: EUR-Lex — Regulation (EU) 2016/679 (GDPR), consolidated text · verified 2026-08-04
Note: Article 33, with Recital 85. The 72 hours runs from awareness of the breach, not from its occurrence, and the obligation is qualified by “where feasible” — it is not an absolute deadline.
Regulation (EU) 2016/679 entered into force 24 May 2016 and has applied across all EU member states since 25 May 2018. Breach notification to the supervisory authority is required without undue delay and, where feasible, within 72 hours (Art. 33).
Source: GDPR — official text (EUR-Lex 2016/679) · verified 2026-08-01
GDPR Articles 37-39 require designation of a data protection officer (DPO) where processing is carried out by a public authority, or where the core activities consist of regular and systematic monitoring of data subjects on a large scale, or large-scale processing of special categories of data or criminal-conviction data. The DPO is designated on the basis of professional qualities and expert knowledge of data protection law, must be involved in all data-protection matters, report to the highest management level, and cannot be dismissed or penalised for performing the role.
Source: Regulation (EU) 2016/679 (GDPR), Articles 37-39 - EUR-Lex consolidated text · verified 2026-08-11
GDPR Article 35 requires a data protection impact assessment (DPIA) before processing that is likely to result in a high risk to the rights and freedoms of natural persons - in particular for systematic and extensive automated evaluation (including profiling) with legal or similarly significant effects, large-scale processing of special categories of data, or large-scale systematic monitoring of a publicly accessible area. Where a DPIA indicates high residual risk absent mitigation, Article 36 requires prior consultation with the supervisory authority.
Source: Regulation (EU) 2016/679 (GDPR), Articles 35-36 - EUR-Lex consolidated text · verified 2026-08-11
GDPR Article 30 requires controllers and processors to maintain records of processing activities (RoPA) under their responsibility, including purposes, categories of data subjects and personal data, recipients, third-country transfers, retention time limits and a general description of technical and organisational security measures. The obligation has a limited exemption for organisations under 250 employees, which falls away where processing is not occasional, is likely to result in a risk to rights and freedoms, or involves special-category or criminal-conviction data.
Source: Regulation (EU) 2016/679 (GDPR), Article 30 - EUR-Lex consolidated text · verified 2026-08-11
The Saudi Central Bank (SAMA) issued its Cyber Security Framework v1.0 in May 2017. It applies to all SAMA-regulated Member Organizations — banks, insurance and reinsurance companies, financing companies, credit bureaus and the Financial Market Infrastructure — and is principle-based, drawing on NIST, ISF, ISO, Basel and PCI. Member Organizations are expected to operate at maturity level 3 or higher.
Source: SAMA Rulebook — Cyber Security Framework · verified 2026-08-04
RBI’s Cyber Security Framework in Banks (2 June 2016) requires scheduled commercial banks to report cyber incidents to RBI within 2 to 6 hours of detection, alongside board-approved cyber security policy, SOC capability and cyber crisis management plans.
Source: Reserve Bank of India (notification, 2 June 2016) · verified 2026-08-01
The Master Direction defines the Central KYC Records Registry (CKYCR) as “an entity defined under Rule 2(1) of the Rules, to receive, store, safeguard and retrieve the KYC records in digital form of a customer”. The Central Registry of Securitisation Asset Reconstruction and Security Interest of India (CERSAI) was authorised to act as and perform the functions of the CKYCR by Gazette Notification No. S.O. 3183(E) dated 26 November 2015.
Source: RBI — Master Direction, Know Your Customer (KYC) Direction, 2016 (updated 14 August 2025) · verified 2026-08-07
Note: “the Rules” means the Prevention of Money-Laundering (Maintenance of Records) Rules, 2005.
Compliance with the HIPAA Security Rule was required from 20 April 2005 for most covered entities; small health plans had until 20 April 2006.
Source: US HHS — HIPAA Security Rule · verified 2026-08-11
The verified fact base — 118 entries across 24 frameworks
The registry is the raw material of this report: each entry is one fact, verified against a primary source — the Gazette PDF, the regulator’s portal, the standards body — and stamped with the date it was last checked. Entries are grouped here by framework. Anything you cite from this chapter, you can audit against its source link.
CMMC (US DoD)
The Cybersecurity Maturity Model Certification (CMMC) Program final rule is codified at 32 CFR Part 170 and took effect on 16 December 2024. It defines three levels: Level 1 (Foundational) - 17 practices protecting Federal Contract Information (FCI), verified by annual self-assessment; Level 2 (Advanced) - the 110 security requirements of NIST SP 800-171 Revision 2, protecting Controlled Unclassified Information (CUI), most requiring a third-party assessment by a Certified Third-Party Assessment Organization (C3PAO); Level 3 (Expert) - Level 2 plus a subset of NIST SP 800-172 requirements for the highest-value CUI, assessed by the Defense Industrial Base Cybersecurity Assessment Center (DIBCAC).
Source: 32 CFR Part 170 - CMMC Program (eCFR) · verified 2026-08-11
Note: Level/assessment structure current-verified 11 August 2026; CMMC rule timelines have shifted repeatedly, so re-check against 32 CFR Part 170 before relying on dates.
CMMC requirements enter DoD contracts through the DFARS acquisition rule (48 CFR) on a phased schedule. Phase 1 began 10 November 2025, with Level 1 and Level 2 self-assessment requirements appearing in select solicitations at the CMMC Program Office's discretion. From 10 November 2026, CMMC Level 2 certification (C3PAO-assessed) is added to new and renewing contracts involving CUI, with further phases extending coverage over the following period.
Source: CMMC Program - 32 CFR Part 170 and the DFARS 48 CFR acquisition rule (eCFR) · verified 2026-08-11
Note: Phase dates current as of 11 August 2026; DoD has adjusted this timeline before.
CMMC applies to DoD contractors and subcontractors across the Defense Industrial Base that process, store or transmit Federal Contract Information (FCI) or Controlled Unclassified Information (CUI). The required level flows down through the supply chain by the nature of the information handled: FCI-only work maps to Level 1, CUI to Level 2, and the most sensitive CUI to Level 3. An affirming senior official must attest to compliance in SPRS, and assessments carry a validity period (self-assessments affirmed annually; C3PAO certifications on a three-year cycle).
Source: 32 CFR Part 170 - CMMC Program scope and assessment (eCFR) · verified 2026-08-11
The CMMC Program rule (32 CFR Part 170) was published 15 October 2024 and took effect 16 December 2024. The acquisition rule (48 CFR) took effect 10 November 2025, starting a phased rollout that adds CMMC requirements to DoD contracts in four annual phases.
Source: US Federal Register — CMMC Program rule (32 CFR 170) · verified 2026-08-01
Note: 48 CFR effective date corroborated across defence-contracting counsel and assessor publications.
UAE PDPL
Federal Decree-Law 45/2021 makes consent the default basis for processing personal data, and Article 4 sets out the cases where personal data may be processed WITHOUT the owner's consent (including where necessary to protect the public interest, for legal proceedings, to protect the data subject's interests, or for the controller's legitimate purposes without prejudice to the data subject's rights). Article 5 fixes the personal-data processing controls (fair, transparent and lawful processing; specified purpose; accuracy; minimisation; and secure retention), and Article 6 sets the terms a valid consent must meet.
Source: UAE Legislation portal - Federal Decree-Law 45/2021, Articles 4-6 (official) · verified 2026-08-11
Note: Article structure read from the official portal index 11 August 2026; the portal states the Arabic text prevails for interpretation, so clause-level conditions should be checked against the Arabic.
The law provides an enforcement structure: data subjects may file complaints with the UAE Data Office (Article 24), grievances against the Office's decisions are provided for (Article 25), and administrative penalties for violations are established (Article 26). Article 28 provides for an Executive Regulation to be issued to detail the law's implementation. The Decree-Law thus contemplates its own detailed regulations - whether that Executive Regulation has yet been issued is tracked separately and remains unresolved in public sources.
Source: UAE Legislation portal - Federal Decree-Law 45/2021, Articles 24-28 (official) · verified 2026-08-11
Note: Article index read from the official portal 11 August 2026. This entry records that Article 28 PROVIDES FOR an Executive Regulation; it does NOT assert that the Regulation has been issued - that is the open question tracked on the uae-pdpl entry.
Federal Decree-Law 45/2021 requires controllers and processors to meet general obligations (Articles 7-8), report personal data breaches (Article 9), appoint a Data Protection Officer with defined roles (Articles 10-12), honour data-subject rights to information, portability, correction/erasure, restriction and objection (Articles 13-18), secure personal data (Article 20), run data protection impact assessments (Article 21) and control cross-border transfer and sharing (Articles 22-23).
Source: UAE Legislation portal - Federal Decree-Law on Protection of Personal Data (official) · verified 2026-08-11
Note: Article map read from the official portal's English index on 11 August 2026. The portal's own disclaimer states the Arabic text prevails for interpretation; clause-level wording should be checked against the Arabic original.
UAE Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data was issued on 20 September 2021, published in Official Gazette No. 712 (supplement) on 26 September 2021, and came into effect on 2 January 2022; the legislation portal lists it as Active. The DIFC and ADGM financial free zones run their own data-protection regimes in place of the federal law.
Source: UAE Legislation portal - Federal Decree-Law on Protection of Personal Data (official) · verified 2026-08-11
Note: OPEN QUESTION - do not treat as settled. Multiple secondary sources report that the Executive Regulations to Federal Decree-Law 45/2021 have been issued, which would activate full enforcement, but they conflict on the instrument and date (one cites Cabinet Decision No. 33 of 2024, others simply say 2026) and none cite a Cabinet Decision number against a primary UAE government source. Not recorded as fact until confirmed from the official gazette or the UAE Data Office.
NCA ECC (Saudi Arabia)
ECC-2:2024 organises its controls under 4 main domains and 28 subdomains: (1) Cybersecurity Governance - 10 subdomains (Strategy; Management; Policies and Procedures; Roles and Responsibilities; Risk Management; Cybersecurity in IT Project Management; Compliance with Standards, Laws and Regulations; Periodical Review and Audit; Cybersecurity in Human Resources; Awareness and Training Program). (2) Cybersecurity Defense - 15 subdomains (Asset Management; Identity and Access Management; Information Systems and Information Processing Facilities Protection; Email Protection; Network Security Management; Mobile Devices Security; Data and Information Protection; Cryptography; Backup and Recovery Management; Vulnerability Management; Penetration Testing; Cybersecurity Event Logs and Monitoring Management; Cybersecurity Incident and Threat Management; Physical Security; Web Application Security). (3) Cybersecurity Resilience - 1 subdomain (Resilience Aspects of Business Continuity Management). (4) Third-Party and Cloud Computing Cybersecurity - 2 subdomains (Third-Party Cybersecurity; Cloud Computing and Hosting Cybersecurity).
Source: NCA - Essential Cybersecurity Controls ECC - 2 : 2024 (English), Figures 1-2 · verified 2026-08-11
Note: Read from the official ECC-2:2024 document (Public, TLP:White) on 11 August 2026; subdomain counts (10+15+1+2) sum to the stated 28.
Under Cybersecurity Governance, ECC-2:2024 requires that a cybersecurity department be established that is INDEPENDENT of the IT/Communications department (control 1-2-1, per High Order No. 37140 dated 14/08/1438H), reporting to the head of the entity or their delegate; that ALL cybersecurity positions be filled with full-time, qualified SAUDI cybersecurity professionals (control 1-2-2); and that a cybersecurity supervisory committee be established (control 1-2-3). The cybersecurity strategy must be documented and approved by the Authorized Official and reviewed at planned intervals (subdomain 1-1).
Source: NCA - ECC-2:2024 (English), Cybersecurity Governance controls 1-1 and 1-2 · verified 2026-08-11
Note: The Saudi-nationals staffing requirement is a distinctive ECC obligation with direct bearing on how a foreign firm supports a Saudi engagement. Read from the document 11 August 2026.
ECC-2:2024 decodes as Essential Cybersecurity Controls, version 2, year of issuance 2024. Individual control codes are four-part: Main-domain . Subdomain . Main-control . Sub-control (for example 2-3-2-6). The methodological structure gives each subdomain an objective and a set of numbered control clauses.
Source: NCA - ECC-2:2024 (English), Figures 3-4 and Table 1 · verified 2026-08-11
Saudi Arabia's National Cybersecurity Authority first issued the Essential Cybersecurity Controls as ECC-1:2018. ECC-2:2024 consists of 4 cybersecurity main domains (Cybersecurity Governance, Cybersecurity Defense, Cybersecurity Resilience, and Third-Party & Cloud Computing Cybersecurity), 28 subdomains, 108 main controls and 92 subcontrols. The Controls apply to government agencies in the Kingdom (including ministries, authorities and establishments) and their affiliated companies and entities inside and outside the Kingdom, and to all private-sector entities owning, operating or hosting Critical National Infrastructure; each entity must comply with all controls applicable to it.
Source: NCA — Essential Cybersecurity Controls ECC – 2 : 2024 (English) · verified 2026-08-11
Note: Counts and scope read directly from the ECC – 2 : 2024 document. NCA's canonical index sits at nca.gov.sa/en/regulatory-documents/controls-list/ecc/, which is unreachable from outside the region; this CDN copy is NCA's own published file and does resolve. Compliance is mandated by Article 10(3) of the NCA Statute and High Order No. 57231 dated 10/11/1439H.
Under Article 10(3) of the NCA Statute and High Order No. 57231 (10/11/1439H), in-scope entities must ensure ongoing continuous compliance with the ECC. The NCA evaluates compliance through self-assessments, periodic reports of its compliance tool, and/or field auditing visits, and issues an ECC-2:2024 Assessment and Compliance Tool to organise assessment. Controls under Subdomain 4-2 (Cloud Computing and Hosting Cybersecurity) are binding on entities currently using or planning to use cloud computing and hosting services.
Source: NCA - Essential Cybersecurity Controls ECC - 2 : 2024 (English), Implementation and Compliance section · verified 2026-08-11
Note: Read from the official ECC-2:2024 document (classification Public, TLP:White) on 11 August 2026.
GDPR
GDPR Article 30 requires controllers and processors to maintain records of processing activities (RoPA) under their responsibility, including purposes, categories of data subjects and personal data, recipients, third-country transfers, retention time limits and a general description of technical and organisational security measures. The obligation has a limited exemption for organisations under 250 employees, which falls away where processing is not occasional, is likely to result in a risk to rights and freedoms, or involves special-category or criminal-conviction data.
Source: Regulation (EU) 2016/679 (GDPR), Article 30 - EUR-Lex consolidated text · verified 2026-08-11
GDPR Article 35 requires a data protection impact assessment (DPIA) before processing that is likely to result in a high risk to the rights and freedoms of natural persons - in particular for systematic and extensive automated evaluation (including profiling) with legal or similarly significant effects, large-scale processing of special categories of data, or large-scale systematic monitoring of a publicly accessible area. Where a DPIA indicates high residual risk absent mitigation, Article 36 requires prior consultation with the supervisory authority.
Source: Regulation (EU) 2016/679 (GDPR), Articles 35-36 - EUR-Lex consolidated text · verified 2026-08-11
GDPR Articles 37-39 require designation of a data protection officer (DPO) where processing is carried out by a public authority, or where the core activities consist of regular and systematic monitoring of data subjects on a large scale, or large-scale processing of special categories of data or criminal-conviction data. The DPO is designated on the basis of professional qualities and expert knowledge of data protection law, must be involved in all data-protection matters, report to the highest management level, and cannot be dismissed or penalised for performing the role.
Source: Regulation (EU) 2016/679 (GDPR), Articles 37-39 - EUR-Lex consolidated text · verified 2026-08-11
Regulation (EU) 2016/679 entered into force 24 May 2016 and has applied across all EU member states since 25 May 2018. Breach notification to the supervisory authority is required without undue delay and, where feasible, within 72 hours (Art. 33).
Source: GDPR — official text (EUR-Lex 2016/679) · verified 2026-08-01
A controller must notify a personal data breach to the supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of it, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where notification is not made within 72 hours it must be accompanied by reasons for the delay.
Source: EUR-Lex — Regulation (EU) 2016/679 (GDPR), consolidated text · verified 2026-08-04
Note: Article 33, with Recital 85. The 72 hours runs from awareness of the breach, not from its occurrence, and the obligation is qualified by “where feasible” — it is not an absolute deadline.
The lower tier is up to 10 000 000 EUR or, for an undertaking, up to 2 % of total worldwide annual turnover of the preceding financial year, whichever is higher — covering obligations of controllers and processors such as security of processing, records and breach notification. The higher tier is up to 20 000 000 EUR or 4 % of total worldwide annual turnover, whichever is higher — covering the basic principles for processing, conditions for consent, data-subject rights, and transfers to third countries.
Source: EUR-Lex — Regulation (EU) 2016/679 (GDPR), consolidated text · verified 2026-08-04
Note: Article 83(4) and 83(5). “Undertaking” is read in the competition-law sense, so turnover can be assessed across a corporate group rather than the single legal entity fined.
OWASP ASVS
OWASP ASVS 5.0 reorganises its requirements into 17 chapters (V1-V17): V1 Encoding and Sanitization, V2 Validation and Business Logic, V3 Web Frontend Security, V4 API and Web Service, V5 File Handling, V6 Authentication, V7 Session Management, V8 Authorization, V9 Self-contained Tokens, V10 OAuth and OIDC, V11 Cryptography, V12 Secure Communication, V13 Configuration, V14 Data Protection, V15 Secure Coding and Architecture, V16 Security Logging and Error Handling, V17 WebRTC. This is a substantial restructure from the v4.0.x chapter layout - a mapping is needed when moving an assessment from 4.0 to 5.0.
Source: OWASP Application Security Verification Standard 5.0 repository (CC BY-SA) · verified 2026-08-11
OWASP Application Security Verification Standard v5.0.0 (May 2025): ~350 requirements across 17 chapters, three verification levels (L1–L3).
Source: OWASP ASVS project · verified 2026-08-01
Version 5.0.0 of the Application Security Verification Standard sets out 345 verification requirements organised into 17 chapters, covering encoding and sanitization, validation, web frontend security, API and web service, file handling, authentication, session management, authorization, self-contained tokens, OAuth and OIDC, cryptography, secure communication, configuration, data protection, secure coding and architecture, security logging and error handling, and WebRTC.
Source: OWASP — Application Security Verification Standard project · verified 2026-08-04
Note: Counted from the machine-readable ASVS 5.0.0 requirement set published in the OWASP/ASVS repository. No release date is recorded here because that file carries none.
ASVS 5.0.0 assigns each requirement to one of three levels. Level 1 carries 70 requirements, Level 2 carries 183, and Level 3 carries 92, totalling 345. The levels are cumulative in practice: an application verified at a higher level is expected to satisfy the lower levels too, so Level 3 verification covers the full set.
Source: OWASP — Application Security Verification Standard project · verified 2026-08-04
Note: Level counts computed from the ASVS 5.0.0 requirement set. Treat the split as the shape of the standard rather than an estimate of effort — Level 1 is deliberately the smallest tier.
DPDP Act 2023
Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023); Presidential assent 11 August 2023; Gazette ID CG-DL-E-12082023-248045.
Source: Official Gazette text (MeitY PDF) · verified 2026-07-31
Digital Personal Data Protection Rules, 2025 notified 13 November 2025 as G.S.R. 843(E), Gazette of India Extraordinary Part II s.3(i).
Source: MeitY / PIB — DPDP Rules 2025 · verified 2026-08-01
Note: Gazette date corroborated across multiple law-firm analyses; the PIB document filename carries the press-release date (17 Nov), not the notification date.
Provisions constituting and empowering the Data Protection Board (ss.18–26), definitions, and procedural rules took effect on 13 November 2025.
Source: DPDP Rules 2025 (phased commencement) · verified 2026-08-01
Section 6(9) (verifiable parental consent) and section 27(1)(d) (publication duty) commence one year from notification — November 2026.
Source: DPDP Rules 2025 (phased commencement) · verified 2026-08-01
Notice and consent standards, data fiduciary duties, children's data and data principal rights commence eighteen months from notification — May 2027. Published analyses split on 12 vs 13 May; confirm the exact day with counsel before relying on it.
Source: DPDP Rules 2025 (phased commencement) · verified 2026-08-01
The Schedule to the Act caps monetary penalties at up to ₹250 crore per instance for the highest tier (failure to take reasonable security safeguards to prevent a personal data breach), with lower tiers at ₹200 crore, ₹150 crore and below; the Data Protection Board determines penalties on the facts.
Source: DPDP Act 2023, the Schedule (official Gazette text) · verified 2026-08-01
Note: Amount verified directly against the Gazette PDF text ('may extend to two hundred and fifty crore rupees'). Enforcement follows the phased commencement (see dpdp-phase-3).
Under Rule 7 of the DPDP Rules 2025, a data fiduciary must intimate the Data Protection Board of a personal data breach without delay on becoming aware, follow with a detailed report within 72 hours (extendable by the Board), and notify affected data principals of the breach in plain language.
Source: DPDP Rules 2025, Rule 7 · verified 2026-08-01
Note: Timelines corroborated across multiple legal publishers. Enforcement follows the phased commencement (see dpdp-phase-3). Runs in parallel with CERT-In’s 6-hour incident reporting — the same incident triggers both.
Every consent request must be accompanied or preceded by a notice informing the data principal of: (i) the personal data and the purpose of processing; (ii) the manner of exercising rights under s.6(4) (withdrawal) and s.13 (grievance redressal); and (iii) the manner of making a complaint to the Data Protection Board. For consents given before commencement, notice must follow as soon as reasonably practicable.
Source: DPDP Act 2023, section 5 (official Gazette text) · verified 2026-08-01
Note: Contents verified directly against the Gazette PDF text. Notice must be available in English or any Eighth Schedule language.
Rule 4 of the Digital Personal Data Protection Rules, 2025 establishes the registration and oversight framework for Consent Managers and comes into force on 13 November 2026. A Consent Manager is registered with the Data Protection Board of India and acts as a single point of contact through which a Data Principal can give, manage, review and withdraw consent via an accessible, transparent and interoperable platform.
Source: MeitY - Digital Personal Data Protection Rules, 2025 (official page) · verified 2026-08-08
Note: MeitY returns HTTP 403 to automated retrieval for both the Rules page and its own FAQ PDF, so this is corroborated across independent legal analyses rather than read from the primary text. Verify against the notified Rules before relying on it in a deliverable.
Part A of the First Schedule sets the conditions the Board must be satisfied of before registering a Consent Manager. They include incorporation in India, a minimum net worth of INR 2 crore (adjusted for inflation), sound financial condition and general character of management, and sufficient technical, operational and financial capacity to discharge the role. Directors, key managerial personnel and senior management must be persons of general reputation and record of fairness and integrity.
Source: MeitY - Digital Personal Data Protection Rules, 2025, First Schedule Part A · verified 2026-08-08
Note: MeitY returns HTTP 403 to automated retrieval for both the Rules page and its own FAQ PDF, so this is corroborated across independent legal analyses rather than read from the primary text. Verify against the notified Rules before relying on it in a deliverable.
A Consent Manager acts in a fiduciary capacity toward the Data Principal. It must not act as Data Fiduciary or Data Processor for the same Data Principal whose consent it manages, must route personal data in a form it cannot itself read, must treat all Data Fiduciaries neutrally without preferential access, and must retain consent records for at least seven years.
Source: MeitY - Digital Personal Data Protection Rules, 2025, First Schedule Part B · verified 2026-08-08
Note: MeitY returns HTTP 403 to automated retrieval for both the Rules page and its own FAQ PDF, so this is corroborated across independent legal analyses rather than read from the primary text. Verify against the notified Rules before relying on it in a deliverable. The conflict rule is the commercially significant one: an organisation cannot register as a Consent Manager for data subjects it also serves as a Data Fiduciary.
CERT-In Directions
Directions under Section 70B(6), IT Act 2000 issued 28 April 2022; effective 28 June 2022. Apply to service providers, intermediaries, data centres, body corporates and government organisations.
Source: CERT-In Directions (official PDF) · verified 2026-07-31
Specified cyber incidents must be reported to CERT-In within 6 hours of noticing.
Source: CERT-In Directions (official PDF) · verified 2026-07-31
ICT system logs must be maintained for a rolling 180 days, within Indian jurisdiction.
Source: CERT-In Directions (official PDF) · verified 2026-07-31
System clocks must be synchronised to NIC or NPL time sources.
Source: CERT-In Directions (official PDF) · verified 2026-07-31
Data centres, VPS, cloud and VPN providers must register and retain accurate subscriber/customer records for 5 years after cancellation or withdrawal of service.
Source: CERT-In Directions (official PDF) · verified 2026-07-31
UIDAI (Aadhaar)
Authentication User Agencies and eKYC User Agencies must have operations audited annually (and on need) by a certified information systems auditor; the report is shared with UIDAI on request. The governing instruments are the Aadhaar (Authentication and Offline Verification) Regulations, 2021, together with the Aadhaar (Data Security) Regulations, 2016 and the UIDAI Information Security Policy.
Source: UIDAI compliance checklist for controls the AUA/KUA must have in place · verified 2026-08-11
Note: Aadhaar (Authentication and Offline Verification) Amendment Regulations were made in 2025, with further UIDAI updates in January 2026 (including a revised pre-onboarding AUA/KUA checklist). uidai.gov.in 307-redirects deep links to a single-page app, so the amendment text could not be retrieved automatically and its effect on the audit obligation is UNVERIFIED here - check the current regulation before relying on this entry for scoping.
IRDAI
Insurance Self-Network Platforms operate under IRDAI permission per the Guidelines on Insurance e-commerce (circular IRDA/INT/GDL/ECM/055/03/2017, 9 March 2017). The controls, systems, procedures and safeguards of the platform must be reviewed at least once a year, at the applicant's own cost, by an external Certified Information Systems Auditor (CISA), a Chartered Accountant holding DISA (ICAI), or a CERT-In empanelled expert, and the resulting report placed before the Board or its sub-committee.
Source: IRDAI - circular on online filing for Insurance Self Network Platform (IRDA/INT/CIR/ECM/083/04/2017), citing the governing e-commerce guidelines · verified 2026-08-07
Note: The governing instrument is the Guidelines on Insurance e-commerce, IRDA/INT/GDL/ECM/055/03/2017 of 9 March 2017. That guidelines PDF is not retrievable in text form from the IRDAI portal, so the citation points to IRDAI's own follow-on circular, which states the reference number and date verbatim. The audit-clause wording is corroborated across multiple independent summaries; verify against the guidelines PDF before quoting it in a deliverable.
Annexure IV sets two alternative routes. Either a Chartered Accountant firm registered with ICAI (partnership or LLP) with at least five years of continuous practice and four partners, including one CISA/DISA holder, one ICAI Fellow, one with three years of cyber or information security audit experience in insurance companies, banks or mutual funds, and one with IT-environment and remote-audit experience — OR, in the guidelines’ own words, a “Cert-In empanelled external systems Auditor holding CISA / DISA certifications”. The auditor must not have been debarred or declared ineligible for corrupt or fraudulent practices by the Government of India, a State Government, IRDAI, SEBI, RBI, ICAI, CERT-In or SFIO.
Source: IRDAI Information and Cybersecurity Guidelines, 2026 — Annexure IV · verified 2026-08-08
Note: Read from the guidelines document itself (VER 2.0, April 2026, 175 pages) rather than from secondary analyses. The covering circular reference number does not appear in the guidelines body and remains unconfirmed, so it is still not cited. CyberSigma qualifies under the second route as a CERT-In empanelled auditor, without needing to meet the four-partner CA-firm test.
Insurers must submit the Audit Report (Annexure III), signed by the auditor and accompanied by the comments of the Board, to IRDAI within 90 days from the end of the financial year OR within 30 days of completion of the audit, whichever is earlier. Foreign Reinsurance Branches whose IT systems interface with overseas parent companies must comply and have the auditor certify per Annexure VI, submitted at the end of every financial year.
Source: IRDAI Information and Cybersecurity Guidelines, 2026 — clause on audit submission · verified 2026-08-08
Note: Read from the guidelines document itself (VER 2.0, April 2026, 175 pages) rather than from secondary analyses. The covering circular reference number does not appear in the guidelines body and remains unconfirmed, so it is still not cited. The “whichever is earlier” limb is the one commonly missed: completing an audit early shortens the deadline rather than extending it.
Certification under these guidelines may not rest on management representation or on reliance upon the work of other auditors, because the auditor is appointed by regulated entities that must protect policyholder and public data. The auditor is required to perform the work through interviews, document verification, compliance checks and adequate testing of controls.
Source: IRDAI Information and Cybersecurity Guidelines, 2026 — Annexure IV clause 3 · verified 2026-08-08
Note: Read from the guidelines document itself (VER 2.0, April 2026, 175 pages) rather than from secondary analyses. The covering circular reference number does not appear in the guidelines body and remains unconfirmed, so it is still not cited.
IRDAI issued Version 2.0 of its Information and Cyber Security Guidelines in April 2026, replacing the Information and Cyber Security Guidelines, 2023 dated 24 April 2023. They apply to all Insurers including Foreign Re-Insurance Branches (FRBs) and Insurance Intermediaries regulated by IRDAI, and to all data created, received or maintained by Regulated Entities in any form. Insurance Agents, Micro-Insurance Agents, Point of Sale Persons and Individual Surveyors are expressly outside their purview, though Insurers remain responsible for ensuring those entities follow a minimum security framework under the Insurer’s Board-approved policy.
Source: IRDAI - Information and Cybersecurity Guidelines, 2026 (official document portal) · verified 2026-08-07
Note: Read from the guidelines document itself (VER 2.0, April 2026, 175 pages) rather than from secondary analyses. The covering circular reference number does not appear in the guidelines body and remains unconfirmed, so it is still not cited. An earlier version of this entry listed brokers, corporate agents, web aggregators, TPAs, ISNPs and IIB as in-scope; that enumeration came from secondary summaries and is not how the guidelines define scope.
IRDAI issued the Information and Cyber Security Guidelines, 2023 on 24 April 2023 (ref IRDAI/GA&HR/GDL/MISC/88/04/2023), superseding the 2017 guidelines (IRDA/IT/GDL/MISC/082/04/2017) and three subsequent circulars. These were themselves superseded on 6 April 2026 by the IRDAI Information and Cybersecurity Guidelines, 2026 (Version 2.0) - the 2023 text is retained here as the previous baseline, not as the current requirement.
Source: IRDAI - Information and Cyber Security Guidelines, 2023 (official document portal) · verified 2026-08-07
PCI DSS
PCI DSS v4.0.1 is the current standard published by the PCI Security Standards Council.
Source: PCI SSC document library · verified 2026-08-01
PCI DSS v3.2.1 retired 31 March 2024. v4.0.1 (a limited revision — no requirements added or removed) was published 11 June 2024, and v4.0 retired 31 December 2024, leaving v4.0.1 the only active version. The 51 future-dated v4.x requirements became mandatory in assessments from 31 March 2025.
Source: PCI Security Standards Council (official blog) · verified 2026-08-01
PCI SSC publishes ten SAQs: A, A-EP, B, B-IP, C, C-VT, D for Merchants, D for Service Providers, P2PE and SPoC. A separate “SAQ Instructions and Guidelines” document accompanies them and sets out eligibility for each.
Source: PCI SSC — Document Library · verified 2026-08-04
Note: Enumerated from PCI SSC’s document library. Which SAQ a given entity may use depends on how it handles cardholder data, and validation is ultimately driven by the acquirer or card brand rather than by PCI SSC. The eligibility criteria sit inside the SAQ Instructions document, which is distributed under licence acceptance and cannot be retrieved automatically — so this entry records the set of questionnaires, not the criteria.
“Integrating Artificial Intelligence in PCI Assessments Guidelines v1.0” is published in the PCI SSC document library, establishing that the Council addresses the use of AI within PCI assessments at version 1.0.
Source: PCI SSC — Document Library · verified 2026-08-04
Note: This entry records the document’s existence and version, both visible in the document library. Its contents are behind licence acceptance and have not been read, so no substantive requirement is asserted here.
PCI DSS v4.x allows two approaches. The Defined Approach is the traditional method: the entity implements the stated requirement and the assessor follows the defined testing procedures. The Customized Approach, new in v4.x, lets an entity meet a requirement’s Customized Approach Objective by other means, supporting innovation in security practice. Compensating controls are available only under the defined approach, and only where a legitimate, documented technical or business constraint prevents meeting the requirement as stated; they must be documented annually, reviewed and validated by the assessor, and submitted with the ROC.
Source: PCI SSC — PCI DSS v4.x ROC Template FAQs, Revision 1 (December 2022) · verified 2026-08-04
Note: Section 1.2. The document states plainly: “Compensating Controls are not an option for the Customized Approach.” Read directly from the PCI SSC document named above. PCI SSC distributes its documents under a licence acceptance that blocks automated retrieval, so the citation points at the document library rather than a direct file URL.
Each individual PCI DSS requirement is reported as exactly one of: In Place, Not Applicable, Not Tested, or Not in Place. Not Applicable requires the assessor to render an opinion and to report the testing performed to confirm non-applicability. Not Tested means the requirement was excluded from consideration entirely — the assessor follows the entity’s instruction and renders no opinion — and any use of Not Tested makes the engagement a Partial Assessment.
Source: PCI SSC — PCI DSS v4.x ROC Template FAQs, Revision 1 (December 2022) · verified 2026-08-04
Note: Sections 2.2, 2.3, 4.1 and 4.2. “In Place with Remediation” existed in the original v4.0 ROC Template and was removed by Revision 1, so it is not a valid finding. Read directly from the PCI SSC document named above. PCI SSC distributes its documents under a licence acceptance that blocks automated retrieval, so the citation points at the document library rather than a direct file URL.
The ROC records an Overall Assessment Result of Compliant, Compliant but with Legal Exception, or Non-Compliant. Separately it records whether a Full or Partial Assessment was performed: Full means every requirement was assessed and none marked Not Tested; Partial means one or more were marked Not Tested. “Compliant but with Legal Exception” applies where a statutory law or regulation prohibits meeting a requirement — the assessor must confirm such a law exists, and contractual obligations or legal advice do not qualify.
Source: PCI SSC — PCI DSS v4.x ROC Template FAQs, Revision 1 (December 2022) · verified 2026-08-04
Note: Sections 2.1, 2.3 and 4.1. Read directly from the PCI SSC document named above. PCI SSC distributes its documents under a licence acceptance that blocks automated retrieval, so the citation points at the document library rather than a direct file URL.
The PCI DSS ROC Template is mandatory for QSAs reporting a PCI DSS assessment, and every response section must be completed even where requirements are not applicable. QSAs may add company logos and legal wording to the customisable title page, change page headers, add table rows, and delete the ROC Template Instructions before issuing the report. They may not edit footers, change the format, reorder or remove sections or requirements, or remove any content from Parts I and II.
Source: PCI SSC — PCI DSS v4.x ROC Template FAQs, Revision 1 (December 2022) · verified 2026-08-04
Note: Sections 5.1 and 5.4. The current unlocked Word version is distributed to assessors through the Assessor Portal at programs.pcissc.org. Accepting payment brands or acquirers may reject a report whose template changes they consider unacceptable. Read directly from the PCI SSC document named above. PCI SSC distributes its documents under a licence acceptance that blocks automated retrieval, so the citation points at the document library rather than a direct file URL.
PCI DSS v4.0 introduced the targeted risk analysis (TRA). Requirement 12.3.1 covers TRAs that set how frequently a periodic activity is performed; Requirement 12.3.2 covers TRAs supporting any requirement met by the customized approach. A TRA is required only where a requirement explicitly says so. Once prepared, the entity reviews each TRA at least once every 12 months and on changes that could affect risk. A TRA cannot be used to perform an activity LESS often than a requirement states — that is a failure of the requirement, not a risk decision.
Source: PCI SSC — Information Supplement: PCI DSS v4.x Targeted Risk Analysis Guidance (November 2023) · verified 2026-08-04
Note: Introduction and FAQs 1, 2, 5 and 6. Performing an activity MORE often than stated needs no TRA. Where a documented technical or business constraint prevents meeting a stated frequency, the route is a compensating control, not a TRA. Read directly from the PCI SSC document named above. PCI SSC distributes its documents under a licence acceptance that blocks automated retrieval, so the citation points at the document library rather than a direct file URL.
Nine requirements let the entity set frequency by TRA, and PCI SSC publishes baseline recommendations for each: malware-risk re-evaluation for components deemed not at risk (5.2.3.1) at least every six months; periodic malware scans (5.3.2.1) daily; review of application and system account access (7.2.5.1) every six months; changing application and system account passwords (8.6.3) every three months; POI device inspections (9.5.1.2.1) monthly; log reviews for other system components (10.4.2.1) every seven days; remediation of non-critical vulnerabilities (11.3.1.1) within three months for medium and six months for low; payment-page change- and tamper-detection (11.6.1) every seven days; and incident-response training (12.10.4.1) yearly and at the start of employment.
Source: PCI SSC — Information Supplement: PCI DSS v4.x Targeted Risk Analysis Guidance (November 2023) · verified 2026-08-04
Note: Table at the end of the supplement. These are recommendations, not requirements — a TRA is still required to document and justify whichever frequency the entity selects. Read directly from the PCI SSC document named above. PCI SSC distributes its documents under a licence acceptance that blocks automated retrieval, so the citation points at the document library rather than a direct file URL.
Appendix A3, Designated Entities Supplemental Validation (DESV), is assessed only when an acquirer or payment brand instructs an entity to undergo it. It adds five requirement groups: A3.1 a PCI DSS compliance programme, A3.2 documented and validated scope, A3.3 PCI DSS embedded in business-as-usual, A3.4 controlled logical access, and A3.5 identification of and response to suspicious events. Its cadences are tighter than the annual assessment: scope confirmed and data discovery performed at least every three months, BAU reviews every three months, segmentation penetration testing every six months, and user-account review every six months.
Source: PCI SSC — PCI DSS v4.0 Supplemental ROC Template: DESV, Revision 1 (December 2022) · verified 2026-08-04
Note: Instructions for Submission and Findings sections. Every DESV requirement examined states “This requirement is not eligible for the customized approach,” so DESV must be met as defined, with compensating controls the only flexibility. Read directly from the PCI SSC document named above. PCI SSC distributes its documents under a licence acceptance that blocks automated retrieval, so the citation points at the document library rather than a direct file URL.
PCI SSC recommends retaining all collected assessment evidence for a minimum of three years, so an organisation can substantiate historic compliance statements and support forensic analysis after a breach. Contractual obligations or local law may require longer. Evidence includes work papers, audit results, interview notes, screenshots and configuration settings, and the retention process should guard against evidence being altered, tampered with or destroyed.
Source: PCI SSC — Information Supplement: Best Practices for Maintaining PCI DSS Compliance v2.0 (January 2019) · verified 2026-08-04
Note: Section 3.6.7. This supplement is written against PCI DSS v3.2.1 and states so; the retention recommendation is guidance rather than a numbered v4.x requirement. Where an entity forbids its QSA from retaining evidence, PCI SSC expects a formal agreement allocating retention responsibility.
SAQ A covers e-commerce or mail/telephone-order merchants who outsource all processing of account data to PCI DSS compliant third parties, store, process and transmit no account data electronically on their own systems or premises, have confirmed those third parties are compliant for the services used, and retain any account data only on paper not received electronically. E-commerce merchants must additionally confirm that every element of the payment page delivered to the customer’s browser originates only and directly from a compliant third-party processor, and that their site is not susceptible to script-based attacks affecting their e-commerce systems. SAQ A does not apply to face-to-face channels or to service providers.
Source: PCI SSC — SAQ Instructions and Guidelines, v4.0.1 r1 (April 2025) · verified 2026-08-04
Note: The two e-commerce criteria were ADDED by revision r1 in April 2025 — the document’s revision history records them as new eligibility criteria, not a clarification. A merchant that qualified for SAQ A before April 2025 may no longer qualify. Read directly from the document named above. PCI SSC distributes it under a licence acceptance that blocks automated retrieval, so the citation points at the document library.
SAQ A-EP covers e-commerce merchants whose website does not itself receive account data but does affect the security of the transaction or the integrity of the page accepting the customer’s account data — typically by controlling how customers or their data are redirected to a compliant processor. Each element of the payment page must originate from either the merchant’s website or a compliant third party. Where the site is hosted by a third party, that provider must meet all applicable requirements including PCI DSS Appendix A for multi-tenant hosting. The SAQ applies only to e-commerce and not to service providers.
Source: PCI SSC — SAQ Instructions and Guidelines, v4.0.1 r1 (April 2025) · verified 2026-08-04
Note: For SAQ A-EP the requirements that refer to the cardholder data environment apply to the merchant website itself, because the site directly affects how account data is transmitted even though it never receives that data. Read directly from the document named above. PCI SSC distributes it under a licence acceptance that blocks automated retrieval, so the citation points at the document library.
SAQ B covers merchants processing account data only through imprint machines or standalone dial-out terminals connected by phone line, not connected to the Internet or to other systems. SAQ B-IP covers merchants using only standalone, PCI-listed approved PTS point-of-interaction devices connected by IP directly to the payment processor, isolated from other systems, where the device does not rely on any other computer, phone or tablet to reach the processor. Neither SAQ permits electronic storage of account data, applies to e-commerce, or applies to service providers.
Source: PCI SSC — SAQ Instructions and Guidelines, v4.0.1 r1 (April 2025) · verified 2026-08-04
Note: Secure Card Readers (SCR) and Secure Card Readers for PIN (SCRP) are explicitly excluded from SAQ B-IP — merchants using them are not eligible. A merchant on an expired PTS POI device should check acceptability with its acquirer or the payment brands. Read directly from the document named above. PCI SSC distributes it under a licence acceptance that blocks automated retrieval, so the citation points at the document library.
SAQ C covers merchants with a payment application system such as a POS on the same device or LAN as an Internet connection, isolated from all other systems, where the POS location is not connected to other premises and any LAN serves a single store only. SAQ C-VT covers merchants whose only processing is manual, single-transaction keyboard entry into a third-party hosted virtual payment terminal, accessed from an isolated computing device in a single location with no card readers attached and no software that stores account data. Neither stores account data electronically, applies to e-commerce, or applies to service providers.
Source: PCI SSC — SAQ Instructions and Guidelines, v4.0.1 r1 (April 2025) · verified 2026-08-04
Note: Isolation in both SAQs may be achieved by network segmentation, and does not prevent the permitted system type from transmitting transaction data onward to an acquirer or processor. Read directly from the document named above. PCI SSC distributes it under a licence acceptance that blocks automated retrieval, so the citation points at the document library.
SAQ P2PE covers merchants whose payment processing runs entirely through payment terminals belonging to a validated, PCI-listed point-to-point encryption solution, where those terminals are the only systems that store, process or transmit account data, the merchant has no access to clear-text account data on any computer system, and the merchant has implemented all controls in the P2PE Instruction Manual supplied by the solution provider. It does not apply to e-commerce or to service providers.
Source: PCI SSC — SAQ Instructions and Guidelines, v4.0.1 r1 (April 2025) · verified 2026-08-04
Note: Solutions appearing on the PCI list of Point-to-Point Solutions with Expired Validations are no longer “validated”; a merchant on an expired solution should confirm acceptability with its acquirer or the payment brands. A mail/telephone-order merchant keying data from paper or a call directly into such a terminal can qualify. Read directly from the document named above. PCI SSC distributes it under a licence acceptance that blocks automated retrieval, so the citation points at the document library.
SAQ SPoC covers merchants processing card-present transactions only through a PCI-listed approved PTS Secure Card Reader-PIN device together with a commercial off-the-shelf mobile device, as part of a validated PCI-listed Software-based PIN Entry on COTS solution, with no access to clear-text account data on any computer system. The COTS device is general purpose — it need not be dedicated to payments.
Source: PCI SSC — SAQ Instructions and Guidelines, v4.0.1 r1 (April 2025) · verified 2026-08-04
Note: Merchants using non-PTS-listed magnetic stripe readers are not eligible. The SAQ may be used for PTS-listed SCRPs that include magnetic stripe reader functionality. Read directly from the document named above. PCI SSC distributes it under a licence acceptance that blocks automated retrieval, so the citation points at the document library.
SAQ D for Merchants applies to any SAQ-eligible merchant that does not meet the criteria for another SAQ type — including e-commerce merchants who accept account data on their own website, merchants who store account data electronically, and merchants who would otherwise fit a narrower SAQ but have additional PCI DSS requirements applicable to their environment. SAQ D for Service Providers applies to all service providers a payment brand has deemed eligible to self-assess.
Source: PCI SSC — SAQ Instructions and Guidelines, v4.0.1 r1 (April 2025) · verified 2026-08-04
Note: Under PCI DSS v4.x, SAQ D for Service Providers requires additional documentation in Section 2a and requires the service provider to describe results for each requirement rather than simply answer. Read directly from the document named above. PCI SSC distributes it under a licence acceptance that blocks automated retrieval, so the citation points at the document library.
Each SAQ states that the merchant confirms eligibility “for this payment channel”, so a merchant running several channels may need to validate them separately. Of the nine merchant SAQs, only SAQ A and SAQ A-EP cover e-commerce; B, B-IP, C, C-VT, P2PE and SPoC each state they are not applicable to e-commerce channels. Every SAQ except SAQ D for Service Providers states it is not applicable to service providers. In all cases the entity must also meet whatever validation its acquirer or the payment brands require — PCI SSC does not set that.
Source: PCI SSC — SAQ Instructions and Guidelines, v4.0.1 r1 (April 2025) · verified 2026-08-04
Note: This channel-by-channel framing is the most commonly missed point in scoping conversations: qualifying for a narrow SAQ on one channel says nothing about the others. Read directly from the document named above. PCI SSC distributes it under a licence acceptance that blocks automated retrieval, so the citation points at the document library.
SEBI CSCRF
SEBI issued the Cybersecurity and Cyber Resilience Framework vide circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2024/113 dated 20 August 2024 (Version 1.0, 205 pages). The compliance timeline was extended twice: circular 2025/45 of 28 March 2025 moved it by three months to 30 June 2025, and circular 2025/96 of 30 June 2025 moved it by a further two months to 31 August 2025. Both extensions applied to all regulated entities except Market Infrastructure Institutions (MIIs), KYC Registration Agencies (KRAs) and Qualified Registrars to an Issue and Share Transfer Agents (QRTAs), which stayed on the original timeline. That final date has passed, so CSCRF is fully in force.
Source: SEBI — extension circular 2025/96 (official PDF, 30 June 2025) · verified 2026-08-04
Note: Upgraded to a primary source: this entry previously rested on the June 2025 FAQ plus independent legal analyses. The extension chain has now been read directly from the SEBI circulars themselves. The most recent CSCRF amendment is circular 2025/119 of 28 August 2025; no later CSCRF circular has issued as at 2026-08-04.
CSCRF applies proportionately by category: (i) Market Infrastructure Institutions (MIIs), (ii) Qualified REs, (iii) Mid-size REs, (iv) Small-size REs and (v) Self-certification REs. Entity-wise thresholds that determine which category an RE falls into are set out in the framework's “Thresholds for REs’ categorization” section.
Source: SEBI — CSCRF circular 2024/113 (official PDF, 20 August 2024) · verified 2026-08-04
Note: Portfolio Managers and Merchant Bankers were re-categorised by circular 2025/119 of 28 August 2025 (Part C).
The framework states: “Unless otherwise specified, all audits mentioned in CSCRF have to be conducted by CERT-In empanelled IS auditing organization.” The same requirement is restated for the VAPT and cyber audit that the Market SOC is to provide to small- and mid-size REs at affordable cost.
Source: SEBI — CSCRF circular 2024/113 (official PDF, 20 August 2024) · verified 2026-08-04
Note: Quoted verbatim from footnote 16, page 48 of 205.
REs identified as “Protected systems” and/or Critical Information Infrastructure by NCIIPC must complete at least two VAPT activities each year — one in each half of the financial year (April to September, October to March), each including report submission, closure and revalidation. All other REs must complete at least one, with the activity commencing in the first quarter of the financial year.
Source: SEBI — CSCRF circular 2024/113 (official PDF, 20 August 2024) · verified 2026-08-04
Note: Table 18, page 48. REs must plan VAPT at the start of the financial year, and no audit cycle may be left unaudited because of a change in category.
The VAPT report must be submitted within one month of completing the VAPT activity, after approval from the RE's IT Committee. Findings must be closed within three months of report submission, following a graded approach based on the criticality of the observations. Revalidation of the VAPT must be completed within five months of its completion.
Source: SEBI — CSCRF circular 2024/113 (official PDF, 20 August 2024) · verified 2026-08-04
Note: Table 19, page 49. Vulnerabilities still open after three months require IT Committee approval and must be closed before the next VAPT exercise begins.
CSCRF mandates a SOC for all REs except client-based stock brokers with fewer than 100 clients. An RE may use its own or group SOC, any third-party managed SOC, or the Market SOC. Small-size and Self-certification category REs are required to onboard the Market SOC, which NSE and BSE must set up and which NSDL and/or CDSL may set up optionally.
Source: SEBI — CSCRF circular 2024/113 (official PDF, 20 August 2024) · verified 2026-08-04
Note: Box Item 11, page 69. For small- and mid-size REs the Market SOC is also to provide VAPT and cyber audit services.
The Cyber Capability Index (CCI) applies only to MIIs and Qualified REs. MIIs must have their cyber resilience assessed against the CCI by a third party on a half-yearly basis; Qualified REs self-assess their cyber resilience using the CCI on a yearly basis.
Source: SEBI — CSCRF circular 2024/113 (official PDF, 20 August 2024) · verified 2026-08-04
Note: Page 14 of 205; the index itself is set out at Annexure-K, page 163.
Circular SEBI/HO/ITD-1/ITD_CSC_EXT/P/CIR/2025/119 dated 28 August 2025 issues technical clarifications in four parts: Part A, principles for REs under multiple regulators' purview, introducing a Principle of Exclusivity and a Principle of Equivalence so an RE regulated by both SEBI and (for example) RBI can demonstrate compliance without duplicating work; Part B, technical clarifications; Part C, re-categorisation of Portfolio Managers and Merchant Bankers; and Part D, Cyber Security Audit Policy Guidelines from CERT-In.
Source: SEBI — technical clarifications circular 2025/119 (official PDF, 28 August 2025) · verified 2026-08-04
Note: This is the most recent CSCRF circular as at 2026-08-04.
RBI
RBI circular DPSS.CO.OD No.2785/06.08.005/2017-2018 (6 April 2018) requires payment system providers to store the entire data relating to their payment systems only in India, with compliance within six months (by October 2018). End-to-end transaction data is covered.
Source: Reserve Bank of India (circular DPSS.CO.OD No.2785/06.08.005/2017-2018) · verified 2026-08-01
Note: Circular number cited for retrieval via RBI's notification search; we deliberately avoid deep-linking RBI's session-bound URLs.
Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices (RBI/DoS/2023-24/107) issued 7 November 2023; effective 1 April 2024. Requires an IT governance framework, information/cyber security policies and periodic IT risk assurance for regulated entities.
Source: Reserve Bank of India (Master Direction RBI/DoS/2023-24/107) · verified 2026-08-01
Note: Direction number cited for retrieval via RBI notification search; RBI deep links are session-bound.
Master Direction on Outsourcing of Information Technology Services (RBI/2023-24/102) issued 10 April 2023; effective 1 October 2023. Governs material IT outsourcing by regulated entities, including vendor risk, audit rights and concentration risk.
Source: Reserve Bank of India (Master Direction RBI/2023-24/102) · verified 2026-08-01
Note: Direction number cited for retrieval via RBI notification search.
Issued 18 February 2021: minimum security standards for digital payment channels — internet banking, mobile payments and card payments — binding scheduled commercial banks, small finance banks, payments banks and card-issuing NBFCs.
Source: Reserve Bank of India (Master Direction, 18 Feb 2021) · verified 2026-08-01
Note: Direction cited by title and date for retrieval via RBI notification search.
RBI’s Cyber Security Framework in Banks (2 June 2016) requires scheduled commercial banks to report cyber incidents to RBI within 2 to 6 hours of detection, alongside board-approved cyber security policy, SOC capability and cyber crisis management plans.
Source: Reserve Bank of India (notification, 2 June 2016) · verified 2026-08-01
ISO/IEC 27001
The IAF three-year transition window for ISO/IEC 27001:2013 certificates ended 31 October 2025 — certificates not transitioned to the 2022 revision by that date lapsed.
Source: ISO/IEC 27001 (iso.org) · verified 2026-08-11
Note: Deadline corroborated across accredited certification bodies (BSI, SGS, LRQA); iso.org blocks automated verification.
The current edition is ISO/IEC 27001:2022, the third edition, published October 2022, titled “Information security, cybersecurity and privacy protection — Information security management systems — Requirements”. It specifies requirements for establishing, implementing, maintaining and continually improving an information security management system, and is the standard against which organisations are certified.
Source: ISO — ISO/IEC 27001:2022 catalogue entry · verified 2026-08-08
Note: Bibliographic identity only — title, edition and publication date. The standard is copyright-protected and its terms forbid reproduction or utilisation without permission, so no clause structure, Annex A control counts or requirement text are recorded here. Deeper coverage requires a copy licensed to CyberSigma; a copy licensed to another organisation is not a basis for a public registry. iso.org also returns HTTP 403 to automated retrieval.
NIST CSF
NIST released Cybersecurity Framework 2.0 on 26 February 2024 — the first major revision since 2014, adding the Govern function and broadening applicability beyond critical infrastructure.
Source: NIST (official release announcement) · verified 2026-08-01
CSF 2.0 organises cybersecurity outcomes under six Functions: GOVERN (GV), IDENTIFY (ID), PROTECT (PR), DETECT (DE), RESPOND (RS) and RECOVER (RC). GOVERN is new in 2.0 and covers how an organisation establishes and monitors its cybersecurity risk management strategy, expectations and policy.
Source: NIST — Cybersecurity Framework (CSF) 2.0, NIST CSWP 29 · verified 2026-08-04
Note: Function identifiers counted directly in NIST CSWP 29.
Beneath the six Functions, the CSF 2.0 Core is organised into 22 Categories and 106 Subcategories. Subcategories state outcomes, not controls, and are the level at which an organisation assesses and communicates its current and target state.
Source: NIST — Cybersecurity Framework (CSF) 2.0, NIST CSWP 29 · verified 2026-08-04
Note: Counted from the unique Category and Subcategory identifiers (for example GV.OC, GV.OC-01) appearing in NIST CSWP 29 itself.
The framework defines four Tiers, quoted from the document: “Partial (Tier 1), Risk Informed (Tier 2), Repeatable (Tier 3), and Adaptive (Tier 4).” Tiers characterise the rigour of an organisation’s cybersecurity risk governance and management practices; they are not maturity levels and reaching Tier 4 is not a goal for every organisation.
Source: NIST — Cybersecurity Framework (CSF) 2.0, NIST CSWP 29 · verified 2026-08-04
Note: Tier names quoted verbatim from NIST CSWP 29.
NIST states that the CSF “offers a taxonomy of high-level cybersecurity outcomes that can be used by any organization — regardless of its size, sector, or maturity”, and that it “does not prescribe how outcomes should be achieved”, instead linking to online resources describing practices and controls. This is why the CSF is not certifiable and why an organisation cannot be audited as “CSF compliant” the way it can against ISO/IEC 27001 or PCI DSS.
Source: NIST — Cybersecurity Framework (CSF) 2.0, NIST CSWP 29 · verified 2026-08-04
Note: Quoted from the Abstract of NIST CSWP 29.
ISO/IEC 42001
ISO/IEC 42001:2023 — the first AI management system (AIMS) standard — was published in December 2023 by ISO/IEC.
Source: ISO/IEC 42001 (iso.org) · verified 2026-08-11
Note: iso.org blocks automated verification; publication corroborated across accredited bodies and major assurance firms.
EU AI Act
Regulation (EU) 2024/1689 entered into force on 1 August 2024. Governance rules and obligations for general-purpose AI (GPAI) model providers apply from 2 August 2025 (with transition for models already on the market).
Source: EU AI Act — official text (EUR-Lex 2024/1689) · verified 2026-08-07
Regulation (EU) 2026/1744 of 8 July 2026 (the Digital Omnibus on AI) amends Regulation (EU) 2024/1689 and was published in the Official Journal on 24 July 2026, entering into force on 27 July 2026. It postpones the obligations for high-risk AI systems designated under Article 6(2) and Annex III from 2 August 2026 to 2 December 2027, and for AI embedded in products regulated under Annex I sectoral legislation to 2 August 2028. It also adds prohibitions to Article 5 covering AI that generates or manipulates realistic non-consensual intimate imagery of identifiable individuals. The Article 50 transparency duties applying from 2 August 2026 are unaffected.
Source: Regulation (EU) 2026/1744 (Digital Omnibus on AI) - EUR-Lex · verified 2026-08-07
Note: EUR-Lex returned an empty document to automated retrieval, so the amended dates are corroborated across multiple independent legal analyses rather than read from the primary text. The regulation number, adoption date, OJ publication date and entry into force are consistent across every source checked. Confirm article-level wording against the Official Journal before relying on this in a deliverable. The staggered application dates were subsequently amended by Regulation (EU) 2026/1744 (Digital Omnibus on AI); GPAI obligations themselves were not postponed.
Article 113 provides that the Regulation applies from 2 August 2026, with three exceptions: Chapters I and II (general provisions and prohibited AI practices) applied from 2 February 2025; Chapter III Section 4, Chapter V, Chapter VII, Chapter XII and Article 78 (notifying authorities, general-purpose AI models, governance, penalties and confidentiality) applied from 2 August 2025, with the exception of Article 101; and Article 6(1), covering high-risk classification for AI as a safety component of products already regulated under Union law, applies from 2 August 2027.
Source: EUR-Lex — Regulation (EU) 2024/1689 (Artificial Intelligence Act), Official Journal · verified 2026-08-07
Note: Article 113 read verbatim from the Official Journal text. The Regulation was done at Brussels on 13 June 2024 and entered into force on the twentieth day following publication. AMENDED: Regulation (EU) 2026/1744 (in force 27 July 2026) postponed the Annex III high-risk obligations to 2 December 2027 and the Annex I embedded-product obligations to 2 August 2028. This entry records Article 113 as originally enacted and must not be read on its own as the current position.
Infringement of the Article 5 prohibited-practices rules is subject to administrative fines of up to EUR 35 000 000 or 7 % of total worldwide annual turnover for the preceding financial year, whichever is higher. Breach of most other operator obligations attracts up to EUR 15 000 000 or 3 %. Supplying incorrect, incomplete or misleading information to notified bodies or national authorities attracts up to EUR 7 500 000 or 1 %. For SMEs including start-ups, each ceiling is the lower rather than the higher of the two figures.
Source: EUR-Lex — Regulation (EU) 2024/1689 (Artificial Intelligence Act), Official Journal · verified 2026-08-04
Note: Article 99. Penalties applied from 2 August 2025 under Article 113(b); Member States set the detailed rules and notify the Commission.
Article 111 gives longer runways to AI already in service. Providers of general-purpose AI models placed on the market before 2 August 2025 must comply by 2 August 2027. High-risk systems placed on the market before 2 August 2026 are caught only if subject to significant design changes after that date — but providers and deployers of high-risk systems intended for use by public authorities must comply by 2 August 2030 regardless. AI systems that are components of the large-scale IT systems listed in Annex X and placed on the market before 2 August 2027 must be brought into compliance by 31 December 2030.
Source: EUR-Lex — Regulation (EU) 2024/1689 (Artificial Intelligence Act), Official Journal · verified 2026-08-07
Note: Article 111 read verbatim. These transitions are the reason an organisation can be lawfully operating non-conforming AI today and still face a hard compliance date. AMENDED: the 2 August 2026 pivot date for high-risk systems was moved by Regulation (EU) 2026/1744; read alongside the Digital Omnibus entry before applying these transitions to a client estate.
SAMA CSF (Saudi Arabia)
The Saudi Central Bank (SAMA) issued its Cyber Security Framework v1.0 in May 2017. It applies to all SAMA-regulated Member Organizations — banks, insurance and reinsurance companies, financing companies, credit bureaus and the Financial Market Infrastructure — and is principle-based, drawing on NIST, ISF, ISO, Basel and PCI. Member Organizations are expected to operate at maturity level 3 or higher.
Source: SAMA Rulebook — Cyber Security Framework · verified 2026-08-04
SWIFT CSP
SWIFT launched the Customer Security Programme in 2016. Connected organisations attest annually against the Customer Security Controls Framework (CSCF, revised yearly), and from 2021 an independent assessment became mandatory for attestations rather than pure self-attestation.
Source: SWIFT — Customer Security Programme (official) · verified 2026-08-11
The framework sets out 32 security controls, of which 26 are mandatory and 6 advisory, resting on three overarching objectives supported by seven security principles. Mandatory controls establish a security baseline for the entire Swift user community; advisory controls are optional best practices Swift recommends. The six advisory controls are 2.5A External Transmission Data Protection, 2.11A RMA Business Controls, 5.3A Staff Screening Process, 6.5A Intrusion Detection, 7.3A Penetration Testing and 7.4A Scenario-based Risk Assessment.
Source: Swift — Customer Security Controls Framework v2026, Detailed Description (1 July 2025) · verified 2026-08-11
Note: The 26/6 split is stated in the document and independently confirmed by counting control identifiers: 32 unique IDs, of which 6 carry the A suffix denoting advisory. Read directly from the document named above. The Swift CSP Document Centre sits behind myswift authentication, so the citation points at the document centre rather than a file URL.
Swift users must attest their compliance through the KYC Security Attestation (KYC-SA) application by the end of each year, against the CSCF in effect at that time. A new CSCF version is published each July and becomes the attestation basis from July of the following year. The document states the position for this cycle directly: users must attest between July 2026 and December 2026 against the controls listed in CSCF v2026, which was published in mid-2025.
Source: Swift — Customer Security Controls Framework v2026, Detailed Description (1 July 2025) · verified 2026-08-11
Note: The v2026 attestation window is therefore open now and closes at the end of December 2026. Users control their own attestation data and may grant counterparties access to view it, which is what makes a weak attestation a commercial problem and not only a compliance one. Read directly from the document named above. The Swift CSP Document Centre sits behind myswift authentication, so the citation points at the document centre rather than a file URL.
Each user must identify which of five reference architecture types most closely matches its deployment, because scope and applicable controls follow from that choice. The types are A1 (user owns the communication interface, and generally the messaging interface), A2, A3, A4 and B. Component or licence ownership is the key differentiator, and where more than one could apply the most comprehensive architecture must be chosen. Swift publishes a CSP architecture decision tree to support the determination.
Source: Swift — Customer Security Controls Framework v2026, Detailed Description (1 July 2025) · verified 2026-08-11
Note: Users owning only a communication interface and no messaging interface still fall under A1. Read directly from the document named above. The Swift CSP Document Centre sits behind myswift authentication, so the citation points at the document centre rather than a file URL.
As announced in the previous version, control 2.4 Back Office Data Flow Security is mandatory in CSCF v2026, activating the phased approach in Appendix H. At minimum a user must now protect the bridging servers guarding flows between its secure zone and the back-office first hops where the exchange is not end-to-end protected, the flows between bridging servers and between bridging servers and the secure zone in the same circumstances, and the new direct flows between the secure zone and the back-office first hop.
Source: Swift — Customer Security Controls Framework v2026, Detailed Description (1 July 2025) · verified 2026-08-11
Note: Security of the legacy direct exchanges — between back-office first hops and bridging servers, or between first hops and the secure zone — remains advisory, with 2028 given as the tentative date for making those flows mandatory and completing control 2.4’s journey. Read directly from the document named above. The Swift CSP Document Centre sits behind myswift authentication, so the citation points at the document centre rather than a file URL.
CSCF v2025 introduced the customer client connector — an endpoint consuming APIs, a middleware or a file transfer client — as an advisory in-scope component. In v2026 it becomes a mandatory in-scope component of fourteen basic cyber-hygiene controls: 1.2, 1.3, 1.4, 2.2, 2.3, 2.6, 2.7, 3.1, 4.1, 4.2, 5.1, 5.4, 6.1 and 6.4. All user endpoints that connect to Swift indirectly through a service provider sharing resources are progressively treated as customer connectors, whether server or client.
Source: Swift — Customer Security Controls Framework v2026, Detailed Description (1 July 2025) · verified 2026-08-11
Note: The document states the consequence plainly: this change “requires some users who previously attested as Architecture type B, to attest as A4 when using a customer client connector.” Architecture B is the narrowest scope and A4 is materially wider, so affected users face a larger assessment this cycle. Read directly from the document named above. The Swift CSP Document Centre sits behind myswift authentication, so the citation points at the document centre rather than a file URL.
Control 2.3 System Hardening now names Windows Management Instrumentation and PowerShell as native OS features to consider when shielding a Windows system. Control 2.9 Transaction Business Controls recognises Swift Universal Confirmation as a validation or reconciliation option alongside MT 900/910 and MT 940/950. Control 4.2 requires multi-factor authentication on one authentication stage for external privileged access managing firewalls, and Alliance Left and Right Security Officer accounts are now named as privileged accounts. Control 6.1 Malware Protection advises protecting non-Windows systems inside a secure zone or hosting a customer client connector. Control 7.2 Security Training and Awareness adds deepfakes as an example of AI-based threats.
Source: Swift — Customer Security Controls Framework v2026, Detailed Description (1 July 2025) · verified 2026-08-11
Note: Swift states that at publication there is no specific guidance on using AI-based tools to support CSP controls, and that the same care applies to any tool handling the confidentiality, integrity and availability of processed data. Alliance Access Integration Platform (IPLA) and Swift Integration Layer (SIL) are expected to reach end of life in 2026 but remain in scope until then. Read directly from the document named above. The Swift CSP Document Centre sits behind myswift authentication, so the citation points at the document centre rather than a file URL.
CKYC (CERSAI)
The Master Direction defines the Central KYC Records Registry (CKYCR) as “an entity defined under Rule 2(1) of the Rules, to receive, store, safeguard and retrieve the KYC records in digital form of a customer”. The Central Registry of Securitisation Asset Reconstruction and Security Interest of India (CERSAI) was authorised to act as and perform the functions of the CKYCR by Gazette Notification No. S.O. 3183(E) dated 26 November 2015.
Source: RBI — Master Direction, Know Your Customer (KYC) Direction, 2016 (updated 14 August 2025) · verified 2026-08-07
Note: “the Rules” means the Prevention of Money-Laundering (Maintenance of Records) Rules, 2005.
Under Rule 9(1A) of the PML Rules, regulated entities shall capture the customer’s KYC records and upload them onto the CKYCR within 10 days of commencement of an account-based relationship with the customer.
Source: RBI — Master Direction, Know Your Customer (KYC) Direction, 2016 (updated 14 August 2025) · verified 2026-08-07
Note: The ten days run from commencement of the relationship, not from when the record is judged complete — so a submission rejected on a template error still consumes the window.
The CKYCR live run began on 15 July 2016, phased, starting with new individual accounts. Scheduled Commercial Banks were required to upload KYC data for all new individual accounts opened on or after 1 January 2017 (with an initial allowance to 1 February 2017 for accounts opened during January 2017). Regulated entities other than SCBs were required to start uploading for new individual accounts opened on or after 1 April 2017. KYC records for accounts of Legal Entities opened on or after 1 April 2021 must also be uploaded.
Source: RBI — Master Direction, Know Your Customer (KYC) Direction, 2016 (updated 14 August 2025) · verified 2026-08-07
Note: The Legal Entity obligation is the most recently added and the one most often missing from older CKYC programmes built around individual onboarding.
Regulated entities capture KYC information for sharing with the CKYCR as per the KYC templates prepared for “Individuals” and “Legal Entities”, and those templates may be revised from time to time as released by CERSAI. Operational Guidelines for uploading KYC data are published by CERSAI.
Source: RBI — Master Direction, Know Your Customer (KYC) Direction, 2016 (updated 14 August 2025) · verified 2026-08-07
Note: Because the templates are revised, a validation performed against an older template version is not evidence that current submissions conform.
A customer may satisfy identification by submitting the KYC Identifier together with explicit consent for the regulated entity to download records from the CKYCR, instead of resubmitting officially valid documents. CERSAI asks regulated entities to display the KYC Identifier to customers on passbooks, account statements, mobile and internet banking, insurance policies and demat statements.
Source: RBI — Master Direction, Know Your Customer (KYC) Direction, 2016 (updated 14 August 2025) · verified 2026-08-07
Note: The consent is the control that matters: a download without recorded, retrievable customer consent is an access to third-party personal data with no lawful basis to show an examiner.
Qatar NIA (NCSA)
Qatar's National Cyber Security Agency mandates the National Information Assurance Policy for government entities and critical infrastructure; the current revision is v2.1 (May 2023), superseding v2.0.
Source: NCSA Qatar (official portal) · verified 2026-08-01
Note: Version and date corroborated across Qatar-focused GRC publishers; the NCSA portal hosts the controlled document.
HIPAA (US)
Compliance with the HIPAA Security Rule was required from 20 April 2005 for most covered entities; small health plans had until 20 April 2006.
Source: US HHS — HIPAA Security Rule · verified 2026-08-11
Following discovery of a breach of unsecured protected health information, a covered entity must notify each affected individual “without unreasonable delay and in no case later than 60 calendar days after discovery of a breach”, except where a law-enforcement delay under § 164.412 applies.
Source: eCFR — 45 CFR Part 164 (HIPAA Security and Breach Notification Rules) · verified 2026-08-04
Note: 45 CFR § 164.404(b), quoted verbatim from the eCFR text current as of 31 July 2026. Sixty days is the outer limit, not the standard — unreasonable delay inside that window is itself a violation.
For breaches of unsecured protected health information involving 500 or more individuals, the covered entity must notify the Secretary contemporaneously with the notice to individuals, in the manner specified on the HHS website. For breaches involving fewer than 500 individuals, the entity maintains a log and reports them not later than 60 days after the end of the calendar year in which they were discovered.
Source: eCFR — 45 CFR Part 164 (HIPAA Security and Breach Notification Rules) · verified 2026-08-04
Note: 45 CFR § 164.408(b) and (c). The 500-individual threshold also determines whether a breach appears on the HHS public breach portal.
The Security Rule requires administrative, physical and technical safeguards for electronic protected health information. Administrative safeguards are “administrative actions, and policies and procedures, to manage the selection, development, implementation, and maintenance of security measures”. Physical safeguards are physical measures, policies and procedures protecting information systems and related buildings and equipment. Technical safeguards are the technology and the policy and procedures for its use that protect ePHI and control access to it.
Source: eCFR — 45 CFR Part 164 (HIPAA Security and Breach Notification Rules) · verified 2026-08-04
Note: 45 CFR § 164.304 definitions, quoted from the eCFR text current as of 31 July 2026.
ISO 22301
ISO published ISO 22301:2019/Amd 1:2024 in February 2024, adding consideration of climate change to the management system requirements. ISO 22301:2019 remains the current edition - the amendment supplements it rather than replacing it, and a next edition is in development with no confirmed publication date.
Source: ISO 22301:2019/Amd 1:2024 (iso.org) · verified 2026-08-07
Note: iso.org blocks automated verification; the amendment number, scope and date are corroborated across certification bodies and ISO's own catalogue listing.
ISO 22301:2019 (business continuity management systems) was published 30 October 2019, replacing the 2012 first edition.
Source: ISO 22301:2019 (iso.org) · verified 2026-08-11
Note: iso.org blocks automated verification; date corroborated across certification bodies.
SOC 2 (AICPA)
TSP Section 100 paragraph .14 states that the security category “is addressed in most trust services engagements”, and paragraph .15 adds that “although uncommon, there may be circumstances in which the security category is not addressed by a trust services examination”. Where security IS included, ASEC has determined the common criteria alone are suitable and no additional control activity criteria are needed. Where availability, processing integrity, confidentiality or privacy are included, a complete set consists of the common criteria plus the control activity criteria for that category.
Source: AICPA TSP Section 100, paragraphs .14 and .15 · verified 2026-08-08
Note: Read from TSP Section 100 itself rather than from secondary summaries. This corrects a claim repeated almost universally in secondary sources, which state that Security is mandatory in every SOC 2. The criteria say it is addressed in most engagements and expressly contemplate examinations where it is not.
The common criteria are the criteria shared by all five trust services categories. They comprise 33 individual criteria organised across nine series, CC1 to CC9. Points of focus sit beneath the criteria and describe characteristics that may be considered when evaluating whether a criterion is met; the concept is drawn from COSO’s Internal Control — Integrated Framework, and points of focus are not themselves requirements to be met one by one.
Source: AICPA TSP Section 100 — common criteria and points of focus · verified 2026-08-08
Note: Read from TSP Section 100 itself rather than from secondary summaries. Criterion count derived by enumerating the distinct CC references in the document.
The criteria for a SOC 2 examination are set out in TSP Section 100, “2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (With Revised Points of Focus — 2022)”, established by the AICPA’s Assurance Services Executive Committee (ASEC). They cover five categories: Security, Availability, Processing Integrity, Confidentiality and Privacy. The 2022 revision updated the points of focus rather than the criteria themselves, which is why the document is still titled as the 2017 criteria.
Source: AICPA - 2017 Trust Services Criteria (With Revised Points of Focus - 2022) · verified 2026-08-08
Note: Read from TSP Section 100 itself rather than from secondary summaries. The TSP Section 100 numbering, previously omitted because AICPA’s public page did not confirm it, is stated on the document’s own title page.
AICPA describes the engagement as “SOC 2 - Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy”. It is an examination of controls at a service organisation, reported on by a CPA firm - not a certification issued by AICPA.
Source: AICPA - SOC 2 topic page · verified 2026-08-08
Note: Engagement title read from AICPA's own topic page. That SOC 2 is an examination rather than a certification follows directly from that wording and is worth stating, because clients frequently ask for a “SOC 2 certificate”.
NPCI / UPI
NPCI's volume-cap guidelines for Third-Party Application Providers in UPI (referencing circular NPCI/UPI/OC-97/2020-21) were originally to bite from 31 December 2024. The compliance timeline for existing TPAPs exceeding the cap was extended by two years, to 31 December 2026. Separately, NPCI issued Guidelines on usage of UPI APIs (OC 215 series, May 2025) requiring PSPs and acquiring banks to monitor and control API usage, with non-compliance exposing them to API restriction, penalties or suspension of new customer onboarding.
Source: NPCI UPI circulars (official listing) · verified 2026-08-07
Note: npci.org.in returns HTTP 403 to automated retrieval, so circular text could not be read directly. Circular references, the two-year extension to 31 December 2026 and the OC 215 API guidelines are corroborated across independent regulatory-tracking services. Confirm clause wording against the PDFs before relying on this in a deliverable.
NPCI's Guidelines for Third-Party Application Providers in UPI (circular OC 97, 2020) impose audit and compliance obligations on TPAPs, including audits by CERT-In empanelled auditors and UPI data storage within India; PSP banks retain audit rights over TPAP UPI infrastructure.
Source: NPCI UPI circulars (official listing; OC 97 direct PDF withdrawn) · verified 2026-08-11
Note: The direct OC 97 PDF was removed from npci.org.in (renders NPCI's 404 page; confirmed in a real browser 11 August 2026). The obligations are retained as corroborated facts - multiple compliance analyses and NPCI's own later TPAP circulars reference OC 97 - and the source points at the official circulars listing, the same treatment as the sibling volume-cap entry. If NPCI republishes the circular, restore the direct link.
PCI DSS v4.0.1 — all twelve requirements
PCI DSS v4.0.1 (June 2024) is now the only assessable version — v4.0 retired at the end of 2024 and the future-dated requirements became mandatory on 31 March 2025. What follows is each requirement decoded three ways: the controls that decide the assessment, the failure patterns QSA engagements actually produce, and the evidence that survives sampling. Control numbers cite the standard so every claim can be checked against it.
Requirement 1: Install and Maintain Network Security Controls
Firewalls became "network security controls" in v4 — the requirement now covers any technology that polices traffic between networks, including cloud security groups. What the assessor tests is whether every path into and out of the CDE is known, restricted and reviewed.
A VLAN is not segmentation until a penetration test proves isolation (11.4.5). Flat networks discovered at assessment time re-scope the whole engagement.
v4 explicitly includes cloud NSCs. Six-monthly ruleset reviews (1.2.7) apply to AWS/Azure security groups exactly as to firewalls — most first-year cloud programmes miss this.
1.3.2 restricts egress from the CDE too. Unrestricted outbound is both a finding and the exfiltration path in real breaches.
If the diagram was last touched the week before the assessment, the assessor will test its accuracy against reality — and use discrepancies to expand sampling.
Requirement 2: Apply Secure Configurations to All System Components
Requirement 2 is the hardening requirement: vendor defaults die here. The assessor compares your running configurations against your own hardening standard — so the standard must exist, map to an accepted benchmark, and actually be applied.
A one-page policy saying "systems shall be hardened" fails 2.2.1. The standard must specify settings per platform, traceable to CIS or vendor baselines.
Servers get hardened; the HSM, printer, POS terminal or load balancer keeps admin/admin. Requirement 2 applies to every system component in scope.
"public/private" strings on network devices are a classic 2.2.2 finding that internal vulnerability scans should have caught quarters earlier.
2.2.7 has no temporary exception — unencrypted admin channels are findings the day the assessor sees them.
Requirement 3: Protect Stored Account Data
The requirement with the sharpest teeth: sensitive authentication data must not exist after authorisation, and stored PAN must be unreadable. v4 tightened hashing — a plain hash of PAN no longer counts. Most Requirement 3 findings are data the organisation did not know it had.
Debug logs, crash dumps, CSV exports and ticket attachments are where discovery scans find PAN. If you have not run a data-discovery scan, the assessor’s will be the first — the wrong first.
TDE/BitLocker on a running database server does not satisfy 3.5.1 by itself (3.5.1.2). Column-level encryption, tokenisation or keyed hashing is still needed.
Verification codes may never be stored after authorisation — recurring billing uses credentials-on-file authorisation, not stored CVV. This one finding can end an assessment.
One admin who can reconstruct a clear-text key alone violates split-knowledge/dual-control expectations for manual key operations (3.7.6).
Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission
Short but unforgiving: PAN over open or public networks travels under strong cryptography, and v4 added a certificate inventory so "we use TLS" becomes provable. The findings live at the edges — legacy endpoints, wireless, and people emailing card numbers.
External scans find the forgotten API host or callback URL negotiating old TLS. Configuration must refuse downgrade, not just prefer 1.2.
Without the 4.2.1.1 inventory, cert expiry becomes an outage AND a finding. The inventory is now the evidence of control.
Customers email PANs; agents forward them. Without DLP quarantine + a redaction procedure, this is a live 4.2.2 failure and a Requirement 3 storage problem in mailboxes.
Requirement 5: Protect All Systems and Networks from Malicious Software
v4 modernised the old "antivirus" requirement: coverage decisions must be justified, scan frequency can be risk-based — and anti-phishing controls are now mandatory. The classic failure is the fleet of Linux servers exempted years ago with no documented evaluation.
5.2.3 demands a documented, periodically refreshed justification. "Linux doesn’t get viruses" from 2019 is a finding, not an evaluation.
Awareness training alone does not satisfy 5.4.1 — the control asks for mechanisms: email authentication, filtering, link protection.
If endpoint users can stop the service, 5.3.5 fails regardless of how good the console dashboard looks.
Requirement 6: Develop and Maintain Secure Systems and Software
Two disciplines in one requirement: fixing known vulnerabilities fast, and not shipping new ones. v4 added the controls e-commerce breaches begged for — an authoritative inventory of payment-page scripts and automated protection for public web applications.
E-commerce entities routinely miss 6.4.3 — tag managers and third-party scripts on checkout with no inventory, justification or integrity monitoring.
6.4.2 requires detect AND prevent. A WAF that only alerts fails the control since the March 2025 date.
A policy saying 30 days without a report proving it invites sampling — and sampled hosts rarely cooperate.
6.5.5 prohibits production PAN in pre-production; masked or synthetic data only.
Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know
Requirement 7 is the access-model requirement: who may see what, and why. v4 added the discipline that was always implied — semi-annual reviews of all user accounts and explicit governance of application/system account privileges.
The single most common v4 gap in year one: 7.2.4 needs evidence of the review itself — account listings, reviewer sign-off, and the removals that resulted.
Nested groups accumulated over years make least-privilege unprovable. The assessor asks "why does this role have this?" — the model must answer.
7.2.5 exists precisely for the integration account granted DA in 2019. Least privilege applies to non-humans too.
Requirement 8: Identify Users and Authenticate Access
The requirement most changed by v4 — MFA now applies to ALL access into the cardholder data environment, not just remote logins. Here is what each control demands, the evidence a QSA actually accepts, and where first-year programmes fail.
v4.0.1 requirement 8.4.2 extends MFA to all CDE access — internal console logins included. Programmes that certified under v3.2.1 and never re-scoped fail here first.
Network devices are system components. A shared enable password without individual attribution violates 8.2.1/8.2.2 even if a bastion logs the session.
If a human can log in with it, 8.6.1 applies: documented approval, time-bound justification and accountability — or disable interactive use.
The assessor needs configuration exports (GPO, PAM policy, IdP settings) and observation, not a policy PDF. Screenshots of the actual enforced settings are the evidence.
Requirement 8 intersects 2.2/2.3: default accounts on POS terminals, HSMs and appliances must be removed or rekeyed — a favourite finding in first-year assessments.
Requirement 9: Restrict Physical Access to Cardholder Data
The requirement people forget until the walkthrough: badge readers, visitor logs, media destruction — and for anyone operating card-present channels, the POI-device controls whose inspection logs assessors always ask to see.
Without dated inspection records per device, 9.5.1.2 fails — the log IS the control’s evidence.
Missing sign-outs and unlogged escorts turn a formality into a finding; logs must survive a 90-day retention check.
Decommissioned drives and shredded documents need evidence — certificates of destruction or internal records with method and date.
9.3.1 requires prompt revocation; the assessor reconciles HR leaver lists against the badge system.
Requirement 10: Log and Monitor All Access to System Components and Cardholder Data
Requirement 10 decides whether a breach is a bad week or an existential event. v4’s change with operational bite: daily log review must use automated mechanisms — a human eyeballing syslog no longer scales or complies.
A SIEM full of unreviewed events fails 10.4.1 exactly as loudly as no SIEM — the evidence is triage records and tickets, not license spend.
Databases holding PAN and the application tier are the classic gaps; assessors reconcile SIEM sources against the asset inventory.
Storage pressure trims logs to 30-90 days; 10.5.1 requires 12 months, three immediately searchable.
10.7 asks what happens when the SIEM agent, FIM or IDS dies — silence for a week is itself the finding.
Requirement 11: Test Security of Systems and Networks Regularly
The requirement that generates the calendar: quarterly scans inside and out, annual penetration tests, segmentation validation — plus v4’s newcomers, authenticated internal scanning and tamper detection on payment pages.
External-only scanning is half the control; 11.3.1 internal quarterly scans with rescan evidence are sampled first.
Post-March-2025, scans without credentials (where feasible) fail 11.3.1.2 — and miss most of what matters.
A pentest that never attempts to cross segment boundaries cannot support 11.4.5; scope language decides this before testing starts.
11.6.1 requires tamper detection on payment pages — CSP reporting, integrity monitoring or equivalent, alerting at least weekly.
Requirement 12: Support Information Security with Organizational Policies and Programs
Everything the other eleven requirements assume: policy, risk analysis, awareness, third parties, incident response. v4 moved real weight here — targeted risk analyses now justify half the standard’s frequencies, and scope must be confirmed annually in writing.
12.8.5 wants, per provider, which requirements they cover vs you — an AOC on file alone does not answer it.
Choosing "weekly" for a flexible control without the TRA behind it fails 12.3.1 across every control that leaned on it.
The annual scope confirmation (12.5.2) needs a dated artefact: data flows, people, processes, technologies, third parties.
A tabletop with attendance, scenario and lessons-learned is the minimum evidence for 12.10.2 — an unopened PDF is not a capability.
ISO/IEC 27001:2022 — Annex A in four themes
The 2013-to-2022 transition ended on 31 October 2025; every certification audit now runs against the 93-control, four-theme Annex A — including the eleven controls added in 2022 that paper-migrated ISMS documentation reliably fails. Each theme below follows the same decode: key controls, failure patterns, and the note that matters for scope.
Annex A.5: Organizational Controls (37 controls)
The largest theme — 37 controls covering policy, roles, supplier risk, cloud, incident management and legal compliance. This is where the 2022 revision added the controls auditors now probe hardest: threat intelligence, cloud service security and ICT readiness for business continuity.
A.5.7 evidence must show intelligence being assessed and acted on — a risk-register update, a rule change, a patch decision — not an unread inbox folder.
A.5.23 expects per-service governance: which cloud services, what data, who owns the relationship, shared-responsibility matrix, exit plan.
Contracts sampled by auditors routinely predate the ISMS and carry no security, breach-notification or audit-rights language (A.5.20).
Zero recorded incidents in a year reads as "not detecting", not "secure". Near-misses and lessons-learned records prove A.5.26/5.27 operate.
Annex A.6: People Controls (8 controls)
Eight controls, one theme: the human layer — screening, terms, awareness, discipline, remote working and reporting. Small count, but the controls auditors verify through interviews rather than documents, which is why unprepared organisations fail them in the corridor, not the audit room.
Auditors sample joiners and ask for verification records; "HR does it" without artefacts fails A.6.1 — especially for contractors, who are routinely skipped.
A.6.3 asks for role-relevant content and effectiveness measurement — phishing-simulation results, quiz outcomes, targeted refreshers.
The interview question that decides A.6.8: "you see something suspicious — what do you do?" A hesitant answer outweighs a beautiful procedure document.
A.6.5 needs exit communication evidence — a checklist item confirming post-employment duties were restated at departure.
Annex A.7: Physical Controls (14 controls)
Fourteen controls from perimeters to clear desks. The 2022 addition — physical security monitoring — formalised what assessors already expected: premises watched, not just locked. For cloud-first organisations this theme shrinks but never disappears: offices, endpoints and the paper on desks stay in scope.
A.7.4 is about monitoring as a process — retention period, who reviews, what triggers escalation — not camera count.
Uncontrolled physical keys to secure areas defeat every badge-system control upstream (A.7.2/7.3).
Clear desk/screen (A.7.7) is the finding auditors photograph. One sticky note in a sampled bay becomes a nonconformity.
A.7.14 needs per-asset evidence — certificates or logged internal wipes reconciled against the asset register.
Annex A.8: Technological Controls (34 controls)
The engineering theme: 34 controls from endpoint protection to secure coding. Eight of the eleven controls new in 2022 live here — configuration management, information deletion, data masking, DLP, activity monitoring, web filtering and secure coding — which is why 2013-era ISMS documentation fails a 2022 audit without real uplift.
The 2022 additions (8.9–8.12, 8.16, 8.23, 8.28) need implemented controls, not a re-mapped SoA. Auditors open with the new controls precisely because paper migrations fail there.
A.8.8 evidence is the full loop: scan → risk evaluation → fix within defined timelines → verification. A folder of PDFs is half a control.
A.8.12 asks for detection AND prevention/response on real channels — sampled alerts with disposition beat a licence invoice.
A.8.10 requires demonstrable deletion when data is no longer required — retention schedule plus executed deletion records; "we keep everything" is now a nonconformity.
SOC 2 — the five Trust Services categories
SOC 2 is an attestation issued by a licensed CPA firm against the AICPA Trust Services Criteria — Security is mandatory in every report; the other four categories follow the commitments you make to customers. The criteria below are decoded for the Type II reality: an observation period, sampled across months, where a control implemented late produces exceptions for every month before it.
Security (Common Criteria) (CC1–CC9) — required in every report
The mandatory category — every SOC 2 examination includes the Common Criteria, whatever else is in scope. CC1–CC5 inherit the COSO internal-control framework; CC6–CC9 carry the technical weight: access, operations, change management and vendor risk. This is ~80% of a typical SOC 2 effort.
Type II covers an observation window (commonly 6–12 months). A control implemented in month 5 of a 6-month window produces exceptions for months 1–4 — sequencing readiness matters.
The classic CC6.2/6.3 exception: leavers with active accounts days or weeks after exit. Auditors reconcile HR lists against IdP logs across the whole period.
CC8.1 samples changes across the period; emergency changes without retrospective approval are the most common exception in engineering-led teams.
CC9.2 needs vendor risk assessments, security terms and periodic review — a spreadsheet of names satisfies nobody.
Availability (A1)
Three criteria with heavy operational implications: capacity, environmental protections and backup, and tested recovery. In scope whenever your customer commitments include uptime — which for SaaS is nearly always. The evidence is engineering telemetry, not policy prose.
A1.3 is the criterion that fails: auditors want dated restore-test evidence. An untested backup is a hope, not a control.
If you commit 99.9% to customers, evidence must show you measure it — uptime reporting tied to the commitment, with incident impact recorded.
Cloud inheritance is legitimate but must be documented: which A1.2 protections come from the provider (their SOC 2), which remain yours.
Processing Integrity (PI1)
The category for systems whose value IS the correctness of processing — payments, payroll, billing, data pipelines. Five criteria trace the data path: objectives, inputs, processing, outputs and storage. Scoped in when customers rely on your processing being complete, valid, accurate and timely.
PI1.3 samples exception handling: failed jobs and dead-letter queues with no documented resolution are direct exceptions.
Input/output completeness needs recorded reconciliations — counts, totals, control files — not an engineer’s assurance that the pipeline is fine.
PI adds real evidence burden; include it when customer commitments depend on processing correctness, not because it sounds thorough.
Confidentiality (C1)
Two criteria, deceptively simple: identify and protect confidential information, then dispose of it provably. Scoped in when contracts carry confidentiality commitments — which is most B2B paper. The work is classification discipline and deletion evidence.
C1.1 fails when sampled repositories show no evidence anyone applies the classification — the policy exists, the discipline does not.
Customer offboarding that contractually promises deletion needs execution records per tenant — the C1.2 sample auditors now routinely take.
Copies in BI tools, support tickets and spreadsheets escape the protection the primary store has — discovery before the auditor’s walkthrough finds it for you.
Privacy (P1–P8)
The largest optional category: eight criteria tracking personal information from notice to enforcement. Scoped in when you make privacy commitments about personal data you collect directly. For Indian entities the mapping to DPDP duties is close — notice, consent, retention, access and erasure all have statutory twins.
Privacy criteria centre on commitments to data subjects — usually the controller’s role. Processors typically serve privacy through Confidentiality + contractual commitments; scoping P1–P8 wrongly doubles the work.
The privacy notice promises X; telemetry collects Y. Auditors read the notice and trace actual flows — the gap is the exception.
P4.3/P5 commitments require operational deletion/access workflows with records — the same machinery DPDP requires, which is why building it once for both is the efficient path.
NIST CSF 2.0 — six functions
CSF 2.0 (26 February 2024) matters in India for a specific reason: SEBI’s CSCRF is structured on its functions, and RBI and IRDAI expectations map onto them cleanly. A CSF profile is the closest thing to a common backbone across Indian regulatory conversations. The framework is voluntary guidance — profiles, not certificates — and each function below is decoded to the category level.
Govern (GV)
The function CSF 2.0 added — and put first. Governance moved from a category buried in Identify to the function that wraps all others: context, risk strategy, roles, policy, oversight and supply chain. If your CSF 1.1 profile predates 2024, this is where the rewrite starts.
Govern is not a rename — GV.SC and GV.OV contain expectations 1.1 never had. Mapping old ID.GV rows across and calling it 2.0 collapses under review.
GV.RM is tested by decisions: can anyone show a choice that changed because of the stated tolerance?
GV.SC expects cyber criteria in selection, contractual obligations, and coordination when a supplier has an incident.
Identify (ID)
You cannot protect what you have not enumerated. Identify holds asset management, risk assessment and — new emphasis in 2.0 — improvement. Its quality decides whether every downstream function operates on reality or on an outdated spreadsheet.
ID.AM evidence is a reconciled inventory — discovery scans vs records vs finance — not a stale export. Unknown assets void downstream controls.
ID.RA expects risks with owners, responses and review dates; a register whose entries have not changed in a year documents a process that stopped.
2.0 emphasises data and its flows (ID.AM); DPDP and sectoral rules ask for the same map — one exercise serves both.
Protect (PR)
The engineering function: identity and access, awareness, data security, platform security and infrastructure resilience. CSF 2.0 reorganised it — platform security (PR.PS) and infrastructure resilience (PR.IR) are the categories where 1.1-era profiles have the most unmapped ground.
PR.AA holds up only when every access path is listed with its authentication strength — the same exercise PCI 8.4.2 forces, reusable here.
PR.DS includes tested backups; an untested backup is the finding every framework writes the same way.
PR.PS expects configurations managed over time — baseline plus monitoring, not a golden image from two years ago.
Detect (DE)
Two categories with one question behind them: would you know? Continuous monitoring across networks, endpoints, personnel activity and services — and the analysis discipline that turns anomalies into declared incidents fast enough to matter.
DE.CM in 2.0 explicitly includes external service providers; audit logs from critical SaaS left uncollected is the modern blind spot.
DE.AE expects defined thresholds for when an anomaly becomes an incident; without them, response starts late and inconsistently.
A queue with thousands of unreviewed alerts is documentation of detection NOT operating — tuning records are part of the evidence.
Respond (RS)
Four categories covering the hours that decide breach outcomes: incident management, analysis, communication and mitigation. For Indian entities this function carries statutory weight — CERT-In’s 6-hour reporting window and sectoral timelines live inside RS.CO.
RS.CO fails when the 6-hour CERT-In window is looked up during the breach; the reporting matrix (who, what, when, how) must pre-exist and be drilled.
Rebuilding a compromised host before imaging it satisfies RS.MI while destroying RS.AN — the runbook must sequence preservation before eradication where feasible.
Tabletops with lessons-learned records are the difference between a plan and a capability; every framework samples them.
Recover (RC)
The shortest function with the most expensive failures: executing recovery plans and communicating during restoration. Recovery is where untested backups, undocumented dependencies and silent stakeholders turn a contained incident into a prolonged outage.
RC.RP includes verifying backup integrity and system cleanliness before restoration — restoring from a backup taken after initial compromise re-infects the environment.
Without criticality-driven restoration priorities (fed by ID.AM), teams restore what is easy instead of what the business needs first.
RC.CO failures compound reputational damage; stakeholders fill communication vacuums with worst-case assumptions.
Build once, comply many times
Read chapters 4 through 7 side by side and the overlap is the story. MFA scoped properly once satisfies PCI 8.4.2, feeds ISO A.5/A.8 access evidence, answers SOC 2 CC6 and lands inside CSF PR.AA. A tested backup-and-restore discipline is PCI 12.10/ISO A.5.30/SOC 2 A1.3/CSF RC.RP — one exercise, four evidence trails. A retention-and-deletion machine built for DPDP section 8(7) is the same machinery SOC 2 C1.2 and P4.3 sample and ISO A.8.10 now demands. The organisations that suffer are the ones that run five parallel programmes with five spreadsheets; the ones that don’t, build the control once and map the evidence outward.
The sequencing that follows from the dates: statutory obligations first (DPDP, CERT-In, sector regulators — they carry penalties and clocks), the revenue-driven attestations second (PCI, ISO, SOC 2 — they carry deals), and the profile framework (CSF) as the connective tissue that keeps the map coherent. The registry’s timeline in chapter 2 is effectively that plan with dates attached.
Continuous evidence is what makes the single-programme model real rather than aspirational — controls monitored between audits, evidence collected as a by-product of operations, gaps visible before the assessor finds them. That operating model is what CyberSigma’s SigmaTrust platform exists to run; the argument for it, however, stands on the framework text alone.
Method, sources and how to cite this report
Every factual claim in chapters 2–3 traces to a primary source linked at the claim: Gazette notifications, regulator publications, standards-body documents. Framework decodes in chapters 4–7 cite control identifiers against the named versions (PCI DSS v4.0.1; ISO/IEC 27001:2022; AICPA TSC 2017 with 2022 points of focus; NIST CSF 2.0) so any statement can be checked against the standard itself. Where sources conflict, the conflict is stated in the entry note.
This report is compiled from the open India Compliance Registry (v1.25.0, updated 2026-08-11) and CyberSigma’s framework series data modules — the same data that renders the website, which is why report and site cannot diverge. The registry changelog is append-only; corrections are recorded, never silently applied. The full editorial policy is published at cybersigmacs.com/editorial-policy/.
Cite as: CyberSigma Consulting Services, “The India Compliance Reference 2026”, registry v1.25.0, cybersigmacs.com/research/india-compliance-reference-2026/. Registry content is CC BY 4.0 — reuse with attribution. Found an error? Report it via the contact page; confirmed corrections are appended to the registry changelog.
← CyberSigma Research · India Compliance Registry · Deadlines tracker