⚖️ Governance, Risk & Compliance

GRC Platform
India-First Compliance Tools

Free, interactive GRC tools built around Indian regulatory requirements. ISO 27001, CERT-In Directions, SEBI CSCRF, RBI IT Framework, SOC 2, PCI DSS v4.0, DPDP Act 2023 — all with interactive checklists, risk registers, policy generators, and cross-framework mappers.

Tools

ISO 27001

93 Controls

DPDP 2023

India Privacy

RBI · SEBI

BFSI

100%

Client-Side

⚖️

GRC Hub — India-First Compliance Platform

10 free, interactive compliance tools covering India's mandatory regulatory landscape (CERT-In, RBI, SEBI, DPDP) and international frameworks (ISO 27001, SOC 2, PCI DSS). All processing is client-side — no data leaves your browser.

India Regulations International 100% Client-Side Export CSV / JSON

India — Mandatory Compliance

Checklist🇮🇳

CERT-In Directions 2022

Mandatory for all Indian orgs — 6h incident reporting, 180-day logs, NTP sync, VPN logs.

Checklist🏦

RBI IT Framework

Master Direction compliance for banks & NBFCs — CISO, SOC, VAPT, data localisation.

Checklist📈

SEBI CSCRF 2024

Tier-based SEBI entity checklist — Tier 1–5 filter, governance, SOC, VAPT, DR, audit.

Guide🔏

DPDP Act 2023 Guide

Obligations, consent framework, data principal rights, penalties up to ₹250 Cr.

International Frameworks

Checklist🌐

ISO 27001:2022 Checklist

All 93 Annex A controls — filter by theme, track status, export CSV, progress saved.

Toolkit☁️

SOC 2 Toolkit

Type II gap assessment & evidence guide — all 5 Trust Service Criteria with evidence checklist.

Reference💳

PCI DSS v4.0 Reference

SAQ selector, all 12 requirements, key v4 changes, customised approach guidance.

Strategy & Architecture

Interactive⚔️

Threat Modeling — STRIDE

DREAD scoring & MITRE ATT&CK mapping — categorise threats and prioritise mitigations.

Reference🔒

Zero Trust Reference

NIST 800-207, 5 pillars, maturity model — assess and roadmap your Zero Trust posture.

Mapper🗺️

Cross-Framework Mapper

ISO 27001, CERT-In, RBI, DPDP, SEBI — shared controls across all frameworks.

🇮🇳

CERT-In Directions 2022

Mandatory for every organisation operating in India under Section 70B(6) of the IT Act. Failure to comply: penalties up to ₹1 lakh per day and imprisonment up to 1 year. Came into force 28 June 2022.

Mandatory · All India Since Jun 2022 ₹1L/day Penalty 20 Incident Types

🔴 Legal Status: Issued under Section 70B(6) IT Act 2000. Applies to ALL body corporates, government entities, intermediaries, and data centres operating in India. No minimum size threshold.

What are the CERT-In Directions 2022?

The CERT-In Directions were issued on 28 April 2022 and came into force on 28 June 2022. They significantly expand India's cybersecurity incident reporting requirements, mandate extensive log retention, and impose new obligations on data centres, VPN providers, and virtual asset service providers.

Item	Detail
Legal basis	Section 70B(6) of the Information Technology Act, 2000
Issued by	Indian Computer Emergency Response Team (CERT-In)
Effective date	28 June 2022
Applicability	All body corporates, government organisations, intermediaries, data centres — no size threshold
Incident reporting window	6 hours from detection/cognisance (not occurrence)
Log retention period	Minimum 180 days, within Indian jurisdiction
Penalty — non-compliance	Up to ₹1 lakh per day + imprisonment up to 1 year (Section 70B(7))

Key Changes Introduced

6-Hour Reporting (New)

No prior strict timeline. 2022 Directions mandate 6 hours from detection for 20 specified incident types. Tighter than most global frameworks.

180-Day Log Retention (New)

No prior explicit log retention mandate. Now mandatory: all ICT logs retained 180 days minimum within India. Cloud logs must be in Indian regions.

VPN Provider Obligations (New)

First-time explicit regulation of VPN providers in India. Must maintain 5-year subscriber records — triggered mass exit of international VPN providers from India in 2022.

NTP Synchronisation (New)

Mandatory sync to government NTP servers (NIC/NPLI/NPL). Critical for log correlation and legal evidentiary value of timestamps in investigations.

Virtual Asset Coverage (New)

Crypto exchanges, NFT platforms, virtual asset service providers explicitly included. KYC records + transaction logs for 5 years mandatory.

Data Centre Obligations (New)

Co-location data centres must maintain subscriber names, IPs allocated, contact details, and ownership/management information. Cannot anonymise or purge this data.

Detailed Requirements by Category

Incident Reporting — 6 Hours

Report 20 specified cybersecurity incident types to CERT-In within 6 hours of detection or cognisance. Report via: incident@cert-in.org.in or online portal. Initial report must include: type of incident, systems/data affected, time of detection, initial assessment. Follow-up with full details as investigation progresses.

CriticalAll Organisations

LOG

180-Day Log Retention in India

All ICT system logs must be retained for minimum 180 days within Indian jurisdiction. Covers: network device logs, server/application logs, security device logs, access logs, DNS query logs. Cloud-hosted logs must be in India-based regions only. Must be provided to CERT-In on demand.

MandatoryAll Organisations

NTP

NTP Time Synchronisation

All ICT infrastructure must synchronise to NIC (time.nic.in), NPLI, or NPL (time.nplindia.org) NTP servers. Time accuracy is critical for incident correlation and legal log evidence. Document NTP configuration — CERT-In may request proof of compliance.

MandatoryAll ICT Infrastructure

POC

Designated Point of Contact

Every organisation must designate a named Point of Contact (POC) for CERT-In. POC details (name, role, phone, email) must be registered with CERT-In. POC must be reachable 24×7 for incident coordination. Updates to POC must be reported to CERT-In promptly.

MandatoryAll Organisations

VPN

VPN Provider — 5-Year Subscriber Records

VPN service providers operating in India must maintain for 5 years: validated names and addresses of subscribers, contact details, email/IP addresses assigned, subscription/payment details, usage patterns, and purpose of using the service. Records must be provided to CERT-In on demand.

MandatoryVPN Providers Only

20 Incident Types Requiring 6-Hour Reporting

⚠ Reporting must be within 6 hours of detection or cognisance — not the time of the incident. Late reporting is itself a violation.

#	Incident Type	Examples	Priority
1	Targeted scanning/probing of critical networks	Recon against BFSI, power, telecom	Critical
2	Compromise of critical systems/information	Admin account takeover, DB exfiltration	Critical
3	Unauthorised access to IT systems/data	Intrusion, insider access	Critical
4	Website defacement or intrusion	Homepage replaced, web shell uploaded	High
5	Malicious code (virus, worm, ransomware, wiper)	Ransomware encryption, wiper deployment	Critical
6	Attack on servers (email, DNS, network)	DNS poisoning, email server compromise	Critical
7	Identity theft, spoofing, phishing	BEC, credential phishing campaigns	High
8	Denial of Service / Distributed DoS	DDoS on banking portal, govt website	High
9	Attacks on critical infrastructure	SCADA/ICS attacks, power grid disruption	Critical
10	IoT device attacks	CCTV botnets, smart meter compromise	High
11	Data breaches / data leaks	PII database on dark web, insider leaks	Critical
12	Attacks on digital payment systems	UPI fraud, payment gateway breach	Critical
13	Attacks through malicious mobile apps	Banking trojan apps, fake govt apps	High
14	Fake mobile apps	Impersonation of banks, e-commerce	High
15	Attacks on digital signature certificate systems	CA compromise, certificate forgery	Critical
16	Targeted attacks on cloud computing systems	Cloud API key theft, misconfigured S3 exfil	Critical
17	Attacks on Big Data, Blockchain, virtual assets	Crypto exchange hack, smart contract exploit	Critical
18	Attacks on Robotics systems	Industrial robot compromise, automation attack	Medium
19	Attacks on Artificial Intelligence systems	Model poisoning, adversarial ML attacks	Medium
20	Supply chain attacks	Software supply chain compromise (SolarWinds-style)	Critical

CERT-In Incident Response Workflow

🔍

Detect

Detect incident. Start 6h clock from moment of knowledge.

→

📋

Classify

Check if in 20 specified categories

→

🔒

Contain

Isolate affected systems. Preserve evidence.

→

📢

Report CERT-In

Within 6h. incident@cert-in.org.in

→

🔬

Investigate

Forensics. Preserve 180-day logs.

→

📄

Follow-up

Detailed report + RCA to CERT-In

Reporting Requirements & Contacts

Mandatory Fields — Initial 6h Report

Organisation name · Detection date/time · Incident type (from 20 categories) · Systems affected · Data type affected · Initial impact · Actions taken so far

CERT-In Contact Details

Email: incident@cert-in.org.in
Portal: www.cert-in.org.in
Phone: +91-11-24368572

Online: cert-in.org.in/incidents.jsp

What NOT to Do

Do not delay reporting to investigate first. Do not wipe systems before evidence collection. Do not pay ransom without notifying CERT-In.

⚠ Delay in reporting is a separate violation

Parallel Sector Reporting

Banks: also report to RBI within 6h. SEBI entities: report to SEBI. IRDAI entities: report to IRDAI. Use single IR runbook covering all parallel obligations.

✓ Automate multi-regulator notifications

Sector-Specific Applicability & Parallel Obligations

Sector	CERT-In Obligation	Parallel Obligation	Action
Banks & NBFCs	All standard obligations + 6h reporting	RBI: 6h reporting to RBI DPSS; Board cyber incident report	Dual Reporting — single IR runbook for both
Stock Brokers / AMCs	Standard + cloud provider logs if cloud-hosted	SEBI: significant incidents to SEBI; annual cyber audit	Dual Reporting — SEBI SLA varies by tier
Insurance Companies	All standard obligations	IRDAI: cyber incident reporting within prescribed time	Update IR policy for IRDAI reporting
Data Centres / Co-location	5-year subscriber records + standard logs	Provide logs to CERT-In on demand within 6 hours	New Obligation — subscriber registry system needed
VPN / Proxy Providers	5-year subscriber logs mandatory	Provide subscriber data on CERT-In request	High Impact — assess business model
Crypto / Virtual Asset (VASP)	KYC + transaction records 5 years	FIU-IND registration + PMLA compliance	Dual Framework — CERT-In + FIU-IND
IT / SaaS Companies	Standard; customer data breach triggers reporting	Contractual obligation to notify customers if serving regulated sectors	Update customer contracts with CERT-In notification obligations

CERT-In Compliance Tracker

Section	Requirement	Type	Status

🏦

RBI IT Framework — Master Direction 2021

Applicable to all Scheduled Commercial Banks, Urban Co-operative Banks, NBFCs (Middle Layer+), and Payment System Operators. Covers IT governance, cybersecurity, data localisation, vendor risk, SOC, VAPT, and incident reporting.

BFSI Mandatory 9 Sections Licence Risk 6h Incident SLA

ℹ️ Scope: Applies to all Scheduled Commercial Banks (SCBs), Urban Co-operative Banks (UCBs), Small Finance Banks, Payment Banks, NBFCs (Middle Layer and Upper Layer), and Payment System Operators (PSOs). Non-compliance risks RBI supervisory action and licence implications.

RBI IT Framework — At a Glance

Item	Detail
Legal basis	RBI Master Direction on IT Framework for Banks 2016 (updated 2021 + DCRSS 2019)
Issued by	Reserve Bank of India (RBI)
Applicability	SCBs, UCBs, SFBs, Payment Banks, NBFCs (Middle+Upper Layer), PSOs
CISO mandate	Full-time, dedicated CISO — NOT dual-charge with CTO/CIO. Board-level reporting.
SOC requirement	24×7 SOC for Tier-I banks; defined monitoring capability for others
VAPT frequency	Annual VAPT by CERT-In empanelled auditor; red team for Tier-I (2-yearly)
Data localisation	Payment data exclusively in India. Core banking primary + DR both in India.
Incident reporting	Significant cyber incidents: 6 hours to RBI DPSS; Board notification 24h; RCA 30d
DR/BCP	DCRSS Tier classification; RPO/RTO defined; annual DR drill mandatory

Key Obligations Summary

GOV

IT Governance Structure

IT Strategy Committee at Board level with independent directors. IT Steering Committee at senior management level. CISO — full-time, dedicated, reporting directly to Board — NOT under CTO/CIO. Quarterly cybersecurity status report to Board including threat landscape, incidents, VAPT findings, security programme roadmap.

CriticalAll REs

SOC

Security Operations Centre

24×7 SOC mandatory for Tier-I banks. SIEM with defined use cases and automated alerting. Incident response playbooks for all defined incident categories. Threat intelligence integration. SOC can be in-house or managed service — but bank retains responsibility.

MandatoryTier-I: 24×7

Data Localisation

All payment system data stored ONLY in India — no foreign mirroring even for DR. Core Banking Solution (CBS) data: both primary and DR sites must be within India. Annual System Audit Report (SAR) submitted to RBI DPSS confirming data localisation compliance.

CriticalMandatory

Vendor Risk Management

Third-party IS risk assessment before onboarding critical vendors. Contractual security clauses mandatory: right to audit, incident notification SLA, data protection obligations. Documented exit strategy for critical cloud and technology vendors. Concentration risk management — no over-dependence on single CSP.

MandatoryAll Vendors

IT Governance Framework

Board IT Strategy Committee

Must be established at Board level. Responsible for IT strategy alignment with business strategy. Must include independent directors. Reviews and approves IT strategy, policy, and major IT investments.

✓ Meeting frequency: minimum quarterly

CISO — Independence Requirement

The CISO must be a full-time dedicated role — not dual-charge. Critical: CISO must NOT report to CTO or CIO. Must have independent reporting line directly to Board/Audit Committee. Any dual-reporting to CTO is a compliance violation.

⚠ CISO reporting to CTO = non-compliant

Quarterly Board Reporting

CISO must present quarterly cybersecurity status to Board covering: threat landscape summary, significant incidents, VAPT findings and remediation status, security programme roadmap, upcoming regulatory changes.

IS Policy Framework

Board-approved Information Security Policy reviewed annually. Sub-policies required: Access Control, Password, BYOD, Remote Access, Incident Response, Vendor Management, Data Classification, Acceptable Use.

Annual Security Training

Mandatory security awareness training for all employees including contractual staff. Role-based training for IT/security staff. Board-level cyber awareness sessions. Training completion tracked and reported.

✓ Track completion — RBI may audit training records

Privileged Access Management

PAM solution mandatory for all system administrators. No shared administrator accounts. Time-limited, approved, recorded privileged sessions. All privileged activity logged and reviewed regularly.

Recommended: CyberArk, BeyondTrust, Delinea

SOC, SIEM & Monitoring Requirements

Requirement	Tier-I Banks	Tier-II/III Banks	NBFCs / PSOs
SOC Coverage	24×7 Mandatory	Defined capability	Risk-based
SOC Model	In-house or MSSP (bank retains accountability)	Shared SOC or MSSP acceptable	MSSP acceptable
SIEM Deployment	Mandatory with defined use cases	Mandatory	Recommended
Threat Intelligence	Mandatory — integrate feeds	Recommended	Optional
IR Playbooks	Mandatory for all defined categories	Mandatory — key categories	Mandatory — basic
UEBA/Analytics	Strongly recommended	Optional	Optional

Mandatory SIEM Use Cases

Authentication Monitoring

Multiple failed login attempts. Successful login after failures. Login outside business hours. Login from unusual geographies or unknown IPs.

Privileged Access

Any privileged account (admin, root, DBA) login. Privileged commands executed. Privilege escalation attempts. Access to sensitive data stores by privileged accounts.

Data Exfiltration Indicators

Large volume file downloads. Access to core banking/customer data in bulk. Data transfer to external storage or cloud. Unusual network traffic to external destinations.

System Changes

Firewall rule changes. New service/account creation. Changes to critical configuration files. Software installation on banking systems.

VAPT Requirements

Auditor Qualification

VAPT must be conducted by CERT-In empanelled information security auditors only. Current list: www.cert-in.org.in/empanelled-auditors. Empanelment verified before engagement.

List: cert-in.org.in/s2cMainServlet?pageid=EMPANELLEDAUDIT

Scope of VAPT

Network infrastructure — external and internal. All internet-facing applications (mobile, web, APIs). Core banking application. Payment systems and gateways. Cloud infrastructure (if applicable).

Frequency

Annual VAPT mandatory for all REs. Critical-severity findings remediated within 30 days. High-severity within 60 days. Red Team exercise for Tier-I banks — minimum once every 2 years.

⚠ Board must be informed of critical findings

Reporting

VAPT report must be submitted to Board. Critical and high findings tracked to closure. RBI may request VAPT reports during inspection. Remediation evidence required.

VAPT Remediation SLAs

Severity	Remediation Deadline	Board Notification	Verification
Critical	30 days from report	Mandatory	Retesting required
High	60 days from report	Recommended	Retesting required
Medium	90 days from report	Optional	Evidence review
Low	Next release / planned cycle	Not required	Evidence review

Data Localisation Requirements

🔴 Critical: Data localisation for payment data is one of the most strictly enforced RBI requirements. Violations have resulted in operational restrictions for major payment companies (Mastercard, Diners, Amex).

Payment System Data

ALL end-to-end transaction data, intermediary data, and customer payment data must be stored exclusively in India. No exceptions — no foreign mirroring, no backup abroad.

⚠ RBI Circular: DPSS.CO.OD No.2785 (April 2018)

Core Banking Data

CBS, General Ledger, customer master, account data — primary AND DR sites both in India. DR cannot be in a foreign country. India-to-India DR only.

⚠ Both primary and DR must be Indian data centres

International Transactions Exception

For international transactions: data can be processed abroad but foreign copy must be deleted within 24 hours. A bring-back copy must be stored in India. Does NOT apply to domestic transactions.

✓ Automate 24h deletion via lifecycle policies

Annual SAR Submission

Annual System Audit Report (SAR) must be submitted to RBI DPSS confirming data localisation compliance. Conducted by CERT-In empanelled auditor. Non-submission triggers supervisory action.

Approved Cloud Regions for RBI-Regulated Data

Cloud Provider	Approved India Regions	NOT Permitted
AWS	ap-south-1 (Mumbai), ap-south-2 (Hyderabad)	Any region outside India — even for DR
Microsoft Azure	Central India (Pune), South India (Chennai)	West India (Mumbai) acceptable only if paired with another India region
Google Cloud	asia-south1 (Mumbai), asia-south2 (Delhi)	Singapore, US, EU — all non-India regions

Incident Response & Reporting Requirements

🔍

Detect

Detect cyber incident. Start SLA clocks simultaneously.

→

🔒

Contain

Isolate affected systems. Preserve evidence.

→

📢

Report RBI

Significant incidents: 6h to RBI DPSS

→

📢

Report CERT-In

Specified types: 6h to CERT-In

→

👔

Board Notify

Critical incidents: Board within 24h

→

📄

RCA 30d

Root cause analysis to RBI within 30 days

What Triggers RBI Reporting?

Significant cyber incidents: ransomware, data breach, unauthorised access to CBS, payment system compromise, DDoS affecting customer-facing services. The threshold is "significant" — interpret broadly.

RBI Reporting Portal

Report to RBI DPSS via: cms.rbi.org.in or by email to the designated RBI supervisory contact for your institution.

RBI CMS: https://cms.rbi.org.in

Parallel Reporting Obligations

RBI (6h) + CERT-In (6h) + Board (24h) + RCA (30d). Use a single IR runbook that covers all four SLAs simultaneously. Automate initial notifications where possible.

⚠ Missing any one SLA is a separate violation

Evidence Preservation

Do NOT wipe or restore systems before forensic evidence collection. Preserve memory, logs, network captures. Retain all evidence for minimum 5 years for BFSI incidents involving customer data.

RBI IT Framework Compliance Tracker

Section	Requirement	Type	Status

📈

SEBI CSCRF 2024

Cyber Security and Cyber Resilience Framework — August 2024. Applies to all SEBI Regulated Entities (REs). Risk-based Tier 1–5 categorisation determines obligation depth. Replaces the 2015/2018 SEBI cybersecurity circular.

Capital Markets Tier 1–5 Aug 2024 Replaces 2018 Circular

ℹ️ Scope: All SEBI Regulated Entities (REs) — stock brokers, AMCs, portfolio managers, investment advisers, research analysts, depositories, clearing corporations, market infrastructure institutions. Tier is assigned by SEBI based on entity size, type, and systemic importance.

SEBI CSCRF 2024 — Overview

Item	Detail
Full name	Cyber Security and Cyber Resilience Framework (CSCRF) 2024
Issued by	Securities and Exchange Board of India (SEBI)
Circular reference	SEBI/HO/ITD-PoC-1/P/CIR/2024/050 dated 20 August 2024
Effective date	1 January 2025 (Tier 1–3); phased for Tier 4–5
Replaces	SEBI Cybersecurity Circular 2018, SEBI IT System Audit Guidelines 2019
Risk-based approach	5-tier classification — Tier 1 (highest) to Tier 5 (lowest) based on entity size/criticality
Key additions vs 2018	Cloud security guidelines, vendor risk framework, SoC requirements, VAPT frequency by tier, data protection (DPDP alignment)

SEBI CSCRF vs 2018 Circular — Key Changes

Area	2018 Circular	CSCRF 2024
Tier structure	Binary (Market Infrastructure vs others)	5-tier risk-based classification
Cloud security	Not specifically addressed	Dedicated cloud security framework — India-first data storage
SOC requirement	Only for Market Infrastructure Institutions	SOC required for Tier 1–3 (shared SOC acceptable for Tier 3)
VAPT frequency	Annual for all	Quarterly (Tier 1), Half-yearly (Tier 2), Annual (Tier 3–4)
Data localisation	Not mandated	Investor KYC/trading data stored in India; cloud vendors in India
Vendor risk	Basic contractual requirements	Comprehensive vendor risk framework; exit strategy mandatory

5-Tier Entity Classification

Tier	Entity Type	VAPT Frequency	SOC Requirement	Compliance Date
Tier 1	Market Infrastructure Institutions — NSE, BSE, NSDL, CDSL, CCIL, MCX	Quarterly	24×7 In-house SOC	1 Jan 2025
Tier 2	Large stockbrokers (>50K active clients), AMCs (AUM >₹10,000 Cr), Large Portfolio Managers, Depositories	Half-yearly	12×5 SOC or MSSP	1 Jan 2025
Tier 3	Mid-size brokers (1K–50K clients), Mid AMCs, Custodians, Clearing Members	Annual	Shared/Virtual SOC	1 Jan 2025
Tier 4	Small brokers (<1K clients), Small RIAs, Small Investment Advisers, Research Analysts	Annual	Not Required	1 Apr 2025
Tier 5	Micro entities — very small RIAs, research analysts, sub-brokers	As needed	Not Required	1 Jul 2025

⚠ Tier Assignment: SEBI assigns tiers based on data submitted during SEBI RE categorisation process. If you believe your tier assignment is incorrect, request review through the SEBI online portal. Tier impacts all key obligations — get it right.

Key Domain Requirements

GOV

Governance & CISO

CISO must report independently to Board — not to CTO/CIO. IS policy approved by Board, reviewed annually. IT Steering Committee meets quarterly. Annual cybersecurity status report to Board.

MandatoryTier 1–4

SOC

Security Operations Centre

Tier 1: 24×7 in-house SOC with threat intelligence integration. Tier 2: 12×5 SOC or MSSP. Tier 3: Shared/virtual SOC acceptable. SIEM with defined use cases mandatory for Tier 1–2. Incident response playbooks tested annually.

CriticalTier 1–3

DATA

Data Security & Localisation

All investor KYC, trading data, order books, and portfolio data stored in India. Cloud vendors must be SEBI-approved and sign data localisation agreement. BYOK encryption for investor data. DLP controls mandatory for Tier 1–2.

MandatoryAll Tiers

IDEN

Identity & Access Management

MFA mandatory for all privileged and remote access. PAM for system administrators. Quarterly access reviews for all privileged accounts. No shared admin credentials. Service accounts use minimum required permissions.

MandatoryTier 1–3

VND

Vendor & Cloud Risk

Cloud vendors must be registered/approved by SEBI for use with investor data. Contractual data localisation agreement with CSPs. Exit strategy documented and tested annually. RTO/RPO defined and tested. No single CSP dependency for critical systems.

MandatoryTier 1–3

Audit, Reporting & Incident Notification

Annual IS Audit

Annual information security audit by CERT-In empanelled auditor. Covers: governance, access control, network security, incident response, data security, SOC effectiveness, VAPT findings. Audit report submitted to SEBI.

Cybersecurity Compliance Report

Annual cybersecurity compliance report submitted to SEBI by 31 March each year. Covers compliance status against all CSCRF requirements. Signed by CISO and MD/CEO.

Due: 31 March annually via SEBI portal

Incident Notification to SEBI

Significant cyber incidents (Tier 1–3) must be reported to SEBI within prescribed timeframe. Initial notification within 6 hours, detailed report within 24 hours, RCA within 30 days. Format specified by SEBI.

⚠ Parallel CERT-In reporting also required

Board Reporting

Annual cybersecurity status report to Board of Directors. Includes: threat landscape, incidents, VAPT findings, compliance status, SOC performance metrics, upcoming regulatory changes.

SEBI Entity Types & Specific Obligations

Entity Type	Typical Tier	Key Specific Obligation
Stock Exchanges (NSE, BSE, MCX)	Tier 1	24×7 SOC, quarterly VAPT, 99.999% uptime for trading systems, disaster recovery in India, real-time threat intelligence
Depositories (NSDL, CDSL)	Tier 1	Demat account security, KYC data in India, HSM for digital signatures, anti-phishing protection for demat portal
Clearing Corporations (CCIL)	Tier 1	Settlement system security, real-time monitoring, systemic risk management, dual-site operational capability
Large Stockbrokers	Tier 2	Client data encryption, trading system security, DDoS protection for trading portals, 2FA for all client login
Asset Management Companies (AMCs)	Tier 2/3	Fund NAV data security, investor KYC in India, online transaction portal security, anti-phishing for investor communications
Portfolio Managers / RIAs	Tier 3/4	Client data encryption, secure communication with clients, access control to client portfolios
Research Analysts	Tier 4/5	Basic IS policy, email security, secure storage of unpublished research, access control for research system

SEBI CSCRF 2024 Compliance Tracker

Your Entity Tier

Domain	Requirement	Min Tier	Status

🔏

Digital Personal Data Protection Act 2023

Complete compliance reference — definitions, obligations, data principal rights, consent requirements, breach notification, cross-border transfers, penalties, and implementation checklist.

All India · Extraterritorial ₹250 Cr Penalty Rules Pending 2025 44 Sections · 7 Chapters

⚠ Status: The DPDP Act received Presidential assent on 11 August 2023. Rules are being finalised by MeitY. The Act establishes the framework; rules will specify timelines, formats, and procedural requirements. Organisations should begin compliance preparation now.

What is the DPDP Act 2023?

The Digital Personal Data Protection Act 2023 is India's first comprehensive data protection law. It governs the processing of digital personal data of individuals (Data Principals) by organisations (Data Fiduciaries). The Act replaces the earlier IT Act provisions on data protection and brings India's framework closer to global standards like GDPR.

Item	Detail
Full name	The Digital Personal Data Protection Act, 2023
Short title	DPDP Act 2023
Presidential assent	11 August 2023
Gazette notification	12 August 2023
Rules status	DPDP Rules being finalised by MeitY (2024–2025)
Regulatory authority	Data Protection Board of India (DPBI) — to be established by Central Government
Chapters	7 Chapters, 44 Sections
Scope	Processing of digital personal data of Data Principals in India; also processing outside India if it involves offering goods/services in India
Exclusions	Personal data processed for personal/domestic purposes; publicly made available by the Data Principal
Replaces	Section 43A and related IT Act provisions on sensitive personal data

Key Structural Changes from Previous Law

Aspect	Pre-DPDP (IT Act / SPDI Rules 2011)	DPDP Act 2023
Scope	Only SPDI (sensitive personal data), paper data excluded	All digital personal data, regardless of sensitivity category
Lawful basis	Consent only (with limited exceptions)	Consent + Legitimate Uses (specified in Section 7)
Children's data	No specific provisions	Verifiable parental consent mandatory; no tracking/behavioural monitoring of children
Data localisation	RBI/SEBI sector mandates only	Act itself does not mandate — but cross-border rules apply
Regulator	No dedicated regulator	Data Protection Board of India (adjudicatory body)
Penalties	₹5 crore max under IT Act	Up to ₹250 crore per violation
Data processor liability	Not directly regulated	Processors have direct obligations under the Act
Individual rights	Limited — only access and correction	7 rights including erasure, grievance, and nomination

Key Definitions (Section 2)

Personal Data

Any data about an identifiable individual. Includes names, phone numbers, email IDs, biometrics, financial data, health data, location, and any combination that can identify a person. Does NOT include anonymised data.

Digital Personal Data

Personal data in digital form — or personal data that was originally collected in non-digital form and subsequently digitised. Paper records not in scope unless digitised.

Data Principal

The individual to whom the personal data relates. In the case of a child (under 18), the parent or guardian exercises the Data Principal's rights. For persons with disabilities — their lawful guardian.

Data Fiduciary

Any person (individual, company, government body) who alone or jointly with others determines the purpose and means of processing personal data. Primary obligation-bearer under the Act. Comparable to "Data Controller" under GDPR.

Data Processor

Any person who processes personal data on behalf of a Data Fiduciary. Subject to direct obligations under the Act — including security safeguards and breach notification to the Data Fiduciary.

Consent Manager

A registered entity that acts as a single point of contact to enable a Data Principal to give, manage, review, and withdraw consent through an interoperable platform. Must be registered with DPBI. New intermediary type — no equivalent in IT Act.

Significant Data Fiduciary (SDF)

A Data Fiduciary designated as such by the Central Government based on: volume of data processed, sensitivity, risk to Data Principals, national security implications, and market influence. SDFs face heightened obligations including mandatory DPO, DPIA, and independent auditor.

Processing

Any operation on personal data — wholly or partly automated. Includes collection, recording, storage, sharing, use, disclosure, combination, erasure, and destruction. "Automated" is broadly interpreted.

Data Protection Board (DPBI)

Adjudicatory body to be established by Central Government. Powers: investigate breaches, impose penalties, hear complaints from Data Principals. Members appointed by Central Government — independence debated.

Child

A person below the age of 18 years. Higher threshold than COPPA (13) or GDPR (16). Verifiable parental consent required for processing any data of a child. Age verification mechanism to be specified in Rules.

Legitimate Use

Section 7 provides lawful grounds beyond consent: employment processing, state/public functions, medical emergencies, disasters, debt recovery, legal functions of courts and tribunals. Limited and specific — not a general "legitimate interests" like GDPR.

Grievance

A complaint raised by a Data Principal regarding non-compliance with DPDP Act obligations by a Data Fiduciary. Data Fiduciary must designate a Grievance Officer and establish a grievance redressal mechanism.

Data Fiduciary Obligations (Sections 8–12)

§8

General Obligations

Process personal data only for lawful, specified, and non-excessive purposes. Ensure accuracy and completeness. Erase data when the purpose is fulfilled or upon withdrawal of consent. Implement reasonable security safeguards.

MandatoryAll Data Fiduciaries

§8(7)

Data Erasure on Purpose Fulfilment

Personal data must be erased once: (a) the specified purpose is fulfilled, or (b) the Data Principal withdraws consent, or (c) the Data Principal exercises the right to erasure — whichever is earliest. Retention policies must align with this obligation.

MandatoryHigh Priority

§9

Processing of Children's Data

Before processing data of a child (under 18): obtain verifiable consent of parent/guardian. Must not process data that is likely to cause detrimental effect on well-being. Absolutely prohibited: tracking, behavioural monitoring, and targeted advertising directed at children.

CriticalAll Fiduciaries (with child users)

§10

Significant Data Fiduciary Obligations

If designated as SDF by Central Government: (1) Appoint Data Protection Officer based in India — answers to Board of Directors, (2) Appoint independent data auditor, (3) Conduct periodic Data Protection Impact Assessments (DPIA), (4) Comply with additional standards specified.

MandatorySDF Only

§11

Data Processor Obligations

Data Processors process data on behalf of the Data Fiduciary under a valid contract. Processors must: implement security safeguards, notify the Data Fiduciary of any personal data breach, not engage sub-processors without authorisation, and process only as instructed.

MandatoryData Processors

§12

Grievance Redressal

Data Fiduciary must establish a grievance redressal mechanism. Designate a Grievance Officer (name and contact details accessible to Data Principals). Grievances must be addressed within a prescribed timeframe (to be specified in Rules). Data Principal can escalate to DPBI if not resolved.

MandatoryAll Data Fiduciaries

Consent Framework (Sections 6–7)

Valid Consent Requirements (§6)

Must be: Free (no coercion), Specific (for defined purpose), Informed (after reading notice), Unconditional (no bundling), Unambiguous (clear affirmative action).

✓ Granular — separate consent per purpose

Notice Before Consent

Data Fiduciary must provide a notice in clear, plain language (English + 22 scheduled languages). Notice must specify: personal data collected, purpose, how to exercise rights, and how to file complaints.

⚠ Existing data: notice required at earliest if consent was not obtained under this Act

Consent Withdrawal (§6(4))

Data Principal may withdraw consent at any time, as easily as it was given. Consequences of withdrawal may be communicated, but withdrawal itself cannot be penalised. Fiduciary must cease processing within prescribed time.

⚠ Implement a one-click "Withdraw Consent" option wherever consent was taken

Consent Managers (§6(9))

Licensed intermediaries to help Data Principals manage consent across multiple platforms. DPBI will maintain register. Interoperability between Consent Managers required. First of its kind globally.

✓ Data Principals can delegate consent management to licensed CM

Legitimate Uses (Section 7) — Alternatives to Consent

Legitimate Use	Section	Scope
Voluntary provision	7(a)	Data Principal voluntarily provides data for an evident purpose — no explicit consent needed
State/public function	7(b)	Central/State Government processing for subsidies, benefits, licences, certifications, services
Medical emergency	7(c)	Protecting life or preventing health epidemics in emergency situations
Employment	7(d)	Processing employee data for employment purposes — safeguarding employer from loss/liability
Court/legal function	7(e)	Processing for functions of courts, tribunals, or other government bodies exercising judicial power

⚠ Important: Legitimate Uses under §7 are narrower than GDPR's "legitimate interests" — there is NO general legitimate interests ground. Each use case must squarely fall within one of the specified bases. When in doubt, obtain consent.

Data Principal Rights (Sections 11–14)

Right to Access Information (§12)

Right to obtain from Data Fiduciary a summary of personal data being processed, a list of other Data Fiduciaries and processors to whom it has been disclosed, and any other prescribed information. Fiduciary must confirm receipt within prescribed time.

Right to Correction and Erasure (§13)

Right to correct inaccurate or misleading personal data. Right to complete incomplete data. Right to update personal data. Right to erase personal data no longer needed for the purpose for which it was given. Data Fiduciary must act within prescribed timeframe.

Right to Grievance Redressal (§13(3))

Right to readily available means for grievance redressal. If Fiduciary does not respond within prescribed time or response is unsatisfactory, Data Principal may complain to the Data Protection Board of India (DPBI).

Right to Nominate (§14)

Data Principal may nominate another individual to exercise their rights in the event of death or incapacity. Unique right not present in GDPR — addresses India's guardianship context. Nomination procedure to be specified in Rules.

Data Principal Duties (Section 15)

Unlike GDPR, the DPDP Act imposes duties on Data Principals. Violations can attract penalties.

Duty to Comply

Must not register false grievances or complaints. Must not impersonate another person.

Accurate Information

Must not provide false information when identifying oneself or exercising rights.

Penalty for Violations

False complaint or false information: up to ₹10,000 per instance.

⚠ Unusual globally — most laws don't impose DP duties

Personal Data Breach Notification (Section 8(6))

What is a Personal Data Breach?

Any unauthorised processing, accidental disclosure, acquisition, sharing, use, alteration, destruction, or loss of access to personal data in a manner that compromises confidentiality, integrity, or availability.

Who Must Notify?

Data Fiduciary must notify DPBI and each affected Data Principal. Data Processor must notify the Data Fiduciary (not directly to DPBI). Fiduciary then determines whether to escalate.

Timeline

Notification must be made "without delay" — Rules will specify exact timeline. Expected: 72 hours to DPBI (aligned with CERT-In 6-hour mandate for regulated sectors).

⚠ Start the clock from time of discovery/knowledge

Notification Content

Rules will prescribe format. Expected: nature of breach, categories of data affected, approximate number affected, likely consequences, measures taken, Grievance Officer contact.

Breach Response Workflow

🔍

Detect Breach

Identify scope, data affected, number of principals

→

🔒

Contain

Isolate affected systems, prevent further loss

→

📋

Assess

Determine if DPDP breach threshold met

→

📢

Notify DPBI

Within prescribed timeline (expected 72h)

→

👤

Notify Principals

Inform affected Data Principals

→

🛠️

Remediate

Fix root cause, submit RCA

Note on CERT-In overlap: For regulated entities in BFSI, healthcare, and critical infrastructure — CERT-In Directions 2022 require incident reporting within 6 hours. The DPDP Act notification obligation will overlay (not replace) CERT-In requirements. Maintain a combined incident response runbook.

Cross-Border Transfer of Personal Data (Section 16)

Transfer Mechanism

Personal data may be transferred outside India only to countries or territories notified by the Central Government. A positive whitelist model — transfer permitted by default except to blacklisted countries.

⚠ Whitelist not yet published — no transfers blocked currently

Current Position

Until the whitelist is notified, cross-border transfers are not yet restricted by the Act itself. Organisations should prepare by mapping all cross-border data flows and data processors in foreign countries now.

✓ Action now: complete data flow mapping

Sector-Specific Restrictions

Certain sectors (RBI payment data, SEBI investor data, health data) already have sector-specific data localisation requirements independent of DPDP Act. These continue to apply.

⚠ DPDP Act adds a layer — does not replace sector rules

Government Exemption

Transfers to foreign governments/entities may be restricted or exempted by Central Government in the interest of national security, sovereignty, or public order — regardless of whitelist.

🗺️ Cross-Border Transfer Risk Assessor

Enter details about a cross-border data transfer to assess DPDP Act compliance risk and required actions.

Destination Country

Data Category

Transfer Purpose

Penalties (Schedule 1 — Section 33)

Violation	Section	Maximum Penalty
Personal data breach due to non-compliance with security safeguards	§8(5)	₹250 Crore
Breach of obligation to notify Data Principals of a personal data breach	§8(6)	₹200 Crore
Breach of obligations relating to children's data processing	§9	₹200 Crore
Non-compliance with additional obligations of Significant Data Fiduciary	§10	₹150 Crore
Breach of Data Principal rights obligations (access, correction, erasure)	§11–13	₹10,000 per instance
Failure to establish grievance redressal mechanism	§12	₹10,000 per instance
Any other provision of the Act or Rules	Schedule 1(6)	₹50 Crore
Data Principal providing false grievances / impersonating	§15	₹10,000

Penalty Process

DPBI investigates complaints/breaches, gives opportunity to be heard, can impose penalties. Right of appeal to High Court. Penalties are per violation — not per record/individual (unlike GDPR's % of global turnover).

Factors in Penalty Assessment

Nature, gravity, duration of violation. Type of personal data affected. Number of Data Principals. Repetitive nature. Whether Fiduciary gained benefit. Steps taken to mitigate harm.

Voluntary Undertaking

DPBI may accept a Voluntary Undertaking from a Data Fiduciary — committing to compliance — as an alternative to formal proceedings. Closes investigation if undertaking is fulfilled.

✓ Proactive compliance reduces penalty exposure

vs GDPR Penalties

GDPR: up to 4% of global annual turnover or €20M. DPDP: fixed maximum caps. For large MNCs, DPDP penalties may be lower than GDPR. For Indian SMEs, ₹250 Cr is existential.

DPDP Compliance Checklist — Interactive

All Immediate Actions Short-term (3–6 months) SDF Only

Area	Action Item	Priority	Status

Sector Applicability & Interaction with Existing Regulations

Sector	Existing Regulation	DPDP Interaction	Action Required
Banking / NBFC	RBI Master Direction on IT, PPI regulations	DPDP overlays on RBI. Payment data localisation (RBI 2018) continues independently. Consent for credit bureau sharing now governed by DPDP.	Review DPA with all cloud vendors; update privacy notice; map cross-border transfers
Capital Markets	SEBI CSCRF 2024, SEBI KYC regulations	Investor KYC data now subject to DPDP consent obligations. Existing SEBI data localisation mandate continues. DPDP adds rights (erasure, access) on top.	Update KYC consent flows; implement Data Principal rights portal; update DPAs
Insurance	IRDAI cybersecurity guidelines, IRDAI data protection circular	Health and life insurance data — DPDP applies. Parental consent required for policies covering children. Cross-border transfer of health data under dual scrutiny.	Review health data processing; implement consent manager; check cross-border flows
Healthcare	NMC regulations, Digital Health Mission	Health data is sensitive — highest protection. DPDP doesn't create a separate category but health data breach carries ₹250 Cr max. ABHA/DigiLocker health data subject to DPDP.	Critical Implement verifiable consent; data minimisation; patient rights portal
Telecom	TRAI regulations, Telecom Cybersecurity Rules 2024	Location data, call records — DPDP applies. Telecom Cybersecurity Rules 2024 add parallel incident reporting obligations. SIM-based verification for age gating likely.	Align incident response procedures with both DPDP + TRAI rules
E-Commerce / Tech	Consumer Protection (E-Commerce) Rules 2020	DPDP is primary law for data processing. Consent required before collecting cookies, tracking, personalisation. Children's data restriction impacts EdTech and gaming platforms heavily.	High impact Cookie consent, age verification, right to erasure implementation
Government / PSU	IT Act, various sectoral regulations	Government processing for public functions falls under Legitimate Use (§7) — consent not required. However, government entities must still maintain security safeguards and respect breach notification obligations.	Moderate Implement security safeguards; designate Grievance Officer; breach notification plan
HR / Staffing	Labour laws, EPFO regulations	Employee data processing covered under Legitimate Use (§7(d)). But employee rights (access, correction) still apply. Consent required for non-employment processing of employee data.	Update Employment contracts; HRMS privacy notices; exit data deletion procedures

🌐

ISO 27001:2022 — Information Security Management

The international standard for Information Security Management Systems (ISMS). 2022 revision: 93 Annex A controls across 4 themes. 11 new controls covering cloud, threat intelligence, ICT supply chain, and secure coding.

93 Controls 4 Themes 11 New in 2022 ISO/IEC 27001:2022

ISO 27001:2022 — At a Glance

ISO 27001 is the world's most widely adopted information security standard. It provides a framework for establishing, implementing, maintaining, and continually improving an ISMS. The 2022 revision reduced controls from 114 to 93 and reorganised into 4 themes (previously 14 domains).

Item	Detail
Standard reference	ISO/IEC 27001:2022
Published by	International Organization for Standardization (ISO) + IEC
Published date	October 2022 (replaces ISO 27001:2013)
Transition deadline	31 October 2025 (all certificates must be to 2022 version)
Controls	93 Annex A controls across 4 themes (down from 114 in 2013)
New controls	11 new controls added in 2022
Core requirement	Establish, implement, maintain, and continually improve an ISMS
Companion standards	ISO 27002 (implementation guidance), ISO 27005 (risk management), ISO 27701 (privacy)

2013 vs 2022 — Key Structural Changes

Aspect	ISO 27001:2013	ISO 27001:2022
Annex A structure	14 domains, 114 controls	4 themes, 93 controls (consolidated + 11 new)
Cloud security	No specific cloud controls	5.23 — IS for cloud services (new)
Threat intelligence	Not addressed	5.7 — Threat intelligence (new)
ICT supply chain	Basic supplier relations only	5.21 — ICT supply chain security (new)
Data masking	Not a control	8.11 — Data masking (new)
DLP	Not explicitly addressed	8.12 — Data leakage prevention (new)
Secure coding	Part of development guidelines	8.28 — Secure coding (explicit new control)

4 Themes — Control Distribution

Organisational (37 controls)

Policies, roles, responsibilities, threat intelligence, IS in project management, supplier relationships, ICT supply chain, cloud services, incident management, BCP, legal compliance, IS reviews. Largest theme — governance backbone of the ISMS.

People (8 controls)

Screening, employment terms, IS awareness, training, disciplinary process, post-termination responsibilities, confidentiality agreements, remote working. Smallest theme — but highest breach impact (insider threats).

Physical (14 controls)

Physical perimeters, entry controls, securing offices, physical security monitoring (NEW), environmental threats, secure areas, clear desk/screen, equipment siting, media disposal, utility protection, cabling security.

Technological (34 controls)

Endpoint devices, privileged access, access restriction, source code access, authentication, capacity management, malware protection, vulnerability management, configuration management, deletion, data masking (NEW), DLP (NEW), backup, redundancy, logging, monitoring, NTP, privileged utilities, software installation, network security, network services, segregation, web filtering (NEW), cryptography, SDLC, application security, secure architecture, secure coding (NEW), security testing, outsourced development, separation of environments, change management, test information, IS in audit testing.

Controls by Category within Each Theme

Theme	Controls	Top 3 Most Audited
Organisational	5.1 – 5.37	5.15 Access control, 5.19 Supplier IS, 5.24 Incident management
People	6.1 – 6.8	6.1 Screening, 6.3 Awareness & training, 6.5 Post-termination
Physical	7.1 – 7.14	7.1 Physical perimeter, 7.2 Entry controls, 7.10 Storage media
Technological	8.1 – 8.34	8.5 Authentication, 8.8 Vulnerability mgmt, 8.15 Logging

11 New Controls in ISO 27001:2022

✓ If you are transitioning from ISO 27001:2013, these 11 controls are your gap areas. Conduct a focused gap assessment on these controls first.

5.7

Threat Intelligence

Collect, analyse and produce threat intelligence about information security threats to inform risk management decisions. Includes: internal threat data, external feeds (CERT advisories, industry ISACs, commercial feeds), and tactical/strategic/operational intelligence.

OrganisationalNew in 2022

5.23

Information Security for Use of Cloud Services

Specify and manage IS for acquisition, use, management, and exit from cloud services. Includes: cloud service selection criteria, contractual IS requirements, shared responsibility model documentation, data classification for cloud, exit/portability planning.

OrganisationalNew in 2022

5.30

ICT Readiness for Business Continuity

Plan, implement, maintain and test ICT readiness based on BCP objectives and ICT continuity requirements. RPO/RTO for critical ICT systems. DR testing with documented results. Integration with overall BCP.

OrganisationalNew in 2022

7.4

Physical Security Monitoring

Continuously monitor premises for unauthorised physical access. CCTV coverage of sensitive areas. Access control logs reviewed regularly. Visitor management. Physical intrusion detection systems.

PhysicalNew in 2022

8.9

Configuration Management

Establish, document, implement, monitor and review configurations for hardware, software, services, and networks. Secure baseline configurations. Configuration change management. Automated configuration scanning and deviation detection.

TechnologicalNew in 2022

8.10

Information Deletion

Delete information stored in IT systems, devices, or media when no longer required. Secure deletion procedures. Retention schedules enforced. Data disposal certificates for media. Aligns with DPDP Act erasure obligations.

TechnologicalNew in 2022

8.11

Data Masking

Use data masking in accordance with the organisation's access control policy and business requirements. Pseudonymisation and anonymisation of PII in non-production environments. Mask payment card data (PCI DSS alignment). Obfuscation in logs.

TechnologicalNew in 2022

8.12

Data Leakage Prevention

Apply DLP measures to systems, networks, and other devices that process, store, or transmit sensitive information. DLP policy covering: email, USB, cloud upload, printing. Monitoring, alerting, and blocking capabilities. Incident response for DLP violations.

TechnologicalNew in 2022

8.16

Monitoring Activities

Monitor networks, systems, and applications for anomalous behaviour and potential IS incidents. SIEM/UEBA deployment. Baseline behaviour established. Alert thresholds defined. Continuous monitoring with human review.

TechnologicalNew in 2022

8.23

Web Filtering

Manage access to external websites to reduce exposure to malicious content. URL categorisation and blocking. SSL inspection for encrypted traffic. Exception handling process. User awareness of web filtering policy.

TechnologicalNew in 2022

8.28

Secure Coding

Apply secure coding principles to software development. OWASP Top 10 addressed. Code review requirements. SAST/DAST in CI/CD pipeline. Developer secure coding training. Third-party component scanning (SCA). Dependency vulnerability management.

TechnologicalNew in 2022

ISO 27001:2022 Implementation Roadmap

📋

Scope & Context

Define ISMS scope. Identify internal/external context. Clause 4.

→

⚠️

Risk Assessment

Identify assets, threats, vulnerabilities. Score risks. Clause 6.

→

📄

Risk Treatment

Select Annex A controls. Write Statement of Applicability (SoA).

→

🔧

Implement Controls

Deploy 93 Annex A controls. Document policies and procedures.

→

🔍

Internal Audit

Internal audit of ISMS. Management review. Clause 9.

→

🏆

Certification Audit

Stage 1 (document review) + Stage 2 (on-site). Certificate issued.

Key Documents Required for Certification

Mandatory Documents

ISMS scope (4.3) · IS policy (5.2) · Risk assessment process (6.1.2) · Risk treatment plan (6.1.3) · Statement of Applicability (6.1.3d) · IS objectives (6.2) · Competence evidence (7.2) · Operational planning results (8.1)

Mandatory Records

Risk assessment results · Risk treatment results · Evidence of competence · Monitoring/measurement results · Internal audit programme + results · Management review results · Nonconformity + corrective action

Statement of Applicability

Central document: lists all 93 Annex A controls, states Applicable/Not Applicable for each, provides justification for exclusions, and references implementation evidence. Auditors scrutinise this document carefully.

⚠ Every excluded control must have clear documented justification

Timeline Estimate

Small org (50–200 staff): 6–9 months to certification. Medium (200–1000 staff): 9–18 months. Enterprise (1000+): 18–36 months. Budget: ₹15–50L for certification body + consultants.

ISO 27001:2022 — 93 Annex A Controls Tracker

All (93) Organisational (37) People (8) Physical (14) Technological (34)

Ctrl	Title	Theme	Status

☁️

SOC 2 Toolkit — Type II Gap Assessment

SOC 2 (System and Organisation Controls 2) is required by most US and global enterprise buyers before onboarding SaaS/cloud vendors. Based on AICPA Trust Service Criteria. Type II covers a minimum 6-month observation period with evidence collection.

5 Trust Criteria Type I / Type II AICPA Framework

What is SOC 2?

SOC 2 is an auditing standard developed by the AICPA (American Institute of CPAs) for technology and cloud service providers. A SOC 2 report assesses controls relevant to security, availability, processing integrity, confidentiality, and privacy of a service organisation's systems.

Item	Detail
Standard	AICPA Trust Service Criteria (TSC) — 2017 version (updated)
Report types	Type I (design of controls at a point in time) · Type II (operating effectiveness over ≥6 months)
Who needs it	SaaS companies, cloud providers, IT service providers serving US/global enterprise customers
India context	Indian IT/SaaS companies serving US/EU enterprises increasingly required to hold SOC 2 Type II
Auditor	Must be conducted by a licensed CPA firm — not an ISO auditor or internal team
Scope	Defined by the service organisation — can be system-wide or specific services/products
Report validity	SOC 2 Type II reports typically cover a 12-month period and are renewed annually

SOC 2 vs ISO 27001 vs CERT-In

Aspect	SOC 2	ISO 27001	CERT-In
Origin	USA — AICPA	International — ISO	India — CERT-In/IT Act
Target audience	US/global enterprise buyers of cloud/SaaS	Universal — enterprise, SME, government	All organisations in India
Mandatory?	Not legally mandatory — market-driven	Not legally mandatory — market/contract	Legally mandatory in India
Focus	Service organisation's customer data controls	Organisation's entire ISMS	Incident reporting + log retention
Auditor type	Licensed CPA firm only	ISO accredited certification body	CERT-In empanelled auditor (for VAPT)

5 Trust Service Criteria (TSC)

Security (CC) — Required

The Common Criteria (CC) covers: CC1 Control Environment, CC2 Communication and Information, CC3 Risk Assessment, CC4 Monitoring Activities, CC5 Control Activities, CC6 Logical and Physical Access Controls, CC7 System Operations, CC8 Change Management, CC9 Risk Mitigation. Required for all SOC 2 reports.

Availability (A) — Optional

System availability for operation and use as committed. Covers: performance monitoring, DR planning, incident response for availability events, capacity planning, backup testing, SLA compliance monitoring. Include if customers have uptime SLA requirements.

Processing Integrity (PI) — Optional

Complete, valid, accurate, timely, and authorised processing. Input validation, error handling, output reconciliation. Most relevant for payment processors, healthcare data processors, financial calculation systems. Usually included for fintech SOC 2 reports.

Confidentiality (C) — Optional

Information designated as confidential is protected as committed. Data classification, encryption at rest and transit, NDA agreements with employees/vendors, secure disposal. Include if you process customer confidential data (trade secrets, financial projections, M&A data).

Privacy (P) — Optional

Personal information collected, used, retained, disclosed, and disposed per privacy commitments. Consent management, notice, access and correction rights, data subject requests, cross-border transfer controls. Include if processing personal data for customers — aligns with GDPR/DPDP compliance.

✓ Most Indian SaaS companies start with CC + Availability. Add Confidentiality and Privacy if customer data types require it. PI is typically added for fintech/healthcare processing.

Evidence Requirements for Type II

Domain	Key Evidence Items	Observation Period
Access Control	User access review logs (quarterly), provisioning/de-provisioning tickets (within 24h SLA), MFA enforcement screenshots, PAM session recordings for privileged access	6–12 months
Change Management	Change tickets with documented approval, CAB meeting minutes, code review records, deployment logs with approver, rollback procedures tested and documented	6–12 months
Risk Management	Annual risk assessment report, risk register with treatment status, vendor risk assessments for critical third parties, Board approval of risk appetite statement	Annual
Incident Response	IR procedure document, tabletop exercise completion record, incident tickets closed within SLA, post-mortems for severity 1/2 incidents, escalation path tested	6–12 months
Backup & Recovery	Backup configuration screenshots, monthly restore test results with documented outcomes, DR drill report, RTO/RPO defined and met in tests, immutable backup evidence	Monthly tests
Vulnerability Management	Monthly scan reports with scan scope defined, patch SLA metrics (critical 30d, high 60d), quarterly penetration test report, critical finding remediation evidence	6–12 months
Security Training	LMS completion records (100% employees), phishing simulation results, role-based training completion for security staff, new hire training within 30 days evidence	Annual
Vendor Management	Vendor risk assessment completed for all critical vendors, DPA/contracts signed with security clauses, annual review of critical vendor access	Annual

Type I vs Type II — Key Differences

Aspect	SOC 2 Type I	SOC 2 Type II
What is assessed	Design and implementation of controls at a specific point in time	Operating effectiveness of controls over an observation period (≥6 months)
Observation period	None — single snapshot	Minimum 6 months; typically 12 months for renewal
Market value	Limited — enterprise buyers increasingly require Type II	High — accepted by most enterprise security teams
Evidence required	Policy and procedure documentation, configuration screenshots	Above + operational logs, ticket records, test results, sampling over observation period
Time to complete	2–4 months (from controls implementation)	6–12 months observation + 2–3 months audit
Cost (India)	₹15–25 Lakhs (CPA firm fee)	₹25–60 Lakhs (longer audit engagement)
Recommended for	Early-stage companies starting their compliance journey	Growth-stage companies closing enterprise deals

When to Get Type I First

You have just implemented controls. Customer is asking "are you SOC 2 certified?" and needs something to review now. Use Type I as a bridge while building 6+ months of Type II evidence.

When to Jump to Type II

You have had controls operational for 6+ months. Customer specifically requires Type II. You are closing enterprise deals where procurement teams require Type II reports.

Readiness Assessment

Before engaging a CPA firm: conduct an internal gap assessment using the Evidence Guide tab. Aim for 80%+ controls implemented before starting observation period.

✓ Use the Gap Assessment tab to measure readiness

Indian SaaS Context

US enterprises typically require SOC 2 Type II as a baseline for TPCRM. DPDP Act compliance evidence can be incorporated into SOC 2 Privacy criteria. ISO 27001 + SOC 2 together cover most global enterprise requirements.

SOC 2 Gap Assessment — Click to Toggle

Click each control to mark as implemented (green) or gap (red). This mirrors what auditors look for during a Type II observation period.

💳

PCI DSS v4.0 Reference

Payment Card Industry Data Security Standard v4.0 (March 2022). v3.2.1 retired March 2024. Applies to all merchants, service providers, and payment processors handling cardholder data. 12 requirements across 6 goals.

v4.0 Current 12 Requirements SAQ A to D

PCI DSS v4.0 — At a Glance

Item	Detail
Standard	PCI DSS v4.0 — published March 2022
Governing body	PCI Security Standards Council (PCI SSC) — founded by Visa, Mastercard, Amex, Discover, JCB
Previous version	v3.2.1 — retired 31 March 2024. All assessments must use v4.0.
Who must comply	Any entity that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD)
India context	RBI mandates PCI DSS for payment aggregators, payment gateways, and entities storing/processing card data under PA/PG guidelines 2020
Approach	Defined approach (prescriptive) OR Customised approach (new in v4.0 — achieve objective via alternative controls)
Future-dated requirements	Several v4.0 requirements had a future-date of 31 March 2025 — all now in full effect

6 Goal Areas

Build & Maintain Secure Network

Req 1–2: Network security controls (firewalls, NSGs, cloud SGs). Secure configurations for all system components. No default vendor passwords.

Protect Account Data

Req 3–4: Protect stored cardholder data. Encrypt transmission of CHD across open/public networks. TLS 1.2 minimum.

Manage Vulnerabilities

Req 5–6: Protect against malware — anti-phishing required (new). Develop and maintain secure systems and software.

Strong Access Controls

Req 7–9: Restrict access by business need. MFA for all CDE access (new in v4.0). Identify and authenticate users.

Monitor & Test Networks

Req 10–11: Log and monitor all access. 12-month log retention. Test security of systems regularly. Authenticated internal scans.

IS Policy

Req 12: IS policy addressing security for all personnel. Vendor management. Targeted risk analysis for each requirement.

12 PCI DSS v4.0 Requirements

Req	Title	Key Controls	v4.0 Change
1	Install and maintain network security controls	Firewall rules, NSGs, cloud security groups, WAF, network diagrams	NSC replaces "firewall" — encompasses cloud SGs, virtual firewalls
2	Apply secure configurations to all system components	Hardening standards, default password change, inventory of system components	Customised approach allowed; vendor default passwords — explicit prohibition
3	Protect stored account data	Data retention minimisation, PAN masking, encryption of stored CHD, key management	Disk-level encryption no longer sufficient for PANs — field-level required
4	Protect CHD with strong cryptography in transit	TLS 1.2+ for all transmissions, certificate management, no clear-text PANs	TLS 1.2 minimum; TLS 1.3 strongly recommended
5	Protect all systems against malware	AV/EDR on all applicable systems, phishing detection, malware incident response	NEW Anti-phishing mechanisms required (Req 5.4)
6	Develop and maintain secure systems and software	Vulnerability management, secure SDLC, web application attacks in scope, WAF	Targeted risk analysis mandatory; web app attacks explicitly in scope
7	Restrict access to system components and CHD by business need	Access control model documentation, role-based access, quarterly review	Access control model must be formally documented
8	Identify users and authenticate access	MFA for ALL CDE access, password complexity, service account management	KEY CHANGE MFA required for ALL access into CDE — not just remote
9	Restrict physical access to system components and CHD	Physical access controls, POI device protection, visitor management, media controls	POI device inspection procedure must be documented and executed
10	Log and monitor all access to system components and CHD	Audit logs, log integrity, automated log review, 12-month retention	NEW Automated log review required (10.7); 12-month retention mandatory
11	Test security of systems and networks regularly	Vulnerability scans, penetration testing, change detection (file integrity)	Authenticated internal scans required; pentesting includes service providers
12	Support IS with organisational policies and programs	IS policy, security awareness training, vendor management, risk assessment	Targeted risk analysis for EACH requirement; customised approach documentation

Key Changes in PCI DSS v4.0

MFA

MFA for ALL CDE Access (Req 8.4)

v3.2.1 required MFA only for remote access. v4.0 requires MFA for ALL individuals with access into the Cardholder Data Environment (CDE) — including local/network access. Major operational impact — review all CDE access paths. Hardware tokens, authenticator apps, push notifications all acceptable.

Critical ChangeAll merchants

TRA

Targeted Risk Analysis (TRA) — Every Requirement

New in v4.0: each requirement with a frequency-based control (e.g. "review quarterly") now requires a Targeted Risk Analysis justifying the frequency based on your specific risk profile. Cannot just copy the default frequency — must document your reasoning. Significant additional documentation burden.

New RequirementAll merchants

ENC

Disk Encryption No Longer Sufficient (Req 3.5)

Full-disk encryption (FDE) alone is no longer acceptable for protecting stored PANs. If disk encryption is used, additional access controls at the application or data layer must be in place to prevent access to CHD. Vendors and merchants using FDE only must add field-level encryption or access controls.

Key ChangeStorage in scope

ANTI

Anti-Phishing Mechanisms Required (Req 5.4)

v3.2.1 only required user education on phishing. v4.0 requires technical anti-phishing mechanisms in addition to training. Acceptable controls: email security gateways with anti-phishing, DMARC/DKIM/SPF enforcement, DNS-based threat filtering, browser-based phishing protection.

New ControlAll merchants

CUST

Customised Approach (New Option)

New alternative to the Defined Approach. Organisations can implement alternative controls if they meet the stated security objective. Requires: Controls Matrix (documenting alternative control + objective met), testing procedures developed with QSA, evidence that objective is achieved. Not suitable for all organisations — requires more sophisticated documentation capability.

Optional

LOG

12-Month Log Retention + Automated Review (Req 10.5/10.7)

v4.0 explicitly requires 12 months of audit log retention (3 months immediately accessible). Req 10.7: Automated mechanisms must be used to detect anomalies and failures in log mechanisms. Alerts on: log tampering, unexpected log absence, failed authentication in logs.

New Specifics

SAQ Type Selector Tool

Answer the questions below to identify your correct Self-Assessment Questionnaire (SAQ) type. SAQ type determines the number of requirements you must assess.

How do you accept card payments?

SAQ Types Comparison

SAQ Type	Applicable To	Requirements
SAQ A	Card-not-present merchants who outsource all card processing; redirect to hosted payment page	~22
SAQ A-EP	E-commerce merchants who outsource payment but own the checkout page script	~191
SAQ B	Merchants with imprint machines or standalone dial-out terminals; no electronic CHD storage	~41
SAQ B-IP	Merchants with IP-connected POI terminals — no electronic CHD storage	~83
SAQ C-VT	Merchants using web-based virtual terminals; no electronic CHD storage	~65
SAQ C	Merchants with payment application systems connected to Internet; no electronic CHD storage	~160
SAQ D (Merchant)	All merchants not covered by other SAQ types; merchants storing electronic CHD	~329
SAQ D (SP)	All service providers eligible to complete SAQ	~359

Scoping the Cardholder Data Environment (CDE)

Scoping is the most critical — and often misunderstood — aspect of PCI DSS compliance. Everything in scope must meet all PCI DSS requirements. Reducing scope reduces compliance cost and effort significantly.

System Components In Scope

Any system that stores, processes, or transmits CHD or SAD. Any system in the same network segment as CHD systems. Any system providing security services (firewall, IDS, authentication) to CHD environment.

⚠ Overly broad scope = unnecessary compliance burden

Scope Reduction Strategies

Network segmentation (firewall/VLAN between CDE and non-CDE). Tokenisation (replace PANs with tokens — removes systems from scope). Hosted payment fields (Stripe Elements, Braintree) — script hosted by PSP, not merchant.

✓ Tokenisation is the most effective scope reduction

Connected-To Systems

v4.0 clarifies: systems that connect TO the CDE but don't store/process CHD are "connected-to" systems. They face a limited subset of requirements. Proper network segmentation moves them out of CDE scope entirely.

Cloud Scoping

Cloud infrastructure hosting CDE is in scope. IaaS: your systems + provider's physical/network layer. PaaS: your application + provider's platform controls. Provider's SOC 2 / PCI DSS certification covers their layer — YOU cover the rest.

💡 India-specific: RBI PA/PG Guidelines 2020 mandate PCI DSS for payment aggregators and payment gateways. Non-compliance with RBI guidelines risks payment licence suspension. PA/PG entities must achieve PCI DSS compliance and submit annual certificate of compliance to RBI.

⚔️

Threat Modeling — STRIDE & DREAD

STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) is the industry-standard threat modeling framework. Pair with DREAD scoring for risk prioritisation and MITRE ATT&CK for TTP mapping.

STRIDE Framework DREAD Scoring MITRE ATT&CK Threat Model Builder

STRIDE Threat Categories — Deep Reference

Spoofing — Impersonation

An attacker pretends to be another user, system, or service to gain trust or access. Violates authentication. Examples: stolen credentials used for login, forged JWT tokens, DNS spoofing to redirect traffic, ARP poisoning, BGP hijacking.

Violates: AuthenticationMitigations: MFA, mTLS, FIDO2, certificate pinning, DMARC

Tampering — Data Integrity Violation

Malicious modification of data in storage or transit. Violates integrity. Examples: MITM modifying API request/response, SQL injection modifying database records, log file editing after compromise, supply chain attack modifying software packages.

Violates: IntegrityMitigations: HMAC, digital signatures, input validation, WORM logs, code signing

Repudiation — Denial of Actions

A party denies having performed an action — no audit trail to prove otherwise. Violates non-repudiation. Examples: user denies transaction, attacker deletes activity logs, no digital signature on financial transactions, weak audit logging that is not tamper-proof.

Violates: Non-repudiationMitigations: Tamper-proof audit logs, digital signatures, NTP sync, SIEM, immutable log storage

Information Disclosure — Confidentiality Breach

Exposing data to unauthorised parties. Violates confidentiality. Examples: verbose error messages leaking stack traces/internal paths, unencrypted traffic intercepted, public S3 bucket with PII, insecure direct object reference exposing other users' data, logs containing passwords/tokens.

Violates: ConfidentialityMitigations: Encryption at rest/transit, DLP, proper error handling, access control, data masking

Denial of Service — Availability Attack

Making a system, service, or resource unavailable to legitimate users. Violates availability. Examples: volumetric DDoS, Slowloris HTTP attack, resource exhaustion via large payloads, ransom-DDoS, amplification attacks (DNS, NTP, Memcached).

Violates: AvailabilityMitigations: Rate limiting, WAF, CDN, auto-scaling, DDoS protection (Shield/Armor/CloudFlare)

Elevation of Privilege — Unauthorised Access Expansion

Gaining capabilities beyond what is authorised. Violates authorisation. Examples: iam:PassRole + lambda:CreateFunction → admin (AWS), kernel exploit → root, SUID binary abuse, sudo misconfiguration, JWT secret extraction for arbitrary role claims.

Violates: AuthorisationMitigations: Least privilege, PAM, MFA for privilege, runtime protection, SCPs, RBAC

DREAD Threat Risk Scorer

Score a specific threat using DREAD (Damage + Reproducibility + Exploitability + Affected Users + Discoverability). Total score 10–50: Low/Medium/High/Critical.

Threat Description

STRIDE Category

Damage Potential

Reproducibility

Exploitability

Affected Users

Discoverability

STRIDE → MITRE ATT&CK Mapping (Cloud Focus)

STRIDE Category	MITRE Tactic	Key Techniques	Cloud-Specific Example
Spoofing	Initial Access, Credential Access	T1078 Valid Accounts, T1566 Phishing, T1539 Steal Web Session Cookie	Stolen IAM keys used to assume legitimate role; STS token theft via SSRF
Tampering	Impact, Defense Evasion	T1565 Data Manipulation, T1070 Indicator Removal, T1490 Inhibit System Recovery	S3 object modification; CloudTrail log deletion; cloud config tampering
Repudiation	Defense Evasion	T1070.002 Clear Linux Logs, T1562.001 Disable Security Tools, T1070.001 Clear Windows Logs	CloudTrail StopLogging; GuardDuty disablement; S3 access log deletion
Info Disclosure	Collection, Exfiltration	T1530 Data from Cloud Storage, T1552 Unsecured Credentials, T1213 Data from Info Repositories	Public S3 bucket; IMDS credential theft; Secrets Manager enumeration
Denial of Service	Impact	T1498 Network DoS, T1499 Endpoint DoS, T1489 Service Stop, T1529 System Shutdown	DDoS on cloud load balancer; Lambda function flooding; resource exhaustion attacks
Elevation of Privilege	Privilege Escalation	T1548 Abuse Elevation, T1134 Token Impersonation, T1098 Account Manipulation	iam:PassRole + lambda:CreateFunction; Azure PIM bypass; GCP SA key creation

Threat Model Builder

Document threats for a system component using STRIDE. Add threats one by one to build a threat model table.

Component

STRIDE Category

Threat Description

Mitigation

Risk Level

🔒

Zero Trust Architecture Reference

Based on NIST SP 800-207. Zero Trust rejects implicit trust based on network location. Every access request is authenticated, authorised, and continuously validated. "Never trust, always verify." The operating model for modern cloud and hybrid environments.

NIST 800-207 5 Pillars Maturity Model CISA Framework

What is Zero Trust?

Zero Trust is a security strategy — not a product. It assumes breach: every request, from any source, must be authenticated and authorised before granting access. Traditional perimeter security ("castle and moat") is replaced by granular, dynamic access decisions based on identity, device health, and context.

Core Zero Trust Principles

Verify Explicitly

Always authenticate and authorise based on all available data points — identity, location, device health, service/workload, data classification, and anomalies. Never grant access based on network location alone.

Use Least Privilege Access

Limit user access with just-in-time and just-enough-access (JIT/JEA). Risk-based adaptive policies. Protect data — don't protect the perimeter. Time-limited access; revoke when purpose is completed.

Assume Breach

Minimise blast radius. Segment access. Encrypt all communication end-to-end. Use analytics to get visibility, drive threat detection, and improve defences. Assume attackers are already inside.

Continuous Validation

Authentication is not a one-time event. Continuously evaluate trust signals: user behaviour anomalies, device posture changes, unusual access patterns. Re-authenticate or step-up auth when risk increases.

Micro-segmentation

Replace flat networks with granular segments. Each segment has its own security policy. Lateral movement is blocked — a compromised endpoint cannot reach other systems without explicit authorisation.

Encrypt Everything

All traffic encrypted — external AND internal. mTLS between microservices. No implicit trust for "internal" traffic. East-west traffic treated the same as north-south. Eliminates network eavesdropping as a viable attack.

Zero Trust vs Traditional Perimeter Security

Aspect	Traditional Perimeter	Zero Trust
Trust model	Implicit trust inside network — "inside = trusted"	No implicit trust — every request verified regardless of origin
VPN	VPN grants broad network access	ZTNA grants access to specific application only, not whole network
Perimeter	Hard outer shell, soft interior	No perimeter concept — microsegmentation throughout
Lateral movement	Once inside, attackers move freely	Every east-west connection requires authorisation — blast radius minimised
Authentication	One-time at login — session persists	Continuous, risk-based — re-challenge on anomaly
Device posture	Not considered in access decisions	Device health checked before and during every session

CISA Zero Trust Maturity Model — 5 Pillars

👤

Pillar 1: Identity

Every access attempt requires verified identity. Phishing-resistant MFA (FIDO2) for all privileged accounts. Continuous session risk evaluation — re-authenticate on anomaly. Just-in-time privileged access (PAM). Identity Governance for provisioning/deprovisioning. UEBA for behavioural baseline and anomaly detection.

Key controls: Phishing-resistant MFA · Conditional Access · PAM/JIT · Identity Governance · Risk-based authentication · SSO with strong session management

Highest PriorityStart Here

💻

Pillar 2: Devices

Only compliant, managed devices can access sensitive resources. Device health evaluated before and during every session. Unmanaged/BYOD devices limited to lower-trust resources. Certificate-based device authentication tied to MDM enrollment. Remote wipe capability for all managed devices.

Key controls: MDM/UEM · Device compliance policy · EDR on all endpoints · Certificate-based device auth · Conditional access on device health · BYOD containerisation

High Priority

🌐

Pillar 3: Networks

Eliminate implicit network-based trust. Software-defined micro-segmentation replaces VLANs. ZTNA replaces VPN — application-level access, not network access. All traffic encrypted (mTLS for internal service-to-service). DNS filtering and network flow analytics. East-west traffic monitored as carefully as north-south.

Key controls: Micro-segmentation · ZTNA/SDP · Encrypted all traffic (mTLS) · DNS filtering · Network flow analytics · SD-WAN with security

Medium Priority

🗄️

Pillar 4: Applications & Workloads

Application-layer authentication and authorisation for every request. API security gateway — rate limiting, input validation, auth enforcement. SASE/CASB for cloud application visibility. Container security and runtime protection. Workload identity for service-to-service auth (no embedded secrets). Runtime Application Self-Protection (RASP).

Key controls: API security gateway · SASE/CASB · Runtime protection · Workload identity · Container security · App-level MFA

Medium Priority

💾

Pillar 5: Data

Protect data everywhere — not just at rest in known locations. Data classification drives all security controls. DLP policies enforce data handling rules. DSPM discovers and protects shadow data. Encryption everywhere. Data access governance with continuous access reviews. Right to erasure workflows (aligns with DPDP Act).

Key controls: Data classification · DLP enforcement · Encryption at rest/transit · DSPM · Data access governance · Automated erasure workflows

Highest Impact

NIST SP 800-207 — Zero Trust Architecture

NIST Component	Description	Implementation
Policy Decision Point (PDP)	The "brain" of ZTA. Evaluates access requests against policy and grants/denies access tokens. Consists of Policy Engine + Policy Administrator.	Identity Provider + Conditional Access engine (Entra ID, Okta, etc.)
Policy Enforcement Point (PEP)	Enforces the decision made by PDP. Sits between subject and resource. Terminates connections that don't have valid access token.	API gateway, WAF, ZTNA agent, network firewall
Policy Engine (PE)	Makes the final trust decision — grant, deny, or revoke access. Uses enterprise policy + trust algorithm inputs.	Conditional Access rules, risk-based policies
Policy Administrator (PA)	Establishes/shuts down communication path between subject and resource. Generates authentication tokens or credentials.	IAM service, PAM solution
Trust Algorithm	Input factors: user identity, device health, network location, time, resource classification, previous activity, threat intelligence.	Risk score engine in identity provider
Continuous Diagnostics	Monitors asset state, software, and credential status. Feeds trust algorithm with real-time device/user posture signals.	EDR, MDM compliance, vulnerability management

ZTA Implementation Approaches

Enhanced Identity Governance

Use identity as the primary security control. All access decisions based on strong identity + device posture. Start here — highest ROI for ZT investment. IAM + MFA + PAM + IGA.

✓ Recommended starting point for most organisations

Micro-segmented Networks

Use network infrastructure to enforce boundaries around resources. Advanced SGs/ACLs, software-defined segmentation (VXLAN, SD-WAN). Blocks lateral movement.

⚠ Requires network infrastructure investment

Software Defined Perimeter (SDP)

All resources hidden from internet by default. Clients authenticate before any network access is granted. BlackCloud approach — infrastructure invisible without auth.

ZTNA (Zero Trust Network Access)

Application-specific access replaces broad VPN access. User authenticated + authorised before connecting to specific app. No lateral movement possible — user cannot scan the network.

✓ Modern replacement for legacy VPN

Zero Trust Maturity Assessment — CISA Model

Click each control to mark as implemented. Calculates maturity score per pillar across Traditional → Initial → Advanced → Optimal.

🗺️

Cross-Framework Regulatory Mapper

Select the frameworks your organisation must comply with. See which control domains overlap — implement once, satisfy multiple regulators. 15 control domains mapped across 6 frameworks: ISO 27001, CERT-In, RBI, DPDP, SEBI, IRDAI.

15 Control Domains 6 Frameworks Gap Analysis Roadmap Generator

Select Applicable Frameworks

Select all the frameworks your organisation must comply with — based on your industry, size, and customer requirements. The mapper will show where controls overlap and where gaps exist.

CERT-In Directions 2022

Mandatory for all India orgs

ISO 27001:2022

International ISMS standard

DPDP Act 2023

India data protection

RBI IT Framework

Mandatory for banks/NBFCs

SEBI CSCRF 2024

Mandatory for SEBI REs

IRDAI Guidelines

Mandatory for insurers

Control Domain Mapping Table

✅ = Domain applies to this framework · — = Not in scope

Control Domain	ISO 27001	CERT-In	RBI	DPDP	SEBI	IRDAI
Identity & Access Management	✅ 5.15–5.18	—	✅ Mandatory	—	✅ Mandatory	✅
MFA & Authentication	✅ 8.5	—	✅ Mandatory	—	✅ Mandatory	✅
Privileged Access Management	✅ 8.2	—	✅ Mandatory	—	✅ Tier 1–2	✅
Incident Reporting	✅ 5.24–5.28	✅ 6 hours	✅ 6 hours	✅ Without delay	✅ 6 hours	✅
Log Retention	✅ 8.15	✅ 180 days in India	✅ 5 years	—	✅ 5 years	—
Vulnerability Management	✅ 8.8	—	✅ Annual VAPT	—	✅ Frequency by tier	✅
Data Classification	✅ 5.12–5.13	—	—	✅ By sensitivity	✅ Mandatory	✅
Encryption at Rest & Transit	✅ 8.24	—	✅ Mandatory	✅ Required	✅ BYOK preferred	✅
Business Continuity / DR	✅ 5.29–5.30	—	✅ DCRSS tiers	—	✅ RPO/RTO defined	✅
Third-Party / Vendor Risk	✅ 5.19–5.22	—	✅ Mandatory	✅ DPAs required	✅ Exit strategy	✅
Security Awareness Training	✅ 6.3	—	✅ Annual mandatory	—	✅ Mandatory	✅
Governance / CISO	✅ 5.2–5.4	—	✅ Mandatory independence	✅ SDF: DPO required	✅ Board independence	✅
Consent Management	✅ 5.34	—	—	✅ Core obligation	—	—
Data Localisation	—	✅ Logs in India	✅ Payment data India only	✅ Cross-border whitelist	✅ Investor data India	—
VAPT / Penetration Testing	✅ 8.8 / 8.29	—	✅ CERT-In empanelled	—	✅ Tier-based frequency	✅

Interactive Gap Analyser

Select frameworks above (Selector tab), then run the mapper to see gaps. Or use this analyser to assess a specific organisation type.

Organisation Type

Implementation Roadmap — Priority Sequencing

Implement controls in this sequence to achieve maximum compliance coverage with minimum redundant effort. Each phase builds on the previous.

🔴

Phase 1 (0–3m)

CERT-In POC + 6h IR + NTP + log retention

→

🟠

Phase 2 (3–6m)

IAM/MFA + Access Control + Incident Playbooks

→

🟡

Phase 3 (6–12m)

VAPT + Vulnerability Mgmt + SIEM/SOC

→

🟢

Phase 4 (12–18m)

ISO 27001/SOC 2 certification + advanced controls

→

🔵

Phase 5 (18m+)

Zero Trust + DLP + DSPM + Continuous improvement

Phase 1 — Immediate Actions (0–3 Months)

Action	Framework	Effort
Register CERT-In Point of Contact (POC)	CERT-In	1 day
Configure NTP to time.nic.in on all systems	CERT-In	1 day
Configure centralised logging — 180-day retention in India	CERT-InRBI	1–2 weeks
Deploy MFA on all internet-facing systems and admin accounts	RBIISOSEBI	2–4 weeks
Create Incident Response policy and runbook	CERT-InRBISEBI	1–2 weeks
Designate CISO with Board reporting line (if regulated entity)	RBISEBI	Immediate
Begin DPDP gap assessment — map personal data flows	DPDP	2–3 weeks

GRC PlatformIndia-First Compliance Tools

GRC Hub — India-First Compliance Platform

CERT-In Directions 2022

RBI IT Framework

SEBI CSCRF 2024

DPDP Act 2023 Guide

ISO 27001:2022 Checklist

SOC 2 Toolkit

PCI DSS v4.0 Reference

Threat Modeling — STRIDE

Zero Trust Reference

Cross-Framework Mapper

CERT-In Directions 2022

Mandatory Fields — Initial 6h Report

CERT-In Contact Details

What NOT to Do

Parallel Sector Reporting

RBI IT Framework — Master Direction 2021

Board IT Strategy Committee

CISO — Independence Requirement

Quarterly Board Reporting

IS Policy Framework

Annual Security Training

Privileged Access Management

Authentication Monitoring

Privileged Access

Data Exfiltration Indicators

System Changes

Auditor Qualification

Scope of VAPT

Frequency

Reporting

Payment System Data

Core Banking Data

International Transactions Exception

Annual SAR Submission

What Triggers RBI Reporting?

RBI Reporting Portal

Parallel Reporting Obligations

Evidence Preservation

SEBI CSCRF 2024

Annual IS Audit

Cybersecurity Compliance Report

Incident Notification to SEBI

Board Reporting

Digital Personal Data Protection Act 2023

Valid Consent Requirements (§6)

Notice Before Consent

Consent Withdrawal (§6(4))

Consent Managers (§6(9))

Duty to Comply

Accurate Information

Penalty for Violations

What is a Personal Data Breach?

Who Must Notify?

Timeline

Notification Content

Transfer Mechanism

Current Position

Sector-Specific Restrictions

Government Exemption

🗺️ Cross-Border Transfer Risk Assessor

Penalty Process

Factors in Penalty Assessment

Voluntary Undertaking

vs GDPR Penalties

ISO 27001:2022 — Information Security Management

Mandatory Documents

Mandatory Records

Statement of Applicability

Timeline Estimate

SOC 2 Toolkit — Type II Gap Assessment

When to Get Type I First

When to Jump to Type II

Readiness Assessment

Indian SaaS Context

PCI DSS v4.0 Reference

Build & Maintain Secure Network

Protect Account Data

Manage Vulnerabilities

GRC Platform
India-First Compliance Tools