The laws, standards, frameworks and certifications that apply to IT companies, software firms and SaaS businesses, explained from the official sources, with what is mandatory and what is voluntary marked on every entry.
IT compliance is the work of showing that your systems, software and processes meet the rules that apply to them. Those rules come from four very different places: laws passed by governments (GDPR, HIPAA, India's DPDP Act), directions issued by regulators (CERT-In, RBI, the SEC), contracts with customers or card brands (PCI DSS), and voluntary standards that an independent body can certify or report on (ISO/IEC 27001, SOC 2).
The difference matters. A law applies whether or not you choose it, and breaking it can mean penalties. A voluntary standard applies only when you adopt it, usually because customers ask for proof that you handle their data well. Many IT companies end up with both: a law that sets the obligation and a certification that shows the market how they meet it.
This directory lists each one with its full name, what it covers, who needs it, where it applies and the body that issues it. Every entry links to a full guide that walks through the requirements, the documents you need, the audit or assessment, typical timelines and costs, common mistakes and the official references. Use the filters to narrow the list by category, by type or by region.
96 guides
Search the compliance directory
Filter by category, by type (law, certification, attestation or framework) and by where it applies. Every entry links to a full guide.
Title 21 Code of Federal Regulations Part 11: Electronic Records; Electronic Signatures (US Food and Drug Administration)
21 CFR Part 11 sets the conditions under which the FDA accepts electronic records and electronic signatures as equivalent to paper records and handwritten signatures. It requires validated systems, secure computer-generated audit trails, access and authority controls, record protection and retention, and controls for unique, verified electronic signatures linked to records. FDA guidance narrows its scope, applies risk-based thinking, and, for device makers, promotes computer software assurance over heavy documentation.
Covers, who needs it, objectives
What it covers
Scope and predicate rules, controls for closed and open systems, audit trails, access and authority checks, electronic signature requirements, validation and computer software assurance, FDA guidance and enforcement discretion, cloud and SaaS considerations, and what vendors should provide.
Who needs it
Pharmaceutical, biotech and medical device companies, contract research and manufacturing organisations, clinical trial sponsors and sites, laboratories, and software vendors building LIMS, QMS, EDC, ELN, MES and other GxP systems.
Why it matters
FDA inspections check data integrity, and failures can lead to warning letters, rejected submissions and product delays; buyers expect vendors to support Part 11 features and validation.
Key objectives
Make electronic records trustworthy and reliable
Make electronic signatures legally equivalent to handwritten ones
Detect and prevent unauthorised changes
Retain records accurately for required periods
Support data integrity in regulated work
Where it applies
United States, applying to electronic records and signatures used to meet FDA requirements, including by companies outside the US that submit data to FDA or make FDA-regulated products.
Information blocking provisions of the 21st Century Cures Act (Section 4004) and HHS rules at 45 CFR Part 171
The information blocking provisions of the 21st Century Cures Act prohibit practices that are likely to interfere with access, exchange or use of electronic health information, unless required by law or covered by a regulatory exception. They apply to health care providers, certified health IT developers and health information networks. Developers and networks face civil penalties of over $1 million per violation, providers face Medicare disincentives, and HHS stepped up enforcement in 2025 and 2026.
Covers, who needs it, objectives
What it covers
Who is an actor, what electronic health information covers, what practices count as information blocking, the exceptions, certified API and Conditions of Certification, penalties and disincentives, 2025 to 2026 enforcement and rule changes, and steps for health IT vendors.
Who needs it
EHR and health IT developers, health information exchanges and networks, hospitals, clinics and physician practices, and software vendors building health apps and integrations.
Why it matters
Penalties are large, enforcement is now active, and product design choices such as API access, export features and fees can create or avoid information blocking risk.
Key objectives
Give patients and authorised parties access to their health information
Stop practices that unreasonably restrict data exchange
Promote standards-based APIs
Balance access with privacy and security through exceptions
Where it applies
United States. Applies to health care providers, developers of certified health IT, and health information networks and exchanges.
Ayushman Bharat Digital Mission (ABDM) and its Health Data Management Policy, with integration standards for health information providers and users
The Ayushman Bharat Digital Mission is India's national digital health ecosystem. It gives people an ABHA health ID, registers health professionals and facilities, and lets health records move between providers and apps only with the patient's consent, through a federated network where records stay with the providers that created them. Its Health Data Management Policy sets rules on consent, privacy, security and data rights, and software must follow ABDM standards and pass sandbox certification to integrate.
Covers, who needs it, objectives
What it covers
ABDM building blocks, roles of health information providers and users, consent and the consent manager, the Health Data Management Policy, technical standards, integration milestones and certification, security expectations and the link with the DPDP Act.
Who needs it
Hospitals, clinics, diagnostic labs, pharmacies, telemedicine and personal health record apps, health insurers and TPAs, and the HMIS, EMR, LIMS and health app vendors that build software for them.
Why it matters
ABDM integration is increasingly expected by hospitals, government schemes and insurers, and health data is among the most sensitive personal data under Indian law.
Key objectives
Give individuals control over their health records
Enable consent-based sharing between providers
Standardise health data with common formats
Protect health data with privacy and security safeguards
Where it applies
India. Applies to hospitals, clinics, labs, pharmacies, health apps and software vendors that choose to integrate with ABDM, and to government health programmes that require it.
Americans with Disabilities Act: web and mobile app accessibility under Title II (2024 rule, 28 CFR Part 35 Subpart H) and Title III
The Americans with Disabilities Act prohibits disability discrimination, and the US Department of Justice and courts apply it to websites and mobile apps. A 2024 DOJ rule requires state and local governments to make web content and mobile apps conform to WCAG 2.1 Level AA, with compliance dates extended in 2026 to April 2027 for larger entities and April 2028 for smaller ones. Businesses open to the public face Title III claims, with thousands of website accessibility lawsuits filed each year.
Covers, who needs it, objectives
What it covers
Title II and Title III of the ADA, the 2024 web and mobile rule and its 2026 extension, WCAG 2.1 AA, exceptions, vendor responsibilities, Title III litigation risk, overlays, testing and remediation steps.
Who needs it
State and local government bodies, public universities and schools, and the software vendors that build their websites, apps and portals; and businesses such as retailers, restaurants, banks, healthcare providers and SaaS companies serving the public.
Why it matters
Title II entities face fixed deadlines, vendors are expected to deliver conforming products, and businesses face frequent lawsuits over inaccessible websites and apps.
Key objectives
Give people with disabilities equal access to digital services
Set a clear technical standard for public bodies
Reduce discrimination in online commerce and services
Provide remedies when access is denied
Where it applies
United States. Title II covers state and local governments; Title III covers businesses that are public accommodations.
Privacy Act 1988 (Cth) and the Australian Privacy Principles, including the Notifiable Data Breaches scheme and 2024 amendments
The Privacy Act 1988 is Australia's main privacy law. It requires government agencies and most businesses with turnover above A$3 million to follow 13 Australian Privacy Principles on open handling, collection, use, disclosure, cross-border transfers, quality, security, access and correction of personal information. The Notifiable Data Breaches scheme requires notifying the OAIC and individuals of breaches likely to cause serious harm, and penalties reach A$50 million or more for serious interferences.
Covers, who needs it, objectives
What it covers
The 13 Australian Privacy Principles, who is an APP entity, sensitive information, cross-border disclosure under APP 8, security under APP 11, access and correction, the Notifiable Data Breaches scheme, penalties and the 2024 and proposed reforms.
Who needs it
Businesses with Australian customers or staff above the turnover threshold, health providers of any size, foreign companies carrying on business in Australia, and IT vendors handling personal information for Australian clients.
Why it matters
Large breaches in Australia led to much higher penalties and stronger OAIC powers, and Australian clients now scrutinise vendors' security and overseas data handling.
Key objectives
Manage personal information openly and transparently
Limit collection and use to what is reasonably necessary
Stay accountable for overseas disclosures
Secure personal information and destroy it when not needed
Notify eligible data breaches
Where it applies
Australia. Applies to Australian Government agencies and to organisations with an Australian link, including foreign businesses carrying on business in Australia, subject to the small business exemption.
Cloud Computing Compliance Criteria Catalogue (C5) of the German Federal Office for Information Security (BSI)
BSI C5 is the German Federal Office for Information Security's catalogue of minimum security requirements for cloud services. Independent auditors test a provider against the criteria and issue an attestation report, much like a SOC 2 report, which customers use to assess the service. C5 is expected by German public bodies and enterprises and is legally required for cloud processing of health data in the German healthcare system. A new version, C5:2026, adds criteria on areas such as key management, confidential computing and post-quantum cryptography.
Covers, who needs it, objectives
What it covers
The C5 criteria domains, basic and additional criteria, complementary customer criteria, environment parameters such as data location, Type 1 and Type 2 attestations, C5:2026 changes and timing, who requires C5, and preparation steps for SaaS and cloud providers.
Who needs it
Cloud service providers and SaaS companies selling to German public sector, healthcare, financial services and large enterprises, and the customers and auditors who evaluate them.
Why it matters
A C5 report is often a precondition for German cloud deals, and healthcare law makes it mandatory for some health data processing in the cloud.
Key objectives
Set minimum security requirements for cloud services
Give customers transparent, audited information
Disclose data location and jurisdiction
Clarify shared responsibilities with customers
Where it applies
Germany, with growing use across Europe. Required by German federal administration and, by law, for cloud processing of health data in the German healthcare system.
California Consumer Privacy Act of 2018, as amended by the California Privacy Rights Act of 2020 (Cal. Civ. Code 1798.100 and following), and CPPA regulations
The CCPA, as amended by the CPRA, is California's general consumer privacy law. It gives California residents the right to know, delete and correct personal information, to opt out of its sale or sharing for cross-context behavioural advertising, and to limit the use of sensitive personal information. It applies to for-profit businesses meeting revenue or data volume thresholds, requires specific contracts with service providers, and is enforced by a dedicated agency with fines per violation and a private right of action for some data breaches.
Covers, who needs it, objectives
What it covers
Collection, use, sale, sharing and retention of personal information of California residents, including employees and B2B contacts, plus security, contracts and new duties for risk assessments, cybersecurity audits and automated decisionmaking.
Who needs it
For-profit businesses doing business in California that exceed the revenue threshold or handle large volumes of California consumers' data, and the SaaS, IT and data vendors that serve them as service providers or contractors.
Why it matters
It is mandatory with per-violation fines, it shapes the contracts US customers ask vendors to sign, and other US state privacy laws follow a similar model.
Key objectives
Tell consumers what is collected and why
Let consumers access, delete and correct their data
Honour opt-outs of sale and sharing, including browser signals
Bind service providers by contract and protect data with reasonable security
Where it applies
California, United States. Applies to for-profit businesses that do business in California and meet a threshold, wherever they are based.
CERT-In Cyber Security Directions No. 20(3)/2022-CERT-In of 28 April 2022 under section 70B(6) of the IT Act, 2000
The CERT-In Directions of 28 April 2022 are binding cyber security directions issued by India's national computer emergency response team under section 70B(6) of the IT Act. They require service providers, intermediaries, data centres, body corporates and government organisations to report 20 types of cyber incidents to CERT-In within six hours of noticing them, keep logs of all ICT systems for 180 days within Indian jurisdiction, synchronise clocks to national time servers, and name a point of contact. Cloud, data centre and VPN providers have extra customer record duties.
Covers, who needs it, objectives
What it covers
Clock synchronisation, six-hour incident reporting, information requests from CERT-In, a point of contact, ICT log retention, subscriber records for data centres, VPS, cloud and VPN providers, and KYC records for virtual asset service providers.
Who needs it
Effectively every company in India, since "body corporate" includes any company, firm or sole proprietorship engaged in commercial activity, plus foreign entities offering services to users in India for incident reporting.
Why it matters
The duties are statutory, override confidentiality clauses in contracts, and failure to comply can lead to imprisonment of up to one year or a fine up to one lakh rupees.
Key objectives
Report cyber incidents to CERT-In within six hours
Keep logs that make incident analysis possible
Use synchronised, standard time across ICT systems
Give CERT-In a reachable point of contact and timely information
Where it applies
India. Applies to entities in India and, for incident reporting, to any entity offering services to users in India.
The CIS Critical Security Controls are a prioritised set of 18 controls and 153 specific safeguards that defend against the most common cyber attacks. Published by the non-profit Center for Internet Security, version 8.1 groups safeguards into three Implementation Groups, starting with IG1, a basic set for organisations with limited security expertise. They are voluntary, practical and mapped to the NIST CSF, ISO/IEC 27001 and other frameworks, which makes them a common starting point for small and mid-sized IT companies.
Covers, who needs it, objectives
What it covers
Asset and software inventory, data protection, secure configuration, account and access management, vulnerability management, logging, email and browser protection, malware defence, data recovery, network security, training, service providers, application security, incident response and penetration testing.
Who needs it
Any organisation, especially small and mid-sized IT firms, MSPs, SaaS companies and public bodies that want a concrete, prioritised security baseline.
Why it matters
It tells you what to do first, in plain technical terms, and maps your work to the frameworks customers and regulators ask about.
Key objectives
Know and control your hardware, software and data
Harden configurations and manage access
Detect, respond to and recover from attacks
Prioritise effort by Implementation Group
Where it applies
Global. Voluntary; referenced by some regulators, insurers and contracts as a reasonable baseline.
Cybersecurity Maturity Model Certification program (32 CFR Part 170 and DFARS 252.204-7021)
CMMC is the US Department of Defense program to verify that contractors protect federal contract information and Controlled Unclassified Information. It defines three levels, from basic safeguarding with annual self-assessment to certification against NIST SP 800-171 and enhanced requirements. The rules took effect in 2024 and 2025 with a phased rollout, but in July 2026 the department suspended Phase 2 and launched a review. Self-assessments, SPRS scores and DFARS 7012 duties still apply.
Covers, who needs it, objectives
What it covers
Assessment and affirmation of contractor cybersecurity for federal contract information (Level 1), CUI under NIST SP 800-171 (Level 2) and higher-risk CUI under selected NIST SP 800-172 requirements (Level 3).
Who needs it
DoD prime contractors and subcontractors at all tiers, including software developers, IT and managed service providers, and foreign suppliers, that handle FCI or CUI.
Why it matters
CMMC status is designed to be a condition of contract award; even during the suspension, the underlying NIST requirements and SPRS reporting remain contractual obligations.
Key objectives
Verify basic safeguarding of federal contract information
Verify implementation of NIST SP 800-171 for CUI
Add enhanced protections for the highest-risk programs
Make cybersecurity status a condition of award
Where it applies
United States Department of Defense supply chain, including foreign subcontractors handling federal contract information or CUI.
Capability Maturity Model Integration (CMMI), version 3.0, from the CMMI Institute (ISACA)
CMMI is a model for improving how organisations deliver software, services and other work. Version 3.0 organises good practices into practice areas across domains such as development, services, supplier management, security, safety, data and people, and defines maturity levels from 1 (initial) to 5 (optimizing). Organisations can be appraised by certified lead appraisers to obtain a maturity level rating, which many IT services companies use to show disciplined delivery to clients and government buyers.
Covers, who needs it, objectives
What it covers
What CMMI is, V3.0 structure, domains and practice areas, capability and maturity levels, appraisal types and validity, the appraisal process, costs, the 2026 AI maturity extension and how CMMI compares with ISO 9001 and agile practices.
Who needs it
Software development and IT services companies, especially outsourcers and government contractors, and organisations seeking structured process improvement.
Why it matters
A CMMI rating is a recognised signal of delivery maturity in tenders and enterprise outsourcing, and the model provides a practical path to more predictable projects.
Key objectives
Deliver projects predictably
Improve quality and reduce rework
Manage requirements, estimates and risks
Measure and improve performance
Build organisation-wide good practice
Where it applies
Global. Voluntary model; appraisals are recognised worldwide and common in Indian IT services and US government contracting.
COBIT 2019 (Control Objectives for Information and Related Technologies)
COBIT is ISACA's framework for the governance and management of enterprise information and technology. COBIT 2019 defines 40 governance and management objectives in five domains, describes the components a governance system needs, and uses design factors to tailor it to each organisation. It is voluntary, but auditors and regulators use it widely as a reference for IT controls, especially where IT supports financial reporting under SOX, and it complements ITIL for service management.
Covers, who needs it, objectives
What it covers
Governance of enterprise IT: board and executive direction, IT strategy, risk, security, architecture, portfolio, project and change management, operations, service delivery, and monitoring and assurance.
Who needs it
Enterprises of any size that want structured IT governance, IT auditors, regulated firms, and IT service providers whose clients use COBIT in vendor oversight.
Why it matters
It gives boards and auditors a common language for IT control and accountability, and it underpins many IT audit programmes.
Key objectives
Align IT with enterprise goals through a goals cascade
Balance benefits, risk and resources
Define clear governance and management responsibilities
Measure and improve process capability
Where it applies
Global. Voluntary; widely used by auditors, regulators and enterprises as a reference for IT governance and controls.
Colorado Senate Bill 24-205 (Consumer Protections for Artificial Intelligence), repealed and reenacted by Senate Bill 26-189 as an automated decision-making technology law
Colorado passed the first broad US state law on high-risk AI in 2024. SB 24-205 required developers and deployers of AI used in consequential decisions, such as hiring, lending, housing and healthcare, to prevent algorithmic discrimination and complete impact assessments. After delays and a federal court stay, Colorado repealed and reenacted it in May 2026 as SB 26-189, a narrower notice-based law on automated decision-making technology that takes effect on 1 January 2027.
Covers, who needs it, objectives
What it covers
The history of SB 24-205, its original obligations, the delay and federal litigation, the SB 26-189 replacement, consequential decisions, developer documentation, consumer notices, adverse decision explanations, correction and human review, liability allocation and enforcement.
Who needs it
Companies that build or use AI or automated decision tools to make or materially influence decisions about Colorado residents in employment, education, lending, housing, insurance or healthcare, including HR tech, fintech, insurtech and health tech vendors.
Why it matters
Colorado is the first US state with a broad law on AI in consequential decisions, and its notice, explanation and documentation duties will shape vendor contracts nationwide.
Key objectives
Tell consumers when automated tools drive important decisions
Explain adverse outcomes in plain language
Let consumers correct data and seek human review
Make developers document intended use and limits
Allocate liability between developers and deployers
Where it applies
Colorado, United States. Applies to developers and deployers of AI or automated decision-making technology used in consequential decisions about Colorado consumers.
Children's Online Privacy Protection Act of 1998 and the FTC Children's Online Privacy Protection Rule (16 CFR Part 312), as amended in 2025
COPPA is the US law that protects the personal information of children under 13 online. Operators of websites, apps, games and services directed to children, or that knowingly collect data from them, must give clear notice, obtain verifiable parental consent before collecting, using or disclosing children's data, keep it secure and limit retention. The FTC amended its rule in 2025, adding separate consent for third-party disclosures, written security programmes and retention policies, with compliance required from April 2026.
Covers, who needs it, objectives
What it covers
Collection, use and disclosure of personal information from children under 13 by online services: notice, verifiable parental consent, parental rights, data minimisation, security, retention and third-party sharing.
Who needs it
Developers and operators of children's apps, games, ed-tech products, toys with online features and general-audience services with actual knowledge of child users, plus ad and analytics providers that collect from them.
Why it matters
The FTC enforces it actively with large civil penalties, and app stores, schools and parents expect children's products to comply.
Key objectives
Put parents in control of children's data
Limit collection to what is reasonably necessary
Restrict sharing and targeted advertising
Keep children's data secure and delete it when no longer needed
Where it applies
United States. Applies to operators of websites and online services directed to children under 13, or with actual knowledge of collecting from them, including foreign operators serving US children.
COSO Internal Control, Integrated Framework (2013) and COSO Enterprise Risk Management, Integrating with Strategy and Performance (2017)
COSO publishes the most widely used frameworks for internal control and enterprise risk management. The 2013 Internal Control, Integrated Framework organises control into five components and 17 principles and is the basis for SOX internal control over financial reporting and the SOC 2 common criteria. The 2017 ERM framework links risk to strategy and performance through 20 principles. In 2026, COSO added guidance on internal control over generative AI.
Covers, who needs it, objectives
What it covers
The five components and 17 principles of internal control, IT general controls, the ERM framework and its 20 principles, links with SOX and SOC reports, fraud risk, and supplemental guidance on sustainability reporting and generative AI.
Who needs it
US listed companies and their auditors, companies preparing for IPO or investment, SaaS and IT service providers whose controls support clients' financial reporting, and internal audit teams.
Why it matters
COSO is the language auditors use for internal control, so technology companies that support financial processes meet it through SOX, SOC 1 and SOC 2 work.
Key objectives
Achieve reliable reporting
Run effective and efficient operations
Comply with laws and regulations
Link risk management with strategy and performance
Where it applies
Global, voluntary. Most widely used in the United States, where it is the standard framework for SOX internal control over financial reporting.
Cloud Security Alliance Security, Trust, Assurance and Risk (STAR) program and Cloud Controls Matrix (CCM)
CSA STAR is the Cloud Security Alliance's assurance program for cloud services. It is built on the Cloud Controls Matrix, a cloud-specific control framework of 17 domains, and the Consensus Assessments Initiative Questionnaire. Providers can publish a free self-assessment (Level 1) in the public STAR Registry or obtain independent assurance (Level 2) by combining the matrix with ISO/IEC 27001 certification or a SOC 2 attestation. The matrix moved to version 4.1 in 2026, and STAR for AI extends the program to AI services.
Covers, who needs it, objectives
What it covers
Cloud-specific security and privacy controls across 17 domains, from governance and supply chain to identity, encryption, logging, interoperability and endpoint management, and a transparent public registry of provider assessments.
Who needs it
Cloud infrastructure, platform and SaaS providers, and the enterprises that buy cloud services and want a standard way to assess them.
Why it matters
A STAR Registry entry answers many cloud security questionnaires in one public document, and Level 2 adds independent assurance mapped to recognised standards.
Key objectives
Describe cloud security controls in a common framework
Make provider assessments transparent and comparable
Reuse ISO/IEC 27001 and SOC 2 work for cloud-specific assurance
Where it applies
Global. Voluntary; recognised by enterprise buyers and some public sector cloud schemes.
Cyber Essentials and Cyber Essentials Plus, the UK government-backed certification scheme (Requirements for IT Infrastructure v3.3)
Cyber Essentials is the UK government-backed certification that shows an organisation has five basic technical controls in place: firewalls, secure configuration, security update management, user access control and malware protection. It is required for many UK government contracts and is common in supply chains. The April 2026 version 3.3 confirmed that cloud services can never be excluded from scope and that cloud logins must use MFA. Cyber Essentials Plus adds independent technical testing.
Covers, who needs it, objectives
What it covers
The five technical controls, scoping rules including cloud, BYOD and home working, the 14-day patching rule, MFA and password rules, Cyber Essentials Plus testing, the certification process, cost, and when UK buyers require it.
Who needs it
UK businesses, charities and public bodies, and overseas IT and software suppliers that sell to UK government or large UK companies.
Why it matters
It is a common gate to UK public sector and supply chain contracts, it is affordable for small firms, and the controls stop many common attacks.
Key objectives
Block common internet-based attacks
Keep systems patched and securely configured
Control and protect user accounts
Prevent malware from running
Give buyers an independent baseline assurance
Where it applies
United Kingdom. Open to organisations anywhere, and required for many UK public sector and some private sector contracts.
Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act)
The Cyber Resilience Act is the EU law that makes cybersecurity a legal requirement for hardware and software products sold in the EU. Manufacturers must design products to essential security requirements, handle vulnerabilities throughout a support period, provide security updates, keep a software bill of materials, carry out conformity assessment and apply CE marking. From 11 September 2026 they must report actively exploited vulnerabilities and severe incidents within 24 hours, and most other duties apply from December 2027.
Covers, who needs it, objectives
What it covers
Security by design and default for products with digital elements, vulnerability handling and disclosure, security updates and support periods, SBOMs, technical documentation, conformity assessment, CE marking and reporting of exploited vulnerabilities and incidents.
Who needs it
Manufacturers of software and connected hardware sold in the EU, including software publishers, app makers and IoT companies anywhere, plus importers, distributors and open-source software stewards.
Why it matters
Non-compliant products can be withdrawn from the EU market and fines reach 15 million euros or 2.5 percent of worldwide turnover.
Key objectives
Put products on the market without known exploitable vulnerabilities
Secure products by design and by default
Handle and disclose vulnerabilities throughout the support period
Report exploited vulnerabilities and severe incidents quickly
Where it applies
European Union market. Applies to products with digital elements made available in the EU, wherever they are made.
Regulation (EU) 2022/2065 on a Single Market for Digital Services (Digital Services Act, DSA)
The Digital Services Act sets EU-wide rules for online intermediaries, from internet access and hosting to social networks, marketplaces and app stores. It keeps liability exemptions for user content but adds tiered due diligence duties: points of contact and transparent terms for all, notice and action and statements of reasons for hosts, complaint handling, dark pattern bans, ad transparency and trader checks for platforms, and risk assessments and audits for very large platforms. Fines can reach 6 percent of global turnover.
Covers, who needs it, objectives
What it covers
Scope and tiers, liability exemptions, obligations for all intermediaries, hosting services, online platforms, marketplaces, very large platforms and search engines, protection of minors, advertising and recommender rules, enforcement, fines and practical steps.
Who needs it
Hosting and cloud providers, SaaS products with user-generated content, social networks, forums, marketplaces, app stores, booking and sharing platforms, search engines, and non-EU companies serving EU users.
Why it matters
Any service that stores or shares user content for EU users has DSA duties, and enforcement has begun, including a first fine of 120 million euros in December 2025.
Key objectives
Create a safer online environment
Give users rights to contest moderation decisions
Increase transparency of platforms, ads and algorithms
Address systemic risks of very large platforms
Harmonise rules across the EU
Where it applies
European Union. Applies to intermediary services offered to recipients in the EU, wherever the provider is established.
Digital Operational Resilience Act, Regulation (EU) 2022/2554
DORA is the EU regulation on digital operational resilience for the financial sector. Since January 2025 it has required banks, insurers, investment firms, payment and e-money institutions, crypto-asset providers and other financial entities to manage ICT risk, report major ICT incidents, test resilience and manage ICT third-party providers under strict contract rules. Software, cloud and IT service providers to these firms must accept DORA contract terms, and critical providers are overseen directly by EU supervisors.
Covers, who needs it, objectives
What it covers
ICT risk management, ICT incident classification and reporting, digital operational resilience testing, ICT third-party risk and contracts, oversight of critical ICT third-party providers, and information sharing.
Who needs it
EU financial entities of many types, and the software vendors, cloud providers, data centres and IT service firms, inside or outside the EU, that provide ICT services to them.
Why it matters
It is binding EU law for the financial sector, and every ICT supplier to an EU financial firm will meet its contract requirements, audits and exit planning demands.
Key objectives
Manage ICT risk under board accountability
Detect, classify and report major ICT incidents
Test digital operational resilience
Control dependence on ICT third-party providers
Where it applies
European Union. Applies directly to EU financial entities and reaches ICT third-party providers worldwide through contracts and, for critical providers, direct oversight.
Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025
The Digital Personal Data Protection Act, 2023 is India's first general law on personal data. It regulates the processing of digital personal data by data fiduciaries, gives people rights over their data, requires consent or a listed legitimate use, sets security and breach reporting duties, and creates the Data Protection Board of India. Its Rules were notified in November 2025 and are coming into force in phases through May 2027. Penalties reach 250 crore rupees per instance.
Covers, who needs it, objectives
What it covers
Collection, use, storage, sharing and erasure of digital personal data (and non-digital data later digitised), consent and notice, children's data, security safeguards, breach intimation, rights of data principals and cross-border transfers.
Who needs it
Every organisation that decides how digital personal data of people in India is processed, including Indian IT, SaaS, e-commerce, fintech, ed-tech and health-tech companies, and foreign companies offering goods or services in India. IT vendors acting as data processors are bound through contracts.
Why it matters
It is mandatory with very high penalties, and Indian clients will push its security and breach duties down to every IT vendor that processes data for them.
Key objectives
Process personal data only with valid consent or a listed legitimate use
Give clear notice and let people withdraw consent easily
Protect data with reasonable security safeguards
Report breaches to the Board and to affected people
Erase data when it is no longer needed
Where it applies
India, and processing outside India connected with offering goods or services to people in India (section 3).
Directive 2002/58/EC on privacy and electronic communications, as amended by Directive 2009/136/EC (the "cookie law")
The ePrivacy Directive is the EU law behind cookie banners. Article 5(3) requires prior consent before storing or accessing information on a user's device, such as cookies, pixels, local storage and fingerprinting, unless strictly necessary for a service the user requested. It also restricts unsolicited electronic marketing and protects the confidentiality of communications, traffic and location data. It sits alongside the GDPR and is enforced through national laws, often by data protection authorities.
Covers, who needs it, objectives
What it covers
Consent for cookies and similar technologies, strictly necessary exemptions, consent quality, electronic marketing and the soft opt-in, confidentiality of communications, traffic and location data, telecom security and reform proposals.
Who needs it
Every website, app, SaaS product, e-commerce store and connected device used by people in the EU, marketers sending email or SMS, and providers of electronic communications services.
Why it matters
Cookie enforcement is one of the most active areas of EU privacy enforcement, and analytics, ads and tracking setups must respect consent before loading.
Key objectives
Protect users' devices from unconsented access
Make tracking optional and transparent
Limit unsolicited marketing
Protect confidentiality of communications
Where it applies
European Union and EEA, implemented through national laws in each member state. Applies to websites and apps accessing devices of users in the EU, wherever the provider is based.
Australian Signals Directorate (ASD) Essential Eight mitigation strategies and Essential Eight Maturity Model
The Essential Eight is the Australian Signals Directorate's set of eight prioritised mitigation strategies against common cyber attacks: application control, patching applications, configuring Microsoft Office macros, user application hardening, restricting administrative privileges, patching operating systems, multi-factor authentication and regular backups. The Maturity Model defines levels one to three for each strategy. It is mandatory for many Australian government entities and widely required of suppliers, and ASD began consulting in 2026 on a broader successor series.
Covers, who needs it, objectives
What it covers
The eight strategies, maturity levels and their adversary assumptions, key requirements at each level, assessment approach, government mandates, how suppliers are affected, and ASD's planned transition to the Essentials series.
Who needs it
Australian government agencies, businesses and not-for-profits, managed service providers, and overseas IT and software suppliers serving Australian clients.
Why it matters
It is the most cited cyber baseline in Australia, used in government policy, procurement, cyber insurance and board reporting.
Key objectives
Prevent malware delivery and execution
Limit the extent of cyber security incidents
Recover data and system availability
Raise baseline maturity in a prioritised way
Where it applies
Australia. Mandatory for non-corporate Commonwealth entities under the Protective Security Policy Framework; widely used voluntarily by Australian businesses and their suppliers.
EU-U.S. Data Privacy Framework (DPF), with the UK Extension and the Swiss-U.S. DPF
The EU-U.S. Data Privacy Framework lets EU and EEA organisations transfer personal data to US companies that self-certify to it, without standard contractual clauses or transfer impact assessments for those transfers. US organisations commit to the DPF Principles on notice, choice, onward transfer, security, data integrity, access and recourse, under FTC or Department of Transportation enforcement. It replaced the invalidated Privacy Shield, has UK and Swiss counterparts, and faces a pending legal challenge.
Covers, who needs it, objectives
What it covers
Eligibility, the self-certification process, the seven DPF Principles and supplemental principles, recourse mechanisms, HR data, onward transfers, the UK Extension and Swiss-U.S. DPF, US surveillance safeguards and legal risks.
Who needs it
US SaaS, cloud and IT companies receiving personal data from EU, UK or Swiss customers, and EU, UK and Swiss organisations choosing US vendors.
Why it matters
Certification simplifies sales to European customers and removes the need for transfer assessments, but it can be challenged, so a fallback is prudent.
Key objectives
Provide a lawful EU to US transfer route
Bind US recipients to privacy principles
Give individuals free recourse
Limit US intelligence access to what is necessary and proportionate
Where it applies
Transfers of personal data from the EU and EEA (and, through extensions, the UK and Switzerland) to US organisations that self-certify with the US Department of Commerce.
Artificial Intelligence Act, Regulation (EU) 2024/1689, as amended by the Digital Omnibus on AI, Regulation (EU) 2026/1744
The EU AI Act is the European Union's law on artificial intelligence. It bans certain AI practices, sets strict requirements for high-risk AI systems used in areas such as employment, education, credit and critical infrastructure, imposes transparency duties on chatbots and AI-generated content, and regulates general-purpose AI models. It applies in stages: prohibitions since February 2025, general-purpose AI rules since August 2025, transparency from August 2026, and high-risk rules from December 2027 and August 2028 after the 2026 Digital Omnibus amendments.
Covers, who needs it, objectives
What it covers
Placing on the market, putting into service and use of AI systems and general-purpose AI models in the EU, by risk level: prohibited, high-risk, transparency-risk and minimal-risk.
Who needs it
Software companies that build AI features or AI products used in the EU (providers), businesses that use AI systems professionally (deployers), and importers and distributors. Includes non-EU companies whose AI output is used in the EU.
Why it matters
It is binding law with fines of up to 35 million euros or 7 percent of worldwide turnover, and EU customers will ask suppliers to show how their AI features comply.
Key objectives
Ban AI practices that are unacceptable
Make high-risk AI safe, transparent and overseen by people
Tell people when they interact with AI or see AI-generated content
Make general-purpose AI model providers document and share information
Where it applies
European Union. Also applies to providers and deployers outside the EU when they place AI systems on the EU market or the output of their AI is used in the EU (Article 2).
Regulation (EU) 2023/2854 on harmonised rules on fair access to and use of data (Data Act)
The EU Data Act gives users of connected products, such as smart devices, vehicles and industrial machines, the right to access and share the data their use generates, and requires manufacturers to design products so data is accessible. It also makes switching between cloud providers easier, bans unfair data contract terms imposed on businesses, lets public bodies request data in exceptional need, protects non-personal data from unlawful foreign access, and sets interoperability rules. It has applied since 12 September 2025.
Covers, who needs it, objectives
What it covers
Scope, user rights to connected product data, data holder and manufacturer duties, design obligations, sharing with third parties, unfair contract terms, business-to-government access, cloud and edge switching, international access safeguards, interoperability and smart contracts, enforcement, and proposed changes.
Who needs it
Manufacturers of connected products and providers of related services (IoT, vehicles, appliances, industrial equipment), SaaS and cloud providers, data platforms, and businesses that buy or license data.
Why it matters
It changes product design, data access and cloud contracts for anyone serving the EU market, with key deadlines in 2026 and 2027.
Key objectives
Give users control over data from connected products
Enable fair data sharing and competition
Make cloud switching easier and cheaper
Protect businesses from unfair data terms
Safeguard EU data from unlawful foreign access
Where it applies
European Union. Applies to manufacturers and data holders of connected products and related services placed on the EU market, cloud and edge providers serving EU customers, and others, wherever they are established.
Directive (EU) 2019/882 on the accessibility requirements for products and services (European Accessibility Act)
The European Accessibility Act is an EU directive that sets common accessibility requirements for key products and services, including e-commerce, consumer banking, e-books, electronic communications, passenger transport services, computers, smartphones and self-service terminals. Since 28 June 2025, businesses offering these to EU consumers must make them accessible, usually by meeting the harmonised standard EN 301 549, which incorporates WCAG 2.1 AA for web content. It applies to non-EU companies selling into the EU.
Covers, who needs it, objectives
What it covers
Accessibility of listed consumer products and services, including their websites, mobile apps, e-tickets and electronic documents, plus service information, conformity, exemptions and market surveillance.
Who needs it
E-commerce businesses, banks and fintechs offering consumer banking, e-book publishers, telecom providers, transport operators, device makers, and the software and agency partners who build their digital channels.
Why it matters
It is binding in all member states since June 2025, applies to companies outside the EU selling to EU consumers, and authorities can order fixes, withdraw products and impose penalties.
Key objectives
Remove accessibility barriers in key products and services
Harmonise accessibility rules across the EU single market
Make digital channels usable by people with disabilities
Inform consumers about accessibility
Where it applies
European Union member states, through national laws. Applies to products and services offered to consumers in the EU, wherever the business is based.
FedRAMP is the US government program that standardises security assessment of cloud services used by federal agencies. A cloud service offering must obtain FedRAMP certification, based on NIST SP 800-53 controls and assessment by an accredited third party, before agencies rely on it. In 2026 the program adopted Consolidated Rules, renamed authorizations to certifications, replaced Low, Moderate and High impact levels with certification classes, and began moving all providers from the Rev5 process to the automation-based FedRAMP 20x.
Covers, who needs it, objectives
What it covers
Security requirements, independent assessment, certification and ongoing monitoring of cloud services (SaaS, PaaS, IaaS) used by US federal agencies.
Who needs it
Cloud and SaaS providers, including non-US companies, that want to sell to US federal agencies, and their subcontractors and underlying cloud platforms.
Why it matters
Without it, federal agencies generally cannot use your cloud service for federal information; with it, one certification can be reused by many agencies.
Key objectives
Assess cloud security once and reuse it across agencies
Base requirements on NIST controls
Use independent assessors
Monitor certified services continuously
Where it applies
United States federal government. Required for cloud services used by federal agencies.
Family Educational Rights and Privacy Act of 1974 (20 U.S.C. 1232g; 34 CFR Part 99)
FERPA is the US federal law that protects the privacy of student education records held by schools, districts and colleges that receive federal education funding. It gives parents, and students once they turn 18 or attend college, rights to access and correct records, and generally requires consent before personally identifiable information from records is disclosed. Ed-tech and LMS vendors typically receive student data under the school official exception, which limits how they can use and redisclose it.
Covers, who needs it, objectives
What it covers
Education records, rights of parents and eligible students, consent for disclosure of personally identifiable information, exceptions such as the school official and directory information exceptions, records of disclosures and annual notification.
Who needs it
K-12 schools and districts, colleges and universities receiving federal education funds, and the ed-tech, LMS, student information system and analytics vendors that handle student data for them.
Why it matters
Schools cannot share student records with vendors unless an exception applies, so vendors must meet FERPA conditions in contracts to win and keep education customers.
Key objectives
Give families control over education records
Limit disclosure of personally identifiable student information
Allow schools to use service providers under defined conditions
Keep records of disclosures
Where it applies
United States. Applies to educational agencies and institutions that receive funds from US Department of Education programs, and reaches their vendors through contracts.
Federal Information Security Modernization Act of 2014 (44 U.S.C. 3551 and following)
FISMA is the US federal law that requires every federal agency to run an agency-wide information security programme, protect its information systems according to NIST standards, report incidents to CISA, and be evaluated annually by its inspector general. The 2014 modernisation clarified the roles of OMB and the Department of Homeland Security and strengthened incident reporting. It applies to agencies directly and reaches IT contractors and cloud providers through contracts and programs such as FedRAMP.
Covers, who needs it, objectives
What it covers
Agency information security programmes, risk management, NIST-based security controls, incident detection and reporting, continuous monitoring, annual independent evaluations and reporting to OMB and Congress.
Who needs it
US federal agencies, and IT contractors, system integrators and service providers that operate systems or process federal information on an agency's behalf.
Why it matters
It is the legal foundation for US federal cybersecurity requirements, so vendors to federal agencies meet its obligations through contract clauses, NIST controls and FedRAMP.
Key objectives
Run an agency-wide, risk-based information security programme
Protect systems using NIST standards and guidelines
Detect, report and respond to incidents
Evaluate and report security annually
Where it applies
United States federal agencies, and contractors and others operating information systems on their behalf.
General Data Protection Regulation, Regulation (EU) 2016/679
The GDPR is the European Union's data protection law. It sets the rules for processing personal data of people in the EU: lawful bases, transparency, data minimisation, security, individual rights, breach notification within 72 hours, and limits on transfers outside the EU. It applies to EU organisations and to companies elsewhere that offer goods or services to people in the EU or monitor them. Fines can reach 20 million euros or 4 percent of worldwide annual turnover.
Covers, who needs it, objectives
What it covers
Any processing of personal data by controllers and processors in scope: collection, storage, use, sharing, transfer abroad and deletion, plus the rights of the people the data is about.
Who needs it
EU-based organisations of every size, and non-EU companies (including Indian and US IT firms) that target or monitor people in the EU or process EU personal data for clients as processors.
Why it matters
It is mandatory where it applies, carries high fines, and EU clients will not contract with a supplier that cannot meet its processor obligations.
Key objectives
Process personal data only on a lawful basis and transparently
Collect the minimum and keep it no longer than needed
Secure data and report breaches promptly
Let people exercise their rights
Protect data when it leaves the EU
Where it applies
European Union and EEA; also organisations outside the EU that offer goods or services to people in the EU or monitor their behaviour there (Article 3).
Gramm-Leach-Bliley Act (1999): FTC Standards for Safeguarding Customer Information (16 CFR Part 314) and privacy requirements
The Gramm-Leach-Bliley Act is the US law governing how financial institutions protect and share consumers' financial information. Its FTC Safeguards Rule requires non-bank financial institutions, a broad group that includes many fintechs, lenders, brokers and tax preparers, to run a written information security program with a qualified individual in charge, risk assessments, encryption, MFA, monitoring, testing, vendor oversight and incident response, and to notify the FTC of certain breaches.
Covers, who needs it, objectives
What it covers
Information security programs for customer financial information, risk assessments, specific safeguards, service provider oversight, incident response, board reporting and breach notification to the FTC, plus privacy notices and opt-outs under the related privacy rules.
Who needs it
Non-bank financial institutions such as fintech lenders, payment and money services, mortgage brokers, auto dealers that finance, tax preparers, collection agencies and some universities, and the software and IT vendors that serve them.
Why it matters
It is enforced by the FTC, now requires breach reporting, and drives the security clauses fintechs put in contracts with technology vendors.
Key objectives
Protect the security and confidentiality of customer information
Protect against anticipated threats
Protect against unauthorised access that could harm customers
Oversee service providers
Where it applies
United States. The FTC Safeguards Rule covers non-bank financial institutions under FTC jurisdiction; banks follow equivalent interagency guidelines.
GovRAMP (StateRAMP doing business as GovRAMP), the cloud security verification programme for US state and local government
GovRAMP, originally launched as StateRAMP in 2020, is a nonprofit programme that verifies the security of cloud products sold to US state and local governments. Based on NIST SP 800-53 Rev. 5 and FedRAMP baselines, it lets providers be verified once and serve many governments. Providers can start with a Security Snapshot, move to Core status covering 60 priority controls, and progress to Ready, Provisionally Authorized or Authorized with independent assessment and continuous monitoring. FedRAMP-assessed products can use a fast track.
Covers, who needs it, objectives
What it covers
Who requires GovRAMP, verified and progressing statuses, impact levels, Security Snapshots and Core, 3PAO assessments, the Fast Track for FedRAMP products, continuous monitoring, TX-RAMP and how it compares with FedRAMP.
Who needs it
SaaS and cloud providers selling to US states, counties, cities, public universities and school systems, and the state and local agencies that buy from them.
Why it matters
A growing number of states require GovRAMP status in cloud procurements, and one verification can be reused across many governments.
Key objectives
Verify cloud security once for many governments
Align state and local requirements with federal baselines
Provide continuous monitoring of providers
Give providers a stepwise path to authorization
Where it applies
United States state and local governments, public higher education and other participating public bodies that adopt GovRAMP in procurement.
Health Insurance Portability and Accountability Act of 1996: Privacy, Security and Breach Notification Rules (45 CFR Parts 160 and 164)
HIPAA is the US federal law that protects health information held by health plans, healthcare clearinghouses and most healthcare providers, and by their business associates, which include many software, cloud and IT vendors. Its Privacy Rule limits uses and disclosures of protected health information, its Security Rule requires administrative, physical and technical safeguards for electronic health information, and its Breach Notification Rule sets deadlines for reporting breaches. Compliance is mandatory where it applies.
Covers, who needs it, objectives
What it covers
Uses and disclosures of protected health information, safeguards for electronic PHI, patient rights, business associate contracts and breach notification.
Who needs it
Covered entities (health plans, clearinghouses, providers who bill electronically) and their business associates: EHR, telehealth, billing, cloud hosting, analytics and IT service vendors handling PHI.
Why it matters
It is federal law with civil and criminal penalties, and US healthcare customers cannot share PHI with a vendor that will not sign and honour a business associate agreement.
Key objectives
Use and disclose PHI only as the Privacy Rule permits
Protect ePHI with a documented risk analysis and safeguards
Bind every vendor that handles PHI with a business associate agreement
Detect, assess and report breaches on time
Where it applies
United States federal law. Reaches vendors anywhere through business associate agreements with US covered entities.
Health Information Technology for Economic and Clinical Health Act (Title XIII of the American Recovery and Reinvestment Act of 2009)
The HITECH Act is a 2009 US law that pushed adoption of electronic health records and strengthened HIPAA. For IT vendors, its key effects are that business associates became directly liable for HIPAA Security Rule compliance, breaches of unsecured health information must be notified, penalties were increased in tiers, state attorneys general can enforce HIPAA, and, since a 2021 amendment, regulators must consider recognised security practices an organisation had in place when setting penalties.
Covers, who needs it, objectives
What it covers
Business associate obligations and liability, breach notification for PHI and personal health records, tiered civil penalties, enforcement by HHS and state attorneys general, limits on sale and marketing use of PHI, and incentives for electronic health records.
Who needs it
HIPAA covered entities, business associates and subcontractors (including health-tech, cloud and IT vendors), and vendors of personal health records and health apps covered by the FTC rule.
Why it matters
It is the reason software vendors handling PHI are directly liable under HIPAA, and it defines breach notification duties and the penalty structure vendors face.
Key objectives
Promote adoption of electronic health records
Make business associates directly accountable
Require notification of breaches of unsecured health information
Strengthen enforcement and penalties
Where it applies
United States federal law, applied through HIPAA to covered entities and business associates, and through FTC rules to some health apps.
HITRUST Common Security Framework (CSF) and HITRUST e1, i1 and r2 assessments and certifications
HITRUST is a private security and privacy framework and certification program widely used in US healthcare. Its Common Security Framework harmonises requirements from HIPAA, NIST, ISO, PCI DSS and other sources into one control set, and its e1, i1 and r2 assessments offer increasing levels of assurance, validated by authorised assessors and HITRUST quality review. It is voluntary and not a government certification, but many health systems and payers require HITRUST from vendors that handle patient data.
Covers, who needs it, objectives
What it covers
Security and privacy controls across 19 assessment domains, scaled by risk factors, with assurance levels from essential cyber hygiene to in-depth risk-based assessment, plus an AI security extension.
Who needs it
Health-tech vendors, SaaS and cloud providers, billing and claims processors, and other business associates of US healthcare organisations, as well as health organisations themselves.
Why it matters
Large US healthcare customers often require it in procurement, and one HITRUST certification can replace many separate vendor security questionnaires.
Key objectives
Harmonise many security and privacy requirements in one framework
Provide scalable, independently validated assurance
Reduce repeated vendor questionnaires in healthcare
Address emerging threats such as AI risks
Where it applies
Developed in the United States and used mostly in US healthcare supply chains; vendors anywhere can be assessed.
IEC 62304: Medical device software, Software life cycle processes (Edition 1.1, IEC 62304:2006+AMD1:2015)
IEC 62304 defines the software life cycle processes for medical device software, including standalone software as a medical device. It classifies software into safety classes A, B and C based on the harm a failure could cause, then scales requirements for planning, requirements, architecture, design, implementation, verification, release, maintenance, risk management, configuration management and problem resolution. Regulators in the US and EU expect conformance, and a second edition broadening scope to health software is in development.
Covers, who needs it, objectives
What it covers
Scope, software safety classification, development, maintenance, risk management with ISO 14971, configuration management, problem resolution, SOUP, documentation, regulatory use with FDA and EU MDR, agile adoption and the planned Edition 2.
Who needs it
Medical device manufacturers, digital health and SaMD companies, and software development partners building or maintaining medical device software.
Why it matters
FDA submissions and EU MDR technical files depend on showing a controlled software life cycle, and development partners must work to it.
Key objectives
Develop medical software safely and predictably
Scale rigour to the risk of harm
Control changes and maintenance
Manage risks from software and third-party components
Produce evidence for regulators
Where it applies
Global. Recognised by the US FDA as a consensus standard and harmonised in the EU for demonstrating conformity under the Medical Device Regulation.
India AI Governance Guidelines: Enabling Safe and Trusted AI Innovation (MeitY, IndiaAI Mission, November 2025)
India's AI Governance Guidelines, released by MeitY on 5 November 2025, set out how India intends to govern AI without a standalone AI law for now. They define seven guiding principles, or sutras, and recommendations across six pillars, from infrastructure to accountability. They propose graded liability, AI incident reporting, content authentication, regulatory sandboxes and new institutions, and rely on existing laws such as the IT Act, IT Rules and DPDP Act for enforcement.
Covers, who needs it, objectives
What it covers
The seven sutras, six pillars, proposed institutions, the decision not to enact a separate AI law yet, graded liability, incident systems, content authentication and deepfakes, copyright, the action plan, and how existing Indian laws apply to AI products.
Who needs it
AI product companies, SaaS and app developers adding AI features, enterprises deploying AI, generative AI and model providers serving Indian users, and their legal and compliance teams.
Why it matters
The guidelines shape how regulators and courts view AI, signal coming obligations, and sit alongside binding rules such as the 2026 synthetic content duties under the IT Rules.
Key objectives
Enable AI innovation while managing risk
Build trust through transparency and accountability
Protect people from AI harms such as deepfakes and discrimination
Use existing laws consistently
Create institutions for AI oversight
Where it applies
India. Applies as policy guidance to developers, deployers and users of AI systems in India, alongside binding existing laws.
The Information Technology Act, 2000 (Act No. 21 of 2000), as amended by the Information Technology (Amendment) Act, 2008
The Information Technology Act, 2000 is India's core law for electronic commerce, electronic records and cyber security. It gives legal recognition to electronic records and digital signatures, defines cyber offences such as hacking, identity theft and data theft, sets compensation for unauthorised access and for failing to protect sensitive personal data, regulates intermediaries, and gives the government and CERT-In powers over incidents, blocking and interception. Most rules that apply to IT companies, from CERT-In Directions to the intermediary rules, are made under it.
Covers, who needs it, objectives
What it covers
Electronic records and signatures, electronic contracts, certifying authorities, cyber contraventions and offences, data protection for sensitive personal data (section 43A), intermediary liability, blocking, interception and incident response.
Who needs it
Every company in India that uses computer systems, and especially IT services firms, software companies, SaaS and cloud providers, data centres, e-commerce platforms and other intermediaries.
Why it matters
It defines what IT companies and their staff can be liable for, and it is the legal basis for CERT-In incident reporting, the intermediary rules and the SPDI Rules.
Key objectives
Give electronic records and signatures legal validity
Define and penalise cyber offences and contraventions
Make companies protect sensitive personal data and honour confidentiality
Regulate intermediaries and enable incident response and blocking
Where it applies
India. Section 75 extends it to offences committed outside India involving a computer system or network located in India.
IRDAI Information and Cyber Security Guidelines, 2026 (revising the 2023 Guidelines on Information and Cyber Security for Regulated Entities)
IRDAI's Information and Cyber Security Guidelines set minimum security standards and governance for insurers and insurance intermediaries in India. The 2026 revision, issued on 6 April 2026 and applicable from the 2026-27 financial year, keeps the 2023 structure but strengthens governance: quarterly security committee meetings, a new IT Steering Committee, an independent and technically qualified CISO, risk-based budgets, independent experts on the risk committee, and remediation of audit gaps within 12 months.
Covers, who needs it, objectives
What it covers
Applicability, governance committees and roles, CISO independence, policies and controls, vendor and supply chain security, audits and remediation, incident reporting, data protection and the relationship with CERT-In and DPDP requirements.
Who needs it
Life, general and health insurers, foreign reinsurance branches, brokers, corporate agents, web aggregators, TPAs, insurance marketing firms, insurance repositories and related entities, and insurtech and IT vendors that serve them.
Why it matters
The guidelines apply from FY 2026-27 with stronger governance and audit follow-up, and insurers pass their requirements to insurtech, TPA and software vendors through contracts.
Key objectives
Set minimum security standards across the insurance sector
Strengthen board and management oversight of cyber risk
Keep the CISO independent of IT delivery and sales
Fix audit findings within defined timelines
Control risk from vendors and partners
Where it applies
India. Applies to insurers, foreign reinsurance branches, insurance intermediaries and related entities regulated by IRDAI.
ISO/IEC 20000-1: Information technology, Service management, Part 1: Service management system requirements
ISO/IEC 20000-1 is the international standard for service management systems. It sets requirements for planning, delivering, monitoring and improving services, including IT services, through a management system with defined processes for service levels, incidents, problems, changes, releases, capacity, availability, continuity, suppliers and security. Organisations can be certified against it by accredited bodies, which makes it the auditable counterpart to practice guidance such as ITIL for managed service providers.
Covers, who needs it, objectives
What it covers
Service management system context, leadership, planning, support and the clause 8 operational processes: service portfolio, relationships and agreements, supply and demand, design, build and transition, resolution and fulfilment, and service assurance.
Who needs it
Managed service providers, IT outsourcing and support companies, cloud and hosting providers, internal IT departments and shared service centres that want an auditable service management certification.
Why it matters
It is a recognised, certifiable proof of service management capability that tenders and enterprise buyers ask for, and it brings discipline to service levels, changes and incidents.
Key objectives
Deliver services that meet agreed requirements
Control changes and releases
Restore service quickly and remove root causes
Manage capacity, availability and continuity
Improve services continually
Where it applies
Global. Voluntary international standard, certified by accredited certification bodies.
ISO/IEC 23894: Information technology, Artificial intelligence, Guidance on risk management
ISO/IEC 23894 gives guidance on managing risks that arise when organisations develop, provide or use AI. It applies the ISO 31000 risk management principles, framework and process to AI, adds AI-specific objectives such as fairness, transparency, safety, security, privacy and accountability, lists common AI risk sources such as data quality, lack of transparency and level of automation, and maps risk management to each stage of the AI lifecycle. It complements ISO/IEC 42001 and the NIST AI RMF.
Covers, who needs it, objectives
What it covers
AI risk management principles, framework and process, AI-specific objectives and risk sources, the AI lifecycle, risk assessment and treatment for AI systems, documentation and links to ISO/IEC 42001, the NIST AI RMF and the EU AI Act.
Who needs it
AI product teams, data scientists, ML engineers, risk and compliance managers, and organisations implementing ISO/IEC 42001 or preparing for the EU AI Act.
Why it matters
AI introduces risks that ordinary IT risk methods miss, and regulators and certification bodies expect a documented AI risk process.
Key objectives
Integrate AI risk into organisational risk management
Identify AI-specific risk sources
Assess and treat risks across the AI lifecycle
Protect people and the organisation from AI harms
Support trustworthy AI objectives
Where it applies
Global. Voluntary international guidance standard.
ISO/IEC 27001 Information security, cybersecurity and privacy protection: Information security management systems: Requirements
ISO/IEC 27001 is the international standard for an information security management system (ISMS): a managed, risk-based way of protecting the confidentiality, integrity and availability of information. It sets requirements in clauses 4 to 10 and a reference list of 93 controls in Annex A. It is voluntary, and an accredited certification body can audit and certify an organisation against it, which is why customers and tenders ask suppliers for it.
Covers, who needs it, objectives
What it covers
How an organisation sets the scope of its ISMS, assesses and treats information security risks, chooses controls, runs and measures them, audits itself and improves.
Who needs it
Any organisation of any size. In IT it is most often requested from software companies, SaaS and cloud providers, IT service and outsourcing firms, data centres and managed service providers.
Why it matters
It is the most widely recognised proof that a supplier manages information security in a structured, audited way, and it answers a large share of customer security questionnaires.
Key objectives
Identify information security risks in a defined scope
Treat risks with controls chosen against Annex A
Assign leadership responsibility and measurable objectives
Audit, review and continually improve the system
Where it applies
Global. Used in every region; no country makes it a general legal requirement.
ISO/IEC 27002 Information security, cybersecurity and privacy protection: Information security controls
ISO/IEC 27002 is the international reference set of information security controls with implementation guidance. Its 2022 edition reorganised the controls into 93 controls across four themes (organisational, people, physical and technological), added 11 new controls such as threat intelligence, secure coding and data masking, and introduced attributes for filtering controls by type, property and capability. It is not certifiable, but it is the guidance behind the Annex A controls of ISO/IEC 27001.
Covers, who needs it, objectives
What it covers
Purpose and implementation guidance for 93 security controls, from policies and supplier security to access control, cryptography, logging, secure development and data protection.
Who needs it
Security teams, auditors and engineers in any organisation implementing an ISMS or choosing security controls, especially those preparing for ISO/IEC 27001 certification.
Why it matters
It explains how to implement each ISO/IEC 27001 Annex A control in practice, which is what auditors expect to see reflected in your controls.
Key objectives
Provide a reference set of security controls
Give guidance on implementing each control
Let organisations filter and map controls by attributes
Where it applies
Global. Voluntary guidance used with ISO/IEC 27001 and on its own as a control reference.
ISO/IEC 27005: Information security, cybersecurity and privacy protection, Guidance on managing information security risks
ISO/IEC 27005 is the international guidance standard for information security risk management. It explains how to set risk criteria, identify risks using asset-based or event-based approaches, analyse likelihood and consequences, evaluate and treat risks, and keep the process running. The 2022 edition aligns with ISO/IEC 27001:2022 and ISO 31000, and is the usual reference for designing the risk assessment that ISO 27001 certification requires.
Covers, who needs it, objectives
What it covers
Context and risk criteria, risk identification with asset-based and event-based approaches, risk scenarios, analysis and evaluation, treatment options and plans, acceptance, communication, monitoring and review, and documentation.
Who needs it
Security and compliance teams building or running an ISO/IEC 27001 ISMS, risk owners, consultants and auditors, and IT companies that need a defensible security risk method.
Why it matters
Risk assessment is the core of ISO 27001 and of most security frameworks, and auditors expect a consistent, repeatable method.
Key objectives
Define consistent risk criteria
Identify realistic risk scenarios
Prioritise risks by likelihood and consequence
Choose and track treatments
Keep risk information current
Where it applies
Global. Voluntary international guidance standard.
ISO/IEC 27017 Information security controls for cloud services (code of practice based on ISO/IEC 27002)
ISO/IEC 27017 is the international code of practice for information security in cloud computing. It adds cloud-specific guidance to the ISO/IEC 27002 controls for both cloud service providers and cloud service customers, and defines extra controls for issues unique to the cloud, such as shared roles, segregation of virtual environments and removal of customer assets. Its second edition, published in 2026, aligns it with ISO/IEC 27002:2022. It is voluntary and assessed alongside ISO/IEC 27001.
Covers, who needs it, objectives
What it covers
Security responsibilities between cloud providers and customers, virtualisation, tenant isolation, administrator operations, monitoring of cloud services, asset return and removal, and cloud-specific guidance for general security controls.
Who needs it
Cloud service providers (IaaS, PaaS, SaaS), SaaS companies, managed cloud and hosting providers, and organisations buying cloud services that want a structured way to manage cloud security.
Why it matters
It turns the shared responsibility model into concrete controls and gives cloud customers recognised evidence that a provider manages cloud-specific risks.
Key objectives
Clarify security roles between provider and customer
Protect tenants from each other in shared environments
Secure cloud administration and monitoring
Handle customer data properly at the end of a service
Where it applies
Global. Voluntary; commonly assessed together with ISO/IEC 27001 certification for cloud services.
ISO/IEC 27018 Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors
ISO/IEC 27018 is the international code of practice for public cloud providers that process personal data on behalf of their customers. It adds privacy-focused guidance and controls to the ISO/IEC 27002 security controls, covering processing only on customer instructions, no use of personal data for the provider's own purposes without consent, transparency about sub-processors and data locations, breach notification, and return or deletion of data. The 2025 third edition aligns it with the 2022 controls.
Covers, who needs it, objectives
What it covers
Privacy protections for personal data processed by public cloud and SaaS providers as processors: customer instructions, purpose limits, sub-processing, disclosure, data location, breach notice, retention, return and deletion, and security safeguards.
Who needs it
Public cloud providers and SaaS companies that store or process personal data for business customers, including providers serving customers subject to the GDPR, DPDP Act and similar laws.
Why it matters
It gives customers recognised evidence that a cloud processor handles their personal data under privacy-respecting rules, which they need to meet their own legal duties.
Key objectives
Process customer personal data only on instructions
Be transparent about sub-processors and data locations
Notify customers of breaches and legally binding disclosure requests
Return or delete data properly at the end of service
Where it applies
Global. Voluntary; widely used by public cloud and SaaS providers to evidence processor obligations under laws such as the GDPR.
ISO/IEC 27031: Cybersecurity, Information and communication technology readiness for business continuity
ISO/IEC 27031 gives guidance on ICT readiness for business continuity (IRBC): making sure the technology that critical business activities depend on can withstand and recover from disruption. It explains how to link ICT continuity with business continuity and security, identify critical ICT services from the business impact analysis, set ICT recovery time and point objectives, choose strategies for people, facilities, technology, data, processes and suppliers, write ICT continuity plans, and test them. The 2025 edition updated the 2011 original.
Covers, who needs it, objectives
What it covers
Integration of IRBC into business continuity management, risk review, inputs from the business impact analysis, ICT dependencies, recovery capabilities, ICT RTO and RPO, strategy options, ICT continuity and recovery plans, testing, exercises, audit and management responsibilities.
Who needs it
IT operations, infrastructure, cloud and security teams, business continuity managers, SaaS and managed service providers, and organisations implementing ISO 22301 or ISO/IEC 27001.
Why it matters
Most critical business processes depend on ICT, and regulators, customers and auditors expect tested recovery of the systems behind them.
Key objectives
Identify the ICT services critical activities depend on
Set ICT recovery objectives that meet business needs
Choose and implement recovery strategies
Plan, test and improve ICT recovery
Integrate ICT continuity with security and business continuity
Where it applies
Global. Voluntary international guidance standard.
ISO/IEC 27701 Information security, cybersecurity and privacy protection: Privacy information management systems: Requirements and guidance
ISO/IEC 27701 is the international standard for a privacy information management system (PIMS): a managed way to protect personal data and meet privacy obligations as a controller, a processor or both. The 2025 edition made it a standalone, certifiable management system standard with its own clauses 4 to 10, no longer an extension that required ISO/IEC 27001. It includes control sets for controllers and processors and is widely used to structure compliance with laws such as the GDPR.
Covers, who needs it, objectives
What it covers
Governance of personal data processing: privacy roles, privacy risk assessment, controls for PII controllers and processors, data subject rights, sharing and transfer, records, and continual improvement.
Who needs it
Organisations that process personal data, especially SaaS providers, cloud and IT service firms acting as processors for clients, and companies subject to GDPR, DPDP or similar laws.
Why it matters
It turns privacy obligations into an auditable management system and gives customers independent evidence that personal data is handled under control.
Key objectives
Define privacy roles as controller, processor or both
Assess and treat privacy risks
Apply controls for lawful, transparent and secure processing of personal data
Audit and improve the privacy management system
Where it applies
Global. Voluntary everywhere; used to organise compliance with privacy laws such as the GDPR and India's DPDP Act.
ISO/IEC 38500: Information technology, Governance of IT for the organization
ISO/IEC 38500 is the international standard for the governance of information technology. It is written for boards and other governing bodies and explains how they should direct, oversee and be accountable for an organisation's use of IT and data. The 2024 edition aligns IT governance with ISO 37000, the general standard on governance of organisations, adopting its outcomes and principles and applying them to technology, data, environmental and social considerations.
Covers, who needs it, objectives
What it covers
What governance of IT means, the difference between governance and management, governance outcomes and principles, the governance model and framework, responsibilities of boards, and how ISO/IEC 38500 relates to COBIT, ITIL and ISO management system standards.
Who needs it
Boards, directors, executives, CIOs and CTOs, internal auditors, and IT leaders in companies, public bodies and non-profits who need a principled basis for IT oversight.
Why it matters
Technology and data decisions now shape strategy and risk, and boards need a clear, recognised basis for overseeing them rather than leaving IT to management alone.
Key objectives
Make IT governance part of organisational governance
Ensure IT supports purpose and strategy
Hold leaders accountable for IT outcomes
Use data and technology responsibly and ethically
Manage IT risk and value over time
Where it applies
Global. Voluntary international guidance standard for governing bodies.
ISO/IEC 42001 Information technology: Artificial intelligence: Management system
ISO/IEC 42001 is the international standard for an AI management system (AIMS): a structured way for organisations that develop, provide or use AI to set AI policy, assess AI risks and impacts, control the AI life cycle and keep improving. It follows the same clause structure as ISO/IEC 27001, adds AI-specific requirements such as an AI system impact assessment, and lists 38 reference controls in Annex A. It is voluntary and certifiable.
Covers, who needs it, objectives
What it covers
Governance of AI across its life cycle: policy, roles, AI risk assessment and treatment, AI system impact assessment, data, documentation, third parties, responsible use and monitoring.
Who needs it
Organisations that build AI products or features, provide AI services, or use AI in their operations, of any size and sector. Most relevant to AI vendors, SaaS companies with AI features and enterprises adopting AI at scale.
Why it matters
It is the first certifiable AI governance standard, gives customers independent evidence of responsible AI practice, and organises the work that AI laws are starting to require.
Key objectives
Set AI policy and accountability
Assess AI risks and the impact of AI systems on people and society
Control AI development, data and deployment through the life cycle
Monitor, audit and improve the AI management system
Where it applies
Global. Voluntary everywhere; referenced by organisations preparing for AI laws such as the EU AI Act.
ISO 9001 is the international standard for quality management systems, used by more organisations than any other ISO management standard. It requires a process-based system focused on customer requirements, leadership commitment, risk-based planning, controlled operations, measurement and continual improvement. The 2026 edition, published in September 2026, keeps the same structure while strengthening quality culture, ethics and change management. It is voluntary and certifiable, and IT companies often need it for tenders and enterprise contracts.
Covers, who needs it, objectives
What it covers
How an organisation understands customer and stakeholder needs, plans and controls the processes that deliver products and services, manages suppliers, handles nonconformities, measures satisfaction and performance, and improves.
Who needs it
Organisations of any size and sector. In IT, software development firms, IT service providers, SaaS companies and system integrators that bid for public or enterprise contracts.
Why it matters
It shows customers that delivery is controlled and repeatable, and certification is a common qualification requirement in tenders and supply chains.
Key objectives
Meet customer and regulatory requirements consistently
Control processes using the plan, do, check, act cycle
Address risks and opportunities
Measure performance and continually improve
Where it applies
Global. Voluntary everywhere; frequently required in public tenders and supply chains.
ISO 22301 Security and resilience: Business continuity management systems: Requirements
ISO 22301 is the international standard for a business continuity management system (BCMS): a managed way to prepare for, respond to and recover from disruptions. It requires organisations to understand their context, analyse the impact of disruption on their activities, set recovery objectives, choose continuity strategies, write plans, exercise them and keep improving. It is voluntary and certifiable, and IT and SaaS companies use it to prove resilience to customers and regulators.
Covers, who needs it, objectives
What it covers
Business impact analysis, risk assessment, recovery objectives, continuity strategies and solutions, incident response structures, continuity and recovery plans, exercises, evaluation and improvement.
Who needs it
Any organisation that must keep critical activities running through disruption, especially SaaS and cloud providers, IT outsourcers, data centres, fintechs and suppliers to regulated industries.
Why it matters
Customers and regulators increasingly require evidence that services will survive outages, cyber attacks and supplier failures, and certification provides independent proof.
Key objectives
Identify prioritised activities and the impact of disruption
Set recovery time and recovery point objectives
Implement strategies and plans to meet them
Exercise, review and improve continuously
Where it applies
Global. Voluntary; used to evidence continuity duties under laws such as DORA and NIS2 and sector regulations.
ISO 31000 is the international guideline for managing any kind of risk, from strategy and operations to projects, technology and compliance. It defines risk as the effect of uncertainty on objectives and sets out eight principles, a framework for integrating risk management into governance and decision making, and a repeatable process for assessing, treating, monitoring and reporting risk. It is the parent of specialised standards such as ISO/IEC 27005 for information security risk.
Covers, who needs it, objectives
What it covers
Risk management principles, the framework (leadership, integration, design, implementation, evaluation, improvement), the risk management process, risk criteria, assessment techniques, treatment, monitoring, reporting and links to sector standards.
Who needs it
Boards, executives, risk managers, project and product leaders, and IT and software companies that want one consistent way to manage strategic, operational, project and technology risks.
Why it matters
It gives organisations a common risk language and process, which makes security, privacy, delivery and business risks comparable and easier to govern.
Key objectives
Create and protect value
Integrate risk into decisions and governance
Use a consistent process for all risks
Base decisions on the best available information
Improve risk management continually
Where it applies
Global. Voluntary international guidelines applicable to any organisation and any type of risk.
IT disaster recovery planning: how standards and laws expect RTO, RPO, backups and recovery testing
IT disaster recovery planning makes sure the systems and data a business depends on can be restored within agreed times after outages, cyberattacks or disasters. Standards and laws describe it differently but expect the same core elements: a business impact analysis, recovery time and point objectives, protected backups, redundant infrastructure, written recovery procedures, regular tests and improvement. This guide compares what ISO, NIST, SOC 2, HIPAA, DORA, RBI and SEBI expect, and how to build a plan that satisfies them together.
Covers, who needs it, objectives
What it covers
RTO, RPO and MTD, business impact analysis, backup strategy, replication and failover, ransomware recovery, recovery procedures, testing types and frequency, cloud and SaaS considerations, supplier dependencies and what major frameworks and regulators require.
Who needs it
IT and operations teams, SaaS and cloud providers, regulated companies in finance and healthcare, and software vendors whose clients ask for evidence of tested recovery.
Why it matters
Customers, auditors and regulators increasingly ask not whether you have backups but whether you have restored them, how fast, and how recently you tested.
Key objectives
Set recovery targets based on business impact
Protect backups from failures and attackers
Recover systems within agreed times
Prove recovery works through regular tests
Satisfy multiple frameworks with one plan
Where it applies
Global. Synthesis of international standards and sector rules that require disaster recovery.
ITIL (IT service management best practice framework), ITIL 4 and ITIL Version 5
ITIL is the most widely used best practice framework for IT service management. It describes how organisations plan, deliver, support and improve technology-enabled services, through a service value system, guiding principles, four dimensions and 34 management practices such as incident, change, problem and service level management. ITIL 4 was published in 2019 and ITIL Version 5 launched in 2026. It is voluntary and certifies people, not organisations; ISO/IEC 20000-1 is the matching certifiable standard.
Covers, who needs it, objectives
What it covers
IT service management: service strategy and design, service desk, incident, problem, change, release, configuration, service level, availability, continuity, supplier and relationship management, and continual improvement.
Who needs it
IT departments, managed service providers, SaaS operations and support teams, IT outsourcing firms and anyone running technology services for customers.
Why it matters
It gives a common language and proven practices for running reliable services, and many contracts and tenders expect ITIL-aligned processes.
Key objectives
Co-create value with customers through services
Run reliable incident, problem and change practices
Agree and meet service levels
Continually improve services
Where it applies
Global. Voluntary best practice; often required in outsourcing and managed service contracts.
Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021, as amended up to 2026
India's IT Rules 2021 set the due diligence that intermediaries such as social media platforms, marketplaces, hosting providers, app stores and messaging services must follow to keep legal immunity for user content. They require published rules for users, grievance officers, fast removal of unlawful content on orders, data retention and cooperation with authorities. Significant social media intermediaries have extra duties, and 2026 amendments added labelling of AI-generated synthetic content and much shorter takedown deadlines.
Covers, who needs it, objectives
What it covers
Who is an intermediary, safe harbour, due diligence duties, grievance redressal and appeals, significant social media intermediary obligations, synthetically generated information, takedown timelines, the digital media ethics code and enforcement.
Who needs it
Platforms with Indian users: social media, messaging, marketplaces, community and review sites, SaaS with user-generated content, hosting and cloud providers, app stores, generative AI tools, OTT and digital news publishers.
Why it matters
Losing safe harbour exposes a platform to liability for user content, and the 2026 amendments impose hours-long deadlines that need engineering and operations work.
Key objectives
Keep safe harbour through due diligence
Remove unlawful content quickly on valid orders
Give users a working grievance process
Make synthetic media identifiable
Cooperate with lawful requests
Where it applies
India. Applies to intermediaries offering services to users in India, including foreign platforms, and to digital news publishers and online curated content providers.
Lei Geral de Proteção de Dados Pessoais (Brazil's General Personal Data Protection Law, Law No. 13,709/2018)
The LGPD is Brazil's general data protection law, closely modelled on the GDPR. It applies to public and private organisations processing personal data in Brazil or of people in Brazil, requires one of ten legal bases for processing, grants data subjects rights such as access, correction, deletion and portability, requires a data protection officer, security measures and incident reporting to the ANPD within three business days, regulates international transfers and allows fines of up to 2 percent of Brazilian revenue.
Covers, who needs it, objectives
What it covers
Scope and extraterritorial reach, legal bases, sensitive and children's data, data subject rights, controller and processor duties, the encarregado (DPO), security incidents, impact reports, international transfers and sanctions.
Who needs it
Any organisation processing personal data of people in Brazil, including foreign SaaS, e-commerce and app providers with Brazilian users, and IT vendors processing data for Brazilian clients.
Why it matters
Brazil is Latin America's largest digital market, the ANPD actively enforces and issues regulations, and Brazilian clients require LGPD clauses from vendors.
Key objectives
Require a legal basis for all processing
Give data subjects control over their data
Secure data and report incidents
Protect international transfers
Make agents accountable
Where it applies
Brazil. Applies to processing carried out in Brazil, processing aimed at offering goods or services to people in Brazil, and data collected in Brazil, wherever the organisation is based.
MeitY empanelment of cloud service offerings under the MeghRaj (GI Cloud) initiative, with STQC audit
MeitY cloud empanelment is the Government of India's approval of cloud service offerings for use by government and public sector bodies. Under the MeghRaj (GI Cloud) initiative, providers are audited by STQC or empanelled auditors against standards for security, interoperability, data portability, service levels and contract terms, with services hosted in India. Government departments procure from empanelled offerings, and regulators such as SEBI reference empanelment for regulated entities.
Covers, who needs it, objectives
What it covers
The MeghRaj initiative, deployment models, the empanelment and audit process, standards and requirements, data location, procurement, regulator references, and what software vendors must do when hosting government or regulated workloads.
Who needs it
Cloud service providers seeking government business, software companies and system integrators building e-governance solutions, government departments, and regulated entities whose regulators reference empanelled clouds.
Why it matters
Government and many regulated projects can only be hosted on empanelled cloud offerings, so vendors must design and deploy on the right provider, region and model.
Key objectives
Give government a list of vetted cloud services
Keep government data hosted in India
Set baseline security, portability and service levels
Simplify cloud procurement
Where it applies
India. Applies to cloud services procured by central and state government departments and public sector bodies, and is referenced by some regulators.
Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS2)
NIS2 is the EU directive that sets cybersecurity risk-management, incident reporting and governance duties for medium and large organisations in a long list of sectors, including digital infrastructure, managed IT and security service providers, cloud and data centre services, and online platforms. It replaced the 2016 NIS Directive, applies through national laws from October 2024, holds management bodies accountable, requires a 24-hour early warning for significant incidents, and allows fines up to 10 million euros or 2 percent of turnover.
Covers, who needs it, objectives
What it covers
Cybersecurity risk-management measures, governance and management accountability, incident reporting, supply chain security, registration, supervision and enforcement for essential and important entities.
Who needs it
Medium and large organisations in the sectors listed in Annexes I and II, including managed service providers, managed security service providers, cloud, data centre, DNS and content delivery providers, online marketplaces, search engines and social networks, plus their suppliers indirectly.
Why it matters
It is binding law in EU member states, makes executives personally accountable, and pushes security requirements down supply chains to IT vendors anywhere.
Key objectives
Raise the baseline of cybersecurity across critical sectors
Make management bodies responsible for cyber risk
Ensure fast reporting of significant incidents
Secure supply chains and supplier relationships
Where it applies
European Union member states, through national laws transposing the directive. Non-EU providers of certain digital services offering them in the EU must designate a representative.
The NIST AI Risk Management Framework is voluntary US guidance for managing the risks of AI systems throughout their life cycle. It describes the characteristics of trustworthy AI and organises risk management into four functions: Govern, Map, Measure and Manage. A companion Playbook suggests actions, and a Generative AI Profile addresses risks specific to generative models. It is not certifiable, but it is widely used to structure AI governance and is named as a recognised framework in some US laws.
Covers, who needs it, objectives
What it covers
AI risk governance, context and impact mapping, measurement of trustworthiness characteristics, risk treatment and monitoring, and generative AI specific risks such as confabulation, data privacy and information integrity.
Who needs it
Organisations that design, develop, deploy, evaluate or use AI systems, including software companies adding AI features, AI vendors and enterprises buying AI.
Why it matters
It gives a structured, widely recognised way to identify and manage AI risks, supports compliance with AI laws, and answers customer questions about responsible AI.
Key objectives
Build a culture and structure for AI risk management (Govern)
Understand context and potential impacts (Map)
Measure trustworthiness and risk (Measure)
Prioritise and act on risks (Manage)
Where it applies
Published in the United States; voluntary and used worldwide. Referenced by some US state laws and procurement policies.
The NIST Cybersecurity Framework is voluntary guidance for managing cybersecurity risk, organised as six functions: Govern, Identify, Protect, Detect, Respond and Recover. Version 2.0, published in 2024, added the Govern function and widened the audience from critical infrastructure to every organisation. It describes outcomes rather than prescribing controls, and uses profiles and tiers to compare current and target states. It is not certifiable, but it is one of the most widely used ways to structure a security programme.
Covers, who needs it, objectives
What it covers
Cybersecurity outcomes across governance, risk strategy, supply chain risk, asset management, protection, detection, incident response and recovery.
Who needs it
Any organisation of any size or sector. Commonly used by US companies, suppliers to US federal agencies, critical infrastructure operators and IT service providers.
Why it matters
It gives leaders and engineers a shared language for security priorities and maps to ISO/IEC 27001, NIST SP 800-53, CIS Controls and many other frameworks.
Key objectives
Set cybersecurity strategy and accountability (Govern)
Understand assets and risks (Identify)
Safeguard systems and data (Protect)
Find attacks and anomalies (Detect)
Contain and recover from incidents (Respond, Recover)
Where it applies
Published in the United States and used voluntarily by organisations worldwide; referenced in some US federal policy and contracts.
NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management
The NIST Privacy Framework is a voluntary tool for managing privacy risk across an organisation. Modelled on the NIST Cybersecurity Framework, it organises privacy outcomes into Core functions for identifying, governing, controlling, communicating about and protecting data processing, and uses Profiles and Implementation Tiers to set targets and measure maturity. It is law-neutral, so organisations use it to build one privacy program that supports GDPR, US state laws, DPDP and other regimes.
Covers, who needs it, objectives
What it covers
The Core functions and categories, Profiles, Implementation Tiers, privacy risk assessment, problematic data actions, privacy engineering, alignment with the Cybersecurity Framework and AI risk, and the 1.1 update.
Who needs it
Product, engineering, security and legal teams at software companies, SaaS providers and enterprises that need a structured privacy program across several laws.
Why it matters
It gives a common language and structure for privacy work that maps to multiple laws and connects privacy with security and AI risk management.
Key objectives
Identify privacy risks from data processing
Govern privacy with policies and roles
Give individuals and organisations control over data
Communicate clearly about processing
Protect data through safeguards
Where it applies
Global, voluntary. Published by a US federal agency and used by organisations worldwide.
NIST SP 800-37 Revision 2, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
The NIST Risk Management Framework is the US government's process for managing security and privacy risk across a system's life cycle. Defined in SP 800-37 Rev. 2, it has seven steps: Prepare, Categorize, Select, Implement, Assess, Authorize and Monitor. Agencies use it to categorise systems by impact, choose and implement NIST SP 800-53 controls, assess them, decide whether to authorise operation, and monitor continuously. It underpins FedRAMP, FISMA compliance and many contractor requirements.
Covers, who needs it, objectives
What it covers
The seven RMF steps and their main tasks, system categorisation, control selection and tailoring, assessment, authorization decisions, continuous monitoring, roles, supporting NIST publications, and how RMF relates to the Cybersecurity Framework, FedRAMP and CMMC.
Who needs it
US federal agencies, defence and civilian contractors, cloud service providers seeking FedRAMP, and organisations that adopt NIST frameworks for structured risk management.
Why it matters
Selling technology to the US government almost always means supporting an RMF-based authorization, and the method is a rigorous model for any security programme.
Key objectives
Integrate security and privacy into the system life cycle
Select controls proportionate to system impact
Make explicit, accountable risk decisions
Maintain awareness through continuous monitoring
Where it applies
United States federal information systems and organisations; used voluntarily by contractors, cloud providers and others.
NIST Special Publication 800-34 Revision 1, Contingency Planning Guide for Federal Information Systems
NIST SP 800-34 is the US government's guide to contingency planning for information systems. It sets out a seven-step process: policy, business impact analysis, preventive controls, recovery strategies, a system contingency plan, testing and training, and maintenance. It explains how plans such as disaster recovery, continuity of operations and incident response fit together, defines terms like maximum tolerable downtime, RTO and RPO, and provides templates for low, moderate and high impact systems.
Covers, who needs it, objectives
What it covers
The seven-step contingency planning process, business impact analysis, recovery objectives, preventive controls, recovery strategies by impact level, the information system contingency plan and its phases, related plan types, testing, training, exercises, maintenance and templates.
Who needs it
US federal agencies and contractors, FedRAMP cloud providers, IT and security teams anywhere looking for a practical contingency planning method, and SaaS providers documenting recovery.
Why it matters
It is a free, detailed and widely recognised method with templates, and it maps directly to the contingency planning controls auditors test under NIST SP 800-53, FedRAMP and FISMA.
Key objectives
Understand how outages affect missions and business processes
Set recovery priorities and objectives
Choose recovery strategies by system impact
Document clear recovery procedures
Test, train and keep plans current
Where it applies
United States federal information systems; widely used voluntarily by other organisations worldwide.
NIST Special Publication 800-53 Revision 5, Security and Privacy Controls for Information Systems and Organizations
NIST SP 800-53 is the US government's catalogue of security and privacy controls, organised in 20 families from access control to supply chain risk management. Revision 5 made the controls outcome-based and usable by any organisation, and Release 5.2.0 in 2025 added software update and patch integrity controls. Federal systems must select controls from baselines in SP 800-53B, and programs such as FedRAMP use them, so vendors selling to the US government meet this catalogue directly.
Covers, who needs it, objectives
What it covers
Over a thousand controls and control enhancements across 20 families covering technical, operational and management safeguards for security and privacy, plus baselines and assessment procedures.
Who needs it
US federal agencies and their contractors, cloud providers seeking FedRAMP, defence and state government suppliers, and organisations wanting a detailed control catalogue.
Why it matters
It is the control language of US government security, and it is the most detailed public catalogue that other frameworks map to.
Key objectives
Provide a full catalogue of security and privacy controls
Let organisations select and tailor controls by impact level
Support consistent assessment and authorisation of systems
Where it applies
United States. Mandatory for federal information systems under FISMA and OMB policy; used voluntarily by many other organisations.
NIST Special Publication 800-171, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations
NIST SP 800-171 sets security requirements for protecting Controlled Unclassified Information (CUI) in contractor and other nonfederal systems. DoD contractors must implement it under DFARS 252.204-7012 and report a self-assessment score, and the CMMC program verifies it. NIST published Revision 3 in 2024 with 97 requirements in 17 families, but DoD contracts still require Revision 2 with its 110 requirements under a class deviation. Software and IT firms in the defence supply chain must meet it.
Covers, who needs it, objectives
What it covers
Security requirements for systems that process, store or transmit CUI: access control, awareness, audit, configuration, identification and authentication, incident response, maintenance, media, personnel, physical, risk, assessment, system and communications protection, and system integrity, plus planning, acquisition and supply chain in Rev 3.
Who needs it
US defence contractors and subcontractors at every tier, including software developers, IT service providers and cloud users that handle CUI, and contractors of other agencies whose contracts require it.
Why it matters
Without it, contractors cannot properly bid on or keep DoD work involving CUI, and false claims of compliance carry legal risk.
Key objectives
Identify where CUI lives and scope systems
Implement the security requirements
Document a system security plan and plan of action
Report incidents and assessment scores as required
Where it applies
United States. Required through federal contracts, mainly DoD contracts with DFARS clauses, for contractors that handle CUI.
NIST Special Publication 800-218, Secure Software Development Framework (SSDF) Version 1.1
The NIST Secure Software Development Framework is a set of high-level practices for building secure software, organised in four groups: prepare the organisation, protect the software, produce well-secured software, and respond to vulnerabilities. It is technology-neutral and maps to other secure development models. US federal policy used it as the basis for supplier attestations until a January 2026 OMB memo made that agency-specific, but it remains the most common reference for secure development expectations.
Covers, who needs it, objectives
What it covers
Secure development governance, roles and training, protection of code and build environments, secure design, coding, review and testing, secure configuration of releases, and vulnerability response and root cause analysis.
Who needs it
Software producers of all kinds: product companies, SaaS providers, agencies and outsourced development firms, especially those selling to US government or large enterprises.
Why it matters
It gives a recognised, concise description of secure development that customers and governments ask about, and it underpins secure development duties in laws such as the EU Cyber Resilience Act.
Key objectives
Prepare people, processes and tools for secure development
Protect code and builds from tampering
Produce software with minimal vulnerabilities
Find and fix vulnerabilities and prevent recurrence
Where it applies
Published in the United States; voluntary and used worldwide. Some US federal agencies and contracts ask software suppliers to follow or attest to it.
New York City Local Law 144 of 2021 on Automated Employment Decision Tools, with DCWP rules (6 RCNY 5-300 and following)
New York City's Local Law 144 regulates automated employment decision tools: software that uses machine learning, statistics, data analytics or AI to produce scores, classifications or recommendations that substantially assist or replace hiring and promotion decisions. Employers and employment agencies may use such a tool only if it had an independent bias audit within the past year, a summary of results is public, and candidates receive notice. Enforcement began on 5 July 2023, and a December 2025 state audit called for stronger enforcement.
Covers, who needs it, objectives
What it covers
What counts as an AEDT, who must comply, independent bias audits and impact ratios, public summaries, candidate and employee notices, data requests, penalties, enforcement and the 2025 state audit.
Who needs it
Employers and staffing agencies hiring or promoting people for roles in New York City, and the HR tech, ATS and assessment vendors whose tools they use.
Why it matters
It is the most established US law on AI in hiring, enforcement is expected to tighten after a critical 2025 audit, and vendors are asked to support bias audits for their clients.
Key objectives
Expose potential bias in automated hiring tools
Make audit results public
Tell candidates when automated tools are used
Hold employers accountable for their tools
Where it applies
New York City, United States. Applies to employers and employment agencies using automated employment decision tools for candidates and employees in the city.
ISO/IEC 5230:2020 OpenChain Specification for open source license compliance, with ISO/IEC 18974 for open source security assurance
ISO/IEC 5230, the OpenChain Specification, defines the key requirements of a quality open source license compliance program. It does not dictate tools or processes; it requires a policy, trained staff, assigned roles, a process to identify and review open source components, compliance artifacts such as notices and source code, and a contribution policy. Its sister standard, ISO/IEC 18974, covers open source security assurance. Organisations can self-certify, and updated versions are planned for 2026.
Covers, who needs it, objectives
What it covers
Why open source license compliance matters, the requirements of ISO/IEC 5230, conformance options, ISO/IEC 18974 security assurance, SBOM and tooling, typical license obligations, and how software suppliers can build a lightweight program.
Who needs it
Software companies, product makers and service providers that use or distribute open source, especially suppliers to automotive, telecom and electronics companies that require OpenChain conformance.
Why it matters
Almost all software contains open source, license obligations are legally binding, and large customers want proof that suppliers manage them consistently.
Key objectives
Know what open source is in your software
Meet license obligations when distributing software
Assign clear roles and training
Build trust in the software supply chain
Manage known vulnerabilities in open source components
Where it applies
Global. Voluntary international standard used across software supply chains, especially automotive, telecoms and electronics.
OWASP Application Security Verification Standard, version 5.0
The OWASP Application Security Verification Standard is a detailed, testable list of security requirements for web applications and APIs. Version 5.0, released in May 2025, organises around 350 requirements into 17 chapters, from encoding and validation to authentication, authorisation, cryptography, logging and WebRTC, and three levels of assurance. Teams use it to define security requirements, design tests and agree contractual security expectations, going far beyond the awareness-level OWASP Top 10.
Covers, who needs it, objectives
What it covers
Verifiable security requirements for web applications and services across input handling, front-end and API security, files, authentication, sessions, authorisation, tokens, OAuth and OIDC, cryptography, communications, configuration, data protection, secure coding, logging and WebRTC.
Who needs it
Developers, architects, security testers and buyers of web applications and APIs, especially SaaS companies and agencies building customer-facing software.
Why it matters
It turns "the application must be secure" into specific, testable requirements, which makes security work plannable and contracts enforceable.
Key objectives
Give developers a checklist of security requirements
Give testers a consistent verification scope
Let buyers specify a level of assurance in contracts
Where it applies
Global. A community standard with no legal force; used in contracts, procurement and security testing worldwide.
OWASP Software Assurance Maturity Model, version 2
OWASP SAMM is an open framework for assessing and improving how an organisation builds secure software. It defines five business functions (Governance, Design, Implementation, Verification and Operations), each with three security practices, and maturity levels for each practice. Teams score their current state, choose targets that fit their risk, and build a roadmap. It complements requirement standards such as the OWASP ASVS and frameworks such as the NIST SSDF, and it is free to use.
Covers, who needs it, objectives
What it covers
Strategy and metrics, policy, education, threat assessment, security requirements, secure architecture, secure build and deployment, defect management, architecture assessment, requirements-driven and security testing, incident, environment and operational management.
Who needs it
Software companies, SaaS providers, in-house development teams and IT service firms that want to measure and improve secure development across teams.
Why it matters
It gives a structured, measurable way to improve secure development step by step, and a credible way to show customers and leadership where the organisation stands.
Key objectives
Assess current software security practices
Set realistic maturity targets by risk
Build a phased improvement roadmap
Measure progress over time
Where it applies
Global. Voluntary open framework used by software organisations of all sizes.
OWASP Top 10:2025, the ten most critical web application security risks
The OWASP Top 10 is the best-known list of critical web application security risks, published by the OWASP Foundation from data on millions of tested applications and a community survey. The 2025 edition, the eighth, ranks broken access control first and adds two categories: software supply chain failures and mishandling of exceptional conditions. It is an awareness document rather than a standard, but secure coding policies, PCI DSS assessments, penetration tests and customer contracts routinely use it as a baseline.
Covers, who needs it, objectives
What it covers
The ten most critical categories of web application security weaknesses, each mapped to CWEs, with examples and prevention guidance for developers.
Who needs it
Every team that builds or buys web applications and APIs: software companies, SaaS providers, agencies, in-house development teams, testers and security reviewers.
Why it matters
It is the common baseline customers, auditors and penetration testers use to judge application security, and most real-world breaches exploit weaknesses in these categories.
Key objectives
Raise developer awareness of the most critical web risks
Give a shared vocabulary for testing and reporting
Point teams to prevention practices and deeper standards such as ASVS
Where it applies
Global. A community document with no legal force; referenced by standards, contracts and auditors worldwide.
PCI DSS is the security standard for payment card data, published by the PCI Security Standards Council and enforced by the card brands through their contracts with acquiring banks, merchants and service providers. Its 12 requirements cover networks, secure configuration, protection of stored card data, encryption in transit, vulnerability management, secure software, access control, logging, testing and policy. The current version is 4.0.1. Compliance is validated each year by a self-assessment questionnaire or an assessor's report.
Covers, who needs it, objectives
What it covers
Systems, people and processes that store, process or transmit cardholder data or sensitive authentication data, and anything connected to them or able to affect their security.
Who needs it
Merchants of every size that accept cards, payment service providers, hosting and managed service providers in the card data path, and companies building payment software and e-commerce sites.
Why it matters
Acquirers and card brands require it contractually; failure can lead to fines passed on by acquirers, higher fees, liability for fraud losses and loss of the ability to take cards.
Key objectives
Build and maintain secure networks and systems
Protect account data in storage and in transit
Maintain a vulnerability management programme
Implement strong access control
Monitor and test networks regularly
Maintain an information security policy
Where it applies
Global, wherever cards of the participating payment brands are stored, processed or transmitted.
PCI Software Security Framework: PCI Secure Software Standard and PCI Secure Software Lifecycle (Secure SLC) Standard
The PCI Software Security Framework replaced PA-DSS with two standards: the Secure Software Standard, which validates the security of specific software products, and the Secure SLC Standard, which validates a vendor's secure software development lifecycle. Version 2.0 of the Secure Software Standard, effective January 2026, takes a principles-based approach focused on protecting sensitive assets, adds a module for SDKs, requires source code access for assessors, and lets Secure SLC qualified vendors self-approve low-impact updates.
Covers, who needs it, objectives
What it covers
The Software Security Framework, Secure Software Standard v2.0 and v1.x, modules for terminal software, publicly accessible software and SDKs, the Secure SLC Standard, the end of PA-DSS, assessment and listing, update tiers, and how it relates to PCI DSS.
Who needs it
Vendors of payment applications, POS software, payment SDKs, e-commerce payment components, payment terminals software, and software that protects sensitive payment assets, plus merchants and acquirers choosing such software.
Why it matters
Acquirers and customers often require validated payment software, PA-DSS has been retired, and validation demonstrates secure design to the payment ecosystem.
Key objectives
Protect account data and other sensitive assets in software
Build security into software design and development
Manage vulnerabilities and updates
Give the payment ecosystem trusted, validated software
Where it applies
Global. Applies to software vendors that choose to validate payment-related software under the PCI Security Standards Council programme, often at the request of payment brands, acquirers or customers.
Personal Data Protection Act 2012 (Singapore), as amended in 2020
Singapore's Personal Data Protection Act governs how private sector organisations collect, use and disclose personal data. It sets obligations covering consent, purpose limitation, notification, access and correction, accuracy, protection, retention, cross-border transfers, breach notification and accountability, plus Do Not Call rules. Organisations must appoint a data protection officer, notify the PDPC of notifiable breaches within three calendar days, and face penalties of up to 10 percent of Singapore turnover.
Covers, who needs it, objectives
What it covers
The data protection obligations, consent and its exceptions, the data protection officer, access and correction, protection and retention, transfer limitation, data breach notification, data intermediaries, Do Not Call rules and enforcement.
Who needs it
Businesses with customers, users or staff in Singapore, including foreign SaaS and e-commerce providers, and IT vendors processing data as data intermediaries for Singapore clients.
Why it matters
Singapore is a regional hub for Southeast Asia, the PDPC publishes enforcement decisions regularly, and Singapore clients require PDPA terms from vendors.
Key objectives
Obtain consent or rely on clear exceptions
Protect personal data with reasonable security
Notify significant breaches quickly
Keep transferred data at a comparable standard
Be accountable through a DPO and policies
Where it applies
Singapore. Applies to organisations collecting, using or disclosing personal data in Singapore, wherever they are based.
Personal Information Protection and Electronic Documents Act (Canada, S.C. 2000, c. 5)
PIPEDA is Canada's federal private sector privacy law. It requires organisations that collect, use or disclose personal information in commercial activity to follow ten fair information principles, including accountability, meaningful consent, limited collection, safeguards, openness and individual access. Since 2018 it has required reporting of breaches that create a real risk of significant harm. Quebec, Alberta and British Columbia have their own laws, and Bill C-36 proposes to replace PIPEDA's privacy part.
Covers, who needs it, objectives
What it covers
The ten fair information principles, meaningful consent, purposes and limits, safeguards, access and correction, breach reporting and record keeping, transfers for processing, provincial laws and the proposed replacement law.
Who needs it
Businesses with Canadian customers or users, including foreign SaaS and e-commerce companies, and the IT vendors and processors that handle Canadian personal information for them.
Why it matters
It applies to many foreign companies serving Canada, its breach reporting is mandatory, and Canadian clients pass its accountability requirements to vendors.
Key objectives
Make organisations accountable for personal information
Obtain meaningful consent
Limit collection, use and retention
Protect information with safeguards
Give individuals access and recourse
Where it applies
Canada. Applies to private sector organisations collecting, using or disclosing personal information in commercial activity, except where a substantially similar provincial law applies, and to federally regulated employers.
Personal Information Protection Law of the People's Republic of China (2021)
China's Personal Information Protection Law is the country's main privacy law. It applies to processing in China and to foreign organisations that offer products or services to people in China or analyse their behaviour. It requires a legal basis for processing, separate consent for sensitive data and cross-border transfers, impact assessments, security measures and incident notification, and controls transfers abroad through CAC security assessments, standard contracts or certification. Fines reach RMB 50 million or 5 percent of annual revenue.
Covers, who needs it, objectives
What it covers
Scope and extraterritorial reach, legal bases, consent and separate consent, sensitive personal information, individual rights, processor duties, impact assessments, audits, incidents, cross-border transfer routes and thresholds, localisation and penalties.
Who needs it
Companies with users, customers or employees in China, foreign SaaS and e-commerce providers targeting Chinese users, multinationals transferring data out of China, and IT vendors accessing that data.
Why it matters
PIPL transfer rules decide whether and how data can leave China, foreign companies may need a local representative, and penalties can reach 5 percent of revenue.
Key objectives
Process personal information lawfully and minimally
Obtain informed and separate consent where required
Protect sensitive information
Control transfers outside China
Make processors accountable through assessments and audits
Where it applies
People's Republic of China (mainland). Also applies to processing outside China of personal information of people in China, for providing products or services to them or analysing their behaviour.
Reserve Bank of India Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026 (successor to the 2023 Master Direction on IT Governance, Risk, Controls and Assurance Practices)
RBI's technology directions set how banks, NBFCs and other regulated entities govern IT, manage cyber and technology risk, run operations, audit systems and recover from disruption. Issued as entity-wise directions on 31 July 2026, they replace the 2023 IT Governance Master Direction and older cyber security circulars. They require board IT strategy committees, a CISO, IT and security policies, vulnerability testing, disaster recovery drills, IS audits, vendor oversight and cyber incident reporting to RBI within six hours.
Covers, who needs it, objectives
What it covers
Board and committee structures, IT strategy and policies, information and cybersecurity controls, IT operations, change and patch management, vulnerability assessment and penetration testing, BCP and DR, IS audit, IT services outsourcing and third parties, and incident reporting.
Who needs it
Commercial and small finance banks, NBFCs including fintech lenders, credit information companies, all-India financial institutions, and the software, cloud and IT service vendors that support them.
Why it matters
Fintech vendors working with Indian banks and NBFCs are assessed against these directions, and RBI expects regulated entities to pass requirements into vendor contracts.
Key objectives
Align IT with business strategy under board oversight
Manage technology and cyber risk
Keep critical systems resilient and recoverable
Audit information systems independently
Control third-party technology risk
Where it applies
India. Applies to RBI-regulated entities, with separate entity-wise directions for commercial banks, small finance banks, NBFCs, credit information companies, all-India financial institutions and others.
Reserve Bank of India directive on Storage of Payment System Data (circular DPSS.CO.OD No. 2785/06.08.005/2017-18, 6 April 2018) and FAQs of 26 June 2019
RBI's payment data localisation directive requires the entire data relating to payment systems operated in India to be stored only in systems located in India. Processing may happen abroad, but the data must then be deleted overseas and brought back within one business day or 24 hours, whichever is earlier. It applies to card networks, wallets, payment aggregators, banks and their gateways and vendors, and compliance is verified through audits by CERT-In empanelled auditors.
Covers, who needs it, objectives
What it covers
Scope of covered operators and vendors, what counts as payment data, storage only in India, the processing abroad exception and 24-hour rule, cross-border transactions, sharing with foreign regulators, system audits and enforcement.
Who needs it
Card networks, prepaid instrument issuers, payment aggregators and gateways, UPI and other payment apps, banks, and IT, cloud and SaaS vendors that store or process payment data for them.
Why it matters
RBI has restricted major card networks from onboarding new customers for non-compliance, and payment clients require vendors to keep payment data in India.
Key objectives
Keep payment data stored only in India
Give RBI unfettered supervisory access to payment data
Limit how long data stays abroad after processing
Verify compliance through independent audits
Where it applies
India. Applies to payment system operators authorised by RBI and to the banks, gateways, intermediaries and vendors in their payment chains, including foreign card networks.
Personal Data Protection Law of the Kingdom of Saudi Arabia (Royal Decree M/19 of 2021, as amended by Royal Decree M/148 of 2023), with its Implementing Regulations and Transfer Regulations
Saudi Arabia's Personal Data Protection Law governs how organisations collect, use, share and transfer personal data of people in the Kingdom, including foreign companies processing their data. It requires a legal basis for processing, privacy notices, data subject rights, security measures, records of processing, breach notification to SDAIA, impact assessments and controlled cross-border transfers. It has been fully enforceable since September 2024, SDAIA has issued dozens of enforcement decisions, and fines reach SAR 5 million per violation.
Covers, who needs it, objectives
What it covers
Scope, legal bases including consent and legitimate interest, sensitive data, data subject rights, controller obligations, DPOs and registration, breach notification, impact assessments, cross-border transfers, penalties, enforcement and 2026 draft amendments.
Who needs it
Businesses operating in Saudi Arabia, foreign SaaS and e-commerce companies with Saudi users, and IT vendors processing personal data for Saudi clients.
Why it matters
Enforcement is active, transfer rules affect where data can be hosted and accessed, and Saudi clients require PDPL commitments from vendors.
Key objectives
Protect the privacy of individuals in the Kingdom
Require lawful, transparent processing
Give individuals rights over their data
Control transfers outside the Kingdom
Hold controllers accountable
Where it applies
Kingdom of Saudi Arabia, with extraterritorial reach to processing of personal data of people in the Kingdom by entities outside it.
Software Bill of Materials: minimum elements, formats and regulatory expectations
A software bill of materials is a machine-readable inventory of the components in a piece of software, including open-source and third-party libraries, with versions and relationships. It lets producers and customers find out quickly whether a newly disclosed vulnerability affects them. SBOMs are now required for products under the EU Cyber Resilience Act and for FDA cyber device submissions, recommended by CISA and CERT-In, and increasingly requested in enterprise and government contracts.
Covers, who needs it, objectives
What it covers
What an SBOM must contain, standard formats, generation in build pipelines, sharing with customers, vulnerability exploitability exchange (VEX), and regulatory expectations.
Who needs it
Software vendors, SaaS companies, device makers and development firms, and organisations that buy software and need to manage supply chain risk.
Why it matters
SBOMs turn "are we affected by this new vulnerability?" from days of guesswork into a query, and laws and contracts increasingly require them.
Key objectives
Know every component in each release
Respond quickly to new vulnerabilities in dependencies
Share component transparency with customers and regulators
Support licence compliance
Where it applies
Global practice. Required by the EU Cyber Resilience Act for products sold in the EU, by the US FDA for cyber devices, and by many government and enterprise contracts; recommended by CISA and CERT-In.
SEBI Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI Regulated Entities, circular of 20 August 2024 as clarified
SEBI's Cybersecurity and Cyber Resilience Framework sets one cyber standard for stock exchanges, depositories, brokers, mutual funds, portfolio managers, investment advisers and other SEBI-regulated entities. It grades entities into five categories, then sets proportionate requirements for governance, a CISO, security operations, VAPT, cyber audits, a Cyber Capability Index, incident handling, recovery within two hours for critical systems and cloud adoption with data and keys in India.
Covers, who needs it, objectives
What it covers
Applicability and categories, governance and the CISO, identify, protect, detect, respond and recover standards, VAPT and audits, the Cyber Capability Index, SOC and Market SOC, incident classification and forensics, RTO and RPO, cloud and third parties.
Who needs it
Stock exchanges, clearing corporations, depositories, stock brokers, depository participants, asset management companies, portfolio managers, investment advisers, research analysts and other SEBI-registered intermediaries, and the software vendors that serve them.
Why it matters
It applies to the whole securities market, sets hard recovery and audit timelines, and drives the security requirements that brokers and AMCs pass to trading platform and fintech vendors.
Key objectives
Build cyber resilience across the securities market
Apply proportionate controls by entity size and criticality
Detect and respond to incidents quickly
Recover critical operations within two hours
Keep sensitive data and keys under Indian control
Where it applies
India. Applies to entities regulated by the Securities and Exchange Board of India, graded into five categories by size and criticality.
SEC Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure rules (Form 8-K Item 1.05 and Regulation S-K Item 106)
The SEC's cybersecurity disclosure rules require US public companies to disclose material cybersecurity incidents on Form 8-K Item 1.05 within four business days of determining materiality, and to describe their cybersecurity risk management, strategy and governance annually in Form 10-K under Regulation S-K Item 106. The rules, in force since December 2023, raise expectations on incident response, board oversight and third-party risk. Industry groups have asked the SEC to rescind the incident rule, but it remained in force as of October 2026.
Covers, who needs it, objectives
What it covers
Who is covered, Form 8-K Item 1.05, materiality determinations, the national security delay, Item 106 risk management and governance disclosures, foreign private issuers, the role of third-party incidents, SEC guidance and enforcement, and the 2025 to 2026 review.
Who needs it
US-listed companies and their boards, CISOs, legal and finance teams, and the SaaS, cloud and IT service providers whose incidents could affect listed customers.
Why it matters
Disclosure deadlines are short, inaccurate statements create legal risk, and listed customers now expect vendors to report incidents quickly and support materiality assessments.
Key objectives
Give investors timely information on material cyber incidents
Describe how companies manage cyber risk
Show how boards oversee cybersecurity
Make disclosures consistent and comparable
Where it applies
United States public companies that file reports with the SEC, including foreign private issuers through Forms 6-K and 20-F.
Section 508 of the Rehabilitation Act of 1973 and the Revised 508 Standards for information and communication technology (36 CFR Part 1194)
Section 508 requires US federal agencies to make the information and communication technology they develop, buy, maintain or use accessible to people with disabilities. The Revised 508 Standards, in force since January 2018, incorporate WCAG 2.0 Level A and AA for web content, documents and software, and add requirements for hardware, support documentation and services. Vendors selling to agencies are asked for an Accessibility Conformance Report, usually based on the VPAT template, and may face accessibility testing.
Covers, who needs it, objectives
What it covers
Who Section 508 applies to, the Revised 508 Standards and WCAG, functional performance criteria, software, hardware and documentation requirements, Accessibility Conformance Reports and VPATs, testing methods, procurement and complaints.
Who needs it
Software, SaaS, website and app vendors selling to US federal agencies, government contractors, and states, universities and organisations that adopt Section 508 in their own procurement.
Why it matters
Accessibility is evaluated in federal procurement, inaccurate conformance reports create contract risk, and accessible products reach more users.
Key objectives
Give people with disabilities comparable access to federal ICT
Apply a consistent technical standard
Make accessibility part of procurement
Give users a route to complain and seek remedy
Where it applies
United States federal agencies, and through procurement, vendors that sell information and communication technology to them. Many states and universities adopt it too.
Supply-chain Levels for Software Artifacts (SLSA), an OpenSSF specification
SLSA is an open specification for protecting software from tampering between source code and the package users install. It defines tracks with increasing levels: the Build track, from provenance that describes how an artifact was built up to hardened, isolated builds with signed provenance, and the Source track, from version control up to enforced controls and two-party review. Producers generate attestations, and consumers verify them before trusting an artifact.
Covers, who needs it, objectives
What it covers
Supply chain threats SLSA addresses, the Build and Source tracks and their levels, provenance and verification summary attestations, how to adopt SLSA in CI/CD, how consumers verify artifacts, and links to SBOM, SSDF and the Cyber Resilience Act.
Who needs it
Software producers, open source maintainers, platform and DevOps teams, and organisations that consume third-party software and want assurance about its integrity.
Why it matters
Attacks on build systems, dependencies and source repositories can compromise many downstream users, and buyers and regulators increasingly expect proof of how software was built.
Key objectives
Prevent tampering during builds
Record verifiable provenance for artifacts
Protect source code history and review
Let consumers verify artifacts before use
Where it applies
Global. Voluntary open specification used across open source and commercial software.
SOC 1: report on controls at a service organization relevant to user entities' internal control over financial reporting (AICPA SSAE 18, AT-C 320; IAASB ISAE 3402)
A SOC 1 report is an independent auditor's report on a service organisation's controls that are relevant to its customers' financial reporting. Payroll processors, billing and revenue platforms, fund administrators, payment processors and IT providers running finance systems obtain SOC 1 reports so their customers and those customers' auditors can rely on them, especially for SOX. Type 1 covers control design at a date; Type 2 adds operating effectiveness over a period. ISAE 3402 is the international equivalent.
Covers, who needs it, objectives
What it covers
Control objectives and controls at a service organisation that affect the accuracy and completeness of customers' financial data: transaction processing, calculations, interfaces, plus IT general controls over the supporting systems.
Who needs it
Service organisations whose services are part of customers' financial reporting: payroll, billing, revenue recognition, expense, payments, treasury, ERP hosting, data centres and IT outsourcing for finance systems.
Why it matters
Customers' auditors need evidence about outsourced controls; without a SOC 1 report, they must audit you directly or customers may choose another provider.
Key objectives
Describe the service system and control objectives
Show that controls are suitably designed
Show that controls operated effectively over a period (Type 2)
List the controls customers must operate themselves
Where it applies
Used worldwide by service organisations whose clients need assurance for financial audits; SSAE 18 in the US, ISAE 3402 internationally.
System and Organization Controls 2: report on controls at a service organization relevant to security, availability, processing integrity, confidentiality or privacy
SOC 2 is an attestation report in which an independent CPA firm gives an opinion on a service organisation's controls against the AICPA Trust Services Criteria: security, and optionally availability, processing integrity, confidentiality and privacy. A Type I report covers the design of controls at one date; a Type II report also tests whether they operated effectively over a period. It is voluntary, but it is the security evidence US enterprise buyers ask SaaS and IT vendors for most often.
Covers, who needs it, objectives
What it covers
Controls over the system a service organisation uses to deliver its service: governance, risk assessment, access, operations, change management, vendor risk and any additional criteria chosen.
Who needs it
Service organisations that store, process or affect customer data: SaaS providers, cloud and hosting companies, managed IT and security services, data processors, payroll and fintech platforms.
Why it matters
It gives customers and their auditors independent evidence about your controls, replacing much of the security questionnaire work in vendor reviews.
Key objectives
Describe the system and its boundaries accurately
Design controls that meet the selected Trust Services Criteria
Operate those controls consistently through the review period
Disclose exceptions and the controls customers must run themselves
Where it applies
Developed in the United States and requested by customers worldwide, especially US enterprises.
Sarbanes-Oxley Act of 2002: internal control over financial reporting and IT general controls
The Sarbanes-Oxley Act is the US law that requires public companies to maintain and assess internal control over financial reporting, with executives certifying their reports and, for larger companies, auditors attesting to those controls. For IT, SOX means IT general controls over the systems that produce financial data: access, change management, development and operations. It applies to US-listed companies, including foreign ones, and reaches their software and cloud vendors through SOC 1 reports and contract requirements.
Covers, who needs it, objectives
What it covers
Internal control over financial reporting, executive certifications, auditor attestation, IT general controls over financially relevant systems, records retention and penalties for fraud.
Who needs it
Companies listed in the US and their subsidiaries worldwide, and the SaaS, ERP, payroll, billing and IT service providers whose systems support their financial reporting.
Why it matters
Listed customers must prove their financial systems are controlled; vendors who cannot provide evidence such as SOC 1 reports become a problem in the customer's audit.
Key objectives
Ensure financial reports are accurate and reliable
Make executives accountable for disclosures and controls
Control access to and changes in financial systems
Provide auditable evidence of controls operating
Where it applies
Companies with securities registered with the US SEC, including foreign private issuers, and by extension the service providers whose systems support their financial reporting.
Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011 (G.S.R. 313(E))
The SPDI Rules 2011 are India's first rules on personal data protection, made under section 43A of the IT Act. They define sensitive personal data such as passwords, financial information, health records and biometrics, and require body corporates handling it to publish a privacy policy, obtain written consent, limit use and disclosure, control transfers, appoint a grievance officer and implement audited reasonable security practices such as IS/ISO/IEC 27001. They remain in force until the DPDP Act removes section 43A.
Covers, who needs it, objectives
What it covers
Privacy policy, consent and purpose limitation for sensitive personal data, disclosure and transfer conditions, grievance redressal, and reasonable security practices and their audit.
Who needs it
Companies, firms and other body corporates in India that collect or handle sensitive personal data in computer resources, including IT, fintech, health-tech and HR platforms.
Why it matters
Failure to maintain reasonable security practices that leads to wrongful loss or gain can result in compensation claims under section 43A, and the rules shape Indian contracts until the DPDP Act fully applies.
Key objectives
Define sensitive personal data and how it may be collected
Require consent, purpose limitation and grievance handling
Control disclosure and cross-border transfer
Require documented and audited security practices
Where it applies
India. Applies to body corporates handling sensitive personal data or information in computer resources, until section 43A of the IT Act is omitted by the DPDP Act.
SWIFT Customer Security Programme (CSP) and Customer Security Controls Framework (CSCF)
The SWIFT Customer Security Programme requires every bank and institution connected to the SWIFT network to secure its local SWIFT environment against cyber attacks. Its Customer Security Controls Framework sets mandatory and advisory controls under three objectives: secure your environment, know and limit access, and detect and respond. Users attest compliance annually, supported by independent assessment, and counterparties can view attestations. CSCF v2026 made back office data flow security mandatory and extended scope to customer connectors.
Covers, who needs it, objectives
What it covers
Why the CSP exists, the CSCF objectives and principles, mandatory and advisory controls, architecture types, the v2026 changes, attestation and independent assessment, consequences of non-compliance, and what vendors and service providers must do.
Who needs it
Banks, financial institutions and corporates connected to SWIFT, service bureaus, and vendors of middleware, payment hubs, API connectors and back office systems that exchange data with SWIFT infrastructure.
Why it matters
Attestation is required annually, counterparties and regulators can see compliance status, and v2026 widened scope to the connectors and back office flows that software vendors often build.
Key objectives
Secure the local SWIFT environment
Know and limit access
Detect and respond to anomalies and incidents
Build trust across the SWIFT community
Where it applies
Global. Applies to all SWIFT users, and through them to service bureaus, middleware and connector providers.
Trusted Information Security Assessment Exchange (TISAX), based on the VDA Information Security Assessment (VDA ISA) catalogue
TISAX is the automotive industry's shared information security assessment and exchange mechanism. Suppliers, service providers and software vendors that handle sensitive information or prototypes for carmakers are assessed against the VDA ISA catalogue by accredited audit providers, and the results are shared with customers through the ENX platform as TISAX labels. Labels cover information protection, availability, prototype protection and data protection. The new ISA2027 catalogue applies to assessments ordered from 1 January 2027.
Covers, who needs it, objectives
What it covers
The VDA ISA catalogue and its modules, assessment objectives and labels, assessment levels, scope, the assessment process, label validity, the ISA2027 changes, and what software and IT suppliers must do.
Who needs it
Automotive manufacturers and suppliers, engineering service providers, design studios, logistics firms, IT service providers and software companies that process sensitive data or prototype information for the automotive industry.
Why it matters
Carmakers and large suppliers often require a TISAX label before awarding work, and the label avoids repeated customer-specific audits.
Key objectives
Protect confidential information in the automotive supply chain
Protect prototypes and test vehicles
Ensure availability where needed
Protect personal data processed for customers
Share assessment results once with many partners
Where it applies
Automotive supply chain. Originated in Germany and used globally by manufacturers and suppliers of the European automotive industry.
Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data (United Arab Emirates)
The UAE Personal Data Protection Law is the country's federal privacy law, in force since January 2022. It requires consent or another lawful basis for processing, gives individuals rights to access, correct, erase, restrict and port data, and imposes duties on security, breach notification, DPOs and cross-border transfers. It does not apply in the DIFC and ADGM, which have their own GDPR-style laws, or to some sectors with specific rules. Its Executive Regulations, which set details and penalties, had still not been issued as of October 2026.
Covers, who needs it, objectives
What it covers
Scope and exclusions, legal bases, data subject rights, controller and processor duties, breach notification, DPOs, cross-border transfers, the pending Executive Regulations, the UAE Data Office, and the separate DIFC and ADGM regimes.
Who needs it
Companies operating in the UAE mainland and most free zones, foreign companies processing data of people in the UAE, and IT and SaaS vendors serving UAE clients, plus businesses in the DIFC and ADGM under their own laws.
Why it matters
The UAE is a regional hub; clients expect PDPL-aligned practices now, and obligations will become enforceable once the Executive Regulations are published.
Key objectives
Protect individuals' privacy
Require lawful and transparent processing
Give individuals rights over their data
Secure data and report breaches
Control cross-border transfers
Where it applies
United Arab Emirates, outside the DIFC and ADGM financial free zones, which have their own data protection laws. Applies to controllers and processors in the UAE and to those outside processing data of people in the UAE.
UK General Data Protection Regulation and the Data Protection Act 2018, as amended by the Data (Use and Access) Act 2025
The UK GDPR and the Data Protection Act 2018 form the UK's data protection law, kept from the EU GDPR after Brexit and amended by the Data (Use and Access) Act 2025. The core principles, lawful bases, rights and breach reporting match the EU GDPR, but the UK now has recognised legitimate interests, more flexible rules for automated decisions, changes to subject access and complaints, cookie exemptions and its own transfer rules. It applies to UK organisations and to companies abroad that target UK residents.
Covers, who needs it, objectives
What it covers
Processing of personal data by controllers and processors in scope: lawful bases, transparency, rights, security, breach notification, accountability, international transfers, cookies and electronic marketing through PECR.
Who needs it
UK businesses and public bodies, and non-UK companies (including Indian and EU IT firms) offering services to people in the UK or processing UK personal data for clients.
Why it matters
It is mandatory with fines up to 17.5 million pounds or 4 percent of turnover, and UK clients expect suppliers to meet it in contracts.
Key objectives
Process personal data lawfully and transparently
Respect individuals' rights and handle complaints
Keep data secure and report breaches
Protect data transferred out of the UK
Where it applies
United Kingdom, and organisations outside the UK that offer goods or services to, or monitor, people in the UK.
General consumer data privacy laws of US states, including Virginia, Colorado, Connecticut, Texas, Oregon and others
With no general federal privacy law, US states have passed their own consumer privacy laws. Starting with California and Virginia, around 20 states now have such laws in effect, most following a similar model: thresholds based on the number of state residents, rights to access, correct, delete and port data, opt-outs from targeted advertising, sale and profiling, consent for sensitive data, data protection assessments, processor contracts and enforcement by the attorney general.
Covers, who needs it, objectives
What it covers
Applicability thresholds, consumer rights, opt-outs and universal opt-out signals, sensitive data consent, children's and teens' data, privacy notices, data protection assessments, processor obligations and contracts, exemptions and enforcement across states.
Who needs it
Businesses that collect personal data from US residents above state thresholds, including SaaS, e-commerce, apps and ad-supported sites, and the vendors that process data for them.
Why it matters
Laws keep multiplying, enforcement is rising, and US customers expect vendors to support rights requests, opt-out signals and processor terms across all states.
Key objectives
Give consumers control over their personal data
Limit targeted advertising, sale and profiling without opt-out
Require consent for sensitive data
Make controllers assess risky processing
Bind processors by contract
Where it applies
United States, state by state. Each law applies to businesses that meet its thresholds for residents of that state, wherever the business is based.
WCAG is the international technical standard for making web content and applications accessible to people with disabilities. Version 2.2 organises 86 success criteria under four principles (perceivable, operable, understandable, robust) and three conformance levels, with Level AA the usual legal target. WCAG itself is voluntary, but laws in the EU, US, UK and India require conformance to it or to standards based on it, so most public-facing digital products now need to meet it.
Covers, who needs it, objectives
What it covers
Text alternatives, captions, adaptable content, contrast, keyboard access, timing, seizures, navigation, input modalities, readability, predictability, input assistance, authentication and compatibility with assistive technology.
Who needs it
Anyone building websites, web applications, mobile apps and documents for the public or employees, especially e-commerce, banking, government, education and SaaS providers.
Why it matters
It is the benchmark accessibility laws and courts use, inaccessible products exclude users, and procurement teams ask for conformance reports.
Key objectives
Make content perceivable by all users
Make interfaces operable without a mouse and without strict timing
Make content and interactions understandable
Make code robust for assistive technologies
Where it applies
Global. A W3C standard referenced by laws and policies in the EU, US, UK, India and many other countries.
Each entry carries one badge. It tells you how the rule reaches you: by law, through a regulator, through a contract, through a government buying program, or by your own choice. Where a voluntary standard becomes mandatory in some settings, the guide explains where.
Badge
What it means
Examples
Law
Mandatory where it applies
GDPR, HIPAA, DPDP Act, IT Act 2000, EU AI Act, NIS2
Regulator direction
Mandatory for the entities the regulator names
CERT-In Directions, RBI IT Governance Direction, SEBI CSCRF
Contractual standard
Mandatory through contracts
PCI DSS, PCI Secure Software Standard, SWIFT CSP
Government program
Required to sell to that government
FedRAMP, CMMC, MeitY cloud empanelment
Certifiable standard
Voluntary, independently certified
ISO/IEC 27001, ISO/IEC 27701, ISO/IEC 42001, ISO 22301
Attestation report
Voluntary, independently audited
SOC 2, SOC 1, CSA STAR, TISAX
Framework
Voluntary guidance, not certifiable on its own
NIST CSF, CIS Controls, COBIT, ITIL, OWASP Top 10
Where to start
Which compliance does your company need?
A starting point by company profile. Your own list depends on your customers, your data and where you operate, so read the "who needs it" section of each guide before you commit.
If your company
Start with
An Indian IT services or software company with Indian clients
This table is a general starting point, not legal advice. Whether a law applies to you depends on facts such as where your users are, what data you process and your role (for example controller or processor). Confirm with your own counsel or auditor.
Editorial policy
How these guides are researched and kept current
Sources. Every requirement in these guides is taken from the official text: the law as published (EUR-Lex, India Code, the US Code of Federal Regulations), the regulator's own direction or guidance, or the standard's owner (ISO, NIST, the PCI Security Standards Council, the AICPA, OWASP). Each guide lists its official sources at the end. We do not quote statistics we cannot trace to a primary source, and we do not invent examples.
Mandatory or voluntary. Every guide states its type at the top. Where a standard is voluntary in general but required in some settings (for example by a government contract), the guide says where and why.
Review cycle. Each guide shows the date it was last reviewed and its next scheduled review. Rules that are still being written or phased in (AI law, India's DPDP Rules, US federal cloud programs) are reviewed every three months; laws in force every six months; stable standards every twelve months. A new version, an amendment or a major regulator decision triggers an earlier update.
Not legal advice. These guides explain what the rules say and what implementing them involves. They do not tell you whether your organisation is compliant. For that, speak to qualified counsel, your auditor or an accredited certification body.
Who writes them. WorldWin Coder is a software development company. We build the features and controls that audits and privacy laws ask for (access control, audit logging, encryption, consent and data-subject request handling, secure development practices), which is the perspective these guides are written from. We are not a certification body or a law firm.
Compliance-ready software
Building software that has to pass an audit?
We build the parts auditors and privacy laws look for: role-based access, audit logs, encryption, consent records, data export and erasure, and secure development practices. Tell us about your product and get a free quote within one business day.
