{"name":"CyberSigma India Compliance Registry","version":"1.25.0","updated":"2026-08-11","license":"CC BY 4.0 — https://creativecommons.org/licenses/by/4.0/","attribution":"CyberSigma — https://cybersigmacs.com/compliance-registry/","changelog":[{"date":"2026-08-11","change":"v1.25.0: deepened CMMC and UAE PDPL from primary sources. CMMC 1->4: the three-level structure (L1 FCI/17 practices self-assessed; L2 CUI/110 NIST SP 800-171 R2 controls C3PAO-assessed; L3 highest CUI/NIST SP 800-172 subset DIBCAC-assessed), the 32 CFR Part 170 final rule (effective 16 Dec 2024), the phased DFARS rollout (Phase 1 from 10 Nov 2025, Level 2 certification in contracts from 10 Nov 2026), and applicability across the Defense Industrial Base - current-verified given the shifting timeline. UAE PDPL 2->4: lawful processing and consent (Articles 4-6) and the enforcement structure (complaints Art 24, penalties Art 26, and the Executive Regulation provision Art 28), read from the official legislation portal; the Art 28 fact records that the law provides for Executive Regulations without asserting the contested issuance date."},{"date":"2026-08-11","change":"v1.24.0: deepened the thin frameworks a coverage audit flagged, from primary sources. NCA ECC (Saudi) 2->5 facts read from the official ECC-2:2024 PDF: the full 4-domain/28-subdomain breakdown, the independent-cybersecurity-department and all-Saudi-staffing governance controls (1-2 per High Order 37140), and the four-part control coding scheme. GDPR 3->6 with Records of Processing (Art 30), DPIA (Art 35-36) and DPO (Art 37-39), cited to the consolidated EUR-Lex text. OWASP ASVS gains the v5.0 17-chapter structure (V1-V17) read from the ASVS 5.0 repository, noting the substantial restructure from v4.0.x."},{"date":"2026-08-11","change":"v1.23.0: GCC expansion for the India-to-global programme, from documents read today. UAE PDPL upgraded from official summaries to the issuing legislation portal (uaelegislation.gov.ae) with gazette metadata (issued 20 Sep 2021, Gazette No. 712 supplement, effective 2 Jan 2022, listed Active) plus a new article-map entry covering DPO, breach reporting, data-subject rights, DPIA and cross-border transfer. NCA ECC gains a compliance-mechanism entry (Article 10(3) continuous compliance; self-assessment, compliance-tool reports and field audits; cloud Subdomain 4-2 binding), read from the official ECC-2:2024 PDF, whose structure figures were independently re-confirmed. SAMA deliberately untouched: the framework PDF endpoint returns an error page even in a real browser today, so the rulebook-sourced entry stands unimproved rather than being filled from secondaries."},{"date":"2026-08-11","change":"v1.22.1: weekly health remediation. All 14 flagged sources opened in a real browser: 13 confirmed present and re-verified (including the UIDAI AUA/KUA PDF, which the automated check had reported dead - the WAF serves bots HTML but browsers get the PDF). One source genuinely dead: NPCI removed the OC 97 direct PDF; that entry now cites the official UPI circulars listing with the withdrawal noted, matching the sibling entry's treatment. Also fixed: the public GitHub dataset mirror had drifted nine versions behind the site (1.13.0 vs 1.22.0) - synced, and the website deploy now pushes the mirror automatically on version change."},{"date":"2026-08-08","change":"v1.22.0: recorded ISO/IEC 27001:2022 bibliographic identity (third edition, October 2022). Content deliberately NOT recorded: the copy available was watermarked as licensed to another organisation and the standard forbids reproduction without permission, so Annex A control counts, clause structure and requirement text are excluded until a copy licensed to CyberSigma is available. The cluster stays thin rather than being filled from material we are not licensed to use."},{"date":"2026-08-08","change":"v1.21.0: SOC 2 completed from TSP Section 100 itself. Confirms the TSP Section 100 numbering and ASEC as the issuing committee, both previously omitted. Records the common criteria structure (33 criteria, CC1-CC9) and CORRECTS a near-universal secondary claim: the criteria say the security category is addressed in MOST engagements and expressly contemplate examinations where it is not, rather than making it mandatory."},{"date":"2026-08-08","change":"v1.20.0: IRDAI 2026 entries upgraded from corroborated to read-from-the-document (VER 2.0, April 2026, 175 pages). CORRECTED the applicability entry: it had listed brokers, corporate agents, web aggregators, TPAs, ISNPs and IIB from secondary summaries, but the guidelines say Insurers including FRBs and Insurance Intermediaries, and expressly EXCLUDE agents, micro-insurance agents, PoSPs and individual surveyors. Added auditor eligibility (Annexure IV — CERT-In empanelled with CISA/DISA is an accepted route), the 90-day/30-day submission deadline, and the bar on management-representation reliance."},{"date":"2026-08-08","change":"v1.19.0: opened the SOC 2 cluster - the largest revenue line with no registry coverage. Only two entries, both sourced from aicpa-cima.com. The detail clients ask about (which category is mandatory, Type 1 versus Type 2, the SSAE 18 / AT-C 205 basis) is not on AICPA's public pages and sits in its paid guide, so it is left OUT rather than written from secondary summaries. SOC 2 turns out to carry the same paywall constraint as ISO."},{"date":"2026-08-08","change":"v1.18.0: added the DPDP Consent Manager framework - Rule 4 in force 13 November 2026, First Schedule Part A eligibility and Part B obligations. MeitY blocks automated retrieval (403), so these are corroborated rather than primary-read and each entry says so. The February 2026 amendment rules are NOT recorded as affecting Rule 4: sources disagree on whether that instrument touches DPDP at all."},{"date":"2026-08-07","change":"v1.17.0: recorded Regulation (EU) 2026/1744 (Digital Omnibus on AI, in force 27 July 2026), which postpones Annex III high-risk obligations from 2 August 2026 to 2 December 2027 and Annex I embedded-product obligations to 2 August 2028, and adds Article 5 prohibitions on non-consensual intimate imagery. The Article 111 and 113 entries are retained as the enacted text and now cross-reference the amendment. Found because the freshness monitor flagged the page at 86 days against a 30-day SLA."},{"date":"2026-08-07","change":"v1.16.0: swept the unguarded single-entry clusters after the IRDAI supersession was missed. Added ISO 22301:2019/Amd 1:2024 and NPCI's TPAP volume-cap deadline of 31 December 2026 plus the OC 215 UPI API guidelines; named the governing Aadhaar regulations and flagged the unread 2025 amendment; recorded the UAE PDPL executive-regulations question as open rather than asserting a contested date."},{"date":"2026-08-07","change":"v1.15.0: IRDAI Information and Cyber Security Guidelines, 2023 were superseded on 6 April 2026 by the Information and Cybersecurity Guidelines, 2026 (Version 2.0) - added the current entry and restated the 2023 one as superseded history. Replaced the ISNP entry's homepage citation with an actual IRDAI circular evidencing the governing e-commerce guidelines, and added the CERT-In empanelled expert audit option the previous text omitted."},{"date":"2026-08-07","change":"v1.14.0: consolidated the IRDAI cluster — three framework labels (IRDAI, IRDAI (ISNP), IRDAI (India insurance)) merged to one, and removed a duplicate of the Information and Cyber Security Guidelines, 2023 that cited the same instrument, date and source URL as the fuller entry. IRDAI facts now render on /irdai-cybersecurity-audit/, where previously none did."},{"date":"2026-08-07","change":"v1.13.0: CKYC (CERSAI) added — 5 entries read from the RBI Master Direction on KYC, 2016 (updated 14 August 2025). Covers CERSAI’s designation as the Central KYC Records Registry by Gazette Notification S.O. 3183(E) of 26 November 2015, the Rule 9(1A) ten-day upload obligation, the phased applicability from the 15 July 2016 live run through to Legal Entity accounts opened on or after 1 April 2021, the Individuals and Legal Entities templates CERSAI revises, and the KYC Identifier download-with-consent mechanism. Added because clients are asking for the service, not because search demand was measurable — with no prior CKYC content the site could not appear for those queries at all."},{"date":"2026-08-05","change":"v1.12.0: SWIFT CSP 1 entry -> 7, read from the Customer Security Controls Framework v2026 Detailed Description (1 July 2025). Added the 32-control structure (26 mandatory, 6 advisory, verified both from the stated figure and by counting control identifiers); the KYC-SA attestation window of July to December 2026 against v2026; the five reference architecture types; and the two structural v2026 changes — control 2.4 Back Office Data Flow Security becoming mandatory under the Appendix H phased approach with legacy flows advisory until a tentative 2028, and customer client connectors becoming mandatory in scope for fourteen controls, which moves some users from architecture type B to A4."},{"date":"2026-08-04","change":"v1.11.0: PCI DSS 12 entries -> 20. SAQ eligibility criteria added for all nine merchant SAQs plus SAQ D for Service Providers, read from the SAQ Instructions and Guidelines v4.0.1 r1 (April 2025) and the individual v4.0.1 SAQs. Notably, revision r1 of April 2025 ADDED two e-commerce eligibility criteria to SAQ A — payment-page elements must originate only and directly from a compliant third party, and the merchant must confirm its site is not susceptible to script-based attacks — so a merchant that qualified for SAQ A before April 2025 may no longer qualify. Also recorded: SAQs are assessed per payment channel; only SAQ A and A-EP cover e-commerce; and every SAQ except SAQ D for Service Providers excludes service providers."},{"date":"2026-08-04","change":"v1.10.0: the five ungated frameworks deepened from 1 entry each to 5, 4, 3, 4 and 3. NIST CSF: six Functions, Core size of 22 Categories and 106 Subcategories counted from the identifiers in NIST CSWP 29, the four Tiers quoted verbatim, and the outcomes-not-controls point that explains why the CSF is not certifiable. EU AI Act: the Article 113 staggered application dates (general application began 2 August 2026), the three Article 99 penalty tiers, and the Article 111 transitional deadlines running to 31 December 2030. GDPR: the Article 33 72-hour breach notification and both Article 83 fine tiers. HIPAA: the 60-calendar-day individual notice, the 500-individual threshold for reporting to the Secretary, and the three classes of Security Rule safeguard, all from the eCFR text current as of 31 July 2026. OWASP ASVS: 345 requirements across 17 chapters and the L1/L2/L3 split, computed from the 5.0.0 requirement set."},{"date":"2026-08-04","change":"v1.9.0: PCI DSS 4 entries -> 12, from four PCI SSC documents read in full: the v4.x ROC Template FAQs (rev 1, Dec 2022), the v4.0 DESV Supplemental ROC Template (rev 1, Dec 2022), the v4.x Targeted Risk Analysis Guidance (Nov 2023) and Best Practices for Maintaining PCI DSS Compliance v2.0 (Jan 2019). Added the two assessment approaches and the compensating-control boundary; the four per-requirement findings; the three overall results plus full/partial scope; ROC Template mandatory use and personalisation limits; both kinds of targeted risk analysis; PCI SSC’s suggested TRA frequencies for nine requirements; DESV applicability and cadences; and the three-year evidence-retention recommendation. Three of the four documents sit behind PCI SSC’s licence gate, so they are cited by exact title, revision and date against the document library."},{"date":"2026-08-04","change":"v1.8.1: PCI DSS 2 entries -> 4. Added the ten published SAQs (A, A-EP, B, B-IP, C, C-VT, D Merchant, D Service Provider, P2PE, SPoC) and the existence of Integrating Artificial Intelligence in PCI Assessments Guidelines v1.0, both taken from PCI SSC’s own document library and API. The standards themselves sit behind a licence-acceptance gate that blocks automated retrieval, so SAQ eligibility criteria, RoC thresholds and control detail are deliberately NOT recorded — they cannot yet be read from the primary documents."},{"date":"2026-08-04","change":"v1.8.0: SEBI CSCRF deepened from 1 entry to 8, every fact read directly from the SEBI circular PDFs. sebi-cscrf-issued is upgraded from FAQ-plus-analyses to the operative extension circular 2025/96 itself. Added: the five RE categories; the requirement that all audits be conducted by a CERT-In empanelled IS auditing organization; VAPT periodicity by NCIIPC designation; VAPT report, closure and revalidation deadlines; the SOC mandate and Market SOC route; Cyber Capability Index applicability; and the 28 August 2025 technical clarifications."},{"date":"2026-08-04","change":"v1.7.3: nca-ecc now cites the ECC – 2 : 2024 control document itself rather than the implementation guide. The 108 main controls figure removed in v1.7.2 is restored, having been verified verbatim in the source, and 92 subcontrols added — a figure the entry never carried. Scope wording aligned to the document's own Scope of Work section."},{"date":"2026-08-04","change":"v1.7.2: sama-csf and nca-ecc re-sourced to live primary documents. SAMA withdrew its framework PDF; the entry now cites the SAMA Rulebook page carrying the framework text, and the applicability statement is corrected to include credit bureaus and the Financial Market Infrastructure. nca-ecc previously cited the NCA homepage rather than a document; it now cites NCA's published ECC implementation guide, and the unsourced '108 main controls' figure is removed because that guide does not state a control count."},{"date":"2026-08-04","change":"v1.7.1: aua-kua-audit re-sourced. UIDAI withdrew the AUA/KUA Agreement v4.0 PDF (now 404), so the fact was pointed at UIDAI's current compliance checklist for controls an AUA/KUA must have in place, which states the annual IS audit obligation directly. The stated fact is unchanged; only its citation moved."},{"date":"2026-08-02","change":"v1.7.0: added IRDAI Information and Cyber Security Guidelines 2023 (primary: irdai.gov.in) and NPCI UPI TPAP audit obligations (OC 97; NPCI portal blocks automated retrieval - verified via the official circular listing and corroborating analyses)."},{"date":"2026-08-01","change":"v1.6.0: added DPDP notice contents (s.5(1), verified from the Gazette), HIPAA Security Rule compliance date, and ISO 22301:2019 publication."},{"date":"2026-08-01","change":"v1.5.0: added DPDP Rules breach-notification timeline (Rule 7: without delay + 72-hour detailed report), RBI Cyber Security Framework for Banks (2 June 2016; 2-6 hour incident reporting), and GDPR application date (25 May 2018)."},{"date":"2026-08-01","change":"v1.4.0: added SWIFT CSP (launched 2016; independent assessment mandatory from 2021), Qatar NIA Policy v2.1 (May 2023), and RBI Digital Payment Security Controls Master Direction (Feb 2021)."},{"date":"2026-08-01","change":"v1.3.0: added SAMA Cyber Security Framework (May 2017), Saudi NCA ECC-1:2018 / ECC-2:2024, US CMMC programme and acquisition rule dates, and UAE PDPL (Federal Decree-Law 45/2021)."},{"date":"2026-08-01","change":"v1.2.0: added RBI IT Governance Master Direction (Nov 2023), RBI IT Outsourcing Master Direction (Apr 2023), IRDAI Information & Cyber Security Guidelines 2023, ISO/IEC 42001:2023 publication, EU AI Act commencement and GPAI dates."},{"date":"2026-08-01","change":"v1.1.0: added DPDP penalty schedule (verified from the Gazette), SEBI CSCRF issuance and timelines, RBI payment-data localisation, PCI DSS v4.x lifecycle dates, ISO/IEC 27001:2022 transition end, NIST CSF 2.0 release."},{"date":"2026-08-01","change":"Initial public release: DPDP Act & Rules phasing, CERT-In Directions obligations, Aadhaar AUA/KUA and IRDAI ISNP audit duties, PCI DSS and OWASP ASVS current versions."}],"entries":[{"id":"cobit-2019","framework":"COBIT 2019","fact":"ISACA enterprise IT governance framework","value":"COBIT 2019 is ISACA's framework for the governance and management of enterprise information and technology, and the successor to COBIT 5. It is built around six governance principles and 40 governance and management objectives grouped into five domains (Evaluate-Direct-Monitor, Align-Plan-Organise, Build-Acquire-Implement, Deliver-Service-Support, and Monitor-Evaluate-Assess). It is designed to be tailored to an organisation's size, strategy, risk profile and sourcing model using components such as processes, structures, policies, information, skills and culture, and applies to any enterprise seeking to align IT with business goals while balancing value, risk and resources.","source":{"label":"ISACA - COBIT","url":"https://www.isaca.org/resources/cobit"},"lastVerified":"2026-08-13"},{"id":"nist-privacy-framework","framework":"NIST Privacy Framework","fact":"Voluntary privacy risk-management framework (v1.0)","value":"The NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management (Version 1.0) is a voluntary framework from the U.S. National Institute of Standards and Technology to help organisations identify and manage privacy risk. It is organised into five functions (Identify-P, Govern-P, Control-P, Communicate-P and Protect-P) subdivided into categories and subcategories, and is designed to align structurally with the NIST Cybersecurity Framework. It is technology-, sector- and law-agnostic and can be used by organisations of any size.","effective":"2020-01-16","source":{"label":"NIST - Privacy Framework v1.0 (CSRC)","url":"https://csrc.nist.gov/pubs/itlb/2020/06/nist-privacy-framework/final"},"lastVerified":"2026-08-13"},{"id":"nist-sp-800-207-zta","framework":"NIST SP 800-207 (Zero Trust)","fact":"Zero Trust Architecture","value":"NIST Special Publication 800-207, Zero Trust Architecture, is a U.S. NIST publication defining zero trust concepts and an abstract model of components, deployment scenarios and use cases for enterprises adopting zero trust. It describes zero trust as moving defences from static network perimeters to focus on users, assets and resources, with access decisions made per session based on policy and continuous verification. It is aimed at enterprise network architects and is a widely referenced federal baseline for zero-trust guidance.","effective":"2020-08-11","source":{"label":"NIST SP 800-207 - Zero Trust Architecture (CSRC)","url":"https://csrc.nist.gov/pubs/sp/800/207/final"},"lastVerified":"2026-08-13"},{"id":"mitre-attack","framework":"MITRE ATT&CK","fact":"Adversary tactics and techniques knowledge base","value":"MITRE ATT&CK is a globally accessible, curated knowledge base of adversary tactics and techniques based on real-world observations, maintained by the MITRE Corporation. It is structured around tactics (adversary goals), techniques and sub-techniques (how goals are achieved) and procedures, organised into matrices for Enterprise, Mobile and ICS environments. It is used across the private sector, government and the security community as a foundation for threat modelling, detection engineering and defensive assessment, and is freely available.","source":{"label":"MITRE - ATT&CK knowledge base","url":"https://attack.mitre.org/"},"lastVerified":"2026-08-13"},{"id":"cis-benchmarks","framework":"CIS Benchmarks","fact":"Consensus secure-configuration baselines","value":"CIS Benchmarks are consensus-developed secure configuration recommendations from the Center for Internet Security (CIS) for hardening technologies against attack, distinct from the outcome-oriented CIS Critical Security Controls. They cover more than 100 baselines across many vendor product families, including operating systems, cloud platforms, containers, databases, network devices, mobile devices and server and desktop software. They are produced through a global consensus process, available as free PDFs for non-commercial use, and mapped to frameworks such as the NIST CSF, ISO 27001, PCI DSS and HIPAA.","source":{"label":"CIS - CIS Benchmarks","url":"https://www.cisecurity.org/cis-benchmarks"},"lastVerified":"2026-08-13"},{"id":"stateramp-govramp","framework":"StateRAMP / GovRAMP","fact":"Cloud security authorisation for state and local government","value":"StateRAMP is a non-profit programme that standardises cloud security verification for state, local, tribal and education (SLTT) government entities, and in 2025 it rebranded to GovRAMP to reflect a broader whole-of-state mission. It is built on NIST SP 800-53 control baselines and operates on a complete-once, use-many model so a provider can be authorised once and reused across participating jurisdictions, with verification levels scaling by control count. It applies to cloud service providers selling to participating government entities and to the governments requiring independent security validation.","source":{"label":"StateRAMP / GovRAMP - official site","url":"https://govramp.org/"},"lastVerified":"2026-08-13"},{"id":"pdpa-thailand","framework":"PDPA (Thailand)","fact":"Thailand Personal Data Protection Act B.E. 2562 (2019)","value":"Thailand's Personal Data Protection Act B.E. 2562 (2019) is the country's comprehensive data protection law, enforced by the Personal Data Protection Committee (PDPC). It governs the collection, use and disclosure of personal data by data controllers and processors, requiring a lawful basis (often consent), data-subject rights, security safeguards and rules on cross-border transfers. After pandemic-related postponements its main operative provisions took full effect on 1 June 2022, and it applies to organisations processing the personal data of individuals in Thailand, including certain extraterritorial processing.","effective":"2022-06-01","source":{"label":"Personal Data Protection Committee (PDPC) Thailand - official portal","url":"https://www.pdpc.or.th/"},"lastVerified":"2026-08-13"},{"id":"uk-gdpr-dpa-2018","framework":"UK GDPR & DPA 2018","fact":"UK data protection legal framework","value":"The UK GDPR together with the Data Protection Act 2018 form the United Kingdom's data protection framework, regulated and enforced by the Information Commissioner's Office (ICO). The UK GDPR sets the core principles, lawful bases and data-subject rights, while the DPA 2018 supplements it with UK-specific exemptions, rules for law-enforcement and intelligence processing, and the ICO's powers and penalties. It applies to organisations processing the personal data of individuals in the UK; the DPA 2018 took effect on 25 May 2018 and the UK GDPR applied following the Brexit transition.","effective":"2018-05-25","source":{"label":"ICO - Data Protection Act 2018 / UK GDPR","url":"https://ico.org.uk/about-the-ico/what-we-do/legislation-we-cover/data-protection-act-2018/"},"lastVerified":"2026-08-13"},{"id":"australia-privacy-act-apps","framework":"Privacy Act (Australia)","fact":"Privacy Act 1988 and the 13 Australian Privacy Principles","value":"The Privacy Act 1988 is Australia's principal legislation protecting the handling of personal information, regulated by the Office of the Australian Information Commissioner (OAIC). At its core are the 13 Australian Privacy Principles (APPs), which govern how APP entities collect, use, disclose, store, secure and provide access to personal information. It applies to most Australian Government agencies and to private-sector organisations with annual turnover above AUD 3 million (plus certain others); the APPs commenced on 12 March 2014.","effective":"2014-03-12","source":{"label":"OAIC - Australian Privacy Principles","url":"https://www.oaic.gov.au/privacy/australian-privacy-principles"},"lastVerified":"2026-08-13"},{"id":"ffiec-it-handbook","framework":"FFIEC","fact":"IT Examination Handbook for U.S. financial institutions","value":"The FFIEC Information Technology Examination Handbook is a set of examination booklets issued by the Federal Financial Institutions Examination Council to guide examiners in assessing the IT and cybersecurity risk of U.S. financial institutions and their service providers. It comprises booklets such as Information Security, Management, Business Continuity Management, and Architecture, Infrastructure and Operations, covering governance, risk identification, controls, incident response and third-party oversight. It applies to banks, credit unions and other financial institutions supervised by the FFIEC member agencies.","source":{"label":"FFIEC - IT Examination Handbook InfoBase","url":"https://ithandbook.ffiec.gov/it-booklets/information-security"},"lastVerified":"2026-08-13"},{"id":"pci-ssf","framework":"PCI SSF","fact":"Software Security Framework (successor to PA-DSS)","value":"The PCI Software Security Framework (SSF) is a collection of standards and validation programmes from the PCI Security Standards Council that promotes security in payment software and replaced PA-DSS. It comprises two standards: the Secure Software Standard, which assesses payment-software products, and the Secure Software Lifecycle (Secure SLC) Standard, which assesses a vendor's ongoing secure-development processes. It applies to payment-software vendors and their products; PA-DSS was formally retired at the end of October 2022, after which the SSF became the applicable framework.","effective":"2022-10-31","source":{"label":"PCI SSC - Software Security Framework","url":"https://www.pcisecuritystandards.org/standards/software-security-framework/"},"lastVerified":"2026-08-13"},{"id":"mas-trm-guidelines","framework":"MAS TRM (Singapore)","fact":"Technology Risk Management Guidelines (2021)","value":"The Technology Risk Management (TRM) Guidelines are risk-management principles and best-practice standards issued by the Monetary Authority of Singapore (MAS) for financial institutions. The revised 2021 guidelines set expectations for technology-risk governance and oversight, secure system development, resilience, incident response and third-party and cloud-risk management to strengthen cyber resilience. They apply to all MAS-regulated financial institutions - including banks, insurers, fund managers and payment service providers - and were issued on 18 January 2021.","effective":"2021-01-18","source":{"label":"MAS - Technology Risk Management Guidelines","url":"https://www.mas.gov.sg/regulation/guidelines/technology-risk-management-guidelines"},"lastVerified":"2026-08-13"},{"id":"bahrain-pdpl","framework":"Bahrain PDPL","fact":"Bahrain Personal Data Protection Law (Law No. 30 of 2018)","value":"Law No. 30 of 2018 with respect to Personal Data Protection is Bahrain's national data protection statute, enforced by the Personal Data Protection Authority established under the Ministry of Justice and Islamic Affairs. It applies to the processing of personal data of individuals in Bahrain by data managers and processors in the public or private sector. As a core rule it prohibits processing personal data without the data subject's explicit consent except on specified legal grounds, and it restricts transferring personal data outside Bahrain unless an adequate level of protection or a specific authorisation exists.","effective":"2019-08-01","source":{"label":"Kingdom of Bahrain, Personal Data Protection Authority - Law No. 30 of 2018","url":"https://www.pdp.gov.bh/en/index.html"},"lastVerified":"2026-08-13"},{"id":"oman-pdpl","framework":"Oman PDPL","fact":"Oman Personal Data Protection Law (Royal Decree 6/2022)","value":"The Personal Data Protection Law, promulgated by Royal Decree 6/2022, is Oman's national data protection statute, with the Ministry of Transport, Communications and Information Technology designated as the regulatory and enforcement authority. It governs the processing of personal data and grants data owners rights including consent, withdrawal of consent, correction and deletion, while imposing obligations on controllers and processors. The law comprises 32 articles across five chapters, requires the data owner's consent before processing, and is supported by an Executive Regulation issued in 2024.","effective":"2022-02-09","source":{"label":"Sultanate of Oman, MTCIT - Royal Decree 6/2022 Personal Data Protection Law","url":"https://mtcit.gov.om/sectors/governance/personal"},"lastVerified":"2026-08-13"},{"id":"tisax","framework":"TISAX","fact":"Automotive information security assessment and exchange","value":"TISAX (Trusted Information Security Assessment Exchange) is an assessment and results-exchange mechanism for information security governed by the ENX Association on behalf of the German automotive industry association VDA. Vehicle manufacturers, suppliers and service providers use it to demonstrate and mutually recognise information security across the automotive supply chain, avoiding duplicate audits. Assessments are performed by ENX-approved audit providers against the VDA Information Security Assessment (ISA) catalogue, which is based on key aspects of ISO/IEC 27001, and the resulting labels are valid for three years.","source":{"label":"ENX Association - TISAX","url":"https://enx.com/en-US/TISAX/"},"lastVerified":"2026-08-13"},{"id":"pci-pin-security","framework":"PCI PIN Security","fact":"Secure management of payment PIN data","value":"The PCI PIN Security Requirements are a standard from the PCI Security Standards Council governing the secure management, processing and transmission of personal identification number (PIN) data during payment card transactions at ATMs and point-of-sale terminals. It applies to acquirers, processors and their agents that handle PIN-based transactions and cryptographic key management. The requirements are grouped into control objectives covering secure equipment and key management, PIN encryption, and the generation, distribution and destruction of cryptographic keys.","source":{"label":"PCI Security Standards Council - PIN Security Requirements","url":"https://www.pcisecuritystandards.org/standards/pin-security/"},"lastVerified":"2026-08-13"},{"id":"pci-p2pe","framework":"PCI P2PE","fact":"Validated point-to-point encryption solutions","value":"The PCI Point-to-Point Encryption (P2PE) Standard, from the PCI Security Standards Council, defines requirements for solutions that cryptographically protect account data from the point of capture at a merchant device until it reaches a secure decryption environment. It applies to P2PE solution providers, component providers and merchants using PCI-listed P2PE solutions, and a validated solution can significantly reduce a merchant's applicable PCI DSS scope. It sets requirements across domains including secure devices, secure applications, encryption and decryption environments, and cryptographic key operations.","source":{"label":"PCI Security Standards Council - Point-to-Point Encryption (P2PE)","url":"https://www.pcisecuritystandards.org/standards/point-to-point-encryption-p2pe/"},"lastVerified":"2026-08-13"},{"id":"pci-3ds-core","framework":"PCI 3DS","fact":"PCI 3DS Core Security Standard for 3-D Secure environments","value":"The PCI 3DS Core Security Standard, from the PCI Security Standards Council, defines physical and logical security requirements for environments where EMV 3-D Secure functions such as the Access Control Server (ACS), Directory Server (DS) and 3DS Server (3DSS) are performed. It applies to entities performing these 3DS functions and is separate and independent from PCI DSS. It is structured in two parts: baseline security requirements for the environment, and 3DS-specific requirements protecting 3DS data, technologies and processes that support card-not-present authentication.","source":{"label":"PCI Security Standards Council - PCI 3DS Core Security Standard","url":"https://www.pcisecuritystandards.org/standards/pci-3ds-core/"},"lastVerified":"2026-08-13"},{"id":"iso-20000-1","framework":"ISO/IEC 20000-1","fact":"IT service management system requirements","value":"ISO/IEC 20000-1 is an international standard jointly published by ISO and IEC that specifies requirements to establish, implement, maintain and continually improve a service management system (SMS) for the planning, design, transition, delivery and improvement of services. It applies to any organisation delivering services, regardless of type or size, and is the only part of the ISO/IEC 20000 family to which an organisation can be certified. The current third edition is ISO/IEC 20000-1:2018.","effective":"2018-09-01","source":{"label":"ISO/IEC 20000-1:2018 - IT service management (ISO)","url":"https://www.iso.org/standard/70636.html"},"lastVerified":"2026-08-13"},{"id":"iso-9001","framework":"ISO 9001","fact":"Quality management system requirements","value":"ISO 9001 is the international standard published by ISO specifying requirements for a quality management system (QMS), and it is the only standard in the ISO 9000 family to which organisations can be certified. It applies to organisations of any size and sector that need to consistently provide products and services meeting customer and applicable regulatory requirements and to enhance customer satisfaction. Its requirements are structured around context of the organisation, leadership, planning, support, operation, performance evaluation and improvement (Plan-Do-Check-Act). The current edition is ISO 9001:2015.","effective":"2015-09-01","source":{"label":"ISO 9001:2015 - Quality management systems (ISO)","url":"https://www.iso.org/standard/62085.html"},"lastVerified":"2026-08-13"},{"id":"iso-27005","framework":"ISO/IEC 27005","fact":"Guidance on managing information security risks","value":"ISO/IEC 27005 is an international standard jointly published by ISO and IEC that provides guidance to support the establishment and operation of information security risk management within an ISO/IEC 27001 ISMS. It applies to organisations of all types and sizes and gives a structured approach for identifying, analysing, evaluating and treating information security risks, aligned with ISO/IEC 27001:2022 and ISO 31000:2018. It is guidance rather than a certifiable requirements standard; the current edition is ISO/IEC 27005:2022.","effective":"2022-10-01","source":{"label":"ISO/IEC 27005:2022 - Information security risk management (ISO)","url":"https://www.iso.org/standard/80585.html"},"lastVerified":"2026-08-13"},{"id":"iso-31000","framework":"ISO 31000","fact":"Principles and guidelines for risk management","value":"ISO 31000 is an international standard published by ISO that provides principles, a framework and a process for managing risk of any type faced by an organisation. It is not specific to any industry or sector, can be applied to any activity at all levels, and is guidance rather than a certifiable requirements standard. It centres on creating and protecting value and describes a risk management process of scope and context establishment, risk assessment (identification, analysis, evaluation), risk treatment, monitoring and communication. The current edition is ISO 31000:2018.","effective":"2018-02-01","source":{"label":"ISO 31000:2018 - Risk management (ISO)","url":"https://www.iso.org/standard/65694.html"},"lastVerified":"2026-08-13"},{"id":"rbi-it-governance-md-2023","framework":"RBI","fact":"IT Governance, Risk, Controls and Assurance Practices Directions (2023)","value":"The Reserve Bank of India (Information Technology Governance, Risk, Controls and Assurance Practices) Directions, 2023 (RBI/2023-24/107), effective 1 April 2024, is a Master Direction that consolidates and supersedes earlier RBI IT-governance and cyber-risk instructions. It applies to regulated entities including scheduled commercial banks (excluding RRBs), small finance banks, payments banks, NBFCs in the specified layers, credit information companies, and all-India financial institutions (NABARD, EXIM Bank, NHB, SIDBI, NaBFID). It requires a board-level IT governance framework covering strategic alignment, risk management, resource and performance management, and business continuity and disaster recovery, plus an IT and information-security risk management framework and periodic information systems audits.","effective":"2024-04-01","source":{"label":"RBI Master Direction RBI/2023-24/107 - IT Governance, Risk, Controls and Assurance Practices","url":"https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=12562"},"lastVerified":"2026-08-13"},{"id":"rbi-account-aggregator","framework":"Account Aggregator (RBI)","fact":"NBFC-Account Aggregator consent-based data-sharing framework","value":"The Master Direction - Non-Banking Financial Company - Account Aggregator (Reserve Bank) Directions, 2016 (RBI/DNBR/2016-17/46), issued and enforced by the RBI, governs a class of NBFC that retrieves and consolidates a customer's financial information from multiple financial information providers and shares it - only with the customer's explicit consent - with financial information users. Only companies registered with the RBI may operate as Account Aggregators, and each must hold a net owned fund of at least two crore rupees. No financial information may be retrieved, shared or transferred without explicit, standardised consent, and the AA acts purely as a data intermediary that does not store, use or transact on the data.","effective":"2016-09-02","source":{"label":"RBI Master Direction DNBR.PD.009/03.10.119/2016-17 - NBFC Account Aggregator","url":"https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=10598"},"lastVerified":"2026-08-13"},{"id":"hitech-act","framework":"HITECH (US)","fact":"Health IT adoption and strengthened HIPAA enforcement","value":"The Health Information Technology for Economic and Clinical Health (HITECH) Act was enacted as part of the American Recovery and Reinvestment Act of 2009 and is administered by the U.S. Department of Health and Human Services, with HIPAA enforcement carried out by its Office for Civil Rights. It promotes adoption and meaningful use of electronic health records while strengthening the privacy and security protections established under HIPAA. It extends HIPAA Security Rule safeguards and direct liability to business associates, establishes tiered civil monetary penalty categories, and introduces breach-notification requirements for covered entities and business associates handling protected health information.","effective":"2009-02-17","source":{"label":"U.S. HHS - HITECH Act Enforcement Interim Final Rule","url":"https://www.hhs.gov/hipaa/for-professionals/special-topics/hitech-act-enforcement-interim-final-rule/index.html"},"lastVerified":"2026-08-13"},{"id":"ccpa-cpra-california","framework":"CCPA / CPRA (US-California)","fact":"California consumer privacy law, as amended by the CPRA","value":"The California Consumer Privacy Act of 2018 gives California residents rights over the personal information businesses collect about them, and was amended by the voter-approved California Privacy Rights Act (Proposition 24), whose additional protections took effect on 1 January 2023. It is enforced by the California Attorney General and the California Privacy Protection Agency. It applies to for-profit businesses doing business in California that meet any threshold (over 25 million US dollars gross annual revenue; buying, selling or sharing the personal information of 100,000 or more California residents; or deriving 50 percent or more of revenue from selling residents personal information). Consumers have rights to know, delete, correct, opt out of sale or sharing, limit use of sensitive information, and non-discrimination.","effective":"2023-01-01","source":{"label":"California Attorney General - California Consumer Privacy Act (CCPA)","url":"https://oag.ca.gov/privacy/ccpa"},"lastVerified":"2026-08-13"},{"id":"lgpd-brazil","framework":"LGPD (Brazil)","fact":"Brazil General Data Protection Law (Lei 13.709/2018)","value":"The Lei Geral de Protecao de Dados Pessoais (Law No. 13.709), enacted 14 August 2018, regulates the processing of personal data by individuals and public or private entities to protect the fundamental rights of freedom and privacy. It is enforced by the Autoridade Nacional de Protecao de Dados (ANPD). It applies to any processing carried out in Brazil, or that offers goods or services to or processes the data of individuals located in Brazil, and it sets out legal bases for processing, data-subject rights, and administrative penalties (fines up to 2 percent of Brazil revenue, capped at 50 million reais per infraction).","effective":"2018-08-14","source":{"label":"Presidencia da Republica (Planalto) - Lei No. 13.709/2018","url":"https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm"},"lastVerified":"2026-08-13"},{"id":"pipeda-canada","framework":"PIPEDA (Canada)","fact":"Canada federal private-sector privacy law","value":"The Personal Information Protection and Electronic Documents Act (S.C. 2000, c. 5) governs how private-sector organisations collect, use and disclose personal information in the course of commercial activity, and sets rules for electronic documents and signatures. It is overseen by the Office of the Privacy Commissioner of Canada through a complaint-and-investigation mechanism. It applies to private-sector organisations across Canada (except in provinces with substantially similar legislation) and includes mandatory breach-reporting and record-keeping provisions.","source":{"label":"Justice Laws Website (Government of Canada) - PIPEDA (S.C. 2000, c. 5)","url":"https://laws-lois.justice.gc.ca/eng/acts/P-8.6/"},"lastVerified":"2026-08-13"},{"id":"pdpa-singapore","framework":"PDPA (Singapore)","fact":"Singapore Personal Data Protection Act 2012","value":"The Personal Data Protection Act 2012 governs the collection, use, disclosure and care of personal data by organisations in Singapore, and establishes the national Do Not Call registry. It is administered and enforced by the Personal Data Protection Commission (PDPC). Its main data-protection obligations came into force on 2 July 2014, and it imposes consent, purpose-limitation, protection, accountability and mandatory data-breach-notification obligations on private-sector organisations.","effective":"2014-07-02","source":{"label":"Personal Data Protection Commission (PDPC) Singapore - PDPA","url":"https://www.pdpc.gov.sg/overview-of-pdpa/the-legislation/personal-data-protection-act"},"lastVerified":"2026-08-13"},{"id":"popia-south-africa","framework":"POPIA (South Africa)","fact":"South Africa Protection of Personal Information Act 4 of 2013","value":"The Protection of Personal Information Act 4 of 2013 (POPIA) gives effect to the constitutional right to privacy by regulating how public and private bodies process personal information in South Africa. It is monitored and enforced by the Information Regulator (South Africa). Its substantive conditions for lawful processing became fully enforceable on 1 July 2021, requiring responsible parties to meet eight conditions for lawful processing and to safeguard personal information, with penalties including administrative fines and, for some offences, imprisonment.","effective":"2021-07-01","source":{"label":"Information Regulator (South Africa) - POPIA","url":"https://inforegulator.org.za/"},"lastVerified":"2026-08-13"},{"id":"glba-safeguards-rule","framework":"GLBA (US)","fact":"FTC Safeguards Rule under the Gramm-Leach-Bliley Act","value":"The Safeguards Rule (16 CFR Part 314), mandated by the 1999 Gramm-Leach-Bliley Act, requires financial institutions under FTC jurisdiction to develop, implement and maintain an information security programme with administrative, technical and physical safeguards to protect customer information. It is enforced by the Federal Trade Commission and applies to entities engaged in activities that are financial in nature. The amended rule also requires reporting to the FTC of notification events in which the unencrypted customer information of 500 or more consumers is acquired without authorisation.","source":{"label":"Federal Trade Commission - Gramm-Leach-Bliley Act / Safeguards Rule","url":"https://www.ftc.gov/business-guidance/privacy-security/gramm-leach-bliley-act"},"lastVerified":"2026-08-13"},{"id":"sox-2002","framework":"SOX (US)","fact":"Sarbanes-Oxley Act of 2002 (Sections 302 and 404)","value":"The Sarbanes-Oxley Act of 2002 (Public Law 107-204), enacted 30 July 2002, reformed corporate financial reporting and auditing after major accounting scandals and created the Public Company Accounting Oversight Board (PCAOB). It is enforced primarily by the U.S. Securities and Exchange Commission and applies to U.S. public companies and their auditors. Section 302 requires senior executives to personally certify the accuracy of financial statements; Section 404 requires management, and the external auditor, to assess and report on the effectiveness of internal control over financial reporting.","effective":"2002-07-30","source":{"label":"U.S. Congress (congress.gov) - H.R.3763, Sarbanes-Oxley Act of 2002","url":"https://www.congress.gov/bill/107th-congress/house-bill/3763"},"lastVerified":"2026-08-13"},{"id":"fisma-2014","framework":"FISMA (US)","fact":"Federal Information Security Modernization Act of 2014","value":"The Federal Information Security Modernization Act of 2014 amended the 2002 Federal Information Security Management Act and updated the U.S. federal government information-security framework. CISA, with OMB oversight, administers implementation of information-security policies for non-national-security federal Executive Branch systems. It requires the head of each federal agency to provide information-security protections commensurate with risk (44 U.S.C. 3554), to report on the effectiveness of their security programmes, and to report major information-security incidents.","effective":"2014-12-18","source":{"label":"CISA - Federal Information Security Modernization Act","url":"https://www.cisa.gov/topics/cyber-threats-and-advisories/federal-information-security-modernization-act"},"lastVerified":"2026-08-13"},{"id":"fedramp","framework":"FedRAMP (US)","fact":"U.S. government cloud security authorisation programme","value":"FedRAMP (Federal Risk and Authorization Management Program) is a U.S. government-wide programme providing a standardised approach to security assessment, authorisation and continuous monitoring for cloud products and services, based on NIST SP 800-53 controls. It is operated by the General Services Administration and maintains a marketplace of authorised cloud services, authorising agencies and recognised third-party assessment organisations. Cloud service providers must obtain a FedRAMP authorisation (Low, Moderate or High baseline) to sell cloud services to U.S. federal agencies.","source":{"label":"General Services Administration - FedRAMP.gov","url":"https://www.fedramp.gov/"},"lastVerified":"2026-08-13"},{"id":"rbi-cyber-security-framework-banks-2016","framework":"RBI","fact":"Cyber Security Framework in Banks (2016)","value":"The RBI circular Cyber Security Framework in Banks (RBI/2015-16/418, DBS.CO/CSITE/BC.11/33.01.001/2015-16), dated 2 June 2016, requires scheduled commercial banks to put in place a board-approved cyber-security policy distinct from their IT or IS-security policy, to implement a baseline cyber-security and resilience framework, and to arrange continuous surveillance (for example through a Security Operations Centre). Issued and supervised by the RBI CSITE Cell, it also requires banks to maintain a Cyber Crisis Management Plan and to report all cyber-security incidents, whether successful or attempted, to the RBI.","effective":"2016-06-02","source":{"label":"RBI Notification RBI/2015-16/418 - Cyber Security Framework in Banks","url":"https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=10435"},"lastVerified":"2026-08-13"},{"id":"uk-cyber-essentials","framework":"Cyber Essentials (UK)","fact":"NCSC-backed baseline cyber security certification","value":"Cyber Essentials is the UK government backed minimum standard of cyber security for organisations of all sizes, developed by the National Cyber Security Centre (NCSC) and delivered through IASME as the official partner. It certifies organisations against five technical controls: firewalls, secure configuration, security update management, user access control and malware protection. Certification (Cyber Essentials, or the audited Cyber Essentials Plus) is required to bid for certain UK government contracts handling sensitive or personal information and is increasingly required across supply chains.","source":{"label":"National Cyber Security Centre (NCSC) - Cyber Essentials","url":"https://www.ncsc.gov.uk/cyberessentials/overview"},"lastVerified":"2026-08-13"},{"id":"au-essential-eight","framework":"Essential Eight (Australia)","fact":"ASD/ACSC eight prioritised mitigation strategies with maturity model","value":"The Essential Eight is a set of prioritised baseline mitigation strategies published by the Australian Signals Directorate Australian Cyber Security Centre (ASD ACSC). The eight strategies are: patch applications, patch operating systems, multi-factor authentication, restrict administrative privileges, application control, restrict Microsoft Office macros, user application hardening, and regular backups. It is supported by the Essential Eight Maturity Model (first published June 2017), which defines Maturity Levels Zero to Three; organisations are advised to reach the same maturity level across all eight strategies before progressing to a higher level.","source":{"label":"Australian Cyber Security Centre (ASD) - Essential Eight","url":"https://www.cyber.gov.au/business-government/asds-cyber-security-frameworks/essential-eight"},"lastVerified":"2026-08-13"},{"id":"iso27002-controls-guidance","framework":"ISO/IEC 27002","fact":"Information security controls guidance (companion to 27001)","value":"ISO/IEC 27002:2022 is an international standard from ISO and IEC that provides a reference set of information security controls with detailed implementation guidance. It is a guidance document and is not certifiable on its own; organisations use it to implement the controls selected in an ISO/IEC 27001 ISMS. The 2022 edition reorganises the controls into the same four themes as ISO/IEC 27001:2022 Annex A - organisational, people, physical and technological - covering 93 controls.","effective":"2022-02-15","source":{"label":"ISO/IEC 27002:2022 - Information security controls (ISO)","url":"https://www.iso.org/standard/75652.html"},"lastVerified":"2026-08-13"},{"id":"iso27701-pims","framework":"ISO/IEC 27701","fact":"Privacy Information Management System (PIMS)","value":"ISO/IEC 27701 is an international standard from ISO and IEC that specifies requirements and guidance for a Privacy Information Management System (PIMS). It applies to organisations acting as PII controllers and PII processors and adds privacy-specific requirements and controls on top of an information security management system. First published in 2019 as an extension to ISO/IEC 27001 and 27002, it lets organisations manage privacy risk and demonstrate accountability, and can be certified alongside ISO/IEC 27001.","source":{"label":"ISO/IEC 27701 - Privacy information management (ISO)","url":"https://www.iso.org/standard/27701"},"lastVerified":"2026-08-13"},{"id":"iso27017-cloud-security","framework":"ISO/IEC 27017","fact":"Code of practice for cloud-services security controls","value":"ISO/IEC 27017:2015 is an international standard from ISO and IEC providing a code of practice for information security controls for cloud services, based on ISO/IEC 27002. It gives cloud-specific implementation guidance for both cloud service providers and cloud service customers and adds cloud-specific controls covering shared roles and responsibilities, return or removal of customer assets, segregation in virtual environments, and administrative operations.","effective":"2015-12-15","source":{"label":"ISO/IEC 27017:2015 - Cloud services security controls (ISO)","url":"https://www.iso.org/standard/43757.html"},"lastVerified":"2026-08-13"},{"id":"iso27018-cloud-pii","framework":"ISO/IEC 27018","fact":"Protection of PII in public clouds (PII processors)","value":"ISO/IEC 27018 is an international standard from ISO and IEC establishing controls to protect personally identifiable information (PII) in public cloud computing environments where the cloud provider acts as a PII processor. It applies to public cloud service providers that process PII on behalf of their customers and builds on ISO/IEC 27002, addressing consent, transparency, restrictions on use, disclosure and cross-border handling of cloud-processed PII, and accountability.","source":{"label":"ISO/IEC 27018 - Protection of PII in public clouds (ISO)","url":"https://www.iso.org/standard/27018"},"lastVerified":"2026-08-13"},{"id":"nist-sp-800-53","framework":"NIST SP 800-53","fact":"Security and privacy controls catalog (Rev. 5)","value":"NIST Special Publication 800-53, Revision 5, is a U.S. National Institute of Standards and Technology publication providing a comprehensive catalog of security and privacy controls for information systems and organisations. It supports U.S. federal agencies (and is widely used by others) in protecting operations, assets and individuals from a broad range of threats and privacy risks. Revision 5 consolidates security and privacy controls into a single catalog, makes them outcome-based and control-organisation-neutral, and groups them into 20 control families.","effective":"2020-09-23","source":{"label":"NIST SP 800-53 Rev. 5 - Security and Privacy Controls (NIST CSRC)","url":"https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final"},"lastVerified":"2026-08-13"},{"id":"nist-sp-800-171","framework":"NIST SP 800-171","fact":"Protecting Controlled Unclassified Information (CUI)","value":"NIST Special Publication 800-171 gives recommended security requirements for protecting the confidentiality of Controlled Unclassified Information (CUI) when it resides in nonfederal systems and organisations. It applies to contractors, universities and other nonfederal entities that process, store or transmit CUI on behalf of U.S. federal agencies, and underpins the DoD's CMMC Level 2. Revision 3 organises the security requirements into 17 families derived from NIST SP 800-53.","effective":"2024-05-14","source":{"label":"NIST SP 800-171 Rev. 3 - Protecting CUI (NIST CSRC)","url":"https://csrc.nist.gov/pubs/sp/800/171/r3/final"},"lastVerified":"2026-08-13"},{"id":"cis-controls-v8","framework":"CIS Controls","fact":"CIS Critical Security Controls v8 - 18 controls, 153 safeguards","value":"The CIS Critical Security Controls (Version 8) are a prioritised set of cybersecurity best practices published and maintained by the Center for Internet Security (CIS). Version 8 consolidates the guidance into 18 top-level Controls containing 153 Safeguards, organised into three Implementation Groups (IG1 to IG3) scaled to an organisation's risk and resources. They apply to organisations of any size and are mapped to other frameworks such as the NIST Cybersecurity Framework.","effective":"2021-05-18","source":{"label":"CIS Critical Security Controls Version 8 (Center for Internet Security)","url":"https://www.cisecurity.org/controls/v8"},"lastVerified":"2026-08-13"},{"id":"csa-ccm-star","framework":"CSA CCM / STAR","fact":"Cloud Controls Matrix and the STAR registry","value":"The Cloud Controls Matrix (CCM) is a cybersecurity control framework for cloud computing published by the Cloud Security Alliance (CSA), organised into 17 domains of cloud security and privacy controls and mapped to leading standards and regulations. It defines responsibilities between cloud service providers and customers and is used to assess cloud security posture. Together with the Consensus Assessments Initiative Questionnaire (CAIQ), the CCM is the basis for CSA's Security, Trust, Assurance and Risk (STAR) programme and its public registry of provider self-assessments and third-party certifications.","effective":"2021-01-21","source":{"label":"CSA Cloud Controls Matrix (Cloud Security Alliance)","url":"https://cloudsecurityalliance.org/research/cloud-controls-matrix"},"lastVerified":"2026-08-13"},{"id":"hitrust-csf","framework":"HITRUST CSF","fact":"Certifiable framework harmonising 60+ authoritative sources","value":"The HITRUST CSF is a certifiable security and privacy control framework created and maintained by HITRUST. It harmonises and maps to more than 60 authoritative sources - including standards, regulations and frameworks such as ISO 27001, the NIST publications, HIPAA and PCI DSS - into a single control library. Originally focused on healthcare, it is applicable across sectors and risk levels, and organisations can achieve HITRUST certification (e1, i1 or r2) through validated assessments performed with an authorised external assessor.","source":{"label":"HITRUST CSF (HITRUST Alliance)","url":"https://hitrustalliance.net/hitrust-framework"},"lastVerified":"2026-08-13"},{"id":"soc-1-icfr","framework":"SOC 1 (AICPA)","fact":"Service-organisation controls relevant to financial reporting","value":"SOC 1 (SOC for Service Organizations: ICFR) is a reporting framework governed by the AICPA under attestation standard SSAE 18 (AT-C section 320). It is an examination by an independent service auditor of the controls at a service organisation that are likely to be relevant to its user entities' internal control over financial reporting (ICFR). The report is used by user entities and their financial-statement auditors, and can be a Type 1 (design of controls at a point in time) or Type 2 (design and operating effectiveness over a period).","source":{"label":"SOC 1 - SOC for Service Organizations: ICFR (AICPA & CIMA)","url":"https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-1"},"lastVerified":"2026-08-13"},{"id":"eu-nis2-directive","framework":"NIS2 (EU)","fact":"EU-wide cybersecurity directive for essential and important entities","value":"Directive (EU) 2022/2555 (NIS2), adopted on 14 December 2022, lays down measures for a high common level of cybersecurity across the European Union and repeals the earlier NIS Directive (EU) 2016/1148. It applies to essential and important entities across critical sectors (energy, transport, banking, health, digital infrastructure, public administration and more) and imposes cybersecurity risk-management measures, governance accountability, and significant-incident reporting, backed by supervision and enforcement. As a directive it must be transposed into each member state's national law.","effective":"2022-12-14","source":{"label":"Directive (EU) 2022/2555 (NIS2) - EUR-Lex","url":"https://eur-lex.europa.eu/eli/dir/2022/2555/oj"},"lastVerified":"2026-08-13"},{"id":"eu-dora-regulation","framework":"DORA (EU)","fact":"Digital Operational Resilience Act for the financial sector","value":"The Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, is a directly applicable EU regulation adopted on 14 December 2022 that sets uniform requirements for the security of network and information systems of financial entities and their critical ICT third-party providers. It applies to a broad range of EU-regulated financial entities - banks, insurers, investment firms, payment institutions and others - requiring ICT risk management, ICT-related incident reporting, digital operational resilience testing, and oversight of ICT third-party risk. It became applicable across all member states on 17 January 2025.","effective":"2025-01-17","source":{"label":"Regulation (EU) 2022/2554 (DORA) - EUR-Lex","url":"https://eur-lex.europa.eu/eli/reg/2022/2554/oj"},"lastVerified":"2026-08-13"},{"id":"dpdp-consent-notice","framework":"DPDP Act 2023","fact":"Consent and notice (Sections 5-6)","value":"Under Section 6 of the DPDP Act 2023, consent to process personal data must be free, specific, informed, unconditional and unambiguous, given through a clear affirmative action, and limited to the personal data necessary for the specified purpose. A Data Principal may withdraw consent at any time, and withdrawing it must be as easy as giving it. Under Section 5, every request for consent must be accompanied or preceded by a notice, in clear and plain language, that gives an itemised description of the personal data and the purpose of processing, the manner in which the Data Principal may exercise their rights and withdraw consent, and the manner of making a complaint to the Data Protection Board.","source":{"label":"The Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023) - MeitY","url":"https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf"},"lastVerified":"2026-08-13"},{"id":"dpdp-breach-notification-rule-7","framework":"DPDP Act 2023","fact":"Personal data breach notification (DPDP Rules 2025, Rule 7)","value":"On becoming aware of a personal data breach, a Data Fiduciary must, without delay, intimate each affected Data Principal in a concise, plain-language notice describing the breach, its likely consequences, the mitigation measures the Data Fiduciary has taken, the safety measures the Data Principal can take, and contact details for queries. It must also intimate the Data Protection Board of India without delay with the initial facts (nature, extent, timing, location and likely impact), followed by a detailed report - including broad facts, causes, mitigation and the notifications made to Data Principals - within 72 hours of becoming aware, or a longer period the Board allows on request.","source":{"label":"Digital Personal Data Protection Rules, 2025, Rule 7 - MeitY","url":"https://www.meity.gov.in/documents/act-and-policies/digital-personal-data-protection-rules-2025-gDOxUjMtQWa"},"lastVerified":"2026-08-13"},{"id":"rbi-digital-payment-security-controls-2021","framework":"RBI","fact":"Master Direction on Digital Payment Security Controls (2021)","value":"The RBI Master Direction on Digital Payment Security Controls (RBI/2020-21/74, DoS.CO.CSITE.SEC.No.1852/31.01.015/2020-21), dated 18 February 2021, sets out a robust governance structure and common minimum standards of security controls for digital payment products and services. It covers areas such as internet banking, mobile banking and card payments, along with customer protection and grievance redressal. It applies to Scheduled Commercial Banks (excluding Regional Rural Banks), Small Finance Banks, Payments Banks and credit-card-issuing NBFCs, and took effect within six months of being placed on the RBI website.","effective":"2021-02-18","source":{"label":"RBI Master Direction - Digital Payment Security Controls (RBI/2020-21/74)","url":"https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=12032"},"lastVerified":"2026-08-13"},{"id":"iso42001-aims-standard","framework":"ISO/IEC 42001","fact":"ISO/IEC 42001:2023 - AI management systems","value":"ISO/IEC 42001:2023 is the first certifiable international standard for an Artificial Intelligence Management System (AIMS), published in December 2023. It specifies requirements for establishing, implementing, maintaining and continually improving an AIMS, so that an organisation developing, providing or using AI does so responsibly. Organisations build the management system against clauses 4 to 10 and select applicable controls from Annex A, a reference set of 38 controls across 9 objectives covering areas such as data quality, the AI system lifecycle, transparency, human oversight and AI impact assessment. Certification is by an accredited body through a Stage 1 (documentation) and Stage 2 (operational) audit.","effective":"2023-12-18","source":{"label":"ISO/IEC 42001:2023 - Artificial intelligence management system (ISO)","url":"https://www.iso.org/standard/42001"},"lastVerified":"2026-08-13"},{"id":"pci-structure-goals-requirements","framework":"PCI DSS","fact":"Structure - six goals and twelve requirements","value":"PCI DSS organises its controls into six goals (control objectives) that break down into 12 core requirements: build and maintain a secure network and systems (Req 1-2), protect account data (Req 3-4), maintain a vulnerability management programme (Req 5-6), implement strong access control measures (Req 7-9), regularly monitor and test networks (Req 10-11), and maintain an information security policy (Req 12). Each requirement contains testing procedures and, in v4.0, a defined and a customised approach. The current version, PCI DSS v4.0.1, was published in June 2024 as a limited revision of v4.0 that corrects minor errors and clarifies language without adding new requirements.","effective":"2024-06-11","source":{"label":"PCI SSC - Document Library (PCI DSS v4.0.1)","url":"https://www.pcisecuritystandards.org/document_library/"},"lastVerified":"2026-08-13"},{"id":"rbi-payment-data-localisation","framework":"RBI","fact":"Storage of Payment System Data (data localisation)","value":"The RBI circular on Storage of Payment System Data (RBI/2017-18/153, DPSS.CO.OD No.2785/06.08.005/2017-2018), dated 6 April 2018, requires all system providers to ensure that the entire data relating to the payment systems they operate is stored in a system only in India. This includes the full end-to-end transaction details and any information collected, carried or processed as part of the payment message or instruction. Providers were given six months to comply and to submit a System Audit Report conducted by a CERT-In empanelled auditor. It applies to all Payment System Providers authorised under the Payment and Settlement Systems Act, 2007.","effective":"2018-04-06","source":{"label":"RBI Notification RBI/2017-18/153 - Storage of Payment System Data","url":"https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=11244"},"lastVerified":"2026-08-13"},{"id":"rbi-payment-aggregators-directions-2025","framework":"RBI","fact":"Regulation of Payment Aggregators Directions, 2025","value":"The Reserve Bank of India (Regulation of Payment Aggregators) Directions, 2025 (RBI/DPSS/2025-26/141), issued 15 September 2025 and in force from 31 December 2025, consolidate the earlier 2020, 2021 and 2023 payment-aggregator guidelines into a single framework covering online and face-to-face (proximity) payment aggregators. A non-bank entity carrying on payment-aggregator business must obtain RBI authorisation, and must have a minimum net worth of INR 15 crore at the time of application, rising to a minimum net worth of INR 25 crore by the end of the third financial year after authorisation, maintained thereafter. The directions also cover governance, KYC of merchants, escrow-account operation, security and reporting.","effective":"2025-12-31","source":{"label":"RBI Master Direction RBI/DPSS/2025-26/141 - Regulation of Payment Aggregators Directions, 2025","url":"https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=12896"},"lastVerified":"2026-08-13"},{"id":"nist-csf-2-functions","framework":"NIST CSF","fact":"CSF 2.0 - six core functions","value":"The NIST Cybersecurity Framework 2.0, released on 26 February 2024 (NIST CSWP 29), is the first major revision since 2014. It organises cybersecurity outcomes into six core functions: Govern (new in 2.0 - establishing and monitoring the organisation's cybersecurity risk-management strategy, expectations and policy), Identify, Protect, Detect, Respond and Recover. CSF 2.0 broadens the framework's scope from critical infrastructure to organisations of all sizes and sectors, and strengthens its treatment of governance and supply-chain risk. The functions are intended to be performed concurrently and continuously.","effective":"2024-02-26","source":{"label":"NIST CSWP 29 - The NIST Cybersecurity Framework (CSF) 2.0","url":"https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf"},"lastVerified":"2026-08-13"},{"id":"iso27001-statement-of-applicability","framework":"ISO/IEC 27001","fact":"Statement of Applicability (clause 6.1.3)","value":"ISO/IEC 27001:2022 clause 6.1.3(d) requires the organisation to produce a Statement of Applicability (SoA) as part of its information-security risk-treatment process. The SoA must contain the necessary controls (those chosen to treat risks, whether from Annex A or elsewhere), the justification for their inclusion, whether each necessary control is implemented, and the justification for excluding any of the Annex A controls. The SoA is a mandatory, auditable document and the reference point auditors use to confirm that all applicable controls are addressed.","source":{"label":"ISO/IEC 27001:2022 - Information security management systems (ISO)","url":"https://www.iso.org/standard/27001"},"lastVerified":"2026-08-13"},{"id":"dpdp-data-principal-rights","framework":"DPDP Act 2023","fact":"Rights of the Data Principal (Sections 11-14)","value":"Chapter III of the DPDP Act 2023 grants every Data Principal four rights against a Data Fiduciary: the right to access information about the personal data being processed and the identities of other fiduciaries with whom it has been shared (Section 11); the right to correction, completion, updating and erasure of personal data (Section 12); the right of grievance redressal through the Data Fiduciary's or Consent Manager's mechanism, exercisable before approaching the Data Protection Board (Section 13); and the right to nominate another individual to exercise these rights in the event of the Data Principal's death or incapacity (Section 14). Section 15 sets out corresponding duties of the Data Principal.","source":{"label":"The Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023) - MeitY","url":"https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf"},"lastVerified":"2026-08-13"},{"id":"iso27001-annexa-control-count","framework":"ISO/IEC 27001","fact":"Annex A control count (2022 revision)","value":"ISO/IEC 27001:2022 Annex A contains 93 controls organised into four themes: Organisational (37 controls, clause 5), People (8 controls, clause 6), Physical (14 controls, clause 7) and Technological (34 controls, clause 8). This restructures the 114 controls across 14 domains of the 2013 edition - the count fell through consolidation and merging, not a reduction in scope. Organisations certified to ISO/IEC 27001:2013 were required to transition to the 2022 edition.","effective":"2022-10-25","source":{"label":"ISO/IEC 27001:2022 - Information security management systems (ISO)","url":"https://www.iso.org/standard/27001"},"lastVerified":"2026-08-13"},{"id":"pci-merchant-levels-visa","framework":"PCI DSS","fact":"Merchant validation levels (Visa)","value":"Visa classifies merchants into four levels by annual transaction volume, which sets the validation path. Level 1: more than 6 million Visa transactions per year across all channels (or any merchant Visa designates Level 1, e.g. after a compromise) - annual on-site assessment and Report on Compliance (ROC) plus quarterly network scan. Level 2: 1 to 6 million transactions per year - annual Self-Assessment Questionnaire (SAQ) and quarterly scan. Level 3: 20,000 to 1 million Visa e-commerce transactions per year - SAQ and quarterly scan. Level 4: fewer than 20,000 Visa e-commerce transactions, or up to 1 million total transactions per year - SAQ and scan as required by the acquirer. Other card brands set broadly similar but not identical thresholds; the acquirer confirms a merchant's level.","source":{"label":"Visa - Account Information Security (AIS) Program and PCI","url":"https://corporate.visa.com/en/resources/security-compliance.html"},"lastVerified":"2026-08-13"},{"id":"pci-saq-types","framework":"PCI DSS","fact":"Self-Assessment Questionnaire (SAQ) types","value":"PCI DSS defines nine SAQ types, each scoped to how a merchant handles cardholder data: SAQ A (fully outsourced e-commerce or mail/telephone order, no data handling); SAQ A-EP (e-commerce that partially controls the payment page); SAQ B (imprint machines or standalone dial-out terminals, no electronic storage); SAQ B-IP (standalone PTS-approved IP-connected terminals); SAQ C-VT (web-based virtual terminal, one transaction at a time); SAQ C (payment application connected to the internet); SAQ P2PE (hardware terminals in a validated PCI P2PE solution); SAQ D for Merchants (all others that store, process or transmit cardholder data - the most comprehensive); and SAQ D for Service Providers. A merchant who cannot meet an SAQ's eligibility criteria, or who is a Level 1 merchant, completes a full Report on Compliance (ROC) instead of an SAQ.","source":{"label":"PCI SSC - Document Library (Self-Assessment Questionnaires)","url":"https://www.pcisecuritystandards.org/document_library/"},"lastVerified":"2026-08-13"},{"id":"dpdp-children-section-9","framework":"DPDP Act 2023","fact":"Children's personal data (Section 9)","value":"Under Section 9 of the DPDP Act 2023, a 'child' is a person who has not completed 18 years of age. Before processing a child's personal data (or that of a person with a disability who has a lawful guardian), a Data Fiduciary must obtain verifiable consent of the parent or lawful guardian. A Data Fiduciary must not undertake processing likely to cause a detrimental effect on the well-being of a child, and must not carry out tracking, behavioural monitoring, or targeted advertising directed at children. The Central Government may exempt notified classes of Data Fiduciary, or notified purposes, from some of these conditions.","source":{"label":"The Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023) - MeitY","url":"https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf"},"lastVerified":"2026-08-13"},{"id":"dpdp-sdf-section-10","framework":"DPDP Act 2023","fact":"Significant Data Fiduciary (Section 10)","value":"Under Section 10 of the DPDP Act 2023, the Central Government may notify any Data Fiduciary or class of Data Fiduciaries as a Significant Data Fiduciary (SDF), based on factors including the volume and sensitivity of personal data processed, risk to the rights of Data Principals, potential effect on the sovereignty and integrity of India, risk to electoral democracy, and security of the State and public order. An SDF must: appoint a Data Protection Officer based in India who represents it under the Act and is the point of contact for grievance redressal; appoint an independent data auditor to evaluate compliance; and undertake periodic Data Protection Impact Assessments, periodic audits, and such other measures as may be prescribed.","source":{"label":"The Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023) - MeitY","url":"https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf"},"lastVerified":"2026-08-13"},{"id":"gdpr-article-83-fines","framework":"GDPR","fact":"Administrative fines (Article 83)","value":"GDPR Article 83 sets two maximum tiers for administrative fines, applied case by case and taken as whichever amount is higher. Lower tier: up to EUR 10 million, or up to 2% of total worldwide annual turnover of the preceding financial year - for breaches of obligations such as security of processing, records of processing, and data protection by design and by default. Higher tier: up to EUR 20 million, or up to 4% of total worldwide annual turnover - for breaches of the basic principles for processing (including conditions for consent), data subjects' rights, and the rules on transfers to third countries. Fines must be effective, proportionate and dissuasive.","source":{"label":"Regulation (EU) 2016/679 (GDPR), Article 83 - EUR-Lex","url":"https://eur-lex.europa.eu/eli/reg/2016/679/oj"},"lastVerified":"2026-08-13"},{"id":"cmmc-levels-final-rule","framework":"CMMC (US DoD)","fact":"Three levels and final-rule status","value":"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).","effective":"2024-12-16","source":{"label":"32 CFR Part 170 - CMMC Program (eCFR)","url":"https://www.ecfr.gov/current/title-32/subtitle-A/chapter-I/subchapter-M/part-170"},"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.","lastVerified":"2026-08-11"},{"id":"cmmc-phased-rollout","framework":"CMMC (US DoD)","fact":"Phased contractual rollout (DFARS)","value":"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.","effective":"2025-11-10","source":{"label":"CMMC Program - 32 CFR Part 170 and the DFARS 48 CFR acquisition rule (eCFR)","url":"https://www.ecfr.gov/current/title-32/subtitle-A/chapter-I/subchapter-M/part-170"},"note":"Phase dates current as of 11 August 2026; DoD has adjusted this timeline before.","lastVerified":"2026-08-11"},{"id":"cmmc-applicability","framework":"CMMC (US DoD)","fact":"Who it applies to","value":"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).","effective":"2024-12-16","source":{"label":"32 CFR Part 170 - CMMC Program scope and assessment (eCFR)","url":"https://www.ecfr.gov/current/title-32/subtitle-A/chapter-I/subchapter-M/part-170"},"lastVerified":"2026-08-11"},{"id":"uae-pdpl-lawful-processing","framework":"UAE PDPL","fact":"Lawful processing and consent (Articles 4-6)","value":"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.","effective":"2022-01-02","source":{"label":"UAE Legislation portal - Federal Decree-Law 45/2021, Articles 4-6 (official)","url":"https://uaelegislation.gov.ae/en/legislations/1972"},"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.","lastVerified":"2026-08-11"},{"id":"uae-pdpl-enforcement","framework":"UAE PDPL","fact":"Complaints, penalties and Executive Regulation (Articles 24-28)","value":"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.","effective":"2022-01-02","source":{"label":"UAE Legislation portal - Federal Decree-Law 45/2021, Articles 24-28 (official)","url":"https://uaelegislation.gov.ae/en/legislations/1972"},"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.","lastVerified":"2026-08-11"},{"id":"nca-ecc-subdomain-structure","framework":"NCA ECC (Saudi Arabia)","fact":"Domain and subdomain structure","value":"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).","effective":"2024","source":{"label":"NCA - Essential Cybersecurity Controls ECC - 2 : 2024 (English), Figures 1-2","url":"https://cdn.nca.gov.sa/api/files/public/upload/86e09090-44e4-481f-bc28-355673607654_ECC--2024-EN.pdf"},"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.","lastVerified":"2026-08-11"},{"id":"nca-ecc-saudization","framework":"NCA ECC (Saudi Arabia)","fact":"Saudization of cybersecurity positions and independent function","value":"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).","effective":"2024","source":{"label":"NCA - ECC-2:2024 (English), Cybersecurity Governance controls 1-1 and 1-2","url":"https://cdn.nca.gov.sa/api/files/public/upload/86e09090-44e4-481f-bc28-355673607654_ECC--2024-EN.pdf"},"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.","lastVerified":"2026-08-11"},{"id":"nca-ecc-coding-scheme","framework":"NCA ECC (Saudi Arabia)","fact":"Control coding scheme","value":"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.","effective":"2024","source":{"label":"NCA - ECC-2:2024 (English), Figures 3-4 and Table 1","url":"https://cdn.nca.gov.sa/api/files/public/upload/86e09090-44e4-481f-bc28-355673607654_ECC--2024-EN.pdf"},"lastVerified":"2026-08-11"},{"id":"gdpr-ropa-art30","framework":"GDPR","fact":"Records of processing activities (Article 30)","value":"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.","effective":"2018-05-25","source":{"label":"Regulation (EU) 2016/679 (GDPR), Article 30 - EUR-Lex consolidated text","url":"https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679"},"lastVerified":"2026-08-11"},{"id":"gdpr-dpia-art35","framework":"GDPR","fact":"Data protection impact assessment (Article 35)","value":"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.","effective":"2018-05-25","source":{"label":"Regulation (EU) 2016/679 (GDPR), Articles 35-36 - EUR-Lex consolidated text","url":"https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679"},"lastVerified":"2026-08-11"},{"id":"gdpr-dpo-art37","framework":"GDPR","fact":"Data protection officer (Articles 37-39)","value":"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.","effective":"2018-05-25","source":{"label":"Regulation (EU) 2016/679 (GDPR), Articles 37-39 - EUR-Lex consolidated text","url":"https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679"},"lastVerified":"2026-08-11"},{"id":"owasp-asvs-5-chapters","framework":"OWASP ASVS","fact":"Version 5.0 chapter structure","value":"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.","effective":"2025","source":{"label":"OWASP Application Security Verification Standard 5.0 repository (CC BY-SA)","url":"https://github.com/OWASP/ASVS/tree/master/5.0/en"},"lastVerified":"2026-08-11"},{"id":"dpdp-act-gazette","framework":"DPDP Act 2023","fact":"Enactment","value":"Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023); Presidential assent 11 August 2023; Gazette ID CG-DL-E-12082023-248045.","effective":"2023-08-11","source":{"label":"Official Gazette text (MeitY PDF)","url":"https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf"},"lastVerified":"2026-07-31"},{"id":"dpdp-rules-notified","framework":"DPDP Act 2023","fact":"DPDP Rules 2025 notification","value":"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).","effective":"2025-11-13","source":{"label":"MeitY / PIB — DPDP Rules 2025","url":"https://static.pib.gov.in/WriteReadData/specificdocs/documents/2025/nov/doc20251117695301.pdf"},"note":"Gazette date corroborated across multiple law-firm analyses; the PIB document filename carries the press-release date (17 Nov), not the notification date.","lastVerified":"2026-08-01"},{"id":"dpdp-phase-1","framework":"DPDP Act 2023","fact":"Phase I — in force on notification","value":"Provisions constituting and empowering the Data Protection Board (ss.18–26), definitions, and procedural rules took effect on 13 November 2025.","effective":"2025-11-13","source":{"label":"DPDP Rules 2025 (phased commencement)","url":"https://static.pib.gov.in/WriteReadData/specificdocs/documents/2025/nov/doc20251117695301.pdf"},"lastVerified":"2026-08-01"},{"id":"dpdp-phase-2","framework":"DPDP Act 2023","fact":"Phase II — one year from notification","value":"Section 6(9) (verifiable parental consent) and section 27(1)(d) (publication duty) commence one year from notification — November 2026.","effective":"2026-11-13","source":{"label":"DPDP Rules 2025 (phased commencement)","url":"https://static.pib.gov.in/WriteReadData/specificdocs/documents/2025/nov/doc20251117695301.pdf"},"lastVerified":"2026-08-01"},{"id":"dpdp-phase-3","framework":"DPDP Act 2023","fact":"Phase III — substantive framework","value":"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.","effective":"2027-05","source":{"label":"DPDP Rules 2025 (phased commencement)","url":"https://static.pib.gov.in/WriteReadData/specificdocs/documents/2025/nov/doc20251117695301.pdf"},"lastVerified":"2026-08-01"},{"id":"certin-directions","framework":"CERT-In Directions","fact":"Issue and commencement","value":"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.","effective":"2022-06-28","source":{"label":"CERT-In Directions (official PDF)","url":"https://www.cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf"},"lastVerified":"2026-07-31"},{"id":"certin-6h","framework":"CERT-In Directions","fact":"Incident reporting window","value":"Specified cyber incidents must be reported to CERT-In within 6 hours of noticing.","effective":"2022-06-28","source":{"label":"CERT-In Directions (official PDF)","url":"https://www.cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf"},"lastVerified":"2026-07-31"},{"id":"certin-logs","framework":"CERT-In Directions","fact":"Log retention","value":"ICT system logs must be maintained for a rolling 180 days, within Indian jurisdiction.","effective":"2022-06-28","source":{"label":"CERT-In Directions (official PDF)","url":"https://www.cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf"},"lastVerified":"2026-07-31"},{"id":"certin-ntp","framework":"CERT-In Directions","fact":"Time synchronisation","value":"System clocks must be synchronised to NIC or NPL time sources.","effective":"2022-06-28","source":{"label":"CERT-In Directions (official PDF)","url":"https://www.cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf"},"lastVerified":"2026-07-31"},{"id":"certin-provider-records","framework":"CERT-In Directions","fact":"Provider record-keeping","value":"Data centres, VPS, cloud and VPN providers must register and retain accurate subscriber/customer records for 5 years after cancellation or withdrawal of service.","effective":"2022-06-28","source":{"label":"CERT-In Directions (official PDF)","url":"https://www.cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf"},"lastVerified":"2026-07-31"},{"id":"aua-kua-audit","framework":"UIDAI (Aadhaar)","fact":"AUA / KUA audit duty","value":"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.","effective":null,"source":{"label":"UIDAI compliance checklist for controls the AUA/KUA must have in place","url":"https://uidai.gov.in/images/Compliance_checklist_for_certifying_compliance_with_controls__that_the_AUAKUA_is_required_to_have_in_place.pdf"},"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.","lastVerified":"2026-08-11"},{"id":"isnp-audit","framework":"IRDAI","fact":"ISNP audit duty","value":"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.","effective":null,"source":{"label":"IRDAI - circular on online filing for Insurance Self Network Platform (IRDA/INT/CIR/ECM/083/04/2017), citing the governing e-commerce guidelines","url":"https://irdai.gov.in/document-detail?documentId=384920"},"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.","lastVerified":"2026-08-07"},{"id":"pci-dss-version","framework":"PCI DSS","fact":"Current version","value":"PCI DSS v4.0.1 is the current standard published by the PCI Security Standards Council.","effective":null,"source":{"label":"PCI SSC document library","url":"https://www.pcisecuritystandards.org/document_library/"},"lastVerified":"2026-08-01"},{"id":"owasp-asvs-version","framework":"OWASP ASVS","fact":"Current version","value":"OWASP Application Security Verification Standard v5.0.0 (May 2025): ~350 requirements across 17 chapters, three verification levels (L1–L3).","effective":"2025-05","source":{"label":"OWASP ASVS project","url":"https://owasp.org/www-project-application-security-verification-standard/"},"lastVerified":"2026-08-01"},{"id":"owasp-asvs-5-structure","framework":"OWASP ASVS","fact":"ASVS 5.0.0 contains 345 requirements across 17 chapters","value":"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.","effective":null,"source":{"label":"OWASP — Application Security Verification Standard project","url":"https://owasp.org/www-project-application-security-verification-standard/"},"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.","lastVerified":"2026-08-04"},{"id":"owasp-asvs-5-levels","framework":"OWASP ASVS","fact":"Requirements are split across three verification levels","value":"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.","effective":null,"source":{"label":"OWASP — Application Security Verification Standard project","url":"https://owasp.org/www-project-application-security-verification-standard/"},"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.","lastVerified":"2026-08-04"},{"id":"dpdp-penalties","framework":"DPDP Act 2023","fact":"Penalty ceiling","value":"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.","effective":"2027-05","source":{"label":"DPDP Act 2023, the Schedule (official Gazette text)","url":"https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf"},"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).","lastVerified":"2026-08-01"},{"id":"sebi-cscrf-issued","framework":"SEBI CSCRF","fact":"Issuance and final compliance timeline","value":"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.","effective":"2025-08-31","source":{"label":"SEBI — extension circular 2025/96 (official PDF, 30 June 2025)","url":"https://www.sebi.gov.in/sebi_data/attachdocs/jun-2025/1751286353420.pdf"},"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.","lastVerified":"2026-08-04"},{"id":"sebi-cscrf-re-categories","framework":"SEBI CSCRF","fact":"Regulated entities are sorted into five compliance categories","value":"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.","effective":"2024-08-20","source":{"label":"SEBI — CSCRF circular 2024/113 (official PDF, 20 August 2024)","url":"https://www.sebi.gov.in/sebi_data/attachdocs/aug-2024/1724326790365.pdf"},"note":"Portfolio Managers and Merchant Bankers were re-categorised by circular 2025/119 of 28 August 2025 (Part C).","lastVerified":"2026-08-04"},{"id":"sebi-cscrf-certin-empanelled-auditor","framework":"SEBI CSCRF","fact":"Audits must be conducted by a CERT-In empanelled organisation","value":"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.","effective":"2024-08-20","source":{"label":"SEBI — CSCRF circular 2024/113 (official PDF, 20 August 2024)","url":"https://www.sebi.gov.in/sebi_data/attachdocs/aug-2024/1724326790365.pdf"},"note":"Quoted verbatim from footnote 16, page 48 of 205.","lastVerified":"2026-08-04"},{"id":"sebi-cscrf-vapt-periodicity","framework":"SEBI CSCRF","fact":"VAPT frequency depends on NCIIPC designation","value":"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.","effective":"2024-08-20","source":{"label":"SEBI — CSCRF circular 2024/113 (official PDF, 20 August 2024)","url":"https://www.sebi.gov.in/sebi_data/attachdocs/aug-2024/1724326790365.pdf"},"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.","lastVerified":"2026-08-04"},{"id":"sebi-cscrf-vapt-timelines","framework":"SEBI CSCRF","fact":"VAPT reporting, closure and revalidation deadlines","value":"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.","effective":"2024-08-20","source":{"label":"SEBI — CSCRF circular 2024/113 (official PDF, 20 August 2024)","url":"https://www.sebi.gov.in/sebi_data/attachdocs/aug-2024/1724326790365.pdf"},"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.","lastVerified":"2026-08-04"},{"id":"sebi-cscrf-soc-mandate","framework":"SEBI CSCRF","fact":"A Security Operations Centre is mandatory, with a Market SOC route for smaller entities","value":"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.","effective":"2024-08-20","source":{"label":"SEBI — CSCRF circular 2024/113 (official PDF, 20 August 2024)","url":"https://www.sebi.gov.in/sebi_data/attachdocs/aug-2024/1724326790365.pdf"},"note":"Box Item 11, page 69. For small- and mid-size REs the Market SOC is also to provide VAPT and cyber audit services.","lastVerified":"2026-08-04"},{"id":"sebi-cscrf-cyber-capability-index","framework":"SEBI CSCRF","fact":"The Cyber Capability Index applies only to the top two categories","value":"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.","effective":"2024-08-20","source":{"label":"SEBI — CSCRF circular 2024/113 (official PDF, 20 August 2024)","url":"https://www.sebi.gov.in/sebi_data/attachdocs/aug-2024/1724326790365.pdf"},"note":"Page 14 of 205; the index itself is set out at Annexure-K, page 163.","lastVerified":"2026-08-04"},{"id":"sebi-cscrf-technical-clarifications","framework":"SEBI CSCRF","fact":"Latest amendment: technical clarifications of 28 August 2025","value":"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.","effective":"2025-08-28","source":{"label":"SEBI — technical clarifications circular 2025/119 (official PDF, 28 August 2025)","url":"https://www.sebi.gov.in/sebi_data/attachdocs/aug-2025/1756380695925.pdf"},"note":"This is the most recent CSCRF circular as at 2026-08-04.","lastVerified":"2026-08-04"},{"id":"rbi-payment-data-localisation","framework":"RBI","fact":"Payment system data storage in India","value":"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.","effective":"2018-10-06","source":{"label":"Reserve Bank of India (circular DPSS.CO.OD No.2785/06.08.005/2017-2018)","url":"https://www.rbi.org.in/"},"note":"Circular number cited for retrieval via RBI's notification search; we deliberately avoid deep-linking RBI's session-bound URLs.","lastVerified":"2026-08-01"},{"id":"pci-dss-4x-lifecycle","framework":"PCI DSS","fact":"v4.x lifecycle dates","value":"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.","effective":"2025-03-31","source":{"label":"PCI Security Standards Council (official blog)","url":"https://blog.pcisecuritystandards.org/now-is-the-time-for-organizations-to-adopt-the-future-dated-requirements-of-pci-dss-v4-x"},"lastVerified":"2026-08-01"},{"id":"pci-dss-saq-types","framework":"PCI DSS","fact":"Ten Self-Assessment Questionnaires are published","value":"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.","effective":null,"source":{"label":"PCI SSC — Document Library","url":"https://www.pcisecuritystandards.org/document_library/"},"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.","lastVerified":"2026-08-04"},{"id":"pci-dss-ai-assessment-guidance","framework":"PCI DSS","fact":"PCI SSC has published guidance on AI in assessments","value":"“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.","effective":null,"source":{"label":"PCI SSC — Document Library","url":"https://www.pcisecuritystandards.org/document_library/"},"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.","lastVerified":"2026-08-04"},{"id":"pci-dss-assessment-approaches","framework":"PCI DSS","fact":"Two approaches to implementing and validating requirements","value":"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.","effective":null,"source":{"label":"PCI SSC — PCI DSS v4.x ROC Template FAQs, Revision 1 (December 2022)","url":"https://www.pcisecuritystandards.org/document_library/"},"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.","lastVerified":"2026-08-04"},{"id":"pci-dss-assessment-findings","framework":"PCI DSS","fact":"Four possible findings per requirement","value":"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.","effective":null,"source":{"label":"PCI SSC — PCI DSS v4.x ROC Template FAQs, Revision 1 (December 2022)","url":"https://www.pcisecuritystandards.org/document_library/"},"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.","lastVerified":"2026-08-04"},{"id":"pci-dss-overall-assessment-result","framework":"PCI DSS","fact":"Three possible overall results, plus full or partial scope","value":"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.","effective":null,"source":{"label":"PCI SSC — PCI DSS v4.x ROC Template FAQs, Revision 1 (December 2022)","url":"https://www.pcisecuritystandards.org/document_library/"},"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.","lastVerified":"2026-08-04"},{"id":"pci-dss-roc-template-mandatory","framework":"PCI DSS","fact":"The ROC Template is mandatory for QSAs, with strict limits on personalisation","value":"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.","effective":null,"source":{"label":"PCI SSC — PCI DSS v4.x ROC Template FAQs, Revision 1 (December 2022)","url":"https://www.pcisecuritystandards.org/document_library/"},"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.","lastVerified":"2026-08-04"},{"id":"pci-dss-targeted-risk-analysis","framework":"PCI DSS","fact":"Two kinds of targeted risk analysis, reviewed every 12 months","value":"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.","effective":null,"source":{"label":"PCI SSC — Information Supplement: PCI DSS v4.x Targeted Risk Analysis Guidance (November 2023)","url":"https://www.pcisecuritystandards.org/document_library/"},"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.","lastVerified":"2026-08-04"},{"id":"pci-dss-tra-suggested-frequencies","framework":"PCI DSS","fact":"PCI SSC’s suggested frequencies for TRA-governed activities","value":"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.","effective":null,"source":{"label":"PCI SSC — Information Supplement: PCI DSS v4.x Targeted Risk Analysis Guidance (November 2023)","url":"https://www.pcisecuritystandards.org/document_library/"},"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.","lastVerified":"2026-08-04"},{"id":"pci-dss-desv","framework":"PCI DSS","fact":"Designated Entities Supplemental Validation applies only when a brand or acquirer requires it","value":"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.","effective":null,"source":{"label":"PCI SSC — PCI DSS v4.0 Supplemental ROC Template: DESV, Revision 1 (December 2022)","url":"https://www.pcisecuritystandards.org/document_library/"},"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.","lastVerified":"2026-08-04"},{"id":"pci-dss-evidence-retention","framework":"PCI DSS","fact":"Assessment evidence should be retained for at least three years","value":"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.","effective":null,"source":{"label":"PCI SSC — Information Supplement: Best Practices for Maintaining PCI DSS Compliance v2.0 (January 2019)","url":"https://www.pcisecuritystandards.org/documents/PCI_DSS_V2.0_Best_Practices_for_Maintaining_PCI_DSS_Compliance.pdf"},"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.","lastVerified":"2026-08-04"},{"id":"pci-dss-saq-a-eligibility","framework":"PCI DSS","fact":"SAQ A: card-not-present with all account data functions fully outsourced","value":"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.","effective":"2025-04","source":{"label":"PCI SSC — SAQ Instructions and Guidelines, v4.0.1 r1 (April 2025)","url":"https://www.pcisecuritystandards.org/document_library/"},"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.","lastVerified":"2026-08-04"},{"id":"pci-dss-saq-a-ep-eligibility","framework":"PCI DSS","fact":"SAQ A-EP: partially outsourced e-commerce where the merchant site affects payment security","value":"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.","effective":null,"source":{"label":"PCI SSC — SAQ Instructions and Guidelines, v4.0.1 r1 (April 2025)","url":"https://www.pcisecuritystandards.org/document_library/"},"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.","lastVerified":"2026-08-04"},{"id":"pci-dss-saq-b-eligibility","framework":"PCI DSS","fact":"SAQ B and B-IP: standalone terminals with no electronic account data storage","value":"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.","effective":null,"source":{"label":"PCI SSC — SAQ Instructions and Guidelines, v4.0.1 r1 (April 2025)","url":"https://www.pcisecuritystandards.org/document_library/"},"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.","lastVerified":"2026-08-04"},{"id":"pci-dss-saq-c-eligibility","framework":"PCI DSS","fact":"SAQ C and C-VT: internet-connected payment applications and virtual terminals","value":"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.","effective":null,"source":{"label":"PCI SSC — SAQ Instructions and Guidelines, v4.0.1 r1 (April 2025)","url":"https://www.pcisecuritystandards.org/document_library/"},"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.","lastVerified":"2026-08-04"},{"id":"pci-dss-saq-p2pe-eligibility","framework":"PCI DSS","fact":"SAQ P2PE: all processing through a validated PCI-listed P2PE solution","value":"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.","effective":null,"source":{"label":"PCI SSC — SAQ Instructions and Guidelines, v4.0.1 r1 (April 2025)","url":"https://www.pcisecuritystandards.org/document_library/"},"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.","lastVerified":"2026-08-04"},{"id":"pci-dss-saq-spoc-eligibility","framework":"PCI DSS","fact":"SAQ SPoC: SCRP device plus COTS phone or tablet in a validated SPoC solution","value":"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.","effective":null,"source":{"label":"PCI SSC — SAQ Instructions and Guidelines, v4.0.1 r1 (April 2025)","url":"https://www.pcisecuritystandards.org/document_library/"},"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.","lastVerified":"2026-08-04"},{"id":"pci-dss-saq-d-scope","framework":"PCI DSS","fact":"SAQ D is the catch-all for everyone the other SAQs do not fit","value":"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.","effective":null,"source":{"label":"PCI SSC — SAQ Instructions and Guidelines, v4.0.1 r1 (April 2025)","url":"https://www.pcisecuritystandards.org/document_library/"},"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.","lastVerified":"2026-08-04"},{"id":"pci-dss-saq-channel-rules","framework":"PCI DSS","fact":"SAQs are assessed per payment channel, and most exclude e-commerce and service providers","value":"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.","effective":null,"source":{"label":"PCI SSC — SAQ Instructions and Guidelines, v4.0.1 r1 (April 2025)","url":"https://www.pcisecuritystandards.org/document_library/"},"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.","lastVerified":"2026-08-04"},{"id":"iso-27001-2022-transition","framework":"ISO/IEC 27001","fact":"2022-revision transition deadline","value":"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.","effective":"2025-10-31","source":{"label":"ISO/IEC 27001 (iso.org)","url":"https://www.iso.org/standard/27001"},"note":"Deadline corroborated across accredited certification bodies (BSI, SGS, LRQA); iso.org blocks automated verification.","lastVerified":"2026-08-11"},{"id":"nist-csf-2","framework":"NIST CSF","fact":"Version 2.0 release","value":"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.","effective":"2024-02-26","source":{"label":"NIST (official release announcement)","url":"https://www.nist.gov/news-events/news/2024/02/nist-releases-version-20-landmark-cybersecurity-framework"},"lastVerified":"2026-08-01"},{"id":"nist-csf-six-functions","framework":"NIST CSF","fact":"Six Functions organise the Core","value":"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.","effective":"2024-02-26","source":{"label":"NIST — Cybersecurity Framework (CSF) 2.0, NIST CSWP 29","url":"https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf"},"note":"Function identifiers counted directly in NIST CSWP 29.","lastVerified":"2026-08-04"},{"id":"nist-csf-core-size","framework":"NIST CSF","fact":"The Core contains 22 Categories and 106 Subcategories","value":"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.","effective":"2024-02-26","source":{"label":"NIST — Cybersecurity Framework (CSF) 2.0, NIST CSWP 29","url":"https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf"},"note":"Counted from the unique Category and Subcategory identifiers (for example GV.OC, GV.OC-01) appearing in NIST CSWP 29 itself.","lastVerified":"2026-08-04"},{"id":"nist-csf-tiers","framework":"NIST CSF","fact":"Four Tiers describe rigour of risk governance","value":"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.","effective":"2024-02-26","source":{"label":"NIST — Cybersecurity Framework (CSF) 2.0, NIST CSWP 29","url":"https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf"},"note":"Tier names quoted verbatim from NIST CSWP 29.","lastVerified":"2026-08-04"},{"id":"nist-csf-outcomes-not-controls","framework":"NIST CSF","fact":"The CSF states outcomes and does not prescribe how to achieve them","value":"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.","effective":"2024-02-26","source":{"label":"NIST — Cybersecurity Framework (CSF) 2.0, NIST CSWP 29","url":"https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf"},"note":"Quoted from the Abstract of NIST CSWP 29.","lastVerified":"2026-08-04"},{"id":"rbi-it-governance-md","framework":"RBI","fact":"IT Governance Master Direction","value":"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.","effective":"2024-04-01","source":{"label":"Reserve Bank of India (Master Direction RBI/DoS/2023-24/107)","url":"https://www.rbi.org.in/"},"note":"Direction number cited for retrieval via RBI notification search; RBI deep links are session-bound.","lastVerified":"2026-08-01"},{"id":"rbi-it-outsourcing-md","framework":"RBI","fact":"IT Outsourcing Master Direction","value":"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.","effective":"2023-10-01","source":{"label":"Reserve Bank of India (Master Direction RBI/2023-24/102)","url":"https://www.rbi.org.in/"},"note":"Direction number cited for retrieval via RBI notification search.","lastVerified":"2026-08-01"},{"id":"iso-42001-published","framework":"ISO/IEC 42001","fact":"Publication","value":"ISO/IEC 42001:2023 — the first AI management system (AIMS) standard — was published in December 2023 by ISO/IEC.","effective":"2023-12","source":{"label":"ISO/IEC 42001 (iso.org)","url":"https://www.iso.org/standard/42001"},"note":"iso.org blocks automated verification; publication corroborated across accredited bodies and major assurance firms.","lastVerified":"2026-08-11"},{"id":"eu-ai-act-dates","framework":"EU AI Act","fact":"Commencement and GPAI obligations","value":"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).","effective":"2025-08-02","source":{"label":"EU AI Act — official text (EUR-Lex 2024/1689)","url":"https://eur-lex.europa.eu/eli/reg/2024/1689/oj"},"lastVerified":"2026-08-07"},{"id":"eu-ai-act-digital-omnibus-2026","framework":"EU AI Act","fact":"Digital Omnibus on AI - high-risk deadlines postponed (current)","value":"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.","effective":"2026-07-27","source":{"label":"Regulation (EU) 2026/1744 (Digital Omnibus on AI) - EUR-Lex","url":"https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng"},"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.","lastVerified":"2026-08-07"},{"id":"eu-ai-act-application-dates","framework":"EU AI Act","fact":"Staggered application under Article 113","value":"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.","effective":"2026-08-02","source":{"label":"EUR-Lex — Regulation (EU) 2024/1689 (Artificial Intelligence Act), Official Journal","url":"https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202401689"},"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.","lastVerified":"2026-08-07"},{"id":"eu-ai-act-penalties","framework":"EU AI Act","fact":"Three penalty tiers under Article 99","value":"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.","effective":"2025-08-02","source":{"label":"EUR-Lex — Regulation (EU) 2024/1689 (Artificial Intelligence Act), Official Journal","url":"https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202401689"},"note":"Article 99. Penalties applied from 2 August 2025 under Article 113(b); Member States set the detailed rules and notify the Commission.","lastVerified":"2026-08-04"},{"id":"eu-ai-act-legacy-transitions","framework":"EU AI Act","fact":"Transitional deadlines for systems already on the market","value":"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.","effective":"2026-08-02","source":{"label":"EUR-Lex — Regulation (EU) 2024/1689 (Artificial Intelligence Act), Official Journal","url":"https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202401689"},"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.","lastVerified":"2026-08-07"},{"id":"sama-csf","framework":"SAMA CSF (Saudi Arabia)","fact":"Cyber Security Framework issuance","value":"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.","effective":"2017-05","source":{"label":"SAMA Rulebook — Cyber Security Framework","url":"https://rulebook.sama.gov.sa/en/cyber-security-framework-2"},"lastVerified":"2026-08-04"},{"id":"nca-ecc","framework":"NCA ECC (Saudi Arabia)","fact":"Essential Cybersecurity Controls versions","value":"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.","effective":"2024","source":{"label":"NCA — Essential Cybersecurity Controls ECC – 2 : 2024 (English)","url":"https://cdn.nca.gov.sa/api/files/public/upload/86e09090-44e4-481f-bc28-355673607654_ECC--2024-EN.pdf"},"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.","lastVerified":"2026-08-11"},{"id":"cmmc-rules","framework":"CMMC (US DoD)","fact":"Programme and acquisition rule dates","value":"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.","effective":"2025-11-10","source":{"label":"US Federal Register — CMMC Program rule (32 CFR 170)","url":"https://www.federalregister.gov/documents/2024/10/15/2024-22905/cybersecurity-maturity-model-certification-cmmc-program"},"note":"48 CFR effective date corroborated across defence-contracting counsel and assessor publications.","lastVerified":"2026-08-01"},{"id":"uae-pdpl-structure","framework":"UAE PDPL","fact":"Obligations and rights - article map","value":"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).","effective":"2022-01-02","source":{"label":"UAE Legislation portal - Federal Decree-Law on Protection of Personal Data (official)","url":"https://uaelegislation.gov.ae/en/legislations/1972"},"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.","lastVerified":"2026-08-11"},{"id":"nca-ecc-compliance-mechanism","framework":"NCA ECC (Saudi Arabia)","fact":"Compliance evaluation mechanism","value":"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.","effective":"2024","source":{"label":"NCA - Essential Cybersecurity Controls ECC - 2 : 2024 (English), Implementation and Compliance section","url":"https://cdn.nca.gov.sa/api/files/public/upload/86e09090-44e4-481f-bc28-355673607654_ECC--2024-EN.pdf"},"note":"Read from the official ECC-2:2024 document (classification Public, TLP:White) on 11 August 2026.","lastVerified":"2026-08-11"},{"id":"uae-pdpl","framework":"UAE PDPL","fact":"Enactment and effect","value":"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.","effective":"2022-01-02","source":{"label":"UAE Legislation portal - Federal Decree-Law on Protection of Personal Data (official)","url":"https://uaelegislation.gov.ae/en/legislations/1972"},"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.","lastVerified":"2026-08-11"},{"id":"swift-csp","framework":"SWIFT CSP","fact":"Programme and independent assessment","value":"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.","effective":"2021","source":{"label":"SWIFT — Customer Security Programme (official)","url":"https://www.swift.com/myswift/customer-security-programme"},"lastVerified":"2026-08-11"},{"id":"swift-cscf-v2026-structure","framework":"SWIFT CSP","fact":"CSCF v2026 contains 32 controls — 26 mandatory and 6 advisory","value":"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.","effective":"2025-07-01","source":{"label":"Swift — Customer Security Controls Framework v2026, Detailed Description (1 July 2025)","url":"https://www.swift.com/myswift/customer-security-programme-document-centre"},"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.","lastVerified":"2026-08-11"},{"id":"swift-cscf-attestation-window","framework":"SWIFT CSP","fact":"Attestation against CSCF v2026 runs July to December 2026","value":"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.","effective":"2026-07","source":{"label":"Swift — Customer Security Controls Framework v2026, Detailed Description (1 July 2025)","url":"https://www.swift.com/myswift/customer-security-programme-document-centre"},"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.","lastVerified":"2026-08-11"},{"id":"swift-cscf-architecture-types","framework":"SWIFT CSP","fact":"Five reference architecture types determine which components are in scope","value":"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.","effective":"2025-07-01","source":{"label":"Swift — Customer Security Controls Framework v2026, Detailed Description (1 July 2025)","url":"https://www.swift.com/myswift/customer-security-programme-document-centre"},"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.","lastVerified":"2026-08-11"},{"id":"swift-cscf-v2026-control-2-4-mandatory","framework":"SWIFT CSP","fact":"Control 2.4 Back Office Data Flow Security became mandatory in v2026","value":"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.","effective":"2026-07","source":{"label":"Swift — Customer Security Controls Framework v2026, Detailed Description (1 July 2025)","url":"https://www.swift.com/myswift/customer-security-programme-document-centre"},"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.","lastVerified":"2026-08-11"},{"id":"swift-cscf-v2026-customer-client-connectors","framework":"SWIFT CSP","fact":"Customer client connectors are now mandatory in scope, moving some users from architecture B to A4","value":"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.","effective":"2026-07","source":{"label":"Swift — Customer Security Controls Framework v2026, Detailed Description (1 July 2025)","url":"https://www.swift.com/myswift/customer-security-programme-document-centre"},"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.","lastVerified":"2026-08-11"},{"id":"swift-cscf-v2026-other-changes","framework":"SWIFT CSP","fact":"Further v2026 changes affecting scope and control expectations","value":"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.","effective":"2026-07","source":{"label":"Swift — Customer Security Controls Framework v2026, Detailed Description (1 July 2025)","url":"https://www.swift.com/myswift/customer-security-programme-document-centre"},"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.","lastVerified":"2026-08-11"},{"id":"ckyc-registry-designation","framework":"CKYC (CERSAI)","fact":"CERSAI operates the Central KYC Records Registry","value":"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.","effective":"2015-11-26","source":{"label":"RBI — Master Direction, Know Your Customer (KYC) Direction, 2016 (updated 14 August 2025)","url":"https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=11566"},"note":"“the Rules” means the Prevention of Money-Laundering (Maintenance of Records) Rules, 2005.","lastVerified":"2026-08-07"},{"id":"ckyc-upload-ten-days","framework":"CKYC (CERSAI)","fact":"KYC records must reach the CKYCR within 10 days","value":"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.","effective":null,"source":{"label":"RBI — Master Direction, Know Your Customer (KYC) Direction, 2016 (updated 14 August 2025)","url":"https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=11566"},"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.","lastVerified":"2026-08-07"},{"id":"ckyc-phased-applicability","framework":"CKYC (CERSAI)","fact":"Applicability was phased between 2016 and 2021","value":"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.","effective":"2021-04-01","source":{"label":"RBI — Master Direction, Know Your Customer (KYC) Direction, 2016 (updated 14 August 2025)","url":"https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=11566"},"note":"The Legal Entity obligation is the most recently added and the one most often missing from older CKYC programmes built around individual onboarding.","lastVerified":"2026-08-07"},{"id":"ckyc-templates","framework":"CKYC (CERSAI)","fact":"Submissions use CERSAI templates that change over time","value":"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.","effective":null,"source":{"label":"RBI — Master Direction, Know Your Customer (KYC) Direction, 2016 (updated 14 August 2025)","url":"https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=11566"},"note":"Because the templates are revised, a validation performed against an older template version is not evidence that current submissions conform.","lastVerified":"2026-08-07"},{"id":"ckyc-identifier","framework":"CKYC (CERSAI)","fact":"The KYC Identifier lets one entity retrieve another’s KYC record","value":"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.","effective":null,"source":{"label":"RBI — Master Direction, Know Your Customer (KYC) Direction, 2016 (updated 14 August 2025)","url":"https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=11566"},"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.","lastVerified":"2026-08-07"},{"id":"qatar-nia","framework":"Qatar NIA (NCSA)","fact":"National Information Assurance Policy version","value":"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.","effective":"2023-05","source":{"label":"NCSA Qatar (official portal)","url":"https://ncsa.gov.qa/en/"},"note":"Version and date corroborated across Qatar-focused GRC publishers; the NCSA portal hosts the controlled document.","lastVerified":"2026-08-01"},{"id":"rbi-dpsc-2021","framework":"RBI","fact":"Digital Payment Security Controls Master Direction","value":"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.","effective":"2021-02-18","source":{"label":"Reserve Bank of India (Master Direction, 18 Feb 2021)","url":"https://www.rbi.org.in/"},"note":"Direction cited by title and date for retrieval via RBI notification search.","lastVerified":"2026-08-01"},{"id":"dpdp-breach-notification","framework":"DPDP Act 2023","fact":"Breach notification timeline (Rule 7)","value":"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.","effective":"2027-05","source":{"label":"DPDP Rules 2025, Rule 7","url":"https://static.pib.gov.in/WriteReadData/specificdocs/documents/2025/nov/doc20251117695301.pdf"},"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.","lastVerified":"2026-08-01"},{"id":"rbi-cyber-framework-2016","framework":"RBI","fact":"Cyber Security Framework in Banks","value":"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.","effective":"2016-06-02","source":{"label":"Reserve Bank of India (notification, 2 June 2016)","url":"https://www.rbi.org.in/commonman/English/scripts/Notification.aspx?Id=1721"},"lastVerified":"2026-08-01"},{"id":"gdpr-application","framework":"GDPR","fact":"Application date","value":"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).","effective":"2018-05-25","source":{"label":"GDPR — official text (EUR-Lex 2016/679)","url":"https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng"},"lastVerified":"2026-08-01"},{"id":"gdpr-breach-notification","framework":"GDPR","fact":"Breach notification to the supervisory authority within 72 hours","value":"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.","effective":"2018-05-25","source":{"label":"EUR-Lex — Regulation (EU) 2016/679 (GDPR), consolidated text","url":"https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679"},"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.","lastVerified":"2026-08-04"},{"id":"gdpr-fine-tiers","framework":"GDPR","fact":"Two tiers of administrative fine under Article 83","value":"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.","effective":"2018-05-25","source":{"label":"EUR-Lex — Regulation (EU) 2016/679 (GDPR), consolidated text","url":"https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679"},"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.","lastVerified":"2026-08-04"},{"id":"dpdp-notice-requirements","framework":"DPDP Act 2023","fact":"Notice contents (section 5)","value":"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.","effective":"2027-05","source":{"label":"DPDP Act 2023, section 5 (official Gazette text)","url":"https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf"},"note":"Contents verified directly against the Gazette PDF text. Notice must be available in English or any Eighth Schedule language.","lastVerified":"2026-08-01"},{"id":"hipaa-security-rule","framework":"HIPAA (US)","fact":"Security Rule compliance date","value":"Compliance with the HIPAA Security Rule was required from 20 April 2005 for most covered entities; small health plans had until 20 April 2006.","effective":"2005-04-20","source":{"label":"US HHS — HIPAA Security Rule","url":"https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html"},"lastVerified":"2026-08-11"},{"id":"hipaa-breach-individual-notice","framework":"HIPAA (US)","fact":"Individuals notified within 60 calendar days of discovery","value":"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.","effective":null,"source":{"label":"eCFR — 45 CFR Part 164 (HIPAA Security and Breach Notification Rules)","url":"https://www.ecfr.gov/current/title-45/part-164"},"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.","lastVerified":"2026-08-04"},{"id":"hipaa-breach-secretary-notice","framework":"HIPAA (US)","fact":"Reporting to the Secretary depends on breach size","value":"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.","effective":null,"source":{"label":"eCFR — 45 CFR Part 164 (HIPAA Security and Breach Notification Rules)","url":"https://www.ecfr.gov/current/title-45/part-164"},"note":"45 CFR § 164.408(b) and (c). The 500-individual threshold also determines whether a breach appears on the HHS public breach portal.","lastVerified":"2026-08-04"},{"id":"hipaa-security-safeguards","framework":"HIPAA (US)","fact":"The Security Rule is built on three classes of safeguard","value":"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.","effective":null,"source":{"label":"eCFR — 45 CFR Part 164 (HIPAA Security and Breach Notification Rules)","url":"https://www.ecfr.gov/current/title-45/part-164"},"note":"45 CFR § 164.304 definitions, quoted from the eCFR text current as of 31 July 2026.","lastVerified":"2026-08-04"},{"id":"iso-22301-amd1-2024","framework":"ISO 22301","fact":"Amendment 1:2024 (climate action)","value":"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.","effective":"2024-02","source":{"label":"ISO 22301:2019/Amd 1:2024 (iso.org)","url":"https://www.iso.org/standard/88412.html"},"note":"iso.org blocks automated verification; the amendment number, scope and date are corroborated across certification bodies and ISO's own catalogue listing.","lastVerified":"2026-08-07"},{"id":"iso-22301-2019","framework":"ISO 22301","fact":"2019 revision publication","value":"ISO 22301:2019 (business continuity management systems) was published 30 October 2019, replacing the 2012 first edition.","effective":"2019-10-30","source":{"label":"ISO 22301:2019 (iso.org)","url":"https://www.iso.org/standard/75106.html"},"note":"iso.org blocks automated verification; date corroborated across certification bodies.","lastVerified":"2026-08-11"},{"id":"dpdp-consent-manager-rule4","framework":"DPDP Act 2023","fact":"Consent Manager registration - Rule 4 in force 13 November 2026","value":"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.","effective":"2026-11-13","source":{"label":"MeitY - Digital Personal Data Protection Rules, 2025 (official page)","url":"https://www.meity.gov.in/documents/act-and-policies/digital-personal-data-protection-rules-2025-gDOxUjMtQWa"},"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.","lastVerified":"2026-08-08"},{"id":"dpdp-consent-manager-eligibility","framework":"DPDP Act 2023","fact":"Consent Manager eligibility - First Schedule, Part A","value":"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.","effective":"2026-11-13","source":{"label":"MeitY - Digital Personal Data Protection Rules, 2025, First Schedule Part A","url":"https://www.meity.gov.in/documents/act-and-policies/digital-personal-data-protection-rules-2025-gDOxUjMtQWa"},"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.","lastVerified":"2026-08-08"},{"id":"dpdp-consent-manager-obligations","framework":"DPDP Act 2023","fact":"Consent Manager obligations - First Schedule, Part B","value":"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.","effective":"2026-11-13","source":{"label":"MeitY - Digital Personal Data Protection Rules, 2025, First Schedule Part B","url":"https://www.meity.gov.in/documents/act-and-policies/digital-personal-data-protection-rules-2025-gDOxUjMtQWa"},"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.","lastVerified":"2026-08-08"},{"id":"iso-27001-2022-identity","framework":"ISO/IEC 27001","fact":"Current edition and title","value":"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.","effective":"2022-10","source":{"label":"ISO — ISO/IEC 27001:2022 catalogue entry","url":"https://www.iso.org/standard/27001"},"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.","lastVerified":"2026-08-08"},{"id":"soc2-security-category","framework":"SOC 2 (AICPA)","fact":"Security is near-universal but NOT mandatory","value":"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.","effective":"2022","source":{"label":"AICPA TSP Section 100, paragraphs .14 and .15","url":"https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022"},"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.","lastVerified":"2026-08-08"},{"id":"soc2-common-criteria-structure","framework":"SOC 2 (AICPA)","fact":"Common criteria structure","value":"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.","effective":"2022","source":{"label":"AICPA TSP Section 100 — common criteria and points of focus","url":"https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022"},"note":"Read from TSP Section 100 itself rather than from secondary summaries. Criterion count derived by enumerating the distinct CC references in the document.","lastVerified":"2026-08-08"},{"id":"soc2-trust-services-criteria","framework":"SOC 2 (AICPA)","fact":"Trust Services Criteria - current version","value":"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.","effective":"2022","source":{"label":"AICPA - 2017 Trust Services Criteria (With Revised Points of Focus - 2022)","url":"https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022"},"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.","lastVerified":"2026-08-08"},{"id":"soc2-engagement-nature","framework":"SOC 2 (AICPA)","fact":"What a SOC 2 report is","value":"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.","effective":null,"source":{"label":"AICPA - SOC 2 topic page","url":"https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2"},"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”.","lastVerified":"2026-08-08"},{"id":"irdai-2026-auditor-eligibility","framework":"IRDAI","fact":"Who may perform the audit (Annexure IV)","value":"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.","effective":"2026-04","source":{"label":"IRDAI Information and Cybersecurity Guidelines, 2026 — Annexure IV","url":"https://irdai.gov.in/en/document-detail?documentId=9189223"},"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.","lastVerified":"2026-08-08"},{"id":"irdai-2026-audit-submission","framework":"IRDAI","fact":"Audit report submission deadline","value":"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.","effective":"2026-04","source":{"label":"IRDAI Information and Cybersecurity Guidelines, 2026 — clause on audit submission","url":"https://irdai.gov.in/en/document-detail?documentId=9189223"},"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.","lastVerified":"2026-08-08"},{"id":"irdai-2026-no-mr-reliance","framework":"IRDAI","fact":"Management representation is not acceptable","value":"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.","effective":"2026-04","source":{"label":"IRDAI Information and Cybersecurity Guidelines, 2026 — Annexure IV clause 3","url":"https://irdai.gov.in/en/document-detail?documentId=9189223"},"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.","lastVerified":"2026-08-08"},{"id":"irdai-infosec-guidelines-2026","framework":"IRDAI","fact":"Information and Cybersecurity Guidelines, 2026 (current)","value":"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.","effective":"2026-04-06","source":{"label":"IRDAI - Information and Cybersecurity Guidelines, 2026 (official document portal)","url":"https://irdai.gov.in/en/document-detail?documentId=9189223"},"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.","lastVerified":"2026-08-07"},{"id":"irdai-infosec-guidelines-2023","framework":"IRDAI","fact":"Information and Cyber Security Guidelines, 2023 (superseded)","value":"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.","effective":"2023-04-24","source":{"label":"IRDAI - Information and Cyber Security Guidelines, 2023 (official document portal)","url":"https://irdai.gov.in/document-detail?documentId=3314780"},"lastVerified":"2026-08-07"},{"id":"npci-upi-tpap-cap-2026","framework":"NPCI / UPI","fact":"TPAP volume-cap compliance deadline - 31 December 2026","value":"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.","effective":"2026-12-31","source":{"label":"NPCI UPI circulars (official listing)","url":"https://www.npci.org.in/circulars/upi"},"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.","lastVerified":"2026-08-07"},{"id":"npci-upi-tpap-guidelines-oc97","framework":"NPCI / UPI","fact":"TPAP guidelines - audit and data obligations (OC 97)","value":"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.","effective":null,"source":{"label":"NPCI UPI circulars (official listing; OC 97 direct PDF withdrawn)","url":"https://www.npci.org.in/what-we-do/upi/circular"},"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.","lastVerified":"2026-08-11"}]}